この国のソフトウェアの開発現場の状況をみると、依然として、その職場に置ける“これまでのやり方”を引きずっています。「経験に基づいて」いるといえば聞こえが良いのですが、現実はそんなものではありません。単に、“そうやってきた”だけのことです。言語やいくらかのツールの導入といった開発環境の変化も、必ずしも開発方法の変化を促さなかった。そこで行われてきたことは、根本的な解決方法ではなく、国の「景気対策」のように延命策に終わっているのです。そのために、結果として本来の転換を先送りしてきたのです。
「言語」でかわして来た歴史
多くの組み込みシステムの開発現場では、今からおおよそ１５年前、要求される機能の増加に伴ってコーディングの作業量が増えだし、残業時間が多くなってきたころに、より生産効率の高い「Ｃ」言語が普及していて、こぞってそれまでのアセンブラから乗り換えました。これだけでコードの生産効率が平均して約３倍にアップしたわけです。言語を変えただけで、細かなバグは減ったし、今までのようにＣＰＵの変更に振り回されなくてもすむようになりました。ＣＰＵの乗り換えの障壁もほとんど無くなったものと思われます。その結果、その場にあった問題のいくつかはそれに連動して消えてしまったのです。でも開発方法はそれまでと何も変わりませんでした。
その後も、ＣＰＵやメモリーの性能アップ、半導体の価格の低下などによって、再び機能の集積ピッチが上がり、最近では製品の開発サイクルも短くなってきました。コード量も次第に増えだし、ソフトウェアの開発チームは連日、夜遅くまで作業が続くようになっていますし、土日もほとんど休めなくなってきました。すでにあふれた分は外注に回しているものの、外注管理のまずさもあって仕事の量は減る様子が見えません。
そのような時に、世の中を見渡せば「オブジェクト指向」が氾濫しています。「Ｃ＋＋」などのオブジェクト指向言語も普及しており、ビジュアル系の言語も使いやすくなっています。そして、かって「Ｃ」言語で救われた経験を持っている人たちは、今は組織の中核にいます。いわゆる「管理職」であったり、プロジェクト・マネージャーであったりします。ただ、今回の言語は、「Ｃ」の時とは勝手が違うので戸惑っているとは思います。言語の方向性も違うし、新しい概念がいくつも入ってきていますので、かってのように簡単には行きません。でも昔の成功体験がそこにあるので、恐らくこれで切り抜けようとするでしょう。
言語の生産効率もは、「Ｃ」と比べて、「Ｃ＋＋」で２．５倍、ビジュアル系の言語では４倍です。また、最初からメンテナンスの容易性を確保した設計がなされていれば、その後の保守開発の作業の効率は、言語の生産効率以上のものが手に入ると思われます。でも、この先の半導体技術の発達やネットワークの普及を考えると、すぐに同じ問題に遭遇するでしょう。
いつまでも「言語」だけで問題をかわせないにもかかわらず、多くの現場では今回も開発プロセスに何ら着手されていません。
みんな同じ状態
ではなぜ、そのような非効率な作業でも、今日まで存在し続けることが出来たのか？ 生産性が上がらないし、人手もかかってしまうのに、どうしてやって来れたのか？
その答えは、みんな同じことをやってきたからです。私自身、実際に全国調査したわけではないので、これは推測です。でも１社でも優れた開発方法を手に入れていれば、旧態依然とした開発方法から変わることの出来ない組織は、競争力に於て劣るわけですから、ある時間の中で存続できなくなっている可能性があります。もちろん、経営の問題はソフトウェアの開発方法だけで決まるわけではありませんが、そこでうまくいけば、例えばＣＭＭのレベル２や３あたりへの取り組みは、ソフトウェア以外の組織にも簡単に応用できますので、その気になりさえすれば組織としても相当な競争力がつき、総合的な効果は出てくるはずです。シックスシグマやＡＢＣ／ＡＢＭへの取り組みも容易になるはずです。
もう一つ決定的な差にならなかった理由は、この国では、ある部署においていくら生産性を上げても、雇用に手を付けることが出来ない状態であったため、結局は、生産性などの経営指標の改善に現れるところまでは行かないということです。たとえばＱＣ活動からＴＱＣやＴＱＭに切り替えても、雇用問題に行き当たる前に活動を止めなければならなかったわけです。雇用に触れることが出来ないという足枷のために、いくら改善しても大きく収益に貢献しなかったし、それ以上の活動の動機を見失うことになります。実際、「シックスシグマ」は、日本のＱＣ活動が元ネタなのですから、皮肉なものです。
もし、このような足枷が無ければ、個々の部署での開発方法の改善は、企業の競争力の差となって現れたはずで、そうなれば、今日のように非効率な開発方法しか持たない組織は残っていなかったかもしれません。
足枷は外される
そして、この雇用の足枷は、１０年という平成不況の中でようやく外されようとしています。たとえ泳ぐ力を持っていても、この足枷を付けた状態では、みんな沈んでしまいます。雇用を守るあまりに本体が沈没してしまっては元も子もないということで、さすがに企業が独自の判断で足枷を外すことについては、政府も見て見ぬ振りをするしかない状態です。ルノー・日産が決定的な役割を果たしたと考えています。足枷には別に鍵がかかっているわけではありませんので、外そうと思えば簡単に外せます。単に自制していただけですから、背に腹は代えられない処まできたことで、企業がそれぞれの判断で外し始めたわけです。もちろん、そこにはモラルハザードというリスクは伴いますが、そのリスクの対応方法はわかっています。その対応をとりながら、まずは少しでも身軽にしないと身動きできません。
ソニーに続いて、東芝もシックスシグマに取り組んでいるようですが、これなどは今までの足枷を前提にしていたのでは取り組めるものではありません。それに「経済のグローバル化」は、企業の評価は株主がおこなうという考え方を受け入れることでもあり、その面からも、足枷は経営者の判断で外せるようになったはずです。日本の企業だけ、妙な足枷をはめているのでは、海外の人たちにとって投資の対象にならなくなってしまいます。
マネージャー次第
このような状況にあって、もっとも重要なのが現場のマネージャーがどう行動するかです。自らの組織を、競争力のある組織に変貌させるためにどのような行動にでるかです。もちろん、ここでいう「マネージャー」とは、複数のプロジェクトの責任者であり、（いくらかの）人事権を持っています。また、制限はあるかも知れませんが決裁権を持っている人でもあります。要するに、組織の進む方向を決めることの出来る人であり、組織的問題の最前線で戦う人です。
しかしながら、今、このような立場の人達はほとんど動こうとしていないように見えます。“なんとかしないと・・”と思っているのかも知れませんが、いったいどのように動けばいいのか、どの方向に動けば良いのかが分からないのかも知れません。
現場のエンジニアに対して何らかの教育を実施しても、それを活かすのはそこに居るマネージャーです。個々のエンジニアは、身に付けた技術を活かす場面を勝手に作りだすことは出来ません。たとえ出来ても、小さな範囲に限られるでしょう。多くの場合、新しい技術というのは、必ずしも今の現場の作業の一部を取り換えるようにはなっていないのです。もちろん、稀には「置き換え」ることの出来る新技術もあります。「Ｃ」言語を導入したとき、本来なら、分析から設計工程まで含めて変わるべきところだったのですが、実際にはほとんどの組織では、単純な「コーディング作業」だけの置き換えで済ませたのではないでしょうか。ちょうど、金槌を自動釘打ち機に変えただけのようなものです。ＣＡＳＥツールがうまく導入できない理由も此処にあると考えています。
ですから、たとえば何の設計手法も存在しない“手作り”の組織に、オブジェクト指向を身に付けた一人のエンジニアがやって来ても、たぶん手も足も出ないはずです。彼には、他の人の作業の流れや切り口を変えることはできませんし、開発チームの中で、自分一人だけでもオブジェクト指向で設計しようとしても、すぐに限界に行き当たるはずです。それを承知で取り組むしかないのですが、チームとしてあるいは組織としての効果はほとんど得られないでしょう。
また、エンジニアが新しい分析手法や設計方法を勉強して来たといっても、マネージャーが“そんなもの書いている時間があったら、さっさとソースを書きなさい”と言ったら、全てが「パー」なのです。実際、このような光景は何度も目撃してきました。従って、組織を変えることが出来るのはマネージャーなのです。マネージャーが、自分の手でこの事態を何とかしようと考えるかどうかなのです。
ＣＭＭの取り組みもマネージャー次第
ＣＭＭの取り組みも、マネージャー次第です。彼の管轄が狭いものならその範囲でしか実現しないし、広い範囲を持っているなら、いずれはその範囲で実現するはずです。ＣＭＭといっても、手順とポイントさえ押さえればそれほど難しいことはないのですから。もちろん、そこにいる人達の意識や評価基準なども変わる必要があるため、最低でも数年という時間はかかるでしょうが、要は、そこにいる人たちが、もっと効率良くソフトを開発できる方法を手に入れようとするかどうかです。それには、“今住んでいる場所”を離れなければなりません。今までやって来た役割も変わってしまいますし、今までのやり方によっては「分担」の切り口も変わります。中には、やったこともない作業（プロセス）をやらなければなりません。
それは、今まで小さな農機具した使ったことのない人が、干害設備が整って大型の機械化が可能な広大な農地を手に入れるみたいなものです。そこには温度管理の利いた種苗ハウスもあります。小型の野菜や花卉の一部は天候に影響されないようにコンピュータで管理された「工場」で作ります。土も、５メートル以上耕されていて、肥料の利いた土が仕込まれています。隣接地には、有機肥料を作るプラントまで作られていて、適時補っていくこもで来ます。
でも、その辺の土地を鋤鍬で適当に耕して作物を得ることしかやって来なかった人たちにとっては、このような広大な農地や先進的な施設をどうやって使えば良いのか分かりません。ＣＭＭに直面しての戸惑いというのは、ちょうどこんな感じです。
そうは言っても、今までの「所」では、作れるものは限られています。競争が無いのならそれでもやっていけるかも知れませんが、現実にはそうは行きません。作っているのは工業製品であり、それらは全て競争に晒されているのです。みんなが、鋤鍬で作業を続けているからやってこれたのであって、どこかのグループが、このような近代工場を作ることが出来れば、その時点で、無競争の歴史は止まってしまいます。
そして厄介なのは、競争相手は島の人間だけではなくなったということです。外からやって来て、さっさと近代工場を作って作業を始めることが可能になったのです。このことをマネージャーは気づいていなければなりません。今までなら、島の人間の動きを見ていれば良かったのですが、これからはそうは行かなくなったのです。
このことを見越して行動できるのは、まさにマネージャーなのです。「if」の間違いや仕様の不備に振り回されることが無いのですから。
まずマネージャーの教育を
だからエンジニアを教育する前に、今いるマネージャーを（再）教育すべきなのです。彼らが今までの「管理職」から「マネージャー」に変わる必要があります。この層が「変化」すれば、組織は一気に変化するはずです。シックスシグマの取り組みでも、最初は「ブラックベルト」の養成から始めます。そして「グリーンベルト」や「チャンピオン」と言うように、専門的に指導する役割の人や、組織のマネージャーに相当する人に対する教育から取り掛かるべきなのです。ＣＭＭだって同じです。多くの日本の組織では、なぜかこれが逆になっているのです。号令だけの時代は終わったのです。変革の道筋を示し、自らリードするマネージャーが求められているのです。
１個人が、日々の生活の中でこのように大きく変化するには、それなりの動機が必要ですが、組織には「人事」という手続きがあります。これを使うことによって短期間に方向を変えることが出来るのです。ただ報告を待っているだけの管理職、御輿に乗るだけの管理職はもういらないのです。２１世紀になって、電子メールもインターネットも自分で扱えない「管理職」に、いったいどのような活躍の場がありますか？ ＦＡＸで有名だったＧＥのウェルチ会長も、最近は電子メール使ってさらにスピードアップしているようです。
教育内容としては、とにかく自らの組織のビジョンがもてなければなりません。その組織の「あるべき姿」が描けなければなりません。それが書けないようなマネージャーに、多くの若い人生を託すことはできません。そのために、自ら進んで世の中の経済的社会的な動きをキャッチする方法を持っていなければなりません。最新の技術動向も頭に入っていなければなりません。それらが、いちいち部下からの報告に頼っているようでは、もう間に合いません。自分で情報収集のネットワークを構築すべきです。特に“分野を越え”た領域での技術動向を手に入れるには、自ら発し自ら動くしかないのです。
その次に、どの部門のマネージャーであっても、経営指標の意味が分かっていなければなりません。そして、自分たちのどのような行動が、これらの経営指標の何処にどのように現れてくるのかを理解しなければなりません。現実問題として、これが出来ないから、全社的目標を自分の組織にブレークダウンできないのです。資本主義経済にあって、企業の経営指標を意識しないような行動に、いったいどのような意味がありますか。
そこで認識しておいてもらわないと困るのが「プロセスの定義」や「ソフトウェアの計量化」です。計量化が何のために必要か、計量化をどのように進めればいいのか、といったことを含めて、計量化の意義をしっかりと認識しておいてもらう必要があります。そし計量化は「プロセス」の確立が前提となります。この計量化が出来ないと、アクションの効果を測る方法を持たないことを意味しますので、経営指標をにらんだマネージメントが出来ないことになります。シックスシグマの取り組みも、プロセス化と計量化は避けて通れないのです。
ＩＴ技術だけでマネージメントはできない
多くの日本の組織では、相変わらず経験年数で昇進が決まっています。もちろん、その前にプロジェクトが成功（と見做せる状態）していることも考慮されるでしょうが、マネージャーになるのに、マネージメントのスキルが判断されることはほとんどありません。それどころか、１週間前には、ソフトウェアの開発部隊のリーダーであったりします。それが、ある日突然に、１枚の辞令でマネージャーの仕事を「仰せつかる」のです。
彼が身に付けているのは、いわゆる「ＩＴ技術」であって、多くの場合、マネージメントの知識や技術は含まれていません。それは、オブジェクト指向の技法であったり、ＨＴＭＬ言語であったり、ＴＣＰ／ＩＰの技術であったり、ＣＡＳＥツールの知識ではあっても、リスク管理やプロジェクト管理は含まれていません。プロセスの改善方法は知りませんし、メンバーのイノベーションを高揚させる技術やノウハウも含まれていません。もちろん苦手な人を動かすノウハウも含まれていません。昨日まで、組織はそのような「もの」を彼に求めてはいなかった。このような状態であるにもかかわらず、「来月からマネージャーに命ずる」というのです。
これは無茶な話です。確かに昔は、その役についてから勉強したのかもしれません。それで出来た（間に合った）のかも知れません。でも、今日のソフトウェアの開発組織では、それは無理です。その最大の原因は、この世界はすでに「チーム」で動いているということです。そして、市場から寄せられる要求は、複雑で短期間のうちに変化します。それらに応えるためのマネージメントのスキルは、それまで使ってきた「ＩＴ技術」とは大きく異なります。
役所のようなところでは、多くは、「経験」だけで「役職」はこなせるかもしれません。戸籍課にチームマネージメントや、プロジェクト管理が必要になることはないでしょう。住民からの依頼などの「手続きの流れ」を理解すれば足りるかも知れません。そこでは、年功の人事で通用するでしょうが、ソフトウェアの開発組織では、何度も言うように、そうは行かないのです。
忘れられた心理学
そしてもう一つどうしても学習して欲しいのは「心理学」です。この国は、心理学を軽視しすぎです。大学でも、特に理系？の人は心理学の講義をまともに受けていない人が多いのではないでしょうか。もしかしたら「以心伝心」という言葉に眩まされているのではないでしょうか。アメリカはもともと多民族国家なので心理学が必要だが、日本は単一民族の国だから必要ないとでも思っているのでしょうか。だとすれば大間違いです。
日本人が単一民族だというのは、最近のＤＮＡ研究で完全に否定されています。むしろ他の国よりも多くの民族が混ざり合っているとも言えるのです。もう一つ、戦後の復興期にあっては、労働環境も含めて個々の労働者には選択の余地が与えられていなかったことが、あえて心理学の出番が作られなかっただけです。でも今は違います。仕事をする目的も意義も、人によって違っています。なによりも、そこにいる人たちは「選択の世代」なのです。それに、いつまでも“日本人”だけの組織で居続けることはできないでしょう。私の見る限り、「多国籍化」の準備はほとんどなされていなません。
組織は、機械で構成されているわけではありません。組織は「ひと」の集まりなのです。たしかに企業という組織は、その性格上、そこに集まる人の目的はある程度集約されますが、それでもいくつかの選択性は残されています。それゆえに「ひと」が分からなくては組織は動かせません。喜怒哀楽が分からなくて、どうやってそこに居る人たちに喜びを与えることが出来るでしょう。
心理学を捨て置いたままで、「マネージメント革命」は起こせません。大学などの教育機関も、早くこのことに気付いて欲しいと思います。そして現実的で効果的なカリキュラムを作って欲しいと思います。個人的には、いろいろと勉強しているマネージャーも居るでしょうが、全体としては、今のままでは、軽薄なマネージメント（マネージメントと言わない？）しか出来ないでしょう。Ｈ２ロケットの失敗やＪＣＯに臨界事故などを見ていると、組織の能力、とくにマネージャーの能力が、どんどん低下しているように思えてなりません。
次はマネージャー候補
現役のマネージャーに対する教育に続けて、現場のリーダーである「マネージャー候補者」に対する教育を早めに実施すべきです。もちろん実施時期はいくらか重なってもよいかとは思いますが、出来れば重ならない方がいいと思います。マネージャーの教育が終わっていることで、候補生が教育から戻ってきたときのことを考えることが出来るはずですし、それを求めなければなりません。
それと、現実問題として自分の配下の候補生を一斉に教育の場に送りだすことは、業務が止まってしまう危険もあります。したがって、最初に教育を受けたマネージャーが、自分のビジョンに沿って候補生に対して研修を受ける順序を決めなければなりません。その意味では、早速マネージャーとしての行動が試されるのです。
教育内容としては、心理学も含めて、基本的にはマネージャーが受けた内容はそのままこれらの人たちも受けることになりますが、その他に、「プレーイング・マネージャー」の役割についての教育も受ける必要があります。人によっては、「現役復帰」を意味することになるかも知れませんが、意味のない「管理職」を減らすことも必要であり、そのことに対して組織は直ちに行動することが求められているのです。
もちろん、現役復帰と言っても、コードを書くことに戻ることはないでしょうが、プロジェクト・リーダーやソフトウェア・リーダーとして復帰することは可能なはずです。いや、むやみにマネージャーを増やすよりも、その人がもっとも能力を発揮できるところで活躍してもらう方が、組織にとってもメリットがあるはずです。
現場のエンジニアの教育はその後です。もちろん、ここでいう教育とは、組織で行う教育であって、各人で取り組むことを否定しているわけではありません。とは言っても、マネージャーの状態によっては、個々のエンジニアが自分で勉強したことが、容易には活かされないことは承知しておくべきでしょう。
残念ながら、現実は、ここで述べたことと全く逆の事が行われているのです。嗚呼。