見出し画像

【PM入門:計画編】開発工程を定義する

PM入門note、初回は『開発工程の定義』をテーマにしたいと思います。開発工程というのは、要件定義とか総合テストとかシステム開発を進めていくときの各工程のことですね、これを定義するための考え方を説明していきます。

「なんでPM入門の初回が開発工程定義なの?」

もしかしたらピンとこない方も多いかもしれません。見積りとかプロジェクト計画とか品質評価とか他にも多数テーマがある中での開発工程定義ですからね。僕もかなり悩みました。ただ、「どこから説明するのがPM入門者にとってわかりやすいか」と考えてみたところ、やはり開発工程定義についてまずは理解してもらうのがよいだろうという結論に達したわけです。見積もプロジェクト計画作成も品質評価も、開発工程が定義されていないと実施できません。まずは開発工程を定義するとはどういうことなのか、PM自ら開発工程を定義するには何を基準にすればよいのか、を理解してもらえればと思います。


プロジェクトを無駄なく効率的に進めるには?

料理でも折り紙でもなんでもそうなのですが、作業には順番があります。順番を間違えると、手戻りが発生したり最初からやり直したり時間と労力が余分にかかりますよね。自分一人で趣味の世界でやっているなら、手戻りも失敗もよい思い出になるかもしれませんが、仕事として顧客やチームメンバーと一緒に進めていくプロジェクトではそうはいきません。可能な限り無駄なく効率的に作業を進める必要があります。

では、プロジェクトの作業を無駄なく効率的に進めていくにはどうしたらよいでしょうか。ベタですが一番確実なのは、プロジェクトで必要なすべての作業を洗い出して、それを手戻りが発生しない順番に並べて、並べた順番に作業を1つずつ実施していく、というものでしょう。すべての作業が完了したらプロジェクト終了。非常に簡単だしなんだかうまくいきそうですよね。

ですが、現実的にこのやり方は採用できません。PMBOKにも「プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」と定義されているように、プロジェクトには独自性があり同じものが1つとしてありません。そのため、いくら過去のプロジェクトを参考にしても、どれだけ経験豊富なPMだとしても、プロジェクト開始時に「すべての作業を洗い出す」ということができないのです。

ではどうするのか。

そう、ここで登場するのが開発工程という考え方です。


プロジェクトを手戻りなく進めるために開発工程を定義する

例えば、プロジェクト完了までに必要な作業がだいたい100個あるとします。正確には105個かもしれないし90個かもしれません。プロジェクト開始時点では正確な数がわからないのです。この状態で手戻りがないように作業の順番を決めるのは非常に難しいですよね。しかし、これらの作業をグループ化してみたらどうでしょうか。最初はざっくりと設計グループ、プログラミンググループ、テストグループの3つのグループにわけてみます。すると、この3つは①設計、②プログラミング、③テスト、の順番で実施すれば手戻りなくプロジェクトを進められそうだなということがわかります。これが開発工程定義のベースとなる考え方です。

ここをスタート地点として、「設計グループの作業は要件確認とシステム設計にわけられそうだな」とか「テストはクラス単位のテストをしてから機能単位のテストをしたほうが効率的だな」とかでグループを細分化していくと、皆さんのプロジェクトでも使用している開発工程の定義ができあがります。


開発工程の定義はプロジェクトごとに異なる

開発工程の定義はプロジェクトごとに異なります。これは当たり前のことなのですが非常に大事なことなのでもう一度言います。開発工程の定義はプロジェクトごとに異なります!

繰り返しになりますが、プロジェクトのすべての作業をグループ化して、それらのグループに名前をつけたものが開発工程です。プロジェクトは独自性を持ち同じプロジェクトは1つもないのですから、プロジェクトを完了させるために必要な作業はプロジェクトごとに異なります。また、プロジェクトごとに環境や条件が異なり、「次の工程からオフショアにだしたいけどテーブル設計はオフショアに任せられないから前の工程までにやっておきたい」といったプロジェクト固有の事情などを反映していくと、当然ながら開発工程定義はプロジェクトごとに異なるものになっていきます。

Coffee Break
このように開発工程の定義はプロジェクトごとに異なるのが当然なのですが、工程定義の認識相違が原因で揉めるなんてのはPM的にはあるあるネタです。顧客やパートナーと開発工程別に契約した時に、「普通はこの工程でここまでやるもんでしょ」「いやいや普通は次の工程でやるものですよ」みたいな言い合いになり、最終的には立場の弱い方が押し込まれて追加作業をするはめに。。。開発工程定義に「普通は」といったものはないので、後々揉めないようにPMさんは開発工程に含まれる作業とアウトプットをしっかりと定義して、関係者に説明しておきましょう。


