最近、職場でキントーンの画面デザインや操作性を上げて欲しいとの要望を数多く頂く。サイボウズ社の提供するSaaS型サービスのキントーンは予め用意されている機能が豊富で強力なDXツールであるものの、確かにデザインは短調でどこか味気ない。

1. キントーンのカスタマイズを支えるJavascript

一方で、たびたびこのブログでも取り上げているとおり、キントーンには JavaScript によるカスタマイズが可能になる機能が標準で実装されている。JavaScript と言えば、Web黎明期はFLASH技術に追いやられ、日の目を浴びない時期はあったものの、00年代中頃から、GoogleによるAjax（JavaScript + XML）技術の採用を皮切りに、jQueryといった優れたライブラリ登場やV8エンジンの登場で見事に復権してきた経緯がある。特にjQueryによるDOM操作は、製作者がこれを駆使することでWebに多様なアニメーションやエフェクトによるリッチな表現をもたらし、現在の大Web時代に至る幕開けを築くのに大いに貢献したといっても過言ではないだろう。

それから、はや時は10数年経ち、JavaScriptはサーバ上で動作する「node.js」や「React.js・Vue.js・Angular.js」といったフレームワークの登場でもはやWeb技術の中心位置へと上り詰めていく。我らは食い扶持を求めて新しいものの登場に敏感に反応し、ただただまっすぐに追いついていくだけだが、jQueryはもはやレガシーな技術となって最近では勉強する者も少ないと聞く。（俺困惑。しかし、Webフロントエンドの進化早すぎ。。）

2. jQueryでキントーンの見た目を無限にカスタマイズ

前置きが長くなったが、話をキントーンに戻す。個人的所感では、キントーン上での話であれば、jQueryのDOM操作は、見た目や操作性向上に極めて有効だ。もちろん、複雑になりがちなjQueryの欠点を補うべく登場したのがReactやVueであるのだが、これらを使うと有効なのはHTMLの変更に一定以上の自由が認められている場合で、キントーンにはあまりあてはまらない。HTML変更に自由がなく、部分的なデザイン修正をいくつか繰り返すのみであれば、jQueryの方が小回りが効いて使い易い。（い、異論は認めないから。）

下の動画は、jQueryによるDOM操作を駆使してキントーンの見た目・操作性を、ユーザ要望に合わせて向上させた例。

3. カスタマイズはチームで取り組もう

jQueryを駆使するにせよ、このようなカスタマイズを一人で行うのは膨大な作業量で、専門分野毎に分業を可能にするチームの存在は欠かせない。ここで少しメンバー紹介を。

まず、一人目は、北村彩夏さん。現在、同部署でキントーンカスタマイズ画面のデザインを担当し、HTML・CSS素材のコーディングも行っている。彼女は、当初キントーン運用のサポートをして頂いていたが、途中一念発起して経験ゼロからWebデザインを学習。上の動画の素材も彼女が作成したものである。現在はJavaScriptまで領域を広げて、Webフロントエンド全般を習得しようと挑む頼もしい存在だ。もちろんこの世界に誘ったのは俺で、何が言いたいかというと、どうだ凄いだろ！、と。笑

続いて紹介するのは、やはり同部署で相棒の辻村幸輝さん。当初は、利用者との間に入ってプロジェクトマネージャー的役割を担ってもらっていたが、彼もキントーンの無限の可能性に導かれた一人で、途中一念発起し、キントーンのJavaScriptによるカスタマイズに取り組んでいる。現在は、キントーンカスタマイズの伝道者的な立場になっていたりもして、彼に導かれた社内の人間は実に多い。もちろん彼もWeb製作などの実務経験はこれまでゼロで、誘ったのは俺。（どうだ！すご・・いや何でもないす。）

