GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

アジャイルに限らず開発手法の議論は不毛になりやすい理由

アジャイル開発に対する論争が盛り上がってるので、僕も便乗しまーす。新野さん、秀逸なまとめありがとうございました。

「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ - Publickey

僕も2年半前にアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceという記事を書きました。アジャイル開発ってかなり牧歌的なので、内部ならまだしても外部の仕事を請けてキチンと回すのは難しいのではと書いたら、多くの方が「そりゃそうよ」と反応してくれました。その頃から、これを"ケツカッチン"な仕事で行うのは困難だと感じておりました。コミュニケーションが密に取れないと動けないじゃん。

議論の軸をもっかい振り直すと、アジャイルが確約出来る内容はあくまで人材育成・組織風土形成という不定形なサービスでしかないんじゃないでしょうか? アジャイルな組織になりたいからアジャイルを許容する or 手懐けることが、ユーザー企業もしくは自社の事業運営にとって必要って感じでアジャイルが求められるのが典型例な気がする。なので、アジャイル開発が約束できるのはあくまで「顧客やビジネスへの変化への対応」であって「組み上げたシステム」じゃないなら、ゆーすけさんが「実証主義的な説明にすぎない」「手段が目的化する」「全体スケジュールにコミット出来ない」といったダメな理由を挙げていくのも頷ける。コンサルティングとあがっているダメな理由は水と油だ・・・。いやいや違いますよ、ウチは請け負った成果物にコミットしますよキチンと仰るのなら、是非ご指摘頂きたいです。

アジャイルが悪いって話じゃないですよ。単純に目指す所が違うだけ。それでいいじゃない、とも思う。

ちょっと考えてもらいたいのは、システムを望む顧客からすれば、

  • 100万払うから責任もってこのシステムを作って欲しい
  • 100万払うから一緒にシステムのあり方を共に作りながら考えて欲しい

この2つの話には大きな違いがあるでしょ? 顧客が何にお金を払うのかという所がすっぽり抜け落ちているので、開発手法の是非の議論をした所でお互いに足を引っ張り合って何の結論も出ていないんじゃないですか? アジャイルで請ける場合どうやって予算を取って回しているんですか、っていうことが僕は最も気になる。請けられないよがFAな気もするけれど。

顧客からすれば、WFだろうがアジャイルだろうがSaaSだろうが、手段は何でもいいじゃん。 ソフトウエアの作り方とすれば、そりゃ不都合なことはコードを書いてから現れるんだから小さく動くのがベストだけど、ソフトウエアが欲しい人からすれば「どういった開発手法やプロセスが」ベストなのかを考えていけばいいじゃないですか。ここは千差万別でしょう。

最終的な成果物が求められる場合は、ドキュメント上の要件定義が全て出来てから開発を開始するのではなく、プロト的な動作確認及び機能の妥当性確認を設計フェーズで入れながら足下を固めるしか無いのかなぁ・・・。ドキュメントだけでゴールを規定しても内製ですら違うものが出てくるから、動かないコンピュータや工程の破綻を避けるならコードを書きながら工程間を動かせるようにするしかないのでは、と思います。そこでゴールが違っても、より良いゴールにたどり着ければ問題無い。特に、内製の場合は動かないコンピュータは許されません。

ただ、「こういう風にシステムで業務を実現したいんです」と要件と仕様に整理することが出来ない組織が多すぎるのに、そこを放置して開発手法の議論をしてもしょうがないという気持ちが年々強くなっています。要件と仕様が区別できているのならば、どういうやり方をとっても大きく破綻することは無くうまく行くからさ。

これからの開発手法の議論は上流工程のあり方をどう変えていくのかという方向も見据えて議論してもらいたいです。是非じゃなくて、さ。

SQLを学習できるWebサービスを作りました。