いわゆる「ソフトウエア開発プロセス」はソフトウエア工学の黒歴史

• 「ソフトウェアプロセス技術がロストテクノロジーになっている」 http://d.hatena.ne.jp/nowokay/20150312#1426122741

いや淘汰された結果，時代遅れな物が死に絶えただけ．1990年台には既に，いわゆる「ソフトウエア開発プロセス」は，工学ではなくカルト宗教やオカルトの領域に入っていた．

ソフトウェアプロセスというのは、「プロセスがよいソフトウェアをつくる」という前提のもと、どのようなタイミングでどのような成果物を作り、どのような管理をし、どのように検査をしてソフトウェアを作るかという手順です。

語るに落ちるというか，

「プロセスがよいソフトウェアをつくる」という前提のもと

が大前提なのに，その仮定が正しいことは立証されていません．だから宗教．

「アジャイルプロセスを採用する」という名目でなんら管理されないプロセスが普及しました。

ウォーターフォールマンセーな老害の眼には，そう見えるらしい．*1

時代錯誤も甚だしいな．

でも、すでにWebは成熟して、しかも作成するソフトウェアの規模が大きく複雑になっています。コンピュータの世界では完結せずに、外側の実ビジネスと連携することも多くなってきています。そうすると、あらかじめ決めることを決めてからソフトウェアを開発することも重要になります。

なんでそうなる．論理展開がおかしい．

「コンピュータの世界では完結せずに、外側の実ビジネスと連携することも多くなる」として，それで？世界で完結しなかったからといって，ソフトウエア開発の何がどう変わると主張したいの？*2外側の実ビジネスでなければ，それは何？内側の実ビジネス？それとも外側の虚ビジネス？

「決めることを決めてから」とかは逃げ道を作るためのための言葉だね．何を決めるの，それをどう決めるの，もし決めなかったらどうなるの．*3

レポートや論文でこんな非論理的な言い回しを使ってたら，書き直しを命じられると思うぞ．*4

Webが当たり前になった2005年あたりに25歳くらいで働きはじめた人が、今は35歳になって開発現場を先導する役割になっていると思います。しかし、そういう人は、「プロセスが重要」と言われた時代を知りません。

もっと古い時代からでも，「プロセスが重要」と騒いでる奴らがいた時代はあったけど，プロセスの重要性が立証されたことは無かったはず．そういう意味では，あくまでカルト宗教やオカルトのレベル．

Developer's Code　本物のプログラマがしていること (アスキー書籍)

ソフトウエアがディスクに記録されたコードを出荷することを意味していた頃にはまだ，計画を立てることには十分に大きな意味があった．でも，Webベースのソフトウエアはこれとは違う種類のゲームだ．コードの記述に取りかかる前に詳細な仕様を作成して，計画を立てる所にはよい所もある．でも，Webというメディアを最大限に生かしているわけでもない．新しいビルドが必要になったら，座り心地のよいアーロンチェアから，たいしたオーバーヘッド無しで1日に一度 ー 1時間に一度だって良いさ ー リリースできるんだから．

幸運にも，業界全体として，このメタファを打ち破ろうという動きが出てきた．アジャイル開発は革命的なものじゃない．単に，昔ほどには意味をなさなくなってるメタファから僕らを解放してくれるだけだ．従来のウォーターフォール型の開発が古くさいものであることはいうまでもない．それでも，大規模で複雑なソフトウエアプロジェクトでは未だにメリットもある．でも，疑問ももたずにこのメタファに追従しているようでは，自分が相手にしているメディアにあったやり方が見えなくなってしまうかもしれないよ．

「計画，計画，また計画」というメタファは，すべてを完璧に把握しようとするために費やす時間を過剰に高く評価し，実際のコードの記述に使えるであろう時間を過剰に低く評価しているんだ．

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup (Pragmatic Programmers)

プログラマのためのサバイバルマニュアル

The key advantage of waterfall is its predictability: everyone has a shared understanding of what's to be done, how long it will take, and therefore how much it will cost.

Waterfall has a couple key vulnerabilities, too: first, when new invention is involved, it's impossible to tell at the outset of the project what tasks will be required or how long they'll take. Programmers must resort to gussing, and the compounded effect of hundreds of guesses is a huge wild-ass guess. At best.

Second, warterfall leaves testing until the end. Technically, that testing is supposed to be a verification test, and there should be few surprises. It never works that way. In practice, engineering gets slack on quality - especially whole-system integration - because they assume the test phase will shake out the bugs.However, finding and fixing bugs becomes increasingly difficult as the software gets larger and worse when it's supposedly "done."

http://d.hatena.ne.jp/JavaBlack/20120505/p1

テストから見えてくるグーグルのソフトウェア開発

