私とアジャイルとの出会い(2)

前回のエントリ、私とアジャイルとの出会い(1)で紹介した大炎上プロジェクト。

その後1年ぐらい経って、またリーダーをさせてもらう機会に恵まれました。
前回大炎上させてしまったことで、もう機会が巡ってこないかもと思っていたので内心ホッとしました。
新しいプロジェクトでも大変でしたし、色々失敗もしましたが、経験を重ねてコツが掴めてきたのか、なんとかリーダーらしきことができるようになってきました。

新しいプロジェクト

そんなある日、新しい案件があり、私をリーダーとする新たなプロジェクトを結成することになりました。それまでのメンバーは他に移り、私の他は入社2〜3年目の若い子が2人だけ。

2人とも真面目で素質はいいものを持っていましたが、あまりプログラミングの経験はありませんでした。

納期も短いうえに、私自身もこれまであまり使ったことのないミドルウェアやプログラミング言語を使っていく必要もありました。この状況は前の炎上プロジェクトより遥かに厳しいものでした。

でも、私はむしろチャンスと感じていました。

あれを試すときがきたかもしれない。

そう、前に日経コンピュータで読んだ、アジャイル的な開発プラクティスの導入です。
プロジェクトのリソースが貧弱で不確定要素が多いという、今回のような状況こそ最適だと思ったのです。

若い子ばかりですから、新しいやり方に対する抵抗感も少ないだろう、という考えもありました。

とはいっても、ウォーターフォール開発の契約ですから、基本的な開発プロセスを崩すわけにはいきません。

なので、

「できそうなプラクティスだけを選択し、アレンジして適用する」

やり方でいくことにしました。

取り入れたことは、

朝会

タスク管理

小さなウォーターフォール

ペアレビュー

でした。

当時は珍しかった朝会。

プロジェクト立ち上げの日、私は皆に言いました。

これから毎日、朝会をやろう。

当時は朝会をやっているプロジェクトなどほとんどありませんでした。週1回の進捗会議を1〜2時間ほどやるのが普通です。
そんな中、いくら3人とはいえ、他の人が座って仕事している中で自分たちだけ事務所の片隅に立って朝会してるわけですから、相当目立ったと思います（私は当時は全然気にしてなかったのですが、メンバーの子はちょっと恥ずかしく思っていたかも・・・）。

いきなりそんなことを始めたもんですから、周りの人からも心配されます。

「なあ、毎日会議してたら時間のムダじゃないか？メンバーの負担も増えるぞ」

と言われたこともあります。

でも、

「いえ、今回のプロジェクトのメンバーは経験の浅い子ばかりなので、自分自身で問題を解決できないことだってあると思います。なので毎日細かくフォローして、問題点があったらすぐに解決してあげないといけないんです。わからないことがあるのに言う機会がなくて、翌週の会議までうまく作業が進まない。そのほうがよほどムダじゃないですか？」

という感じのことを言って、続けていたと思います。
実際、作業で困ったことを早いうちにキャッチアップすることができ、ありがちな「後で衝撃の事実が発覚し大混乱」のようなことはほとんど起きなかったように思います。

少人数のタスク管理はExcelが最強!?

タスク管理の方は、本当はホワイトボードに付箋紙を貼って、タスクかんばんを作りたかったのですが、当時の事務所にはホワイトボードを設置する場所がありませんでした。
ホワイトボードの数も限られており、わずか3人のプロジェクトで独占するわけにもいきません。

そのためExcelで課題一覧表を作り、毎日内容をチェックするようにしました。まあ、あまりExcelというのはイケてないし、Excel方眼紙は大嫌いなのですが、設備がない以上仕方ありません。
でも、少人数のプロジェクトでしたのでExcelで十分だったともいえます。むしろ検索とかデータの二次利用ができたので、このときはメリットの方が大きかったな、と思います。

ウォーターフォールも繰り返せばイテレーションになる

