2015年09月15日

SIerの未来は明るい?

XP祭り2015に参加してきました。スタッフの方々お疲れ様でした。今回は、あまり外に情報が出てくることがないと思われる、社内SE業で成果を出すために実践してきたことを発表してきました。

前のブログのエントリーでも書きましたが、今回考えさせられたのが岩切さんの発表の「在庫切れのメカニズムの原因となる事象を把握していたのが、社内の情報部門の人間だけだった」ということです。また、その後の質疑でも、「金融系もそうだった」という話が出ました。ここで説明したいと思っていたのが「業務はどんどん狭く深くなる」ということですが、内容が膨れてきたので前のエントリーに分けました。

だいたいビジネス書とかで語られているような仕事効率の基本原則は、同じ時間で成果を上げるためには、儲かる部分にフォーカスして儲からない部分は削るということです。時間あたりのビジネスの効率があがれば、忙しさを抑えてインカムも増えてハッピー、歩合制の仕事であれば、空いた時間でさらに多くの仕事をこなせて2倍美味しい、というストーリーです。実際には、サラリーマンだと後者のインセンティブはなかったりもしますが、だいたいそんな感じの内容が多いですよね。

儲からない部分を削るには、うるさいだけでお金を出さない客を切るということと、定型的な仕事は自動化/省力化するという主に2つの方法があります。省力化/自動化は脳の力をなるべく使わない(脳で酸素をムダに使わない)方法と言い換える方法がありますが、コンテキストスイッチを減らしたり、繰り返しのルーチンワークを効率化したり、情報の伝達のムダを減らすにはコンピュータが活用があります。企業としても利益率向上は存在理由に直結する部分なので、がんばる時間を設定したり、ITに投資したりして改善をします。分業を徹底的に行なって1つのタスクにフォーカスして成果をどんどん上げる、そして他の人との情報のやりとりは必要最低限にフィルタリングされて、余計な情報に煩わされることはない、という姿が理想型でしょう。

企業が意思を持ってそのような変革をしなかったとしても、仕事をする中でそのような方向への変革のフォースは常に発生しています。Aという仕事が得意な人と、Bという仕事が得意な人が同じチームにいれば、自然と分業されていきます。「相手を信頼して任せる」「現場に権限移譲」が成功の秘訣です。

このように業務内容が変わらないと想定しても、分業は進んでいくと考えられますが、競争力を保つためにより高度な仕事の仕組みを作り上げていったり、高度な商品の開発を行っていくと、仕事はどんどん深くなっていきますし、1人が面倒を見切れる範囲には限界があるので、その分対象は狭くなって専門化していきます。これは前回のエントリーで書いたことです。

ドメインエキスパートはどこにいる?

業務が分断されてしまったら、いざ業務改善を図ろうとした時に誰に聞きに行けばいいんでしょうか?XP本では当初、顧客は単数形(customer)だったのが、XPシリーズのあとに出た本で複数形(customers)に修正されたというのがXP祭りの木下さんの発表にありました。1人が顧客を代表するにしても、結局はその人が社内の多くの人にヒアリングして回る必要があるでしょう。このように、多くの人に分割された「業務形態」を見える化することに注力した方法の1つにマジカ!があります。

工程が前後に分割されただけであればそれでいいのですが、コンピュータで自動化してしまった複雑なロジックなんかは、現場の誰の手にもその情報がなく、そのソフトウェアを管理している人の中にしかない、ということもありえます。実際、これが岩切さんの発表の質疑で出てきた事例になります。また、システムが業務のワークフロー全体の効率化をしていたら、業務フローの全体そのものもコンピュータの中ということになりかねません。印鑑スタンプラリーを自動化したようなグループウェアはともかく、ロジスティックみたいな複雑なシステムの知識がオーパーツ化されてしまうと悲惨です。

業務の改善を行う時に、IT部門の人が現場よりもフローや細かいドメインを詳しく知っている・・・というのは僕も経験があります。実際にそのようになってきている会社も多くあると思います。IT投資が叫ばれて、第一世代のシステム、第二世代のシステム・・・と世代を重ねれば重ねるほど、現場から隠蔽されたブラックボックスが大きくなっていき、現場でノウハウとされるものはそのブラックボックスの使い方程度になっていくのは必然です。システムを作るためのドメインエキスパートは情報部門の中にしかおらず、ユーザ部門に聞いても役に立たなかったということも増えていくでしょう。

XPやドメイン駆動設計は、ユーザ=ドメインエキスパートが前提になっています。要求開発や、ユーザストーリーもそうでしょう。なので、ユーザがドメインを知らない、というのは、結構これらの議論の根幹を揺るがす事態じゃないか?と衝撃でした。ユビキタス言語がないと議論できないということはなく、システム部の人が過去の仕様書を取り出したり既存のコードを分析すれば済んでしまう、むしろそこ以外に情報がないという可能性もあります。もちろん、ユーザインタフェースの分かりにくい部分の改良とか、分かりにくい部分の改良みたいな表面的なところであればユーザの意見を聞くということはあるでしょうが、それは瑣末な部分です。

ユーザストーリーや要求開発は死ぬのか?

実践ドメイン駆動設計にしても何にしても、ドメインエキスパートがソフトウェアの専門家とは別にいて、ソフトウェア固有の用語(これも一種のドメインですが)をあまり理解しない、という前提の元に構築されています。もちろん、DDDはそれ以外にも役立つところも多いと思うので、ドメイン関連の章以外が無駄になることはないでしょう。

