SREホールディングス株式会社でプロジェクトマネージャ（PM)をしている鍋谷です。
システム開発で最も難しいのは、実現したい仕様を決めることだと思っています。
それはさまざまな組織や人の思惑がぶつかり、仕様が発散するリスクをもっているからです。そのぶつかる工程が要件定義です。
この記事では、私がこれまで経験してきたシステム開発から学んだ要件定義の重要性と仕様決定者へのアプローチ術について詳しく解説します。
対象読者
・システム開発のプロジェクトマネージャ
・お客様とシステムの仕様を調整するシステムエンジニア
・コミュニケーションスキルを向上させたい人
要件定義の重要性
要件定義は、システム開発プロジェクトにおいて最も重要な工程の一つです。この工程では、プロジェクトの目的や目標を明確にし、システムがどのように機能するべきかを詳細に定義します。要件定義がしっかりと行われていないと、プロジェクトの進行中に多くの問題が発生し、最終的にはプロジェクトの失敗につながる可能性があります。
実際、プロジェクト遅延の主な原因の50％以上が要件定義の問題に起因しているというデータがあります。この驚くべき事実は、要件定義がシステム開発プロジェクトの成否を左右する重要な工程であることを示しています。
独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」P23より引用
システム開発では期待していたものと異なる成果になるとトラブルのもととなります。要件定義が適切に行われることで、プロジェクトの方向性が明確になり、関係者全員が同じ目標に向かって進むことができます。
仕様を決める人（仕様決定者）を特定する
要件定義の成功には、誰が仕様を決定するのかを明確にすることが不可欠です。人間が決める以上、誰が決めるかによって仕様が変わってきます。それは誰もがいつも論理的に判断できるとは限らず、時には感情や他人の意見に流される場合があるからです。
私がPMとして、あるお客様のシステム開発をしたときに苦い経験があります。
A株式会社のシステム管掌部長のBさんから、要件定義を一緒に進める担当者Cさんを紹介されました。Bさんは「システムの仕様は担当者Cさんと詳細を詰めてもらえればいいから」とおっしゃられました。担当者Cさんと要件定義を進め、無事に要件定義を終えることができました。
しばらくしてプログラム開発をはじめたころ、A株式会社の中でシステムの仕様レビューが行われました。そこで問題がおこりました。担当者Cさんと詰めた仕様は、部長のBさんにほぼ全否定され要件定義からやり直しとなりました。
仕様決定者は担当者Cさんではなく、部長のBさんだったのです。
少し極端な例ですが、仕様決定者の特定は早い段階で必要です。
仕様決定者を分析する
仕様決定者の特定ができたら、その人はどんな人物か分析します。人は何かを決めるとき、ある判断基準に従って決めます。判断基準がみんな同じであれば仕様は同じになるはずですが、現実は違います。判断基準に影響する観点は以下の３つの観点です。
仕様決定者がこれらの観点をどのようにもっているかを事前に理解する・しないことで、要件定義の成否に大きく差があらわれます。
(1)価値観
価値観は、要件定義で仕様を決める上で最も影響が大きい観点です。
(a) 理想の仕様
システムを開発する上で、純粋にシステムを良くしたいという願いから出てくる仕様です。仕様の方向性はどの視点を重視するかによって変化します。例えば以下のようなものです。
-
ユーザ視点
システムを利用するユーザが使いやすいことを目指すもの。例えば、画面の見た目や操作性に優れているなど。 -
運用者視点
システムを安定して運用できることを目指すもの。例えば、システムの自動運転や障害時の検知や回復手順が簡単であるなど。 -
開発者視点
開発効率やコードの品質を重視するもの。例えば、コードが読みやすく保守しやすいことや、開発環境を整えることなど。
(b) 組織の文化
システムを開発する上で、組織の文化によって仕様が大きく左右されます。例えば、以下のようなものです。
-
コスト重視か、価値重視か
- コスト重視：短期的な予算制約のなか迅速な導入を目指す
- 価値重視：長期的なビジネス価値や顧客満足度を重視して高機能を目指す
-
イノベーション重視か、品質重視か
- イノベーション重視： 新しい技術や方法を積極的に取り入れることを優先する
- 品質重視： 製品やサービスの品質や安全性を優先する
-
上下関係が強いか、水平関係が強いか
- 上下関係が強い： 明確な階層構造があり、指示や決定が上位から下位に伝達される
- 水平関係が強い： 階層構造が少なく、全員が対等な意見を出し合う
(c) 個人の関心
仕様決定者によってシステム開発に対する関心事が異なります。例えば、以下のようなものです。
-
成果の認知
-
システム開発の成功や成果物が組織内外で認められたい
システム開発の成功が自分のキャリアにプラスになることを期待し、社内外での評価を重視します。例えば、新しいシステムが予定通りに導入され、業務効率が向上した場合、その成果が上層部や顧客に認知されることを望みます。 -
成果は及第点があればよく減点されなければいい
特に大きな失敗がなく、最低限の成果を達成することで、評価が下がらないようにすることを目指す人もいます。例えば、予算内でシステムを完成させ、基本的な機能が動作することで、プロジェクトが無事に終了することを重視します。
-
システム開発の成功や成果物が組織内外で認められたい
-
人間関係
-
上位者とのネットワーキングで昇進や昇給を期待している
上司や経営陣との良好な関係を築くことで、昇進や昇給の機会を得ることを目指す人もいます。例えば、プロジェクトの進捗報告や成果発表の場で、上層部に自分の貢献をアピールすることを重視します。 -
チームメンバーや同僚と良好な関係で仕事を進めたい
チーム内の協力やコミュニケーションを重視し、良好な人間関係を築くことで、システム開発の成功を目指す人もいます。例えば、定期的なミーティングを通じて、チーム全体の意見を取り入れながら進めることを重視します。
-
上位者とのネットワーキングで昇進や昇給を期待している
-
自己興味
-
自分が興味ある分野や技術に取り組みたい
自分の興味や情熱に基づいてシステム開発に取り組むことを重視する人もいます。例えば、新しいプログラミング言語やフレームワークを試す機会を得ることで、自己成長やスキルアップを目指します。
-
自分が興味ある分野や技術に取り組みたい
価値観の輪
上記の価値観をイメージで表示すると以下のようになります。価値観の強さを大きさ、価値観の関係を重なりで表現します。これを価値観の輪と呼ぶことにします。仕様決定者（組織）で大きさ・重なりが異なり、価値観の輪の形状によって仕様決定者の特性をあらわすことができます。この特性をよく理解することが重要です。
3観点が重視される価値観の輪
組織の文化が重視され、個人の関心は組織内に向いている価値観の輪
組織より個人が重視される、理想の仕様を追及する価値観の輪
価値観の輪は、個人（組織）を特定できれば、その形状は一意に決まります。しかし、価値観の輪を外からゆがめるものがあります。「経験」と「感情」です。以下では、なぜ「経験」と「感情」が外からゆがめるかを具体的に説明していきます。
(2)経験
ここでいう経験とは、組織や個人が過去のシステム開発で得た知見やノウハウのことです。経験には、成功と失敗があります。
(a)成功経験
組織や個人は、過去の成功経験を過大評価してしまう傾向があります。過去の成功はさまざまな条件が重なり、たまたまうまくいった場合もあるにも関わらず、それに気づかずに過大評価してしまうのです。
- 成功経験からのゆがみ
- 経験： 複数部門が使用するシステムの開発で、各部門から代表者を集めたクロスファンクショナルチームを編成し、要件定義を共同で実施。各部門のニーズをバランスよく反映したシステムが完成し、全体の業務効率が向上した。
- 今回の行動： 今回のシステム開発もクロスファンクションチームを編成した。
- ゆがみ： 複数の仕様決定者が存在し、組織の文化や個人の関心がバラバラだった場合、仕様が発散するリスクが大きくなる。
(b)失敗経験
失敗経験もまた、過大評価されることがあります。失敗から学ぶことは重要ですが、過去の失敗が必ずしも現在の状況に当てはまるとは限りません。
- 失敗経験からのゆがみ
- 経験： 要件定義が終わったあとに、システムの仕様を上位者に説明したところ、仕様を否定され、要件定義をやり直した
- 今回の行動： 仕様は自身で勝手に決定せず、上位者に都度確認することとした。
- ゆがみ： 多忙な上位者が時間をとれず、仕様が決まる時間が長引くリスクが大きくなる。上位者の意見が優先され、個人の関心が埋没していく。
経験が価値観をゆがめるのは一時的な期間です。繰り返し同じことを経験したり、時間が経過すると、価値観に取り込まれていきます。運悪くこの一時的な期間に要件定義を進めると、最初と最後で仕様決定者の言っていることが変わってくることがありますので、注意が必要です。
(3)感情
仕様決定者の個人の関心を最もゆがめるものが、その人の感情です。感情は他の人から見えづらく、タイミングが読めないので、非常にやっかいです。例えば以下のような感情があります。
(a) 好き・嫌い
好き・嫌いは個人の好みで判断が揺らぐ場合があります。
例えば、UIデザインで好きな色やフォントを提案されると無条件に受け入れたり、仕様説明の言いまわしが嫌いでその提案を受け入れられないなど、価値観の輪から外れた判断をすることがあります。
(b) 安心・不安
安心感や不安感で判断に影響する場合があります。
安心感を求める人は、リスクを避けるために保守的な選択をしがちです。例えば、新しい技術や方法を導入する際に、不安を感じるとその提案を拒否することがあります。
一方で、安心感を得られると感じた場合、その提案を積極的に支持することがあります。
(c) 誇り・恥
誇りや恥の感情も判断に大きな影響を与えます。
例えば、仕様の説明をされたときに、その内容を理解していないのにそのことを知られるのが恥ずかしいと感じて、理解しているふりをして判断してしまうなどです。
仕様決定者にアプローチする
仕様決定者の特定と分析が、要件定義を進める上で重要であることを説明しました。それでは、実際にどのように仕様決定者にアプローチすればよいのでしょうか？
アプローチの手順は以下のとおりです。
(1) 信頼を得る
仕様決定者から信頼を得るためには、以下の行動が効果的です。
(a) 接する回数を増やす
信頼を得るにはまず好感度をあげることです。相手に対する好感度を上げるためには、接する回数を増やすことが重要です。頻繁にコミュニケーションを取ることで、相手との距離が縮まり、信頼関係が深まります。
コミュニケーションの内容はなんでもかまいません。あいさつひとつでもよいです。とにかく会って話す回数を増やしてください。
(b) 聞く側にまわる
相手と話ができるようになったら、相手の話をよく聞くことが重要です。聞く側にまわることで、相手の考えや感情を理解しやすくなり、信頼を得ることができます。
相手の話を聞くときに注意すべきことがあります。
-
相手の話をさえぎらない
相手が話している途中で口を挟まず、最後まで話を聞くことで、相手は自分の意見が尊重されていると感じ、信頼を深めることができます。 -
相手の感情に共感する
相手の立場に立って考え、共感を示すことで、相手は自分が理解されていると感じ、信頼を寄せやすくなります。
(c) 約束や時間を守る
信頼関係を築くためには、一貫性と誠実さが重要です。約束や時間を守り、誠実に対応することが基本です。
(2)本音を引き出す
仕様決定者の分析をするには、「経験」「感情」をいかに理解するかによります。「価値観」は公式な情報であるRFPやプロジェクト憲章・システム化構想などの文書で公式情報として公開される場合が多いですが、「経験」「感情」のような非公式な情報は文書化されていません。この見えない「経験」「感情」の情報を得るには本音を引き出すしかありません。
では、本音はどのように引き出せばいいのでしょうか？
これは2種類の人がいて、それぞれアプローチが違います。
(a) 本音を話せない人
本音を話せない人とは、本当は話したいと思っているが心理的な壁が邪魔しているタイプです。このようなタイプには、自己開示が効果的です。自己開示とは、自分の考えや感情を率直に話すことで、相手も安心して本音を話しやすくなるという方法です。例えば、自分の経験や失敗談を共有することで、相手も心を開きやすくなります。
(b) 本音を話さない人
本音を話さない人とは、話す内容を選別して意図的に本音を話さないタイプです。このようなタイプには、相手が欲しい結果は何か理解する必要があります。その欲しい結果と引き換えに本音を話してもらうのです。
(3)人物を理解する
本音を話してもらうことで、仕様決定者の本当の人物像を知ることができます。特に「感情」は公式な会議や打ち合わせだけではわかりません。非公式な場でよく会話して、どういうときに感情が動くかを理解しましょう。
ここでの紹介したアプローチ術はシステム開発の要件定義に限った話ではありません。営業のマーケティングや心理カウンセラーなど、さまざまな職種の方がそのノウハウを公開しています。
最近読んだ参考となる書籍を紹介します。アプローチのステップは少し違いますが、本質的には本記事と同じようなことが書かれていると思います。
まとめ
要件定義はシステム開発プロジェクトの成功に不可欠な工程です。要件定義がしっかりと行われることで、プロジェクトの方向性が明確になり、関係者全員が同じ目標に向かって進むことができます。しかし、要件定義の成功には、仕様決定者の特定と分析が重要です。
仕様決定者の価値観、経験、感情を理解し、信頼関係を築くことで、より正確な要件定義が可能になります。信頼を得るためには、接する回数を増やし、相手の話をよく聞き、約束や時間を守ることが基本です。また、本音を引き出すためには、自己開示や相手の欲しい結果を理解することが効果的です。
これらのポイントを押さえることで、要件定義の精度が向上し、プロジェクトの成功に近づくことができます。要件定義の重要性を再認識し、適切なアプローチを取ることで、システム開発プロジェクトを成功に導きましょう。
Discussion