今回は先日読んで勉強になった「システムを「外注」するときに読む本」について私が気になった内容や特に実務に活かしていきたい、活かしていけると思う考え方、ノウハウ、学んだことを取り留めもなく紹介したいと思います。
こちらは、これまで大小問わず70を超えるプロジェクトに携わり、システム開発で起きるあらゆるトラブルに触れてきた細川義洋さんが、システム開発をシステムベンダーに発注する側の視点として、どうしたらシステム開発を成功に導くことができるかを凝縮した本です。
ぜひ、書店でも手に取っていただければと思います。
書評
システム開発を発注する側は勿論、システム開発を請け負うシステムベンダーの人も必見です。
私自身もシステムベンダー側の立場として、顧客（発注者側）と要件定義やプロジェクトマネジメントを通じて顧客折衝する機会が多いですが、その時はいつも、いかに顧客をコントロールするかを考えています。特に、顧客企業にはシステム部門が存在せず、経理や総務部門がシステム担当を兼任しているような顧客も多く、そうした場合は、システムベンダーが顧客側も巻き込んでシステム開発を推進する必要があります。そういう意味でも、発注者側の立場を理解しておくことは、システムベンダーにとっても非常に有益です。
本書は、物語調で進んでいくため、読みやすいかと思います。一方で、教科書的な使い方をするには使い勝手は悪いかなという感じです。
スポンサーリンク
ポイント
- 業務要件定義は発注者側が主導する
- システム化の範囲を間違えない
- プロジェクト管理能力を測る
- 本業扱いとする
- ベンダーのリスクも共有する
- 発注者がベンダーを育てる
これら６つに加えて、システム開発における重要な工程である要件定義工程の終わり方やパッケージシステム導入におけるポイントについても触れたいと思います。
スポンサーリンク
業務要件定義は発注者側が主導する
要件定義は、「業務要件定義」（どのような業務にしたいか、ToBeとしてどのような業務を実現したいか、どのような業務にするか）と「システム要件定義」（業務要件定義で定めた業務を実現するために必要となるシステムをどのようにするか）に大別できます。
そのうち、「業務要件定義」については発注者側が責任を持たなければなりません。
本書では、次のように述べられていました。
「業務要件定義」については、発注者自身が全面的にリードしなければいけません。現在の自社の業務弱点や今後の方向性を明らかにして、新しい業務をイメージする作業ですから、社外ベンダにはわからないことも多く、ベンダからは「同業他社ではこんな業務をしているみたいですよ」と情報提供を受ける程度であるのが一般的です。
システムを「外注」するときに読む本 細川 義洋（著）
また、業務要件定義で作成する業務フローにはあらゆる情報を書き込むようにも述べられています。具体的には、業務フローには「懸念と理想」をできるだけ記載することを改めて学びました。
これは私がベンダーとして要件定義でも実践しています。業務フローにはあらゆる情報が付いている方がシステム要件定義、システム設計、基本設計というその後の工程のインプット情報が増えるため、基本的にはプラスに働きます。ただし、情報が発散しすぎて、混乱を招くような情報は記載してはいけませんし、誤った情報は後々の工程での手戻りに繋がるため注意が必要です。昔私自身も先輩から「上流工程で作成した文章の１文は、プログラムになったら1000stepになる。それだけ責任を持て」と言われたことがあります。それだけ、上流工程で作成するドキュメントは重要だということです。
スポンサーリンク
システム化の範囲を間違えない
システム化する範囲を間違えてはいけないことが強く謳われています。
システム化するのは、効果が明確に説明できるところだけ（中略）システム化する範囲は、本当にそこをコンピュータでやるべきか、何度も考えてきめる
システムを「外注」するときに読む本 細川 義洋（著）
効果が明確なところのみシステム化する一方で、効果が不透明であるところについてはシステム化を見送ることが大切ということを学びました。
私も経験してきましたが、現行業務でうまくいっているところ、その企業の強みといえる部分をシステム化しようとして、逆に良さが失われてしまうという苦い経験もしてきました。
発注者は業務のプロとして、判断基準を誤ってはいけません。
スポンサーリンク
プロジェクト管理能力を測る
発注者は、システム開発を委託するベンダーの技術力は勿論、それと同じかそれ以上に、プロジェクト管理能力を測る必要があります。プロジェクト管理を測る方法としては、「プロジェクト計画書」「プロジェクト管理計画書」を確認する方法が挙げられていました。
その他にも、リスク管理台帳、課題管理台帳、欠陥管理台帳を確認することも有効です。
また、一般的にプロジェクト管理工数は、全体の10%と見積るのが相応しいとされていると本書にも記載されていました。これは、色々なところで言われている割合になりますが、ベンダーの立場として工数見積する際にも活きる目安であるため覚えておくことと良いと思います。
あくまで目安ですが、例えばメンバーが4人＋１人（PM自分）の時は、１か月の工数は100人日（5人月×20日）となります。そのため、そのうちの10%、つまり10人日が管理工数に当たる計算になります。そのため、月の半分は管理作業をすることになり、１日に直すと半日は管理作業をすることになります。
あくまで目安ですし、”管理作業”をどこまで含めるかによっても定義はあいまいですが、目安として使うと良いと思います。管理作業の中に、成果物レビューも含めるのか、メンバーが参加する定例会などは管理工数としてみなすのかなどによっても変わってくる部分かと思います。
スポンサーリンク
ベンダーが負うプロジェクト管理義務
システム開発において、要件や仕様の変更に伴う計画の見直しは日常茶飯事です。それについて、本書では次のように記されていました。
理由はどうであれ、プロジェクトが計画通りに進まないなら、何等かの是正措置を提案すること。その際に費用が発生するなら、正しく見積もること、結果としてお客様がそれを受け入れてくださるかは別として、とにかくそうした提案と見積もりを行うこと。これを怠ったベンダは、プロジェクト管理義務違反に問われます。
（中略）
ベンダが何の提案も見積もりも出さずに、結果プロジェクトが失敗した場合、損害賠償の対象になる
システムを「外注」するときに読む本 細川 義洋（著）
ベンダーの立場である私からすると耳が痛い話ですが、たしかに至極当然です。これを踏まえていえることは、ベンダーはこうした追加見積作業も含めた管理工数の計上が必要になるということを感じました。
スポンサーリンク
ベンダーのリスクも共有する
プロジェクトには様々なリスクが存在します。その中でも、ベンダー内部のリスクについて、どのように考えるかについて整理していました。
ベンダが自分達の内部で解決すべき問題については、発注者に明かさずに抱え込むケースが多い
（中略）
ベンダがリスクを開示しなかったらことで困るのは、何も知らされずにある日突然ベンダから「実は・・・」と打ち明けられる発注者側なのだ。
システムを「外注」するときに読む本 細川 義洋（著）
ベンダーの立場からすると、技術的な問題（ex.テスト環境の整備ができていない、扱う技術についてのナレッジがない）や体制上の問題（ex.技術者が離任した、体調不良によって稼働ができなかった、有識者が不在）などを発注者（顧客）に伝えることは勇気がいることです。しかし、それでも、伝えることが顧客のためになると思い、正直に打ち明けることで双方の為になるとのことでした。打ち明けることで、解決策を見出せることもあるということでしょうか。
発注者とベンダーは敵同士ではありません。協力して１つのプロジェクトを成し遂げるチームであることを忘れてはいけないと改めて感じました。
スポンサーリンク
発注者がベンダーを育てる
発注者は”業務屋”、ベンダーは”システム屋”ということができると私は思います。
そうした中で、ベンダーは業務のことを業務屋に、発注者はシステムのことを”システム屋”から教わりながら、プロジェクトを進めていきます。
本書でも発注者側の立場において、次のように記されていました。
モヤモヤが消えるまで質問や注文を繰り返すことで、発注者もベンダも、今のやり方の正しいさに自身が持てる
システムを「外注」するときに読む本 細川 義洋（著）
前述した通り、プロジェクトは、発注者とベンダーとの協力によって進めます。そのため、互いに納得感を持って進めることが成功には欠かせません。
ベンダーの立場としても、よくわからない業務があったり、イレギュラーな業務ケースが考えられる場合は憶測でシステム化を考えるのではなく、納得するまで質問をし、その結果をもとにシステム化を考える姿勢が求められるということを改めて本書から学びました。
スポンサーリンク
要件定義成功への鍵
本書では、発注者側の立場で要件定義をどのように進めるべきか、どのようなことを意識すべきか整理されています。そこで、本書でも紹介されいた要件定義での確認ポイントや要件定義の終わらせ方について非常に参考になったため一部紹介したいと思います。
要件定義で確認すべきチェック項目
要件定義成果物を確認する際には、次のような観点でチェックすることで、要件定義の品質を確保することができます。
【システムを「外注」するときに読む本 細川 義洋（著）】をもとに一部抜粋。
〇要件は必要且つ十分か
✓記載されている要件は、顔初や導入の目的に寄与するか
✓記載されてい派生要件は、親となる要件に寄与するものか
〇要件は十分に詳細化されているか
✓要件は設計者が迷いなく設計できる程度に詳細化されているか
✓最下位の要件に、異なる操作者・タイミングの操作や処理が混ざっていないか
〇業務の例外や異常は考慮できているか
✓例外的な業務や処理を漏れなく記載しているか
✓異常処理を漏れなく記載しているか
スポンサーリンク
要件定義中盤・終盤での確認ポイント
要件定義の中盤や終盤では、現在の要件定義状況を把握し、今後の進め方、そして終わらせ方を検討していきます。
【システムを「外注」するときに読む本 細川 義洋（著）】をもとに一部抜粋。
✓要件などは未決事項ないか？
✓未決事項はいつまでに、誰が、どのように決定するのか？
✓未決事項の対応により、影響を受ける他の要件はないか？
要件定義中に無理やりすべての検討事項を完了させる必要はありません。ただし、積み残された課題に対して上記で記載したような取り決めを１つずつしておく必要があるとのことでした。
スポンサーリンク
まとめ
いかがでしたでしょうか。
以上、細川 義洋著 システムを「外注」するときに読む本を読んでみての感想と私が特に思い留めておくべきだと感じた内容や学んだ内容でした。
発注者側の立場でも、ベンダーの立場でも、システム開発に携わる人が全員把握しておくべきことが記されいたので、ぜひ本書を手に取っていただければと思います。
まだまだ紹介したい内容もありますが、その内容は本書を手に取っていただければと思います。
コメント