開発工程を定義するのはPMの仕事

プロジェクトをどのような開発工程にわけるのか、各工程でどんな作業を行い何をアウトプットするのか、これらを定義するのはPMの仕事です。見積もプロジェクト計画作成も、開発工程が決まってからじゃないと整理できませんので、まずは開発工程を定義しましょう。

「でも開発工程の定義ってどうやってやればいいの?」

これについては、残念ながら唯一絶対の正解はありません。システム開発プロジェクトは建築系プロジェクトに比べると開発プロセスが成熟しておらず、だからこそバグも混入するし手戻りもするし、予定通りいかなくて炎上したりもします。開発工程の定義も、それぞれの会社、それぞれの現場で試行錯誤を繰り返しながら、日々改善が進められているのです。

とはいえ、ここで終わってはPMを目指す人のお役に立てません。ですので自己流ではありますが、僕自身が過去のPM経験も踏まえて現時点でベストだと考えているやり方について紹介したいと思います。


開発工程を定義する

『開発工程を定義する』をより具体的にイメージできるよう分解すると、
 ・どの工程で
 ・どんな作業を実施し
 ・どんな成果物を作成するか
を決めるということになります。一覧表にするとしたら、工程名、工程の説明、実施する作業、主な成果物、がその一覧表の項目として並ぶイメージですね。この一覧表をすべて埋めたら、開発工程の定義は完了です。

とはいえ、ゼロからこの一覧表を埋めていくのは大変です。時間と労力をかけてすべて埋めたとしても、知識不足や考慮不足から、作業や成果物に漏れがでてしまうかもしれません。開発工程定義は見積やプロジェクト計画のインプット情報となりますので、ここで漏れがでるのは何としても避けたいです。ではどうするか。自分の知識不足を補い作業の漏れをなくすために、自社の標準パターンや過去プロジェクトの開発工程定義を活用しましょう。PMBOKにも「組織のプロセス資産(教訓や過去の情報)を活用しよう」と書いてありますし、プロセス資産の活用はPMとして推奨されるやり方です。

ちなみに僕が開発工程を定義する場合、優先順位の高い順に以下の手法をとります。
【手法1】同一システムの過去の類似プロジェクトを参考に微調整
【手法2】類似システムの過去の類似プロジェクトを参考に微調整
【手法3】プロジェクトの特徴を踏まえて自分で一から定義

既存システムの機能追加プロジェクトの場合は【手法1】、新規システム構築プロジェクトの場合は【手法2】で、【手法3】を使うことはほとんどありません。【手法3】は非常に新規性の高いプロジェクトの場合や、顧客側PMOとして新規プロジェクトの開発工程を定義しないといけない場合などに使う程度です。ですが【手法3】の知識とスキルが身についていると、【手法1】【手法2】でいうところの「類似プロジェクトを参考に微調整」にPMとしての考えや方針をうまく反映できるようになり、ものすごく地に足のついて開発工程定義に仕上げることができます。皆さんもイメージアップできるように、ここでは「微調整」の例をいくつか紹介しておきます。

◆要件定義後の見積り金額が顧客プロジェクト予算の上限になるため、精度の高い見積をしてほしいと顧客から依頼があった。そのため、過去プロジェクトでは外部設計工程で実施していた画面遷移図と画面レイアウトの作成を要件定義工程で実施することにした。

◆過去プロジェクトでは、外部設計まで国内パートナー、内部設計からオフショアパートナーという役割分担で実施していたが、今回プロジェクトではオフショアパートナーを別会社に変更することにした。処理のシーケンス図は内部設計の成果物としていたが、品質担保のために今回プロジェクトでは外部設計後半で国内パートナーに実施してもらうことにした。

◆世間を騒がすシステム障害を起こしてしまったため、顧客内の品質基準が厳しくなり、総合テストの障害密度を過去プロジェクトの半分以下にすることが今回プロジェクトの要件となった。これまで総合テストで実施していた業務シナリオケースのうち基本シナリオ分を連結テストの最後に実施することにした。

いずれの手法を使用するにしても大事なのは、PM自らが「このプロジェクトはこんな特徴があるからこんな進め方をする、だとすると開発工程定義はこうするのがベストだ」と言えるような開発工程を定義することです。このような考えを持って開発工程を定義し、見積をして、プロジェクト計画を作成することで、PMの考えが反映されプロジェクトの特徴も捉えた実行力のあるプロジェクト計画を作成することができるのです。


