アジャイルに目的はない

日経なんとかにアジり記事を書いてる人のツイートに触発されてか、次の記事が紹介されていました。

「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!

2012年の記事なのね。でもあまり状況は変わっていない。

で、上記記事を読んだのだけれど、昔から感じている違和感があるので、今日はそれを整理したいと思います。

私が知っていたのは「日々変化するビジネス環境の中で、ソフトウェアが予測困難な要件や変化する仕様に対応できていない」という課題があり、そこから産まれたニーズが「変化に対応していけるソフトウェア開発」というもので、それに応えることができるのが「アジャイル開発」だったと思っていました。

しかし最近の文脈では「短納期化と低コスト化する中で、ユーザーの要件を確実に、高品質に、より短期間で提供できていない」という課題に対して、「低コストで速く作れるソフトウェア開発」というニーズに応えるものが必要で、それを「アジャイル開発」と呼んでいるようです。

前段の課題意識はまっとうだと思うし、それにアジャイル開発で答えられると考えるのもごく自然だと思います。しかし、後半にはひっかかりますね。

SIerは、大規模ででもそれほどエッジではない業務システム開発のやり方しか知らなくて、だから要件定義、設計、実装、試験、導入、という流れに特化しちゃってます。集約労働型ウォーターフォールでしかできない。結果として、決めきれない要件をあいまいなまま全部詰め込むところからスタートし、頭数だけ揃えた開発メンバーは言われたことをやるだけかそれすらもあやしく、設計や実装についてフィードバックから洗練させていくこともないので、まあアーキテクチャに関してはそうそう外すことはないとしても、馬鹿みたいにコピペだらけで醜くて重複と無駄だらけのコードが量産され、そこまでに大変時間がかかり、そしてその検証は遅れたスケジュールを挽回する最後の機会だから短縮はされてるけどテスト内容を減らすことはできないのでデスマになります。SIerだってさすがにそれがリスクで問題だという認識はあるわけですが、なかなかいい対策を思いつかないところにアジャイルに出会ったわけです。

ところで、そもそもアジャイルには目的はありません。アジャイルの定義ともいえる アジャイルソフトウェア開発宣言 は価値観の表明文だし、 アジャイル宣言の背後にある原則 も原則のリストです。これらをなにに用いるかは実践者の自由で、何に用いたとしてもこれらの価値観と原則に従っていればアジャイルと呼んで構わないでしょう。

SIとアジャイルの幸せな出会いというものを想像すると、こんな感じだと思うのです:

要件定義をやりきれないと設計以降の工程に入れないという縛りが解ける。集約労働っていうか質が低い大量のかきあつめ人材に頼らず、少数の信頼できる限定したメンバーで継続的に動くソフトウェアを提供するかたちにできる、要求とその実現形態を探索できる、新しいミドルウェアやプラットフォームを用いる技術的リスクにも繰り返しテスト・デプロイできるなかで正しいやり方を発見し適用できる、

これらをSIerと顧客が受託開発で享受する。なにが悪いんです?

結果として、スケジュールが遅延して(=早くない)、終盤のデスマに火消しを投入する分大赤字になる(=安くない)が回避できるなら、それは早くて安いんじゃないですか。

そういえば、スクラムのソフトウェア開発以外への適用の話で、ワイナリーの業務運用に適用した事例がありましたね。ワイナリーの業務って日々変化するんですか。そんなのアジャイルじゃないですか?

まあ、倉貫さんの記事が書かれてから6年経っても、SIerも実際のところ、中途半端にアジャイルラクティスを適用しただけの中途半端なアジャイルしかやってないことが多い印象です。それは本当のアジャイルのよさを発揮できていないので、アジャイルと言っちゃうのはどうかと思う、という指摘はもっともだしいいことだと思いますけどね。

SIerにもアジャイルをやらせてあげてくださいよ。アジャイルといいながらもそうなってないじゃんってところが事例報告とかにあったらそこを具体的に指摘するのはいいと思いますが、SIにアジャイルはありえねえ!みたいに言うのはやめて、という話でした。