前回 は用語を半分解説したところで終わったので、今回はその後編として続きを説明していきます。

まずは前回のとあるプロジェクトのメールを再掲します。

プロジェクトが開始されるのに伴いキックオフを行います。ついては皆さんの参加をお願いします。
開発のスコープは調整中でしたが昨日ステークホルダーと決定しました。
進捗は線表をもとに管理していきます。決定したスコープをもとにまずはスケジュールの作成からお願いします。システムのカットオーバーは来年の3月末です。
開発はフェーズごとに必須でレビューをお願いします。作業が遅れる場合はリスケも含め対策を検討の上、適宜報告をお願います。
今回はテストの不具合件数を適宜報告してもらいます。

前回はこのメールの「キックオフ」、「線表」、「進捗」、「リスケ」、「カットオーバー」を説明しました。今回は説明していない残りの用語を説明していきます。前回をまだ見ていない、見たけど忘れてしまった方は前編からどうぞ。

前回同様、文中のソフトウェア業界独特と思われる用語をそれぞれ解説していきます。解説していく順序は文中の出現順と異なる点は前回と同様となります。

システム開発でスコープはいくつかの意味で使われますが、この文脈における「スコープ」は開発範囲の意味となります^[1]。

システムやソフトウェア（アプリ）の開発では、今作ろうとしているシステムやアプリに含める機能の範囲を決めます。

例えばECサイトを作ることが決まったので必要な機能を考えたところ、会員機能、商品管理機能、商品閲覧機能、注文機能、レコメンド機能、ポイント管理機能の6個の機能が挙がったとします。

しかし、ECサイトは半年後にカットオーバーする必要があり、また開発に必要な予算も限られているため、6個の機能すべてを作った場合、カットオーバーの期限には間に合わず、予算も足りないことは明らかでした。

そのような場合、皆さんならどうしますか？期限を延ばしてもらいますか？それともどこかに頼み込んで予算を増やしてもらいますか？

この2つの作戦もなくはないですが、多くの場合、開発期間と開発予算は変えることができない制約となっています。よって、プロジェクトはこの制約の範囲内で進めていく必要がありますが、この場合に採られる王道的な作戦は「作るものを減らす」ことです。

今回の例でいえば、ネットでモノを売るためには会員機能、商品管理機能、商品閲覧機能、注文機能の4つは最低限必要となりますが、レコメンド機能とポイント管理機能はなくてもとりあえずなんとかなる気がします。なので、期間と予算を範囲内に収めるためにレコメンド機能とポイント管理機能の2つの開発は見送り、今回は会員機能、商品管理機能、商品閲覧機能、注文機能の4つを対象として開発を進めていきましょうといった調整と決定はソフトウェア開発ではごく一般的に行われます。

そして、この開発プロジェクトで決定された開発対象範囲を「スコープ」といいます。

開発スコープはプロジェクトに参加する関係者間でキチンと認識を合わせておくことが非常に重要です。これから開発に携わる新人の方はホントにそんなことがあるのかと思われるかもしれませんが、プロジェクトで決定された開発スコープの理解が正しく行き渡っていなかったために、プロジェクトの最後の方になって必要な機能が作られていないことが判明するといったことは笑い話ではなくよくあったりします。

また、このようなプロジェクト全体の方向性を合わせる目的でも前回紹介したキックオフが必要となります。

スコープに続いてはステークホルダーです。私はこの用語を20年前くらいに初めて聞いたのですが、それを聞いた最初のイメージはまさに次のようなものでした。

ステーキ？をホルダー？な感じで聞いたときはまったくなんのことか想像すらできなかったのですが、「ステークホルダー」の意味は辞書を引いて出てくる直訳のとおりソフトウェア開発でも「利害関係者」となります。

メール中のステークホルダーが登場する文章を見ると

開発のスコープは調整中でしたが昨日ステークホルダーと決定しました

となっています。この文章だけをみるとステークホルダーといってるけど、それって「お客様」だろ、なに恰好つけて横文字を使ってるんだと思われる方もいるかもしれません。当時は私もその一人でした。

しかし、ステークホルダーにはもっと深く重要な意味があります。良いシステムを作るには、そのシステムに関係するすべての人たちの期待を満たす必要があります。

開発費を出してくれる直接のお客様は確かに重要な利害関係者の1つではありますが、作ったシステムを運用するのは多くの場合、お客様や開発者とは別の組織となります。その場合、作られたシステムを日々運用してく組織や人たちには、その人たちなりに例えば「今回作るシステムでは障害が発生したらSlackと連携して通知がくるようにして迅速に対応できるようにしたい」といった自分たちがシステムを運用しやすくするための期待や要望があったりします。

