仕様把握

ここ1ヶ月、開発者がすべて撤退してしまうという理由から
とあるシステムのすべてを自分達が引継がなくてはならなくなり、
色々と奮闘してました。

仕様把握、設計書、レビュー方法、環境、開発手法、テスト手法、もちろんコードの中味。

いやー、システムも大きいし何から手をつけていいやらって感じでした。
とりあえず、勉強会を開いてもらい、IPOの読み合わせをやってみては見たものの、
ぜんぜん頭に入りません。IPOに書いてあることが細かすぎるんです。
とはいえ、機能の概要を書いた資料はない状態でした。

で、上手く引き継げたかというとぜんぜん上手く引き継げてませんが
今日から開発者は自分達だけになってしまいました。

意図的にやったIPOの読み合わせでは、仕様や開発方法、テスト方法は
まったく理解出来ていません。
ですが、偶然ながら仕様が少し理解できています。
そして、開発手法、テスト手法、コードもある程度引き継げています。

なんでだ？意図的じゃありません。

で、なぜかを考えてみました。

・仕様の理解は、ITのテストケースをトリガーとして、仕様を聞きまくっていた。
　ITのテストケースは「なぜそんなケースが必要なのか？」という疑問がわきやすく
　仕様を質問するための良いきっかけ(トリガー)になっていた。

・業務のワークフローが、偶然ながらつかめてきた。

・主要DBのデータの流れが、偶然ながら見えてきた。

・キラー機能について、重点的に理解しているメンバーが偶然ながら出来てきた。

・各開発フェーズの専門家が偶然ながら出来てきた。

・とりあえず、いろんな仕様を前の開発者にマトリックス(表)にしてもらっていた。

以上のような偶然の結果だということが分かってきました。

というわけで、次回はこの偶然を必然にすればいいわけで、
引継ぎのコツが見えてきた気がします。

キラー機能についての専門家を作り、各開発フェーズの専門家も設け、
ITのテストケースから疑問を定義し、業務のフロー、データのフローを重点的に掴み、
とりあえずマトリックス(表)で記録する。

これを、引継ぎ当初から積極的に行っていれば、もう少し引き継ぎが上手く出来ていたと思う。
この方法だと、各メンバーの範囲を決めてしまうので、引継ぎ時点では、トラックナンバーが増えてしまうが
引き継いでしまったあとに、アジャイルに持ち込めばそのリスクもなくなるはず。

やっぱ一人や二人では引き継げない。チームの力を信じるべきだな。