古いプログラマー: 需要分析の経験あり

以前私が書いたブログ記事「満足できるコードの書き方」では、ユーザーのニーズが不確実なため、全体的な設計フェーズで常に目的が定まらないという問題が発生する、と読者がコメントで述べていました。要件分析はもちろん非常に重要であり、場合によっては全体的な設計よりも重要です。では、需要分析をどのように理解すればよいのでしょうか?

「需要分析」というキーワードを Google で検索すると、インターネット上で関連記事が多数見つかります。その多くは教科書のように包括的かつ正確に書かれており、ベストプラクティスの分類方法もいくつか提供されています。この記事では、個人的な観点から私の経験についてお話しします。

まず、最も重要な質問は、なぜ需要分析を行う必要があるのか​​、あるいは需要分析の重要性は何なのかということです。この問題については、人それぞれ異なる経験があるかもしれません。要件分析の意義は、プロジェクトが提供すべき成果物を正確かつ明確に表現し、要求者の承認を得ることで、プロジェクト全体のベンチマークを確立することにあると私は考えています。要件が変更されないことを期待することはほぼ不可能です。プロジェクトの進行中に、開発者と需要者の両方が変更を提案する可能性があります。したがって、要件分析 (および変更管理) の目標は、決して変更されない要件を定義することではなく、開発の開始からプロジェクトの終了まで、両者が要件 (変更後の要件も含む) について一貫した理解を持つことを確実にすることです。

少し抽象的なので、例を挙げて説明しましょう。

たとえば、プロジェクトの開始時に形成された要件分析には、「アプリケーション システムは、事前に定義されたパーソナライズされたテンプレートに基づいて、各ユーザーのデータに対応する PDF レポート ファイルを自動的に生成し、ユーザー情報に事前に設定された電子メール アドレスに送信できます。」のような記述があります。

この要件に応えて、開発者は PDF ファイルを自動的に生成するプラグインを見つけました。このプラグインは XML テンプレートを読み取り、渡されたデータに基づいて PDF ファイルを生成します。しばらくして機能が完成し、ユーザーのプロジェクトマネージャーが生成されたPDFを見て良いと感じ、プロジェクトは順調に進みました。

しかし、段階的な承認の段階になると、ユーザーは試用期間を設けましたが、一般ユーザーは XML テンプレートの編集方法を知らず、非常に面倒でフォーマットエラーが発生しやすいと感じたため、この機能に誰もが不満を抱いていました。現時点では、ユーザーがテンプレートを「見たまま」の方法で編集できるように、編集インターフェイスを提供すべきだとユーザーが提案するのは当然です。

ここで問題が起こります。要件にはこのようなインターフェースの必要性について言及されていないため、開発者はこれを要件の変更だと考えます。これにより、プロジェクトのスケジュールと予算を調整する必要があり、おそらく誰かがユーザーに開発コストの増額を求めることになるでしょう。ユーザーは、これは開発作業の質が悪いと思うでしょう。ユーザー自身が XML を編集できる機能を作成するにはどうすればよいでしょうか。XML が何であるかを知っているユーザーを 100 人中 1 人見つけることさえ困難でしょう。ましてや、XML を編集できるユーザーなどいないでしょう。したがって、この問題については双方が絡み合うことになるでしょう。これはプロジェクト全体のほんの一部です。一枚の葉っぱですべてがわかります。他の部分にも問題があるはずです。

ユーザーが無茶苦茶なのか、それとも開発者が怠惰なのか？実は、どちらでもありません。問題は要件の定義が不正確であることにあると思います。開発者が要件分析プロセス中にテンプレート形式の問題についてユーザーとコミュニケーションを取っていれば、ユーザーは最初の機会にテンプレート編集の必要性を明確にするでしょう。このように記述された要件は、「アプリケーション システムは PDF テンプレート編集機能を提供でき、ユーザーは WYSIWYG 方式でパーソナライズされたテンプレートを定義し、テンプレートに基づいて各ユーザーのデータに対応する PDF レポート ファイルを自動的に生成し、ユーザー情報に事前設定された電子メール アドレスに送信できます。」などです。このような要件はより厳格であり、後で議論になる問題を減らすことができます。もちろん、「定期的」という概念が何なのか、週に 1 回なのか月に 1 回なのか、ユーザーがカスタマイズできるのか、ユーザーが選択できるいくつかの標準オプションを提供するのかなど、厳密さが足りない部分もあります。需要分析プロセスでは、これらの不明確な定義に注意を払う必要があります。その不確実性と最悪の結果を十分に認識していない限り、それを無視すると、将来的にプロジェクトに問題を引き起こすことになります。

