kintone認定エキスパート ドリルStep3
https://cybozu.co.jp/kintone-certification/level/kaizenmanagement-expert/
kintoneSIGNPOSTに対して、「なぜなら？」「たとえば？」を問うドリル
Step3です。
STEP3 設計と構築
3-21 同一ドメインから
情報共有量が増えるように、意識的に環境を用意する。
各社要望の権限設定を考えるとkintoneのドメインを分けたくなるが、それではデータの二重管理や余計なコストがかかってしまう。
なぜなら？
まずは情報共有量の多い、同一ドメインでのkintone環境の構築から検討を始める。
たとえば？
3-22 3つ以上のアイデア
前例にとらわれずに批判的思考をもつ。
前例にとらわれ批判的思考なしに業務アプリを構築すると、後で手戻りが発生してしまうかもしれない。
なぜなら？
業務システムの開発方針やアプリ構成を決定する前には、アイデアを3つ以上挙げてそれぞれのメリット・デメリットを比較する。
たとえば？
3-23 図に描く
設定する前に図に描けば、見えてくる。
実施した改善が思わぬところに悪影響を及ぼしてしまう恐れがある。
なぜなら？
改善を思いついたら、まずは「図」や「表」に描いてみる。
たとえば？
3-24 ストック情報中心設計
情報の性質に合った場所選びが、その後のデータ活用につながる。
情報の性質にあった場所で共有、管理しなければ情報の活用、分析、再利用が難しくなる。
なぜなら？
特定の型で蓄積される「ストック情報」はアプリのレコードとして共有・管理し、不定形な「フロー情報」の共有・管理についてはスレッドやメッセージ機能を活用する。
たとえば？
3-25 プロセスのシンプル化
作り方の前に、プロセスをシンプルに。
現在の申請プロセスや運用方法そのままをkintoneで再現するだけでは、業務改善の効果は少ない。
なぜなら？
現行のプロセスをkintone化する際は、そのプロセスの流れを効率化・簡略化できないか検討した上でプロセスを再設計する。
たとえば？
3-26 担当別アプリ
業務プロセスでアプリを分けて、繋げる。
担当者ごとの作業やコミュニケーションが競合・混線してしまい、管理が煩雑になってしまう。
なぜなら？
構築するアプリに複数の業務プロセスや担当者が関わる場合、アプリを分ける検討をする。
たとえば？
3-27 親子アプリ
親子データでアプリを分けて、繋げる。
毎回手入力にすると手間が多く入力ミスの原因にもなってしまう一方で、ドロップダウンだけではすべてのケースに対処できず使い勝手の悪いシステムになってしまう。
なぜなら？
親子関係にあるデータは、親データを管理するアプリと、子データを生成するアプリに分ける。
たとえば？
3-28 最軽量のアクセス権設定
アクセス権の設定順序に気をつけて、設定を軽量化する。
行き当たりばったりに、ユーザー単位でのアクセス権を設定すると、人事異動が発生するたびに権限の再設定の手間や、それに伴う設定ミスの危険性が発生してしまう。
なぜなら？
上位の設定項目や、組織やグループごとのアクセス権で設定をすることで、軽量なアクセス権設定を保つ。
たとえば？
3-29 ほどほどのUIカスタマイズ
一度立ち止まって、カスタマイズの必要性を考える。
UI/UXの大幅なカスタマイズは、kintoneのアップデートの影響を受け、アップデート後に想定通りの動きをしなくなる可能性がある。
なぜなら？
UI/UXカスタマイズは「ほどほど」を念頭に置いて検討を進める。
たとえば？
3-30 共通のマスタアプリ
マスタアプリはみんなで使えるように整備する。
様々なチームがそれぞれアプリを作成すると、kintone上に類似のマスタアプリが複数でき、管理や運用が煩雑になってしまう。
なぜなら？
マスタアプリは、全社で共通利用できるように整備する。
たとえば？
3-31 性能への気遣い
kintoneの特性を知って、性能に配慮した設計をする。
kintoneの特性を理解せず、性能に配慮しない構築をすると、いざリリースした後に性能低下の問題が生じる恐れがある。
なぜなら？
それなりの規模のシステムの設計をする際は、データ量×複雑度×アクセス数が膨れ上がらないように【設計への気遣い】をする。
たとえば？
3-32 開発環境の用意
安全に、変更を試せる場所を作る。
実装したアプリや加えた設定変更を試してみたいが、いきなり本番環境に反映すると、不具合があった場合などはユーザーの業務に影響を及ぼしてしまう。
なぜなら？
設定変更の影響をテストできる開発環境の準備を考慮する。
たとえば？
この記事が気に入ったらサポートをしてみませんか？