ドメインエキスパートがソフトウェアの専門家になったとしても、ユーザストーリーなどがムダになるかというとそんなことはないでしょう。企業の社内システムで、すでにあるシステムを改良していくというフェーズではいらないかもしれませんが、顧客が特定の契約企業ではないような、これから開拓していく完全新規のビジネスや、B2Cのビジネスなどであれば必要な技術だと思います。ただ、ドメイン駆動が当初ターゲットとしていた分野での重要度が相対的に下がっていくことは考えられます。

ドメインエキスパートとしてのIT専門家のキャリアの可能性

社内のシステム部門がソフトウェアの開発が行えるほどの規模を持っているというアメリカであれば問題はありませんが、日本の場合だとヘタすると外部の会社ということもあります。日本IBMなんかは、金融部門とかユーザ企業の業態によって組織がわかれているといいますし、ユーザ企業以上にドメインを知り尽くしているんじゃないかと思います。

ソフトウェアの世界でもそういうことは起きる可能性があって、IaaSの発達で、イーサケーブルのコネクタを付けたり物理的な配線をしたことがないインフラエンジニアというのが出てきてもおかしくありません。まぁ、IaaSはいろいろな選択肢があって競争があるし、引っ越そうと思えば不可能ではないのでまだマシだと思いますが、たまにニュースなど見かける「オープンソースで開発しました(ドヤァ」という事案で、AWSどっぷりみたいなのがあって「ああ、この人達の目には、AWSそのものがプロプライエタリサービスというのはすっかり見えてないのだなぁ」というのがありますよね。

もちろん、AWSで何かあったら、AWSのサポートに問い合わせることになります。一番上のプレミアムなサポートで24時間働いてくれて2200万円ほど($15000/月)。使用量が増えるとこれより増えてきますが、とりあえず最低料金で計算してみます。日本円で考えると高く見えるかもしれませんが、人を1人雇うと、経費、社会保険その他で給与の2倍ぐらいの負担になることを考慮に入れると、3交代で稼働日数が約240日だとすると、4.5人は必要なので、一人あたり換算で240万円以下で雇うのと同等になるので格安です。エキスパートを雇うとなると2-3倍以上かかりますよね?営業日の9:00-17:00だけのサポートでよければエキスパートを雇うのでもいいかもしれませんが。

このように明朗会計で手厚いサポートであれば問題になることはないかもしれませんが、社内のドメイン知識が集約されたシステムの専門家が外というのは問題があります。外のSIerにお願いするような大きな会社ほど、「発注時の不正防止のために相見積もりすべし!」みたいな体制になっていることもあって、いざ発注を受ける時に他社に負けちゃったりして、詳しい知識を持っている人に頼れないということもあります。それ以外にも、ドメインエキスパートがIT技術者だったことを見落とすと、さまざまなリスクにさらされることになります。

  • 社内情報部のドメイン知識を持っている人がより楽しい開発/高い給与を求めて転職してしまう
  • 競合関係にある会社の人が、外部のSIerのドメインエキスパートをヘッドハンティング
  • 外部SIerが潰れたり、買収されたり、または部署異動によってドメインエキスパートのが仕事を外れる

そのうち何度か「業務エキスパートがいなくなって、競争力の向上ができなくなって会社が死ぬ」みたいな事件が発生するようなことがニュース(経営層が好きそうな日経新聞とワールドビジネスサテライトだけでもいいので)を騒がせるようになれば、相対的にIT専門家の重要度が増して、銀行からの出向・転籍のように、SIerからドメインを知り尽くした業務改善の役員としてソフトウェアの専門家が会社に雇われていくというパスはありえるんじゃないかと思います。有名人をフェローとして雇ってアドバイザーとして入ってもらったり、福利厚生みたいなのは今でもみかけますが、現場のシステム部門でガッツリ業務ドメインを知り尽くして、CIOとしてではなく、COOとして会社の運営の中心に関わっていくと。もちろん、外注を使うだけではなく、ドメインのコアとなる部分だけでも自作できるようなしっかりとしたIT部門を社内で育ていくという方向もありそうです。

SIerの未来は明るい(という希望)

と、断言するにはまだまだエビデンスが足りない気もしますが、スタートアップでうぇーいという最近の流れ以外にも、SIerが外部脳として多くの企業の中枢に関わっていく可能性は信じたいと思います。コンピュータがさまざまな現場で活用されればされるほど、ソフトウェアが会社の仕組みの縮図、あるいはモデルとして重要度が増していきます。ソフトウェアに関わる人の地位が外向けにも高く見えるようになれば、もっと若い人も学生時代にもっと学ぼうと思うようになって業界全体の底上げになると思います。

もちろん、SIerの業務を見てみればソフトウェア開発そのものがコアドメインということになるので、コーディングを丸投げするのではなくて、デイヴに怒られないようにコードを書く人を同じように大事に抱えて安定した成果を出せるようになって欲しいですし、コード書く人が偉くなったらSEではなくて、コーディング、ドメインエキスパート、管理者と3つのキャリアパスを自由に選べるようにして、それぞれの道を極められるようになったらいいなと思います。

そういうことで、ドメインエキスパートが確保できなくて競争力が弱って経営にダメージというニュース(経営層が好きそうな日経新聞とワールドビジネスサテライトだけでもいいので)が流れるのを期待しています(大事なことなので2回)。まぁ、この手のダメージは地味に少しずつくるものなので、報道にはならないかもしれませんが・・・

posted by @shibukawa at 23:53 | TrackBack(0) | 日記 はてなブックマーク - SIerの未来は明るい?
この記事へのトラックバックURL
http://blog.sakura.ne.jp/tb/163682630
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2016年12月 >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