私の考えをまとめると、プロジェクトでは、ユーザーの辞書にはドキュメント、収入、レポート、監査などが含まれ、開発者の辞書にはキー値、インデックス、ボタン、イベントなどが含まれます。要件分析は翻訳機のようなもので、ユーザーの言語と開発者の言語を統合して、両者がお互いの意味を正確に理解できるようにし、開発作業を開始する前に両者がお互いのアイデアを真に理解できるようにします。

需要分析における重要な要素について、私自身の経験では主に次の3点が挙げられます。

1. ビジネスを深く理解する

需要アナリストは、ユーザーのビジネスについて非常に深く理解している必要があります。非常に深い理解とは、ユーザーの経営陣とビジネス上の問題について活発な会話ができることを意味します。金融商品を扱うときにリスク管理を理解していなければ、フォーラムを扱うときに SEO を理解していなければ、人事システムを扱うときに組織行動を理解していなければ、どうやってビジネスを深く理解できるでしょうか?

これを読んで、「ユーザーはどんな機能を実行する必要があるか説明してもらえればそれでいいのに、なぜ彼の業界についてそこまで深く理解する必要があるのか​​」と言う人もいるかもしれません。私が言いたいのは、需要分析も多くのレベルに分かれているということです。レベルが上がれば上がるほど、ビジネスに対する理解が深まる必要があります。

もう一つの例を挙げましょう。プロジェクトは、企業管理システムの開発を目的としています。クライアントは、複数の製品ラインを扱う多数の支店を持つ企業グループです。グループは、支店の業務管理が断片化していることに悩んでいます。これまでの慣例では、各支店が毎月末に各製品ラインの事業報告書をグループにファックスで送信し、その後グループが事業統計を実施していました。現在、顧客が求めているのは、各支店にグループと同様の業務管理システムを導入し、グループのプラットフォームにデータレポートモジュールを作成し、各支店が自社システムから電子データをエクスポートしてグループにアップロードできるようにすることで、受付や統計の効率化を図ることです。

「適切な」要件分析では、要件を正確に記述し、厳密に定義できるため、開発者はユーザーを満足させる機能を開発できます。 「より良い」需要分析では、さらに一歩進んで、支店が報告しなくてもグループがいつでも各支店の業務状況を確認できる大規模な集中システムを構築できるかどうかをユーザーと話し合い、それによって虚偽の報告やデータの隠蔽の問題を排除することができます。 「より優れた」需要分析により、組織構造を変更することなく (組織構造の問題は需要分析の範囲外であり、プロジェクトの範囲外であるため)、情報システムのサポートを通じてマトリックス ビジネス管理を実現することについてユーザーと話し合うことができ、それによって各事業ラインに対するグループのマクロ管理能力が向上し、各製品ラインに対するグループの戦略がより適切に実装されるようになります。

おそらく、誰かが「より優れた」ビジネス分析を行っているかもしれませんが、ビジネス分析の結果が詳細であればあるほど、ユーザーにとっての価値が高まり、開発チーム全体に対するユーザーの認識も高まることがわかります。これはプロジェクトの成功にとって非常に重要です。顧客が、ビジネス管理能力の強化に役立つソリューションを提案してくれたことに非常に感謝しているとしても、メニューの色が十分かどうかについてまだ議論するでしょうか?

2. ユーザーと十分にコミュニケーションをとる

