ソフトウエア開発の「マネジメント法」確立のために
岩尾 俊二 (いわお しゅんじ)
(株)構造計画研究所
情報技術部長
◆プロフィール◆
1949年生まれ。1973年、京都大学理学蔀数学科卒業。（株）構造計画研究所に入社。プログラム開発部（現システム開発本部の母休）に所属し、主にメインフレームのプログラム開発に携わる。1979年、所長室に異動し、数値演算処理に特化した「高速マトリックス演算ソルバー」の企画・検討を行う。1980年からは「科学技術分野向けプログラム生産技術開発」プロジェクトの主任設計者を務め、商品化と社内利用の促進に従事した。1986年、新設ビジネスユニット「ソフトウェア営業部」に異動し、前述の商品化製品の技術支援と改版に従事。部分的に営業活動も経験。1988年、システム開発部に戻り、国産互換メインフレーム機向けのRDBMSの開発に参画する。
現在、マネジメント職を遂行しながら、社内の1949年生まれ。1973年、京都大学理学蔀数学科卒業。（株）構造計画研究所に入社。プログラム開発部（現システム開発本部の母休）に所属し、主にメインフレームのプログラム開発に携わる。1979年、所長室に異動し、数値演算処理に特化した「高速マトリックス演算ソルバー」の企画・検討を行う。1980年からは「科学技術分野向けプログラム生産技術開発」プロジェクトの主任設計者を務め、商品化と社内利用の促進に従事した。1986年、新設ビジネスユニット「ソフトウェア営業部」に異動し、前述の商品化製品の技術支援と改版に従事。部分的に営業活動も経験。1988年、システム開発部に戻り、国産互換メインフレーム機向けのRDBMSの開発に参画する。現在、マネジメント職を遂行しながら、社内のベストプラクティス還流化活動、社外では1S015939 標準化委員会への参画など、業界発展にも幅広く貢献している。ベストプラクティス還流化活動、社外では1S015939 標準化委員会への参画など、業界発展にも幅広く貢献している。
岩尾俊二は、定量的な測定方法を用いて、ソフトウエア開発における「マネジメント法」の確立を目指し、社内のみならず社外で旺盛な活動をしている。
岩尾は1949年に生まれた団塊の世代の一人である。1973年に京都大学理学部数学科を卒業した岩尾は構造計画研究所に入社する。当時はまだ大学紛争の残り火があった頃である。岩尾自身は「数学科に籍は置いていましたが あまり勉強はしませんでした」と謙遜する。
岩尾自身はとくに情報サービス産業やソフトウエア産業に典味があって、この業界を選んだわけではないという。いくつかの会社の入社試験を受けたが、いずれも不合格になり、結局、構造計画研究所に入社したのだ。
入社時には、当時の部長から「学生時代、元気がよかったらしいな」とからかわれたらしい。このような経緯で入社したために、何をやっている会社かもよく分からなかった。もちろん大学時代にコンピュータのことはまったく勉強したことはなかった。
コンピュータ使用料金十万円、オペレーター料金三千円
入社した岩尾は七年ほど、コンピュータ・メーカーのシステムソフトウエア関連の開発に携わった。
「最初はコンパイラ、エデイターなどのソフトウエア開発のための支援ツールを開発しました。その後研究用のシミュレーションソフトウエアも開発しました。」
この頃、岩尾には強烈な思い出がある。
「入社三年目にIBMに対抗する国産の互換機コンピュータを使ってシステムソフトウエアを開発していました。そのコンピュータは新宿の住友ビルに設置してありました。夜中に開発をしていたので、明け方に支払いのために、そのコンピュータの使用料の請求書をもらいます。それにはコンピュータの使用料金が十万円、オペレーター料金が三千円とありました。こんな程度にしか人間は評価されていないのか、これではダメだと思いました。」
三十歳で、岩尾はソフトウエア開発の生産性向上のためのツールづくりのプロジェクトに参加する。このプロジェクトは通商産業省（現経済産業省）が助成金を出し、様々な会社からのメンバーで構成されたものであった。岩尾はここで初めてプロジェクト・リーダー、主任設計者となる。このプロジェクトではデータベースシステム、FORTRANなどのバグを自動的こ余し去する仕組みをつくった。このプロジェクトは二年で解散してしまうが、岩尾自身も認めているが、その後の岩尾の生き方に大きな影響を与えた。後にこのプロジェクトの成果の一部を活用して、パッケージとして販売をすることになるのである。
さらにもう―つ岩尾に大きな影響を与えたプロジェクトがある。1982年のIBM産業スパイ事件の影響で、国産コンピュータ・メーカーが独自にIBM互換機のリレーショナルデータベースを開発しなければならなくなり、このプロジェクトのリーダーとなったのが岩尾であった。結局、設計、試作バージョンまでつくった時点で、プロジェクトは中止になった。しかし、このプロジェクトのリーダーの経験も岩尾にとって強く印象に残っているという。
業界には多くの無謀なプロジェクトがある
二つのプロジェクトのリーダーを経験した後、岩尾はマネジメントに携わるようになる。
「最初はとまどいがありましこたが、自分の適性はソフトウエア開発より、マネジメントにあるように思いました」
このように岩尾が思い始めたのは、それまで業界で行われていたソフトウエア開発プロジェクトの進め方に対して、大きな苛立ちを感じていたからである。その理由はソフトウエア開発に試作の段階がないこと、何が技術的に最適かが、十分に検討されていないこと、ユーザーの真のニーズが不明確なままにソフトウエア開発が行われることなど、三点にまとめられる。
「ソフトウエア開発には試作段階がありません、試作段階がなくては、本来はエ数の見積もりもできません。また、開発に使用される技術が最適で、実際に目標を達成できるのか、何が最合わせなのかが分からないままにソフトウエア開発が行われています。ユーザーのニーズといいますが、ユーザーの真のニーズはどこにあるのか、そのニーズは誰が出しているのかを見分ける必要があります。しかし、それも十分に行われていません。結局そうした無謀なプロジェクトが、業界では現実に動いているのです。それでは基本的に成功するわけがありません。」
そして、岩尾はその解決策としてマネジメントの重要性を強調する。
「人は不安になって早く実作業に入りたくなります。様々なリスクがあり、それを考慮するためには本来は机の上での作業が必要なのです。結果が良ければリーダーは誉められるでしょう。しかし、失敗した時にはプロジェクトのメンバーは自分の心を整理できなくなって、疲弊します。会社を辞める人も出てきます。そんなことは自分のところで起こしたくありません。そのためにはマネジメントが重要なのです。」
路線バスのダイヤ編成システムの意外な成功
岩尾は主にOSやシステム周りのソフトウエアの開発を手がけているが、意外なところでも成功を経験している。
それが路線バスのダイヤ編成システムである。それまで路線バスのダイヤ編成はワークス
テーションを使って無行われており一つのシステムが一億円から二億円もした。それをパソコンで処理すると、一つのシステムが数千万円で構築できる。1991年、岩尾は路線バスダイヤ編成システムわパソコン処理に切り替えるための開発を初めて手がけたが、その際大赤字を出してしまった。
「最初はお客様のニーズの深さが分からなくて、どんどん仕様が膨らんでしまい赤字になってしまいました。ソフトウエア開発プロジェクトにおける失敗の典型です。」
ここでもソフトウエア開発におけるマネジメントの重要性を、岩尾は認識している。
しかし、その後は順調に進み、大手バス会社の半分以上のマーケットを確保している。日本には百台以上のバスを所有するバス会社は二十社程度しかないという。
「どこもやってない狭い市場でしたが、製品を差別化して投入できたことで成功しました。構造計画研究所というと建築関係の製品が強いのですが、それ以外のマーケットのビジネスモデルができました。」
ソフトウエア開発の管理者の四つの能力
岩尾は前述のようにソフトウエア開発プロジェクトにおいてマネジメントが重要だと力説し、ソフトウエア開発における「管理者」としての必要な能力を四つ挙げている。
第一は、「ユーザーの利害関係者の構造を分析して、キーパーソンを嗅ぎ分ける能力」である。これによりユーザーの真のニーズが把握でき、ソフトウエア開発プロジェクトの目標も明確になる。
第二は、「自社の利害関係者のあり方を認識して、必要であれば部門を超えてもリソース（資源）を獲得、利用する能力」である。
第三は、「山のようにある失敗の要因を先読みする能力」である。たとえば、部下のアウトプットを客観的に把握することはできるが、それだけではなく、とくに部下の顔つき、目つき、ため息に注意を払っていなければならない。しかし、これを行うのは数人の部下であれば問題ないが、人数が多いと、マネジャーにとって大きな負担になる。
そして第四は、「案件のゴールのイメージ、つまり成功の道筋を描く能力」である。たとえ上司がゴールのイメージを描けても、あえて部下にイメージを描かせる。その上で部下の描いたイメージを修正させることが大切である。
「マネジャーが明確な目標を示せば、メンバーは実力以上の能力を発揮します。マネジャーが明確な目標を示せないと、どんなに優秀なメンバーが集まっても、そのプロジェクトは成功しません。」
プロジェクトの成否を分けるマネジャー
岩尾は「蟻」の集団をたとえに使って説明する。
「蟻のうち実際に働いているのは二割で、残りの八割は遊んでいます。その遊んでいる八割の蟻だけを別にするとその中からまた二割の蟻が猛烈に働くようになります。この現象はソフトウエア開発プロジェクトにも当てはまります。」
つまり平凡なソフトウエア技術者であっても、しっかりしたリーダーが明確な目標さえ示せば、非凡な能力を集団として発揮すると岩尾は考えている。
実際に、目標がハッキリしないために失敗したプロジェクトは幾らでもある。岩尾は通産省が助成したソフトウエア開発プロジェクトで、プロジェクト・リーダーとサブリーダーの技術的志向の違いから、目標がメンバー全員に明確にならず、「メンバーがつくったプログラムを壊して、また別につくる」という失敗の例を間近に見ている。
また岩尾自身にも苦い失敗の思い出がある。岩尾の部下が、まとめることが不可能なまでに、ソフトウエアの仕様を拡大してしまった。本来実現不可能な機能まで契約書に盛り込んでしまったのである。
「最終的には、何とか着地点を見つけてまとめました。当時まだ私も若かったものですから、管理者として介入すべきタイミングを逸してしまったのです」
このように、岩尾はソフトウエア開発において管理者が重要であると考えているが、現在、業界では、このような「マネジメント」に関する教育が欠けていると指摘する。
「ソフトウエアのプランニング、コストや品質、そしてそれらのトレードオフのバランスをいかに取るかなどの教育が重要です。しかしこれらの教育が、現在は欠けています。産業として成熟し、競争力をつけるには人材の教育研修プログラムを根底から変えなければなりません。」
「マネジメント法」の確立のために
マネジメントが欠如した「無謀なソフトウエア開発プロジェクト」があまりに多いことを嘆く岩尾が、現在行っているのは、まさにソフトウエア開発における「マネジメント法」を確立することである。
それが「ファンクションポイント法」の導入である。ファンクションポイント法は、1979年に、アメリカのIBMのA.J. Albrechtによって考案された方法であり、その後さらに改良が加えられている。この方法はソフトウエアの規模を、これまでのエ数の見積もりで用いられているステップ数を使うのではなく、そのソフトウエアが持つ機能から見積もる方法である。
「ソフトウエア開発における定量的な物差しで、生産性、納期などを過去のデータから予測するものです。」と岩尾は、その特徴を述べる。
この方法を利用することにより正確な見積もりが可能となるとされる。しかし、そのためにはソフトウエア開発において標準化や部品化が必要となる。その上でファンクションポイント法を導入することにより、見積もりが正確にできるようになるだけではなく、さらにソフトウェア開発における生産性の客観的な測定やその品質向上がもたらされることになる。
岩尾は、このファンクションポイント法の国内における普及団体である日本ファンクションポイントユーザ会(JFPUG)の研究活動や、それに関するISO標準化委員会にも参加している。またファンクションポイント法に関する書籍を翻訳し、日本国内に紹介もしている。
その上、同業他社や異業種でのファンクションポイント法の導入のコンサルテーションも行っている。
「無謀なソフトウエア開発プロジェクト」を嘆く岩尾にとって、このファンクションポイント法の普及、紹介は最適な仕事であると同時に使命であるに違いない。
また、これからのソフトウエア産業では国内のマーケットだけではなく、さらにインターナショナルマーケットからの調達が増加すると岩尾は見る。この国際化は避けることはできない。とするならば、これからはインターナショナルな取引のために、コミュニケーションの能力、そしてインターナショナルな知識が求められる。そのためには「頭が固くてはダメです。もっと頭の柔軟な若い人たちに活躍してほしい」と岩尾は若い世代に対する期待を述べた。
(takashi umezawa)
注 所属、役職等は取材時のものである。