グロービス Advent Calendar 2017 の16日目です。
はじめに
グロービスでは、gaimeriというチームで自然言語処理を活用した研究開発や実証実験向けのプロトタイプ開発を実施しています。
昨今、テクノベートという言葉が出てきていますが、
これまでITからは遠かった業界にも、ソフトウェアサービスやアプリケーションを作る機会が増えてきています。
オークション、EC、ゲーム、など、ITだけで完結していたテックの侵食が
教育業界にも本格的にやってきて、業界勢力図が一変しつつある時代にあります。
私は、グロービスでは、自然言語処理を活用したサービスの研究開発に従事していますが、
研究だけでなく、自然言語処理搭載のサービスを実証実験するため、ユーザに使ってもらうためのプロトタイプを作っています。
また、グロービスでは、
ビジネスの現場でもITサービスをどんどんリリースして、
顧客満足度を高めていきたいという機動性ある意思決定がなされており、
ビジネスサイドとエンジニアが共創する機会であふれています。
本稿の趣旨と想定する読者
本投稿では、非エンジニアのビジネスサイドのマネジャーに向けて、
エンジニアとうまく共創するためのオーソドックスなプロジェクトマネジメント方法「V字開発モデル」について書きます。
＊自然言語処理関連の投稿でも良かったのですが、ビジネスマネジャーとエンジニアの共創は重要ですので。
＊ソフトウェア工学に定義に厳密に則ることは本稿の目的ではないので、実務で使える形にデフォルメして書いています。
ウォーターフォール
v字開発モデルはウォーターフォール型開発の一種です。
ウォーターフォール型か。と言われると「古い」と想起しがちですが、
要件定義や仕様が明確になっている場合は、効果的なのではないかと考えています。
また、ビジネスマネジャーとエンジニアの仕事が分業しやすいので、
エンジニアにとっても、朝令暮改的な機能追加や仕様変更にさらされることが減ります。
V字開発モデルはウォーターフォールで何が異なるかと言うと、
私は、テスト設計にあると考えています。
まずウォーターフォール型の図を見てみましょう。
要件定義からテストまで、上流から下流へと流れています。
名前の通り、前の工程完了がなされたら、原則として上には戻さないという思想です。
（仕様が確実に決まっていないと、ウォーターフォールは向かないという所以はここにあります。）
v字モデル
さて本題のv字モデルの図をみてみましょう。
ウォーターフォールとの違いは、
基本設計時に総合テスト項目を、詳細設計時に、単体テスト項目を作成する点にあります。
より具体的な実装に進む前に、事前にテストすべき項目まで明確に定めています。
テスト項目を事前に作成することで、あってはならない手戻りのリスクを減らしています。
以下では、各工程について説明をします。
要件定義
ビジネスの現場で、新サービスを提供したい状況があるときを考えます。
例えば、自由記述の短答式のテキスト入力を受けて、自動フィードバックを返すe-learningのシステムを考えてみます。
ユーザは誰で、ユーザに何をさせたいのか。を丁寧に定義していきます。
私が実施する際には、ユースケース図などでまとめています。
たたソフトウェア工学に従って厳密にやろうとすると大変なので、
ビジネスマネジャーとしては、下記のようなレベルで書いておけば、エンジニアには伝わると考えています。
（手法オタクになって厳密に作法を守ることは、目的ではありません。）
基本設計
この工程においては、ユースケースをシステムで実現するための検討をします。
どの部分をITに任せて、どの部分を人が実施するのかという、ハイテクとハイタッチの切り分けも検討します。
私が実施する際には、シーケンス図と表示操作仕様を作成しています。
アウトプットとしては、総合テスト項目を作成します。
表示操作仕様に沿って動作するかどうかからテスト項目を作成します。
（異常系の操作も盛り込んでおきます。）
テスト項目の作成は、ビジネスマネジャーでも十分にできます。
エンジニアの目線で、異常系などのテストも網羅的に実施をする形が良いと思います。
詳細設計
シーケンス図や表示操作仕様に基づいて、実体関連図などを起こします。
また関数やクラス単位での設計書やテスト項目を作ります。
（あまり細かくなりすぎると、スピードが落ちるので注意です）
00年代の初頭は、クラス図を用意していたりもしましたが、
ただし、最近のトレンドとしては、フロントエンド、バックエンド、
自然言語処理エンジンなど分業して開発するマイクロアーキテクチャ思想などが存在するので、
クラス図ではなく、各機能ごとにAPI仕様を定めて、各サービスごとにさらに詳細設計をする場合が多いです。
実装
上記で得られた設計書に忠実にプログラミングをします。
つまり設計書が間違っていたらそのままプログラミングをされてしまうので、
設計書が確実に正しい状態であることが、重要です。
設計書は、プロジェクトにおける法であるとも言えます。
単体テスト・総合テスト
基本設計や詳細設計工程時に作成された、テスト項目書に沿って、テストを実施して行きます。
backlogなどで、問題のあるバグが発見されたら登録をして、問題処理管理を実施すると効率的です。
受け入れテスト
要件がしっかり満たされているかをチェックします。
業務委託契約を結んでアウトソースする際には、
納品時の検収として実施しているケースが多いですが、
内製で実施する場合は、単体テスト・総合テストはテストエンジニアが実施して、
受け入れテストはビジネスマネジャーが実施する形が良いと思います。
内容は、総合テストと受け入れテストは重なる部分があったりします。
v字モデルにおけるビジネスマネジャーとエンジニアの分業について
v字モデルの良いところは、ビジネスマネジャーとエンジニアが分業できる所にあります。
プロジェクトマネジャーは一貫して必要なのですが、
ビジネスマネジャーは、要件定義や基本設計を考えれば良く、
エンジニアは、詳細設計と実装に集中すれば良い形となります。
さらにテストもレイヤーごとに分業できます。
どんなメンバーが必要なのか？
- ビジネスマネジャー：実際にお客様にサービスを販売する責任者（呼び方は、営業といったり様々）
- UXデザイナー：ビジネスデザインができる。ビジネスマネジャーとお客様のインサイトを汲み取って、要件定義をする。
- プロジェクトマネジャー：ビジネス側の要望をエンジニアがわかる形に翻訳しつつ、進行管理をする。チームメンバーから厚い信頼ある方が望ましい。
- エンジニア・デザイナー：プログラミングやデザインを実施する
- テストエンジニア：テストを忠実に実行する
まとめ
v字モデルの長所
法人向けサービスや医療向けなど、失敗した際のコストが高い場合には、向いています。
またエンジニアと共創する際に、意思決定の履歴が設計書という形で丁寧に残っていくので、
問題が起きた際にも、設計書をバイブルとしてコミュニケーションができます。
設計書を通じて、基本的なエンジニアの考え方を学ぶこともできるでしょう。
またエンジニアは、後工程での仕様変更（無理難題だと思われていないけれども実態はものすごく大変）を設計書を通じて、ビジネスマネジャーに交渉することができます。
v字モデルの短所
設計書やテスト項目書をベースとして、プロジェクトを進めるので、
ドキュメンテーションに時間が取られ、スピードが落ちる場合があります。
また、工程の後半では、この機能がやっぱり欲しい。と言っても、融通は効かないことが多いです。
設計工程で盛り込まれなかった機能を追加するには、設計工程の成果物である設計書を改版する必要があります。
テスト項目書を消化しないと、市場投入できないので、
まず作って市場投入して、反響を見てからバージョンアップをするというスタイルには向かない場合があります。
スピードが落ちて、サービスリリースに手間取っている間に、
スタートアップ企業など競合企業が同様のサービスを粗い状態でリリースして、バージョンアップを積み重ね、
気付いたら、ノックアウトされている。という状態にならないように気をつける必要があります。
v字モデルがいつも良いという訳ではありませんので、
私自身、長所短所を理解して活用して行きたいと思います。
実態としては、携帯電話のOSを作るような巨大なプロジェクトでなく、小規模なプロジェクトである場合で、
かつ、エンジニアとの信頼関係があれば、
ドキュメンテーションの省略や、工程の手戻りなども柔軟に対応いただける場合もあります。
ビジネスマネジャーとエンジニアの信頼関係が、プロジェクトの成否を決めるのは、
どの開発スタイルを取っても同じだと考えています。