多重下請けにアジャイルは馴染まない
- 「日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜」 https://qiita.com/hirokidaichi/items/1faf7a57cc55562a15e1
内容が薄い単なる広告．
私は、アジャイルとは何かという話をするときには、「不確実性に向き合うための考え方」だという説明をしています
まるでオブジェクト指向に対する憂鬱本のようだ．*1技術の話が精神論にすりかわってる．ほぼデマ．*2
アメリカ社会に東洋的なエッセンスを感じ取らせ、次第に経営学にとりいれられるようになっていったのです。
不確実性に向き合うこと
アメリカ社会で芽吹いた「新しい合理性」は、殊の外時代にフィットしました。
下手な横文字混ぜて水増ししただけの駄文．
たしかにトヨタのカンバン方式やリーン生産方式とアジャイル開発の類似性を指摘する声もあるにはあるけど *3 ，それは本当にごく一部の類似で，肉じゃがとビーフシチュー，クレープとお好み焼きほどにも似ていない全くの別物．まして東洋思想とカンバン方式となると，もはや無関係といっても良いのではないだろうか．
日本にアジャイルが普及しない理由は既に答がでてるだろ．多重下請け構造，SIビジネス，開発は外注へ丸投げ，下請けいじめ，たらい回し人事，プログラマー30歳定年説，元請の技術音痴，経営陣の技術軽視，薄給激務で長時間残業などなど．
全部ぶっ壊すくらいでないと成功しないけど，やる気のある経営者は皆無．だから失敗する．
「わからないものを実際やってみて確認する」というサイクルを固定するために、多くのアジャイル開発手法では、短いタイムボックスを設けて、都度振り返りとレビューを行います。これが、「未来」のわからなさに対するアジャイル的なアプローチです。
技術的な裏付けがなければ，変更に強いソフトウエアは作れない．「仕様変更を多くしただけのウォーターフォール」はアジャイルではないのに，日本の伝統精神論で神風アタックさせれば当然デスマーチになる．
アジャイル開発したければ，そういうスキルを持つプログラマを長期的に同じプロダクトに専念させるべきだが，日本企業が大好きな多重下請け構造SIビジネスは正逆の方向を目指している．その構造を維持したままアジャイルを導入しようとすれば失敗は必然だった．
オブジェクト指向設計実践ガイド ?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
- 作者: Sandi Metz
- 出版社/メーカー: 技術評論社
- 発売日: 2016/09/02
- メディア: Kindle版
- この商品を含むブログ (6件) を見る
http://ascii.jp/elem/000/001/076/1076171/index-3.html
- 川上 4年前にニコ動の開発が行き詰まったんです。「変更に変更を重ねてきたけど、これ以上は無理だ、何の機能追加もせずつくりなおしたい、2年間は何も変えずに現状維持にしたい」と開発の責任者が言ってきた。
- 川上 2年は新サービスが出せないとぼくはそのとき聞いたんですが、それからもう4年が経ったのに、ニコ動の新しいサービスは未だに出てないんですよ。4年間ずっと、イベントでごまかしてきたんです。
バグの修正には何時間も何日もかかり、修正や機能の変更には数日から丸々1週間を費やし、この停滞が速く仕事を進めたいと思う他の関係者を足止めし、あなたは技術的負債を解消する時間を取ることもできず、痛みが悪化するだけという悪循環に陥る。言うまでもないが、この悪循環はしばしば死のスパイラルになり得る。
最初の「最小限の実行可能な製品」は完璧にエレガントでスケーラブルであることはなく、またその必要もないというのは事実だ。しかし、もしそれが泥沼ソフトウェアで、あなたが人々が望むものを構築仕損なっていた場合には、対応はとても困難で遅々として進まず、目標を変えるのも高価についてしまうのだ。一方高品質のソフトウェアを持つ競争相手や新規参入者たちは次々と素早く取捨選択を進めていける。
https://jp.techcrunch.com/2016/07/25/20160724how-much-does-it-matter-if-your-software-quality-sucks/
http://javablack.hatenablog.com/entry/20160725/p1
http://b.hatena.ne.jp/entry/s/qiita.com/hirokidaichi/items/1faf7a57cc55562a15e1
- id:cyan0302 インハウスで開発しないからじゃないすかね。
- id:monorod みんな言ってるけど、アジャイルが請負に向かないってのがすべてだと思う。内製してるなら細々した問題はあるにしろ、アジャイルやること自体はそこまで難しくない。
- id:xlc 請負契約にアジャイルを適用しようとするキチガイをなんとかしろ。日本で「アジャイル」とは「下請けにリスクを押し付ける」という意味になってる
- id:digital-twins-papa アジャイルを「要件変えていい」と考える業務側がアサインされると死ぬ。試行の結果変わるのであって、要件定義を甘くして良いのではない。
- id:kazukan IT開発が外部発注になるビジネスモデルなのが1番反アジャイルで、それは日本全体のビジネス慣習によるものだと思う
- id:ttysumi クライアント側が、アジャイル対応で進めていく状況を理解できない／できていない／受容できてない、というのは大きな理由の一つだろうね。（最終のコスト・時間の不確実性も許容は受け側だけでなく出す側も必要）
- id:junglejungle ソフトを内製するところが少ないからだよ。びっくりするほどソフトを軽視しているんだよね。ロボット業界も、オフラインシミュレータとかは外国製ばっかりで、お家芸が聞いて呆れる。
- id:rck10 予算と仕様の明確化がＷＦの選ばれる理由。客とSIerの信頼関係は地に落ちているので「仕様通りです」という魔法の呪文だけが自分の身を守る手段なんだよ。プロトの開発物なんて金出さないって言い出すぞ。
- id:acealpha 開発を依頼する側として何をいつどこまで作れるかわからないと発注できない なので外注や、たとえ内製でも自部門外注になる場合の純アジャイル開発などない アジャイルは企画と開発を一緒に出来ない限り無理
- id:mrpotas “何を作ったらいいのかを知るのであれば、実際に作ったものを見せて顧客に聞いてみれば正しいのか正しくないのかわかります。” 顧客が「何か違うんだよなぁ」しか言わないんですが、どうしたら良いですかね。
それはアジャイルとウォーターフォールの悪い所どりしてるだけでは．
時代遅れの老害マネージャが，勘違いしたままアジャイルもどきを導入しようとするとなりがち．
- id:qpci32siekqd 個人的になんでウォーターフォールとアジャイルのハイブリッドにならないか不思議。
それらは水と油だからだよ．*4
分かってない人が形だけ真似すると、上の例みたいに失敗する．
この二つが技術音痴の偉い人がやらかす「似非アジャイル」の話．
すでに日本企業における「アジャイル導入失敗パターン」の一つになってるようだ．
