要求開発はSIerを幸せにするか
要求開発サミット2006に参加してきた
要求開発サミット2006に参加してきた．参加の直前に慌てて書籍「要求開発」を購入し，斜め読みで予備知識も詰め込んだ．これらを通じて大いに刺激を受け，色々なことを考えたり感じたりした．その一つをここに書いてみる．
私の問題意識
以前にid:kuranukiさんの記事を読んだ．
これには強烈なインパクトを受けた．前々から感じていた問題が明確に表現されていた．
私自身，手前味噌で恐縮だけど以前に次のような文章を書いてみたこともある．
SIerはどうしてもディフェンシブにならざるを得ないという構造的な欠陥を抱えていると思う．この欠陥を抱えたまま要求開発 OpenThology を導入して，果たしてどこまでSIerは幸せになれるのかな？というのが私の問題意識．
つまり，要求開発や OpenThology そのものに関する議論ではない．論点は「SIerを幸せにするか」であり，要求開発そのものではない．
それから，情けないことだが，自分の意見にそんなに自信があるわけじゃない．「こんな風に感じたんだけど皆はどう思う？」みたいな感じ．ツッコミ歓迎です．
目的と手段の連鎖
要求開発のキモは「目的と手段の連鎖」にある，と感じた．要求開発アライアンスは「正しくない要求を正しく作っても意味がない」というメッセージを発している．では「正しい要求」とは何か．それは，経営戦略という「目的」からシステムという「手段」まで途切れることなく連鎖している要求である，と主張する．つまり最上位の目的から最下位の手段までが「通電」している必要があるのだ．
そこまで情報を開示してくれるのか
「正しい」要求を開発するためには，相手の業務を深く理解する必要があるはず．相手の業界に特殊な事情なども理解しておく必要があるだろう．時として業務・業界だけでなく，もっと「ウェットな」部分も理解する必要もあるかもしれない．つまり相手の社風とか，各部門間の力関係とか，各ステークホルダーの狙いとか．
しかし，ユーザー企業がSIerにどこまで情報を開示してくれるものだろうか．私の少ない経験では製造業と仕事をしたことがあるけれど，彼らはちょっとした情報やデータの開示にも神経質だった．非常に厳しい秘密保持契約を迫られることもある．ましてや，経営戦略のように重要な情報をSIerに開示してくれるものだろうか．それよりは，ユーザー企業側である程度要求を纏めてしまって，それをSIerに発注するというスタイルのほうが想像しやすい．・・・この辺りは経験が浅いのでよく分からないのだけれど．
仮にSIer側から情報開示を説得するとしたら，経営戦略にとって情報システムが如何に重要かを訴えるしかない．経営の根幹に関わる重要なことなのだから，どうか私たちも仲間に入れてください，と．
自分の首を絞める？
この説得方法は自分の首を絞める危険性があるように思う．この説得におけるSIerの狙いはこうだ．即ち，ユーザー企業の経営の根幹にまで入り込んだパートナーの地位を獲得し，Win-Winな関係を築いていきたい．
しかし，情報システムが経営の根幹に関わると深く理解した経営者は，次のように考えるのではないか．「ならば自社内に情報システムの開発部隊を整えてしまおう」と．情報システムがコアコンピタンスに直結するのならば，その開発部隊を自社内に用意するのはごく自然な考えに思われる．こうなってしまうと，結果としてSIerに外注される部分は縮小されてしまい，SIer自身の首を絞めることになりかねない．
要求開発をSIerが手がけるメリットはあるか
SIerが関わるメリットは，様々な要求開発の経験や知識を再利用することで，要求開発の高品質化・低コスト化が期待できることだ．SIerが多数の企業の要求開発を経験することで，アナリシスパターンのようなパターンや，あるいは「要求パターン」とでも呼ぶべきもう一歩進んだパターンを学習できる可能性がある．これはSIerにとって強力な資産となりうるし，ユーザー企業にとってもSIerに依頼するメリットが出るのではないか．
しかし，私の脳内シミュレーションではまたしても悲観的な結果が出てしまった．
＃ 私はもう少しポジティブシンキングを学ぶべきかもしれない．．．
前述したように，SIerの強みはＡ社の案件で得た経験や知識をＢ社の案件に再利用できることにある．しかし，これをＡ社が歓迎するだろうか．知識の再利用が可能ということはＢ社はＡ社にとって競合他社である可能性が高く，知識をＢ社に再利用されてしまうことはＡ社にとっては歓迎できることではない．従って，何らかの契約で同業他社へのビジネスを制限される可能性がある．結局，一つの業界でパートナーを組めるのは一社だけ，という制限がついてしまいそうな気がする．
また，知識が再利用できるレベルまでパターンとして整理される頃には，その知識は陳腐化しているような気がする．つまり「その業界では知っていて当然」という知識になっていて，経営戦略のレベルに直結するようなパターンにはなりにくいんじゃないか．「業界の常識」に遅れている企業が追いつくためには使えるかもしれないが，オフェンシブに業界をリードする知識にはならないんじゃないか．
垂直統合か水平分業か
現在の，ユーザー企業がSIerに発注する，という構図は水平分業的な構造だ．この構造はソフトウェアの飛躍的な品質の向上とコストの低下をもたらした．「飛躍的な品質の向上」などと書くと反論が山ほど返ってきそうだが，ソフトウェアの世界には非常に安価（時としてフリー）で非常に高品質なコンポーネントが沢山あるし，オープンな規格も沢山ある．これは水平分業的な構造が生み出したものだと思う．垂直統合的な，自社用のシステムをすべて自社で開発するような構造では，このような高品質化・低コスト化は実現されなかっただろう．そういう点ではソフトウェア業界は十分胸を張っていい．
水平分業のメリットというのは「再利用」や「シェア」という言葉で表現されるものだ．ある技術の確立に巨額のコストがかかったとしても，その技術をあらゆる業界でシェアできれば個々が負担するコストは小さく済む．こうすることで，高品質のコンポーネントを安価に提供することが可能になる．このメリットは，コピーが簡単（製造コストがゼロ）であるソフトウェアの世界で特に顕著だ．だからこの世界ではここまで水平分業モデルが浸透し，オープンな雰囲気があるのだろう．
しかし，水平分業のメリットは要求開発の分野には活かせないと思う．先述してきた理由により，要求開発では「再利用」や「シェア」は上手くできないと思うからだ．それよりも垂直統合型に移行したほうがメリットが大きい．
というのは，要求開発では目的と手段の連鎖が重要だから．つまり，縦の連携が重要なのだ．ならば要求開発チームも縦に切ったほうが有利に決まっている．即ち垂直統合型だ．垂直統合型なら，目的と手段の連鎖がステークホルダーをまたがない．だから目的と手段が断絶しにくい．阿吽の呼吸も伝わりやすいかもしれない．
垂直統合型への揺り戻し
「ウェブ進化論」の著者である梅田望夫氏は，Googleは垂直統合型の企業だと言っている．垂直統合型といえばかつてのIBMだ．IBMはハードからソフトまですべてを自社で開発した．次にMicrosoftやIntelが登場した．これによりソフトとハードで分業する水平分業モデルが確立した．そして今，Googleの登場で再び垂直統合型への揺り戻しが来ている．Googleは一見ソフトウェアの会社にしか見えないが，実はハードウェアも自社で開発しているそうだ．
参考：Googleとオープンソースの知られざる関係 | 日経 xTECH（クロステック）
これと似たようなことがあらゆる業界で起こるかもしれない．例を考えてみよう．ReDA家具販売（株）は表向きは家具を販売する企業だ．しかし社内には独自の情報システムを備えていて，それが競争力の源泉となっている．そのシステムは自社で抱えている開発チームが開発したものであり，今もメンテナンスされ続けている．開発チームは家具販売の業務を熟知しており，経営戦略を素早くシステムに反映することが出来る．つまり，ソフトウェア技術がReDA家具販売の中核を支えているのだ．ReDA社はソフトウェアは販売しないが，内部にはソフトウェア会社としての顔を隠し持っている垂直統合型の企業なのだ．．．
こういった垂直統合型の企業を想像するとき，要求開発 OpenThology は上手く機能するように思える．しかし，水平分業型のSIerが要求開発で活躍する姿を，私は上手く想像できない．
要求開発はSIerを幸せにするか
結局，要求開発とはユーザー企業自身のためのものであり，SIerのものではないと思う．SIerがアドバイザーとしてコンサルタント的に参加することはあっても，主導権はユーザー企業自身が積極的に握らないと要求開発は失敗するだろう．
そもそも，経営戦略からシステム要求までを通電させるという要求開発のコンセプトは，非常にオフェンシブな性格が強いものである．ここにディフェンシブな性格を持つSIerが主導してもあまり良い結果は生まないのではないか．ディフェンシブな性格を持つSIerにはディフェンシブなシステムしか開発できないと思う．
別にあらゆる企業が垂直統合型に移行するわけではないし，水平分業型のメリットが消えてなくなるわけでもない．しかし，徐々にSIerがカバーできる範囲は変化（縮小）していくんじゃないかな，と思う．あまり悲観的なことは書きたくないけれど，要求開発というコンセプトがSIerの幸せに直結する，というほど楽観的にはなれない．
何かあるとすれば，それは垂直統合が有利とも水平分業が有利とも言い難い「メゾ領域」ではないかな．要求開発では垂直統合が有利といっても，どこかのレベルで水平分業型のSIerにバトンタッチする必要がある．その境界前後のメゾ領域でSIerに何が出来るか，考えていく余地があると思う．
オフェンシブなSIerを目指せ
ここまでは，SIerにとっての要求開発に関して悲観的な意見を述べてきた．悲観的な意見で終わるのは嫌なので，前向きな意見を書いてみたい．
何故悲観的になってしまったかといえば，SIerをディフェンシブなものに位置づけていたからだ．何故ディフェンシブかというと，要求開発ではシステム開発は下流に位置するからだ．下流に甘んじる者はどうしてもディフェンシブにならざるを得ない．
SIerがオフェンシブになるためにはどうすれば良いか．一つの選択肢はSIerが要求開発にまで食い込むことだが，これは今まで述べたように私はちょっと悲観的．そうではなくて，システム開発を逆に上流に持って行くような努力が必要なんじゃないかな．あるいは，鮭が川を上るように下流から上流へ攻め上がる．技術側から積極的にアイディアを提供して，ビジネス側を変革していくのだ．かつて下流工程だったテストがテスト駆動開発によって脚光を浴びたように．
つまり，要求開発も攻める．システム開発も攻める．この２つの流れがぶつかるところに，何か大きな価値がある気がしてならない．その価値を捕まえるためには，SIerも攻める武器を持たなくてはならない．オープンで標準化された技術を追いかけているだけではその武器は手に入らないんじゃないか．技術者がもっと自分自身の頭でアイデアを考えて，ビジネス側に積極的に提案していく流れが必要なんじゃないか．その先にSIerの幸せがあるように思う．
