はじめに
キントーンアプリデザインスペシャリスト合格に向けて、ここは落とせないという所を私的な目線でまとめるブログその2です。
今回は「プロジェクト企画」と「設計と構築」です。実務においても成否を分ける核となる部分ですね。
プロジェクト企画で落とせないポインツ
基本機能から考える
個人的に資格対策だけでなく業務においても一番大事だと考えている所です。
要件を色々出して全部実装しようとなった時に、kintone単体ではできないからコーディング追加しましょうといった進め方は非常に危険です。
追加機能間で不整合が起きたり仕様が把握しきれなくなることにつながります。
まずは目的を達成できる要件だけに絞り、かつkintoneの基本機能+プラグインで実装できるかを考える必要があります。
なんでもできるシステムは総じてやることが多いシステムになりがちです。結局大変じゃんとなって要件の再検討につながります。
どうしても必要ならば保守を含めた長期的視点でメリット・デメリットを考えましょう。
自分たちのガバナンス設計、オープンな閲覧権限
これは大体同じ内容になるのでまとめます。
システムにおいては閲覧権限の設定というものがつきものですが、何でもかんでも制限すればいい、というものではありません。
もちろん法令に則ったり経営陣か否かで見せられない情報は制限が必要です。
ただし、そもそも情報の共有がうまくいっていない、都度会議開いたり資料作らないと知るべきことも知れないのでは効率は非常に悪いです。
組織構造や共有したい情報を整理したうえでむやみやたらに権限は追加せずにオープンに閲覧できるようにするとスムーズな業務につながるでしょう。グラフを合わせて作れば集計結果を共有する会議をなくすことだって狙えます。
なお、一つのレコードに閲覧権限のあるフィールドとないフィールドが混在する場合どのように権限を設定するか、また関連レコードではどのように見たい情報だけ取得するかも併せて確認しておきましょう。
データの断捨離
権限設定以外にシステム開発あるあるなのが、既存システムからのデータ移行です。
今期のデータだけ移す場合もあれば過去数年分移すこともある結構面倒な作業です。
kintoneではcsvやExcelでレコードの一括登録ができるので大量データを一気に移行したくなります。
ですがとりあえず移せるものを移すのは危険です。そもそもいらない、誤登録したものが混在するといった異物混入や、移行データの準備・作業によるコスト増につながります。
サインポスト記載のデータの選別過程を頭に叩き込んで丸暗記してください。
設計と構築で落とせないポインツ
図に書く
試験合格、というよりも普段の業務で重要だよね、という意味の方が強いのですが図に書くのは本当に重要です。頭の中にある状態だけで話すと本当に同じものが共有できているのか、ずれは無いのかが全く分かりません。
業務フローだけでなく、権限設定についてもどの権限で何ができる・できないを視覚化することで漏れがないことの確認だけでなく不要なものを事前に除くこともできます。
ストック情報中心設計
画面を作っていると「備考欄」ってつけることあるじゃないですか。あれ、いらなくね？って思ったことある人いると思うんです。私です。
kintoneでも備考欄を配置することは可能ですが、レコードごとにコメント機能がありチャットのようにやり取りができます。備考欄で色々記録を残したいという要件が多いと思いますがこれは本当に必要か考える必要があります。
その時の基準がストック情報かフロー情報かです。
ストック情報とは、分析などに使われる情報で、フロー情報とは一時的な共有だけが目的の情報です。
例えば、商談用の商品名と価格は月ごとの売り上げなどの分析で使われるのでストック情報。商談用資料の進捗確認など一瞬把握できていればいいものはフロー情報となります。
ストック情報は特に問題ありませんが、フロー情報は場合によっては量が増えたり内容も変わってきます。備考欄一つでは対応しきれません。
そこで、コメント機能を使うことでレコードに余計なフィールドを置かずにレコードと紐づく形で情報を管理することができます。また、レコードと紐づけなくていい場合はスレッド上でやり取りするのも手です。
とにかく何でもアプリにフィールドを配置して管理しようという設計はアプリの安定稼働に影響するので丁寧な検討が必要です。
プロセスのシンプル化
ここだけじゃなく、サインポストほぼ全体と関わるといっても過言ではないと考えています。
既存のやり方を踏襲するのではなく、まずは図に起こし、目的にそぐわない要素を排除し本当に必要な作業だけに整理する。
シンプルにすることで基本機能で賄えるようになれば、プラグインや追加開発によるコストの削減もできます。
従来と違うやり方ではなく、従来より手間のないやり方になっているかが要です。kintoneにはモバイルアプリもあるため、社外でもデータチェックできることで不要な待機時間を削ることはできないかといった観点も必要です。
親子アプリ
顧客と見積のように一対多の構造となるデータは親となる顧客アプリと異なる見積アプリに分けるのが吉です。顧客情報の誤入力や表記ゆれを防ぎ、ルックアップやアクションを組み合わせることで入力の手間を除いたシンプル構造にもできます。
一つのアプリに何もかも詰め込む = シンプルではなく、各アプリが必要最低限の機能を有しルックアップのような連携機能で繋ぐことで各アプリで管理すべき情報を明確にする設計が求められます。
最軽量のアクセス権設定
アクセス権をあれこれ設けていろんなユーザーに付与すると当然レコードやアプリへの設定も増えるので長期的に見て管理が難しくなります。
権限設定を考える前に、扱うデータの中でこれだけは閲覧制限が絶対に必要というもの以外は制限せずユーザー単位で付与せずにアプリグループ単位やスペース単位での設定が結果的に管理しやすくなります。
細かい権限設定が想定されるケースとしては、関連レコードで情報共有する場合です。関連レコードから該当のレコードへアクセスできるため、その先で閲覧可否が分かれるレコードがある場合はその先で権限設定が必要になります。
試験ではkintone導入目的と照らし合わせてどの選択肢の権限設定が最適か、冷静に読み解く必要があります。
ほどほどのUIカスタマイズ
画面設計して開発してレビューしてもらったらユーザーからあれこれ指摘されて色々盛り盛りになる。あるあるだと思います。
特に現行のシステムがあってそこから新しいアプリへ移行する場合過去のやりやすさに評価内容が引っ張られがちです。
ですが、ここでがっつりとカスタムを加えてしまうと保守コストやkintoneのバージョンアップで動作に影響が出る可能性も0ではありません。
kintoneの基本機能だけで実装できないか、しばらく操作してみて慣れてきたら違和感がなくならないかを確認する必要があります。また、基本機能で賄えない場合はまずはプラグインで実現できないかを考える必要もあります。
API、JavaScriptによるカスタマイズはそもそも試験の範囲外なので、アプリデザインスペシャリスト合格という観点では勉強中は理解しなくてOKです。そういうのあるんだよな、くらいでOKです。
性能への気遣い
これはサインポストに書かれている内容よりもパターン実践ガイドにある「性能上の考慮点と改善策」の内容になります。
データ量、複雑度、アクセス数の観点から書かれていますが、これらの内データ量と複雑度は特に重要度が高いなという印象です。
データ量は長く運用すればするだけ増えるので、実践ガイドに記載されている各方法を理解して、試験では問いに対してどの方法が最適かを判断する必要があります。
複雑度は特に一覧画面に関する問いに関わってきます。いろんな項目を横並びに出して、詳細画面で見られる情報量と変わらないじゃないか、みたいなことありますがそれでは負荷が増えます。
あくまで詳細にアクセスするための一覧なので、表示する項目の取捨選択や複雑な条件は一覧切り替えにして、普段は単純なソート条件を最初に表示するといった工夫が必要か？という視点を持つ必要があります。
おわりに
だいぶ長くなってきたのと、結局ほぼ全部大事じゃね？という感じになってきたので今回はここまでで終わりとします。
読んでいるうちに各項目の内容が関連していると感じた方もいるでしょう。
実際にサインポストの内容を個別に覚えるよりもこことここは関連しているな、ということを意識しながら読むと定着しやすく、試験でも一見正解っぽい間違いを見抜く力になります。
アプリデザインスペシャリストを目指している方のお役に立てれば幸いです。
Discussion