略
【1】経営陣がアジャイルを理解し、企業文化を醸成すること
まず、イノベーション文化を醸成するには、企画・開発が一体化した組織のあり方、現代のソフトウエア文化を支えるアジャイル開発を理解する必要がある。これは、「働き方改革」の文脈で捉えることもできる。エンジニアたちにできる限り自己組織的なチーム運営を任せる。働きやすい環境を与える。ツールやマシンを買い与える。
よく誤解されるが、アジャイル開発は「無規律」ではない。むしろタイムボックスに沿って強く（自律的に）マネジメントされている。定期的な自己改善と計測を行いながら、市場にフィットした製品やサービスを作り出すための、ビジネスとエンジニアリングのコミュニケーション手法である。これを経営は戦略として利用しない手はない。イノベーションは「内的モチベーション」から発生する。世界を変えたい、と思っている人たちに権限と裁量を与えるのが一番だ。
【2】既存の情報システム部門と別に、イノベーション部隊を建設すること
これまでの情報システム部門は、どうしてもベンダーをコントロールして計画どおりの成果を予算以内で作る（QCD）に注力してしまっていた。イノベーションの世界では「つくるべきもの」の定義を、ニーズ探索と小さな製品づくりを繰り返して行う（鶏と卵を同時に育てる）のだから、このやり方ではうまく行かない。
これからは、別途インハウスのイノベーション部隊を新しく組織する必要がある。そこに固定枠の予算をとる。新子会社を作ったり、社長直轄の部署を作ることもあろう。とにかく、小さなチーム（10名以内程度）を、必要であれば複数作る。そして、そのチーム単位で投資する。それをまとめて1つの部署にするのもよい。また、既存事業部署との関係を強くもつチームがあってもよい。むしろ、企業の強みを生かすためにはそうすべきだ。既存事業はその企業の強みであるはずで、そこを生かしながらイノベーションの外部関係を模索して行くのがよい。
また、その部隊は「内製」を目指すべきだ。そのためにはソフトウエアエンジニアが社内に必要になる。まず社内から募ろう。きっとよい人材がみつかる。見つからなくても、外部に単純に委託せず、ともに考えてくれるベンダーと準委任契約することを考えよう。イノベーションは、QCDの達成が目的ではない。ベンダーにリスクを負わせてはいけない。コストや営業力、プレゼンのうまさで選ぶのではなく、ともにアジャイル開発ができるよい人材を持つベンダーを選別し、信頼して付き合える関係を築こう。
【3】イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること
そういったイノベーション部隊を、計画達成度の進捗管理のもとに置くべきではない。そもそも計画できないのがイノベーションである。また、新しいアイデアが10出たとして、そのうち成功にまでたどり着くものはせいぜい1つあるかないかだ。これを計画対比で進捗管理してしまったら、確実につぶしてしまうだろう。ファンドを運営するように、小さな投資を複数に行うべきだ。
そのチームは、開発と企画の一体となった組織横断でつくり、品質保証やユーザー体験（UX）づくり、データ分析部隊も含めて一体化させる。そして生き残っていくものにさらに投資する。意思決定を細かく行い、ステージ管理をして少数のイノベーションを育てる必要がある。
新しい製品やサービスが、既存のシステムと連携することはよくある。いわゆるMode-1とMode-2の連携である。その場合でも、種となる人材を既存部隊から移動し、連携を含めて企画していく必要がある。
従来型のチーム
DX（アジャイル）型のチーム
本当にやりたいこと、欲しいものは自分たちにしかわからないのだから
ほんとうにこれ
これ分かっていない経営者多い
金出せば理想の物がポンッて手にはいると思っている。
海外だと実務をする技術者を自分の所で抱えてたりするんだよな
金を払ってでも技術やノウハウを自社内に残そうとする
つーかソフトってのは非常に頭のいい10人のプログラマのチームが100人の凡庸なプログラマより良いものを作れる世界。
100人の凡庸なプログラマはウォーターフォールで、10人の頭のいいプログラマはアジャイルで。
全員優秀ならウォーターフォールの方が効率よさそうじゃないか？
顧客も優秀じゃないと、それは成り立たない
>>6
ウォーターフォールだと
その優秀な10人が仕様書かいて
普通の人がコーディングする
あれ？自分で書いた方がよくね？
ってのがアジャイル
プログラム=ドキュメント
アジャイルってのはドキュメントを作らないことではない
素人が適当に語ってんじゃねえ
つーかイノベーション部隊とか
アホ？
まともな奴が雇われでイノベーション起こす方がマレ。
意識高い系がマックブック拡げて
遊ぶだけになる。
もっとベンチャーキャピタル部門立ち上げて融資と買収に力いれろよ。
立ち上がったのを買うんじゃなくて
種まきから手伝って育てたら買うなり 、配当を得るなり。
あと、できないやつを速攻で首にしないと効率が
それじゃ次から次だ
そこんとこよろしく
>>28
>必要なのは十分な予算と時間、どちらが欠けても駄目
そんなものより、作って欲しい仕様をきちんと話せるユーザーだと思うぞ
文字列置換を忘れた原稿がそのまま掲載に出ちゃったんだろ。
パワーワードだな、「アジャイル」って。
そういう事言ってんの日本人だけだよ
2012年の時点でこういう情況
アジャイルってのは小さいウォーターフォールを
多数小刻みに進めることなんじゃないの
ただ手抜きして早くコーディングすることだと
考えている人がよくいて困る
ウォーターフォールで問題無いケースは実は少ないのかもしれない
だから反復型に変わった。日本はまだだけど。
シャープ復活などを見ると良い指摘だと思うがな
「○○機能の進捗率37％、予定より5日遅延。リカバリ策は何々。」みたいなやつ。
日本の没落は管理部門の肥大化による所が大きい。
大規模開発だと進捗管理するのは当然じゃね？
>>110
それがウォーターフォール型の癌の一つだよ
アジャイル型だと一つ一つの開発が短めにされて、タスクの状況が何かしらのツールで機械的に共有される形になるから進捗管理が遥かに楽になる。
いわゆるスプリントってやつだな。
それらが集まって結果的に大規模になるって感じ。
ただやっぱ障害や不具合を出来るだけ減らすって上の思考が変わらないと中々導入はしづらいと思うよアジャイルは。
小さなそれ自体完結した開発単位にブレイクダウンできるような
案件でしか有効ではないような。
>>121
そこもやり方次第だよ。
自己完結って結合テストかシステムテストまで網羅的に出来るかとかまで気にしてるかもしれないけど、
アジャイルも設計とか勿論ある前提だし、
各機能の結合までをモックやスタブ使ってガンガン回して貰う。
→システムテストは別にチーム置いて集まった機能から回していく。
→不具合があればまた起票して複数あるどっかのチームが拾ってスプリント回すの待つ
みたいな感じにやるだけ。
アジャイルって結局単体/結合/システムテストの流れをいちいち各工程足並み揃えたり、品質評価したりせずにガンガン回すだけで、
開発規模はどれにでも対応できるよ。
なめてるとウォーターフォール以上に火を噴くぞ笑
5人しかいない会社に行って
縄張り意識強くてアホかと
君のやってることは越権行為だ！って
辞めたわ
プロジェクトをスプリントを回して、小規模な改修を適時リリースしていくならアジャイルでいい。
例）GoogleがAndroidOSを毎月リリースするならアジャイルでいい。
大きなプロジェクトならウォーターフォールやアジャイルといった開発手法の問題ではない。
例）マイクロソフトがMS Officeの新版をリリースする場合、開発手法の取捨選択は大きな課題ではない。
ウォーターフォールを悪、アジャイルを善とする日本のコンサル的な思想こそが
もっとも時代遅れな思想
現にマイクロソフトはフィーチャー単位開発でパッケージを作っているが
フィーチャー内の開発手法はウォーターフォールもアジャイルも入り乱れている。
狭いIT業界にいると、大規模開発って言ってもMSオフィスとか
その程度のことしか考えつかないのか…
わかりやすい例えに噛みつくのはカルシウム不足だと思うぞ？
1500とかフィーチャーがあれば十分デカいと思うけどなぁ
社畜気味の日本人は向かないというか。
ウォーターフォールの欠点は「川上で決定したことに従わざるを得ないこと」
誤りを見つけて差し戻そうとしても
「担当者は別の作業をしているので無理」
「したがって何とかするのが川下の仕事」
等と言われて改変を拒否されるのがほとんど
そういう改変可能性を含むならアジャイルは意義がある
長いです。
管理人からひと言
現場でも理解できてないのにな・・・・
お役所的なタイプが多い日本人組織ではウォーターフォールはよくないのよ。