模擬ITプロジェクトを終えて。

みなさんこんにちは。
内田裕介です。

前回の投稿で「投稿頻度を増やす」とか言っておきながら、結局、月末の投稿となってしまいましたね。自分のキャパシティの狭さには課題を感じるばかりです。

今回は余裕を持って宣言しておきます。次回の投稿は、6月末とします。(笑)

まあそんなことはさておき、今回は研修で行われた模擬ITプロジェクトについてお話していこうと思います。

僕が所属する部署はプロジェクトマネジメントを支援しているので、基本的にはクライアント先に常駐する形となり、その案件の多くがITプロジェクトです。

つまり、ITプロジェクトの大まかな流れを体験し、プロジェクトとは何なのかを身をもって知ることが、この研修の目的です。

お題は「人材評価および人材ポートフォリオ作成ツールを作成せよ」というものでした。前提条件としては、期間は1週間強・ウォーターフォール型の採用などがありました。

1週間以上、ひたすら同じグループで仕事をしていくというのは初めてだったので、それだけで僕にとってはとても新鮮でしたね。結果を見ても、自分たちが納得のいくツールが作成できたし、担当講師たちを納得させることもできたので、良い出来だったのではないかと思います。

そんな中で、僕がとても学びになった出来事があったので、それについてお話していきますね。

フレームワークに囚われない。

先程、このプロジェクトの前提として「ウォーターフォール型の採用」があったと記述しました。

ウォーターフォール型というのは、以下のようなモデルのことです。

別名「V字型モデル」とも言います。僕の会社では、外部設計を基本設計、内部設計を詳細設計、コンポーネント間総合テストを単体テスト、などのように別の言葉を使っていますが、このように、各フェーズの名称はプロジェクトによって異なるみたいですね。

ここで注目してもらいたいのは、「設計（定義）→検証→テスト」という部分です。

これは何を意味しているのかというと、「コンポーネント間総合テストでは、内部設計を網羅しなさい」と言っているんですね。つまり、内部設計書で記述されている内容が全て実現されているかどうか、テストによって検証しなければならないのです。

サブシステム間総合テストや、システムテストでも同様です。

何故そんなことをわざわざ説明したかというと、僕がこの模擬プロジェクトにおいて、テスト責任者を務めたからです。テストケースはほとんど僕が作成してリスト化しました。

僕が大きな学びを得たのは、この後です。

作成したテストケース一覧表を、担当講師の方にレビューしていただいた時でした。まず言われた言葉は「このテストケースは何をインプットにしてるの？」というものでした。

初めはさっぱり意味が分からず「特にインプットはありません。自分で考えてツールの業務フローにおける懸念事項を挙げ、それらを検証できるようなテストケースを作成しました」と回答しました。

みなさんはもうお気付きだと思います。

先程記述した「設計（定義）→検証→テスト」を無視して、僕はテストケースを作成してしまっていたのです。さらに、テストは必ず3段階なければならないと思い込んでいたため、自分が考える粒度でテストケースを分類して無理やりに3段階に分けていました。

そういった僕の考え方の間違いに気づいた講師の方は「ウォーターフォールはあくまで考え方。基本設計書を単体テスト、要件定義書を総合テストとして検証したって良い」のだと教えてくださいました。

これを受けた時に、自分がウォーターフォールというフレームワークに固執してしまっていたことに気付きました。

僕は結果として、意味もなく3段階として考えていたテストを要件定義書の機能要件と非機能要件を網羅する2段階に修正し、無事にテスト責任者としての役目を果たすことが出来たのです。

フレームワークはとても参考になる考え方で、僕はそういう型にはまった考え方を勉強するのが好きですし、とても役に立つことも実感してきました。

しかし、それに固執することで、今回のように自分の思考を制限してしまうことがあるのだと身をもって実感しました。

僕の会社では間もなく研修が終わろうとしています。5/31、つまり次の月曜日で研修が終わりとなり、僕たち新入社員は晴れて現場へと旅立っていきます。

僕はまだどこの現場に配属されるかは分からない（それどころか未だに直属の上司と連絡すら出来ていない）のですが、現場に出ることが決まったら、この研修で学んだことを精一杯活かしていこうと思います。

引き続き、応援よろしくお願いいたします。