まず、どのようなユーザーがいて、それらのユーザーがどのように関連しているかを把握する必要があります。すべての人を満足させることは難しい、ユーザー間で意見の対立が起きるという古い格言があります。たとえば、経営幹部は、できるだけ多くのデータを集めたいと考えています。今は使えなくても、将来、データマイニングツールが開発され、それが突然大きなメリットになるかもしれません。一方、データ収集を担当する現場のユーザーは、当然、自分たちにとって十分なデータであれば、できるだけ少ないデータを集めたいと考えています。一部のビジネス部門では、ビジネス データを多くの人に知られたくないと考えています。プロジェクトによっては、一部の部門が権限を失い、一部のリーダーが職を失うことさえあるかもしれません。そのため、プロジェクトにおいては、要件検討会議においてさまざまな意見が出ることが多々あります。声の背後には立場があり、立場の背後には利益がある。経験の浅い要件分析者は、これらの意見に簡単に惑わされ、作成する要件は寄せ集めになりがちですが、これはまさに一部のユーザーが望んでいるものです。

こんな時、どうすればいいでしょうか？私は古いプログラマーとして、先祖から受け継いだ秘密のレシピを持っています。それは、ユーザーに最も大きな影響を与えるリーダーを見つけて、プロジェクトの全体的なアイデアについて話し合い、リーダーの意見に従ってユーザーのニーズを選別することです。リーダーのアイデアと明らかに矛盾するものはすべて捨てられ、リーダーのアイデアと一致するニーズは完全に洗練されます。ビッグリーダーとは、IT部門のマネージャーや情報部門のディレクター、顧客プロジェクトマネージャーなどではなく、プロジェクトに関連するビジネス上の問題について最終決定を下せる人物です。たとえば、人事システムに取り組んでいる場合、ビッグリーダーは少なくとも人事部長であり、財務システムに取り組んでいる場合は少なくとも財務部長です。もちろん、トップリーダーが積極的に関与できればより良いでしょう。上級リーダーと議論するプロセスは、彼らのアイデアを理解するプロセスであるだけでなく、ニーズを精査するプロセスであり、さらに重要なことに、彼らの支持を得るプロセスでもあります。上級リーダーのサポートがあれば、会議中に下から大きな騒音があっても、落ち着いて自信を保つことができます。

また、「いつでも大ボスに会えるのに、あなたは何者だと思っているんだ？」とつぶやく人もいるかもしれません。これは、先ほどお話しした最初の問題、つまり、ビジネスに対する理解の深さと関係しています。プロジェクトが開始すると、上級リーダーは通常、日常的にプロジェクト チームと会議を行い、上級リーダーにも印象を残すことになります。データベース、フォーム、Javaフレームワークなどの話ばかりしていると、上司はあなたに関心がなくなり、当然会いたがらなくなります。このプロジェクトに関連するビジネス分野における最大の競合相手の長所と短所、海外でのビジネス管理経験などを話すことができれば、上司の主賓として頻繁に招かれるようになるかもしれません。したがって、プロジェクトを成功させるには、ビジネスを深く理解することが重要です。

要件に関する議論、上級管理職との面談、ユーザーとの議論など、ユーザーとのコミュニケーションにはさまざまな形式があります。まずは現場のユーザーとたくさん議論し、たくさん質問し、あらゆるビジネス上のつながりを徹底的に理解し、需要分析の基礎となるいくつかのフォームとデータを収集する必要があると思います。次に、上級管理職との面談を実施して、全体的なアイデア、戦略、目標などのマクロの問題を理解します。要件に関する議論は通常、後の段階で行われ、主に議論の余地のある問題や明確に定義されていない問題に焦点を当て、アイデアを集めるために行われます。これは実際にはブレインストーミングの方法です。こうした議論において、需要アナリストは記録者となるだけでなく、より多くの質問をしてより多くの提案をし、独自のアイデアを使ってユーザーに刺激を与え、大胆な仮定を立てて慎重に検証する必要があります。しかし、ユーザーの意見を尊重することにも注意しなければなりません。ユーザーが技術を理解していないから、ただ聞いているだけだと考えることはできません。それをどのように実装するかは技術的な問題であり、ユーザーにはあまり関係がありません。これは後の段階で問題を引き起こすことがよくあります。