このように、当初は何でも一人でやって疲弊していたが、彼らの成長のお陰で、本来得意とするサーバーサイドの開発や新規案件に集中できるようになった。何より、チームで取り組むから、課題解決のスピードも早く、案件成就のの喜びも共有して楽しいのだ。とりわけ、現代は実際に手の動かせる高度技術者が世の中全体で不足していて採用が極めて困難な時代、ゼロから人材を育てるのも一つの計。もし、かつての当方のように一人で開発取り組んでいる方がいたら、周りを見てシステムやデザインに素養高そうな近隣の仲間を勧誘するところから是非お勧めしたいと思う。

JavaScriptのDateオブジェクトで日付を扱う際は実に落とし穴が多く、初心者は必ずといっていいほど躓いてしまう。JavaScriptによるkintoneカスタマイズを初めたビギナーが日付を扱った際に、どうも上手くできないと相談を受けることが多かったので、躓きかぎなポイントなどを記事でまとめておこうと思う。

1. 躓くポイント①〜「月」取り扱いの罠

まずは、百聞は一見に如かずで、実際に現在の日付を取得して、月の数字を抜いてみる。

const date = new Date(); //Mon Feb 18 2019 16:04:22 GMT+0900 (日本標準時)
console.log(date.getMonth()); //1

あれ、２じゃないの？となる。笑 日付型の数値から値を取り出す方法としてDateオブジェクトではgetMonthメソッドが用意されているが、これを実行すると、1始まりではなく0~11を返すので、実際の月を得るには +1してあげなければならないのだ。こんなの事前に知っておかないと戸惑うよね。笑

2. 躓くポイント②〜「年」取り扱いの罠

まだまだあるJavaScriptによる日付の罠。年取得ではgetYearとgetFullYearの２つのメソッドがある。このうち、getYearは、殆どの人が下二桁の数値を返すと思いがちになるが、実際には1900を引いた数字が返る。笑

const date = new Date(); //Mon Feb 18 2019 16:04:22 GMT+0900 (日本標準時)
console.log(date.getYear()); //119

JavaScript開発者は世紀末論者で2000年を迎えることを想定していなかったのか！？本当にあった「西暦2000年問題」を体現してるようで、なんだか胸熱だ。笑 まったく実用的ではないので、フル４桁の数値を得る getFullYearのみを使うのが吉。

3. 躓くポイント③〜タイムゾーン補完の罠

Javascript は、日付文字列を日付にパースする際に時刻情報を持たないとタイムゾーンを勝手に補完するが、それが一定しない。「/」区切りだとJST(日本標準時)と解釈され０時の扱いとなり特に問題ないが、「-」区切りだと元々UTC（世界標準時）として解釈されて+0900が補完され９時になる。

const date = new Date('2019/02/18'); //Mon Feb 18 2019 00:00:00 GMT+0900 (日本標準時)
const date = new Date('2019-02-18'); //Mon Feb 18 2019 09:00:00 GMT+0900 (日本標準時)

タイムゾーン補完の解釈があいまいなのは、これだけではない。マシンが日本語環境の場合、大抵の場合は jst のままで扱われるが、例えばJSON化した場合や、kintone でも REST APIのGETメソッドで日時フィールドを取り出した際は、jstとして解釈された後にUTC日時に置き換えて出力されるなど、実際に日付が変わってしまうので実にやっかいだ。

const date = new Date('2019/02/18'); //Mon Feb 18 2019 00:00:00 GMT+0900 (日本標準時)
console.log(date.toJSON()); //2019-02-17T15:00:00.000Z
console.log(JSON.stringify(date)); //2019-02-17T15:00:00.000Z

こうした罠を回避するために、出力データがどのタイムゾーンで扱われるか、不要なところで±9時間の処理が行われていないか気を配る必要があり、扱いが実に煩わしい。

4. moment.js を使ってみよう

dateオブジェクトの不足点を補う JavaScript のライブラリーとして、moment.js がある。業務アプリ内で日付を複雑に扱う場合には、最近はこのライブラリをできる限り使用している。このライブラリーを読み込んで momentオブジェクトが使えるようになれば、日付文字列を日付にパースする場合も文字列の型によってタイムゾーン解釈の揺れは発生せず、日本語環境であればJSTでの出力が標準になる。