では、このような期待や要望はお金を直接的に出してくれるお客様や開発者だけで考えて出てくるでしょうか？たまたま出てくるかもしれませんが、それがすべてで正しいかはそれ自身を主体的に行う人や組織じゃないと分からないですよね。

ということで、開発プロジェクトにおける利害関係者は決してお客様だけではなく、開発するシステムに対して何らかの期待や要望といった関心をもっているすべての人を含みます。どのような組織や人がどのような関心を持っているかといったプロジェクトにまつわるステークホルダーを正しく認識することはプロジェクトを運営していく上で非常に重要となります。

開発プロジェクトのある意味ゴールである開発スコープが決まったからといって、みんなで「いっせーのーせ」で作り始めても上手くいかないですよね。ある人はいきなりプログラムを書き出したり、ある人は機能の入力と出力はどうあるべきかといった機能の詳細を考え出したりといったように、個々人がバラバラなことをしていったら全体を把握することができなくなり、結果無駄な作業も発生します。

そもそも論として会員機能を作ろうとしてもいきなりプログラムを書き始めることはできないですよね？例えば会員情報として管理する項目としてはどのようなものが必要か？そしてそれはどこに保存するか？や入力してもらった会員情報はどのような流れで処理を行っていくか？というように、対象を段階的に詳細化していく必要があります。

このようなことから、ソフトウェア開発プロジェクトではプロジェクトを進行する上で異なる段階や期間をいくつかに分けて開発を進めていき、その区切られた各段階や期間を「フェーズ」と呼びます。

一般的にプロジェクトは複数のフェーズに分けられ、各フェーズは特定の目標を持ちます。これにより、プロジェクト全体が今どのくらい進んでいるかが把握しやすくなり、進捗の確認やモノがキチンと出来ているかの品質の確保が行えるようになります。

典型的なソフトウェア開発プロジェクトのフェーズとしては「要件定義フェーズ」や「設計フェーズ」、「実装フェーズ」、「テストフェーズ」、「保守フェーズ」などといったものがありますが、これらを説明すると記事があと2,3本は必要となるため、ここでは用語の紹介に留めます。

レビューは今まで学生だった方にはなじみがない言葉だと思います。同じなじみがない言葉でもステークホルダーは違うものですが頭に浮かぶものがありましたが、初めてレビューという用語を聞いたときは私も正直何も浮かびませんでした。

そんなレビューですが、私は「中間チェック」という意味でとらえています。先ほどの「フェーズ」で説明したように開発プロジェクトにはそれぞれの目標ごとに分けられたいくつかのフェーズがあります。フェーズには定められた目標がありますが、その目標に達しているかを確認せずに次のフェーズに進んで行った場合どうなるでしょうか？気が付いたときには問題が大きくなっているのは想像に難くないですよね。

こうならないためにも開発プロジェクトでは要所要所でプロジェクトで作成したドキュメントやプログラムコードなどといった成果物が目標に照らし合わせて正しいかの評価を行います。そしてこの成果物を評価する行為を「レビュー」といいます。

例えば、要件定義フェーズでは、成果物としてシステムで何を作るかを明らかにする機能一覧を作ったりしますが、その機能一覧に含まれる機能がプロジェクトの目的に対して充足しているかを要件定義フェーズの後半でレビューします。

ただし、充足しているかを自分で評価することは難しいです。このため、レビューではレビュー対象となっている成果物に対して関心があるステークホルダーやその成果物に対し深い知識を持っている有識者などを交えて行われるのが一般的です。

最後の用語はテストです。私がこの用語を初めて聞いたときは「社会人になってもテストがあるのかー、いやだなー、どんな問題が出るんだろう？」と本気で学生の学期末テスト的なものを思い浮かべましたが、全く違いますので安心してください。

ソフトウェア開発における「テスト」とは、作ったソフトウェアが期待どおりに機能するか、または特定の目的を満たしているかを確認する作業で、平たくいうとできたものを動かして確認すること^[2]です。テストといわれると構えてしまいますが、このようにいわれるとなんだそういうことかと普通に思っていただけるのではないかと思います。

2回に分けて行ってきたプロジェクト用語の解説は以上となります。実際に使われているソフトウェア開発に独特なプロジェクト用語はこれ以外にももっとたくさんありますが、この記事が理解の入り口となったら幸いです。