アジャイルサムライから学んだこと

9月に東京であったPHPカンファレンス2011のとあるセッションで紹介されていた書籍に「アジャイルサムライ」というものがあった。口コミ等を見るととても評価が高かったのですぐ購入した。が、羽毛布団.comのリニューアルが佳境だったのと、終わってからは仕事が忙しくなったのでなかなか読む時間がとれなかったのだが、先日ようやく読み終わった。

結論から言えば、とても面白かったし考え方という部分で刺激を受けた。アジャイル開発に興味があるとか関係なしに、システム開発に関わる人は一読の価値があると思う。

アジャイル開発というものは最近よく聞くようになったし、実践しているシステム開発会社も増えているだろうが、その精神というのを理解しているのは少ないんじゃないだろうか。先日うちの会社でもあるプロジェクトでアジャイルを取り入れているという話があったが、「イテレーション」とかアジャイルで使うキーワードは出ているが、結局それくらいなんじゃなかろうかと感じた。

アジャイル開発の肝は、

・顧客満足を最優先とし、価値のあるソフトウェアを継続的に提供すること
・要件の変更に柔軟に対応する
・顧客と開発者はともに働く
・動くソフトウェアの提供を最優先とする

こんなところだと現時点では理解した。アジャイルはよくあるウォーターフォールとかスパイラルみたいな開発手法の一つであることは変わりないが、その根底にある考え方はずいぶん違う。それは、顧客に価値を提供することが最優先であるということだ。

東京でやっていた2年間の仕事は数十億という予算があり、ピーク時には100名以上がこのプロジェクトに従事していた。が、最終的には膨大なドキュメントが残っただけで、動くソフトウェアとしては何も提供できないまま頓挫した。
当時は「つらい」という気持ちしかなかったので、ぽしゃってよかったぐらいしか思っていなかったが、アジャイルサムライを読んであのプロジェクトを振り返ると、ダメになるべくしてなったと思える。少なくともプロジェクトの中盤からは「顧客」に価値を提供することを考えがなくなっていたからだ。

膨大なドキュメントを見せられたって顧客にははっきり言って理解できない。見たいのはあくまでもソフトウェアのはずだ。じゃあそのドキュメントは誰のために書いているのかというと、本来顧客のためのはずだが実際は開発者のために書いている。そして、その開発者は会社に縛られる。同じ顧客を相手にシステムを開発しているはずなのに、いつの間にか各開発会社間の責任のなすりつけ合いになった。そのネタにされたのがドキュメントの品質だ。

その結果、さらにドキュメントを書く。顧客の知らないところで、いつまで経ってもソフトウェアの開発ではなくひたすらドキュメントの作成が行われた。ドキュメントが不要とは言わない。ただ、システム開発はドキュメントを書くのが仕事ではなくて、ソフトウェアを作って、それを使ってもらってこそ意味がある。その意識が当時の僕にもいつしかなくなっていた。

アジャイルの手法がすべて正しいとは思わない。ただ、少なくとも小規模なプロジェクトには向いている手法だと思う。逆に言えば大規模プロジェクトに導入するのはなかなか難しい。なぜなら、イテレーションを区切って継続的にソフトウェアを提供する形になると、従来のように大手SIerが受注→下請けに仕事を流す、なんてビジネスモデルが破綻するからだ。
見積もりなんていう経験則とどんぶり勘定で大きく予算をとって、後はお任せ〜なんてことはアジャイルではできない。

また、アジャイルチームでは部下の進捗管理と顧客への報告だけしておけばいいなんてポジションは必要ない。チーム全体でソフトウェアを継続的に提供しなければならない。そういう意味で大手SIerのSEではこんな仕事ができる人は少ない。そういう意味で、彼らのビジネスモデルを崩すようなことはおそらくなかなかできないと思う。
ただ、逆に下請けの企業もうちはプログラミングだけやってるから、顧客との折衝は大手のプロパーにお任せなんて考えも通用しない。

システム開発の仕事は最先端を行っているというイメージとは裏腹に今まで大手→下請け→孫請けなんて、今時珍しいってくらいピラミッド構造のビジネスモデルだった。そういう時代が徐々に変わりつつあるのかもしれない。ITがこれだけ進化して、顧客もそこまでバカじゃない。大手だからとかじゃなくて、価値を提供してくれるSE・会社が選ばれる時代が近づいているのだろうか。

とりあえず、次の仕事でいろいろ試してみたいこともできたし、アジャイルサムライの続きとして次は以下の本を読みたいな。