設計と構築

3-29

ほどほどの
UIカスタマイズ

一度立ち止まって、カスタマイズの必要性を考える。

状況

kintoneアプリで作ったプロトタイプを現場メンバーに試してもらったところ、UI/UXに関して様々な要望が上がってきた。たとえば以下のような具合だ：
・「使い慣れた既存の業務システムに比べて、kintoneはフィールドの大きさやフィールド同士の間隔が大きく、入力速度が落ちそうだ。これらを小さくしてほしい。」
・「『アプリ」や『スペース」という文言がわかりづらいので、画面に出てくる文言をすべて自社で決めた文言に変更したい。」
・「kintoneではレコードのコメント欄が右側にあり使いづらいので、左側から出せないだろうか？」

現場メンバーが使いやすい見た目にしたいという気持ちから、これら要望についてカスタマイズ開発での対応を検討しはじめた。

▼その状況において

問題

UI/UXの大幅なカスタマイズは、kintoneのアップデートの影響を受け、アップデート後に想定通りの動きをしなくなる可能性がある。

kintoneの見た目や使い勝手を既存の業務システムに合わせるなど、大きな変更を加える場合、kintone APIのドキュメントで記述されていない実装方法を選択せざるを得ない場合がある。この方法は、サイボウズが推奨しないカスタマイズとなるので、kintoneのアップデートの影響を受け、カスタマイズした部分が想定通りの動きをしなくなる可能性がある。
また、この時点で出てくる現場メンバーからの見た目や使い勝手への要望は、旧来のシステムへの慣れなどからきている物が多く、新システムに慣れていくにつれて解決する可能性もある。その場合、コストと時間をかけて実装したカスタマイズが不要になることもある。

▼そこで

解決

UI/UXカスタマイズは「ほどほど」を念頭に置いて検討を進める。

【基本機能から考える】(2-14)ことを踏まえながら、見た目や使い勝手に関する要望には以下のように対処する。

1．現場メンバーのUI/UXへの要求（例：入力スピード・入力データの正確性・利用時の負荷の軽減・利用者のリテラシー補助など）とその優先度を整理する
2．基本機能であるフォーム設計やフィールド設定でUI/UXを検討する
3．その後、連携サービスやプラグインを利用したUI/UXの利用感の向上を検討する

利用者のkintoneへの慣れがUI/UXへの要求を解決することもあるので、この時点で一定期間実際利用する現場メンバーにテストしてもらう時間をもつのもよい。

4．最後に、基本機能や連携サービス、プラグインで対応できず、かつ優先度の高いUI/UXへの要求については、カスタマイズ開発によるメリット・デメリットを整理し、カスタマイズ要否とその実装方法を決定する

▼その結果