IT業界のシュールな現実（3）

キャリア | スキル | 業界動向

» 2008/09/29

　数年前（もうかなり古いことなので恐縮ですが）、ある大手SIerでのことです。

●ありがたいお話

　突然Webアプリケーション事業部長が話をするから、下請けを含めた開発者全員、会社の大会議室に集まるようにと言い渡されました。大学の大教室のような広い会議室で待っていると、年のころは60歳近く、小柄でやせていましたが重役クラスと思しき事業部長が1人出てきて、講壇に上がり、話し始めました。

　話の内容はこうです。わがWebアプリケーション事業部は発足以来、時代の波に乗って高収益を上げてきた。しかしこの数カ月その勢いがなくなっている。個々人の仕事ぶりも沈滞しているではないか。これはいったいどうしたことだ。

　わたしもその職場では組織上の問題があると思っていたところでした。さすが大企業、問題をいち早く認識している、と感心したのはそこまで。あとがいけない。その事業部長の見解は、要するにわたしたち開発者の自覚が足りないということでしかありませんでした。それで終わるならまだよかったのですが、その事業部長、司馬遼太郎を引き合いに出し、東西の文明論にまで発展した話を、延々2時間しゃべり続けました。わたしたちはスケジュールの遅れにやきもきしながら、その事業部長の教養あふれる話をありがたく拝聴させられたのです。

　課長の月曜朝礼ではありません。歴史小説をネタにした素人文明論など、いやしくも200人にもなる事業部のトップが話すことではないでしょう。この長ったらしい訓話の目的が何だったのかはっきりわかりません。もし事業部の収益が低下気味だというのなら、それは事業部長がハッパをかけるようなことで解決できるような話ではありません。きちんと原因を究明すべく人を使って調べさせ、分析結果を元に組織変更なり作業手順変更なりの対策を検討した上で周知実行する、というような話です。事業部長がこれでは会社の品格が疑われるでしょう。

●これで本当に「大手」？

　わたしにはこの大手SIerの事業部が、規模ばかり大きくとも、実質的な管理能力は大変貧弱で、中小SIerと同じレベルだったように思われます。おそらくこの教養のある事業部長さんの実質的な手足になるスタッフはごくわずかだったのでしょう。実際のプロジェクト管理は下請けから派遣されたPM任せにしていました。事実上プロジェクトを「丸投げ」していたのです。いくら人数規模が大きくても組織としてきちんと管理されていなければ、それは単なる群集に過ぎません。

　そもそも「大手」というのは一体何なのでしょう。ユーザーはどうしてアプリケーション開発を「大手」に発注するのでしょうか。技術力に対する漠然とした期待があるから？ それもあるでしょう。しかしそれよりも何よりも大手には資金力があります。システムを開発するために集めた技術者にはまず給与を支払わなければなりません。そのためにSIerは銀行からお金を借りるのですが、当然大規模な開発には多額の資金が必要となります。そのような多額の資金を借りる信用力は中小SIerにはなく、結局規模の大きい開発案件は大手が受注することになります。このとき大手元請に期待されているのは開発のリスクを負担すること。例えば、開発費が予定をオーバーしても、それをユーザーにも下請けにも及ぼさないことです。ある開発で生じた損失は別の開発の収益で補えばよい。数ある受注案件を総合してプラスになれば、個々の案件のリスクは解消できる。それでこそ、ユーザーには安定してアプリケーションを供給することができ、開発者は安心して仕事ができるのです。大手SIerの存在意義は根本的にここにあります。

　この仕組みは一見うまくいっているように見えます。ITという新しい事業にベンチャー企業も意欲的に投資してくれるでしょうが、やはり安定的に設備投資するのは大手企業です。大手はやはり大手に仕事を依頼する。中小SIerはそこから仕事を請けた方が、自社で直接受注するより営業経費もかからないでしょうし、開発費用の超過も負担してもらえるでしょう。Webアプリの開発はまだ開発ノウハウの少ない分野ですから、何が起こるかわからない。「よらば大樹の陰」というわけです。大手SIerがプロジェクトを「丸投げ」しても、開発リスクを負担するなら少しも不当なことではないし、利ざやを取る権利は十分にあります。

