なぜWEB系企業ではソフトウェアプロセス技術が流行らなかったのか

ソフトウェアプロセス技術がロストテクノロジーになっている - きしだのはてな

プロダクト特性にあわせ開発プロセスを定義する、成果物を定義する、開発手法と体制を編成するなんてblogに書くとたまに?な反応があるので納得感がある。web企業だとロストしてるのか。。。

2015/03/12 11:37

自分でコメントしたあとふと思うことがあったのでまとめ。

ソフトウェアプロセス技術とは

話の前提として、ソフトウェアプロセス技術を定義しなければ始まりません。

といっても、組織によって微妙に使われ方が違うのでアレなんですけど、ICSSPに則れば、ソフトウェア開発における開発工程（プロセス）の

• モデリング
• 計測分析
• 管理

を行う技法と思っていただければOKです。

要は、ソフトウェア開発工程自体の定義と分析、管理により組織やプロダクトにマッチした最適な開発手法を求める技法（メタプロセスマネジメント）と考えるとわかりやすい。

よく言われるCMMIは、上記のソフトウェアプロセスに対して、それ自体を管理するメタプロセスの達成レベルを問うものです。

ちなみに、プロジェクトマネジメントと混同されがち。でも、プロジェクトマネジメントでは契約やソフトウェアプロセスの範囲外で発生するリスク管理等の概念もマネジメントの対象としているので、共通の概念がいくつかある、ぐらいだったり。

あと、何故かソフトウェアプロセス技術＝ウォーターフォール開発プロセスを厳格に守ること、と勘違いされがち。

うろ覚えなんですけど、自分の周りだとJ-SOX法で内部統制強化なんて叫ばれた時に「とりあえずウォーターフォールの開発工程ごとのチェックを厳格におこなえばいいんじゃね」ぐらいの感覚で管理統制を強化しようとして混乱した記憶があります。

この場合のソフトウェアプロセス技術は「管理」だけの話に留められることが多いんですよね。

なぜWEB系企業ではソフトウェアプロセス技術が流行らなかったのか

さて、ここについての考察ですが、残念ながらWEB系の組織に所属したことが無いため、直接的に理由を知ることができません。

なので、公開されている情報からソフトウェアプロセスの分析により類推してます。

１．自社サービスが中心で、そもそもプロセスを変える必要性が薄い

同じプロダクトであれば同一のプロセスを利用するのが最も理にかなってます。

したがって、受託開発のような案件ごとにプロダクトが異なる開発を行っているSIerを中心とした組織よりも、一点もののプロダクトを作っているWEB系組織ではプロセスを変える必要性が無いのでは、と思います。

２．扱うWEBサービスはDOA型のモノリシックなアーキテクチャが多い

色々見聞きするWEBサービスのアーキテクチャですが、大雑把に分類するとDOA型のアーキテクチャか、それに類似した形をよく見かけます。また、ドメインもそこまで複雑じゃないように見えます。このようなプロダクトでは、特段データの整合性など気にしなくても良いため、ドメインに応じたソフトウェアの修正、追加開発も端々に分散した形で実現可能だったりするんですよね。

それが丁度採用していたアジャイル開発とマッチしていたため、「プロセス自身を変える」という考えは生まれづらいのじゃないか、と思います。

実際、DOA型からSOA型/OOA型のmicroserviceといった分散アーキテクチャが採用されるようになってウォーターフォール型の管理が必要な事例*1がでてたりも。

氏の経験では、これを達成するための課題は、多くの組織がプロダクトマネージャや開発者、品質担当者などの独自チームで構成されており、何かを成し遂げるためには、多くのミーティングやウォーターフォールのアプローチを取らざるを得ないことだ。

マイクロサービスの現在

３．少人数内製が多く、「自己組織化」や「メンバーマネジメント」といった言葉で代替された

WEB系企業だと、内製が中心と考えてますが、こういった内製が中心なモノリシックな組織だと、組織をまたいだプロセスやアグリーメントを多人数でとる承認プロセスといったプロセスが発生しづらい組織構成になっています。

ステークホルダーが「自社の開発メンバ」以外にほとんどないのであれば、わざわざプロセス改善という考え方を導入しなくても「自己組織化」や「メンバーマネジメント」「チーム改善」等の考え方でも、組織活動を改善することができます。

とまあ、ざっくりとですが上記のような話がソフトウェアプロセスの考え方から導けます。

つまり、「当初から利用していたアジャイル開発がWEBサービス開発にあまりにもマッチしているため、プロセスを変更するという考えが不要だったのでは」と思ってます。

あとは。。。ただの個人の感想ですけどブコメとかブログとか見るに、志向の違いもある気がします。

ソフトウェアプロセス技術って典型的なエンジニアリング技術じゃあないですか。結構泥臭。

でも、ブコメやブログ見るにウェブ系のエンジニアって、エンジニアリング志向の「エンジニア」と言うよりか、テクノロジー志向の「テクノロジスト」に見える。

全員とは言わないけど、SIerよりは比率は高そう。

なので、ソフトウェアプロセス技術は忌避されがちだろうな、とも思いました。

なぜSIerではソフトウェアプロセス技術が職人芸となりがちなのか

では、WEB系組織では流行らなかったソフトウェアプロセス技術ですが、SIerで流行ったのか、というと微妙。

