Q&A
非常に興味深い考察をありがとうございます。
たしかに生産性が高い人の割合は少ないですよね。
でも個人的な意見ですが、プログラミングにおいては、ダメな人と凄い人の生産性の差って２倍とか５倍とかそういう次元ではないと思います。もう１００倍・１０００倍違う場面もあるのではないでしょうか。技術・経験・過去の資産、もろもろ合わせると１００倍、１０００倍の生産性の差が生まれる分野だと思います。
オブジェクト指向（OOP）は変更に強い、と一般に言われます。
カプセル化とかいろいろな機能のおかげで、あとから仕様変更する場合などに他に影響が及びにくい、と。
しかし実際には銀行や官公庁の大規模プロジェクトで、システム開発の失敗や遅延、頓挫などをしばしば見聞きします。
それらはおそらくJavaでOOPで開発されているはずです。
失敗や遅延などする理由は、発注元の曖昧な要求や後出しの仕様変更の多発などが想像されます。
でもOOPであれば、少なくとも仕様変更には強いはず。
なのに、なぜ失敗しまくるのでしょうか？
なぜ仕様変更のたびに膨大な影響範囲の調査・テストが必要なのか？ ある一部分の機能を変更するだけなら、そのクラスの単体テストだけでいいんじゃないの？
「OOPは設計が大事。最初の設計がダメだった」という意見が想定されます。
しかし数百億円・数千億円規模のプロジェクトに関わるレベルの人ですら上手な設計が出来ないのであれば、じゃあ一体誰なら上手に出来るのでしょうか？
そう考えるとOOPって机上の空論というか、現実的に「仕様変更に強い」という夢のようなことは期待できないのではないでしょうか？
あと、もしOOPが理論どおりに機能する概念だとしても、開発に延べ何千人も関われば結局グズグズになっていくのではないでしょうか？ 少数精鋭でやったほうが速く安く正確に開発できるのでは？ そもそもなぜ延べ数千人・数万人もの開発者が必要なのか？ 規模がデカいだけで、機能個々のプログラムの内容自体はそんなに難しいものではないでしょう？
初心者に毛が生えたようなSEやプログラマ数千人かき集めるよりも、スーパーハカークラスを超高給で数十人雇ったほうがいいのでは？
質問を整理します。
0. オブジェクト指向は本当に変更に強いのか？
0. なぜOOP開発での失敗例が多発するのか？
0. 失敗例の教訓、改善法はあるのか？
0. なぜ少数精鋭チームで開発しないのか？
その他OOP開発や大規模プロジェクトの失敗等について思うところあればなんでもご意見ください。
回答21件
0
近い未来に変更予定の仕様を想定して設計してあれば強いと思いますが、何でもかんでも変更に強いかというとそうではないとおもいます。
オブジェクト指向の最大のポイントは"プログラムの再利用"だと思います。コード量を減らすにはいいかもしれませんが、変更には弱いと思います。
変更したことによって、それを使っているモジュールが正しく動くかどうかは未知数です。オブジェクト指向が逆に足かせになってしまうのではないかと思います。
前述のとおり、ちゃんとあらかじめ変更を想定して入出力を設計してあれば最小の手間で変更が可能だとは思いますが、高いスキルと計画性が必要だと思います。
２～４は開発手法などの問題ではなく、日本の受発注における諸問題のせいだと思います。
技術を知らない文系営業が適当に見積もって受注した案件を、プログラムが書けないSEがこねくり回して、頓珍漢な仕様で孫請けひ孫請けの単価もレベルの低いプログラマに作らせる…。
この構造が何とかならない限り改善しないと思います。
日本の電子産業が比較的強い(強かった(涙))のは、無意味な孫請けひ孫請けが少なかったからだと私は思っています。
スーパーハッカーを雇えばいい、という意見ですが、確かにそういうプロジェクトもあると思いますが、銀行や官公庁の大規模プロジェクトといった仕事は、彼らにとっては"つまらない仕事"と思っているとおもいます。もっと稼げて、クリエイティブな仕事がたくさんありますし、そういう人たちは自分で仕事を生み出す人たちです。仮に単価が高かったとしてもやりたがらないでしょうし、そもそも日本の多くの経営者にはそういう人材に高給を出そうという発想すらありません。
投稿2016/09/12 03:45
総合スコア1939
0
こんにちは。
まず比較対象を明確にした方が良いです。性能比較は常に相対的なものですから。
銀行の事例を上げられているので、COBOLと比較した方がよいでしょうか。
1.オブジェクト指向は本当に変更に強いのか？
COBOLが得意とするような単純だが大規模な帳票処理を実装するにはあまり向いていないと思います。
COBOLのようにひな形も充実していないでしょうし。
では、COBOLが想定していない処理、例えば新しいWEB技術との連携はやはりJava等の方が向いているように思います。
変更に強いかどうかは対象のアプリで変わるでしょう。特化されたものほど想定内の変更には強く、しかし、想定外の変更には事実上対応できません。
OOPはCOBOLに比べて常に変更に強いとは言えないと思います。でも、COBOLに比べて対応範囲は広く、COBOLが苦手とする分野では決定的に変更に強いでしょう。
2.なぜOOP開発での失敗例が多発するのか？
OOP開発を習得するにはCOBOLを習得するより時間がかかると思います。
結果、使える人材が少なくなり失敗のリスクが増えるているのだと思います。
極端な話COBOLはプログラミングを習っていない人でもある程度興味を持っている人なら比較的短期間で使えるようになると思います。OOPはなかなかそうはいかないでしょう。なんとしても習得したいと言う強い意思を持っている人でないとなかなかマスターするのは難しいかと。
ちょっと古いですがCOBOL 言語の評価と展望という資料がありました。この分析には納得できます。
3.失敗例の教訓、改善法はあるのか？
最近の状況を把握していませんが、日経群の中にはきっと分析しているものが多数あるのでは？
昔は本当にたくさんありました。
4.なぜ少数精鋭チームで開発しないのか？
優秀な人の割合が少ないのだと思います。
平均の5倍の生産性を維持できる人はプログラマ100人に一人もいないと思います。
例えば平均レベルのプログラマ1000人の中に5倍の生産性を出せる人は10人いないでしょう。
トータルの生産能力は平均1000人に比べて優秀な人10人では1/20以下の生産能力に下がってしまいます。
生産性を平均の5倍や2倍に下げていったとしてもこの関係が逆転するポイントはないように感じます。
平均の2倍の人は10人に1人とか。
IT土方等の言葉が示すように中々悲惨な職場環境の話が有名になったので、興味がちょっとあるだけで特にやりたいわけではない人は参入してこなくなった。Javaを学んだ人たちが今更COBOLに手を出したくない等の社会情勢的な問題もあるかも知れません。
投稿2016/09/12 04:33
総合スコア23272
横からですが
生産性1が1000人と
生産性5が10人では確かに単純には生産性20:1ですが、
1000人と10人ではコミュニケーションにかかるコストが全然違うので
10人のほうが実はマシなのではと想像してしまいます。
ダメな人は決定的にダメですし、ほとんどいませんから（辞めていくなど）、ダメな人との比較は意味が無いです。平均と比較しましょう。大半の人は平均近辺にいますし。
平均的な人には決定的に出来ないことを優秀な人はできると言う差はあるかも知れませんね。その時は100倍、1000倍もありえるでしょう。教育期間が追加されますし、教育してもできないなら生産性0ですから。
でも、平均的なプログラマが対応できない程、難易度の高い部分ばかりの銀行や官公庁系の大規模プロジェクトってあり得ないと思いますよ。大半の部分は平均的なプログラマでも普通の工数で開発できると思います。そのような部分で平均的な人と優秀な人で100倍もの差が付くことはありえないと思います。
ozwkさん。
コミュニケーション・コストの問題は確かにありますね。
普通はピラミッドにしてコスト削減しますし、活動時間の大半を打ち合わせやその準備・復習に費やすということもないよう工夫しますから、先に書いたより差の2倍くらいの差で収まるのでは？
1000人で仕事する生産性1の人はコミュニケーションの時間のため生産性が1/2になり、10人で仕事する生産性5の人はコミュニケーションの時間のために5*9/10になるとか。
コミュニケーション・ミスによる手戻りを想定するともっと開くかも。
そこをカバーするのはマネージャの腕ですね。如何に風通しを良くするか。
0
なんか「面白そうな話題だったので～」みたいな事言ってる人いますが、
全然おもしろくもなんともない話題ですよ、これ。
なのに、なんでみんな、本当のこと教えてあげないんですか？
・なぜOOP開発での失敗例が多発するのか？
・なぜ少数精鋭チームで開発しないのか？
答えは、ゼネコン体質だからですよ。
Nなんちゃらとか、Hなんちゃらとか、Fなんちゃらとか、Tなんちゃらみたいな「名の通った馬鹿デカイ会社」が仕事を請けるけど、基本的にそいつらは何にもしなくて下請け会社に丸投げします。
その下請け会社もさらに下請け会社に丸投げします。それを何回か繰り返して、
４次請けとか５次請けとか、場合によってはさらにその下の会社に来ている、ほとんどがマトモなコードさえ書けないレベルのやつがプログラムつくるからですよ。
そうすっと、その階層構造で伝言ゲームしまくることになって、無駄なドキュメント作成や連絡の時間が膨れ上がっていきます。伝言ゲームやった事あるでしょう？最初と最後で全然違う物になること、しってるでしょう？
で、プロジェクトが遅れ始めると、「やばい、もっと人増やせ！」ってなって、どんどん人員規模がでかくなってくんです。予算だけは無駄に膨大に確保してありますからね。
人員規模がでかくなると、さらに伝言ゲームがむずかしくなっていって、統制がとれなくなっていきます。人を増やせば増やすほど、開発が難しくなるんです。こうなったらもう、手遅れですね。どうしようもありません。
・失敗例の教訓、改善法はあるのか？
教訓はもう、最近、あちこちから声が上がっています。
3,4年前の「特許庁の56億円プロジェクト大失敗」の顛末を読んでみて下さい。
あれが特別な例なのではなく、あれがこの国の本質なのです。
上記が原因なので、つまり、その一番最初のところを改善する以外に方法はないですよ。
要するに、OOPがどうしたとか、そんなのとは全く関係無い低次元なところで失敗しているんです。
だからこの質問は、全く関係ない２つの事を結びつけようとしている、頓珍漢な質問だということです。
ちなみに、最近の例の「みずほ銀行のプロジェクトがヤバイ」という話は、さらに話がややこしくなってます。
銀行の大統合のせいで、今のみずほ銀行のシステムは元あった複数の銀行のシステムをつなぎ合わせたハリボテみたいな状態みたいです。
だから、「これは統合しなければ」ってなったみたいですが、元々別銀行で別の手続きで行っていたものですからね、そう簡単には行きません。
全部の仕組みがわかってる人が何人かいれば簡単なんでしょうが、多分、一人も居ないんじゃないでしょうかね？
そこに前述のすばらしきゼネコン文化開発を持ち込むんですから、うまくいくわけ無いですよ。
現場で働いていた末端のプログラマの声とかも探せばみつかりますが、もはや、人間の働く場所ですら無かったみたいな感じですね。
そんなところに、スーパーハッカーな人がくるわけないですね。
寧ろ、絶対に避けるでしょう。
そういうことです。
投稿2016/09/20 04:07
退会済みユーザー
総合スコア0
そんなことが全部明るみになってきたから
120年ぶりに「契約」に関する民法が改正される運びとなったようです。
http://www.techvan.co.jp/media/quality/civil-code
これを「恥ずかしい事だ」と思えないやつは、本当はシステム開発に関わっちゃいけなかったんです。
ゼネコン体質が諸悪の根源だというのは大賛成です。
それによって情報伝達やら何やら、いろいろなコストが爆発的に増えますからね。
で、OOPは全く関係ないのかというとそうでもないと思います。
ゼネコン体質的な方法論とOOPは相性がいいと思うから。
極端な話、OOPだからこそ（それがいいかどうかは別として）多層ピラミッド構造での分業化がしやすいという点はあるでしょう。
> で、OOPは全く関係ないのかというとそうでもないと思います。
> ゼネコン体質的な方法論とOOPは相性がいいと思うから。
> 極端な話、OOPだからこそ（それがいいかどうかは別として）多層ピラミッド構造での分業化がしやすいという点はあるでしょう。
そう、そこまで分かってるなら話は早いです。
あなた自身が答えを出しているじゃないですか。
そんなメチャクチャな開発やっていても、現実にはそれなりには結果は出せている。失敗も多いけど、なんとか動いているものも沢山有る。
つまり、OOPは「一定の効果を上げている」んです。
OOPじゃなければそれはもっと難しかったはずですよ。
それが最後に残った質問
・オブジェクト指向は本当に変更に強いのか？
の、僕の答えです。
＞現実にはそれなりには結果は出せている
いや、多重下請けを法律で禁止すれば、もっといい結果が出せたのでは？
税金投入額は１０分の１以下で済んだのでは？
＞OOPじゃなければそれはもっと難しかったはず
そうかなぁ？
ピラミッド構造じゃなければ、OOPでない方法でもやれたはず。
私の質問の本質は、OOPの有用性の是非はもちろんですが、そこから結局無駄（特に税金の）をなくせるかどうかです。
> いや、多重下請けを法律で禁止すれば、もっといい結果が出せたのでは？
> 税金投入額は１０分の１以下で済んだのでは？
勿論そうでしょうね。で、それはあなたが聞きたいOOPの有効性と何か関係があると、
まだ思っているのですか？
> ピラミッド構造じゃなければ、OOPでない方法でもやれたはず。
じゃ、ピラミッド構造にしない方法を考えるのが先ですね。OOPの有効性について考えるのはその後の話ですね。
> 私の質問の本質は、そこから結局無駄（特に税金の）をなくせるかどうかです。
だから言ったでしょう？
>上記が原因なので、つまり、その一番最初のところを改善する以外に方法はないですよ。
って。
OOPがどうしたなんてのは全く関係ない話だと、まだわからないんですか？
わからないなぁ。
＞一番最初のところを改善する以外に方法はない
じゃあ具体的にどうしたらいいのでしょうか？
提言してください。
> わからないなぁ。
ん？ これまでの会話でもまだ、OOPが関係あるかもしれないと思っているってことですか？
少し頭良さそうに見えたのは錯覚だったかな？
よく読み返して、自分の言ってることが筋道通っているか、よく考えてみましょう。
もう一回説明しろって言われても同じことしか言えないですよ。
> じゃあ具体的にどうしたらいいのでしょうか？
> 提言してください。
なぜ？ どうしたらいいのかは「自分で考えなさい」です。
理由は簡単、100人居たら、100通りの答えが出てくるからです。
僕は僕なりの答えを出して、上記の狂ったシステム開発から抜け出しました。
あなたは誰かに「こうすればいいよ」って教えて欲しい、教えてもらわないと答えが出せない木偶ですか？
それに、あなたが聞きたかったのは「OOPは本当に変更に強いのか？」でしたよね。
その答えは、わたしと貴方の会話の中で出てるじゃないですか。
もし、「この業界を変えるにはどうしたら良いのか？」という質問をしたいなら、新たにスレッドを立てなさいな。
それが、teratailの趣旨に合うかどうか、よく考えてからね。
0
オブジェクト指向は本当に変更に強いのか？
強いです。
しかしそれは、OO以前の構造化技法に対する相対的な強さで、
絶対失敗しない**「銀の弾丸」ではない**です。
なぜOOP開発での失敗例が多発するのか？
OOが普及して母数が多くなったから、失敗例も増えたのでしょう。
しかし、OO採用と非採用で比較する必要があります。
OOを採用していなかったら、もっと失敗が増えていたでしょう。
また、ご質問はOOが実施できている前提になっています。
しかし、本当は関数型言語と同じくらい難しいが、
OOPは関数型プログラミングより制約が緩いため、
本当はできていない場合が見分けづらいと考えます。
失敗例の教訓、改善法はあるのか？
あるでしょうが、それはOOのような開発技法ではなく、
組織管理の話になるかと思います。
なぜ少数精鋭チームで開発しないのか？
そもそも、大規模開発は企業間での巨額の契約ですから、
そうなるはずだ、という希望的観測で事を進めるわけにはいかないでしょう。
かりに「ウチの会社は千人分の仕事を十人でこなせます」といったところで、
本当にできるかどうかを検証するのが難しいです。だからリスクがあります。
要するに人月的な発想があるのでしょうが、
しかし、それを捨てたら上手くいくとも限りません。
平凡な人材と精鋭とで、本当に10倍も100倍も差が開くかは疑問です。
精鋭との差は量より質の差に出ると、個人的には考えています。
たとえば機械学習のようなジャンルだと行数より精度が問題になります。
しかし、「銀行や官公庁の大規模プロジェクト」は規模は超巨大だが、
極端に難しい処理が固まっているわけでもないので、
少数精鋭のプロジェクトに向かないのではないかと思います。
投稿2016/09/12 07:20
総合スコア5592
> 精鋭との差は量より質の差に出る
> 極端に難しい処理が固まっているわけでもないので、 少数精鋭のプロジェクトに向かない
なるほど！
たしかにそうかもしれませんね・・・
プロジェクトの失敗や無駄を減らしたい、詰まるところ税金の無駄をなくし、IT技術者が幸せになる世界にしたい。そう思ってるんですがなかなか難しいですね。
諸外国ではこういった巨大システムの開発はどうやってるんでしょうね？
＞諸外国ではこういった巨大システムの開発はどうやってる
アメリカでもやはり大規模開発の多くはウォーターフォール式で、
IT先進国だから大規模も少数精鋭、ってわけでもないようです。
＞IT技術者が幸せになる世界
ただ、かりに1000人を10人でやったら、雇用が減って困る気もします。
ですから私としては、大規模開発を少数精鋭化するよりは、
日本も米のようにベンチャー企業を作りやすくして欲しいです。
なぜならたとえば、ビル・ゲイツやスティーブ・ジョブズは、
並の人材の万倍も億倍も、付加価値を作り出してますよね。
もしかりに、彼らが大規模開発の一員だったら、
「たかが百倍や千倍」の生産性で終わり、
今のMSもアップルもありませんでした。
むしろ日本の場合、日本的事なかれ主義で起業のリスクを避け、
本来の「精鋭」はすでに大企業に入っていて、大規模開発に参加しているが、
少数精鋭としては実力を発揮できていないのが、真の問題かもしれません。
だから、日本の精鋭にはベンチャーで市場開拓して欲しい、と私は考えます。
＞かりに1000人を10人でやったら、雇用が減って困る気も
短期的にはそうですが、長期的には心を病んだり自殺したりする人が減っていいと思います。プログラマ的素養は他の業界・仕事でも必要だと思いますしね。
＞日本の精鋭にはベンチャーで市場開拓して欲しい
これはまったく同感です。
0
まず、前提として、Javaを使ったからと言って無条件にオブジェクト指向になるわけではないと思います。Javaを使ったらオブジェクト指向になるのではなく、オブジェクト指向を実現するための言語としてJavaがあると考えてください。
1-オブジェクト指向は本当に変更に強いのか？
変更には強いですが、程度に寄るし限度もあります。
2-なぜOOP開発での失敗例が多発するのか？
オブジェクト指向で開発されているプロジェクトの母数が多い上に、他の言語をラッピングして再利用するので一番外側の言語に問題が発生しているように見える。
3-失敗例の教訓、改善法はあるのか？
PMBOKではプロジェクトを振り返るフェイズがあります、ここが機能していたらもしかしたら同じ失敗は減るかもしれませんね。
4-なぜ少数精鋭チームで開発しないのか？
1人幾らでお金を貰っていて、作業している人の技術レベルでお金が増減することはないから、利益にならないんじゃないかと思います。
投稿2016/09/12 03:55
総合スコア18155
＞前提として、Javaを使ったからと言って無条件にオブジェクト指向になるわけではない
銀行や官公庁の大規模プロジェクトに関しては、前提として「オブジェクト指向は当たり前」と考えていいのでは？ それとも、そんな数百億円とかが動く日本有数の規模の仕事でも、まともなOOPが出来ない人たちが上流にいるのでしょうか？
＞プロジェクトの母数が多い
今回は大規模なプロジェクトに限ってお尋ねしております。
数百億・数千億の仕事で頻繁に失敗されては困ると思うのですが・・・
＞1人幾らでお金を貰っていて・・・
現状がそうであるのは分かりますが、なぜ改善しないのか？が疑問です。
内側の人が声を上げて政府なりなんなりに文句言うべきでは。
設計者と実装者が同じ人、同じ会社、またはすぐに連絡できる場所にいると思いますか？
設計者はオブジェクト指向に則り設計をします。実装者は設計書をもとに道具「Java」を使ってオブジェクト指向を実装しようとします。
設計がまずい場合もありますが、実装がJavaを使ったなんちゃってオブジェクト指向なら恩恵は減りますよね？
プロジェクトの母数について
そうですか。プロジェクトの成功失敗とプロジェクトの大小とは関係ないと思いますが。
お金について
「私の会社にスーパーハカーレベルの技術者がいて、100人月分は仕事します。」
「私の会社は技術レベルが高いので、100人月を担当しますよ。だから契約単価も高めになりますよ。」
こんなこと言い出したら取れる仕事も取れないような気がしますね。
あなたは具体的に政府になんと言うつもりですか？
＞設計者と実装者が同じ人、同じ会社、またはすぐに連絡できる場所にいると思いますか？
いないから問題だと思います。
これは技術の問題というよりも受発注の問題だと思いますが。
＞プロジェクトの成功失敗とプロジェクトの大小とは関係ない
話がかみ合っていませんね。
あなたが「母数が多いから失敗も多い」と書いたので「大規模の母数はそんなに多くないし、大金かけて失敗されまくったらアカンでしょ」と私は返答しました。それに対する
「成功失敗と規模の大小は無関係」というあなたのコメントは的外れで話がかみ合っていません。
＞お金について
ちょっと何を言っているのか分かりませんし、この狂った現状を改革しようという気持ちもないようですね。
話が噛み合いませんね。表現が足りない部分が多すぎました、ごめんなさい。
ただ、私が考えてる解決方法はあります。
IT従事者特に専門的な知識を持つ人間がフリーランスになること。または、会社内でフリーランスに近い流動性のある人事をおこなうこと。
なるほど、それはいい解決アイデアの一つですね。
でも現状では日本全体の雇用環境が足かせになりますね。
厳しい解雇規制が撤廃されて雇用の流動性があがり、さらに正規・非正規の区別がなくなるような状況にならないと、なかなかサラリーマンを辞める勇気を持つ人はいないでしょうね。
これが実現できれば、オブジェクト指向の設計ができる人が設計を行い、Javaを使ってオブジェクト指向を実現できる人が現場に増え、オブジェクト指向の恩恵を十分に受けることができるはずです。
あなたが言う設計者と実装者が同じ開発現場にいることもできる気がします。
0
いろいろ書いては消し、書いては消ししましたが、結論としては仕様書を書く人の多くがオブジェクト指向を理解していないのでソースコードレベルでオブジェクト指向にするのに限度があるということが大きいです。
大規模開発は政治に渡り歩く能力が求められ、ある種の専門性が高いので、コーディングやオブジェクト指向などのプログラミング方面の専門性の優先順位が低くなります。
少数精鋭にすれば解決するかもしれませんが、銀行ではOOPやドメインモデルを使ったとしても過去から積み上げられた大量のロジックがあり、発注側に大量の仕様書を渡す必要があるため、少数では回らないでしょう。（発注側がソースを読むつもりになれば話は変わりますが・・・）
恐らく公官庁では、発注側の技術的な能力不足のためにUMLなどであっても受け入れるのは難しいと思います。
テスト結果に関しても、発注側として許容される報告書の作成が必要であり、それなりの工数となることが予想されます。
そういったわけで、私は恐らくOOPと言ってもモデリングをキチンとしたものでやられている可能性はほとんど無いと考えています。仕様書を書く工数があまりにも大きいのです。
OOPがまともに機能していないし、仕様変更を人数でカバーできる体制をくんであるので、技術的な問題でプロジェクトが失敗する可能性を回避しています。違和感を感じない訳には行きませんが・・・
ただし、大規模開発にオブジェクト指向が向かないわけではないです。Webやアプリケーション分野では当たり前に使われている技術なので、かなり有効な技術だと思います。
受注開発の場合に問題がおこる場合が多いと考えています。
改善方法としては、発注側に技術責任者をおいて、仕様書を減らしアジャイルな開発方法を採用できれば、真にOOPの恩恵があるでしょう。しかし、技術責任者に権力が集中するので、専任以外に委員会を設けるなど細かい配慮が必要かなとも思います。
追記
優秀な技術者についてのイメージが回答者によってまちまちなので、私のイメージを書きます。
・おおむねタイプ速度は速いですが、２倍も速いということはないと思います。
・コードが短いので早く仕上がります。
・手順がしっかりしているので手戻りが少ないです。もしくは自動化をしています。
・バグフィックスが早いです。
・テストの回数は多いですが、テストを実行する時間は短いです。
・バグは早期につぶされます。
・潜在的なバグが少ないです。
たぶん、この時点で２～４倍程度の生産性の差が出ます。
バグフィックスにかかる時間は思いのほか大きいものです。
それでも、このレベルの優秀さであれば、大量に人を集めても変わらないと判断する人も多いと思います。
さらに優秀な技術者はプロセスにも精通しています。
・テストの管理・変更管理・デプロイなどの定型業務のあるべき姿を知っていて改善することができます。
・不要なプロセスを指摘することができます。
・チェックポイントをまとめ上げ、可能ならば自動化します。
開発チーム全員の生産性を上げることができるので、寄与した生産性は１０人分を超えます。
ただし、そうすることが許されればの話で、個別の作業にEXCELの資料を求められたら意味がありません。
さらに、ほとんどが優秀な技術者のチームとなるとこのような効果があります。
（書いてから気が付きましたが、まんまアジャイル開発ですね・・・）
・設計段階からきちんとしたモデリングをすることができます。
・モデリングされたコードを書くことができます。
・開発段階でリファクタリングを行い設計変更による影響を減らせます。
・設計資料は最小限に抑えられます。
・テストを大規模に自動化できます。
・細かいリリースで、ユーザーテストに十分な時間をかけられます。
これができれば生産性は一人当たりの生産性は１００倍になっても不思議ではないかと考えています。
もちろんこれを受託開発で行うにはかなりのハードルがあると思われます。
しかし、これは大規模なソフトウェア開発では普通に行われていても不思議ではありません。
（google・Facebook・Microsoft・LINE・楽天 などを思い浮かべてください。）
投稿2016/09/13 16:05
編集2016/09/14 03:54
総合スコア2883
0
大規模案件に参画経験はないので、
ある程度想像の入った話となりますので、参考までに。
###開発モデルの問題
大規模案件では基本的にウォーターフォール開発モデルが利用されると聞きます。
恐らくはそれ単体ではなく、
一部スパイラル開発モデルも利用されているとは思いますが・・・。
この開発モデルの1番の問題点は手戻りが発生した時の差し戻しがとんでもなく手間がかかることです。
でも普通に考えると要求仕様は生き物のように変わり得るので、
開発当初と言ってたことが違うやんみたいなことが簡単に発生し、
結果その部分の元々の設計と大きく食い違うと大幅な遅延を招きます。
じゃあスパイラルモデルとか、
今流行りのアジャイルを採用すればいいじゃんと言われかねないですが、こちらはこちらで問題があります。
それは全体としての見積を取るのが容易ではないことです。
大体大型のプロジェクトとなると、
最初の時点である程度見積を出して、顧客がそれに対して採否を決める形がほとんどだと思われます。
仮にスパイラルモデルとかアジャイルとかを採用してプロジェクトを進めた場合、
それこそ先行きが読めず規模が膨らみまくって破綻するということが予想されます。
またアジャイルとかとなると、
顧客も開発・仕様決定に積極的に関与してくれないとこれも破綻しやすいです。
そのため結局はウォーターフォールベースの開発に落ち着いているというのが現状かもしれません。
###産業モデルの問題
IT産業では請負元から、下請け発注をかけて開発を投げるというのがお家芸となっているので、
構造上どうしても色々な企業や多くの人員が関わってきます。
これによって、組織間のコミュニケーションはどうしても発生するのですが、正直この部分でうまく伝達が行えていないパターンも多いように思えます。
少なくても中規模な案件ですら、
伝達ミス、思い違いなどによる実装漏れや実装ミスが生まれるのですから、
大規模案件ではその辺りを徹底的に管理してないとすぐにそのような事態が発生すると思われます。
でもそれでも今のIT産業が冒頭のような構造で成り立っているので、
抜本的に変わらない限りここの変化はまずあり得ないでしょうね。
###人員確保の問題
Javaとかではよく言われてますが、
割と良い人材は囲い込まれていますし、
スーパーハッカークラスになると、
案件自体に興味すら持たないことも多そうなのと、
どうやって本当にそのクラスの人材であると判断するのかといった別の課題が発生します。
そうなると結局は大規模案件は、
ある程度信頼のできる実績のある大企業に発注をかけ、
ITの産業モデルに従いずるずるととなるのかなと思います。
###最後に
あくまで個人的な意見ですが、
設計スキルや実装技術云々よりも、
管理面とか産業構造によって起こっている遅延とかが起こる側面が強いのかなと思ってます・・・。
投稿2016/09/12 04:38
総合スコア1636
ウォーターフォール開発モデル自体に限界があるのに、さらにそこに日本特有の商習慣（多重下請けなど）が混じって悲惨なことになっていますね。
個人的には税金を投入する案件については下請けに投げるのを禁止すべきだと思います。
元請が直接雇った社員のみ開発に参加するように義務付ければ、日本のIT界は改善すると考えています。
> zico_teratailさん
確かにそのような制約を付ければ、下請け連鎖による開発現場の分散は防げるかもしれませんね。
ただそうなると元請け側の方に優れた人材を選び抜く能力があるかという点の課題はあると思います。
大企業がどのように人材管理しているかは当方把握してませんが、
スキルマップを明確にした管理があることが前提で、
かつ適材適所に割振りがてきないと結局はポシャる気はします。
下請けに流してその辺りの負荷を分散したいという狙いも当然あると思うので、
一筋縄にはいかないでしょうね。
後はIT産業界のお金の循環の側面も絡んできそうな気もする・・・。
ちなみにですが、
銀行系のシステムでは近年COBOLからJavaのシフトが目立ってますが、
正直そういう案件はCOBOLを熟知したスタッフとJavaを熟知したスタッフを揃えないといけない(どちらも万全にこなせる人はなかなかいないし、どちらのスタッフが欠如しても炎上しやすい)ですし、
結局その場合もコミュニケーションコストがかかるから銀行系は厄介なんでしょうね^^;
0
ベストアンサー
- オブジェクト指向は本当に変更に強いのか？
オブジェクト指向自体は強いです。
強度で言えば極まった関数型の方が強いとは思いますが、極まったオブジェクト指向で十分でしょう。
- なぜOOP開発での失敗例が多発するのか？
オブジェクト指向言語と呼ばれる言語の内、大多数は命令型言語です。
プルグラマが寄ってたかって、1メソッド200行は当たり前という神クラスを作り始めるわけですよ。
それオブジェクト指向じゃねーから！！
JVMで動作するJavaもどきの産物は再利用の出来ないゴミでしかありません。
- 失敗例の教訓、改善法はあるのか？
200行にも渡るメソッドを作り上げるお馬鹿さんでもいつか気付くわけですよ。
「ん、俺らが書いてたこれはオブジェクト指向とは呼べないんじゃね？もっと良い方法があるはずだ…」
様々な本を読み、デザパタを覚え、コードを数多く書いて、少しずつ改善されるわけですよ。
しかし大企業のゼネコンシステムで行う限りありえません。
30歳を目前に「お前もそろそろ良い歳なんだから、プログラミングなんかやってないで上流工程いけよ」と肩を叩かれます。
「なんかとはなんだ！」と言い返せるはずもなく、成長過程のプログラマが駆逐されてしまうわけです。
- なぜ少数精鋭チームで開発しないのか？
これが正解で、ベンチャー企業の多くは少数精鋭のチームです。
しかし、ベンチャー企業で成功する企業は殆どなく、10年で1%程度しか生き残れません。
知名度がないから仕事を取ってこれないし、買い叩かれるし、自社サービスを作っても使って貰えないですからね。
その1%で成功して金を得た企業も少数精鋭は長続きしません。
軌道に乗せた上位1%の敏腕経営者は大金を注ぎ込んで一気に儲ける仕組みを知っています。
大金持ってるだけの金持ちが何もしてないのに稼ぎまくる姿を羨ましく思いながら堅実に頑張って来たんです。
やるなという方が無理でしょう。
人月の神話を夢見て、人を増やしますが募集掛けてもそらでFizzBuzz書ける人は10人に1人も来ません。
それで妥協すると、あっという間に大企業と同じ環境が出来上がりますが、妥協しなくても別に良いエンジニアは増えません。
結局使えない人間を大量に仕入れて人身売買に手を染めるという安易なビジネスが出来上がります。
もう既に世界は十分豊かで、働かなくても生きていける世界なはずなんです。
だから、技術に興味のある人間は死ぬほど技術を磨く事が出来るはずだし、
真に技術を認めあった人間同士で作りたいサービスのアイデアをもちよって自由に組んで仕事が出来る世界にもうなっているはずなんですよ。
…なんで現実は毎日朝早くから深夜遅くまで仕事しないと食っていけないんでしょうかね。
この辺のギャップ…つまり太字のどれかが4番の答えな気がしてならないですね。
投稿2016/10/25 12:31
総合スコア21158
4番の少数精鋭が正解と答えた理由ですが、
私の考える正解は「ハッカーと画家」という書籍が根拠になっています。
動的型付きの開発速度の出る言語を使って少数精鋭で一気に作ってしまうのが、ベンチャー企業の勝ちパターンとして紹介されています。
強い言語として書籍内でオススメされている言語はLISPですが、
Ruby、Python、Node.js（With AltJS）なんかも強い言語の候補に上がってくるかと思います。
＞既に世界は十分豊かで、働かなくても生きていける世界なはず
私もそう思います。
少なくともIT業界は過去の知見やソースコード財産が溜まりまくっており、前回と同じようなものの開発ならば加速度的に速くなっていかないとおかしいはず。
実際私は（組織に所属しておらず個人開発ですが）、過去の資産の組み合わせにより、現在は本当に開発速度が速くなっています。デザイン面でもBootstrapなどCSSフレームワークのおかげでものすごい時間短縮です。
にも関わらず、税金を投入するITプロジェクトや銀行などのITプロジェクトは、何十年も似たようなものを作ってるくせに一向に開発期間が短縮されないのはなぜなのか？
同じようなミス・炎上を繰り返すのはなぜなのか？
銀行業務全体としては細かな要求仕様が膨大にあるとしても、それはある意味「枝葉」の部分であって、銀行の根幹を成す部分は何十年前から変わっていない（変わってたら銀行じゃなくなる）はずなのに。
「ハッカーと画家」、読んでみたいと思います。
0
面白そうな話題なので、私も回答してみようと思います。
オブジェクト指向は本当に変更に強いのか？
本当です。きちんと設計されていれば。
理由は簡単です。オブジェクト指向設計では「変更可能性を織り込んで」設計をする事ができるからです。
ここはこんな風に変更するんだよ。と明示されているわけです。
そのような設計が変更に強いのはむしろ当然のことではありませんか？
なぜOOP開発での失敗例が多発するのか？
OOPだから失敗した、というわけではないのではないですか？
失敗例の教訓、改善法はあるのか？
それがわかっていたら大金持ちになれます。
なぜ少数精鋭チームで開発しないのか？
属人性をなくしたいからだと思います。
SIerはSIの工業化という夢を見ています。
だれがやっても同じものができる。というものです。
そうすれば、工場で流れ作業のようにプロジェクトができます。
優秀なエンジニアに頼ると、その人間がいなくなるとどうにもならないし、それはエンジニアの価値
であって、SIerの価値ではなくなってしまいます。
SIerの価値とは、だれがやっても一定水準のシステムを作れる方法論を持っているということだ。
そう彼らは考えます。
だから、彼らは少数精鋭など絶対にしないのです。
投稿2016/09/17 11:57
総合スコア42
＞「変更可能性を織り込んで」設計をする事ができる
具体的にどうやるのでしょうか？
あるいはどういう単語でググればそういう事例が見れますか？
＞OOPだから失敗した、というわけではないのではないですか？
OOP「なのに」失敗したケースについて質問しています。
＞それがわかっていたら大金持ちになれます。
巨額の税金を投入した仕事で、しかも何十年も知見が蓄積しているはずの分野でいまだに何度も何度も失敗されてたら困ります。いっそのことパッケージ化して業務をパッケージに合わせろよ、と言いたくなります。
＞属人性をなくしたいから
属人性をなくしたいからこそオブジェクト指向で作るのであって、チーム人数の多寡は関係ないでしょう。
実際、多人数でやってるのに属人性が散見されてデスマの一因となってる事例が多数あるじゃないですか？
＞工場で流れ作業のようにプロジェクトができます
だからもうゴミみたいな特注品はやめて、みんなパッケージにしろよ、と思います。
まあこれは受注側の問題というよりは発注側の頭が悪いせいですが。
> ＞「変更可能性を織り込んで」設計をする事ができる
> 具体的にどうやるのでしょうか？
> あるいはどういう単語でググればそういう事例が見れますか？
フレームワークのコードを読むことをオススメします。
フレームワークを用いてWEBアプリを作ることは、「拡張する事」そのものです。
WEBアプリは「フレームワークの拡張ポイントを用いて拡張」しているのですよ。
> ＞OOPだから失敗した、というわけではないのではないですか？
> OOP「なのに」失敗したケースについて質問しています。
OOPを何だと思っていらっしゃるので？
上等な包丁を使えば美味しい料理が作れるわけではありませんよ。
>＞それがわかっていたら大金持ちになれます。
> 巨額の税金を投入した仕事で、しかも何十年も知見が蓄積しているはずの分野でいまだ> に何度も何度も失敗されてたら困ります。いっそのことパッケージ化して業務をパッケ> ージに合わせろよ、と言いたくなります。
お気持ちはわかります。
しかし、どの会社も同じやりかたで仕事をしていたら、会社ごとの特色はなくなります。
多様性のない業界、社会が良いなどと私は思えません。
問題はパッケージ云々ではないと私は思います。
> ＞属人性をなくしたいから
> 属人性をなくしたいからこそオブジェクト指向で作るのであって、チーム人数の多寡は> 関係ないでしょう。
> 属人性をなくしたいからこそオブジェクト指向で作るの
誰かそんな事をおっしゃいました？誰だろう。
オブジェクト指向で作っているという現場で、オブジェクト指向で作っているSIerを見たことがありません。中身は全て構造化ですよ？
ER図を描いて、フローを書いていますよ、彼らは。
それを「Javaで作っているのだからオブジェクト指向だ」と言い張っているのです。
> 実際、多人数でやってるのに属人性が散見されてデスマの一因となってる事例が多数あるじゃないですか？
だから、SIerのシステム観や目指す方向自身が間違っていると、世間で言われているわけです。
> ＞工場で流れ作業のようにプロジェクトができます
> だからもうゴミみたいな特注品はやめて、みんなパッケージにしろよ、と思います。
> まあこれは受注側の問題というよりは発注側の頭が悪いせいですが。
パッケージ好きなんですね。SIerでもパッケージ使っているのでは？
パッケージ云々の問題ではない気がしますが。
＞フレームワークのコードを・・・
フレームワークも言語によってはかえって毒というかグダグダになりますけどね。
たとえばPHPでフレームワークとか害の方がデカイと思う。
＞どの会社も同じやりかたで仕事をしていたら、会社ごとの特色はなくなり
いやいやいや、たとえば基幹系システムと呼ばれるものは、本来は会社ごとに特色あっては困る（いけない）ものでしょう。法律でほぼ決まってる最終形があるんだから。
ある会社に特有の業務・儲けに直結するコアコンピタンスを実現するのは基幹系システムありきじゃないっしょ。
誰かが「基幹業務って言ってるけど実際は間接業務だろう」って書いてた人がネットにいましたが、私もそう思います。特に会計なんかはそう。本来はどの会社でも同じじゃなきゃおかしい間接的な業務。
＞多様性のない業界、社会が良いなどと私は思えません
日本ではクソみたいな各社のくだらないこだわりに合わせてカスタマイズするのが一般的ですが、欧米では標準パッケージに業務を合わせるのが一般的らしいですよ。
それで欧米は多様性に乏しい社会だと思いますか？
＞パッケージ云々の問題ではない
あなたの論理ではそう主張するだけの論拠に欠けますね。
>＞フレームワークのコードを・・・
> フレームワークも言語によってはかえって毒というかグダグダになりますけどね。
> たとえばPHPでフレームワークとか害の方がデカイと思う。
それはパッケージでも同じでは？
フレームワークではなくてパッケージのコードでも良いですよ？
同じことです。
> 本来はどの会社でも同じじゃなきゃおかしい間接的な業務。
そういうのはそうでしょうね。
> それで欧米は多様性に乏しい社会だと思いますか？
思います。
ただまあ、業務の種類によっては標準にあわせるべきだ。それに関してはおっしゃるとおりだと思います。
> ＞パッケージ云々の問題ではない
> あなたの論理ではそう主張するだけの論拠に欠けますね。
え？もちろん私は何の論拠も述べてはいませんが、その前に
あなたの主張の論拠はどこですか？
世の中の開発はパッケージとSIerだけなんですか？
0
大規模プロジェクトにおいてコーディング・プログラミングが占める割合は小さいのでOOPとは関係ない箇所で遅延しているんだと思いますよ。
大規模なシステム開発でコードを書く時間はごくわずかです。要件定義から始まって、設計、影響調査、レビュー、顧客の承認、コーディング、テスト、リリースまで作業が沢山ありますし、利害関係者の会議日程調整、チーム間の調整など無駄に時間が過ぎ去る要因もあります。
仮に全体の期間が100だとして、コーディングの割合が20だとします。ここで夢のような技術が開発されて、期間が半分に削減されて10になりました。人も費用も50%削減できました！でも、全体としては1割しか削減されてないんですよね。
よって技術的な部分を解決しても意味はないと思います。原因はそこにはないのですから。
投稿2016/09/12 08:33
総合スコア759
そのような純粋なコーディング以外の「無駄な時間」が多すぎるので、それを削る目的もあって「少数精鋭チームでの開発はどうか？」という提案です。
もっと言えば発注側にも罰則なりペナルティが必要だと思います。
特に税金を投入するプロジェクトの場合、発注側のせいでトラブったり納期が遅れたりしたら発注側にもしっかり責任を負わせるべきです。役人天国すぎ。
0
COBOLとJavaを双方経験したものです。４３歳独身です。私は学がありませんので皆さんのように視座は高くありません。あらかじめご了承ください。
1.オブジェクト指向は本当に変更に強いのか？
変更に対してプログラマが理解しやすく、仕様どおりに修正できるかといえばCOBOLと同程度かと思います。ただしプログラムの基礎的な部分（キュー、同時制御、IO制御）などに仕様変更せざるを得ない場合、オブジェクト志向にもとづくプログラムの構成は設計者の嗜好が反映されている分、理解に時間がかかり、しかも広範囲に再利用されるので、ちょっとした変更でも恐ろしいと感じます。Cと比較はしませんよ。設計者、あるいは基礎的な部分を実装した人間がプロジェクトに参加していない場合、大企業レベルのオブジェクト志向のプログラムは、迷宮のような印象です。綺麗な設計というのはだいぶ後にならないとわからないものです。
Minecraftでも豆腐と呼ばれる家は、大概作れもしますし、修繕もなんとかなるものではないかと思います。
2.なぜOOP開発での失敗例が多発するのか？
情報自体の整理と使い方をどこまで突き詰めるか？ということがオブジェクト志向の一番大事なところだと思い、日夜業務をこなしています。しかし、これは短期間でやれることなのか？といつも疑問に思っています。
大規模開発では、作業は分担制です。しかしAさんの考える設計とBさんのそれでは噛み合わない可能性があります。もちろんレビューなど様々な方法で防ごうとするのですが、その差異を埋めることは難しいという認識です。このズレは人数分の組み合わせたとき複雑度を増しますので、失敗あるいはそれに準ずる結果になる可能性は高いです。
またオブジェクト志向的なアプローチ（状態を保つ）と大規模案件はすごく相性が悪いという印象です。なんでもメモリ溜め込んでしまう方向に行きやすい印象です。（道具によって人の意識は左右するのでしょうか？）
大量データや同時アクセスをしっかり取り扱うには熟練の経験者が入ります。しかし一般の技術屋は億を超える件数を動かすオブジェクト志向独特の開発ノウハウは持ち得ていません。それはだいたい公開されませんし、引き継がれません。オブジェクト志向的アプローチを捨てろとはなかなか言えないものです。
3.失敗例の教訓、改善法はあるのか？
現場の技術者としてはこんなアイデアしか思い浮かびませんでした。
a) 言語別のソースを標準化
オブジェクト志向は難しいという前提に立ち、徹底したノウハウの公開だと思います。車輪の発明はもう。言語、フレームワーク別に大規模開発用のソースコードの書き方標準があったら相当いいなと夢想します。（データベース周り,ファイルIO,同時実行関係 etc ）
b)機密レベル抵触しないレベルでのソースコードの公開
上のアイデアとほぼ同じなんですが、恨み節的なアプローチ。税金で作っているなら、国で作ったソースの一部を公開したらいいのでは？もちろん悪用されたりするのは問題なんですが、なんというかそうでないプロジェクトもあるはずです。これをまとめてJapan1.xとか格好いいかなと。
c) 早めにパフォーマンステストを行う。あと問題はだいたいDBとファイルIOです。
みなさん問題はこれではないですか？IT直後にやったらだいたいわかりますって。あと非正規化をしっかり検討しておく。オブジェクト志向は正規化をしすぎる傾向があります。
d) 自称天才（オフショアにたくさんいます）に組ませない
e) ソースコードを組ませないように注意する（車輪の発明を阻止する）
f) オブジェクト志向という言葉を一部なくす
これっているでしょうか？ほとんどが本を売るための言葉のように思えます。なんというか、IT業界ではマーケティングに負けて新しい技術を強要されてきた風潮がある印象です。オブジェクト志向は、おそらくフレームワークを使っている技術者には概ね不要かと思います。学ぶ必要も特にありません。大量生産に合わせたスキルに特化していくべきです。
最後はだいぶ荒っぽい意見ですね、気を悪くされた方がいらっしゃったら申し訳ありません。
4.なぜ少数精鋭チームで開発しないのか？
少数精鋭については基本的に賛成です。人月のお話などもありますから簡単ではないのだろうなと思います。精鋭になりうる方の業務範囲が狭いと、他案件では並になってしまうかもなので結果として人を揃えられないというのがぼんやりとした感想です。彼らの活躍できる範囲ってきっと２、３０Kステップくらいなので、お金的にも厳しいですよね・・・・・
蛇足ではありますが、オブジェクト志向と少数精鋭の相性はいいと思います。工数、品質ともに成果が期待できます。しかしこの場合は、極論に行かずに折衷案的な編成を行ってはいかがと思います。
基礎的な部分 ： 少数精鋭←中級をここに入れていく ← 最初は彼ら。テストのツールとかも検討してもらう
大量生産部分 ： 初級、中級レベル
打ち合わせとか事務作業 ： 打ち合わせ専門部隊（技術者だけ、営業だけはダメ）
この場合、中級レベルのメンバーが未来の中核です。段階的な移行にもとづき完成に向かう的なのはいかがでしょうか？ざっくりと言えば、初期のパフォーマンステスト、IT中期まで行ったら少数精鋭部隊を別案件、もしくは次フェーズに移行します。もちろん少数精鋭でもバグは出ますし、どこにバグが出るかはわかりません。つまりテストフェーズか先は人手がかかります。しかしテストするためにはドキュメントも必要であり、ドキュメントの効率化はなかなか難しい。なぜしないかという問いは各社によるのでわかりませんが、プロジェクトにい続けることは難しいのではないでしょうか。中小規模案件なら少数精鋭で実施するべきなのでしょうね。快く受けてくれるかは置いておくとしてですが。
最後に長々と、かつ不躾な発言をどうぞお許しください。おっさんの深夜の戯言と片付けていただければ幸いです。合コンがたくさんあるのでどうやら疲れていたようです。
投稿2016/09/20 19:47
総合スコア12
0
オブジェクト指向を使うと既存の実績のあるclassやlibratyなどを
オブジェクト指向のプログラミングでは既存の実績のあるclassや
libratyを簡単に継承して自分が作ったかのように扱えます。
システム変更時も確認を追加すべき箇所は既存の実績のあるclassや
libratyの箇所でなくて新規に追加した箇所だけになるのでその分、
容易になるというだけです。
C,C++,Javaなど最近の開発言語はほとんどオブジェクト指向での
プログラミングができます。使っていない人はいないといっても
過言ではないでしょう。
そもそもオブジェクト指向プログラミングでもそんな大人数が必要に
なるようなシステムはそもそも変更箇所が思っているよりも多いと
考えます。（オブジェクト指向でなければ更に大人数必要と思います。）
そもそも仕事になるようなシステム変更はバージョン変更など新しい
要素が多く、参考とする書籍や情報もなく色々と試してみながら開発を
進めないといけない要素が多いので人海戦術が必要な場合が多いと思います。
エキスパートクラスを集めても結果的に試してみるしかないため安い人件費で
若い人を多く投入した方が良いことも多いと思います。
そのため凄い人数でとりかからなければならないプロジェクトなどが生まれたり
するのです。
投稿2016/09/20 08:58
総合スコア1628
0
強力なツールであることは間違いはないですが、完全なものではありませんし使う人間にも依ります。また、規模が大きい話ならば技術要素でない経営上の要素も当然絡みますし一概には言えません。
ちなみに、「仕様の変更に強い」といっても、これを安直に実施するようでは人間として信頼されません。ましてや「契約」が絡む話であれば「双方の合意」なく変更を行えば信頼問題となります。
（OOPではないですが）私が以前携わったプロジェクトにおいてこんなことがありました。当時の責任者は「仕様変更に強い作業手順を発明した」とか言ってこれを活用すべく仕事をもらってきておりました。私も一作業者としてこれに従事しましたが、責任者のアイディアは「消せるボールペン」レベルのものでした。契約企業の担当者に相談したら怒って仕事を打ち切られました。仕様変更のリスクは技術面だけでないことを留意してください。
投稿2016/09/17 14:47
総合スコア4830
＞使う人間にも依ります
使う人間によらない（属人性を低くしやすい）のがOOPのウリだった気が・・・
＞「双方の合意」なく変更を行えば信頼問題
そういう話をしているのではありません。
＞仕様変更のリスクは技術面だけでない
だからそういう話ではありません。質問の主旨からだいぶズレた回答です。
0
面白そうな議論だったので、大規模プロジェクト視点で私の思うところを。
なお、もし質問者さんが大規模プロジェクトの関係者であれば、
1000人以上のエンジニアが身近にいると思うので、
現場で聞いた方が確実かと思います。
（立場によっては聞けないかもしれませんが）
でもOOPであれば、少なくとも仕様変更には強いはず。
なのに、なぜ失敗しまくるのでしょうか？
なぜ仕様変更のたびに膨大な影響範囲の調査・テストが必要なのか？
ある一部分の機能を変更するだけなら、そのクラスの単体テストだけでいいんじゃないの？
⇒仕様変更内容にもよりますが、
例えば、
「○○画面で出力される△△の帳票のこの項目の出力する仕様を
□から☆にする」ような内容であれば、
最初から影響調査が限定されている、と思うかもしれませんが、
これはこれで、単体試験で済むレベルでは収まらない影響調査が必要です。
たとえば、
「□から☆する部分は本当にこの帳票・この画面だけか」
「□の部分は他に参照していないのか」
「□から☆にするには、情報が十分そろっているのか」
「設計の内容・修正内容で、他への影響は本当にないかどうか」
etc...
上記以外にも、全くのど素人相手でも
「どう説明すれば、影響調査で問題ないと証明できるか」
という内容も考えなくてはならないので、
大規模であればあるほど影響調査には時間がかかります。
小規模であれば、「事前の結果がこれで、事後の結果がこれです」と言えば済む話かもしれませんが、
画面や帳票が500以上あるようなプロジェクトでは、
同じ項目がある他の画面や他の帳票等の事前と事後は？という確認が入るでしょうね。
確認する立場の人（品質を担保する人）はどんな作りをしているかなんて、関係ないですから。
しかし数百億円・数千億円規模のプロジェクトに関わるレベルの人ですら
上手な設計が出来ないのであれば、じゃあ一体誰なら上手に出来るのでしょうか？
現実的に「仕様変更に強い」という夢のようなことは期待できないのではないでしょうか？
⇒何を持って「上手な設計」とするか分かりませんが、
質問者さんの言う「上手な設計」が
『1画面・1帳票・1項目の修正があると分かっていない、かつ、予測も無理な時点で、
1画面・1帳票・1項目の修正の導入を1ヶ所修正して単体試験で終わらせて
リリースできるような設計になっている事』
を指すようであれば、誰にもできないでしょうね。
このレベルの要求になると、OOPは飛び越えて、
設計・製造・試験・リリース・運用・保守を全て人工知能化するとかでしょうか。
それだけで、莫大な費用と工数がかかりそうですが、
（最近流行の）人工知能を活用する場合でも、ビッグデータが必要ですから、
「仕様変更のビッグデータ」を作るとなると、当分、無理でしょうね。
（ここで触れてる実現の可否はあくまで簡単な机上の話です。）
また、大規模プロジェクトの中でも、仮に完全独立していて、
「単体試験してOKならリリースしてOK」という場所があったとしても、
「すぐ対応できた分、安くなります」ではなく、
「上手な設計」をした関係者（顧客含む）の単価を上げて欲しいなぁ、
と個人的には思います。
もしOOPが理論どおりに機能する概念だとしても、
開発に延べ何千人も関われば結局グズグズになっていくのではないでしょうか？
⇒そんなプロジェクトもありましたね。何社つぶれたことか。。。
とはいえ、何千人居てもうまく回ってる（大事なニュースにならない）
プロジェクトは表に出ないだけで、存在しているので、何とも言えないです。
少数精鋭でやったほうが速く安く正確に開発できるのでは？
⇒パレートの法則は無視されますが、机上はそうなります。
ただ、集める段階でうまく行かないと思われます。
100人に1人居るか居ないかのレベルの人は、
既に参加している現場が手放したくない状態でしょうから。
お金チラつかせて既に参加している現場を無視して、
ヒョイヒョイ乗っかってくれれば楽でしょうが、
人間には人情もありますので、
人探しだけで数ヶ月～数年かかるでしょうね。
また、少数精鋭の場合、誰か１人でも体調を崩す等で欠けたら、
スケジュールに大きく影響するため、顧客側が
リスク（スケジュール・追加費用等）に寛容にならないといけませんが、
納期絶対の官公庁系では無理でしょうね。
それと、開発をする上で、
「優秀な人がわざわざやらなくても良い作業」
「優秀な人でなくても出来る作業」
「優秀な人でも普通の人でも作業スピードの差が少ない」
というのが必ず存在します。
こういう作業をわざわざ超高給の人にやってもらうのは、
逆に費用対効果が悪いと思います。
また、保守性について、
ずっと続くような官公庁システムの場合、
いつまでもその優秀な人たちだけにやってもらうわけにもいかないので、
100人に1人居るか居ないかの「卵」を育てるor見つける必要があります。
その優秀な卵も途中でリタイアするかもしれませんが、
今後も安定したシステムを提供し続けるには、数千人のうちの数十人が必要不可欠と思われます。
数千人規模のエンジニアと言っても、
優秀でない人の中身はコロコロ変わっているので、
超優秀な人材数十人を雇う≒数千人規模の開発であることは割と理にかなってる気はします。
最後に半分ボヤキですが、数千人規模の開発において、
優秀な人材は他に行ってしまうリスクが大きいので、
所属している会社側でワークライフバランスをどうにかするか、
受注側で給料の配分はどうにかするか、
発注側で個別支給とかがあると良いのかもしれませんね。
投稿2016/09/12 19:53
総合スコア27
0
「なぜ少数精鋭チームで開発しないのか？」について、コメントします。
大規模開発では、多くのソフトウェアで構成されています。Javaのエンタープライズアプリケーションを構成するソフトウェアとして、Java VM、Java SE、Java EE、Java EEコンテナ、ミドルウェア、データベース、フロントエンド、統合開発環境等の開発・保守が必要です。
データベースとフロントエンド以外のソフトウェアでパッケージ化するにしても、多くのソフトウェア開発が必要なわけです。大企業であっても優秀な人材は限られていますし、大企業ほど多くの案件を受注します。そのため、特定のプロジェクトのために、優秀な人材をかき集めて割り当てるアイデアは非現実的です。
次に、皆さんも指摘されているとおり、大規模案件では、人月で受注しています。これも重要なポイントです。受注後、ほとんどのプロジェクトでは、「見切り発車」が多く発生します。たとえば、納期が近づいているため、「テストが十分とは言えないが、大丈夫だろう」で出荷してしまいます。品質を高めるのには膨大な工数がかかるため、常に工数が足りない状態で出荷しているのが現状です。
人月で受注しているわけですから、作業期間もおのずと決まっています。すると、優秀な人材は、プログラミング工数を短縮する代わりに、品質を高めるためにテストに時間を割きます。つまり、優秀な人材をかき集めても、生産性が単純に100倍、1000倍となるわけではないのです。
A社向けとB社向けの大規模案件が2つあり、ソフトウェア規模が同程度としましょう。では、A社には優秀な人材で6ヶ月で納期、B社には平均的な人材で12ヶ月で納期しましょうという商談で、顧客を納得させるのは難しいでしょう。皆さんも言われているように、優秀な人材も平均的な人材にも、同程度の給料で働いているという日本の風土を変えなければなりません。
問題は根深く、改革は容易ではありません。
投稿2016/09/20 06:53
編集2016/09/20 07:07退会済みユーザー
総合スコア0
どうしたら改革できるでしょうね・・・？
数十年も同じ問題で繰り返し悩んできているのに、なぜ改革できないのか。
誰が「甘い汁」を吸っているのか？
・能力が高い人が給料も高くもらえる
・納期が早いほど高く報酬をもらえる
・（発注側の）要求まとめ遅延や度重なる仕様変更はきっちり追加請求、公務員なら罰則
・人月での請求を法律で禁止
まあトップ（首相）が大統領並みに権限を持っていて改革する気持ちさえあればすぐやれるんでしょうけど、日本ではねぇ・・・。
エリート層にはびこる根性論と非効率な無駄の積み重ねについては、根本的には大東亜戦争時代から何も変わってない。
能力が高い人ほど給料をもらうためには、企業に「能力主義制度」を導入する必要があります。日本では最近は能力主義制度を導入する企業が増えていますが、能力主義制度の運用も非常に難しいものがあります。なぜなら、個人の能力を客観的に評価すること自体が難しいためです。
遅延への追加請求は、現実にあります。トラブル発生時に慰謝料を払うケースもあります。また、アジャイル開発では、度重なる仕様変更は前提ですし、ウォーターフォール型でも、仕様変更を受け入れて追加開発（収入を追加）とするケースもあります。
逆に教えてください。人月の請求を禁止する場合の代替案はありますか？
ちなみに、大規模案件ではウォーターフォール型が多く、アジャイル開発はまだ難しいと考えています。
大企業云々、法律云々は上の人に任せましょう。大規模アプリの開発者としては、たくさん学ばなければならないことがあります。OOP以外にも、ROA、OOA、ドメイン駆動開発、イベント駆動開発、CQRS等のアーキテクチャパターンも学ばれたほうが良いです。これらの技術を学ぶ過程で「なぜOOPだけでは問題が解決できないのか」が分かってきます。
「脱 人月」とかでググると過去さまざまな議論や提案がありますね。
そもそも人月でしか見積もりができないのは受注側の見積能力が低いせいですよね。
だったら受注側が見積もり能力を高め、人月ではなくて「これだけもらえば十分に利益が出る」という金額を決めるしかないですね。
どんな業界、どんな商品でも、普通は完全オーダーメイドについては「人月」で請求されないはずです。「それを作るには○○円もらいますが、いいですか？」でしょう。たとえばオーダーメイドの自動車を注文して、人月で請求するバカがいるでしょうか？
なんでITだけ人月で発注側も納得するのか謎です。
バカは言いすぎですよ。他の業界は工数の見積もりが簡単であるのに対し、ソフトウェアは簡単ではないからです。ソフトウェアの価格を決めるのに、どういう計算をするのか、それこそ難しい問題だと思います。
ともかく、大規模開発において、優秀な人材を揃えるのは困難であること、価格を決めるのが簡単ではないこと、さまざまな問題が横たわっています。
0
大規模、小規模、あまり関係ないと思います。
プログラミング言語の問題も、さほどないと思います。
仕様がキチンとしていれば、数年現場でプログラマやってればある程度人と同じぐらいに書けるでしょう。
エリートプログラマに任せば。。。なんて話も上がってますが、間違いだらけの仕様書で組んだ物は、誰がやっても間違いだらけです。
私は**「発注側にプロがいないための、仕様の不安定さ」という事が諸悪の根源**だと思います。
超小規模開発の現場で、それこそエクセルのVBAでこーゆーことをやってくれ、
という程度の仕事ですら、発注する側にエクセルVBAが多少でも使える人が担当についてくれるのと、
事務のおばちゃんが担当するのでは、全然かかる時間が違います。
同じ人間がプログラムをしても、相手の担当が多少物事をわかってるかどうかで、最終的にかかる時間は２倍、３倍となってしまうことはよくあります。たかだかそんな物ですら、です。
これが銀行などの「担当者も全容を把握しきれていない、よくわからないプロセスが複雑に絡み合って凄く面倒な案件」だったら、どうでしょう。何百倍、何千倍に悪影響が出ます。
面倒なシステムほど、しっかりと細かい部分までわかっている人が少ないのも事実です。
大規模な案件では、イの一番に実力のあるSEチームを送り込み、仕様のあいまいな部分を開発に入る前段階で潰していく事が、現実的には一番効果があり、工期を短縮できるのかもしれません。
投稿2016/09/20 04:43
総合スコア289
＞間違いだらけの仕様書で組んだ物は、誰がやっても間違いだらけ
いやだから、仕様書の段階からスペシャルな人だけでやってほしいなぁっていう。
＞「発注側にプロがいないための、仕様の不安定さ」という事が諸悪の根源
それが一番大きいですね。
そしてそれを知りつつも金をたくさん稼げるからと黙認している大手SIerも共犯者です。
＞何百倍、何千倍に悪影響が
そう、だからこそ発注側も受注側も「スペシャル人厳選、少数精鋭で」がいいのではないかと考えています。
＞仕様のあいまいな部分を開発に入る前段階で潰していく
もっと言うとあいまいな仕様を要求してくる無能な発注者を潰せたら一番いいんですけどね。
民間は無理としても、税金を投入するものに関してはそういう仕組みなり法律を作って、発注側の無能なヤツがあれこれ好き勝手な要求を出せないようにすべきです。技術がわかっている役人を経由しないと、たとえトップ層でも勝手な意見を出せないようにする。
0
オブジェクト指向やら言語を選定したら、勝手に仕様通りのコードが出来上がるわけではないですからね。
結局のところ、実装や設計の作業者のレベルによるってことです。
物は物、道具は道具で、手にした人間が正しく扱えるかどうかは別ですからね。
投稿2016/09/20 03:46
総合スコア12
それはそうなんですが、じゃあ誰ならOOPを正しく効果的に使えるの？っていう疑問です。
数百億円とかが動く規模のプロジェクトの人たち（≒レベルが高いであろう人たち）ですら何割か失敗するのだから、OOPって銀の弾丸ではないどころか鉄の弾丸でもないのでは？？？っていう。
OOPにすることによってまた別の問題（複雑さとか設計の難しさとか）が出てくるし、オブジェクト指向って共産主義などと同じく机上の理想論なのではと思ってしまいます。
0
オブジェクト指向は本当に変更に強いのか？
オブジェクト指向という道具を適切に使用することが出来れば、オブジェクト指向が出る以前に比べ、変更に強くしやすくなった、と言えます。
何故、このように歯切れが悪いかと言うと「オブジェクト指向」というもの自体は、あくまでツールの一つであり、使わない場合における「万人がよく陥りやすい問題」を、このツールの使用によって少なくする事は可能ではあるものの、同時に、このツールの使用によって新たに生まれた独特な複雑性も存在します。
毒の部分が強調されてしまうか、薬の部分が強調できるかまでは「オブジェクト指向」というツールは関与しない為「変更に強い」という言葉の文脈に応じ、そうとも言えるし、一概にそうとも言えない、とも言えてしまいます。
なぜOOP開発での失敗例が多発するのか？
このご質問の前提とし「でもOOPであれば、少なくとも仕様変更には強いはず。」という思い込みがあるように感じられますが、前述の通り、OOPであってもそうでなくても「仕様変更」というものは要求から設計に落としてコードに落とした過程そのものを覆す、上位の出来事です。（要求の変化、または設計ミスによる辻褄合わせ）
仕様変更の度合い次第では、OOPが適切に使用されていて助かったという局面もあれば、その仕様変更は勘弁…という仕様変更もあります。
しかし、どちらにしても、手を付ければ付けるほど乾燥した砂の城のように意図しない所からボロボロ崩れていく状態になりがちな可能性のある方法と、少しは水分を含んだ砂の城に手を入れるのと、どちらがマシかといったら後者でしょう。
変更に対する強度は、OOPを全く使用しないよりは多少マシというものです。
失敗例の教訓、改善法はあるのか？
それらの教訓から、模索しつつ進んでいる過程と考えます。
OOPの抱える問題点や、開発手法（今回の場合、大規模開発、ウォーターフォールモデルに絞ったほうがイイのかな…）が抱える問題点などを解消する為、OOP＋αの何かだったり、様々な開発手法が生まれています。
ただしここにおいても、やはり万能の銀の弾丸は存在せず、宇宙のしがらみによったり、今回はこれでよかれと思ったものがフィットしなかった、という不幸は付きまといます。
むずかしいですね…。
なぜ少数精鋭チームで開発しないのか？
・他社との差別化を要求するが故に共通パッケージのようなものでは済まない
・既存のシステムを完全置換できない、あるいは最低限連携できないと困る為、接合部は共通化できない
とか考えてみましたが、弱いですね。
流石に実績が無ければ任せづらい、という事実はあるにせよ、例えば歴戦のSIerで、いわゆる本当にデキる「公的システムや金融機関システムを開発する人たちの中でスペシャルに能力が高い人」達が結託し、過去のノウハウを集約し、パッケージ化した金融・公的システムに絞って作成・販売する集団が、自前で銀行作って運用し始めちゃうくらいの所から実績もひっさげつつ出てきたりしてもおかしくはないような気がしますが、それが出てこない理由が何かあるのでしょうね…。
投稿2016/09/17 18:57
総合スコア12
示唆に富んだ素晴らしいご意見ありがとうございます。
一つのご意見として非常に具体的で勉強になりました。
＞それが出てこない理由が何かある
既得権益層（大企業や役人など）のビジネス上・金銭上の理由だけだと私は思います。
そうでないとこの非合理な多層ピラミッドによる搾取構造と無駄な仕事の利点なんか本当は存在しないはず。
0
相対的な強さはあるんじゃないですかね。
仮に下記のようなシステムがあった場合、きちんとMVC分離されたシステムと比べてどちらが変更に強いかと言われたら、このサンプルの方が強いと主張する人はほぼいないと思います。
PHP
1<html> 2<body> 3<?php 4 if($_POST['data']) { 5 echo $_POST['data']['name'].PHP_EOL; 6 } else { 7 echo '<input type="name">'.PHP_EOL; 8 } 9?>
-
オブジェクト指向は本当に変更に強いのか？
上記のサンプルのようなシステムに比べてとても強いと思います。
が、限度はありますし、仮に「人間」Modelに「100mを5秒で走る」機能を実装せよと言われてもとても難しいでしょう。
どうしても実装する場合、「車に乗る」と言うような進化が必要になり、その場合は車の実装も必要になります。
そしてこの車は変更要件から生まれたモノであっても、新規で開発したモノになる為、人間が車に乗った時の挙動その他についてはイチから設計し、開発し、テストを行う必要があります。 -
なぜOOP開発での失敗例が多発するのか？
多くのプロジェクトは成功裏に終了しています。
だからこそ失敗した時に大きく取り上げられ、問題となるわけです。
そして、失敗しないために当然のようにOOA開発選択されていたので、それがOOA開発の失敗だ！と取り上げる方がいるわけです。 -
失敗例の教訓、改善法はあるのか？
ありますが、それはOOAという問題ではなくPMOの問題ですね。
そして大きなプロジェクトの場合、PMOよりも権限の強い、契約条件という問題が大きくなっています。
安心安全な国産無農薬素材100%で無菌室で調理された料理を提供する手法は多くの料理人が知っていて、実践する事も出来ますが、そんなことをやっていたら店の従業員に安定して給料を払えない事も併せて知っているわけですね。 -
なぜ少数精鋭チームで開発しないのか？
1000人月のプロジェクトを10人で開発すると、100か月かかりますが。
iPhoneが発表されたのでそれに対抗しようと開発を始めていたら、出来上がったころにはiPhone7が出来ていたという事になりますので。
投稿2016/09/12 04:29
総合スコア5405
＞1000人月のプロジェクトを10人で開発すると、100か月かかりますが
はい？？？？
どういう計算ですか、それは？
アホ１０００人が一ヶ月かかって終わらせる仕事（いいものが出来るとは言っていない）は、すごい人１０人がやると１００ヶ月かかるとでも言いたいのですか？
質問者ですら指摘しているとおり、どうみても頓珍漢な計算式です。
0
1.完璧なオブジェクト指向か中途半端なオブジェクト指向で変更に対する強みが明らかに違うと思います。
2.大規模なもので失敗例が多い理由はやっぱり下請け下請け下請けって感じの構造のせいでしょうか。
先の人が述べてる通り、伝言ゲーム（しかもやたら日程決めとかでコンタクト取れてない）で
日数を無駄に。小さな食い違いに気づけず後の工程でその食い違いが露骨にでて失敗。そんな流れ。
3.教訓はあるんでしょうが。対策は明確になるのに対し、「なぜ起きたのか」の原因について、
考えが及ばないor対策のしようがないパターンがあるのではないか。
それこそ、下請けの風潮だったり、やっぱり子会社が潰れないよう仕事を回すのも一次請けの仕事ですし。
このプロジェクトは自社だけで開発しますなんて言ったら既存のシステム運用が壊滅するかもしれませんからね。
4.その大規模案件以外に抱えてるタスクが多いのではないかな。
頻繁に顔だしたりしてないのだとしたら、それこそ伝言ゲームで正しい設計は難しいと思います。
最後に：素人意見です。
投稿2017/04/20 03:32
総合スコア382
0
ほとんど回答が付いていますが。
私の回答は初心者寄りの回答です。( その道のプロではないです。 )
オブジェクト指向にすればバグは出ないか。
そうではありません。
一般的に言われている「オブジェクト指向なら応用しやすい」というのは、
「バージョン等が上がり、中身を切り替えてもその部分だけ編集すればいいので応用しやすい」ということでは?
たとえば、
ITest インターフェースがあって、それを継承し、
Test1, Test2 クラスを生成します。
で、あるクラスの引数で ITestを受け取るとして、
Test1 を渡していたところを Test2 に切り替えとか。
デザインパターンをうまく利用すればオブジェクト指向は強みになると思いますが、
結局は作る人次第。(プログラマの腕による。)
そういうことでは?
投稿2016/10/25 10:16
総合スコア4958
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/11/20 04:58 編集
2016/09/12 04:00
2016/09/12 04:09
2016/09/12 06:38
2016/09/12 06:56
2016/09/12 09:30
2016/09/13 22:53