過去の類似プロジェクトを参考にする理由

「プロジェクトに同じものは1つもないんです!」「開発工程の定義はプロジェクトごとに異なります!」と散々言ってきたのに、過去の類似プロジェクトを参考にするということに違和感を感じる方もいるかもしれません。この点について少し補足します。

例えば見積りをするときに「50画面の業務システムを新規作成する場合の開発工数は、1画面あたり0.5人月として25人月だな」などと見積ります。品質評価をするときも「1,000stepあたりの障害数が0.5件以内だから、品質は大丈夫そうだな」などと評価したりします。この時に登場する「1画面あたり0.5人月」とか「1,000stepあたり0.5件」という数値のことを標準値とか目標値という言い方をするわけですが、これらの数値はたいてい、過去プロジェクトの実績値だったり、成功したプロジェクトで使用していた目標値だったりします。過去実績のある数値なので、見積りをするにも品質評価をするにも一定の安心感があり、人に説明するときも説得力がありますよね。

では、これらの数値。適用条件について考えたことはあるでしょうか。

当然どんなプロジェクトでも同じようにこれらの数値を使えるわけではありません。いざ自分のプロジェクトで見積りや品質評価をする時に、これらの数値がそのまま使えるのかどうか、PM自らがよく考える必要があります。しかし、過去実績があり他のプロジェクトでも同じように使用しているという理由で、そのまま適用してしまっているPMさんが実は意外と多いのです。それがダメな理由は、プロジェクトを擬人化して考えるとよくわかります。

例えばAさん。SE歴20年のベテランで、過去の経験から自分の仕事の進め方をかなり効率化しています。このAさんが1画面0.5人月で開発できるとします。それに対してBさん。SE歴5年で優秀ではあるものの、まだまだ仕事の進め方は粗削り。そのBさんが20画面の開発をするとき、Aさんが1画面0.5人月で開発できる実績があるからといって、0.5人月×20画面で10人月と見積をするでしょうか。やりませんよね。

では、このAさんとBさんを、プロジェクトAとプロジェクトBに置き換えて考えてみましょう。開発プロセスが最適化されて熟練メンバーを集めたプロジェクトAと、開発プロセスを新たに定義してメンバーも新たに集めたプロジェクトB、あなたはプロジェクトBのPMです。見積りや品質評価をする際に、プロジェクトAの実績値をそのまま使用しますか?このように説明すると、ほとんどの人はNoと答えるのですが、実際にプロジェクトの見積りや品質評価の説明を聞いていると、過去実績であるプロジェクトAの実績値を使用して見積りしたり品質評価をしているケースが少なくありません。

これらの数値、適用可否のポイントはプロジェクトの類似性です。「同じ実力のチームが、同じ難易度のシステムを、同じ開発プロセスで実行した場合、生産性や品質も同程度になるだろう」という発想ですね。なので、実力が違う、システムの難易度が違う、開発プロセスが違う、など異なる要素があれば、当然これらの数値はそのまま使用することはできません。異なる要素を把握したうえで、数値を適切に微調整して使用するのが望ましいと思います。

話を開発工程定義に戻します。

過去実績から算出された標準値や目標値というものは組織のプロセス資産であり、極力活用してあげることがプロジェクト成功の近道となります。では開発工程定義はどうするべきかですが、プロジェクト固有の事情がない限り、できる限り過去プロジェクトに合わせてあげるのが望ましいと僕は考えています。過去プロジェクトと合わせることで、プロセス資産である各種標準値を活用することができますし、プロジェクトメンバーにもなじみやすいケースが多いためです。


各工程で何をどこまでやるかの基準を持つ

「要件定義ってどこまでやれば終わりですか?」

皆さんはこんな質問をされたことはないでしょうか。開発工程はプロジェクトごとにPMが定義するものではありますが、顧客から、メンバーからこの質問をされたときに、明確に回答することができそうでしょうか。

この質問に回答するためには、開発工程定義について自分なりの基準を持っている必要があります。基準に従い開発工程を定義するとこう、今回プロジェクトについてはこんな特徴があるので基準から外れるけど特別にこう、そんな説明ができるようになるために、各工程で何をどこまでやるかという自分なりの基準を持ちましょう。

