ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。
－－だとすると、日本のSI業界というのは将来性があるのでしょうか？ わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。
「情報システムを開発・維持する仕事は、この国に経済がある限り、無くならないでしょう。しかし今のSIerのような業態が続くかといえば、疑問だと思いますよ。」一人が答え、他のメンバーも賛同する。「一括請負で、プロマネは受注側には居るが発注側にはおらず、人月を一山いくらで売るばかりのソフトウェア商売は、もうこの先、もたないんじゃないかな。」これを別の人が引き取って続ける。「アメリカではPMは発注側の組織にいて、バラバラなユーザ要求をまとめる責任もあるんです。そうやって、納期やコストとのバランスを調整する。日本のユーザ企業って、そういう旗振り役がいないんで、全部請負側にリスクが押しつけられるんですよ。」
アメリカの事情は別にいい。わたしも多少は知っているし、ユーザ側のPMもじつは有期契約の渡り鳥だったりする。だが、とりあえずわたしは日本企業に勤めており、日本の業界の実態を知りたい。すこし矛先をかえて別の質問を出してみた。－－ソフトウェア開発のプロジェクト・マネジメントで、一番苦心されるのは、どんな点ですか？
「それはね、人の確保ですよ。」右隣の人が答える。「それも、人数じゃない。出来る技術屋の確保。プロジェクトはこれに尽きます。ITエンジニアの生産性って、人によって30倍くらい違いますから。」すると向かいの人が突っ込む。「いやあ、人によっちゃあ、いつまで経っても出来あがらない奴がいるから、生産性の違いはもう無限大だな。」（笑）
あれ？ わたしが駆け出しだったころ、プログラマの生産性の違いは“倍・半分”といっていた。10年ほど前には、たしかどこかで、SEの能力差は“10倍くらい”ときいた覚えがある。そして今や、30倍だという。この指標では、インフレが進んでいるようだ。なぜだろうか。開発環境やライブラリが充実したせいか。それとも、職種自体が変化しているのか。わたしはそれもたずねてみた。－－その個人別の生産性の数字かグラフ、もしあったら見せてもらえますか？
「いや、そんなものはありませんよ」が、答えだった。
－－じゃあ、どうやって30倍だと分かるんですか？
「そりゃあ、プロが見ていれば分かります。感覚ですけどね。」
－－経年変化とかのグラフもない、と？
「佐藤さん。ITエンジニアの生産性って、具体的に測るのは難しいんですよ。」相手は諭すような口調でわたしに言った。
難しいくらいは、わたしにだって分かる。だから、どうやってそれをマネージしているのか興味を持ったのだ。何かをマネジメントしたかったら、まず、それを測って、数値化する。そして、標準値を設定する。その上で、実績が標準に足りない場合はその原因を調べて取り除き、さらに標準値自体を押し上げる改善の努力をする。これが、生産管理の世界での常識、いや、マネジメント全般に共通するやり方だ。
だから、IT分野のマネジメントで人の生産性が問題なら、それを測って数値化する試みから、着手されるはずである。そう、単純に考えたのだった。仕事の実績から、個人単位の生産性を割り出すのが難しいのなら、テスト問題を作ってみて、それで測る手もあるだろう。あるいは、もしプロが見て分かるのなら、５～６人の社内のベテランの目から評価させ、平均値をとる方法も考えられよう。だが、そうした発想は、ここでは通用しないらしい。
－－個人の生産性の違いを決める、決めてってのは何ですか？
「そりゃあ、センスですよ。もって生まれたセンス。」
－－てことは、生まれつき決まっていて、教育や研修では伸びないものだ、と。
「まあ多少、経験や、あと、誰について仕事を学んだかで、かわってきます。」
ーーふうむ。そうすると、IT開発マネジメントの最大の仕事というのは？
「だから、社内にいる限られた優秀なキーパーソンを、どうやって確保するかで勝負が決まるんです。」
この方は、社内の椅子取りゲームに勝つのがプロジェクト・マネジメントの要点であると信じているようだった。社内全体の椅子の数を増やして、全員が座れるようにするにはどうしたらいいか、は眼中にない様子だ。まあ、それを考えるのはPMOの仕事、ということなのかもしれない。
全体の話は次第に、ビッグデータの方に流れていった。ビッグデータという語の流行(?)とともに、『データ・サイエンティスト』という職種の概念が新たに登場し、急に脚光を浴びるようになってきた。多量のデータを見て、そこから“意味”や“仮説”を汲み出す力。まあ、たしかにエンジニアリングと言うよりもサイエンスに近い。技術は発明が主題だが、科学は発見が重要だからだ。では、そのデータ・サイエンティストはどのように育成するのか。大学はどこの専門を出た人間が適切なのか。いや、これはサイエンスと名付けているが、実際にはかなり「アート」に近い仕事なのではないか、云々。
だが、わたしは次第に話に興味を失っていった。とるべきデータなら、目の前に沢山ころがっているではないか。それは、自分たちIT分野の仕事の実績データである。生産性でもいい。生産性がもし難しいのなら、品質（つまり瑕疵）のデータでもいいし、あるいは受注確率のデータでもいい。自分達の仕事を向上させる手がかりは、データの中にしかないはずだ。なのに、なぜ商品RFIDの移動や、スマフォの緯度経度のデータばかりが重要だと考えるのか。データサイエンスから最も縁遠い業界の一つが、じつはIT業界ではないのか。そんな気がしてきたからだ。
国内外で仕事をしてきた経験から感じるのは、彼我の技術者のマネジメント観の違いである。いや、こういう言い方が大ざっぱすぎるなら、言い直そう。英米社会で教育を受けた技術者と、日本社会で主に教育を受けた技術者の違いはどこか。それは、マネジメントという仕事が独立した科学の対象でありうるかどうか、という意識の差である。
日本の技術者というのは、ほぼ例外なく真面目で、優秀だ。たとえば、最近読んだ調査によると、日本の大企業の基幹情報システムの障害による月間停止時間はわずか1.7時間なのに対し、北米では14.7時間だそうだ。まさに10倍近い信頼性の差である。また、ソフトウェアの不具合数（1年後に発見された1KLOCあたりの不具合数）は、
日本 0.020
アメリカ 0.400
インド 0.263
欧州他 0.225
平均 0.150
だということで、日本のIT技術は格段に信頼性が高い（JUAS＝日本情報システム・ユーザー協会「ユーザー企業ソフトウェアメトリクス調査2013」p.291 より引用）。
だが日本の技術者は、（IT分野に限らず機械だろうが建築だろうが）マネジメントは「文系の仕事」だと思っている人が少なくない。自分の仕事と認識している人でも、マネジメントとは“人間力の問題”だととらえることが多い。つまり、いかに出来の良い人をとってくるか、いかに人をモチベートしてやる気を出させるか、いかに明確なビジョンを示して皆を引っ張るか、いかにメンタルな面に気をつけてやるか、etc, etc… マネジメントとはヒューマン・ファクターの集合であり、個人が修行して悟るしかない。そして、それは自分の固有の技術領域とは無関係のものである、と。
IT業界人こそ、こうした「普通の日本人」の思考法の枠内から、自覚的に離れる努力をしていってほしいと、わたしは願う。もし生産性を測るのが難しいのだったら、そこをブレークスルーできた者は、大きな優位性を得られるはずである。なぜ、そうした方向を目指す企業が少ないのか。なぜ、一山いくらの値段勝負の泥沼から抜け出そうとしないのか。
IT業界には頭の良い人が多い。論理的に思考する能力を持たないと、仕事にならない。しかし、論理性だけでは、何かが足りないのだ。その何かは、「仕事に関するサイエンス」の中にしかないと思うのだが。
“ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係” に対して19件のコメントがあります。
コメントを残す
コメントを投稿するにはログインしてください。
無限大ってのは、正にそうですよね(笑)。
恐ろしく｢ソフトウェア｣を勘違いしている話ですね｡
プログラミングを工学で言うところの｢製造｣と勘違いしてマネジメントをしてしまう愚行については､10年以上前にC++ジャーナルの名論文が指摘しているのですがね｡
プログラミングは｢設計｣で､ソフトの｢製造｣は｢コンパイラー｣の仕事です｡
汗水垂らして､紙にCOBOL書いていた時代とは違うんですよ｡
>10年以上前にC++ジャーナルの名論文が指摘している
ふと気になったのは、それってオンラインで読めるのでしょうかね。
>>guest0
http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
どぞ
個人の生産性や品質、プロジェクト管理etcについては、30年ぐらい前から否定され続けてるネタですね。
工場での生産やプラントの構築等とは根本が異なるので、ソフトウェア界隈のプロジェクト管理に関する情報を集めたほうが良いかもしれません。
個人の生産性や品質、プロジェクト管理については、スポーツ業界が大いに参考になると思います。
野球選手や監督、コーチがどのように評価され、その評価の基準となっているものは何かということはほとんどが公開されています。
>10年以上前にC++ジャーナルの名論文が指摘している
こういう論文を盾にして、自ら新たなマネージメントの地平を開こうとしないのが問題。
VisualBasicのバッドノウハウを今になって語るようなものだよ。
この辺が参考になるかと思います
「人月の神話」
http://www.amazon.co.jp/dp/4864010056/
「ピープルウェア」
http://www.amazon.co.jp/dp/4822281108/
プログラミングは、東大や京大クラスの数学の受験問題かな?
数学はとける人には解けるけど、解けない人はいくら時間をかけても解けない。
後者の人たちは、仕事の場では仕方が無いから、総当たりで泥臭く全試行で解くかのごとき、ゴミを生み出す。
前者の人はスマートにエレガントに解けてしまう。
というわけで、ソフトウェアのマネジメントは「能力の足りない者」の排除が重要。どうやっても役に立たないのだもの。
さて、数学力の育成は、本人がひたすら悩み勉強し、人と対話する以外に無く、プログラミングも同様の勉強法に行き着くと蓋し思う。
この話は「貴方は明日、ゴッホになって誰も見たことのない名作を書きなさい」と言う課題にサイエンスで対応するか、アートで対応するかという話ではないでしょうかね。blog主さんはサイエンスだと言う持論のようですが、参加者多数はアートだと思っている。私もアートだと思いますけどね。あるいは個人のセンスであると言う意見に賛成だなぁ。マネジメントだけですむなら世の中こんなくずコードばかりでもないと思うけどな。
記事の意図する「マネジメントは科学である」という意見に賛成します。コメントはIT村は製造村とは違う、よそ者にはわからないと言いたげでうんざりしますが。
業種はずれますがIT業同様に個人の資質の差が顕著なコンサル業においても、BCGでは新人採用からプロジェクトの貢献、評価者の妥当性までデータを取得し、客観的なデータを基にマネジメントが行われているようです。
>コメントはIT村は製造村とは違う、よそ者にはわからないと言いたげでうんざりしますが。
違うよ。
「違うといいたげ」なんじゃなくて本当に「違う」んだよ。
素人には分からないかもしれないけどね、分からないなら勉強すればいいと思うよ。
>>読者A
う~ん｡ソフトウェアは工学における｢製造｣とは異なる｢設計｣工程だからねぇ｡
いやソフトウェアを｢製造｣にしか見えない時点で､日本のIT(笑)に毒されているか､あなたの頭が悪い･ソフトウェア向きではない･抽象思考が弱いんだよ｡
ソフトウェアにおけるマネジメントを｢科学｣とするには､現行の数学である圏論などの最新鋭の数学に踏み込むかのような抽象性や頭の良さが要るからね｡
いつも記事を楽しく読ませてもらってます。
今回の記事を読んでいて、前回の記事「レベルいくつの議論をしているの」を思い浮かべました。
なんとなくこの集まりの参加者で認識がかみ合ってないような…？ という感覚がまとわりつきます。
例えば「生産性」の定義。生産性や付加価値というと言葉は意外に人によって認識が異なる悩ましい言葉です。そもそもなんとなく使っている言葉で真剣に定義を考えたことが無い、なんてことも。
(労働に対する生産性といっても、生産量÷労働時間、生産額÷労働時間、付加価値÷労働時間といくつか考えられます)
もしこうであれば生産性の指標も決められません。
生産物について質の評価が難しいという面もありますが、何らかの方法で最終的には一定以上の質が確保されているはずなのですし。
・マネジメントによってSI業界の生産性が上がるか
大雑把に考えれば、生産効率の上げる余地はあると私は考えます。(程度はさておき)
理由の一つとして、どんなスケールでも比較優位は成り立つはずなので。
>「貴方は明日、ゴッホになって誰も見たことのない名作を書きなさい」と言う課題
CGツールに付いている「ゴッホ風フィルタ」で効果をつければ、どんな絵でも写真でもゴッホが描いたようになりますよ。
はじめまして。
計測方法を統一して実際に品質や生産性を測ってみたところ、見た目はバラバラですが、言語・目的（新規か更改か保守か）などにより分類すると、ある程度の傾向がわかります。影響の強そうな要因にフォーカスして開発プロセスを整備し定着させることにより、成熟度の異なる人材でも、バラツキを抑えて統計的にコントロールすることはできます。
確かに製造とIT開発は特性が異なりますが、ITでも科学的なマネジメントは可能で、それにより実際に成果を上げたことがあります。（URLをご参照ください。）
非常に残念なことに、このような考え方は日本ではあまり一般的ではないようで、この活動を指揮した自分は、現在失業中です。
おそらく日揮コーポレートITの佐藤さんだと思うのですが、間違っていたら申し訳ありません。となりのProject IT部の林幹高と申します。いつもブログ拝見させていただいています。
>土屋さん、
コメントありがとうございます。いろいろな意見があると思いますが、わたしは土屋さんのお考えに賛同します。たしかに障害も大きいと思いますが、次なるご健闘をお祈りしています。
＞林さん、
Blogをごらんいただき、ありがとうございます。楽しんで読んでいただければ、何よりです。なお、正確にはコーポ－レートITではなく、情報統括室です。
コメントに対するReplyをどうもありがとうございました。
自分は未だに失業中ですが、ご賛同いただき、お力をいただいた様な気がします。
別のBLOGに書かれていることも非常に興味深いので、学会などでお話を伺える機会があれば嬉しいです。
スキルセットが同じエンジニアで生産性が30倍違う事はまずないと思うんですよね。問題は、エンジニアの経験が全然ない状態で人柄重視で、とか言って採用した人間を使い続けるから物凄く環境に依存したスキルしかないエンジニアが出来上がる。そしてマネジメント側も案件の具体的な要求や使うべきソリューションがわかってないから「人」でしか案件とマネジメントを理解できていない。 使うべき技術をなんとなく知っている人がいても、上に話を通せないから採用されない。 魔データはないけど生産性に一番格差があるのは「環境」のような気がする。