kintone認定エキスパート ドリルStep2
https://cybozu.co.jp/kintone-certification/level/kaizenmanagement-expert/
kintoneSIGNPOSTに対して、「なぜなら？」「たとえば？」を問うドリル
Step2です。
STEP2 プロジェクト企画
2-13 プロの伴走
自分たちだけでがんばらなくてもよい。
kintoneを使った業務改善において、その規模や難易度によってプロジェクトに関する判断軸がなく、進行に時間がかかってしまう。
なぜなら？
kintoneを利用した業務システム構築に知見のあるプロに、kintoneの導入や開発の伴走をしてもらう。
たとえば？
2-14 基本機能から考える
「カスタマイズ開発で実現できることか？」ではなく、「カスタマイズ開発でしか実現できないことか？」を確認する。
業務システムで実現したいことのイメージが先行してしまい、カスタマイズ開発の要件が複雑になってしまう。
なぜなら？
まずはkintoneの基本機能やプラグインで実現できる方法がないかを検証する。
たとえば？
2-15 自分たちのガバナンス設計
ゆるやかに始めて、自分たちのガバナンスを見つける。
最初からkintoneの自由度を制限しすぎると、現場メンバーのアイデアを活かせずkintoneの活用範囲が広がらない。
なぜなら？
最初はガバナンスにゆとりをもたせ、運用の中で理想的なガバナンス設計をしていく。
たとえば？
2-16 オープンな閲覧権限
必要以上にかくさずに、公明正大でいく。
「閲覧権限」を組織ごと役職ごとに細かく設定すると、組織変更や人事異動によるアクセス権のメンテナンスが煩雑になってしまう。
なぜなら？
「見せてはいけない情報」のみに閲覧権限を設定し、必要以上に情報をかくさない。
たとえば？
2-17 未来の変化への備え
「変化し続ける」という備え。
継続的な改善を想定していないと不便で使われないシステムになってしまうし、企画段階で全体を精緻に計画しても状況の変化によって無駄になってしまう可能性がある。
なぜなら？
今後起きる状況の変化に対して柔軟に対応できる保守体制を構築しておく。
たとえば？
2-18 守るべきデータ
本当に守るべきデータを見極める。
たとえkintoneに移行しても、現場メンバーによるデータ損失があった場合はデータは復旧できない。
たとえば？
損失が許されない業務データを洗い出し、重要性(影響度・更新頻度)に応じて業務データの管理体制を整備する。
なぜなら？
2-19 データの断捨離
システム移行時の移行データは最低限に。
既存システムやそのデータ形式によっては移行ができない、または移行するためのデータ整形に莫大な工数を要する場合がある。
なぜなら？
システム移行時にはデータの断捨離を考える。
たとえば？
2-20 小さなリリース単位
価値あるものは早く現場ユーザーに届ける。
一度にたくさんの業務アプリをリリースすると、現場ユーザーからのフィードバック対応や不具合対応が膨大になってしまい、対応しきれない可能性がある。
なぜなら？
業務アプリのリリースは、小さい単位で提供する。
たとえば？
この記事が気に入ったらサポートをしてみませんか？