システム開発の成果物って？

システム開発の成果物ってなんですか？
そりゃー、開発したプロダクトでしょ。
ほんとにそれだけ？

先日書いたこちらでも触れてましたが、社内イベントのアジャイル座談会に参加させてもらってきました。
こちらもいろいろと感じるところがあったのですが、
今回は、開発の結果生み出される成果物の話をしようかと思います。

いわゆるThe成果物

システムの開発であれば、最終的な成果物は何かしらのプロダクトであるはずです。
で、それを生み出す過程で生じるものとして、設計ドキュメントがあり、コードがあり、実行環境があり、操作マニュアルがあり、みたいな話はスルッとでてくるかと思います。
それ以外に、内部向けにはテスト結果のレポートだったり、開発チームから運用チームへの引き継ぎ資料だったりがあったりするのかなと。

それ以外の成果物

直接エンドユーザーが使うものではないし、内部向けのドキュメント類でもない。
でも、実プロダクトと同等レベルに大切なもの。

ずばり、「チームそのもの」です。

その開発を通じて、チームがどんな学びを得たのか、どんな成長を遂げたのか。
それって、ものすごく重要ですよね。
たとえ、そのチームが開発終わったら解散して、それぞれのメンバーが違う開発をスタートしていくことになるのだとしても。
開発チームがそのまま運用チームになっていったりする場合には、チームメンバー間の相互理解や、クライアントとの関係性含め、今後の開発・運用をの質を左右する大きな要素になる。

で、これをWFとアジャイルで対比してみると、、、

チームの成長も成果物だよね。
ということを前提に、WFとアジャイルを比較してみましょう。

開発を通じて得た学びって、それぞれいつ活かせますか？というと、

ウォーターフォールの場合

WFの場合は、次のプロジェクトです。

振り返りをどのタイミングでやるかによっては、その学びを後続フェーズで活かすことができるかもしれない。
ただ、その名のごとくフェーズは一方方向に流れていって、戻ることはない（手戻りはあり得るけど、、、）。
となると、例えば要件定義でもっとこうしてたらクライアントとの認識相違がなくせたなーという気付き・学びがあったとしても、、、

そう、次の要件定義はそのプロジェクトでは巡ってきませんので、次のプロジェクトにしか活かせない。

アジャイルの場合

一方アジャイルはというと、スプリントの中で得た学びは、
次のスプリントで活かすことができる。
スプリントの長さにもよるでしょうが、ウォーターフォールと比べて短期間で経験値を得られる。
そして、次のスプリントで改善策が有効かどうか、検証もできる。
これって、ものすごく大きいですよね。

自プロジェクトに当てはめてみると、、、

ウォーターフォールでの開発。
既存システムのOS、HWの保守限界に合わせて７年スパンぐらいでリプレイス。工期数年。
リプレイスからリプレイスの間は半年〜１年規模の機能追加案件対応。

みたいな感じなので、なんせ成長スピードが遅い！！！
他社のエンジニアと会話すると、出川哲朗モード発動します（ヤバイよヤバイよ～）。

機能設計は経験あるけど、要件定義・基本設計はやったことないっす。みたいなことはざらにある。
案件の特性によっては、非機能要件なんて気にしたことないっす。なんてこともざらにある。
基本コアメンバーは入れ替わりがほぼないので、次のリプレイスが回ってくる頃には、ポジションが変わってたりもして、担当者としてのリプレイス開発の経験はあるけど、チーム運営する側としては初めてっす。とかも、ざらにある。
なので、前回開発の学びがほとんど活かされず、毎回毎回手探り、、、

そんな私からすると、スプリントごとに経験値が溜まって、それがすぐに活かせるって、めっちゃキラキラしてみえるんです。

最後に

ポジションが上がり、プロダクト自体の開発を直接進める立場から、開発を進めるチームを育てるみたいな役回りになってきたこともあり、いかにチームの成長スピードを早められるかっていうのが、テーマになってきています。
開発手法としてのアジャイルの有用性みたいなところは、それなりに理解していたつもりですが、これってチームの成長っていう観点でもすごく魅力的じゃんというところに気がつけたのは、ほんとにありがたいことで。

単なる理想で終わらないように、導入を画策しなければ、、、