【第177回】How to 事故のない会社

本コラム【第170回 理想の会社】で「どうやって事故のない会社を作るか」ということについて書いた。
“事故”とは、いわゆる納期遅延や予算オーバー、客先からのクレームの総称である。当時は無事故記録が約2年間更新中で「3年以上無事故であれば筆者の理論が一応正しいかもしれないと証明されるので、その施策を解説する」と言及していた。
今この時点(2015年8月)で一応3年半位、無事故記録が続いており、筆者の理論が正しそうな気がしてきたので、一応その方法を開示してみたい。ポイントは4つである。
ちなみに、文中のエピソードはすべて実話に基づいている。事件は常に現場で起こっているのである。

1. 上から順に仕事の出来る組織を作る
これを実行するために筆者は7年位かかった。その背景を説明してみよう。
大手のSIerに入社すると、3年位はプログラムを組んで、早い人で20代、遅い人でも30代でまったくプログラムを組まなくなる。プログラミングは単価の安い外注の仕事で、胴元のSIer(要するにソフトウェアのゼネコンです)は、もっと付加価値の高い仕事をせよと上から言われるので、若いうちからプロジェクトマネジメント(外注手配、客先交渉、コスト管理、たまに部下の育成、設計業務)を任される。要するに、若いうちから実務から遠ざかるキャリアパスを経る人が多い(むしろ殆ど大部分ですが)。
30代でプログラムを組んでいると周囲からは“仕事の出来ないやつ”と見なされることもしばしばである。そのうち、主任・課長・部長と役職が上がるに従ってプログラムはおろか設計業務さえほとんどやらなくなるのである。そうやってコンピュータから遠ざかって十数年を経て“立派”な管理職(この業界では“手配師”という敬称で呼ばれるようです)になってしまうのである。
これだけ実務から遠ざかると、まずコンピュータの最新技術が分からなくなる。大型汎用機の時代ならば技術の進歩がハードウェアのサイクルの5年単位だったので、気の利いた部下にレポートを作らせて読めば最新技術をお客さんに代弁できたのだが、今の技術のサイクルは早すぎて部下のレポートでは間に合わないのである。
例えば、AmazonのクラウドAWSのサービスにしても、NTTコミュニケーションズのCloudnのサービスにしても、3ヶ月でマニュアルを作成した途端に新バージョンがリリースされるため、プリントアウトするドキュメントを追いかけるだけでは最新技術をキャッチアップできないのである。最近の技術進歩はそれほど速い。
また、最新技術のレポートも辞書のような厚い解説書を書かないと文字には出来ない。例えば、EclipseとNetBeansの違いをレポートせよ、と言われてもどの位の量のドキュメントになるか分からない。部下のレポートを二、三枚見て理解できるような世界ではないのである。アンドロイドOSではないが、自分で使ってみないと判断できないのである。コンピュータから10数年遠ざかるということは、“ほぼ素人”であるということである。素人に正確な最新技術を文章で(会社の報告書で)伝えることは極めて難しい。また、これだけ技術から遠ざかっていると見積りの妥当性が分からない。なぜかと言えば、システム開発のコストはプログラミングコストのシグマであるから、プログラミングをそもそもまったくやらない、まったくやれない人に積算の妥当性を判断することは出来ない。“出来ない”にもかかわらず見積りの妥当性やリスク管理はその“コンピュータを知らない”部長がやるのである。
また、“設計が出来ない”ということは、設計者の腕が分からないということである。弊社でも実際に起きた事件であるが、設計の出来ないSEは時々とんでもないミス人事をするのである。ある案件でA君とB君がいたとする。A君はその案件の設計スキルを十分に持っており実装力もあった。B君はプログラミング能力がまったくなく設計もいまいちである。ところがそのプロジェクトのマネージャはB君を主任設計者に指名したのである。その結果、設計をやり直す大事故となってしまった。
なぜそのような間違った人事が起きたのか?筆者はそのマネージャに「なぜB君をアサインしたのか」と聞いた。マネージャ曰く、「B君の方がベテランだから」。
実はそのマネージャはファイル設計、DB設計も出来なければ画面設計も出来ない。ついでに言うとプログラムも組めない。要するに技術者の技術を判定するスキルをまったく持っていなかったのだ。マネージャにスキルがないということは人事も出来ないということを意味する。もちろん部下を育てることも出来ない。なぜならば教えるもの(スキル)を何も持っていないからである。
また、弊社はパッケージベンダーであるから、お客様にパッケージに関することを聞かれたら何でも答えて即座に対応しなくてはならない。それがベンダーの技術者である。それを「いや、私はSEなのでプログラムのことはよく分かりません」などと言ったらお客様からは役に立たないから帰れと言われるだけである。
筆者の第一の改革ポイントは、“下から上に行くに従ってスキルが高くなる組織を作る”別の表現をすると、“上から順番に仕事が出来る組織を作る”ということであった。これには数年を要した。ヒラより主任、主任より課長、課長より部長、部長より社長が技術力を持つ組織を作るということである。従って弊社では部長でもプログラミングが現役で出来るようになっているし、同時に設計も要件定義も提案もこなすということをやっている。決して、組む人、設計する人、プレゼンする人、などというような別々の役割分担はない。ゆえに人材を育てるのに10年以上かかるのである。