　しかし実際にはこのビジネスモデルは正常に機能していません。というのもソフトウェアの開発では製品品質を評価することが困難だからです。

●ソフトウェアには形がない

　これが建物とか機械のように形があるものならば、製品評価はそれほど難しいことはありません。注文住宅がイメージどおりにできていれば、注文主は満足するでしょう。自動車は人を乗せて走ることができれば、完成品であることがわかります。しかしソフトウェアは形がありません。そのよしあしは使ってみないとわからない。そのうえアプリケーションはつねに特注品（パッケージで売られているソフトはわたしたちが作っているのではありません。あれはCDやDVDの生産ラインが作っているのです／注1）。要件定義の行き違いから、思わぬところで作り直しを要求されるかもしれません。だからPMは設計作業に時間をかけます。Webアプリの場合、設計書は事実上この注文者との間に交わす製品評価の約束書きのようなものです。それでもPMが最終的にでき上がるソースコードを想定し、それにかかる作業を見積もることができるなら、さして支障はないのですが、不幸なことにPMがJava（あるいはPerl、PHP、.NET）の実装を知らない場合（WebアプリのPMはCOBOL開発のPMが横滑りしてくることが大半でした）、設計作業は必要以上に膨れ上がってしまうことになります。PMにも製品が「見えない」わけですから、「見える」ようにするために設計工程にお金と時間を費やす。注文する方もその方が安心できる。だから設計工程はなかなか終了しません。その結果設計工程が必要以上に膨らんでしまうのです。

●どうしてそんなに長々と設計を？

　この大手SIerで起こっていた問題は、まさしくそれだったと思います。わたしが参加したのはそこが抱えていた案件の1つ、某新聞社の読者サービスサイトの開発でした。すでに実装作業を目前にしていて、そのマネジメントをしてくれというのです。実装はそれまで設計してきたSEが引き続き行うことになっています。そういうことならそれまでそのチームを率いてきたPMがメンバーの力量を知っているわけですから、自分で直接管理するのがベストですが、なにか別の仕事があるのでしょう、作業工程の管理ならわたしにも多少心得がありましたのでお引き受けしました。

　ところがスケジュールを見て驚きました。それまで設計に半年かかってきた来たものを2週間で作れというのです。わたしの経験に照らしてみると、2週間で実装できるものに半年も時間をかけるのはナンセンスです。設計に半年かかったシステムは、実装にも半年以上かかります。ところが話を聞いてみると、重要なのはサイトの記事を管理する機能で、この部分にはパッケージのフレームワークがあるから大丈夫だというのです。半信半疑で資料を調べてみると、たしかにそういう機能は用意されています。パッケージの設計思想が古く、MVCパターンを想定していないのが不満ですが、たしかにこれなら2週間で（実際には3週間かかりましたが）できそうです。しかしそれならなぜ半年も設計期間が必要だったのでしょうか。

　わたしがPMなら、最初に一部分を手分けして実装してしまいます。そうすれば技術者は製品のパターンを理解しますから、ほかの部分の設計に時間がかかるようなことはありません。実装に1週間（5日間）かかる機能は3日以内で設計できるでしょう。このPMはそれをしませんでした。自分がわからないことを部下にさせるのは（たとえ部下がそれに習熟していても）不安なことです。それゆえ部下の作業をコントロールするために、またあとで元請から責任を問われないために、必要以上に設計工程に時間をかけてしまったのでしょう。いずれにしても彼は設計工程に無用の人的資源を費やしたことになります。

　この傾向はこの会社の他のプロジェクトでも起こっていたと思われます。それは製造費用の上昇となって事業部の利益を圧迫したでしょう。事業部長が出張ってハッパをかけにきたのも、開発費がいたずらに上昇しているのが数字に表れたからだったと推測します。

●これって職場いじめ？

