システムを作らせる技術

社内の業務システムを改修する仕事に携わっているため，『システムを作らせる技術』（白川克，濱本佳史，日経 BP，2021年7月21日）を読んでみた。

「Why → How → What」の順で考えなければならない。そうしないと何をやりたいかがぼやけてしまうし，うまく説明できないから関係者を巻き込むことはできない。結果として良いシステムは完成しない。（pp. 24 - 25）

何をやるにしても，Why → How → What の順で考えよう。

うまく説明することができれば，関係者を巻き込んでいける。

業務フロー作成のテクニック６箇条（p. 87）

変換点を必ず書き出す

まずはアナログで作る

フォーマットを決める

メインフローが先，イレギュラーが後

詳細はとりあえず脇に置く

1 人で作らず，人を巻き込む

業務フローを作成する時の参考にする。

業務の変化点を抑えておくことで，システムにしたときの効果を算定しやすくなる。

漫然と言われたことをやっているだけでは，構造を理解できない。すると将来像の議論には参加できない。

皆さんは自分の現在の業務を「ちゃんと」語れるだろうか？（p. 93）

業務を語るために，自分の業務の構造を描いてみよう。

機能を洗い出す 7 つの方法：基本編（p. 111）

現行システムから洗い出す

標準テンプレートから洗い出す

業務フローから洗い出す

ソリューションや入門書で抜け漏れをチェックする

機能を洗い出す 7 つの方法：応用編

ビジネスの文脈を捉え，将来への布石を打つ

新規ビジネスモデルから導き出す

シーズ × シーンマトリクスを使う

機能を洗い出す方法の 1 ～ 3 はできていると思うが，4 以降の方法は不足しているかもしれない。

この方法で開発を予定している機能をチェックしてみよう。

FS*1 に書きこと 4 つ

実現したいこと

扱う情報

他の機能との関連

バリエーションやイレギュラー

FS に書かないこと 2 つ

実装方法

画面イメージ

ベンダーより機能一覧を提示してもらっているが，システムを作らせる側として，Function Spec を作ってみるか。

これから機能ごとに開発する／しないを選んでいくのだが，そのベースとなる考え方はとてもシンプルだ。

「効果があり，簡単に作れ，簡単に使いこなせる機能を真っ先に作る。それよりも優先順位が落ちる機能は後から作る。もっと優先順位が低い機能は作らない」（p. 160）

この考え方は，投資する時の考え方と同じ。

今後多くの社員の仕事に影響がある意思決定なので，プロジェクト関係者に説明したり，選定経緯を後で振り返ることができるように，きちんと資料を残そう。経営会議などで，説明する際の資料にもなる。このために新たな情報を集める必要はなく，これまでの経緯を誰が見ても理解できるようにまとめておくだけで良い。（p. 245）

誰が見ても理解できるように資料を残すのは，大事なこと。

チームのメンバーにも，言っているが，実践できる人・実践できない人に分かれる。

投資決裁を仰ぐ際に，改めて説明すべき情報は以下になる。（p. 273）

現時点で何がまずいか → 現状調査の結果

だからこうなりたい（ビジョン・将来像） → 将来のあるべき姿

ビジョン実現のために，こんなシステムが必要になる → FM にまとめた内容

選定したベンダーやパッケージと，その理由 → 選定結果

必要なリソース（費用，時間，体制）

全体として，投資する価値があること

投資決裁を仰ぐ資料は，上記のフレームに当てはめて作成してみる。