勉強日記（2023/02/13）要約チャレンジ100字2

昨日に引き続き、kintone SIGNPOSTの要約してみた！
眠くて寝そうｗ

1-12～2-25 

1-12 先駆者の話
kintoneを利用した業務システム構築や導入を担当している人の話を直接聞きにいくことで、実践現場での工夫や苦労、考え方について情報を得られるため、自分の実践のイメージをよりふくらませることができる

2-13 プロの伴走
スキルの低さからkintoneで実現できる内容かすら分からないことがあるが、kintoneのプロが伴走することで判断基準が明確になり、システム開発や運用体制作りが加速する。

2-14 基本機能でから考える
すぐにカスタマイズせず、業務要件が複雑になっていないか基本機能で実現できないかを確認する。基本機能やプラグイン・連携サービスでは実現が難しい場合にのみ、カスタマイズ開発を検討する。

2-15 自分たちのガバナンス設計
kintoneを使い始める時はガバナンスに余裕を持たせる。運用の中で権限やルールを決めていき、組織にあったガバナンス設計にし、アプリ作成のルールを決める。

2-16 オープンな閲覧権限
見せてはいけない情報以外をオープンにすることで組織内における情報格差が小さくなり、業務の属人化を予防できる。また、業務システムのパフォーマンス向上やメンテナンス工数削減も実現できる。

2-17 未来の変化への備え
プロジェクト終了後の保守体制・保守費用を用意しておくことで、現場ユーザーの要望やビジネス状況の変化に迅速に対応でき、継続的に業務効果を出せる。

2-18 守るべきデータ
損失が許されないデータを洗い出し、重要度に応じた管理体制を整備する。適切なアクセス権を設定したり、定期的にファイルに書き出したりしてデータを守る。

2-19 データの断捨離
データの範囲や役割分担を考えて断捨離をする。移行データは業務フローを見直して最低限とする。不要なデータは参照用として既存システムに残したり、アーカイブ化したりする。

2-20 小さなリリース単位
小さなリリース単位だとフィードバックを早くもらうことができる。また小さい単位で業務アプリを使い始めれば良いので、比較的容易に新しい業務アプリに慣れる事ができる。

3-21 同一ドメインから
「開かれた情報」を考慮して同一ドメインから考え、通常どおりに使用したり、組織間アクセスやゲストスペースを使う。同一ドメインが難しければ連携サービスや複数ドメイン準備する。

3-22 3つ以上のアイデア
アイデアは3つ以上出し、批判的思考で考える。過去事例を参考にしたkintoneが業務に最適かどうかを内省する。業務の付加価値やシステム化のコンセプトを考え、業務にフィットしたアプリを作る。

3-23 図に描く
現状や改善後の内容について、図や表を使って可視化する。それぞれの要素の依存関係や影響範囲も見えやすくなるため、思わぬところに悪影響を及ぼすことを未然に防ぐことができる。

3-24 ストック情報中心設計
定型的なデータはストック情報として、コメントなどはフロー情報として情報の活用、分析、再利用をまで踏まえて考えることで、どの情報をフィールドとして配置すべきかがわかりやすくなる。

3-25 プロセスのシンプル化
プロセス設計の見直しの際は、業務の付加価値を明確にして、その業務の目的や付加価値に立ち返ったり、図に描くでプロセスの全体像を把握したりすることで、プロセスの不要な部分を見つけられる。