基準の決め方ですが、これも正解はありません。最初は社内標準そのままでもよいですし、他のPMさんのマネでもよいと思います。最初は社内標準のままでよいと思っていても、プロジェクトがうまくいかず、次のプロジェクトでは見直すこともあるかもしれません。自分の中でスッキリ腹落ちする基準が見つかれば、開発工程について何を質問されてもPMとして自分の考えを説明できるようになります。以下に基準を決めるためのポイントを列挙しますので、こちらも参考にしながら自分なりの基準を考えてみてください。

◆工程の切れ目が明確でわかりやすい
・工程を分けるルールがシンプル
・各工程で何をどこまでやるべきなのか容易に理解できる
・各成果物をどの工程で作成するのかメンバーもわかりやすい
・各工程で注力すべきタスクを認識できる
・顧客も理解しやすい

◆プロジェクトを進めやすい
・各工程を順番に実施できる
・タスクの先行関係が守られている
・役割分担がかわる切れ目と工程の切れ目が同じ
  最終レビューが顧客 → 最終レビューが社員
  実行主体が社員 → 実行主体がパートナー
・契約の切れ目と工程の切れ目が同じ


工程基準の具体例

開発工程定義の基準についても具体例があったほうが理解しやすいと思いますので、最後に僕がよく使う基準の説明をしたいと思います。スッキリ腹落ちしたらそのまま使ってもらってもよいですし、自分や会社の慣れ親しんだ定義に合わせてカスタマイズしてもらってもOKです。


◆基本の考え方「境界仕様を定義する」
基本的な考え方は、『各工程で対象とする範囲を境界線で囲み、その境界に対して、何をインプットするのか、何をアウトプットするのかといった境界仕様を定義する』というものです。具体的に各工程ごとに説明します。


◆要件定義
要件定義での設計対象は「対象システム」全体です。対象システムと外部(ユーザや他システム)との境界仕様を決めるためのタスクが、本工程で実施すべきタスクになります。

【工程の定義】
・対象システムと外部(ユーザや他システム)との境界を定義する。
・対象業務を実現するために、ユーザがマニュアル作業で実施すること、他システムで実現する機能、対象システムで実現する機能を決める
・ユーザと対象システムとの境界仕様として、対象システムへのインプット/アウトプット項目を定義する
・他システムと対象システムの境界仕様として、インターフェース項目やインターフェース方式を定義する
・対象システム内で永続化して保持するデータを定義する

【主なドキュメント】
・業務フロー(対象システム/他システム/ユーザの機能分担、インターフェースする情報、対象システムに保持するデータを整理して記載)
・機能一覧(業務フローに記載された機能の一覧)
・インターフェース一覧(他システムとのインターフェース一覧)
・永続化データ一覧(対象システム内に保持するデータの一覧。テーブル設計のインプット)

【次工程準備として実施すべきこと】
・システム方式設計(インフラおよびアプリケーション・アーキテクチャなどシステムの構成・方式を決める)
・プロジェクトコスト見積のために必要な情報の整理(テスト計画、移行計画、全体スケジュール等)


◆外部設計
外部設計での設計対象は、1つ1つの「機能」です。各機能と外部との境界仕様を決めるためのタスクが、本工程で実施すべきタスクになります。

【工程の定義】
・各機能と外部(画面/ファイル/データ)との境界を定義する。
・対象機能が、何をインプットにして、どんな業務処理を行い、何をアウトプットするのかを定義する。
・インプット/アウトプットとなる画面/ファイル/データについては、項目名/桁数/属性/チェック仕様等まで決定する

【主なドキュメント】
・画面遷移図、画面一覧、画面仕様書
・インターフェースファイル一覧、ファイル仕様書
・テーブル一覧、テーブル仕様書
・バッチ処理一覧、バッチ処理仕様書

【次工程準備として実施すべきこと】
・開発ガイドラインの作成


◆内部設計
内部設計での設計対象は、1つ1つの「プログラム」です。各プログラムとその他プログラムとの境界仕様を決めるためのタスクが、本工程で実施すべきタスクになります。

【工程の定義】
・各プログラムと外部(その他ブログラム/ファイル/テーブル)との境界を定義する。
・性能/保守性/拡張性などを考慮しながら、機能を実現するためのプログラム分割を行い、プログラム間のインターフェース仕様を決定する。

例えば複数テーブルから取得したデータを画面表示する場合でも、SQL1本でレコード結合&ソートまでするのか、各テーブルから複数レコードを取得してきてプログラム内で結合&ソートするのか、機能要件はどちらの方法でも実現できます。データ量や要求される応答性能など非機能要件によって、どのようなプログラム分割を行い機能を実現するのかを決定することになります。