　ちなみにこのプロジェクトでのわたしの仕事は散々でした。工程に余裕がありませんでしたので、実装作業にむだが出ないよう毎日ミーティングを開いて進捗を管理したのですが、それが厳しすぎると思われたのか、SEの1人から猛烈に反発されました。技術的には不安のある人でしたが、そのチームでは1番の年配者で、職場では発言力がありました。進捗会議ではわたしに反抗的な態度を見せ、陰にまわってはわたしの悪口を言っていたようですが、こちらは新参者のPM代理、自分の権限もはっきりしていなかったので、手の打ちようがありませんでした。わたしを雇ったPMも何もいいませんでした。ともかくも実装作業が終わり、わたしはプロジェクト管理からはずされることになりました。やれやれ、これでプログラミングに戻れると思ったところ、いきなり契約を打ち切られてしまいました。理由ははっきりしません。PMからは何も説明がありませんでした。そのときは人間関係のトラブルがマイナスに評価されたからかと思ったのですが、どうやら単にプロジェクトに人手が要らなくなったから、不要の人間から切るということだったようです。

●泣きを見るのは外注PG

　コンビニの「名ばかり店長」に見るように、権限のない管理職は悲惨なものです。この会社のプロジェクトはまだ幸せな方でした。PMが自分の裁量で人員を増やす権限を与えられていたのですから。PMにそういった権限のない場合、またそういった予算のないプロジェクトの場合、事態は悲惨なことになります。しかもその被害は下流の実装技術者が受けやすい。各工程で起こる問題は、例えば人的資源の不足であったり、現場技術者の怠慢であったりしますが、PMはこれらをそれぞれの工程で解決するようなことはあまりしません。スケジュールの遅れにして先延ばしします。増員が無理でも時間の配分は自分の判断で簡単に裁量できるからです。人は自分の自由になる方法で問題を解決しようとするものです。それがたとえ一時しのぎに過ぎないとしても。問題が先送りされた結果、実装工程がひどい労働条件になっても、元請から文句をいわれなければ自分の責任ではない。そして元請は作るものだけ作ってくれるなら文句はいわない。泣きを見るのは外注PG、ということになります。

●本当はすごい実装工程

　こんな理不尽な理由から過酷な条件を突きつけられても、これまでPGが何とか耐えてきたのは、技術革新のおかげで実装工程の生産性が日夜向上してきたからです。JavaによるWebアプリケーションでいえば、IDEツールとしてeclipseが無料で利用できるようになり、Struts、Springなどの優秀なフレームワークがオープンソースで供給されたことなどによって、実装工程は格段の進歩を見ました。それがなければWebサイトの実装を2週間で仕上げろというような無理な注文には対応できなかったことでしょう。

　しかしこのことは「上流」からは見えにくい。eclipseもStrutsも実装者がネットで手に入れたフリー（無料）の資源ですから、コストの要素として意識されないのかもしれません。ふつう技術革新は生産工程にプラスになると考えられていますが、実際はそんなに単純ではありません。逆に全体の生産コストを増やしてしまうかもしれない。「無理を承知でPGにやらせてみたらうまくいってしまった。ラッキー♪」で終わってしまったら、そのPMはこまったPMです。

●技術革新の落とし穴

　本来、技術革新は工程ごとの資源配分とともに評価されなければなりません。ある作業で生産性が上がっているとしたら、それは何が原因でそうなっているのか。それは持続するのか。そのことで生じた利益はコストに正しく反映されているか。そういった分析をしなければ正しいマネジメントとはいえません。この場合、実装工程で生じた余裕が設計工程でむだに費消されてしまっているので、全体のコストが下がらないし、逆に上昇してさえいるのです。

　さらにこの状況を助長しているのが、大手が受注して下請けが生産するというIT業界の産業構造にあるのです。先ほどふれましたように、IT業界ではどうしても大手SIerに受注が集まってしまう傾向がある。というのもソフトウェアの開発は事前にコストを見積もるのがむずかしい。くり返しになりますが、わたしたちが作っているものは「特注品」です。しかも実装にどれだけの時間がかかるか、わたしが自分で作る場合でも正確な数字は出せません。まして実装作業はPGの技量に大きく左右されます。PMはそれを無理やり「人月」ではかって見積もりますが、開発の規模が大きくなるにつれてその誤差は拡大するでしょう。この誤差がもたらすリスクは中小SIerの経営を揺さぶります。それで中小SIerは大手から仕事をもらうようになる。

