新人さんに捧げる、やさしく楽しく解説するソフトウェア開発のプロジェクト用語(前編)
春ですね。そういえば筆者が新人で配属されたプロジェクトの会議に初めて参加したときですが、聞きなれない業界用語が飛び交っていて面喰ったのを思い出します。今回は新人の皆さんが今後プロジェクトにスムーズに参加できるように、そんな初めての人は聞きなれないが、現場では当たり前のように使われているプロジェクト用語を独断と偏見でいくつか紹介したいと思います。
とあるプロジェクトのメール
#架空の内容ですが、プロジェクトの開始時に皆さんに次のようなメールが飛んできたとします。まずはこれを読んでみてください。
プロジェクトが開始されるのに伴いキックオフを行います。ついては皆さんの参加をお願いします。
開発のスコープは調整中でしたが昨日ステークホルダーと決定しました。
進捗は線表をもとに管理していきます。決定したスコープをもとにまずはスケジュールの作成からお願いします。システムのカットオーバーは来年の3月末です。
開発はフェーズごとに必須でレビューをお願いします。作業が遅れる場合はリスケも含め対策を検討の上、適宜報告をお願います。
今回はテストの不具合件数を適宜報告してもらいます。
メールの内容は開発経験が1年もあれば何をいっているのかはだいたい理解できるような内容ですが、皆さんはどうでしょうか？初めての方は聞きなれない用語が沢山で？？と思われたのではないでしょうか。
用語の解説
#ここからはそんな文中のソフトウェア業界独特と思われる用語をそれぞれ解説していきます。説明しやすい順に解説してくため、説明は文中の出現順とは異なります。
キックオフ
#プロジェクトが立ち上がった際に関係者全員を集め、その開発プロジェクトの目的や概要、大まかな計画等を説明し、プロジェクト全員の向かう方向を合わせることを目的に行われる会議を指して良く使われます。これは何かの書籍や規格で明確に定義されている用語ではないですが、一般的によく使われる業界用語です。
プロジェクトの立ち上がり時はキックオフ会議の他に関係者みんなが参加する懇親会という名の飲み会も良く行われます。ただ、筆者が新卒で配属された部署では、そのプロジェクトの立ち上がり時のみんなでやる飲み会のことをキックオフと呼び、最初に全員で集まる会議は別の名前で呼んでいました。
なので、キックオフとは飲み会のことだと信じて疑わなかったのですが、転職して初めて参画したプロジェクトで、なんとキックオフを昼間からやるというのを聞いて「結構カジュアルな会社だとは思っていたけど、昼間っからみんなで飲んじゃうんだー、スゲーなぁー」とカルチャーショックを受けていたら、開けてびっくりそれが世の中で一般的にいうキックオフ会議でした。
このように会社や組織が違えば、同じ用語でも違うものを指していたり、同じことを別の用語で使っていたりすることは往々にしてあるので注意しましょう。ちなみに筆者はその時、同僚に「昼間っから飲み行くっていってもどこでやるのかねぇ？」と聞いてポカーンとされたことをよく覚えています。
線表
#必要なそれぞれの作業に対して作業期間の線を引いた次のような表です。
システムやソフトウェア(アプリ)を作るには、いくつかの作業が必要となります。線表にはその必要な作業に対して「どんな」作業が、「いつからいつま」で掛かり、それを「誰が担当」して、その結果として「なにが出来上がるか」を主に記載します(例の図は「誰が」と「なにが出来上がるか」の記載は省略されています)。
線表は一般的にプロジェクト開始時に作成し、それをもとにそれぞれの作業の進み具合を把握します。ですので、線表はいつなにをやるかを分かりやすく表現した予定表といえます。
線表と同じような意味・目的でよく使われる用語として「ガントチャート」や「WBS」もありますが、（厳密には違いますが最初の頃は）WBSといったらスケジュール表や線表のことか！と思って問題ありません。
線表を作るにはある程度コツと経験が必要となるため、新人の人がいきなり線表を作らされることはありません。コツや経験が必要となるのは、余りにも余裕を持った作業スケジュールを作るとお客様や上司から「なんでそんなに掛かるのか」と詰められ、かといってタイトなカツカツのスケジュールを作ると、スケジュールを守るために毎日残業で自分の首が閉まるため、良い感じの線表を作るのには熟練の技[1]が必要となります。
ただ、プロジェクト初期のスケジュールはどこまで行っても「ここまでに出来たらいいな♪」という占いや願望といった要素を排除できません。このような不確実性に対する対処の1つとしてとして昨今ではアジャイル開発が広まってきたと筆者は理解しています。といってはみたものの、筆者はアジャイル開発について語れるほど知見やネタは持ち合わせてないので、このテーマは他に譲りたいと思います。
進捗
#作業の進み具合を「進捗」と呼びます。プロジェクトでは線表のところで説明したように作業の開始時にその作業の結果として「なにができるか」のゴールを定義します。進捗はそのゴールに対してどのくらい進んでいるかを説明したもので、多くは割合で表されます。
例えば、ある機能を設計する作業があり、その設計作業では成果として設計書を作ることになっており、その設計書のページ数を10ページと占って見積もっていたとします。これに対してある日の時点で3ページ出来上がっている場合、その作業に対する進捗率は30%となります。
と言われると「なんだ簡単なことだな」と思われるかも知れませんが、進捗を正しく測るのは実はとても難しいものです。例では完成ページ数を10ページと最初に見積もりましたが、作業を進めていくうちに予想していたより沢山の事柄が出てきてページ数が膨らんでいくことは良くあります。また、ある日の時点で9ページ出来ていたので進捗を90%としていたが、次の日に記述漏れに気が付きページ追加が必要だと分かりました。ではこの日の進捗は何パーセントでしょうか？
といったように進捗を正しく測るには、精度の高いゴールの定義とそれに対して今どこまで出てきているかを正しく計測する方法が必要となります。
「精度の高いゴールの定義」とは例えば、作業開始時に想定完成ページを正しく言い当てるのは非常に難しいですよね。また、今回はページ数を例にしたので分かりやすかったですが、作る対象がある機能だった場合、どうでしょうか？
先輩に「あの機能ってどのくらいの進捗？」と聞かれた場合、どのように答えますか？気分的に半分くらいできたので50%とかでしょうか？実は現場では感覚で進捗を判断していることは往々にしてあり、またそれで困らないケースも多いのは事実です。
なので、正確な進捗を報告しなければ！と肩肘を張る必要はありません[2]が、「進捗や計画、見積もりを正しく精度良く測るのは実は難しいことなんだな」ということは理解しておきましょう。
ちなみにこの対象を「精度よく見積もる」や「対象の出来を正しく計測する」はソフトウェア開発での長年のテーマで、ソフトウェアエンジニアリングの世界では色々な手法が考案、提案されています。ある程度経験を積んだら、この辺りを探求しもらうと面白いかもしれません。
リスケ
#正式名称はRe-Scheduleで予定を変更することを意味します。開発プロジェクトでこの用語は、主に当初予定していた作業の開始予定日や完了予定日を変更することを指します。開始予定日や終了予定日を前に持ってくる分には作業の前倒しになるため、上司やお客さまから文句を言われることはありませんが、後ろにズラすことはシステムの完成が当初予定より遅れることに繋がりかねないため、それなりな理由がないとなかなか認めれないことが多いです(当たり前ですが)。
なお、予定が遅れている場合、その代表的な解消策は次の3つです。
- 予定していた完了日を伸ばす。つまり後ろ倒しにリスケする
- 当初予定していた作業を減らす
- 残業して気合で頑張る
余談ですが、筆者が若いころ(1990年代後半～2000年代初頭)は、1.と2.が認められることはホボなく、選択肢として実質採り得るのは3.の残業で頑張るだけでした。しかし、近年は働き方改革などもあり？遅れは受容し1.と2.が認められるような雰囲気になってきた感じはあります。
カットオーバー（日）
#作っているシステムをお披露目する日、つまりシステムを利用開始する日です。これは利用者視点で言ってますが、開発者視点でいうとその日までに絶対にシステムを作り上げないといけない日、つまり締め切り日となります。
この用語は業界内でも色々な類語があり、「リリース」、「ローンチ」、「サービス開始」などもカットオーバーと同じ意味でよく使われます。ちなみに筆者が新卒で配属された部署ではカットオーバーのことを「丸S（マルエス）」や単に「S（エス）」と言っていました。これは線表にカットオーバーの日をStartのSを丸で囲んで書いたことから来ていると上司から聞いたことがあります。
つづきは後編へ
#とこんな感じで説明していたらまだ半分の5個しか説明していないのにかなり長くなってしましました。今回はここまでにして、続きは 後編 にしたいと思います。
