これは日本の情報サービス業界の第一線で活躍し、一流といわれている26人のソフトウェア技術者、管理者たちのインタビューをまとめた梅澤隆・内田賢「ソフトウエアに挑む人たち」コンピュータ・エージ社 2004年のうち、梅澤が担当した「あとがき」と本文の一部を書き換え、再編集したものである。
26人のソフトウェア技術者おのおのの証言はそれぞれ興味深く、大いに参考になることは間違いない。しかし26人の証言には共通性があることもまた事実である。26人の技術者が卓越しているのは、必ずしも天性によるものではなく、たまたまチャンスに恵まれたからだけでもない。そこには共通の行動上の特性がある。このような高い業績を上げる人たちの行動特性は一般に「コンピテンシー」と呼ばれている。
ここでは26人のソフトウェア技術者、管理者たちのインタビューから、ハイ・パフォーマンスな技術者のコンピテンシー、つまり高い業績を上げる人たちの行動特性を考えてみよう。高い業績を上げる技術者、管理者、26人がどのような共通の行動上の特性を持つのかを明らかにすれば、それを取り入れることにより、誰もが「一流」の、そしてハイ・パフォーマンスな技術者、管理者に近づくことができるからである。
その前に、まず、彼らがどのようにしてこの業界に入ったのかを簡単にみてみよう。面白いことに、ソフトウエア開発が好きでこの業界に就職したものは意外に少ない。たしかに、新田（コア）の「ソフトウエアをつくるのが好きになりました」という例や、山本（ソラン）のように大学の卒業論文のためにプログラムをつくり、その過程で「ハードでもソフトでも達成感は同じで、これならソフトに人生を賭けてもいいなと思いました」という例もある。また西野（エスシーシー）のように高校時代に自らコンピュータ同好会をつくり、大学では情報工学を学んだものもいる。しかしこれらは多数派ではない。
また大学時代に趣味あるいはアルバイトでプログラミングやソフトウエアなどと関わりをもったものの、それが将来の自分の職業となるとは思わなかったものいる。たとえば南（新日鉄ソリューションズ）は大学で「東大マイコンクラブ」に入り、アルバイトにソフトウエア開発を行っていたが、ソフトウエア開発の仕事に就こうとは思わなかったという。「アルバイトで日立のSEと一緒に働きましたが、大変だという印象で、この仕事をやろうとは思いませんでした」。また入鹿山(NTTドコモ）も中学、高校を通じてアナログ回路、デジタル回路、プログラミングの技術を身につけたと考えて、あえて独学できない化学を大学では学んでいる。
小川（日立ソフトウェアエンジニアリング）は「ソフトウエアそのものの研究は大学院ではしませんでした。ソフトウエアを書いたこともありませんでした」と述べて、指導の先生からは「『ソフトウエアだけはやらない方がよい』といわれていました」と述懐している。
前田（住生コンピューターサービス）は大学在学中、コンピュータに触れたことは一切なかった。同じように中井（伊藤忠テクノサイエンス）も、就職するまでコンピュータとはまったく無関係であった。大学の数理工学を卒業した岩尾（構造計画研究所）もコンピュータとはまったく無縁の大学時代を過ごした。このようにコンピュータとまったく関係なく学生時代を過ごしたものもいる。
IT業界、ソフトウエア業界に入った具体的な経緯は多様である。それは最初からIT業界、ソフトウエア業界に就職したいと思ったもの、コンピュータ関連の勉強はしつつも、将来この業界にだけは入るまいとしたが、しかし結局この業界に入ったもの、そして学生時代にコンピュータとはまったく関係なく過ごし、何かのきっかけで、この業界に入ったものという3夕イプに整理できる。
しかし、いずれのタイプであったとしても、この26人の人たちは、現在I、T業界、ソフトウエア業界において現場の第一線で活躍している、一流のソフトウエア技術者、管理者といわれる人たちなのである。
- 現場を重視、しかし顧客のいうとおりにつくるな ！
26人の多くが述べているのが現場の重要性である。たとえば「客先に行って、お客様の声、営業マンの声、メンテナンスをしている人の声を聞いて、ものづくりに生の声を浸透させることが重要です。新しい仕事は、お客様、現場、マーケットの中にあります。社内にいて、社内の顔を見ているだけではインパクトのあるアイデアや新しい仕事は見つかりません」と内藤（富士通サポート＆サービス）は述べている。
内藤は、20年近くコンピュータ・システムのメンテナンスに従事した経験を通じて、お客さんの声を聞くこと、現場に立つことが、仕事するものにとっていかに重要であるかを、身をもって感じている。
南（新日鉄ソリューションズ）も、応用人工知能（エキスパートシステム）の開発を通じて、現場が重要だということが分かったという。
「現場で働いている人たちの知識を入れてもらって、知識ベースができるわけですが、そのためには人物当てクイズの知識ベースを仕込むなど色々工夫して知識を入れてもらうようにしました。工場の環境は悪いし、みんなコンピュータのそばでタバコを吸？から故障が起こります。ともかく現場に行って使っているところを見ないと何も分かりません」
ただし、この現場を重視するという姿勢は単にお客さんやユーザーの要望通りにシステム、ソフトウエアをつくるということではない。
田口(CRC ソリューションズ）、鵜川（野村総合研究所）は、そのことを強調している。田口は「お客様と議論し合える関係が必要です。お客様のいう通りに何でもつくってしまってはいけません。むしろシステムとして必要なものは何かという基本線を自分がしっかり持つことが必要です」と述べている。また、鵜川もただ現場を知っているだけではなく、問題意識を持った人と組むことの必要性を強調している。
たとえば革新的な「With スミセイ」を開発した前田（住生コンピューターサービス）は、試作の段階で、ユーザーである営業職の女性たちから多くの不満が出ることを期待していた。
しかし、あまりにその試作機が革新的であるために、ほとんどクレームはなく、唯一、本体の色は薄いピンクにしてくれという要望だけだったという経験をしている。
現場を重視するということは丸山（アイネス）が指摘しているように、顧客の要望とエンジニアの持つIT技術の「合わせ技」が重要であるということなのである。
「お客様がいった通りにつくりました」という方法では十分ではないと丸山はいう。そもそもはユーザーの仕事のやり方を熟知していない。おおまかな業務の流れは簡単につかめるかもしれない。しかしユーザーは仕事をする上でいろいろなノウハウを持っている筈だ。しかもユーザーは自分のやって欲しいことをSEにしっかり伝えられる訳ではない。うまく言葉で表せなかったり、また「こんなことができれば便利だ」ということに気づいていないこともある。
そこでSEはユーザーとしっかり話をして彼らの仕事の内容を知り、時にはユーザーにヒントを投げ掛けながら、彼ら自身がうまくいえなかったことを表現できるように助けなければならない。ユーザーが望んでいることを十分に把握し、それを実現できるようSEが自分の持つ技術でソフトウエアをつくり出すのだ。
ユーザーが持つ仕事のノウハウとSEの持つIT技術‘この二つの「合わせ技」で真に役立つソフトが生み出される。
つまり、よりよいシステム、ソフトウエアをつくるということはエンジニア自身だけでなく顧客やユーザーの仕事の現状をも変えようという姿勢が必要なのである。
- 真のリーダーはシンプルで、明確な目標を示す ！
ソフトウエア開発のプロジェクトチームでは当然のことながらリーダー、マネジャーの責任は重い。リーダーがいかに明確な目標を示すかどうかで、プロジェクトの正否は決まるといっても過言ではない。
リーダーの役割を内藤（富士通サポート＆サービス）は「私は企画書の作成、交渉など黒衣に徹しました。そして開発にあたったメンバーには、良いコンセプトができたら誉めて、次のより良い目標を設定します」と目標設定の重要性を指摘している。しかし単に目標を設定するだけではプロジェクトメンバーはついてこない。そのためには分かりやすく、追求すべき目標をシンプルにしなければならない。
中井（伊藤忠テクノサイエンス）は、テーマが一つであり、それぞれの立場で達成すべきことが明確だったことが満足な結果を生んだ、とあるプロジェクトの成功の要因を指摘しているが、目標を絞り込んで明確にしたのは、ほかならぬ中井である。さらに、たとえば西野（エスシーシー）は次のように述べている。
「バグがいくつあるか知らせずにバグを見つけろといっても、見つける方はいくつまで見つければ良いか分からない。しかし8つバグがあるから見つけろといって目標を与えれば必死にやります」。
つまり具体的でシンプルな目標を与えることが必要なのである。
事実、岩本（アルゴ21)は明確な目標を示すことができないために大きな失敗を経験している。「自分の目が届かないのでどこで何をやっているか分かりませんでした。知らないと判断できません。これはこうやれという指示もできません。どこに問題があるのかという指摘もできないのです」という状況に陥ったのである。これではシンプルで明確な目標を定めようがない。もちろん岩本は後にこの失敗から多くのことを学ぶことになる。
吉田(NTT コムウェア）は人事管理システムの開発にあたって、短時間でそれを開発するというシンプルで明確な目標を定め、そのため反対を押し切って外部の企業が開発したERPを採用した。
岩尾（構造計画研究所）は、目標の設定の仕方について次のように結論づけている。
「マネジャーが明確な目標を示せば、メンバーは実力以上の能力を発揮します。マネジャーが明確な目標を示せないと、どんなに優秀なメンバーが集まっても、そのプロジェクトは成功しません」
プロジェクトのリーダーは目標を明らかにした上に、さらにプロジェクトのメンバーに役割を認識させることが求められる。たとえば越沼は、次のように述べている。
「開発するシステムの意義を開発者に徹底することが重要です。システム全体を理解させた上で、各人が自分の担当している部分は、システム全体のなかでどのような意義を持っているのかを理解することが必要です」
- マネジメントはメンバーに優しく ！
複数のエンジニアが同じソフトウエア開発に参加するとなれば、当然のことながらマネジメントも必要となる。「Webもデータベースもユーザーの業務も何でも分かるという人はいないし、そもそも不可能です。一人ですべてはできません。だから指揮官がいてチームで分業して仕事をしないと無理です」と西野（エスシーシー）は、指揮官にはマネジメント能力が不可欠であると述べている。そして、「マネジメントは目標を立てて皆を導くというイメージがあります。メンバーに技術を身につけさせて目標を持たせ、彼らの満足度(ES)を上げること、これがマネジメントです」と語る。
同じように岩尾（構想計画研究所）も、次のようにマネジメントの重要性を指摘している。
「失敗した時にはプロジェクトのメンバーは自分の心を整理できなくなって、疲弊します。会社を辞める人も出てきます。そんなことは自分のところで起こしたくありません。そのためにはマネジメントが重要なのです」
より良いマネジメントをするためには部下の危険信号を読み取ることが必要である。田口ソリューションズ）は、次のように指摘している。
「ソフトをつくるのは人間です。一人ひとりに気を配ることが大事なので、部下との会話の中で、部下が危険信号を出していないかに注意します。病気休みの人間が出たらロスが大きいので、部下の顔色などにも気を配り、心配なことがあったら早めに休養を取らせたり、病院に行かせたりします」
保科（日本ユニシス）は「部下が駒に見えたら、もううまくいきません」と断言して、ただプロジェクトの進捗だけを考える管理者に陥ってしまうことを戒めている。
- コミュニケーションは必要不可欠なツールである ！
梅田(NTTデータ）はシステムの構築には多くの人が関わるために、その間のコミュニケーションも大切であるという。さらに中井（伊藤忠テクノサイエンス）も、プロジェクトチーム内におけるコミュニケーションの必要性について、次のように述べている。
「メンバーは能力や経験に秀でた人たちが集まっています。しかし、思考スタイルや仕事のやり方は皆違います。いくら開発のスケジュールやルールをつくり、守らせても思考がバラバラではうまくいきません。お互いの立場を理解し尊重して一緒にやっていかないとダメになります。一分一秒を争う仕事ではなおさらです」
コミュニケーションが必要なのは、通常の業務の時ばかりではない。プロジェクトが危機に瀕した時には、さらに重要性が増すのである。たとえば鵜川（野村総合研究所）によればプロジェクトが本当に苦境に陥った時に必要なことは、その場の雰囲気を変えることだ。酒でも飲みながら、リーダー、サブリーダーたちとフラットな関係でワイワイ議論していると、苦境に陥ったシステム開発から脱出する方法として思いもかけない知恵が浮かぶという。つまりフラットな場でのコミュニケーションが苦境脱出の鍵にもなるのである。
また同時に小又（元NEC ソフト）は「目に見える管理」として業務の現状を掲示して上司や部下の別なく全員の目に入るようにすること、さらには協力会社など外部の人間とも情報共有できるような仕掛けを考案することが、コミュニケーションをスムーズにする手法の―つであると述べている。
- 失敗はノウハウ蓄積の母である ！
小川（日立ソフトウェアエンジニアリング）は「誰でも失敗はするものです。しかし同じ失敗は二度と繰り返さないことが重要です。そしてお客様の信用を保つために一生懸命に努力することが必要です」という。また山本（ソラン）も失敗やトラブルの経験、そしてそれらを解決したときのノウハウを大事にしている。次に同じ場面に遭遇しても二の轍を踏まずに問題なく乗り切れるからだ。西野（エスシーシー）も「失敗を恐れずに挑戦し、結果として失敗したらその原因を分析してフィードバックすればいいのです」という。
岩本（アルゴ21)は大きな失敗を経験したが、そこから多くのノウハウを引き出し、対応策の構築に成功している。
失敗したプロジェクトの当事者だった岩本だが得たものも多い。しかもそれは全社的なノウハウとして残すこともできた。岩本は会社から「事情聴取」された。なぜこのプロジェクトが失敗したのかを記録に残し、再び過ちを起こさないためのノウハウを蓄積するためだ。岩本はこの場で次のように主張した。
「新規のプロジェクトでは、プロジェクトメンバーの半分以上が同じ釜の飯を食ってお互いの技量や性格が分かっている関係でなければプロジェクトは成功しません。社内のメンバーが会議で集まって名刺交換しているようではダメです」
現在アルゴ21では社員に関するスキル・インベントリーを充実させている。どんな言語、どんな技術に精通しているか、過去にどんなプロジェクトを誰とやっているかなどのデータがプロジェクト編成の基礎情報となっている。
さらにソフトウエア開発において何らかのトラブルが起こるのは当然なのだから「マネジャーに必要なのは、問題の早期発見と早期解決能力を身につけること。マネジャーは心配性になることです」と榎森（日本電子計算）は強調する。
- ソフトウエア・エンジニアリングを身につける ！
何らかのソフトウエア・エンジニアリングを身につけることも求められている。三好(SRA)はソフトウエア開発の品質を定めたCMMのリードアセッサーである。三好は若い頃から品質管理や開発工程に興味を持っていた。岩尾（構造計画研究所）は日本におけるソフトウエアの定量的な見積もり手法であるファンクションポイント法の普及に力を入れている。
しかしIT業界、ソフトウエア業界において、ソフトウエア・エンジニアリングが不在のまま開発が進められている現状に苛立ちを表明する声は多い。岩尾も試作段階がないこと、何が最適なのかが十分に議論されず、ユーザーの真のニーズが不明のままに、ソフトウエア開発が行われている現状への不満を吐露している。
「ソフトウエア開発には試作段階がありません、試作段階がなくては、本来はエ数の見積もりもできません。また、開発に使用される技術が最適で、実際に目標を達成できるのか、何が最適な技術の組み合わせなのかが分からないままにソフトウエア開発が行われています。ユーザーのニーズといいますが、ユーザーの真のニーズはどこにあるのか、そのニーズは誰が出しているのかを見分ける必要があります。しかし、それも十分に行われていません。結局そうした無謀なプロジェクトが、業界では現実に動いているのです。それでは基本的に成功するわけがありません」
この問題はソフトウエアの品質にも関わるものである。小林(TDC ソフトウェアエンジアリング）は郵貯システムという大規模システムの開発に参加することでソフトウエアの品質がいかに重要であるかを再認識している。ソフトウエア開発にトラブルが起こった時に駆けつける「火消し役」の南（新日鉄ソリューションズ）も、火消しという業務の中から、それまで好きではなかったプロジェクト菅理やソフトウエア・エンジニアリングの重要性を知った。
つまり品質は何らかのソフトウエア・エンジニアリングを用いて、ソフトウエア開発工程でつくり込んでいくことが必要なのである。たとえば梅田(NTT データ）は、次のように述べている。
「ソフトウエア開発では、その工程をしつかり管理して、その中で確実に品質をつくり込んでいくことが必要です。開発標準を決めて、その通りにソフトウエア開発をやらないといけない。そしてアラームをいかに早く発見するかに、管理者は気を配らなくてはなりません。順風満帆にいっていると思えるソフトウエア開発ほど危ないものはないのです」
品質を含めて職人芸的ではないソフトウエア開発を行うためには何らかのソフトウエア・エンジニアリングを身につけることが必要なのである。
● 好奇心を持つ ！
それではソフトウエア技術者、その管理者に必要な個人的な特性とは何かを見てみると、猪澤(DTS)は、絶対諦めず乗り越えていく、中途半端に終わらない姿勢ということを挙げている。田口(CRC ソリューションズ）も同様の指摘をしている。
しかし、それより多く共通して指摘されたのは「好奇心」であった。山本（ソラン）は、好奇心を忘れたら技術者ではないと断言し、越沼(TKC)も、同様に指摘している。
「今はプログラミングをやっていても、それにとどまって受け身でいてはダメです。次のシステム設計の段階へ能動的にならなくてはいけません。プログラミングをやっていても、常に好奇心を持ち、その一段上を見て仕事をしなければなりません」
「飽きっぽい性格」だが「変化が楽しいのでこの業界にいます」という吉場(NTT ソフトウェア）だが、彼のいう「飽きっぽい性格」とは「好奇心」の別の表現に他ならない。また丸山（アイネス）の「洞察力を持つということは考える力を持つということです。オ能も必要ですが、訓練で伸びていきます。考える力はいつも興味を持つこと、疑問を持つことから始まります。そこから真理が得られるのです」という発言も、結局は「好奇心」に帰着する。
- プロフェッショナルとしての意識を持つ ！
日本のソフトウエア技術者やその管理者たちは果たしてプロフェッショナルとしての意識を持っているのかどうか疑問だと指摘する声もある。たとえば印南（住商情報システム）は「エンジニアとしてのスピリットがありません。だから目標も低く甘い。何となく設計しておいて本番までには何とかするという構図、体質です。ミたから後になるほどプロジェクトが火を吹くのです」と指摘する。
また三好(SRA)は「エンジニアは自分で技術を鍛えるものです。他人や会社を頼りにしてはダメです」と述べ、また猪澤(DTS)も「自分に投資せよ」、「教育は外から受けるものではない」と考えている。
そして奥住（ヤマトシステム開発）が、画家が絵に自分のサインを書き込むように品質に対する誇りを設計書やアプリケーションに埋め込んでほしいと願っているのも、まさにSE、ソフトウエア技術者にプロフェッショナルのとしての意識を持ってほしいということに他ならない。
携帯端末等を開発してモバイル・コンピューティングの世界という新しいライフスタイルを提案する入鹿山(NTTドコモ）は、その意味で徹底したプロフェッショナルとしての意識を持っている。入鹿山は「技術者という意識はありません。クリエーター、新しいもの、新しい市場をつくるのが生き甲斐なのです」と述べる。
いずれにしても日本のソフトウエア技術者やその管理者は、より徹底した「プロフェッショナル」としての意識を持つ必要がある。
以上のように26人のインタビューから「現場を重視、しかし顧客のいうとおりにつくるな！」、「真のリーダーはシンプルで、明確な目標を示す！」、「マネジメントはメンバーに優し＜！」、「コミュニケーションは必要不可欠なツールである！」、「失敗はノウハウ蓄積の母である！」、「ソフトウエア・エンジニアリングを身につける！」、「好奇心を持つ！」、「プロフェッショナルとしての意識を持つ！」の八つのコンピテンシーを抽出した。
ただしこれは―つの例にすぎない。本書からはこれ以外にもたくさんのことが引き出せるはずであり、それほど本書は豊かな内容を持っている。
また、ここで紹介した八つのコンピテンシーの言葉の本来の重みや面白さは各インタビューの中でこそ味わえるものである。可能であるならもう一度、各章に戻って、それを味わってほしい。
これが現役のソフトウエア技術者やその管理者たちにとって少しでも役立ち、そしてこれからそれを目指す若い人に、その仕事の面白さと厳しさが少しでも伝えられたなら、著者たちにとっては望外の幸せである。
(takashi umezawa)
注 所属、役職は取材時のものである。