3. 強力な技術的背景と厳密な思考力を持つ

要件分析はビジネスとテクノロジーをつなぐ架け橋であり、要件ドキュメントはユーザーに対するコミットメントです。要件ドキュメントを作成する場合、要件アナリストは相当の技術的背景を持ち、各要件の実装パス、難易度、およびおおよその作業負荷を理解し、ビジネス担当者と技術担当者の両方が明確に理解できる厳密な方法で要件を記述できる必要があります。もちろん、これは前のセクションでユーザー（技術者を含む）と十分にコミュニケーションをとった上でのものです。

需要分析者の中には、技術的なバックグラウンドがあまりない人もいます。それでは、適切な需要分析ができないのでしょうか? 私はそうは思いません。このようなときにこそ、チームの力が必要なのです。また、高度な技術力を持つ開発者がバックアップし、要件について話し合い、技術的なアドバイスを提供して、ビジネスに関する理解とコミュニケーションスキルを最大限に活用できるようにすると、良い組み合わせになります。

ドキュメントの作成は、要件担当者のライティングスキルをテストします。時には、すべての文や単語を慎重に検討する必要があり、注意しないと、自分自身に穴を掘ってしまう可能性があります。弁護士になったような気分になりますよね? ビジネスとテクノロジーの両方を理解できるようにするのは、確かに簡単ではありません。ここで、もっと絵を描くことをお勧めします。時には、1 枚の絵が何千もの単語の価値があることもあります。フローチャート、データフロー図、組織図、ユーザーインターフェース図など、できるだけ多くの図を描きます。図とテキストを組み合わせれば、読者の理解が簡単に迷うことはなくなります。

最後に、要件ドキュメントが作成された後には、それを印刷して各コア ユーザーにコピーを渡すことを忘れないでください。数日以内に 1 回だけ改訂を提案できることを通知します。最初の要件の最終バージョンは 1 回の改訂のみで作成されます。それ以降の改訂には変更管理プロセスが必要になります。アーカイブ用にさらに数部印刷し、最後に署名確認ページを追加します。これにより、要件ドキュメントを受け取ったすべてのユーザーが署名して確認する必要があり、最後にユーザーのプロジェクト マネージャーが署名する必要があります。署名され確認されたアーカイブは、将来の要件変更の基盤として使用できます。

相手側のプロジェクト マネージャーが署名するだけで十分ではないか、なぜコア ユーザー全員が署名しなければならないのか、という人もいます。リーダーは署名に非常に慎重だからです。署名が必要ない場合は、要件をパラパラとめくって、よく見ることなく引き出しに放り込んでしまうのです。しかし、3日後に一度に修正案を提案し、修正せずに承認に署名するのであれば話は別です。彼はそれを注意深く読み、真剣なアドバイスをします。なぜなら、注意深く読まないものに署名する人はほとんどいないからです。これは、厳密に定義されておらず、将来的に論争を引き起こす可能性のある内容を事前に確認するのにも役立ちます。したがって、このプロセスを通じて、コアユーザーの要件に対する理解を開発チームと同期させることができ、要件のベンチマークを真に形成することができます。

需要分析に関する私の経験については以上です。私のレベルは低く、長々と話しましたが、どれだけ役に立つ内容を話せたかわかりません。読者の皆様には訂正をお願いしたいです。最後に、実はもう一つアイデアがあります。需要分析はプロジェクト マネージャーの欠かせない仕事です。要件が非常に複雑でチームが必要な場合は、プロジェクト マネージャーもこのチームの中核メンバーでなければなりません。私もプロジェクト管理の経験があります。時間があるときに、読者を笑わせるためにそれについて何か書きたいと思います。読者の皆様、次に何が起こるか知りたい方は、次のエピソードをお楽しみに。

この記事の著者: Bole Online - Old Coder

この記事へのリンク: http://blog.jobbole.com/49332/

[転載する場合は、本文中に明記し、原文リンク、翻訳リンク、翻訳者などの情報を保持する必要があります。 ]

元のタイトル: 古いプログラマー: 需要分析の経験あり

キーワード: 需要、分析、コーダー