console.log(moment('2019/02/18')._d); //Mon Feb 18 2019 00:00:00 GMT+0900 (日本標準時)
console.log(moment('2019-02-18')._d); //Mon Feb 18 2019 00:00:00 GMT+0900 (日本標準時)

JSONデータやkintone のREST APIでの出力する日時データなど、UTCで出力される前提のものは、momentオブジェクトで再出力すればJSTに変換される。+9時間するよりは多少は楽か。

const date = JSON.stringify(moment()); //2019-02-17T15:00:00Z
moment(date)._d; //Mon Feb 19 2019 00:00:00 GMT+0900 (日本標準時)

なお、月が0~11で出力されるのは、dateオブジェクトと変わらず・・・。

const date = moment(); //Mon Feb 18 2019 16:04:22 GMT+0900 (日本標準時)
date.month(); //1

kintone での moment.js の使用方法は、［設定］ - ［JavaScript / CSS でカスタマイズ］ にて、Cybozu CDNからライブラリを読み込むだけで良い。[何日後］のような計算を簡易に行えるメソッドなど、dateオブジェクトには無い機能が沢山備わっているので、是非利用をお勧めしたい。（詳しくは、こちらサイボウズ社のデペロッパー向けサイト）から！）

前記事では JavaScriptについて、割と好意的に書いている。だが、この際はっきり言うと、JavaScript にはいくつか罠がある。今回、記事にとりあげる少数計算（少数点以下の数値を含む計算）もそのひとつだ。

1. 突如現れる誤差の衝撃

それは前触れもなくやってくる。そう、少数を含む計算を行う際に。

let result = 0.1 * 0.1;
console.log(result);  //0.010000000000000002

なん・・・だと・・・。0.01が正解ではないのか？0.000000000000000002はどこから来た？と思うだろう。

なぜ、このような結果になるかというと、それはJavaScriptで扱う数値がIEEE754で規定されている浮動少数であることに起因する。更になぜ浮動少数かと掘り下げると、コンピューター内で数値は最終的にバイナリ形式で、1と0の並び（２進数）で表現されることにより密接に起因する。例えば、0.1 のように１０進数では綺麗に表現できる数値でも、２進数で表すと0.00011001100… のように小数点第2位から0011が循環して永遠に終わることのない無限少数となる。これを決められたデータ型に格納するために有効桁数以下を丸めるべく2進法では0捨1入するわけで、その丸めた結果誤差が生じるのだ。（丸め誤差、と呼ばれる。）

2. どうすれば回避できるのか

よく取り沙汰されるのが、少数を整数にして計算し、再度少数に戻す方法。しかしながら、これは少数を整数にする際に少数計算が発生するため、結局誤差が生まれかねない。

そこで、一番シンプルで有効な回避策は、①いったん数値を文字列化し、文字列操作でドット(.)を排除して整数とする。②整数同士で計算を行ったうえで、元のドットの位置をもとに10^Nで割って元の少数へ戻す、という手順だと考える。うむ、これなら少数計算は発生しないので、誤差も生じない。

let strA = '0.1';
let strB = '0.1';
let dotposiA = (strA.length-1)-strA.indexOf('.'); //ドットの位置からstr1の少数点以下桁数を取得
let dotposiB = (strB.length-1)-strB.indexOf('.'); //ドットの位置からstr2の少数点以下桁数を取得
let preresult = parseInt(strA.replace('.','')) * parseInt(strA.replace('.',''));  //1
let N = dotposiA + dotposiB;
let result = preresult / Math.pow(10, N); //0.01 

期待する結果が得られ、なかなか良さげ。

そのほか、ライブラリを使う方法もある。有名どころでは、BigDecimal.js と decimal.js の２つがあるが、試しに decimal.js の方を使ってみた。

<script type="text/javascript" src="decimal.js"></script>
<script>
let a = 0.1;
let b = 0.1;
let dec = new Decimal(a);
console.log(dec.times(b).toNumber());  //0.01
</script>

これもよりシンプルでいい感じ。

* * *

このように JavaScript は、いくつか落し穴的な要素があるので、今後も機会を見て紹介していきたい。（他によく取り沙汰されるものとしては「日付の罠」がある。これは近日記事にしたいと思う。）

この度、会社でサイボウズ社のキントーンを導入することになった。　導入部門より導入前にS社やND社のサービスをはじめ複数候補間での比較で何度か相談を受けたが、ある一つの明確な理由でキントーンを推してきた。

1. 軽量で素早い開発が可能

その明確な理由とは、キントーンでアプリを開発する際の環境にある。

キントーンは予め用意された機能以外の動作・アクションを実装する場合に、JavaScript言語を開発環境とする機能が用意され、公式にサポートされている。JavaScriptと言えば、短い記述で処理を実現でき、手軽に取り扱うことができる軽量なスクリプト言語として位置付けられる。対極には、JavaやCなどコンパイルを前提とし開発環境を作る時点でかなり煩わしい作業が発生するコンパイラ言語があり、一方同じ位置付けの言語としては、いま人気のPythonや昔ながらのRuby,　PHPなどがあるが、これらはいずれもサーバ上で動く言語だ。それに対しJavaScriptはHTML・CSSと同様にブラウザ上で動くWebフロントエンドの言語として軽量さでは群を抜く。ブラウザ上で動くということは、つまりサーバーをセットアップして開発環境を用意せずとも、手軽に手持ちのPCでコードを書き、ブラウザで動作確認やデバッグがささっと行えてしまうのだ。

もちろん、JavaScriptはここ10年でWebフロントエンドの主要言語として確固たる地位を築いてきた経緯があり、いまや勉強したい言語の人気ランキングで必ず上位にきて裾野が広いメジャー言語である点が背景にはある。また、軽量であれば無条件に良いというわけでなく、案件に応じてはJavaやCのような使用するメモリ領域まで細かく管理する言語の方が向くものもある。（Javaからキャリアをスタートした当方も軽量な簡易言語に触れると、こんな端折った記述でいいのかと不安になることも・・。）しかしながら、OSや大規模システムを作るならいざしらず、業務アプリレベルの話であれば、殆どの案件で軽量プログラミング言語で事足りてしまうのが事実なのである。

そして、軽量な開発が行えるということは、IT導入によりデジタルトランスフォーメーションやコスト削減など何らかの成果を持続可能な状態で継続的に上げていこうとする場合、成功のカギを握る重大な要素であり、究極的にはその要素の有無が成否を分ける。

2. やりたかったのはアジャイル開発の実践

なぜ、ここまで「軽量で素早い開発」に拘るのかといえば、企業のIT導入とは、目的ではなく継続的なプロセスだという事実を認識しており、短いスパンで短期間で失敗を積み重ねることが最終的に成功に至るための強力なアプローチだと確信しているからだ。

このような考えに至ったのは、現在世界のITをリードする米国では主流となり日本でも導入企業が増えているアジャイル開発にかつてより関心を持ち、根底にある思想・概念を知ろうとしてその起源たる「アジャイルソフトウェア開発宣言」（2001年）を目にした時からだ。

現在、ソフトウェア開発では、機能駆動型開発（FDD）やスクラムなど優れた新手法が次々と生まれているが、これら手法の根底にはこの宣言がある。また、アジャイル開発でとるべき行動をより具体的に表したのが、この宣言に続いて出された「アジャイルソフトウェアの12の原則」である。

初めて目にした日から10年以上経つ今読んでも実にいいことが書かれているわけだが、企業がアジャイル開発を実践するにはそれを実現できる環境の整備が求められ、願わくばソフトウェア開発を内製化できる環境の実現が望ましい。そしてそれは容易ではない。外注丸投げ文化が根付いてしまった典型的日本型企業であればなおのことそうであろう。

一方、キントーンは、前述のとおり「軽量で素早い開発が可能」なツールで、当初からこの要求に十分応えられる内容であった。仮に当初は当方一人で難易度の高い開発やカスタマイズを続けることになったとしても、感度が高く素養の高い仲間を身近集めて必要な知識を与えていけば、後に十分開発メンバとして迎え入れることができ、提供者側と利用者面の両面で規模を拡大していけると確信が持てるのだ。

3. あとはやるだけ

期せずしてキントーン導入で程良い環境が整ったのが、大事なのは実際にアジャイルをやってみせることで、要は日々実践のみ。先日、当方がメインとなって、導入後第一弾となるアプリをリリースした。もとより短納期であり、かつ現場の要求は緻密かつ多岐にわたるためリリースの前日まで仕様の変更が発生するような厳しい工程になったが、まずその変更が理にかなったものであったため、利用部門の変化を好意的に受け容れ、まさしくリリース直前まで再リリースとフィードバック、デプロイを繰り返した末に予定日当日に無事リリースした。そして、こういったアクションがとれるのも、軽量で素早い開発が可能なキントーンを選定したことによる恩恵である。

その後、利用部門の反応も上々で、既に当方が加わって開発着手がきまった案件が複数ある。今後もキントーン開発に拍車がかかると思うが、そこで得るアイディアやノウハウを【kintone カスタマイズ Tips】として、このブログで備忘録的に記録して発信していきたいと思う。

自分は、もはやGitHub が無い生活は考えられないくらいこのサービスの恩恵を受けているが、日常的に使わないコマンドはいつもうろ覚えで、ネット検索にお世話になっている。いい加減おぼえろやと自省して、いつも忘れがちになるコマンドをまとめておく。

1. ローカルリポジトリを作成してリモートに push

まずはローカルレポジトリを作成したい場所までターミナル上で移動して、'git init' を実行。続けて、普通に 'git add' から 'git commit' まで実行してしまう。（ファイル数0から始める場合は、'git add' 前に適当なファイルを作っておく。）

% git init

% git add .

% git commit -m "適当に first commit などのコメント"

次に push 先となるリモートのリポジトリをGitHub上で作成し、ローカルからアドレスを指定して紐付けを行う。（アドレスの指定は SSH で行うのがお勧め。push の度に、ユーザ名とパスワードを入力する手間が省ける。但し、事前にローカル環境で公開鍵と秘密鍵のペアを作成し、このうち公開鍵を GitHub に登録しておく必要がある。）アドレスは、GitHub のレポジトリ毎のページに記載があるので、それをコピペ。

% git remote add origin 紐付けするリモートリポジトリのアドレスを 'HTTPS' または 'SSH' で指定

最後に 'git push' を実行。実行時に、'-u' または '--set-upstream' のオプションをつけることで push 先のブランチがトラックされ、これ以降 push や pull のデフォルトの対象先として設定できる。

% git push -u origin master

% git push --set-upstream origin master

2. commit を安全に取り消す

'git reset' では、commit が削除されてもはや最初から無かったことになってしまう。これは、かなり危険なのであまり多用したくなく、作業がかなり進んだ段階では、'git revert' だけを普段使うようにしている。

% git revert <commit ID>

% git revert HEAD

'git revert' 自体の変更履歴が残るので、それ自体取り消してまた 'commit' 後の状態に戻れたりと、作業の取り返しが何度でも可能。既にリモートに 'push' した後の 'commit' を取り消した後は、pushも忘れずに。（'git revert' 自体が、新しい 'commit' の追加になるので、 '-f' オプションは不要。）

% git push origin master

なお、直前より前の 'commit' を取り消すと、その後の 'commit' の内容に同一ファイルの変更が含まれる場合などにコンフリクトが発生し、カオスな状態に陥り易くなるため、直前以外の 'revert' を多用する際は注意したい。

3. ローカルの変更を破棄

ローカルで幾つか変更を加えて save するものの、何かモヤモヤして git に展開する前に元に戻したくなる時がたまにある。そんな時に使うコマンド。

% git checkout <filename>

% git checkout .

まあ、ひとまずこんなところで・・・。まだまだ 'merge' だとか'rebase' だとか色々あるが、機会を見つけて本ページ内に追記していきたい。