この難問を単純に解きたければ，開発とテストを別々の物として扱うことを止めることだ．テストと開発は共に前進していくものだ．少しコードを書いたら，それをテストする．そしてまた少しコードを書いて，テストする．テストは開発と切り離してやることではない．開発プロセス自体の一部なのだ．品質はテストではない．品質は，開発とテストを互いに区別できなくなるまで融合することによって実現される．

グーグルではまさにこれを目標にしている．開発とテストを融合して，片方だけでは出来ないようにしているのだ．少しコードを書いたら，それをテストする，そしてまた少しコードを書いて，テストする．ここで大切なのが，誰がテストするかだ．グーグルでは専任テスターの数が極端に少ないため，答えの選択肢はデベロッパーしかない．実際にコードを書いた人間以上に，テスターとして適切な人はいるだろうか．バグを入れた人以上に，バグを見つけると言うことで適切な人はいるだろうか．最初からバグを入れないようにしようという気持ちがもっとも強いのは誰だろうか．グーグルが少数の専任テスターでやっていけるのは，デベロッパーがオーナーとして品質に対して責任を負っているからだ．社外に出た製品が問題を起こしたとき，最初に苦情が届けられるのは，問題を摘出できなかったテスターではなく，問題を作りこんだデベロッパーである．

Code Complete 第2版 上　完全なプログラミングを目指して

3.2.1 反復型手法への準備

反復型の手法を用いるプロジェクトは準備に重点を置く必用はまったくないと断言している文献もあるが，その考えは誤った情報に基づいている．反復型の手法は，上流の作業が不十分な場合の影響を緩和するものの，完全に排除するわけではない．

3.2.2 反復型か，逐次型か

ソフトウェア自体については，逐次型よりも反復型の方がはるかに効果的だろう．反復型ならば，必要に応じて公式と非公式を使い分けたり，完成度を加減したりしながら，プロジェクトに適した準備を整えることが出来る．

なお，ウォーターフォール管理の現実も，実際は「なれる！SE」や「PRESS ENTER」みたいだったりする．

なれる！SE4 誰でもできる？プロジェクト管理 (電撃文庫)

「別府さんは……どんな進め方されたんですか？」
興味本位で尋ねると，だが薬院は顔を曇らせた．
「『とりあえず仮だから』と線表を引いて，実際に納期が迫ると『今更変更はきかない』『約束した以上，徹夜でもメンバー追加でもして乗り越えて下さい』―― そう言ってくる人でしたね」
うへ．
「『後でいくらでも変更きくから』が常套句なんです．大丈夫，変更には柔軟に対応しますと言っておいて一度受け入れたら最後，コスト・休日度外視で作業させられる．だから私たちもこのお客さんには絶対見積書ベースでしか対応しないようにしてるんです．下手に融通を利かせたら以降，奴隷のようにこき使われますから」
「……」
なるほど……当初，薬院含めプロジェクトメンバーがかたくなだった理由はコレか．一歩でも譲歩した瞬間骨の髄までしゃぶられる．限界寸前まで無理難題を押しつけられる．不信，恐怖，警戒．負の感情がベンダー間に渦巻いてる．まったく，どこが切れ者ＰＭだ．とんでもない恐怖政治だった

PRESS ENTER 冷たい方程式（6） 「強者の論理」

　「当然だ。内容は私がチェック、承認する。見積もりは出してもらって構わない」
　「分かりました」あたしは受話器に手を伸ばしたが、渕上マネージャの話はまだ終わっていなかった。
　「ただし、1本につき1人日だ」
　「1人日ですか？」思わず声が高くなった。「1画面の詳細仕様書を1日で書けというのは無茶だと思いますが」
　「1日で書けとはいっていない。追加の工数としてカウントしていいのが、1人日分だけ、ということだ。実際に何日かけようが、それはホライゾン社の都合だ」
　「それじゃ、ホライゾンさんの損害になりませんか？」
　「うちの損害ではない」それがすべてだ、と言わんばかりの口調だった。

　あたしは天を仰いだ。

　「ちなみに、どの程度の仕様書を書くことを想定されているんでしょうか？」

　渕上マネージャは、その質問を予測していたらしく、1枚のプリントアウトをあたしに渡した。それを見たあたしは、軽いめまいに見舞われた。

• 機能概要
• ロバストネス図
• シーケンス図
• クラス図
• 画面レイアウト
• 項目定義
• 処理定義
• テスト項目

　前の会社でも詳細仕様書は必須だったが、ここまで細かく作成したことはない。これだけの仕様書を真面目に作成していたら、それだけで軽く2〜3日は費やしてしまうだろう。

　「こんなに書くんですか？」
　「君が書くわけではない」
　「分かってますが、これだけの量の仕様書を書く工数が、1人日というのはいくらなんでも……」
　「ホライゾン社の問題だ」渕上マネージャは、すでに興味をなくしたようにモニタに目を戻した。「先方に伝えたまえ」

　――自分で伝えろよ。

