「ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係」
http://brevis.exblog.jp/20765925/
http://blogos.com/article/65824/
全般的にスゲー糞つまらん．
10年以上前にも同じ論法で「ソフトウエアのマネジメントは遅れてる（キリッ）」とか言ってる人はいたけど，その手の輩が成功したという話は聞いたことがない．
あれ？ わたしが駆け出しだったころ、プログラマの生産性の違いは“倍・半分”といっていた。10年ほど前には、たしかどこかで、SEの能力差は“10倍くらい”ときいた覚えがある。そして今や、30倍だという。
なにを「1倍」の基準にするかで変わるけど，概ね30倍以上．
- 作者: ロバート・L・グラス,山浦恒央
- 出版社/メーカー: 日経BP出版センター
- 発売日: 2004/04/08
- メディア: 単行本
- 購入: 4人 クリック: 29回
- この商品を含むブログ (78件) を見る
「倍半分」はSIerの内部限定オレオレルールでしょ．もう随分前から30倍以上というのが定説だし，実際に下の方は０やマイナスもあるので，数値化することに意味はない．差が何倍あるかは下側の人間が「どれだけ生産性が低いか」で決まるけど，欲しいのは「生産性の高い人間を獲得する方法」だ．*1
追記
一環として，経験を積んだプログラマグループの実績を測定した．そのグループの中だけでも，最高と最低の実績比率は生産性にして十対一，プログラム開発のスピードと量ではなんと五対一だった．ようするに，年間二万ドルのプログラマが年間一万ドルのプログラマの十倍も生産性が高いと言うことである．その逆もまた真だろう．しかし，このデータからは，経験と実績との間に何の相関も見られなかった（コレが常にそうだとは言えないと思う．）
（人月の神話 第三章 外科手術チームより）
「人月の神話」は古典中の古典で，初版は1975年．
The Mythical Man-Month: Essays on Software Engineering
- 作者: Frederick Phillips Brooks
- 出版社/メーカー: Addison-Wesley
- 発売日: 1975/01
- メディア: ペーパーバック
- この商品を含むブログ (7件) を見る
その頃には「熟練プログラマの中でさえ生産性に十倍の差がある」ということは既に知られていた．未熟な低レベルプログラマまで含めれば，その差は30倍を優に超えるだろう．
さらにこの章の後では，
結論は単純だ．つまり，二百人体制のプロジェクトに，極めて優秀で経験豊富なプログラマでもあるマネージャーが二十五人いたら，残りの集団百七十五人は首にしてしまい，マネージャーをプログラミング作業に戻せば良いのだ．
という文章もある．日本のように「プログラミングなんて誰でも出来るが，マネジメントはそうじゃない．だからマネージャーが偉くてプログラマは底辺．」というSIer的価値観は，この当時から既に否定されていたのである．
日本でそれができないのは人月単価の存在と，マネージャーが底辺プログラマ以下の技術スキルしか有していないからに他ならない．
難しいくらいは、わたしにだって分かる。だから、どうやってそれをマネージしているのか興味を持ったのだ。何かをマネジメントしたかったら、まず、それを測って、数値化する。そして、標準値を設定する。その上で、実績が標準に足りない場合はその原因を調べて取り除き、さらに標準値自体を押し上げる改善の努力をする。これが、生産管理の世界での常識、いや、マネジメント全般に共通するやり方だ。
うん，バカだ．スゲーバカだ．
その考えは「生産管理」の世界では常識でも，ソフトウエアのマネジメントには使えない．*2
とりあえずプログラミングを勉強し直せ．話はそれからだ．
だから、IT分野のマネジメントで人の生産性が問題なら、それを測って数値化する試みから、着手されるはずである。そう、単純に考えたのだった。仕事の実績から、個人単位の生産性を割り出すのが難しいのなら、テスト問題を作ってみて、それで測る手もあるだろう。あるいは、もしプロが見て分かるのなら、５〜６人の社内のベテランの目から評価させ、平均値をとる方法も考えられよう。だが、そうした発想は、ここでは通用しないらしい。
うん，それ全部通用しません．いずれも典型的な失敗パターンということで．*3 *4
日本の技術者というのは、ほぼ例外なく真面目で、優秀だ。たとえば、最近読んだ調査によると、日本の大企業の基幹情報システムの障害による月間停止時間はわずか1.7時間なのに対し、北米では14.7時間だそうだ。まさに10倍近い信頼性の差である。
ダウンタイムは要求仕様によるしなあ．*5
コストをかければいくらでも下げれるけど，それを顧客が要求しているのか否か．むしろ日本企業が過剰品質による高コスト体質というだけじゃないの？
また、ソフトウェアの不具合数（1年後に発見された1KLOCあたりの不具合数）は、
これ，本気で言ってるんだろうか．．．．
そういうのは計れるが，それで「ソフトウエアの品質」は計れない．
タイム・マネジメントとSCM専門家のエッセー・批評・考察集 by Tomoichi_Sato
なるほど．
ITとかプログラミングについては何も知らん素人なわけだ．
だが、わたしは次第に話に興味を失っていった。とるべきデータなら、目の前に沢山ころがっているではないか。それは、自分たちIT分野の仕事の実績データである。生産性でもいい。生産性がもし難しいのなら、品質（つまり瑕疵）のデータでもいいし、あるいは受注確率のデータでもいい。
たとえばソフトウエアの品質について，必要な元データを取るだけなら簡単．通常は既にバージョン管理システムのレポジトリに，全ソース／全成果物が入っている．チェックアウトとコミット時間で差分を取れば変更にかかった時間の目安にもなろう．
問題なのは，そこから評価すること．あまりに複雑すぎて事実上不可能と言って良い．各種のソフトウエアメトリクスも，大雑把な目安くらいにしか使えない．
もしあなたが囲碁や将棋プログラムの作り方を少しでも囓ったことがあれば，これらのゲームにおける評価関数*6 *7を作るのがどれほど難しいか分かるだろう．もっと簡単なチェスやオセロでさえも，初心者にはお手上げだ．
- 作者: 松原仁
- 出版社/メーカー: 共立出版
- 発売日: 2012/05/09
- メディア: 単行本
- 購入: 1人 クリック: 10回
- この商品を含むブログ (12件) を見る
測定すべき内容は駒や碁石の配置だけで，それは見れば分かるほどに記録は単純だが，その状況を判定するのは誰にでもできるものではない．囲碁や将棋の名人がそれをどうやって判定しているかと問われれば，きっと「経験」や「直感」，「センス」などと答えるだろう．*8 *9
プログラムにおいて，たとえばその品質のために測定すべき要素は，（おそらくは囲碁や将棋と比べても）複雑で量が多い．しかも「（中盤における）敵の駒を奪う」や「勝敗」のような単純な目的が存在しない．可読性，拡張性，バグの個数，深刻なバグの占める比率*10，等々．その評価関数を作ることは，囲碁と比べても遙かに難しかったとしても驚きはしないだろう．
http://b.hatena.ne.jp/entry/brevis.exblog.jp/20765925/
- id:netcraft 「日本の技術者はマネジメントは文系の仕事だと思っている人が少なくない」って本当にそうかな？私の出会ったWEB系エンジニアでそんな風に考えている人は少なかったな。そもそも、ここでいうサイエンスの定義って何？
激しく同意．
技術系のマネジメントは技術者の素養のない人間には無理．「マネジメントは技術力がなくてもできる」というのは文系マネージャーが信じたいと思ってる都市伝説に過ぎない．
- id:isseium テイラーさんの管理手法が当たり前過ぎるくらいに浸透してるからこうなるって誰かがいってた。ルーチンワークにはテイラーさんの管理手法がいいけど、非ルーチンワークに適した手法をまだ人類は発見してないって
- id:kamei_rio 同一報酬に合理的な説明が付かないから、生産性を真面目に議論する気なんてないよ
これも激しく同意．．．orz
- id:atsushifx 「ピープルウェア｣「ゆとりの法則｣を読んでからだな。それにアイデアや企画のような知的生産の生産性をどうやって計るつもりなのか。アイデアは数じゃないようにプログラミングも行数じゃない
- 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 26人 クリック: 339回
- この商品を含むブログ (189件) を見る
- 作者: トム・デマルコ,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2001/11/26
- メディア: 単行本
- 購入: 14人 クリック: 119回
- この商品を含むブログ (111件) を見る
本当に気がするだけ．
上流工程の失敗や，上流工程と下流工程に切り離すことによる生産性低下・品質低下も満足に計れてない．
- 「ソフトウェア設計とは何か？」 http://web.archive.org/web/20080803072849/www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
- id:y-kawaz 何か文句ばっか言ってるけど今そういうのをマネージメントする仕事についたわけだから5年10年後にあなたの成功例を聞かせて欲しい。
文句を言ってるだけで自分では何もしないか，さもなくば自分でやって過去と同じ失敗例がまた一つ繰り返されるのどちらか．
- id:airj12 製造業では"設計"の生産性が測れてるのかな / ITでは設計と製作の境目がほぼ無い事が生産性を測れない要因の一つな気がしてるので
- id:dadapon 紺屋の白袴、灯台下暗し的な話。
むしろ「生兵法は大怪我の元」だと思う．
半端な知識で専門外に口出ししたので大失敗している．
- id:cad-san コードの品質はサイクロマチック数等の定量化手法はあるけど、生産性はしらないなぁ。同一の機能作るわけでもないし、見積りに対する実際の作業時間としても見積もりが必ずしも正しいわけではないし。難しそう。
同意．
サイクロマチック複雑度他のメトリクスを駆使しても，コードの品質の指標程度にしかならない．
人間の体において，もし「健康度」というものが計れたとしても，メトリクスは血圧計くらいの意味しかない．血圧が異常値を示していれば，おそらく不健康だ．しかし血圧が正常だからと言って，その人が健康だとは言えない．
- id:andalusia 「なぜ、そうした方向を目指す企業が少ないのか。」→ 無理だからでしょうね。竹槍でB29を落とすようなもの。だから Google も Facebook もそんな方向は目指していない。20%ルールはマネジメントの放棄ではない。
- id:korin 無理に数値化して死屍累々だった過去のことを誰も説明してくれなかったのかな。事前の見積もりと結果の関連性は数値化できそうだけれど。。データからパターンを見出すのがアートというのは同意。だから面白いと思う
- id:surunpashi 測れるなら測るだろうけど、生産性が人によって全く違うのにその標準を作っても、バラツキが大き過ぎて意味がない気がする。だからセンスのあるエンジニアを確保する方が現場では優先されるんじゃなかろうか。
- id:teruyastar 実装が早いのは測れるけど、同時に保守性、仕様変更、バグも見ないとわからない。関わった人数分のプログラマやSIerとのやりとりから、それぞれの立場で自分の責任ではないと言い出せば測るのは無理かな
- id:Koozz 技術において生産性は本当に人それぞれだからな?測ったところでって感じがする。
- id:T-norf 長い工数で見積もってそれなりに仕上げる人と、短い工数で見積もってドタバタしながら驚異的なスピードで仕上げる人を、３６０度評価とかすればいいんだろうけど、得意分野もバラバラで..
- id:moons なんかこの人の方が「ステップ数」の話をしてる気がする。相手方の日本の管理者のいう事の方が道理だと思う。プログラムはチーズバーガーを作るのとは違う。十人バイト雇うより一人の料理人が必要。毒されてる？
- id:yokochie 本筋と関係ないけど、生産性を測らないのに30倍違うという具体的な数字はどこから出してくるんでしょうね？
- id:Rinta 確かに３０倍とか、何を基準にした数字なのかわからんよね。そこらへんきちんとしないとダメだと思う。
たとえば，「ＡさんとＢさんとＣさんが3人がかりで２ヶ月以上かけてできなくて失踪したものを，ベテランのＤさんが引き継いだら２週間で出来た．しかもＡさんたちが書きかけのコードより，遙かに洗練されていて保守性も性能も高かった．」みたいなことがあれば，「10倍以上」ということは言える．そしてそういうことはそんなに珍しい話ではない．
Fizz-Buzz問題のような単純な問題でさえも10倍以上の差が出るのは普通のようだ．そして，本当にできない人は1時間かけてもできないとか．そういう「出来ない人」に本当に3時間でも30時間でもやってもらえば，簡単に30倍以上という数値は得られる．しかも難しい問題では，この差はもっと開く．その差が正確には300倍であろうと3万倍であろうとそんな下手くそにできる仕事はないので，正確な数値を測ることにビジネス的実用的な意味はない．*11
このようにして「出来る人と出来ない人の差」であれば簡単に測ることが出来る．
しかし現実には，個々の開発において，個人個人の能力や成果を測るのが難しくする要因がある．*12
- チームで動く．個々人の仕事と成果は独立していない．
- それぞれのチームが同じ問題を解くわけではない．
- 同じ期間，同じ人数，同じ仕様書で作るわけではない．
- 使用言語，フレームワーク，既存コードの有無，参加する人数等々の条件が千差万別．
- 既存コードの完成度が高い場合もあれば，糞コードのこともある．
- 開発者個人にも，それぞれ得手不得手がある．
そのため，任意の二人を連れてきて，「その二人の生産性の差が２．３８倍違う」のような形で計測することはできない．*13 *14
- id:YaSuYuKi 生産性の計測が困難であることを、論理的に説明できる人は、確かにあまり見かけない
いや説明されてるよ？
むしろ常識すぎるので，わざわざ説明する必要がないだけ．
コードの品質の評価がいかに難しいかとか，もはや常識．ソフトウエアの生産性／品質の指標としての，単位時間当たりに書いた行数，ファンクションポイント法，出たバグの数，一メソッドあたりの行数などなど．全てが物笑いの種にしかならない．*15 *16
他にUIの品質も測るのが難しいものの一つだ．
iPhoneが登場した時，そのUIが画期的だと評価した人は多かった．じゃあ一台のiPhoneのUIの価値は，ガラケー何台分だろう？「1台のiPhoneのUIは，7.23ガラケーに相当する」みたいな測定値は存在しないのだ．
*1:しかもアルバイトなみに安く，劣悪な労働環境で．
*2:製造業の例えはソフトウエア開発には通用しないということ．
*3:「着手されるはず」って，その時点で怪しいなあ．「誰がそう決めたの？」という疑問は常に念頭に置くべき．
「着手されるはず」で，その手法に疑問を持たないのは，コンサルタントにあるまじき思考停止じゃないの？
*4:なんだか10周くらい周回遅れで，２０〜３０年くらい昔の議論を読まされている気分だ．
*5:たとえばGoogleが1時間ダウンしたら世界中でニュースになるが，NTTデータのDoblogが一週間ダウンしても話題にもならない．
*6:「現在の盤面の善し悪しを判定し数値化する関数」と思ってもらえば良いと思う．
*7:ある意味で，そういう複雑な局面を評価して数値化することに関しては，その手のプログラマーこそが本職だ．そこらのコン猿ごときの出る幕じゃないよ．
*8:もちろんその直感やセンスは学習／訓練して磨くものなのである．
*9:ホームズ流の「直感」もこういう解釈じゃなかったっけ．彼の頭の中では複雑な論理的思考が展開されているのだけれど，その外部から見ることの出来ない凡人には想像も付かない思考を「直感」と呼んでいるだけ．決して非科学的オカルト的な未来予知のようなものではない．
*10:これを決めるためには，その前に「バグの深刻度」を測る必要があるのだ．
*11:「少なく見積もっても30倍以上」であって，キッチリ30倍と言ってるわけではない．
*12:野球でもサッカーでもいいけど，そのチームの勝利の原動力になった選手が誰で，その全体に占める貢献度が何％ずつなのか，常に測ることができるだろうか？足の速さとか投げたボールの速度とかは客観的に数値化出来る．でも個々人の能力を数値化するのは簡単じゃないよ．
*13:そもそもソフトウエアにおける「生産性」の定義自体が曖昧だし，品質に関しても多義的だ．
*14:「人間が走る速さ」でも普通は同じ条件で比較する．異なる条件で比較した場合に速度差が何倍になるかを判定するのは難しい．
たとえば同じ100m走で比較して，Aさんが100m10秒でBさんが15秒なら1.5倍と言える．これがたとえばAさんが100m10秒，Bさんが42.195kmを2時間，自衛隊のCさんが80kgの荷物を背負って，雷雨の中，富士山頂まで12時間で登頂した場合，その速度の単純比較にどれほどの意味があるだろうか．
*15:たとえばコード品質において可読性は数ある指標の中でも重要なものの一つだけど，可読性の善し悪しについてさえ軽く本一冊が書けるレベル．可読性そのものについてさえ議論が分かれるというのに，それら指標全てを統合して数値化？そら無理でしょ． リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) CODE COMPLETE 第2版 上 完全なプログラミングを目指して
*16:生産性がそんな簡単に計れるなら，技術的負債なんて最初から生まれないって．