まず理解しなければならないのは、SIerで利用されているとされるウォーターフォールは既にウォーターフォールではないって事実です。

実際に、いろんな開発の現場を散々見てきましたが、名目上ウォーターフォール開発と呼んでいたものの、ウォーターフォール開発を厳密な意味で守っている開発の現場はとんと見たことがない。

実は、SIerでは「ウォーターフォールの裏プロセス」が存在してます。

オープン系の開発でウォーターフォール開発をし、それなりに成果を出しているように見えるプロジェクトには、いままで挙げたようなリスクをヘッジするための裏プロセスが存在する。

　その裏プロセスを表プロセス化すると、それはもはやウォーターフォール開発ではない。筆者の感覚でいうと、反復プロセスとも違う。一般的な裏プロセスを含むウォーターフォール開発は、並行開発プロセスのようなものに近い。

ソフトウェア開発の匠（3）：「現状のソフトウェア開発は間違っていないか？」（プロセス編） (3/3) - ＠IT

まあ、昔からウォーターフォール、ウォーターフォール言われてますけど、やっぱり失敗することも多い開発手法なので、現場の知恵で案件に合わせて独自の開発手法として定義するってことが当たり前のように行われてます。

あるものはスパイラルモデルにそっくりだったり、またあるものはまんまアジャイルだったりと、現場現場に応じて使わけるのが当たり前となっております。

アジャイル開発の技術講習がアジャイルの専門家からされた時も、「それは今現在の開発手法と同じじゃないか」という感想がよくでるんですよね。そんなこともあり、オッサンの周りではアジャイル開発だとむしろ案件の大小・複雑さの変化に対して対応しきれない（アジャイルのアジリティの限界）ってことで積極的に採用されない場面もあるんですよね。余談ですけど。

つまり、ソフトウェアプロセス技術の中でも「プロセス定義」については当たり前すぎて技術としてあまり認識されてないって感じです。

じゃあ、SIerではソフトウェアプロセス技術を使いこなせているか、というとそんなこともない。

なぜそのプロセスなら成功するのか、どうしてそのような特殊なプロセスが必要なのか、を計測・分析してなかったりすることがほとんど。リーダやマネージャの勘だったりすることも多い。こういうのがSIerの秘伝のタレと呼ばれている技術だったりして、場合によっては「○○社が独自に定義した開発手法で、他社には真似できない」なんて呼んでいたりする原因だったりもします。

ちなみに、元記事にもあるように若手のうちはプロセスの「管理」を徹底的に叩き込む反面、「プロセスの構築」はプロジェクトリーダ以上から、「分析・計測」はそもそもやらないってことも多い。 

つまり、技術と呼ぶには中途半端で未成熟な場合が多く、あまり使いこなせてないなあって印象なんですよ。

ざっくりまとめると、全体的には「ソフトウェアプロセス技術は確かに存在し、部分的には使われているけど、メタプロセス管理の視点が弱く、工学的手法ではなく、職人技的手法となっている」って感じ。

ソフトウェアプロセス技術って結構面白い

まあ、ソフトウェアプロセス技術って「管理」だけの観点で語ると非常につまらないし、人によっては苦痛にしか感じないんですけど、「構築」や「分析・計測」まで含めると結構おもしろんですよね。

感覚的には、ソフトウェア設計に近いし、プログラミングの感覚に通じるところがある。

自分なりにはいくつかのプロセス設計パターンを作れたりもして、それらの中から比較的有効なプロセスを過去記事で紹介してました。

サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ

メタプロセス管理という考え方を持つと、上記のようなプロセス設計もできて面白いですよ。

 ã¾ã¨ã‚

 é•·ã„。ダラダラ書きすぎました。疲れたのでこのくらいで。

 æœ€å¾Œã«ã€å…ƒè¨˜äº‹ã®å†…容に少しだけ触れておきます。

でも、すでにWebは成熟して、しかも作成するソフトウェアの規模が大きく複雑になっています。コンピュータの世界では完結せずに、外側の実ビジネスと連携することも多くなってきています。そうすると、あらかじめ決めることを決めてからソフトウェアを開発することも重要になります。もちろん、ユーザーの触る部分は早いリリースや試行錯誤が重要でもあります。きっちりしたプロセスときっちりしてないプロセスを混合してまわしていく必要が出てきているように思います。 

これが現実に起きているのならば、WEBサービスの世界もゲームのルールが変わったってことかな。であれば、ソフトウェアプロセス技術が、変化したルールに対応するための手法として必要となるのもわかります。

オッサンが過去記事で記載したハイブリッドアジャイルが参考になりそうな気がする。

ま、前述したようにソフトウェアプロセス技術の話って面白いので、勉強する価値はあるんじゃないかな、なんて。

なお、CMMIから内部統制に拘ると沼に入り込むので注意したほうが良いかな。

※管理原理主義者は扱いづらい。。。

以上

ソフトウェア・プロセス改善のROI―プロジェクト・マネジャーとソフトウェア・エンジニアのためのメトリックス

*1:この話は事前に予想できてたんですけど、実際に当たると嬉しい。問題に合わせてアジャイル、ウォーターフォールを工夫することが肝要だよね - プロマネブログ