【IT】日本が抜け出せないウォーターフォール型の開発と、トップダウン組織構造。経営陣はアジャイルを理解せよ
■ このスレッドは過去ログ倉庫に格納されています
略
【1】経営陣がアジャイルを理解し、企業文化を醸成すること
まず、イノベーション文化を醸成するには、企画・開発が一体化した組織のあり方、現代のソフトウエア文化を支えるアジャイル開発を理解する必要がある。これは、「働き方改革」の文脈で捉えることもできる。エンジニアたちにできる限り自己組織的なチーム運営を任せる。働きやすい環境を与える。ツールやマシンを買い与える。
よく誤解されるが、アジャイル開発は「無規律」ではない。むしろタイムボックスに沿って強く（自律的に）マネジメントされている。定期的な自己改善と計測を行いながら、市場にフィットした製品やサービスを作り出すための、ビジネスとエンジニアリングのコミュニケーション手法である。これを経営は戦略として利用しない手はない。イノベーションは「内的モチベーション」から発生する。世界を変えたい、と思っている人たちに権限と裁量を与えるのが一番だ。
【2】既存の情報システム部門と別に、イノベーション部隊を建設すること
これまでの情報システム部門は、どうしてもベンダーをコントロールして計画どおりの成果を予算以内で作る（QCD）に注力してしまっていた。イノベーションの世界では「つくるべきもの」の定義を、ニーズ探索と小さな製品づくりを繰り返して行う（鶏と卵を同時に育てる）のだから、このやり方ではうまく行かない。
これからは、別途インハウスのイノベーション部隊を新しく組織する必要がある。そこに固定枠の予算をとる。新子会社を作ったり、社長直轄の部署を作ることもあろう。とにかく、小さなチーム（10名以内程度）を、必要であれば複数作る。そして、そのチーム単位で投資する。それをまとめて1つの部署にするのもよい。また、既存事業部署との関係を強くもつチームがあってもよい。むしろ、企業の強みを生かすためにはそうすべきだ。既存事業はその企業の強みであるはずで、そこを生かしながらイノベーションの外部関係を模索して行くのがよい。
また、その部隊は「内製」を目指すべきだ。そのためにはソフトウエアエンジニアが社内に必要になる。まず社内から募ろう。きっとよい人材がみつかる。見つからなくても、外部に単純に委託せず、ともに考えてくれるベンダーと準委任契約することを考えよう。イノベーションは、QCDの達成が目的ではない。ベンダーにリスクを負わせてはいけない。コストや営業力、プレゼンのうまさで選ぶのではなく、ともにアジャイル開発ができるよい人材を持つベンダーを選別し、信頼して付き合える関係を築こう。
【3】イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること
そういったイノベーション部隊を、計画達成度の進捗管理のもとに置くべきではない。そもそも計画できないのがイノベーションである。また、新しいアイデアが10出たとして、そのうち成功にまでたどり着くものはせいぜい1つあるかないかだ。これを計画対比で進捗管理してしまったら、確実につぶしてしまうだろう。ファンドを運営するように、小さな投資を複数に行うべきだ。
そのチームは、開発と企画の一体となった組織横断でつくり、品質保証やユーザー体験（UX）づくり、データ分析部隊も含めて一体化させる。そして生き残っていくものにさらに投資する。意思決定を細かく行い、ステージ管理をして少数のイノベーションを育てる必要がある。
新しい製品やサービスが、既存のシステムと連携することはよくある。いわゆるMode-1とMode-2の連携である。その場合でも、種となる人材を既存部隊から移動し、連携を含めて企画していく必要がある。
従来型のチーム
http://jbpress.ismcdn.jp/mwimgs/0/e/670mn/img_0ef4a34ee6e186426e051cc219a2e4e527741.jpg
DX（アジャイル）型のチーム
http://jbpress.ismcdn.jp/mwimgs/6/4/670mn/img_64de4853d2cd0ac4e69e5634e176042f30479.jpg
以下ソース
http://jbpress.ismedia.jp/articles/-/52264?page=2 納期遅延と思ったら、バンザイ突撃で玉砕した挙句、戦果なしってのは、ジャップランド
の伝統芸。 >>433
・その報告書の作成でさらに遅延
・個人でできる対策なんてほぼないから「死ぬ気で頑張ります」って言う意味のない報告書
もうあるある過ぎてワロえない >>1
金払ってくれるなら、アジャイルでも良いですが、大抵の顧客が改修費渋るじゃないですか 内製ならともかく、外注の場合は外注先の内部でどんな開発手法を
取ろうが関係なく、成果物を納期までにきっちり納めろってこと。 新規システム構築ならアジャイルでいいが、
システム老朽化に伴う全面刷新を一度でやるなら
全機能網羅検証後のウォーターフォールで進めないと無理。 >>443
新規でも、ECサイトみたいなのならアジャイルで機能をすこしづつ
追加ってのもありだろうけど、プラント制御だとか生産管理みたいな
産業用大規模システムには適していない。 >>174
必要なのはITの知識じゃなくて、
システム導入のプロセスには何が必要か、を理解すればいいだけなんだけどね
普段の業務を全て洗い出して評価するとかさ
そういうポイントをちゃんとプレゼンしないSEが悪いと思うよ >>446
あらゆる前提を隠して「簡単」と言った人で
腕のいいプログラマーを見た事がない >>28
>必要なのは十分な予算と時間、どちらが欠けても駄目
そんなものより、作って欲しい仕様をきちんと話せるユーザーだと思うぞ >>447
土方だらけの職場じゃそう感じても不思議じゃないな >>442
契約締結時には納期とシステム名くらいしか決まっていなくて、予定納期の直前になって、
仕様が追加・変更されるんだろ？ いつものこと〜ってか？ 簡単な仕事だからと値切って丸投げしようとするのは、案件紹介ピンハネ会社の営業の
常套手段。 なお、丸投げ先への支払いに限って消費税は内税です。 >>3
機能ごとに適当に安い会社に丸投げした
バグが数千個あるシステムを死んだ目しながら保守したことある
とにかくやすく作らせたもんだから
部品化もしてないし、基盤もバラバラ
開発した側もあんまり金貰えんし
発注元もクレーム対応だらけになるし
保守側も発狂しながら直さなくてはいけない
誰も得しないし、誰も幸せになれない >>443
逆じゃね？
全面改修と言っても、全て作り直すわけではなく、変えない部分、変える部分、追加する部分と
何をどうしたいのか？が、明確になりやすいから、バックログが明確化しやすいし
スプリント毎のタクスもはっきりしやすいから、アジャイルの方が楽かと。 >>455
老朽化対策の場合はハードも利用ソフトも古い場合が大半で、メーカー保守を受けるためにも刷新する。
それに昔のシステムは矢継ぎに機能追加を繰り返して中身がぐちゃぐちゃで読み解いたり機能分割するのも困難なものが多い。
部分置換えを始めようとしても途中で匙を投げる事もある。
割り切れる会社はアジャイルとかウォーターフォールなんて考える事なくパッケージ導入し、業務をパッケージに合わせる方向に進む。 >>456
それは新規システム構築を選択した場合だね。 OSやプラットフォームから変われば、ほとんど作り直しだろ。 オンプレミスからクラウド
とかな。 業務システムだと、導入から10年以上経っているとか普通にあるし。 >>456
企業の導入するソフトウェアって、いわゆる「業務」だけじゃないよ。 結構まともなことを言ってると思うけどな。
特に基幹系データの現場展開とかは、仕様
をまとめるくらいなら、社内チームで試行
錯誤しながら作成した方が早くて安くできる。
特に頻繁にシステム変更があるものは、
内製しかない。
問題は、今までの常識にとらわれて、最初から少しのミスも無いシステムを求めること。まずは小さく作って、次第に完全に仕上げて
いく考え方を経営層が分かってないと、現場は批判ばかりで何も作れない。 整理整頓できれば簡単だよ
ちゃんと整理整頓できればね >>440
よくある夏休みの宿題みたいになってくからな
「完璧な計画だ」→「明日から頑張ろう」→「XX時間やればまだ間に合う」→「写さしてもらおう（ヘルプ投入）」
年食ってもやることは変わらない まともに遅れを取り戻せた事例があったら聞いてみたいｗ >>463
岩田「OK。ちょっとMother2持ってきて」 >>464
そんな開発費話があったのか・・・
でもマザー3は >>465
岩田は取締役開発室長の時まで自分でコード書いてたらしいからな
さすがにチームに組み込まれてたわけじゃなくて、部下から相談されてコード最適化とかアルゴリズムの実証とかを手助けしてた感じらしいが >>468
社長に向いてなかったんだろうなあ・・・ アジャイルって重要な機能から開発して小出しにリリースするって言うけど
機能追加による手戻りでテーブル変更とかあった場合、データ移行も
都度やるんですかね？
最初にテーブル設計を含んで、きちんとした設計がなされていて、
実装することが明確になっていないと、機能追加や修正のたびに
スキーマ変更やらデータの再移行やら、現場が混乱しませんか？
いまいち具体的なことが見えない。 それに契約にしたって、優秀な人材を囲い込んで人月単位でやるっていうけど
そんなことできるSIler っているの？
発注元が直接、外部の開発者を雇ったりしないでしょ？
必ず、元請けがいて、そこからさらに外部に発注する多段階層の構造ですよね？
もし、本当に発注元が直接開発者を雇って囲い込むような状況になった場合
今のSIlerって不要になりませんか？ 生産設備の制御ソフトウェアとかには適用できないね。 >>471
ちょっと書き漏らした。
「発注元」って言っているのは、システムの発注元。つまりエンドユーザ。
エンドユーザが内製するために直接開発者雇ったらSIlerいらなくね？って意味です。 そんなことより140-200時間固定とかいうクソ契約やめろ 内製やれるよ。内製経験者を一人外から呼んでくればよい。アジャイルよりウォーターフォールの方がいいよ。三ヶ月くらいで設計フェーズ、開発フェーズ、試験フェーズに分けて内製メンバーで回せばいいよ。
アジャイルはスプリントを二週間くらいで回すけど、あれやってたら、みんな疲弊して逃げちゃうから。
ベンチャーのほとんどはそれで潰れるし。 >>470
アジャイルの重要な点は｢顧客（又は顧客の要望を完全に理解しているスタッフ）｣を開発チームの中に入れることであって、開発チームは顧客の要望を把握できる状態になることが前提
別の言い方をすると｢顧客は自分が欲しいものを理解している｣｢開発チームは顧客と常に連絡が取れる｣状態を作らないと成功しない
でも、この条件を満たしているなら、別にアジャイルじゃなくてもプロジェクトはうまく回りそうな気がするんだよな… >>471
人月方式では不可能に近い、アジャイルは内部に開発者が常時最低人数いることが前提
アジャイルには既存技術で結果をすぐ求められるプロ方式と、
有能だがフルスタックでない技術者が新技術を学びながら試行錯誤して、誤りをその都度訂正していく方式がある
前者は社内に有力なライブラリーがあるので、技術が変動しないケースだが、全てをスクラッチで
開発できる技量が求められる、リリース間隔は短い
後者は外部ライブラリーを試しながら、試行錯誤しながらメンバー内で得たスキルを共有
しながら回していくケース、リリース間隔はスタブさえも含むので、顧客へのリリースを意味しない
数年間隔で新技術・トレンドが生まれる分野なら後者だが、数十年間ずっとC言語という
ソフトウェア開発なら前者の方が適している >>478
その考え方は良いと思う
継続してお金を払うからこその蓄積技術だよね
いきなり呼ばれて短期間でさあ最高の答えを出せというのはまあ無茶ぶりだわな >>476
こういう奴が問題
実作業をする人間を誰がやっても同じ成果が出せる部品としか見なさない
その癖自分は特別だと思ってる
その認識を生み出すのは結局のところ何をやらなければならないのか
どんな能力があればそれが達成できるのかを考える事すら出来ない思慮の浅さ
簡単に言うと無能 >>478
471 です。返答ありがとうございます
前者も後者も「ユーザ企業自身による内製」が前提のように思います。
そうすると、業務システム開発の現状である「多階層の丸投げ連鎖」とは
まったく別で、「本来のシステム開発のあり方」のように感じます。
アジャイルの「数サイクルに分けて小規模リリースを行う」の部分を
「数サイクルに分けて顧客納品して、顧客に出来ばえを確認、課題の洗い出しをしてもらう」に
変えて考えれば、現状の「多階層丸投げ連鎖」でもいけそうに感じます。
契約は１サイクルごとで、業務の現場にリリースせず、あくまでも顧客のテスト環境に
リリースします。（よって、スキーマ変更などに伴うデータ移行や画面変更などに伴う
オペレータへの再教育もなくなります)
ただし、技術の蓄積などはできず、スパイラル開発のようになりますが。 つづき
そうすれば、ユーザテストの段階になって、「こんなんじゃ使えない。」「イメージと違う」
ということは軽減できると思います。
ただ、スピーディなシステムリリースではなく、従来型の開発の改良した１形態になるだけです。
これなら SIlerもピンハネ専門会社も生き残れます。 開発形態の「大改革」ではなく「ゆるやかな改良」であれば、
顧客も我々開発側もなんとかついていけそうです。 http://agilemanifesto.org/iso/ja/manifesto.html
「プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。」
1. Highest priority is customer(market) satisfaction
2. Welcome changing requirements
3. Frequent delivery of software
4. Business people & developers cooperating daily
5. Build projects around motivated people
6. Face-to-face conversation is best
7. Progress measured by working software
8. Sustainable development pace
9. Continuous attention to technical excellence
10. Simplicity
11. Self-organizing teams
12. Regular reflection & adaptation
- Pair Programming
- Test Driven Development(TDD)
- Refactoring/Emergent Design
- Continuous Integration >>408
今までの負の資産を一層できる機会でもある。 コンサルタントが新たな稼ぎ先を得るために煽ってるだけ ■ このスレッドは過去ログ倉庫に格納されています