【主なドキュメント】
・クラス図
・シーケンス図
・ジョブフロー図

【次工程準備として実施すべきこと】
・特になし


◆ プログラム設計
プログラム設計での設計対象は、各「プログラム」の内部処理です。前工程で各プログラムの境界仕様を定義しているため、プログラム設計だけは設計対象が境界仕様ではなく内部処理となります。

【工程の定義】
・プログラムの内部処理を定義する。
・インプットデータを、どのようなに処理してアウトプットするのかを定義する。
・プロジェクトによっては省略されることもある。プロジェクト規模や体制により本工程要否はPMが判断する。

【主なドキュメント】
・プログラム仕様書

【次工程準備として実施すべきこと】
・特になし


◆コーディング
【工程の定義】
・プログラムのコーディングを行う。

【主なドキュメント】
・プログラムコード


◆単体テスト
単体テストでのテスト対象は、1つ1つの「プログラム」です。各プログラムに対してインプットとなるテストデータを投入し、アウトプットが仕様通りの結果となるかの確認をします。

【工程の定義】
・各プログラムへのインプットに対して、仕様通りのアウトプットになることを確認する
・テストケースはプログラム設計書をインプットに作成される。

【主なドキュメント】
・単体テスト仕様書
・テストコード
・単体テスト結果書


◆連結テスト
連結テストでのテスト対象は、1つ1つの「機能」です。各機能に対してインプットとなるテストデータを投入し、アウトプットが仕様通りの結果となるかの確認をします。

【工程の定義】
・各機能へのインプットに対して、仕様通りのアウトプットになることを確認する。単体テスト済みの各プログラムを連結して、機能単位で仕様を充足することを確認する。
・テストケースは外部設計書/内部設計書をインプットに作成される。
・プロジェクトによっては、機能間連結テスト(機能Aのあとに機能Bを動かして機能確認)を本工程に含める場合もある。

【主なドキュメント】
・連結テスト仕様書
・連結テスト結果書


◆総合テスト
総合テストでのテスト対象は、「対象システム」全体です。対象システムに対してインプットとなるテストデータを投入し、アウトプットが仕様通りの結果となるかの確認をします。

【工程の定義】
・対象システムへのインプットに対して、仕様通りのアウトプットになることを確認する。
・テストケースは要件定義書/外部設計書をインプットに作成される。
・プロジェクトによっては、システム観点と業務観点で2つのフェーズにわけることもある
・機能要件だけでなく非機能要件を確認するための性能テスト、運用テスト、障害テスト、等も本工程で実施する。

【主なドキュメント】
・総合テスト仕様書
・総合テスト結果書


◆ユーザ受入テスト
総合テストまで完了したら対象システムを納品します。納品されたシステムが要求通りの機能、品質、使い勝手になっているかどうかをユーザが確認します。

【工程の定義】
・システム発注者による対象システムの確認テスト。要件通りにシステムが完成していることが確認できると受け入れOKとなる。
・要件通りにできているかの確認以外に、機能やインターフェースのユーザビリティを確認する観点を含める場合もある。

要件通りにできていても利用してみたら使いにくい、機能が足りない、などの要件不備が発見されることがあり、修正対応方針を事前に定めておかないと揉める原因となるので注意しましょう。

【主なドキュメント】
・ユーザ受入テスト仕様書(システム発注者にて作成)
・ユーザ受入テスト結果書(システム発注者にて作成)


開発工程定義はプロジェクト計画作成の第一歩


これで開発工程定義についての説明はおしまいです。今回説明したものは、僕がよく使う開発工程定義の基本的な考え方ですが、これが唯一の正解でもないしどのプロジェクトにも適応できるものでもありません。僕がPMをやるときも毎回同じように開発工程定義をするわけではなく、プロジェクトの特徴を見ながらうまく進めるための作戦を考え、それに合わせて開発工程定義も変えています。この「プロジェクトに合わせて変えることができる」というスキルがPMには非常に大事ですので、皆さんも自分のプロジェクトに合わせて開発工程を定義してみてください。

開発工程定義ができたら、次は要件定義をして、見積もりをして、スケジュールを決めて、その他もろもろをまとめてプロジェクト計画を作成していきます。それらの説明はまた別の記事で。


参考文献

通勤大学 図解PMコース1 プロジェクトマネジメント 理論編

PMの哲学

この記事が気に入ったらサポートをしてみませんか?