　「こういうのって下請法に抵触しませんか？」あたしは別の方向から攻略を試みた。「“買いたたき”に該当するんじゃ……」

　「再見積もりを行わずに、一方的に単価を決めれば抵触する」渕上マネージャは、あたしの浅はかな理論武装をあっさりはねのけた。「今回は、再見積もりを認めているのだから問題はない。早く伝えたまえ」

　あたしは諦めて受話器を取った。ユダになった気分だった。今でも報酬の相場は銀貨30枚なんだろうか。

http://el.jibun.atmarkit.co.jp/pressenter/2012/02/6-efec.html

現場を見たこともない雲の上の人たちはウォーターフォールで管理したつもりかもしれないが，実際は下請けいじめやパワハラで現場を脅迫して納期を守らせてるだけ．*5ウォーターフォールがスケジュールを管理しているわけじゃないし，ましてやウォーターフォールにより品質が上がるわけでもない．

http://b.hatena.ne.jp/entry/d.hatena.ne.jp/nowokay/20150312%231426122741

• id:oaruR あたかも、かつては確立されていたかのような印象を受ける

でも，そんな時代は無かったんだよね．一度も．

• id:te2u アジャイルプロセスも立派なプロセス技術だと思うけど。サイズは違うけど、１つのイテレーションで行うことはウォーターフォールとさして変わらない
• id:deep_one 最近は「プロジェクトマネージメント」と言っているだけなのかもしれない。成果物・管理・テストの大半は含まれる気がする。

• id:minamishinji 確かに最近プロセスについていわなくなった。とは言っても、ウォーターフォールを「基礎」にするのはどうなのか。
• id:harabu おかしな方向に進化した「ソフトウェアプロセス神話」なら知ってるよ。テクノロジーじゃなくて人海戦術だったから「神話」としか言えなくて、夏。夏じゃない。30年くらいこういうことやってるはずだなー。

• id:a_micchan CMMIとかISOの形で存在はしているが、具体的な内容は大半が非公開だからWebで見えないだけ。所謂フロントWeb系の小規模アジャイル開発しかやってない人達はこの点を見逃しているだけでしょう。

• id:orihime-akami ウォーターフォールはもはや本に書くまでもないくらいに世の中で普及したということでは。ただ、あらゆるアジャイル開発にもウォーターフォール的要素はあるし、逆もあると考えると、まだ掘り直す余地はあるんだが。

いや，むしろ物笑いの種になってる．たしかに日本のSIerでは広まってるようだけど．

少なくとも「ウォーターフォールが王道で，それを守ることがソフトウエアの品質を良くするんだぁああああ！！」なこういう人は時代錯誤すぎる．

• id:Rinta CMMIとかその辺の話題。めんどくさいんだけどね！ でも大事な事。特に社会的に重要な仕組みにおいては。みずほが二の轍を踏む事は許されないんだ。

あれの失敗は開発プロセスとかあんまし関係無いでしょ．むしろ社内政治や金の話．

• id:okusa75 「ソフトウェアプロセス」っていかにも和製英語っぽい響きだな。

むう言われてみれば．

Software Process (Trends in Software, 4)

Software Process Definition and Management (The Fraunhofer IESE Series on Software and Systems Engineering) (English Edition)

The Process of Software Architecting (English Edition)

Unified Software Development Process, The (Addison-Wesley Object Technology Series)

他の言い回しもあるにせよ，無いわけではなさげ．

あと，Rational Unified Process(RUP)なんかも有名でしたね．

ラショナル統一プロセス入門 第3版 (ASCII Software Engineering Series)

ラショナル統一プロセスによるJ2EEアプリケーション構築 (新紀元社情報工学シリーズ)

The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP (Addison-Wesley Object Technology Series) (English Edition)

IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP) (IBM Press)

むしろこの話題で，なんでRUPが出てこないか謎．

Twitter

激しく同意．

へー，わかるんだ．．．．へー．

Webでウォーターフォール管理で作ったら，商売にならないどころか大赤字で会社が潰れるよ．ついでに開発者も．

*1:この人が不思議なのは知識の偏りは若い人っぽいのに，こういう発言が絵に描いたように典型的な老害なところかな．畑違いの分野から知識無しでSIerにやってきて，そこで洗脳されちゃった口なのかな．

*2:実際には完結しようとすまいと千差万別十人十色．

*3:「決めるべき事を決めてから」なのはアジャイルでも同じなんだけどなあ．むしろ「今決めるべきでないことまで決めてから投機的に実行する」ことが，ウォーターフォールの非効率性の一因にもなっている．

*4:たかがブログだからちょっとくらいおかしくても許容範囲だけど，この日の日記への信用が失われることには変わりない．

*5:これも日本のIT業界がブラックになる要因の一つ．構造的問題であるために，業界まるごと潰してやり直さない限りは解決することは不可能．