●まちがったビジネスモデルがもたらす悲劇

　しかしこのビジネスモデルでは、元請SIerからはコスト発生の構造が見えなくなります。元請は案件の受注を増やして見えないリスクを吸収しようとする。それを下請けSIerにばら撒くようにして作らせるわけで、当然個々の案件については目が届かなくなる。下請けの言うとおりに開発費を支払うのだけれど、それが有効に使われていない。たとえていえば穴の開いたバスタブにお湯を張ろうとしているようなものです。

　こんなことをいうと誤解されそうでいうべきかどうか迷うのですが、「下流」のわたしが見るところ、Webアプリの開発はもっと少ない工数で開発することができます。わたしにはソフトウェアの「形」が見えるのでそう思うのです。そして設計工程の人員を減らし、ユーザーとプログラマが直接対話して仕様を作っていけるような開発体制を作れば、その工数はもっと減らすことができます。

　しかしこれはリスクが低くなるということではありません。ソフトウェアの開発リスクはその作業の特性上、下がることはありません。ただそれはお金に換算して負担すべきものではないのです。例えばリスクを絶対に予測できないビジネス、鉱山業や石油採掘ならこのモデルは有効でしょう。大鉱業資本は、有象無象の山師が持ち込む投資話にいちいち耳を傾けお金を出してきました。その投資の多くがむだになったことでしょうが、そんなむだがなければ今日わたしたち人類が利用できる地下資源の多くは発見されなかったことでしょう。しかしソフトウェア開発はそうではありません。リスクをお金で解決しようとしても、余分な投資は本来流れるべきところに流れず、要らぬところに流れてしまうのです。

●これはPMの責任ではありません

　このようなことをいうと、PMにすべての責任があるように聞こえるかもしれませんが、私は決してそういうことを言いたいわけではありません。PMはたんなる労働者にすぎません。PMは雇用主、注文主の求めに従って作業を配分し、経済原則に従ってアウトソーシングしているだけなのです。問題は仕事の性質に適合しないプロジェクト管理が、業界の構造によって維持されてしまっていることにあるのです。

　リスクは本来それを負担できる人が負担し、評価しなければなりません。今のビジネスモデルを維持していこうと思うなら、元請は生産工程に目を光らせ、個々に発生した遅滞の原因を突き止め、工程の誤りを是正していかなければなりません。そうしなければリスクの原因はいつまでも解決されず、IT開発はいつまでもハイリスクな事業にとどまるでしょう。リスクの芽は小さなうちに摘み取ってしまう。そうすればそのリスクは次からは予測可能になる。そのようにして管理を洗練していくことこそ本来あるべきビジネスの姿ではないでしょうか。

　件の事業部長にはこのようなことをするどく指摘してもらいたかったのですが、どうも教養がじゃましたようですね。

●現代の若者は大志を抱けるか

　わたしたちのIT業界は技術進歩の激しいところです。半年前の新技術はもう古いものになっています。技術の進歩は作業工程の生産性を大きく塗り替えます。このことはプロジェクト管理の面から見れば、たぎった溶岩の上にいるのと同じです。プロジェクト管理はそのことに敏感でないと、プロジェクトを大きくゆがめます。われわれの業界は、すさまじい技術革新による生産性向上にもかかわらず、「3K」と呼ばれて若い人に敬遠されています。生産技術の革新が生産現場の労働条件の改善に結びつくどころか、逆に悪化させている場合、それはなによりもまずプロジェクトの管理に問題があると考えるのは常識ではないでしょうか。ところがこの常識がこの業界では通用しない！

　大手SIerの経営者は「10年は泥のように働け」などという前に、このことを考えてほしいものです。

注1：この見解には異論をもたれる方も多いでしょう。最近は「ソフトウェアプロダクト」なる概念も提唱されていますが、この考え方は生産性向上という面においてはあまり効果をもたらさないように思います。これについてはいずれ私見を申し上げようと思います。