ポジション的なもの
個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。
現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。
キーワード「エンタープライズ」が出てきているので、業務システムの話をします。
情けないぞアジャイルコーチ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。
サム・グッケンハイマーの一言
の方が
「ウォータフォールは一切メリットがないので止めておきなさい」
といったそうです。まあ、ポジショントーク。 マイクロソフトは、これから日本で、Azureを使ったDevOpsを売りたいですよね？
自分の本当の心の中
統計を見ても、2015年のVersion One のサーベイを見るとワールドワイドで９５％の企業がアジャイルを導入しているが、日本だと、同年のPMIの統計によると 31%が導入済みに過ぎず、明らかに遅れをとっている
うしおさんがMicrosoftの中の人である以上、ポジショントークとして扱うのが良いと思います。特に、この画像にde:codeのロゴ入っているのが、ひっかかります。
マイクロソフトの面接での出来事
彼は面接の最初にちょっとびっくりした声で私に聞いた Tsuyoshi、日本でアジャイル導入があまり進んでないって本当か？
DevOpsを売るに当たって、前提として「アジャイルが流行っていない」のどうしようか？みたいな、状況でしょうか？ エンタープライズ向けに売ろうと思うと、由々しき事態だと思います。 上司の方の危機感の認識は日本市場に合っているのではないでしょうか？
最近ソフトウェアに詳しいアメリカの女性と話した時にウォータフォールの話をしたら「まだ日本ではウォータフォールなんてやってるの！そんなの誰もやってないよ！」と本当に驚いていた
なるほどー、そうなのかもしれません。 人類に達成可能である証拠なので、アジャイルを導入したい、自分にとっては朗報です。
ウォータフォールは起源から異なっていた
ウォータフォールの起源はどのようなものか？というと、Winston.W.Royceが書いた MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS という論文が起源になっている
私も、そうだと思っていました。久しぶりに見直した日本語のWikipediaに・・・
初めて「ウォーターフォール」という用語を用いたのはT.E.BellとT.A.Thayerによる1976年に発表された論文「Software Requirement」であり、B.W.Boehamが1981年に出版した本「Software Engineering Economics」においてウォーターフォールモデルのオリジナルはRoyceだと述べ、ウォーターフォール・モデルの起源がRoyceであるという誤解を広めた。
まじかよ！本日、最大の驚き！！
ウォータフォールを前提とするのが本当に日本のためだろうか？
１日に１０回も１００回も本番にデプロイできるようなオートメーションがなされたり、データセンターレベルで抽象化が進んで自動回復を行えるまでの環境が出来てる。Infrastrucute as Codeの対応をしている2200台のサーバーのセキュリティパッチをたった一人が１５分で当て終わるような時代だ
1日に10回、本番デプロイする必要がある、業務には、どういう業務を想定されているのでしょうか？ 個人的には思いつきません。
個人的な経験では 「1日待ってもいいから、ちゃんとテストして、バグで毎日の業務が止まらないことを保証してから、リリースしてください。」 と要望されることが多いです。
1日に10回、本番デプロイできる環境では、業務システムを使って業務を行う方たちも
- バグったらシステム管理者に連絡
- 再リリースまで休憩
な、やり方に慣れるのでしょうか？ 米国に、そういう事例があるのであれば、是非知りたいです。
開発する立場としては、「とりあえず勘で直してリリースした。直ったかどうか、確認して」と言えたら、とても気楽だなと、思います。 正しいやり方かはわかりませんが、緊急回避手段が増えるのはありがたいことです。
自分の恥ずかしい体験談 私はインターナショナルでは無価値である
彼らは日本では体験できないほどアジャイルについて深く理解しており、私があげたどの想定課題も既に体験・解決済みだった。例えば、受け入れテスト駆動開発の話題を振っても彼らはそれを導入した時の事、発生した課題、どう解決したか？みたいな話をしてくれた
これは、うしおさん個人が、アジャイルな現場での開発技術についていけていない話な気がします。 現場で手を動かすのをやめるのが早すぎたのではないでしょうか？
アジャイルコーチのジョークに「もう何年もプログラムを書いていない」みたいな話があった記憶があります。 そのイメージです。元ネタを失念しました。
最も深刻なことは、「経験」を積めないこと
2003年の時点の私の経験は、米国でも価値のあるものだったと思う。では日本で経験を積んだ私が無価値になってしまった
は
私は外資系、できれば海外に住むことをターゲットに仕事を探していた
という目的に対しては、残念とは思います。
だけど、あなたの積んだ「経験」は、絶対に他人が詰んだ経験とは異なります。 異なる経験は異なる状況では価値があります。普遍的に無価値ではありえません。
「自分の経験は無駄だった」はただの思い込みです。無駄なのでやめましょう。
日本はソフトウェア開発の後進国
ChefのAlexが日本のソフトウェア業界が8年遅れだと言っていた。Samは5年遅れだと言っていた
これは間違いないです。日本人のGithubのリポジトリをWatchしたことがありません。 本場で自分の力を試してみたい人は行けばいいと思います。 個人的には食の面で、移住には魅力を感じません。
海の近くで魚介が美味しくて、山の近くで水が美味しいと、食べ物は美味しいです。 シリコンバレーは割と食べ物がおいしいかもしれません。
自分が目指すビジョン
私のここ数年のビジョンは、日本と米国の技術やプロセスの導入スピードを同じにすることだ
なぜでしょう？
Samの野郎に、「日本は今や米国と同じスピードで遷移している」と言わしめたい
遅れていると言われるのが嫌だからでしょうか？
うーんと・・・「ファッションアジャイル野郎が！」と言ってみたいですね（汗
エバンジェリストに期待すること
「遅れている」や「遅れがもっと広がる」という、脅しは必要はありません。 FUDは嫌いです。
を伝えて欲しいです。
事例さえあげてもらえれば、あとは我々SIerが発注者に売りこみます。
日本でアジャイルが流行らない理由
個人の考えです。
- 予算確保にシステムの仕様が必要
- システムの発注が請負契約
- 発注企業のシステム担当者が、一つのシステムに専任していない
- 発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
- 発注企業の業務担当者が、システム開発に専任していない
予算確保にシステムの仕様が必要
95%の会社がアジャイル開発やっているなら、これ教えて下さい。本当に。 システム開発を始める際に、会社内でプロジェクトの期間と目的と予算は決めているはずです。
どういう風にプロジェクトを初めて、どういうときに中止するのか。 リスク管理のやり方が真似できれは、日本の企業もアジャイルな発注ができるはずです。
公共案件の予算管理にも適用できると、大手SIerもアジャイルに移行できるのではないでしょうか？
システムの発注が請負契約
よく言われます。これは分割納品にすれば割と回避できます。
ただし、最終納品では揉めることがあります。 発注時の仕様と違うものを納品するには、発注会社のシステム担当者が社内を説得する必要があります。 できなかった場合に、納品のためのごちゃごちゃした作業が必要になります。 プロジェクトは炎上します。
社内を説得できる人は、とっくに「アジャイルのようなこと」をやっています。
「予算確保にシステムの仕様が必要」と同根です。 発注会社（のシステム担当者の上司）はアジャイルなプロジェクト管理をする方法がわからないのです。 開発側の技術や環境の問題ではありません。
発注企業のシステム担当者が、一つのシステムに専任していない
アジャイルなプロジェクトで1週間に1回リリースすると、発注企業のシステム担当者の時間が足りなくなります。 毎周、検収して次の週のストーリーを考えるのは無理です。
これは、発注企業のシステム担当者が、一つのシステムに専任していないからです。 他の業務に追われています。
この状況では「1日に10回本番デプロイ」魅力にはなりません。 DevOpsを使いこなすためには、発注企業は、システム開発の費用にシステム担当者の人件費をもっと増やす必要があります。
検証環境に「1日に10回本番デプロイ」できると、ソフトウェア開発者にとっては便利です。 手で受け入れ試験を回せるので、システムの理解が捗ります。
発注企業のシステム担当者が、コンピューターサイエンスの知識を持っていない
- ディスクは遅くて、ネットワークはもっと遅くて、メモリはちょっぱや
- 1万レコードは問題ない。10万レコードはちょっとおもい。100万レコードは重い。1億レコードは色々頑張らないと無理
みたいな感覚を持っていてもらえると、コスト感が通じやすくて嬉しいです。愚痴です。
端から見ていると、業務システムのプロダクトマネージャーは、とても難しい仕事に思えます。
- 商売の理解。システムをどう活用すればもっと儲かるのか
- 業務の理解。どういうシステムなら業務がまわるのか
- コンピュータサイエンスの理解。どういうシステムなら低いコストで作れるのか
すべての知識を持ったプロダクトマネージャーは、非常に稀有に思えます。 数千万円程度の投資をして、外部から登用するか、社内で育てる必要があるように思えます。
それで商売上の価値があるのかは、私にはわかりません。
発注企業の業務担当者が、システム開発に専任していない
日本では当たり前です。業務担当者は、
- 開発初期のインタビュー
- 開発終盤の受け入れ試験での確認
ぐらいに参加。システムが稼働し始めてから、本格的に使って混乱します。 慣れてくると、本当の要望が出てきます*1。
米国では、「業務設計担当者とアジャイルに開発して、現場の人はマニュアルにしたがって操作するだけ」なのでしょうか？ 気になるところです。
「システムを段階的に導入して、現場の業務担当者のフィードバックを生かして、システムを育てていきたい」 と、常々思います。 受託開発では、納品後はシステムはソフトウェア開発者の手を離れます。 「現場の業務担当者のフィードバック」を受ける機会はあまりありません*2。
