IPA、「海外における非ウォーターフォール型開発の拡大」に関する分析結果を発表 76
ストーリー by hylom
日本ではどう？ 部門より
日本ではどう？ 部門より
あるAnonymous Coward 曰く、
システム開発と言えばいまだウォーターフォールが多い日本だが、IPAが6月11日、海外でのアジャイル型開発の拡大を分析した報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」を発表した。
この調査は日本のソフトウェア産業の強化を目的とし、欧米におけるアジャイル型開発の普及要因を明らかにすることを意図して行われたもの。アジャイルが普及している各国ごとの要因として、米国では「ユーザ企業にIT技術者が多く、内製化率が高い」、ブラジルでは「米国からのオフショア・受託開発が多く、また国内でもアジャイルにおける成功例が認知されている」、デンマークでは「政府調達においてアジャイルが推奨されている」といった点が上げられており、またIT技術者の評価が高く流動性も高いため、知識が業界内を伝播しているといった分析がなされている。
一方、こういったアジャイルが普及している国においても「IT部門によるアウトソース」、「大規模プロジェクトやコンプライアンスがクリティカルなシステム」、「レガシーシステムの拡張」といったケースではアジャイルが普及していないという回答も載せられている。
報告書では日本でアジャイル型開発を普及させるための施策として「ユーザー企業で内製化を行う」「国や自治体が調達でアジャイルを用いる」「リアルタイムでコミュニケーションがとれる環境を構築する」「成功事例を世間に広める」といった提言をしている。日本においてもアジャイルが主流となる日は来るだろうか？
日本企業でアジャイルは無理 (スコア:2)
今や外資系ですら縦割り構造が浸透しきっている現状で、
今さらアジャイルとか言われても昔からいるオジサン達が困る以外の変化は見られないと思います
＃概要設計、基本設計、機能仕様から運用マニュアルまで紙で提出、判子で承認とか、もうね
Re:日本企業でアジャイルは無理 (スコア:1)
アジャイル開発が適した開発案件が無いのだから、無理にやる必要無いです
趣味のオープンソース開発と業務の開発の区別が出来ないお馬鹿さんたちが増えるばかりじゃしょうがない
Re:日本企業でアジャイルは無理 (スコア:1)
# 概要設計、基本設計、機能仕様から運用マニュアルまで紙で提出、判子で承認とか、もうね
これ自体は別にアジャイルとは矛盾しないと思いますよ．
ただ，それらの提出の規模が大きいから矛盾しているように見えるだけです．
プロジェクト単位とかでやっていたことを，
機能モジュール単位でやるだけでアジャイルが適用できると思います．
承認する人の等級も落せばうまく回るように思いますよ．
Re: (スコア:0)
無理やり既存の枠内でやってるけど、品質保証部に提出する情報との辻褄合わせが辛い
テスト工程以前のバグの扱いをどうしたものか、いつも悩む
# 一応、大手です。。
Re:日本企業でアジャイルは無理 (スコア:1)
テスト工程以前を抱えているセクション vs. QAセクション の利害の反する各サイドでは現状を認識した上でどう改めるべきだと考えているのでしょうか?それとも寝た子は起こすなという上からの業務命令の優先順位が強すぎて身動きがとれないあがきを甘受しつづけるのでしょうか?という一点に興味があります。
// 現状の辻褄合わせを指弾するつもりはない。するだけ空回りするから。何をするにも金が余計かかるがない袖は振れないという答えを半ば予想。。。。
Re: (スコア:0)
一度品証からアジャイル開発に関するひどい指針が出てきた時点であきらめました
寝た子は起こすな的方針で、変な管理されるよりは現状の辻褄合わせの方がマシと判断してます
# 一応、厳密なウォーターフォール型じゃないことについては、調整済
上の方が、たまたま理解のある人たちなんで成り立ってる状況なんですがね...誰かが入れ替わったら終了の予感
報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:2)
エライ人に資料見てもらうためには、表紙めくって最初の3～5枚が勝負だろ、普通。
（エライ人がかいてるから、若者は全部見ろ・・と思ってんのかいな）
結論が一番最後・・というか全66ページの40ページ目って、見てほしくないのかね、と小一時間。
まあ内容としてはそこそこ興味深いと思いましたが。
ユーザー企業もある程度内製できる（開発ベンダーと一緒にモックアップ的なものを
作るくらいの） スキルがあってもいいのではと思う今日この頃です。
そうでないと業務に即したシステムつくるのは業務を熟知したベンダーになって、
そのベンダー（担当者）ロックインになってしまうわけで。
ただ、ユーザー企業のコミットが増えてくると、困る会社／人たちが出てきますので
その辺がロビー活動をしたり、と。 世の中混沌としてるなぁ。
Re:報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:2)
Re: (スコア:0)
IPAのエライ人が泥十年とか言う人ですしな
Re:報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:1)
その人末期がんの末に自殺したんだよな
Re:報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:2)
うわ、ほんまや。
泥に返ったか。いや、土か
Re:報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:1)
研究者とかに資料として読んでもらえればいいんじゃないかと。
そういった人達には途中の経過とかも重要だから, これでいいんじゃないかな。
目次もついているから, とりあえず結論見たければそこにいけばいいんじゃないかな。
理解が深まらない人に, 至極単純化した結論だけ読まれて, 個別のケースについて勘案せず, それだけが絶対の正義であるかのようにわめきちらされる方が, 自分は迷惑。
Re:報告書なら最初にエグゼクティブサマリーを書いてほしい (スコア:1)
一般的に論文って, 表題とアブストラクト(数行, 10行は超えない)を読んでダメなら残りは読まれませんよね.
アブストラクトって何? なんて言っている人が書くようなものは論外.
アジャイル型の普及は (スコア:1)
下請開発会社の衰退とセットですよ！
みんな分かってるよね？
Re: (スコア:0)
そういうことね。今の日本のIT業界の構造やビジネススタイル、IT技術者に対する一般社会の意識、そしてユーザー企業の仕事のやり方まで含んだ大改革でもない限り無理。
そして下請開発会社にしかは入れないレベルの人にはIT業界から退場してもらうしかないけど、今や行き場は無いしね。
Re: (スコア:0)
いやむしろSIerの衰退とセットと思ってもいいくらい。
だから日本だと日本企業全部が滅ぶ方が現実的かもしれない。
テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない (スコア:1)
一方で
「テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じないと。キ－マンズネット調べ」
http://www.publickey1.jp/blog/12/8585.html [publickey1.jp]
http://www.keyman.or.jp/at/dev/debug/30004610/ [keyman.or.jp]
まあ絶望的だね。
要するに１０年遅いと。
Re:テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない (スコア:1)
そのページ、だいぶ偏向ですよ。
>情報システム部門が全体の33.3％、一般部門が36.9％、ベンダ・SIerが29.7％
に対して「テスト自動化ツールは導入しているか」と聞いての話なので
開発じゃない部分のほうが多いようなアンケートです。
Re:テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない (スコア:1)
それを込みにしても、低過ぎるという結論については何も変わらない。
開発部門じゃなくても「テストがイラネ」なんて人がいても良いわけじゃない。
いやむしろそういう人がいるからこそ、日本でのアジャイル開発が絶望的なのです。
Re: (スコア:0)
なんというかうん、絶望的だね
絶望的であることを望んで文章読むような人が声を張り上げてるだもん
テスト「自動化」ツールの話なのにいつの間にか「テストがいらね」なんて読み変えてるし…
Re:テスト自動化ツールを導入済みは8.5％、85％以上が検討していないか必要を感じない (スコア:2)
＞テスト「自動化」ツールの話なのにいつの間にか「テストがいらね」なんて読み変えてるし…
うーんと、今の時代に単に「テスト」っていえばまずは「自動テスト」でしょ。
＞＞開発部門じゃなくても「テストがイラネ」なんて人がいても良いわけじゃない
は「開発部門じゃなくても「（自動）テストがイラネ」なんて人がいても良いわけじゃない」と読み替えて下さい。
＃そんなことに説明が必要だとは思わなかったわ。
この時代に
「（自動）テストなしに全部「手動テスト」でやる、それで構わないと思ってる人がいる」
というのはとても絶望的なことなんですよ。
こんな回りくどいことしないで， (スコア:1)
「日本においては IT 産業は完全に失敗した」って引導を渡してくれたほうが早いと思う．
正直言って，なにからなにまで間違っているとしか思えない．情報の結合と構築がソフトウェアの肝なのに，情報のやりとりが疎になるばかりの下請け孫請け構造ってうまくいくはずないじゃん…
ウォーターフォール vs スパイラル (スコア:1)
すべき論。 (スコア:0)
そもそもアジャイル型というのが本当に普及しないといけないんですかね？
誤解に基づくニーズ (スコア:3, おもしろおかしい)
だってアジャイルなら、いくら仕様変更しても追加料金かからないんですもの。
Re:誤解に基づくニーズ (スコア:2)
そして延々と追加要望に対応する日々←今ココ！
Re:誤解に基づくニーズ (スコア:2)
Re:すべき論。 (スコア:1)
ありふれた「○○と似たものを作る」場合ならば、
最初からハッキリ見えてるのだから一本道なトップダウンでやればいいし、
革新的すぎて「モヤモヤっとしか完成形をイメージできない」場合ならば、
最初から正解なんて出せっこないのだから反復的にエクストリームでやればいいし、
こんなの、何でやるべきかは、どんなタイプのもの作るかによりけりだと思うわ。
「革新的でモヤモヤしたものを、一本道で作る」とか、そんなのなら無茶だとは思うけど、
たぶん、結局みんなバカじゃないので適切なタイプを選択してるだろうし、
「アジャイルしてない、遅れてる」的な忠告は余計なお世話な気がする。それが向いてれば選択するだろうから。常識的に。
Re: (スコア:0)
それはCOBOLerが
「本当にXXX言語を使わなければダメなんですか？COBOLじゃダメなんですか？」
と言ってるに等しい。
いつまでも古くて非効率で失敗だらけの方式を使い続けると、
遅かれ早かれ性能的金額的品質的に他国との競争に敗北する。
Re:すべき論。 (スコア:3)
COBOL がダメなのは確定事項でしょうか?
ダメなことが確定だとして、アジャイルがウォーターフォール
よりも良いのは確定事項でしょうか?
どうせダメなんだから、良いか悪いかに関わらず手法を変える
というのも悪い方策では無いかもしれませんが、"非効率で失敗だらけ"
(古いこと自体は悪いことではない;-) であることを説明できなければ
"競争に敗北する。" という結論は前提が崩れますね。
きっと、ケースバイケースなのではないでしょうか?
# まぁ、アジャイルとウォーターフォールの違いも分かってないですし
# プログラミング言語の "良さ" を理解できるほどの知識もないのですが。。。
Re:すべき論。 (スコア:2, すばらしい洞察)
＞ウォーターフォールがダメでなのは確定事項でしょうか?
＞COBOL がダメなのは確定事項でしょうか?
どちらもＹＥＳ。
＞ダメなことが確定だとして、アジャイルがウォーターフォール
＞よりも良いのは確定事項でしょうか?
アジャイルが『銀の弾丸』にはならないけれど、ほぼＹＥＳ。
＞きっと、ケースバイケースなのではないでしょうか?
違いが分かってない人ほど、こういうことを言うなあ。
ウォーターフォールの方が良い場合。
・外注に丸投げする無責任開発
・ＳＩビジネスで多重下請け構造
・車輪の再発明的なリスクの少ない開発であること
・低スキルプログラマを百人単位、時には千人単位で投入できる。
・サービス残業させられる
・お金に糸目をつけない。スケジュールがどれだけ遅延しても構わない。
まあウォーターフォールでも良いような開発って、組織として腐ってるし終わってるよね。
Re:すべき論。 (スコア:2)
違いが分かっていなくて申し訳ないです．
元々の問いは，”アジャイルが普及しなきゃいけないのか？” なわけで
なぜアジャイルを普及させることが当然正しいという流れになっているのか？
っていう疑問だと思うのですが，その答えを ”YES” で返しているように
思えるんですよね．．．
それじゃ，議論になっていないですよね？って言うのが元のコメントの意図
なんですが．．．
# なぜ と YES じゃ，噛み合っていないですよね？
好きな物を好きだと言うのはとっても良いと思うのですが，なぜ好きかと
聞かれたら，なぜかを答えてほしいなと思います．
ところで，開発と組織，腐ってたり終わってたりするのはどちらですか？
まぁ，開発が終わってたりしたら，お家に帰ってオヤスミナサイですかね ;-p
また，場合について書いてありますが，この条件は and か or のどちらでしょうか？
そういった疑問はいくつかあるのですが，気分は分かった気がします．
# フレームの元ですね．．．m(._.)m
> ・外注に丸投げする無責任開発
> ・ＳＩビジネスで多重下請け構造
wikipedia で見た程度の知識で考えると，工程管理をしない or 出来ない，
っぽいのを想定されてそうなので，失敗する条件に見えますね．どちらの手法でも
後半は失敗を許容するという条件でしょうか．．
そんな時なら，どんな手法でも良いので，ウォーターフォールである必要もなさそうです．
むしろ，管理者の名前が表に出てしまって，うやむやに出来ない気がします．
Re:すべき論。 (スコア:1)
ウォーターフォールが問題点の多い開発手法であることは事実だけど、
アジャイルがその問題点を解決しているわけではない。
アジャイルは大規模開発には向かないし、製造をオフショアに出すのも難しい。
複数の会社が入っている場合も、責任分解点が曖昧になるので向かないでしょう。
その代わり、小規模で、客と直結していて、その関係をコントロールしやすい案件なら
そのメリットを十分に享受することが出来る。
結果として、アジャイルに強いのは小規模な会社に多くなってしまうし、
そこにいる人たちが、大手SIerを見下す材料としては非常に使いやすい。
だからといって、既存のウォータフォールを置き換える手法ではないため、
大手やそこにぶら下がる側からすると、ドヤ顔されてもなあ、となってしまう。
ということで、手法として対立しているというより、立場が対立させてるだけなんですね。
Re:すべき論。 (スコア:1)
ウォーターホールの欠点だけ列挙して
アジャイルの欠点に言及しないのは公平性にかけるのでは？
というか、実際にアジャイルをバリバリつかている人の意見じゃないよね。
アジャイルに幻想見過ぎ。
高スキルプログラマを望みどおり集められる会社ってどこ？
アジャイルの方が良い場合。
・客の協力が得られる【重要】
・仕様がよく変わる
・プロジェクトが小規模～中規模
・プロジェクトに関わるプログラマの半数以上が高スキル
・開発者が客から直接ニーズを聞くことができる
日本ではこれに合っていないプロジェクトや体制が多いのが
アジャイルが使われることが少ない要因だと思う。
アジャイルの方がドキュメントが減るはずなのに、
結局納品物としてドキュメントが必要だったりするし。
アジャイルに合っていないプロジェクトや体制が多いのが
良いか悪いかはまた別の話。
多段請負は弊害が多いけど、やらないと
うちみたいな零細はやっていけないしね。
#今やっているプロジェクトなんて、毎月動く形にしてリリースしてるのに
#元請けも客も全く触った形跡がない。
#どうにかしてくれ。
Re:すべき論。 (スコア:1)
ケースバイケースなのも間違いないでしょう。
しかしそもそもウォーターフォールの元といわれている提唱者は早くプロトタイプを作れと言っていたり、前工程に戻ることも別に禁止していなかった。今ウォーターフォールといわれてる開発形態は単に（大した根拠の無い）見積もりがしやすいので採用されやすかった。
また、過去私がいたところではトヨタ式のなんの言うのも聞こえてましたが、最近じゃトヨタのリーン開発も逆輸入されて「本当はそういう事じゃないんだ」っていうのを他の国から教わる始末。
そういうところがダメだと思います。
アジャイルもそれぞれのプラクティスの理由を踏まえなければ上手くいかないと思いますね。
# yes, fly. no, fry.
Re: (スコア:0)
アジャイルが真に良いとは言えないけど、
それぐらいの変化を受け入れる体制が無いのならば滅びるのみ
ユーザ企業にIT技術者が多く、内製化率が高い (スコア:0)
この前提だと日本でアジャイルできるプロジェクトってIT企業の内製システムだけじゃね？
いままでアウトソースアウトソースでユーザー企業にIT技術者不要ってビジネスロジックでやってきたわけだし
Re: (スコア:0)
つ ゲームコンテンツ
＃ゲームはITじゃないって？ああそうですか
Re: (スコア:0)
家庭用ゲーム機向けのゲームはウォーターフォールだと、その出来から勝手に思ってるんだがどうなんだろう
ウォーターフォールと言われても (スコア:0)
純粋なウォーターフォールなんて今まで経験したことがない気がする。
世間で幅を利かせているのは、仕様が確定しなくても見切りで先に進んで、手戻りと仕様変更をバリバリに許容するエセウォーターフォールのような気が。
Re:ウォーターフォールと言われても (スコア:3)
洪水ですねｗｗ
Re:ウォーターフォールと言われても (スコア:4, おもしろおかしい)
いや、洪水ではないんですよ。
騙し絵のごとく、落ちていたはずの水がいつの間にか元の場所に昇ってきてるだけで。
Re:ウォーターフォールと言われても (スコア:1)
> 仕様が確定しなくても見切りで先に進んで、手戻りと仕様変更をバリバリに許容するエセウォーターフォールのような気が。
それをアジャイルっていうんじゃないんですか？ :-)
Re:ウォーターフォールと言われても (スコア:1)
この人はジョークで言ってるのかもしれないが、世の中には本気でそう信じている開発部長様がいたりするからマジ困る。
Re: (スコア:0)
プロトタイプじゃね
Re:ウォーターフォールと言われても (スコア:1)
※ただしプロトタイプコードは破棄せずにそれを拡張修正してリリースとする
Re:ウォーターフォールと言われても (スコア:1)
手戻りと仕様変更をバリバリに許容する
そう、それは水に例えれば波のように行ったり来たり・・・
ジョーク？ (スコア:0)
"IPA、「海外におけるウォーターフォール型開発の拡大」に関する分析結果を発表"に空目した。
Re: (スコア:0)
だめな奴であり続けることに関しては優れている。
はい論破。
Re: (スコア:0)
優れてないじゃん