2. オフショアを使わない
ソフトウェアゼネコンにしてみればコストの大部分は人件費であるから、その人件費が安いということは利益に直接結びつくことになるので、80万円の日本のSEを使うより20万円の某国のSEを使った方がコストダウン出来てよいということに(世の中では)なっているらしい。
昔こういうおとぎ話があった。


昔々、ある船主が某国の山の民に船を発注しましたとさ。山の民は予定通り船を作りましたとさ。ところが、スクリューが甲板についていましたとさ。船主は怒って「何でスクリューが甲板についているんだ、船が走らないじゃないか」と怒ったとさ。そうしたら山の民は平気で言ったとさ「だって、SPEC(仕様書)に書いてなかったですよ。」船主は常識も含めて技術なんだということを悟ったとさ。めでたし、めでたし。


先日、某大手SIerのSEがこうこぼしていた。「この間のプロジェクトではひどい目にあいました。開発が遅れているのにオフショアのSEが毎日定時に帰るんです。残業をお願いしても、残業はしないポリシーだと言って帰ってしまうんです。」そのオフショアのSEは夜の6時から別の仕事(アルバイト)をしていて、そのために残業が出来なかったのである。
1994年に筆者がSIerにいた頃、某国から3人の留学生を研修で2年間預かったことがある。そのうちの1人がある時難聴になってしまった。後々判明したのだが、その人はパチンコ屋で夜アルバイトをしていて難聴になったのだった。当時某国の1ヶ月の給与は日本円で5千円位、日本の給与が35万円位だった。実に70倍の給与を支払っていたのである。南北差を利用するとはこういうことである。別のアルバイトをして15万円位稼げば月収50万円、実に100倍の収入になるのである。仮に滞在出来る期間が2年だとすれば一生懸命アルバイトする気持ちも分からなくはない。家に仕送りも出来るであろう。
会社だけではない諸事情のせいでスクリューが船の甲板に乗ることがオフショアの仕事ではよくあることである。これが100回に1回、1,000本に1本だとしてもその被害は甚大である。実はソフトウェア開発はプログラム工程だけを切り出して外注しても大したコストダウンにはならない。その中に著しく低品質なものがあったときのリカバリーの工数を考えると、安かろう悪かろうが結局一番高くつくのである。
“安物買いの銭失い”とは昔の日本人の知恵である。我々は少し反省する余地があるかもしれないのである。

3. 品質を守るためには品質を守れる人に仕事を任す
“品質”は実は極めて属人的価値である。それゆえ半分は人格の問題と捉えてもよいかもしれない。そうなると“品質を守る”ために社内レビューをしたり、テスト仕様書を作ったり、標準化したり、システム監査を実行してもあまり効果はない(役に立たないとは言いませんが)。その品質を守る仕組みを実行運用するSEによって結果が異なるからである。どちらかと言えばズボラでいい加減なラテン気質のSEにルール遵守だけで品質を向上させるのは不可能に近いと筆者は考えている。品質を本当に守りたかったら品質を守れるSEに仕事を任せるのがいちばん効率がよく効果が出ると筆者は考えている。要するに品質は人格なのである。
プロジェクトとしてきっちり落とし込まなければならない案件では必ずチームの中に品質を守れるSEを配置しなければならない。いろいろなルールを作ったり、システム監査を何回も繰り返したり、標準化ルールを厳しくしてもあまり効果は期待できないと筆者は考えている。

4. 技術の分からない人には人事権を持たせない
みなさんは“技術屋は技術屋の下でしか働けない”という言葉をご存じだろうか?たとえば、天才プログラマのA君が、プログラムをまったく知らないB部長に「君のプログラムは素晴らしい、天才的だ」とほめられてもまったく嬉しくないということである。部長は技術なんか何にもわかってないくせに、と心の中では思われているだけである。
ゆえに技術を分かってない上司の下に優秀な技術者をつけてもモチベーションは上がらない。これが人事となると技術の分からないB部長は適材適所の人事がまったく出来ない。スキルがないのでどの部下がどういうスキルレベルにあるか判定できないのだ。
部下を伸ばそうと思ったら、100の力を持つ人に90の仕事を与えてはダメで(スキルが下がるか会社を辞めます)、120や130の仕事を与えてもダメで(過労で悲観して会社を辞めます)、少し負荷のかかった状態の110位の仕事を与え続けることが重要である。ある技術者にとって仕事の負荷が90か100か130かということを判定するためには上司に技術力がなくてはならないのである。ゆえに弊社では手配師に人事権を付与しない。技術者の健全な育成のためにもその上司管理者の技術スキルはとても重要な要素なのである。
SEはサラリーマン社会であるが、その中にも疑似的な徒弟制度(ギルド制度)が存在するのである。それゆえ技術の分からない上司がSE集団の上に君臨してはならないのである。

総論
以上のような施策を十分に打っても営業が不当な安値で仕事を取ってきたり、お客が最初と想定外の要求をしてきたり、赤字や工数オーバーの原因となる要素が外部環境に存在する。弊社では要件定義や上流工程の設計で予算に落とし込むということをSEに課している。システム開発はただ来た要求を単純に積み上げただけならば必ず予算オーバーとなってしまうのである。新国立競技場を見積もったゼネコンのようなものである。同じ設計が倍や3倍の価格になったりするのである。それを予算に落とし込む力が“設計力”なのである。予算に落とし込めないほど要求が費用と乖離しているケースは残念ながら受注を辞退するしかない(弊社ではあまりありませんが)。