【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 >>325
プラントとか航空機とかの制御ソフトウエア開発には使えない技法。 そもそも、
アジャイルとかいう訳の分からん単語をそのまま使ってるから日本のITは駄目なんだよw >>337
それはその通りなんだけど、アジャイル＝ボトムアップではないよ。
アジャイル＝ボトムアップ×機能横断だから。
日本の企業ってボトムアップではあるけど機能横断ではないでしょ。
開発するときに生産やマーケや営業の人とチーム作ったりはあまりない。
開発は開発って感じでしょ。 >>333
進歩の早さについて行くノウハウがあるんだよ >>336
面白いなあ
下町なんとかはウォーターフォールの枠をガチガチに固められてて軌道修正が出来なくなってしまってる >>342
じゃあ、建築みたいなちゃんとした構造計算とか見積もりの手法がITにあるとでも？ >>338
うん、
組み込みや、高いレベルですり合わせが必要なハイパフォーマンス系、医療やエンプラそういうのにも向かない
基本的にはアジャイルはウェブサービスを前提として、サービスダウンはある程度かまわないというところでの話だよ >>300
サイマルテニアスエンジニアリング
フロントローディング
コンカレントエンジニアリング
こういう言葉を聞いたことがないのかしら？ >>343
スキー板の方は、ユーザとメーカーが共同で、半分趣味で顧客に合わせて板を作ったら大人気という。
元々スキーメーカーですらないから、より横断的な組織で製品が開発されたのが凄い。 >>345
Agile Medical Device Development
https://www.slideshare.net/Zuehlke/agile-medical-device-development-55893571
4. Creating innovative products all the way from the concept phase, through development
and into mass production. • Developing bespoke software solutions which combine innovation
with stability and link business with software. • Bringing experiences gained in many different
industry sectors and disciplines. • Using tried and tested development processes
5. in feasibility and system design phases – with a cross-functional team – electronics, mechanics,
software, microfluidics, optics, simulation, etc.
8. Act pragmatically! Fail early! Think and act in system context! Talk, discuss, and ask!
Learn and adapt! Think positive! Don’t make assumptions! Drive team success! Define System-DoD!
Draw a common picture! Act proactively! >>1
アジャイルを遵守すべき規律とするよりも、現行のシステムをアジャイルに近づけるという考え方が米式だと考えるが
How to develop medical device software with agile methods? - Part 1
http://blog.cm-dm.com/post/2012/05/12/How-to-develop-medical-device-software-with-agile-methods
A solution is to spend time of the first stage to software specifications, architecture design
and (a bit of) detailed design. This first stage is consacred to the reflexion on the functions,
the architecture and the design. Developers may (and will) write sketches of software but
this remains a low percentage of activity.
The SRS, STP, SAD and SDD should be almost 100% finished at the end of the first stage.
Software in Medical Devices - waterfall development repeated n times, with first and last
iterations that are modified Then the iterations begin, of 3 months each. They stem from
the results of the first stage to implement sequentially the software requirements in each
iteration and the tests cases. So only the SDD and the STD are updated at each iteration.
Others documents should remain unchanged or be slightly changed to match the small
changes in software requirements and design.
During the last stage, the whole software is verified, last bugs are fixed and the software
is validated.
このような改善型方式でも内製でないと難しいだろうから、外注・請負型は不要、阻害要因となる アジャイルと近いシステムでも外部に発注するのは現実的でなく、内製が基本となる
https://ja.wikipedia.org/wiki/DevOps
アジャイルソフトウェア開発・継続的デリバリーとの関係[編集]
アジャイル[編集]
DevOpsの概念はアジャイルソフトウェア開発といった概念とも関連している。
ただし似てはいるが、方法は異なる。アジャイルソフトウェア開発は考え方と学
びを変えることが組織改革につながるという手法であり、DevOpsは組織改革を
強化することで目標を達成する手法である。[7] 小さな変更を頻繁にリリースす
ることの多いアジャイルソフトウェア開発においては、開発担当者と運用担当者の
連携を密にする必要があり、こうした開発手法の普及とともにDevOpsの考え方が
広まることとなった。アジャイルソフトウェア開発が拡がるにつれて、リリース回数
が増加する傾向のなかでDevOpsが開発された。
DevOpsの目標の一つは、より信頼性の高いアプリがより早く頻繁にリリースされる
環境を作ることである。この目標を達成するために、リリース管理者は継続的な
デリバリー方法を取りながら、アプリケーションリリースの自動化や継続的な
統合ツールなどを利用し始めている。
DevOpsに関わる多くの考え方や関係者は、エンタープライズシステムの管理とアジ
ャイルソフトウェア開発の潮流のなかから生まれた。 https://www.mckinsey.com/~/media/mckinsey/mckinsey%20solutions/numetrics/resources/insights%20on%20%20medical%20devices%20numetrics.ashx
Adoption rates of Agile processes and methodologies also lag the hightech segment
医療機器では４割がアジャイルの導入、5割がアジャイルを限定的に導入、1割が非アジャイル
ハイテクでは3割がアジャイルの導入、5割が中程度で導入、2割が限定的に導入、0%が非アジャイル >>1
>>345
防衛・航空産業でもアジャイルは導入されている
USAF’s Pawlikowski: DoD Use of Agile Software Development ‘Critical’
https://defaeroreport.com/2017/07/27/usaf-pawlikowski-dod-agile-software-development-critical/
Gen. Ellen Pawlikowski, USAF, commander of US Air Force Materiel Command,
discusses agile software development’s criticality to the work of both the US Air
Force and US Defense Department — especially in the face of rising weapons-systems
software costs — and barriers to its implementation during the Mitchell Space
Breakfast Series’ “Keeping a Decisive Edge — Agile Software Development in the
USAF” event, presented by the Mitchell Institute for Aerospace Studies on July 14,
2017, at the Capitol Hill Club in Washington. >>339
でも機敏開発とか言ってもどうせわからんし >>1
（米政府は開発者を直接雇用して内製するのが基本で、外注は内部のリソースで手に負えない場合）
国防（防衛）省（DoDの直訳は防衛省）での契約は固定・定額と実費償還契約の2種類があるが、
国防省は両方の契約でアジャイルに対応できると主張している
プロジェクトに不確実性があり見積もり額が明確にできない場合や、強引に見積もりをすると
信じられないような多額になる場合が適当だろう
https://www.gao.gov/products/gao-12-681
Why GAO Did This Study
Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011.
However, long-standing congressional interest has contributed to the identification of numerous examples of
lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related
outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends
modular software delivery consistent with an approach known as Agile, which calls for producing software in
small, short increments. Recently, several agencies have applied Agile practices to their software projects.
Accordingly, GAO was asked to identify (1) effective practices in applying Agile for software development
solutions and (2) federal challenges in implementing Agile development techniques. To do so, GAO identified
and interviewed ten experienced users and officials from five federal projects that used Agile methods and
analyzed and categorized their responses.
米政府は開発者を直接雇用して内製するのが基本だが、繁忙期や内部技術者（公務員）に特殊な技術であれば
外注することはある
アジャイルはコストを下げるための有効な手段の一つではある >>1
>>356 は完全なアジャイルの導入ではなく、部分的か中程度の導入となるだろう
>>351 のようにアジャイルと他の開発手法を組み合わせた独自方式を考案するにしても定額契約では限界がある
政府機関での試みは興味深いが、アメリカは内製が中心で、外注は繁忙期の手伝いが多いことも念頭
にいれるべきだ
アジャイルは組織で独自の枠組みを作ってこそであり取り捨ては当然しないといけない
大小差はあれどアジャイルを導入している企業が大半だろう ピンはねSIerとIT土方にアジャイルは無理だっての プロジェクトの規模と、メンバーの質の平均は反比例する >>1 >>358
大半のSIerには内部にプログラマーがいないので、組織構成の視点からはアジャイル開発ができないだろう
多重下請け外注では、アジャイルの真似事さえできないはずだ >>360
だから下請けじゃなくて企業がある程度フレームワーク作って簡易設計で動かして理想を追求してから膨大な、作業を下に流せば良いのでは？
なんで企業主体で開発出来ないの？それじゃ企業が中抜きしてるだけで存在意義がなくないか？ 抜け出せないのはトリクルダウン期待からだろう アベ まだウオータフォールでやってんのか
ダメだってわかってるはずなのに 別に、ウォーターフォールが悪いわけじゃない。 上流からキッチリと仕様を決めてかかる
前提なのに、途中で仕様がコロコロ変わる、ウォーターフォールとアジャイルの悪いとこ取り
したのが、日本の開発手法。
んで、ゴールも決まってないのに、進捗率を聞いてくる。 >>118
> 顧客や世界のニーズを「自社で管理」出来る企業ならそうだな。
> ウォーターフォールだと顧客が終盤になってから物を見てコレジャナイとか言い出すから、アジャイルなんだよ。
そんなん俺だって業界人だから知っとるがなw
しかし顧客のニーズを自分で管理できないなら全て終わりやろ。
> DDDでググれ。
ぐぐったよ。抽象レイヤーのマネジメント論やんか。
だからこれができるなら、顧客から要件も聞きだせるし、整理して確認もとれる。
アジャイルだろうがなんだろうが、
関係者が要件とその工数感を把握してなきゃだめだとワイは思うがな〜
無茶な要求言ってくる客も無知だからそうなるわけで、ちゃんと対話すれば大概大人しくなるぞ経験上。
通じないからって結局妥協するのにアジャイルという言葉を使って欲しくないで。 大規模プラントの制御するようなソフトウエアをアジャイルとやらで開発できるの？ >>364
使用きっちり
その前提はまず成り立たない IT屋って、ITがすべてだとか、ITでなんでもてきるとか、
わけのわからん思い込みがある。ITなんて道具に過ぎないのに。 駄文極まるがこればっかりは事実だしなー。
いやウォーターフォール型が一概に悪いわけじゃないけど今の多重下請構造はこう言う偉そうな奴がお上でも動かしてくれないと延々駄目な気がする。 アジャイルは少人数しか旨味がないってアジャイル教教祖が言ってるでしょ
なんで全部右向け右で煽ってるの？ >>371
さらに言うと、｢少数精鋭｣に向いたやり方だと思う
ただ、大抵の会社の場合、｢10人のエースを小型プロジェクトに集中投入する｣みたいなのは贅沢過ぎて出来ないと思うわ
エースが10人いたら、複数のプロジェクトの中核メンバーとして分散して使おうとするだろうし、会社の利益的にはその方が良くなる
逆に、並の人材レベルでアジャイル開発したら、たぶん統制が取れなくなってひどいことになる 経営者がたかがソフトウエアの開発の手法なんて理解する
必要はないでしょ。 何をもってアジャイルというのか知らんが、
ドキュメンテーションをわりと二の次にしてよい、という意味なら
生産性高いかもね、とは思う。
一般的にはデジタルゼネコンとして分業させる段取りの部分で
多くの労力を使うので。 契約と規則に則ったコンプライアンス意識の高い会社なら
経営そのものがほぼプログラムのようなものだと思うけど
必要ないって言っちゃうなら、そうじゃない会社って事だろうな。 >>332
ソフトウェアの業界用語なんだから問題ないだろ
無理やり日本語に置きかえたら逆にわかりにくい 最初に緻密な設計さえされていればいろんな開発手法取れるけど現状じゃ厳しい 日本の江戸時代だって、町方の中村主水さんとかは例外的に
現場仕事やってるけどさ、ほとんどの役人は書面だけで仕事したこと
にしてるだろ、んでウォーターフォールモデルみたいな上意下達
でも、杉良太郎さんとかの与力とか八州とか言われた十手持ちは
書類とか関係ない現場ばっかだよ、そんなのもアジャイルに近い
日本のむかしはそんなの役人と民間に別れてともにやってただけじゃ？ >>376
ソフトウェア業界の人にしか分からんやん マツダは、良いか悪いかは別として、今まで経営陣が、銀行と外国企業の下請けだったから、
マルチプラットフォーム開発が得意で、社内の開発手法も、アジャイル寄りとよく報道されてるな。
開発者個人的な研究も割と自由らしいし。 松田は一族経営で小説が出たほど問題だったじゃん
良く成っても豊田も一族経営で真似はじめてて危ないんでは >>373
たかがじゃないよ
組織の在り方が関わってくるんだから ソフトウェアの勉強もセックスも同じ
Machineがmachineを造ると滅ぶで、まともにさせてくれたことは無い
原因はだんだん分かってきたが 日本のエクセラーしかいない下請けドカタ構造じゃアジャイルは無理よ
ITは大手企業を切り離して見捨てない限り何も出来なくて滅びるだろうねw >>1
無理大企業では無理それらの子会社どもも無理
Slerでは無理
変えようとしている中小の有能会社よ日本ベンチャー軍団よいかに大企業の汚物団たたかれようと開発の革新だけは止めるなよ とある大企業ではアジャイルを導入したといきって発表していたが実は設計だけで
開発は外に丸投げという摩訶不思議なことをしているらしい
依然と何が違うって？
カタカナの名称をとっかえただけなのです 言っておくが、日本のウォーターフォールは、ウォーターフォールですらない
欧米でウォーターフォールと言ったら、日本で言うところのスパイラル開発に近いものを指す >>387
わかる。
日本はまず構造化やオブジェクト化が下手くそすぎて、担当間コミュ障起こして小回り利かないからすごく静的なものになる。
全体統括できる人材がおらんからそうなるんだろうな。 開発手法ばかり取り上げられているけど、スパイラルにしてもプロトタイピングにしてもアジャイルにしてもそれを実現するための基盤づくりがなってないと話にならない
日本の企業の大多数はそもそも少数「精鋭」っていうのを用意できないんじゃないかな？ >>391
建前は全員ガンダムな組織運営だからねw
「精鋭」と称して集められた部隊が意識高いザク部隊なんてザラだし。 >>391
腕の立つプログラマーがあんまりIT業界に行かないという事情もあるしな
大学時代に情報系の研究室に所属してて、神のようなスキルの先輩がいたけど、IT業界に行かないどころか国I受けて公務員になってしまった
今は趣味でオープンソース界隈に多少の貢献を続けてる程度で、仕事は技術とは全然関係ないらしい
俺も就職先は自動車メーカーだし、同じ研究室に同期が6人いたが、いわゆるIT系に行ったのは、NTTの研究所と某鉄鋼系SIerに行った2人だけ
なんというか、適性のある人をちゃんと捕まえられる程度に待遇を上げとく必要があるんじゃないか？ >>388
日本の企業の多くはPDCAサイクルを回せてないけどな。
PとDだけやって、改善できたつもりになって、CとAが疎かになる。
その結果どうなるか？
改善策をフル装備して、余計に無駄の多い重量過多業務になる。
きちんとCとAまで回さないなら、PDCAサイクルは、回さない方がマシですらある。 IT業界＝プログラマーとか、どういう思い込みだよ。
建築業界が全員土方と思っているくらいばかばかしい話。 フレームワークが全方位的に最初から完璧でなくてもよくて
やっぱり、あれがたりねーや、引数もっと必要だった、という設計変更にいちいち怒ってても仕方ないのではないかと。
なんにせよ、多人数でプログラム組み立てるというのは
面倒なことだね。 >>392
新卒を教育せずザクに乗せて「ガンダムに勝て」と喚くのがリーダーの仕事だから
「シャアならできる」から簡単だという認識だからねｗ >>379
ソフトウェア業界の人向けの記事でしょう アジャイルだと、できる人間がその人月単金のみで囲い込まれるのが現状だと思うのだが、SIer各社はどうやってるんだろう。
これこそが、国内でアジャイルが普及しない要因だと思っているのだが。 ソフトウェアにも色々あって、WebベースのUIをウォーターフォールの塩漬けで開発すると、
IE向けに一度品質チェック済んだUIはIEだけサポートで、
上流からの仕様変更が無いとChromeもEdgeも未サポートとかなったりする。 一方で、銀行間の出納処理とかをセキュリティ対策かなんかでライブラリが新しくなったから仕様をオーソライズしないでチャッチャと変更とか危ないし。 20年前におんなじ事言ってたな
何も変わってねえって事
衰退するわけだよ、この国が 別にウォーターフォールで良いと思うよ。
ただ、条件は客もベンダーも合意事項を絶対守るって事だな。 >>403
Webベースとか関係ないソフトウエアが大量にある。
プラント制御とか金融系とか。 金融はなぁあ…
ブロックチェーンでコストが削れるって大銀行が息巻いてるけど、
あれってホスト狙い撃ちににして大リストラするって死の宣言している状態なんだが大丈夫か? >>403 あーあるある。うちの得意先、１０社くらい「自社のwebEDI｣持ってて
中には対応ブラウザはＩＥ６まで、しかも聞いたこともないミドルウェアプラグインを入れさせられて
しかも運用ルールが「今日注文するか、１年後に注文するかわからんけど毎日見なさい。
もし出荷漏れしたら罰金ね。あ、webEDI利用料として売り上げの１０％天引きして支払うから。
だって、ＩＴ化でおたくら楽になるでしょ」
だったりする。
なまじ取引先が大きい会社だとＳＥ部門がこのような中途半端な開発するので、非常に迷惑。 IT業界の人ってもしかして、みんな凄く頭いいの？
凡人の俺には全く理解できないわｗｗｗ >>410
心配しなくてもみんなよくわかってない状態でなんとなく会話してるだけ
そんなアホなって思うだろうけど結構マジ
案件も似たような感じで進んで実際に実装する段になってデスマになることが多々ある この記事↓だれか、このビジネルnews+ 板にスレ立てしていただけないかな。
【IBM】またもやらかした。27億円超の損害賠償【文化シャッター】
https://fate.5ch.net/test/read.cgi/fakenews/1518521480/
> 両社は当初、アジャイル開発とウォータフォール開発の併用によるシステム構築を目指していたが、
これ、関係者から話をきくと、IBM はほとんど詐欺みたいなことやったらしいね。
アジャイルもウォーターフォールもIBM側の担当者はだれも理解してない。
口先三寸の営業が、話を盛りまくっただけという ウォーターフォール自体もできてないと思う。
人海戦術の無規律状態じゃね？ 抜け出せないのは、ウォーターフォールが麻薬だから
中抜きして拝金出来るし、産業構造的な『下』の人間が居るから、マウンティングやイジメも出来て楽しい
ウォーターフォールは、性格の悪いクズ向け、階級はあって然るべしと考えるクズ向けの方法で、
自身の社会的立場＝階級を保全するためだけの階級再生産装置が、IT業界のウォーターフォールだ
アジャイルは、逆に、自由と平等が謳われている国でしか上手く運用できない
なので、自由と平等が根柢にあるアジャイルという方法論は、日本という階級社会では機能するわけがない
日本では、階級の再生産が社会の目的そのものだからだ
階級からの脱却・「階級」の対象外、という意味では、逆に、インドはカースト外のIT業界に行く人間が多くて、それと理屈は同じだ
日本では新産業だったIT業界が瞬く間に階級再生産の機構に汚染されて、業界全体が階級再生産装置に成り果てた
つまりは、制度化された階級再生産装置がウォーターフォールで、その国が階級社会ならとても親和性が高い
だから日本はウォーターフォールを止められないし、止める理由もない
それを続ければ続けるほど、階級を再生産出来るからだ ものすごい優秀な設計チームとマネージャーの下で土方してみたい。 >>414
実装無理な設計を指摘しても「お客様の要求」の一言で突っ走るからなぁ
この業界から足洗いたいけどどこ行っても変わらんか くだらんレスばっかり
なんちゃってPMの方々、お疲れ様です 今の現場、PMが進捗管理に必要と言って午前、午後、終業前の三回進捗報告をさせられて、
流石に業界から足洗いたいなと思ってる今日この頃です。 >>423 ４時間で進捗しないでしょ。
それとも１万人くらいで一斉にビルドしてるのか。 ウォーターフォール型と銘打っても
受け入れテストで要求仕様が発覚する
疑似アジャイル型開発となっております >>423
進捗管理とかクライアントへの報告にパワーの大半を割いている現場
あるねえ、どことは言わないが >>423
以前入ったNTT関連の偽装請負だと、開発を受託していたSRAのプロマネが、1時間
ごとに進捗を聞きにきやがったぜ。 たぶん、世間的にはいまだに古参の中堅SIerと
認識されているらしいが、もはや中身はカラッポの丸投げ屋だ。
ちなみに、まだ横浜にSRAの開発センターがあった時代。 会社が正社員として求めている人材は思考停止して言われた事に
疑問を持たず受け入れてくれる従順な人間なので無能で構わない
会社の方針に疑問を持ったり、上に楯突きそうな人間はいくら有能
でも採用したくない
これが有能な人ほど正社員として採用されづらい原因
だから、面接では無能を装った方が成功率が高いのである >>422
それ最初アジャイルもやろうとしてグダグダになった奴だろ w 散々進捗聞いてきて「遅れてます」って言っても
なんらかの手が打たれることはないのは
気のせいだろうか。 >>425
あるあるだなｗ
結局開発プロセスではなく、PMの腕次第なんよな。
受け入れで要求仕様が発覚した時に、追加費用と工数を要求できるだけ
過去のエビデンスを残しておいたり、プロジェクトの経過を理解できてればいい。
重要度の低い実装とのトレードやら、なんでもアリ。
もしくは、何でも受けてしまい自社がいないと回らなくしてしまうのも手。
どの手でどう進めるか？がPMの技量 >>430
うちは進捗で遅れてますって言うと
進捗遅れの原因と、その遅れを(個人で)どう取り戻すかの
報告書の提出が求められるよ。 アジャイル開発とか顧客との契約はどうするの？
ウォーターフォールなら、要件定義の成果物でいくら、
基本設計の成果物で．．．とかあるけど
アジャイルの場合どうよ？ >>434
アジャイルって内製開発での手法なのでは？ >>434
人（工数）を買う感じかな。あとはその工数を使って優先度高いところから仕事やってもらえばいい。 アジャイルとほざいているのは、まともに仕様もきめられない連中が丸投げを正当化する
ために唱えているだけで、納期厳守とか進捗管理を誰がどうやってやるつもりなのか
問い詰めたいね。 まぁ、PM補佐なんて役回りさえ、偽装請負や派遣で募集しているから、
そいつらに丸投げするんだろうな。 >>436
アメリカなんかはもともと納期遅延のリスクを発注側も負う契約形態が普通だから、アジャイルの考え方が浸透しやすいんだろうな ■ このスレッドは過去ログ倉庫に格納されています