アジャイルの特徴である「イテレーション」「変化への対応」については、ウォーターフォールモデルを崩すわけにはいかなかったので、ちょっと難しい面はあったのですが、「設計に誤りがあっても仕様変更に迅速に対応できる」仕組みをなんとかして作ろうとしていました。

そのころ、一緒に仕事をしていたお客様側のリーダーの方も、アジャイルには興味を持っておられましたので、やり方を提案してみようと考えました。ウォーターフォール的なものを維持したままアジャイル的な考えを取り入れるにはどうすればよいか・・・私の考えはこうでした。

開発量や期間を短くした「ミニウォーターフォール」を定義し、それを複数回繰り返す。

この「ミニウォーターフォール」には「フェーズ」という名を付けて「フェーズ1」「フェーズ2…」と呼ぶようにしました。1回のフェーズがアジャイルでの1回のイテレーションにあたります。

各フェーズはそれぞれ実装すべき機能が決められており、「設計」「プログラミング」「テスト」の工程順で機能を実装していきます。もし工程の途中で問題が発生したり、作りきれなかった場合は、フェーズ終了後にお客様と話し合い、次回のフェーズで開発する内容を見直していきます。

今回は特に、使ったことのなかったミドルウェアやプログラミング言語を使いこなす必要があり、開発途中で何が起きるかわからなかっただけに、フェーズを繰り返せたことは大変効果がありました。1回毎のフェーズが短いので早い時期にテストできたため、問題点を早期に見つける事ができましたし、問題が起きても次のフェーズで作戦を立て直すことが可能になりました。

あとはテスト駆動でできればよかったんですが、ちょっとそこまではできませんでした(笑)

ペアプログラミングには不安が…ペアレビューを導入

当時XPの特徴的なプラクティスと言えば「ペアプログラミング」でした。
ただ、これはマネージャ層の受けがとにかく良くなかったです。

1つのプログラムを2人で作ったりしたら、生産性が半分になるじゃないか！

必ずしもそうではないとは思うのですが、なにせこちらも初めてですので結果がどうなるかはわからない状況でした。あまり無理を通してプロジェクトを失敗させては元も子もありません。
自分自身も以前少しだけペアプロを試したことがありましたが、(やり方の問題もあったのか)予想外に疲れるもので時間もかかった経験がありました。なので、無理にペアプログラミングを導入するのはやめて、
「ペアレビュー」という仕組みを取り入れてみました。

当時のレビューと言えば、会議形式で大人数で行うことが主流でした。今ほどペーパレス化が進んでいなかったですから、ソースコードはいちいち紙に印刷して配布していました。

ただ、このやり方だと手間がかかりすぎ、頻繁に行うことはできません。
会議室を押さえたり、印刷して仕分けして、大勢の人のスケジュールを調整して・・・意外とレビューの準備というのは大変なのです。

さらに、今回は経験の浅い子が多いですから、もし間違ったプログラムを作っていて、工程の最後で発覚したら直す時間が取れなくなってしまいます。
そこで、プログラミング工程の途中に軽めのレビューを挟んでいくやり方を考えました。
ソースコードの印刷や会議室の確保など、手間のかかることは行わず、座席でdiffをかけたPC画面を見ながら2名で実施します。レビューの範囲も狭くして、時間もごく短時間で終わらせます。
これにより、気軽にレビューを始められ、比較的早期にプログラムの問題点を見つけて対策する事ができたと思います。レビューで指摘があってもその場でプログラムを直せるし、正しく直せたか確認する手間もかかりません。

ただ、このやり方だとレビューの観点が局所的になってしまい、全体的な問題点を見つけられなくなるのでは、という不安もあったので、最終的にはこれまで通り会議形式のレビューも実施するようにしました。

これらのおかげもあり、色々苦労もあったもののなんとかプロジェクトは終了し、無事に納品を迎える事ができました。