伝送システム開発から学んだことの最近のブログ記事

プロジェクトの成功は人の和の力に感謝

プロジェクトが成功するためには、プロジェクトに関わるすべての人が各々の持ち場で力をあわせて仕事をしなければなりません。プロジェクトの成功はプロジェクトリーダーの力だけでは成しえないもので、プロジェクトメンバーの力を結集する人の和があって初めてできるものです。リーダーはメンバーに、メンバーはリーダーに感謝する心を持つことが大事です。

仕事を与えられた環境に感謝

会社に帰属して仕事をやる以上、会社から与えられた環境の中でしか仕事は出来ません。ここで言う環境とは、仕事そのものを与えられる、即ちあるプロジェクトに参画できることを言います。やりがいのあるプロジェクトに参画できるか否かは、フリーランスでない限り自分では選べません。　もうひとつ言うと、開発プロジェクトにおいてリーダーが最も力をいれなければならないことは、仕事の環境を整えメンバーが働きやすくすることです。ここでいう環境は、作業環境や設備そして人的リソースや必要な経費の確保などをいいます。これらを整えてくれたリーダーにも感謝の心を持ちましょう。

長く付き合える仲間に感謝

やりがいのある仕事を一緒にやった仲間は、その仕事が終わった後も長く付き合うことができます。仕事をやっているときは、なんでこんな大変な思いをしてまで仕事をやらなければならないのかと思ったとしても、その仕事が成功裏に終われば、「あの時は大変だったけど一緒に仕事をしてよかったですね！」と言い合える仲間になります。この長く付き合える仲間にも感謝しましょう。

技術が成熟しつつある時

実用化にはタイミングが肝心です。ここで言う実用化とは、研究の成果を世の中で使える具体的な物に仕上げることを言います。技術が成熟しつつある時とは、例えばLSIの規模や動作速度がシステムから要求される高度な仕様にぎりぎり合いそうになってきている時とか、光ファイバが安く大量製造できるようになってきている時を言います。要するに、開発しようとするシステムに採用可能な技術が出揃ってきた時のことです。それから、社会の要請といいますか、大義名分があるとき、それから、技術とか技術者、そういうものに勢いがあるとき。技術者のいる集団ということでいいと思います。そういうときに大きなシステムの開発が成功するのだと思います。

社会の要請（大義名分）がある時

大義名分というのは、新しいものに対する期待ということです。昔、新しい通信システムの開発をやるときに何を言われたかというと、古い通信システムは価格が高い、システムを設置する床面積が広く邪魔、扱いにくいと言われ、この三悪を解消せよという要請がありました。他でも述べますが、現状が悪いほど新システムの付加価値は高くなります。

技術（者）に勢いがある時

これは実用化だけではないですけれども、技術者とか、ある技術に勢いがあるときというのは、仕事をやっていて非常に楽しく充実しています。それは、経験して後から見てみると、いやあのときは大変だったけどおもしろかったということになって、そういうときの仲間というのは、あとずっと良いつき合いができます。

この技術とか技術者に勢いがあるということは非常に大事なことであります。実用化ですから、突然何かできるということはなかなかなくて、そこまできちんと技術をだれかが育ててくれていたからできるのです。

以上に述べた３点がそろったタイミングで「大きなシステムの開発が成功する」のだと思います。

ビジョン、目的を共有する

これは、開発プロジェクトにとっては基本中の基本ですが、組織の中央の開発リーダーのお膝元のメンバーには徹底できても、大きなプロジェクトで分散開発を行う地方組織のメンバーに同じ意識を持ってもらうためにはリーダーとして大きな努力が必要です。人間は面白いもので、所属する組織が権力の中枢から物理的距離が離れれば離れるほど所属する人間の緊張感が薄くなるものです。リーダーと、週に1回顔を合わせて打合せするメンバーと3ヶ月あるいは6ヶ月に1回しかリーダーと顔を合わせることのないメンバーでは、リーダーから伝わる情報の量が違います。もちろん、テレビ会議や電話会議をつかって日頃の打合せを行ないますが、Face to Faceに勝るものはありません。

仕事の分担のインタフェースを明確に

分散開発プロジェクトを成功に導くためには、各々の開発組織が分担する仕事間のインタフェースを明確にしておくことが大切です。大枠は問題なくても、細部になると、これは相手がやってくれるだろうと思っていた仕事が、相手方も同じく相手がやってくれるだろうと思っていることが起きます。インタフェース仕様は、なかなか全てを書ききるのは難しいのですが、疑義があったらお互いに確かめ合う習慣をつけることが大切です。

開発リーダーは分散開発拠点に直接出向く機会を沢山作る

これは、上に述べたビジョン・目的を共有するためには必須のことです。リーダーは分散開発拠点のプロジェクトメンバーに直接語りかけることが重要で、自分たちのプロジェクトの話だけではなく、地方にいると聞けない本社の生々しい話もすると興味を持って聞いてくれます。　私は、中央1箇所で地方の分散開発拠点が北海道、東北、関西、九州と4箇所の開発プロジェクトを管理した経験があります。これらの分散開発拠点4箇所を年に3回訪れることをメンバーに約束しこれを果たしましたが、結構な稼動でした。ただ、地方に行けば、食べ物もお酒もおいしいですし、メンバーと共にアフター５を楽しむこともできて、よい経験になりました。

リーダーは自信にあふれていること

開発プロジェクトを引っ張るリーダーの態度は、そのプロジェクトの成否に大きく関わります。リーダーが自信なさそうで、何を聞いてもはっきり答えてくれなかったらプロジェクトのメンバーの心は離れていって、そのプロジェクトは失敗に終わるでしょう。リーダーが自信を持ってプロジェクトを管理し、顧客対応も開発の専門家としてきちんとやれば、プロジェクトメンバーの仕事のやる気はいやでも高まるでしょう。

俺がやるんだから大丈夫！

数多くのプロジェクトを成功に導いてきたリーダーは、新しいプロジェクトに対しても「俺がやるんだから大丈夫！」ということをプロジェクトメンバーに宣言します。特に、混乱したプロジェクトの立て直しの場合には、プロジェクトの先行きに不安をもっていたメンバーたちに安心感を与え、仕事に前向きに取組もうという意欲を高めます。

クリティカルパスを予測し先手を取る

開発プロジェクトのリーダーの重要な仕事のひとつは、クリティカルパスを予測し先手を取ることです。プロジェクト全体が順調に進んでいるときは見えないクリティカルパスが、プロジェクトの一部に遅れがでると突然浮かび上がります。リーダーはこれを予測し、人的リソースの手当てなどの対策を先手、先手で打つことでプロジェクトを成功に導くのです。

何が起きても驚かない

開発プロジェクトでは、思いもよらない突発事象が生じることがあります。メンバーが右往左往しているときに、リーダーは泰然自若の態度で事にあたることが必要です。このような突発事象に対して、経験豊かなリーダーは技術的直感が働いて事象の原因の推測ができることが多くあります。原因の推測ができなくても。原因を突き止めるための切り分け方法はすぐにリーダーの頭には浮かび上がります。

自分を中心に世の中はまわらない

技術の先を読むためには世の中を広く見ることが必要になります。これは、技術動向だけを見ていれば良いのではなく、社会状況や経済状況の変化も含めて見る必要があります。自分が持っている技術で十分と思っていると、突然、外部条件が変わって自分が持っていた技術が陳腐化してしまうことも起きます。要するに、自分を中心に世の中はまわらないのです。

時流を読み、時流に乗る

繰り返しになりますが、世の中の流れを読むことは、今後どんなシステムを作ればよいか、それにはどんな技術が使えるかということを読むということです。日本の携帯電話は独自の高度化を遂げて、ガラパゴス状態だといわれてきましたが、ここにきて世界の動きが変わり始め、インターネットアクセスできる携帯電話が世界各地で普及し始めています。時流は変わるのです。ただ、日本の携帯電話機メーカーさんがこの世界の時流に乗れるかどうかは疑問が残ります。時流に乗れれば商売としてうまくいくことになります。

世の中で広く使われているものを使う

世の中で広く使われているものは、時流に乗っているものであり、大量に安く供給されます。そこに使われる技術は、技術として成熟したものでありやがてコモディティ化して誰でもが使えるものになります。システムに使う技術は、特殊なものよりは世の中で広く使われているもののほうが、作ってくれる企業もサポートしてくれる企業も多くてよいといえます。ただし、システムに何らかの付加価値をデザインなりブランドなりでつけないと埋没してしまいます。

成功体験が大切

良いシステム開発に従事して、それが成功体験に終わると人は育ちます。開発に従事しているときは、何でこんなに大変な仕事をしなければならないのかと思っていても、プロジェクトが成功裏に終わると、自分も今までとは少し違った人間になったような気になります。これは、気になるだけでなく、新しい仕事に取組んでみれば自分の成長が実感できると思います。

達成感が次の仕事の意欲を高める

成功体験は、達成感につながり、達成感は次の仕事の意欲を高めます。前の仕事であれだけのことが出来たのだからという自信が、次の仕事に活きてくるわけです。達成感は、やって良かったという満足感ともいえるもので、技術者として開発に携わった喜びにも通じます。

プラス思考が生む Positive Feedback

プラス思考が生むポジティブ・フィードバックをかけていく。これは、うまく言った経験を持つ人は、新しい仕事に対し、また成功させてやろうとポジティブに考えることができるということです。前のプロジェクトが失敗していると次のプロジェクトも失敗するのではないかとネガティブになることの反対です。私は、仕事はいやいややるのも前向きにやるのも、同じ時間をかけるのならば前向きに、ポジティブにするのが良いと思っています。

これからシステム開発技術者を目指す若い人に対して「人を知り、人を使え」というとちょっと不遜な態度をとれといっているように聞こえるかもしれませんが、個人が保有する知識は有限なので他人が持っている知識を活用する手段を身につけることをお勧めしたくてこのような表現をしました。

他人の知識や考え方を自分のものにするための最も簡単な手段は、恥ずかしがらずに質問することです。日本においては、職場全体の仕事の効率を上げる事を第一に考えていますから、若い人の質問に対してはほとんどの人が親切に答えてくれます。逆にいうと、質問をしないとすべて分かっているものとして扱われてしまいます。

質問をするときに、誰に聞くかという事も大事な事です｡始めは身近な人に質問をすることになりますが、直接尋ねた人が「そのことなら○○さんに聞いてごらん」というようにあることの専門家を教えてくれるようになります。この誰が何を知っているかというインデックスを自分で作る事が「人を知り、人を使え」ということの真髄になると思います｡先輩を含めたお友達作りが「人を知り、人を使え」ということなのです。

覚えたことが身になる

若さは力であるといっても、若い人にはぴんとこないかもしれません。中年になって記憶力がおぼつかなくなるとよく分かるようになります。若さのすばらしさは、覚えた事が身になることです。ですから若いうちに色々な事を勉強しておいて欲しいのです。

趣味的に覚えた知識は一生もの

特に、好きで趣味的に覚えた知識は一生のものになります。趣味でいえば、鉄道の機関車や電車の形式番号や自動車の車種名は、好きだといくらでも覚える事ができます。仕事の例でいえば、ＬＩＮＵＸのコマンドは年をとってからではすべてを覚える事はほとんど不可能ですが、若いときに覚えてしまえばその後ずーっと使えます。私達の世代で言うと、ハードウェアでＴＴＬのＩＣの型番とその機能やピンの配置は、毎日半田ごてを握ってディジタル回路を組んでいた人にとっては自然とあるいは否応無く頭に入ってしまい、設計図を書かなくてもある機能の回路を作り上げることができるようになります。「好きこそものの上手なれ」という言葉がありますが、ものを覚えるにはそのことが好きになることが一番です。これに若さが加われば「鬼に金棒」です。

語学は何とかなるところまでは必ずやる

もうひとつ、外国語については若いうちに「いざとなれば、なんとかなる」レベルまで勉強して身につけておいてください。技術開発を目指すのならぜひ英語を身につけてください。特に、リスニングについてはネイティブの先生について、色々な発音の英語があることを学び、とにかく聞き返してでも相手の言っていることを理解できるようになっておいてください。日本語の場合でも相手の言っている事を１００％理解しながら会話しているわけではなく、これは外国語でも同じだといえます。そう思うと少しは外国語の会話も楽になります。それでも相手の言っている事を理解できないようでは話が前へ進みません。この耳を慣らす事においても若さは力になります。

人としての魅力をつける

あなたが一人前の開発技術者をめざすのなら、まず人間としての魅力をつける努力をしてください。技術は一流でも人間としての魅力のない人では、部下もついていけませんし、お客様から見てもこの人に仕事を任せて大丈夫だろうかと疑問を持たれてしまいます。これは、なにも開発に限ったことではなく、世の中で通用するための条件です。人間としての魅力をつけるためには、技術の本だけでなく社会や経済の本を読み世の中の常識を身につけることが必要です｡

さらに、恋愛を経験することもよいことかもしれません。そうはいっても、たくさんの恋愛をするわけにもいきませんから小説を読んで擬似体験することも良いと思います。なぜ、こんなことをいうのかというと、人間としての魅力は相手の立場に立って物事を考える事ができることにより生まれてくるものだからです。べつに、相手に迎合しろと言っているわけではなく、相手の主張を十分に理解した上で自分の主張の言うべき点はきちんと言い、実りある議論をすることが大切です。

先輩・後輩を含め人のつながりを大切に

また、先輩や後輩をはじめとする人間関係を大切にして、幅広く色々な人と交際することが必要です。特に、この人はすばらしい人だという人と巡り合ったら、その人の考え方や行動をよくみて学ぶことが大切です。もちろん、人間ですからすべての面ですばらしい人はそうはいません。悪い面は反面教師として学べばよいのです。この人から学ぶ習慣をつける事は、将来人事で人を評価するときに大変役に立ちます。人は、こちらがその人とのつながりを大切にしたいと思って接すれば、相手にもその気持ちは伝わるものです。システム開発のプロといわれるような技術者と知り合ったら、その人の技術的判断の根拠を聞いてみてごらんなさい。なんでもないと思われる判断の裏に隠されていることがたくさんあるものです。

技術は一生勉強する

さらに、しつこく言いますが、技術は一生勉強してください。技術は日夜進歩しています。技術の勉強に関してこれでいいと言う事はないのです。若い時代には自分の専門を作るために特定の分野の技術を深く掘り下げるように勉強してください。仕事が忙しく勉強の時間がとれない場合でも、かばんの中に専門の本を入れて歩き、ホームのベンチでも電車の中でもちょっとの時間を大事にして本を読む習慣を忘れないことが大切です。

現場を知る

技術者として開発業務に携わるということは、日々勉強を続けるということです。最初に学ばなければいけないことは、「現場を知る」ことです。ハードであれソフトであれ開発対象のシステムが使われる現場が、どういう所でどんな人がどんな仕事のやり方をしているのかを知ることです。これがなぜ大切かというと、システムを発注する人は必ずしも現場のことを知っているとは限らないからです。企業では一般的にシステムを発注する部門とそのシステムを利用する部門との間には距離があり、発注する部門は「せっかく作のだから」と色々な機能をつけたがり、利用する部門では全体から見れば限られた基本的な機能だけを利用するものなのです。このため、開発技術者としては「現場を知る」ことが極めて重要なのです。

雑学の師になれ

そして「現場を知る」ことは「雑学の師になる」ことでもあるのです。開発しようとしているシステムに本当に必要な機能は何で、その次に必要な機能は何で、あっても無くても良いが経営者に見せると喜ぶ機能は何かを技術者として判断するためには、つまらないと思われるような些細なことまで知っていることが必要なのです。また、雑学を知ることは世の中の常識を知る事でもあり、自分の専門以外の技術に対する評価にも役立ちます。

情報収集能力を高める

これだけ知ることが多く必要となると「情報収集能力を高める」ことが重要になります。社内のどんな人がどんなことを知っているかを知る事やどんな本を読めばいいかを知る事から始まって、社外の専門家とのパイプを作る事、さらには海外の専門家とのパイプを作ることまで自分の専門に関連して必要な情報はしっかりと集められるように努めて下さい。

英語力が差をつける

今の日本の状況は、残念ながらまだ世界の技術の先端情報が日本語ですべて得られるわけではありませんし、技術に対する評価も日本と海外で違っていることもあります。情報収集能力を高めるためには、英語力が差をつけますので、若い技術者はぜひ英語の力をつけて下さい。もちろん英語は読み書き話せなければなりません。現在は、インターネットを使って色々な情報を取得する事が出来ますが、英語の力次第で得られる情報に差がでます。英語が読めないようではどうしようもありませんが、読めても大量の英語の文書を読みこなせるようにならないと良い情報を得ることは難しくなります。さらに、英語で質問が書けるようなると得られる情報の質は飛躍的に高まります。そしてあなたが自分でやったことを英語で世界に発信してください。国際学会で口頭発表できるだけの実力をつけるよう、若いうちから努めてください。

経験する（自分の目で確かめる）

技術を身につけるためには、その技術分野の知識を修得しなければなりません。そのためにはまず自分で経験することです。日々の仕事を通じて体で覚えることです。何か前近代的に聞こえるかもしれませんが、耳学問だけでは技術は身につきません。経験することには限りがあります。その時代なり環境なりの制約があり、ある技術の一断面を垣間見る事しかできません。もちろん先輩が築き上げてきた技術発展の成果の上に、あなたは立っているのですから、昔の人から見れば最初からはるかに高度な技術に接しているわけです。それでは、経験以外の手段はなにがあるのでしょう。

本を読む

技術を身につけるためには、本を読む事が必須です。特に、あなたが学ぼうとしている技術分野を体系的に取り上げた本を読む事です。本には、先人の苦労と知恵がたくさん含まれています。自分の専門とする技術分野の本を読んだら、今度はその周辺技術の本を読んでください。そして、これはと思う本があったらぜひ自分のお金で買って下さい。これは、自分への投資ですから。もし、あなたが専門とする技術分野の本がほとんどないとしたら、あなたは大変幸せな事に新技術の開拓をやっていることになります。将来、あなたが本を書かなければいけなくなるのかもしれません。本当に本が見当たらなかったらどうすればいいのでしょう。

先輩の話を聞く（先輩の失敗を繰り返さない）

技術を身につけるためには、先輩の話をきくことです。技術者は、どんなに難しい顔をしていても技術について質問すれば親切に答えてくれるものです。人間の営みは、同じ事の繰り返しが常で、知らないと先人の失敗を再度経験しないとその先に進めません。そうならないためには、先輩から話を聞くことです。あなたが新人の時には、先輩に何を聞いてもかまいませんが、少し経験をつんだらその技術分野の本を読んで知識を増やし、質問にもちゃんと勉強している事が分かるようにしてください。さもないと、先輩から「こいつはちっとも学ぶ気がない。いくら教えても無駄だ。」と思われて相手にされなくなってしまいますから。

技術者としての専門家を作るには、最低５年、普通は１０年

焦らずに自分の専門を確立する

これからシステム開発を目指そうとしている若き技術者の方々にお願いです。システム開発を行うためには、自分自身、自信が持てる技術をひとつは身につけていただきたい。会社に入って最初に与えられる仕事は面白くないかもしれません。私はこんなことをやるためにこの会社を選んだのではないと不満を持つことが多いと思います。それでも最低３年は最初に与えられた技術を徹底的に学んで下さい。一人の人間がある技術で一人前になるためには最低で５年、普通は１０年かかります。もちろん、一つの技術を５年学んでそのあとその技術の周辺分野を学んだのでもかまいません。とにかく焦らずに自分の専門技術を確立することが大切です。

一つの技術の専門家になると、技術をみるセンスが身につきます。そうすると自分の専門でない技術についても技術者としての勘が働くようになります。私は、伝送系のハードウェアの研究開発を１８年やったあと、伝送系のソフトウェアの研究開発を７年ほどやりました。その後は、知財や標準化の仕事をやりましたが、あくまでもベースとなる技術は伝送技術でした。ハードウェアの開発プロジェクトを管理した経験が不思議なことにソフトウェアの開発プロジェクトでも生きて、トラブルが発生したときに技術的におかしい事をきちんと指摘できました。私自身の思いとしてハードでもソフトでも技術の根っ子は同じだと感心したものです。

仕事の線表は自分で決める

要するに自分が使われているのではない、自分が仕事をコントロールしているのだ、そういうことを私はコントロール感のある仕事の進め方といいます。ですから、仕事の線表は自分で決めます。といっても全体スケジュールに穴をあけるようなことは出来ませんので、全体最適の中での個別最適を行うということです。それでも、全てを決められたもの、与えられたものとして受け身で仕事をするよりは、積極的に仕事に励めます。

先を見通す力をつける

今の自分の仕事の3ヶ月先は大体見当がつくと思いますが、1年先をどう捉えるか。これは、今の時代ではけっこう厳しいものがあると思います。その中で、自分の仕事領域の外部条件の変化や技術の流れを読んで、先を見通す力をつけると、仕事に使われているのではなく仕事を自分でコントロールしている感覚になると思います。

今の立場より一つか二つ上の立場で判断する力を付ける

今現在、自分が置かれている立場より一つか二つ上の立場で判断する力をつける。これは、自分が係長なら、課長はこのことについてどう判断するかな、部長ならどう判断するかなということを予測した上で、自分の判断をすることを心がけるということです。課長や部長のキャラクターによっては、ものごとに対する判断がまるで逆になることもありえますので、自分がやりたいことを通すための作戦をよく考えて下さい。大体において二つ上の立場の人の判断が予測できるようになると、非常に楽です。 以上の三つのことが出来るようになると、自分の仕事を自分でコントロールできます。

動機付けを明確にする（情報の共有）

人の力を引き出すマネジメントを行う上で一番重要なことは、「何のためにこのシステムを作るのか？」あるいは「このプロジェクトの目的は何か？」といった動機づけを明確にすることです。これは情報の共有ということで、プロジェクトマネージャーだけが情報をにぎって、プロジェクトのメンバーには何も知らせないということでは部下は働く気になりません。

プロジェクトマネージャーが、プロジェクトの目的、現在の状況、今後起こりうるリスク等をきちんとメンバーに説明しないと、下から悪い情報は早く挙がって来ません。

コントロール感のある仕事をやらせる

部下にコントロール感のある仕事をやらせるということは、プロジェクト全体の進行は決められたスケジュールで行うわけですが、個々のメンバーが担当する仕事の進め方は、あたかもその個人が自分で決めて進めていくような感覚にすることです。これについては別の項目で述べたいと思います。

段階的に達成感を味あわせる

プロジェクトマネージャーは部下のメンバーに、段階的に達成感を味あわせることがメンバーの力を引出すことになります。大規模ソフトウェアの開発などでは２年ぐらいの長丁場になります。そうすると、３カ月ぐらいごとに、ああここまで出来たね、やったね、そういう達成感を味あわせることが必要になります。遠い目標に向かってひたすら馬車馬のごとく走れというだけではなかなかうまいマネジメントはできないので、この段階的にというマイルストーンをつくって、そこに達したならばよかったねという、そういう形です。

見えない物には意見は言えない

開発技術は、現場は急には変わらないことを認識しておいて欲しいと思います。技術者がいろいろな新しいものを考えて、その新しいものを現場に導入しても、使う側の立場の人間というのはそう簡単には変わりません。「こう言う新しいシステムを作ろうとしていて、今なら現場の皆さんの意見を反映できますが、何か意見はありませんか？」と、その新しいシステムが将来導入される現場の人々に問いかけても、出てくる意見は、今あるシステムのあそこが悪いから直して欲しい、次のシステムではこういうことが起きないようにして欲しいという既存のシステムへの意見だけです。新しいシステムはどうですかと言われても、そんなもの見たこともないから意見は言えないということです。

これは、一般的にシステムの運用をしている人からみれば、そもそもそのシステムがどういう思想でつくられているかなんていうことは関係なく、これちゃんと面倒見ろよと言われて、こうやれば動くのか、このボタンを押せば壊れたときもリセットがかかるのか、そういうことだけしかわからないわけです。

開発者の思いもしない使い方をする

そうすると、現場の皆さんは開発者の思いもしない使い方をします。これはハードもそうですし、ソフトもそうです。これは非常におもしろくて、ソフトの場合に設計する人と試験する人とを分けてやると、設計する人は自分の頭で考えてテストのデータを作る。そうすると、そのときは自分が設計したのだから、自分で試験データを作る分にはちゃんと通る。ところが、作った人と全然違う人が試験をやると、とんでもないデータを入れる。そうすると、突然バグが出る。何で出たの、いやパラメータチェックが甘かったのだ、「まさかそんな値を入れるとは思わなかったと。」そういう言い方なのです。

これはハードウェアでもそういうことは当然ありますし、ソフトウェアでも起きてくるということで、そのときに開発する側としては弁解をしてはいけなくて、確かに我々の設計に漏れていたところがありましたということになります。

システムを使いこなせるようになると次の要求がでる

それから、急には変わらないのですが、システムを使いこなせるようになると次はこうして欲しいという話が出てきます。ですから、顧客の潜在ニーズというものをいかに早くつかんで、今のシステムに対して次の要求は、当然こういうものが出てくるであろうということが予測できるようになると大分違ってきます。

システム開発の専門家として

• 顧客の潜在ニーズを掴み
• 技術と業務の両面で顧客を説得し
• 自分のペースで仕事をする

ことが出来れば理想である。 システム開発に関わっている皆さんにぜひとも持っていただきたいもの、専門家としての自負を持っていただきたいと思います。これはシステム開発の専門家としてお客様の潜在ニーズをつかんで、最近はソフトウェア開発ということで業務まで入っていますが、技術と業務の両面で顧客を説得し、自分のペースで仕事をすることができれば理想であるということです。別項で述べたように、お客様は自分が本当に欲しいものを知っておられません。それから、よいものを作るためにはどこで妥協すれば良いかもお分かりになりません。お客様を説得する、教育するというと余りよい言い方ではないかもしれませんが、必要なことだと思います。

自分のペース、要するに開発線表では、無理のない線表というのはまず引けませんが、とにかくこちらのペースで仕事ができるように、専門家としての自負を持って、できない、やってはいけないことは、もうできませんとはっきり言い、それからお客様にはここから先は私たち専門家にどうぞお任せくださいと、任せ切ってもらうことをする。そういう意味での自負をぜひとも持っていただきたいということです。

初期システムは、開発完了が出発点

この話は、どちらかというとハードよりはソフトウェアの方のシステムです。システム開発は最後の仕上げが肝心ということです。初期システムと言っていますけれども、バージョン１と呼ばれるものは、開発完了が出発点です。どういうことかというと、お客様の要望に応じてシステムというものを作るわけです。大体お客様の要望は非常に多くのものがあって、当然のごとく色々な要求があります。それらを全部実現していたら所要時期にはシステムはできないということになります。初期システムというのは大体６０点から８０点ぐらいでご容赦くださいということで作るわけです。ということは、初期システムが開発完了しました、で終わりではなく、そこから今度はお客様と一緒にシステムを育てることになります。

導入支援はおまけではない

普通のシステムでは、システムの要となるデータベースが必要です。初期システムのものだけ作って、データベースのデータ投入はお客さんの仕事だといって知らん顔する。悪い例だと、そこでデータが入り切れなくてシステムは導入したのだけれども、結局使われないまま置いておかれる。そういうシステムは世の中にはかなりあります。

あらかじめこういうデータの精度を高めておかないとシステムはうまく動きませんということで、お客様の運用部門との間でデータの精度をどうやって向上させるか、そのためのツールはどうするかといった事前準備をきちんとやっておいて、そのうえでシステムを入れるのです。このように開発した側が導入支援をきちんとやる必要があります。

顧客と共にシステムを育てる

初期システムが導入されても、まだ生まれたばかりで、初期システムに盛り込めなかった機能の追加や運用を開始した後でのフィードバック開発などシステムの完成度を高めることは、開発側がお客様と一緒にシステムを育てるという心でやらないとなかなかうまくいきません。

いつどのような機能を追加するのかといった段取りを考えておかないといけません。これは社会インフラに関わるシステムでは特に重要で、そのシステムが使われなくなるまでずっと保守をやっていくことになりますから、顧客との良い関係を保ち愛情をもってシステムを育てて欲しいと思います。

現状が悪いほど新しいシステムの付加価値は大

現場は開発の宝の山と書いたのですが、現状のシステムがいろいろ悪いと言われる、ということは、現状が悪いほど新しいシステムの付加価値は大きくなります。これは経営などでも言われることですが、今の状態が悪ければそれ以上悪くならないのだから、その悪いものを順番につぶしていけばよくなるのではないかと。

多分悪いというその程度の問題というのはいろいろな面で、例えばもともとは非常にたくさん人がいることを前提につくったシステムなのに、企業の合理化で人だけ減ったとなると、初めはよかったシステムが悪くなってしまうわけです。ですから、そこら辺の悪さかげんというのはどういうものなのか、それに対してどういうふうに新しいもので付加価値をつけていけばいいのかということを考えることが必要です。

システムの世代交代を考える

システムの世代交代を考える。これはコンピュータで言えばメインフレームからクライアントサーバ最近はクラウドコンピューティングということで、技術の進歩に伴いシステムの形態も変わってきます。未だにメインフレームが一部生き残っている分野もありますが、コンピュータのハードウェアとソフトウェアの進化に合わせてシステムの世代交代を考える必要があります。もっとも、ソフトウェアベンダーの商売に乗せられてころころシステム変更をすることは避けなければなりません。

過去との継続性は程々に

少し古い話で恐縮ですが、コンピュータがメインフレームからクライアントサーバに世代交代するときに、メインフレーム上で動いていたアプリケーションソフトをそのまま新しいサーバに載せ代えたいという話がありました。ここでの問題は、古いシステムのアプリケーションソフトは、コンピュータのプロセッサの速度が遅くメモリの容量にも制限があるので、顧客の要求を押さえつけて作ったものなので、顧客側から見れば新しいシステムにするのならあれもこれも出来るようにして欲しいということになります。

開発側のお金や時間の都合で、古いシステムのソフトを新しいシステムに移植したとしても、顧客からは次々に追加開発の要求が来て、結局、新しいシステムの上で新しいソフトを新規開発したほうが安くて使い勝手もよかったということになりかねません。そういう意味で、過去との継続性はほどほどにということを言っているわけです。ようは要求条件が違ってきているということを考えると、余り過去のものに引っ張られることはよくないだろうと思います。

ゼロベースの開発では最重要

システムですからコンセプトといいますか、ものの考え方が大事です。考えているだけではだめなのですけれども、システムコンセプトを作って、その上で全体を組み立てていくことが必要です。特にゼロベースの開発では非常に重要なことです。このコンセプトが間違ってしまうとなかなかよいものはできません。

わかりやすさ、考え方が見えるものを作る

コンセプトは、わかりやすさとか考え方が見えるものを作る必要があります。それと、決めたら全体を統一することが必要です。これは新しい通信システムを作るときに、装置を安くしようということだけでなく、その装置が使われる環境や運用方法まで含めてコンセプトを作ることが大切です。その原則は、構成のシンプル化と運用の簡易化の二つが大もとの考え方です。この考え方自体は、別に大したことというわけではありません。

決めたら全体を統一する

このベースの上に立って、新しい通信システムにやったことは何かというと、それまでは通信機械室に人が入って保守をしていた。通信機械室に人は入らなくても保守できるようにしましょう。それまでの装置は自然空冷でなければいけない。それにしばられたら装置全体が大きくなってしまうから強制空冷も使いましょうということです。そういう意味では、基本的な考え方に沿って先々の状況の変化というものを読んで、かなり大胆に前提条件を変えていく。そのときに、寄って立つ考え方はといったら、このコンセプトというところに端を発して、それからきちんとつながっているというのがわかりやすく見えていないとだめです。

時代、技術により分担は変わる

ハードとソフトの機能分担は、なかなか難しいもので、時代、技術により分担は変わりますが、今現在は相体的にソフトへ振り過ぎていると思います。

ハードとソフトの機能分担の例として、よくパソコンをとりあげるのですが、パソコンはハードの性能向上がすばらしいのに、それに伴ってパソコン用のＯＳ（オペレーティングシステム）が肥大して、結局、使う側からみるとログスケールぐらいでしか使いやすさは良くなっていない。どうもパソコンのハードとソフトの機能分担というのは余りうまくないと思います。

ハードのバグはとれるが、ソフトのバグはとりきれない

機能分担に関連する問題の一つは、ハードのバグはとれるけれども、ソフトのバグはとり切れないことです。この辺に私自身の経験からいっても非常に悔しい部分があるわけです。ＬＳＩとソフトという技術はほぼ同じような時期に非常に成長しました。ＬＳＩ側はＣＡＤが非常に発達して自動設計ができて、ＣＡＤ上でシミュレーションができます。そうすると、そこでほとんど回路設計上のバグというのはとれますし、最近はＬＳＩの中にセルフチェックするようなテスト回路を入れることもできます。 これに対してソフトの方は、はっきり言ってこの２０年、特に大規模システムソフトのつくりというものは、言語とかＯＳとかというものは変わってきていますけれども、基本的には変わっていません。

オブジェクト指向が救世主になったかというと、やはり大規模システムにおいてはなっていません。結局、それはもう人がひたすら設計をやって、こつこつ作って試験をやっています。ソフトの場合でも、設計ツールをそろえて、少しでも安くていいものを早く作ろうという努力をしているのですが、なぜか今度はツールに頼って人間が余り考えなくなってしまう。そうすると、根本的な部分まで戻って設計を直そうと思うと、人間の思考回路の中できちっとそういうものがフォローし切れなくなる。そういうこともあって、やはりソフトのバグというのは常に残ります。それも試験期間といいますか、試験中に全部取りきるわけにもいかないし、本当にバグなしになるまで試験をしていると、いつまでたってもサービスに供することができません。

使い方の決まるものはハードへ

ハードとソフトの機能分担を考えるときに以上のようなことを考えれば、とにかく使い方の決まるものはハードへということになります。私が経験した通信システムの開発の例で言うと、新世代の最初のシステムであったので、使い方がわからないからといっていろいろな機能をソフトに振ってしまいました。システムが現場に導入されて使いこなせるようになった時点で改良するとすれば、かなりの部分はハードに落とせると思います。

自らの退路を断つ

システム開発プロジェクトは、限られたお金や人のリソースと限られた時間の中で進めるものですから、開発リーダーとしてのマネージャーの態度に緩みがあってはいけません。自らの退路を断ち、絶対にやり抜くという強い信念と自信にあふれた態度でプロジェクトを引っ張って下さい。開発リーダーが自分に逃げ道を作ってしまうと、開発リーダーの交代というプロジェクト崩壊の第一歩が始まります。

人の和を作る

ハードであれソフトであれシステム開発プロジェクトは人間が行うものですから、そこに参画する人たちの心がひとつになっていないとうまくいきません。成果主義ということで個人個人の目標を立て、その達成度で成績をつけることが一時期もてはやされました。この成果主義は、非常に能力が高く一人でソフトウェアを開発できるような技術者には適用出来るかもしれませんが、日本人はグループで成果を出すことが得意なので日本には定着していません。プロジェクトのメンバーの人の和を作ることは、開発リーダーの役目です。

謝ることはリーダーの役目と自覚する

開発リーダーはプロジェクトを任された責任があるのですから、対外的な全ての折衝の責任があります。といっても、プロジェクトを推進する中で開発リーダーが褒められることは、あったとしてもうまく完成した時の1回だけで、あとは色々なトラブルに関して謝ることばかりです。プロジェクトのメンバーは、開発リーダーが責任を取って自らが顧客のところへ謝りに行く姿を見れば、この人にために頑張ろうという気持ちになります。反対に、開発リーダーが部下に謝りに行かせるようではそのプロジェクトはうまくいきません。

ある技術分野の専門家になる

マネージャーには、ある技術分野の専門家になって技術力で勝負ができるようになることが必要です。ひとつの技術分野で専門家になると不思議と技術的な勘が働くようになり、外の技術分野の事象に対しても正鵠を得た意見を言えるようになります。専門家になるにはひとつの技術分野で10年は仕事を続けないと難しいので、途中で仕事が変わっても、自分が専門とする分野の勉強を続けて下さい。不思議なもので、そういう努力をする人にはチャンスが回ってきます。

大局的判断力を養う

システム開発プロジェクトを推進する上で、マネージャーは色々と判断しなければならないことがでてきます。とかく自分のプロジェクトの事情がこうだからああしたい、こうしたいと自己中心に考えがちですが、顧客の立場から見たときの物の考え方を身に付けることが大切です。大局的判断力を養うには、人の話を謙虚に聞くことや偉大な経営者に関する本を読むことが有効です。それと周りの人の行動や判断をよく観察すると、「人の振りみて我が振り直せ」ではありませんが、反面教師は結構います。

部下に仕事を任せる腹を持つ

マネージャーにはマネージャーのやるべき仕事があるので、開発プロジェクトの仕事の実体は部下に任せなければ全体としてうまくいきません。ついつい自分が技術的に強い分野の仕事だと色々口をはさみたくなるものですが、部下を育てるためには部下に仕事を任せなければなりません。部下に仕事を任せても最終的な責任はマネージャーにあるのですから、いかに太っ腹になれるか、どれだけ部下から信用されるあるいは尊敬されるかが問われるのです。マネージャーとして、きちんと技術的判断ができるだけの技術力をつけることが第一歩だと思います。

専門家になるには１０年かかる

ひとつの技術分野の専門家になるには１０年はかかります。ひとつの技術分野で専門家になれば、もうひとつ分野を広げることは５年でできるようになります。ひとりの人が色々な分野の専門家になれるわけではないので、いろいろな分野の専門家とお友達になって情報を交換したり専門家の判断を仰いだりすることが大切です。

ギブ・アンド・テイクの出来る仲間を作る

専門家のお友達を作るには、自分も専門家として情報提供ができなければなりません。ただ情報だけをとっていくだけの人とは、専門家でなくても付き合いたくないものです。お互いに専門家として尊敬しあい、情報のギブ・アンド・テイクが出来る仲間をたくさん作ることが大切です。

良き仲間とは誠実に付き合う

技術者も人間ですから、人間関係を大切にして良き仲間とは誠実に付き合うことが大切です。特に、技術の研究開発においてはその技術に勢いがあったときに一緒に仕事をした仲間とは長い付き合いができます。私の経験では、昭和40年代後半のこれからは画像の時代だといわれていたときにいた研究室の仲間、昭和50年代後半の電話の加入者系のデジタル化の研究を一緒に進めていた仲間そして昭和の最後から平成にかけて新しい伝送システムを共に開発した仲間とは今でも良い付き合いをしています。

情報力の差がリーダーシップを左右する

システム開発を引っ張るマネージャーは、自分のプロジェクトに直接関わる情報のみならず、自分の会社の情報、顧客の情報そして社会一般の情報に詳しくなければいけません。プロジェクトが困難な局面にあるときには自分たち中心に考えがちですが、社会の一般常識からみたらどう見えるのか、顧客目線ではどうなのかという観点から判断を下すことがマネージャーには求められます。

上意下達に自分の解釈を加える

会社のような組織のなかでシステム開発プロジェクトを推進するときに、会社の経営方針や通達を、マネージャーはメンバーに伝えなければなりません。上意下達の情報は、余分なあるいは積極的に言いたくない情報は削られています。このときマネージャーは、自分が各種会議や同僚から得た情報をもとに、上意下達の情報に自分の解釈を加えてメンバーが変な誤解をしないように気をつける必要があります。

悪い情報は早く上げる

悪い情報は早く上げることは、プロジェクト遂行上すべてのレベルで必要なことです。やっています、大丈夫ですといい続けて、期限がきたらまともなものになっていなかった、最悪の場合は何も出来ていなかった！ということは現実に起こります。悪い情報が早く上がれば対処案も複数考えることができるので、マネージャーはメンバー全員にこのことを肝に銘ずるよう指導しなければなりません。

手抜きはばれる（まあいいかはダメ）

システムの規模が大きくなり、かつ短期間での開発を要求されるとソフトウェアであれ組み込みソフトであれ、既存ソフトからの流用あるいは改造を行わざるを得なくなります。先輩が作って現用の装置で動いているソフトモジュールだから大丈夫だろうと思って流用して見ると、思わぬバグがでることがあります。これは、ソフトの動く環境が変わったために潜在していたバグが現れたということで、例え機能が同じでも、新たなソフトモジュールの設計はきちんとやって、流用するソフトのソーストレースをやって大丈夫なことを確認してから流用してください。マネージャーの仕事は、メンバーが手抜きをしないように指導することです。

出来ないことは出来ない

出来ることと出来ないことを見極める必要があります。特にソフトウェアの開発においては、無限の稼動を投入すれば出来ないことは無さそうに思われますが、現実には時間も人も限られているのですから、顧客からの過大な要求を仕切るマネージャーが必要になります。

ハードウェア開発においても限られた時間の中で行うわけですから、最先端のＬＳＩ技術に期待をかけて極めて高性能な装置にするのか、最先端のひとつ手前の枯れた技術を採用して高性能で安定した装置にするのかマネージャーに判断が求められます。

システムの性能は要素技術の中で一番低いもので決まる

システムの主要部分については十分な検討を行い高性能なものにしたとしても、システム全体の性能はシステムを構成する要素技術の中で一番性能の低いもので決まります。ハードウェアでは、電源とアースまわりの設計には注意が必要です。装置の信頼性が電源まわりに使われていたコンデンサで決まってしまうことも起こります。システム全体に目配せをして要素技術のバランスをとることがマネージャーの仕事です。

ビジョンを示すこと

５年先に自分たちの仕事がどうなっているかを示す物がビジョンです。３年先までは事業計画で、近場は開発計画で仕事の将来像が見えますが、それだけでは開発メンバーのモチベーションを高めることは難しいと思います。５年先の姿を確定的に述べることは難しいことですが、社会の要請の変化と技術の流れを読んで、開発リーダーとしてのビジョンを示すことが大切です。

メンバーが仕事のやり易い環境を整えること

開発リーダーの重要な役割のひとつは、メンバーが仕事のやり易い環境を整えることです。ここで言う環境とは、物理的な職場環境のみならず人的リソースから予算を含めた広い意味の環境をいいます。言って見れば、開発メンバーに対する鞭と飴の飴に相当するものです。メンバーからみれば、このリーダーは自分たちを大切にしてくれている、そういうリーダーだからついていこうということになります。

顧客に謝ること

システム開発では、全てが順調にいってトラブル無く開発完了を迎えることは、まずありません。小さいトラブルが重なるようだと、そこには結構根の深い原因があります。それが顧客からの仕様変更によるものであることは多々ありえます。顧客側の担当者と開発メンバーの間では仕切りきれないような場合には、開発リーダーが顧客の責任者に話をする必要があります。この時、良いシステムを納期までに完成させるという顧客側と開発側の共通意識を醸成するために、開発リーダーは下手にでて謝りながら実をとることも大切です。　勿論、大きなバグをだして顧客に迷惑をかけるような場合には、開発リーダーが謝りにいくことは必須です。これを開発メンバーまかせにして、自分の責任を回避するようなリーダーには人はついていきません。

本流を見極める

システム開発において採用する技術は、そのシステムが社会インフラに関わる度合いが高い物ほど本流の技術である必要があります。本流の技術とは、過去の開発経緯を振り返れば分かるのですが、筋が良くてある程度枯れた技術をいいます。システムが長期に渡り安定して稼動するためには、開発時に技術の本流を見極めることが大切です。

先端技術がものになるまでには時間がかかる

システム開発時に、その時の先端技術が魅力的に見えても、その先端技術が本当に使いものになるまでにはいくつかのトラブルを経験することを覚悟しなければなりません。世の中で広く使われることにより、先端分野では見えていなかった技術上の問題点が見えてくるからです。

初物には注意（First Userにはなるな）

先端技術ではなくても、新製品ですと売り込まれる部品を安易に取り入れることは、自分たちがその新製品のデバグをすることを覚悟しなければなりません。"First Userにはなるな"というと、随分後ろ向きに思えるかもしれませんが、開発期間が短い場合には新製品の採用には注意しないと思わぬ開発遅延を招くことになります。

技術の世代交代を知る

技術の世代交代とは、アナログ技術からデジタル技術、メタリック技術から光ファイバー技術というような、技術の大きな変革をいいます。技術の変革期には必ず両世代の技術を組み合わせたハイブリッドシステムの提案がなされますが、世代交代が進むと消えていきます。新世代の技術の将来を見通して大胆に乗り換えていくことも必要です。

作業は必ずペアでやる

システムの移行作業やトラブル対策作業は必ず二人の人がペアで行って下さい。一人が実作業を行い、もう一人は手順書に従ってきちんと作業が進んでいるか冷静な目でチェックをしてください。作業中に異常が発生したときに、一人で作業していると頭の中が真っ白になってさらに余計なことをすることになります。二人ペアでやっていれば、異常が発生するまでの作業手順を振り返り、原因を冷静に分析することができます。

リハーサルを確実に実行する

システムの移行作業やトラブル対策作業は、検証設備でリハーサルを確実に実行して下さい。ちょっとした修正だから大丈夫だろうと思って、いきなり現用システムに入れることは、絶対に避けて下さい。実際問題としては、検証設備を現用システムと同じにすることはお金の面でほとんど無理で、検証設備ではOKだったのに現用システムではNGということもおきえます。それでも、手順書の検証を含めリハーサルを確実に実行して下さい。

リリースファイルで試験をする

大規模なシステムでは、試験が済んだブロックごとのソフトウェアファイルを最後にマージしてリリースファイルを作ります。このリリースファイルを作る作業は極めて慎重にやる必要があります。全部試験が済んだファイルのつもりが１ファイルだけ前のバージョンだったということは結構な確率で発生します。

試験用ファイルではOKだったのにリリースファイルではNGということがおきるのです。ですからリリースファイルができたら、そのリリースファイルで試験をしてください。

人についたノウハウを組織に残す

システム開発を行うと、それに参画した人々は色々な技術やノウハウを身に付けることができます。システムの仕様書には基本的なことしか書かれていなくても、システム設計書には詳細なフローチャートやパラメータが記載されます。システムを作ることは設計書があればできます。

問題は、システムが完成すると設計書と試験成績書は残りますが、システムアーキテクチャをどう決めたのか？パラメータの範囲はどう決めたのか？といった設計根拠が開発に携わった人々の頭の中にしか残らないことです。人についたノウハウを組織に残すため、忙しく時間がないのは分かりますが、設計根拠資料を残しましょう！

システムの無理な拡張を回避するため

設計根拠が分からないと、後からシステムに手を入れて拡張する際に、どこまでが現行システムの延長で可能で、どこから以上は新システムに移行すべきかということが分かりません。よくあることは、システム拡張をした結果、思わぬバグがでて、そのバグを修正しようとしたら次々に修正が入ることになり二進も三進もいかなくなることです。システムの無理な拡張を回避するためにも設計根拠資料を残しましょう！

システムの性能問題の限界を明確化するため

システムの性能は、最初に開発したシステムに大きく依存します。単位時間当たりのジョブの処理量は最初のシステム設計時にはもちろんマージンを持って設計します。システムが使われだすと、当然のことながら処理量は増加し、ある負荷以上になると動作が不安定になる、システムが挙動不審な動きをすることがおきる場合があります。性能問題はその限界が見えにくいものなので、システムの性能問題の限界を明確化するためにも設計根拠資料を残しましょう！

導入部門に強い意志がないと駄目

企業が経営体質を強化するために業務改革を行う場合に、いくらトップが方針を出しても、業務改革の現場がその気にならなければ成功はありえません。業務改革を指向するシステム開発においては、導入部門に「改革をやるんだ！」という強い意志がないと駄目です。今までと仕事のやり方が変わる、業務に関わる人の数が減るといった現場の不安を掻き立てる要素が多いわけですから、経営トップが強い意志で現場を説得、指導して、現場の人々に業務改革をやることを自らの問題としてとらえるところまでいかないと、システム開発を請け負う側は、トップの要求と現場の要求の板ばさみになりよいシステムは作れません。

シンプルなワークフローを考える

業務をいかにシンプルにするか、あるインプットからあるアウトプットを得るための最もシンプルなワークフローをまず考えます。そのワークフローに含まれるプロセスの数をいかに減らすか、ループになるプロセスはないか、本来のフローでは必須ではないがデータだけ参照したいといった要求はデータベース検索メニューとして別枠にするといったことを考えて、シンプルが一番を実践します。

システム導入の準備、運用の定着には時間がかかる

業務改革を指向するシステムを現場に導入するときには、その準備に時間がかかります。それまでは各拠点ごとに小さいシステムがあり、その小さいシステムにばらばらに入力していたデータを新しく導入する全社システムに移行させるには、個々のデータの不整合やダブリを取り除いてデータをきれいする必要があります。この作業をさぼると新システムは使い物にならないと言われることになります。

新システムを使った現場の運用が定着するのにも時間がかかります。最初からうまく動く新システムはめずらしいもので、通常は現場に入れて初めてでてくるバグもあります。これはテスト環境でのコンピュータの擬似負荷が軽かったため実環境で重い負荷がかかって出てくるバグの類です。これ以外にも現場要望で細かいところに手を入れなければならなくなることもあります。他でも述べますが、新システムは開発側と導入側が協同で育てていかなければ良い物にはなりません。

よい開発リーダを育てるためにはということです。次の世代を担うという意味では若手技術者に、よい開発リーダのもとでよいシステム開発を成功体験させることが必要です。最近見ていると、よいシステム開発、これがなかなか世の中に転がっていません。大変革がどうも余り起きない。インターネットのルータはアメリカの会社の製品が主流で日本勢は元気が無い。

そういう意味でそろそろ次の仕掛けということを考えなければいけないのですが、よい開発リーダを育てるためにということだけではなくて、日本が元気になるためにも何かよいシステムというものを考えなければいけないと思います。

良いシステムを作るためには...

• ユーザとの信頼関係を作り
• すべての風をフォローにして
• 発注側も受注側も納期を守る

...ことが大切である。

良いシステムを作るためには、ユーザとの信頼関係を作るということが大事です。それから、すべての風をフォローにすること。一番大事なことは、発注側も受注側も納期を守ることが大切です。この発注側が納期を守るということが非常に大切なことです。昔、新しい通信システムの開発をやったときに、私は発注側として設計要綱をいつまでに作るといったら、とにかく納期を守るようプロジェクトのメンバー全員に言いました。このことは私としては、セットメーカさんに納期を守っていただくために非常に大事なことだと思って、部下を指導しました。

２０年前のことですので、インターネットはまだなく、ワープロで作成した資料を設計要綱の納期当日の夜中の１１時過ぎからFAXでメーカさんへ送信を開始し、送り終わるのは翌日の明け方という、今でも関係者の間では語り草になっている出来事です。すべての風をフォローにするとは、発注側も受注側も各々の企業内のシステム開発に関する意思の統一がとれていることをいいます。発注側で、担当者と幹部の間でシステム開発に関する発言に濃淡があると、受注側のメーカの営業担当者が疑心暗鬼になります。受注側も幹部まで意思統一ができていないと、開発プロジェクトの経費や人員が膨らんだときに臨機応変の対応がとれず、開発遅延を起こすことになります。風がアゲインストにならないように環境を整えるのもプロジェクトマネージャの大切な仕事です。

情報システムなどの、発注側の納期はいつかというと仕様決定の期日です。受注側が、どういうことにするのかいついつまでに決めてくださいというお願いをしても、なかなか決めていただけないのです。受注側として、もう決められないのであれば専門家である我々に任せてくださいとなかなか言えないのです。これは相互の信頼関係を作ると言えるようになります。結局仕様が決まらないでずるずるずるずる延びていって、最終の納期だけはずれないというのでは、よいシステムはできません。そういう意味では、発注側の責任ということを世の中に向かって叫びたいと思っています。

良いシステムを開発する秘訣は何でしょうか？

発注者もルール（納期）を守る

良いシステムを作る秘訣の第一は、発注側もルール（納期）を守ることで、これができれば発注側と受注側との信頼関係が生まれます。信頼関係があれば、開発上のトラブルを発注側に隠す必要もなくなります。受注側が「やってます、大丈夫です」といい続けて納期直前になり「実は・・・」ということもなくなります。

少数精鋭の開発チームを組む

少数精鋭の開発チームを組むこと。これは贅沢だと言われるかもしれませんが、やはり頭というか、船頭が多いとなかなか良いシステムになりません。　その昔、私が新しい通信システムを開発したときは、コアメンバーは私を含めてハード側は４名で、あとは社内の現場から来た技術者と新入社員だけで、少数精鋭でやるしかなかったのです。他でも述べますが、良いシステム開発に従事することは若手技術者が育つことなので、少数精鋭の開発チームといえども次の世代を担う人をうまく入れておかないとまずいということです。

明確な目標の設定を行なう

明確な目標の設定を行うこと。これは当たり前の話です。当たり前ですが、いつまでに何を達成するのか、マイルストーンをどこに設定するのかといったプロジェクト管理で言われていることを実践することは結構大変です。　もうひとつ、明確な目標はプロジェクトメンバー全員で共有しなければなりません。メンバーの気持ちをひとつにすることで、個々の事案に対する判断のブレがなくなります。

• 使用者：仕事が楽になって良かった
• 発注者：あそこに頼んで良かった
• 受注者：大変だったがやって良かった

良いシステムというものはどんなものですかと聞かれたことに対する私の回答です。

システムの使用者すなわちオペレーターあるいはエンドユーザから見ると仕事が楽になって良かったと言われる。発注者の立場から言えば、あそこに頼んで良かったと。あそこというのは、要するにシステム開発をある企業に頼んで良かった。システム開発の受注者側は、大変だったけどやって良かったというふうに三者三様に言われるシステムであると思います。

なぜこんな言い方をするかというと、普通の情報システムというものは、大体使う人と発注する人は違います。大体部門が違っていて、これは大企業の中でシステム開発をする場合も大体そうで、開発組織とエンドユーザである現場とは違っています。結局一番難しいことは、発注する人、ここがいかにきちっとしたものの考え方を持っているかということが非常に大事です。

ですから、情報システムで言えば、発注者側の責任は非常に大きいわけです。発注者側というのは、できれば一つの開発ですべてうまくいくようにしたいと思っているわけで、当然いろいろな要求をしてきます。ときには、発注者の個人の趣味まで入るような要求が出てきます。そういう要求に対し、やはり受注者側にしてみれば、なかなか断るのも難しくていろいろなことを聞いてしまうことになります。そのときに、受注者側としては、発注側を指導するというと言い過ぎかもしれませんが、発注者をくすぐり倒して自分のペースに持っていくことが大切です。

そのときには、何かスタンダードがないとやりにくいわけで、そのスタンダードというのがＳＬＣＰと言われているＩＳＯ標準のソフトウェア・ライフサイクル・プロセスです。この標準は、ＪＩＳ化されており、さらに日本の産業界での利用を促進するため「共通フレーム2007　第２版」という本が出版されています。特に情報システムにおいては、システム開発で良いものを作るためには受注者側だけでなく発注者側にも責任があることをもう少し勉強して欲しいと思います。

【参考書籍】

共通フレーム2007―経営者、業務部門が参画するシステム開発および取引のために (SEC BOOKS)

共通フレーム2007―経営者、業務部門が参画するシステム開発および取引のために (SEC BOOKS)

これからは世界で売れるものを

日本の市場は、人口が1億余人ということもありほどほどの規模があり、携帯電話機を作っている通信機器メーカーさんは海外での商売を積極的にやろうとはしていません。今後を考えれば、やはり世界で売れるシステムを作っていくことに真剣に取り組まなければならないと思います。

隣国の韓国の通信機器メーカーさんは、韓国の人口が日本の半分なので韓国の国内市場だけでは食べていけないので積極的に世界展開しています。日本には、この必死さがないので、湯で蛙状態が続いて気がついたら国産の通信機器メーカーがなくなっていたと言う事態も想定されそうです。

日本カスタマイズよさようなら

北米で売れている通信機器を日本のキャリアさんに売り込もうとすると、日本の顧客は品質にうるさいので、北米仕様のままではだめで、あの機能を追加せよ、この機能を追加せよと日本向けにカスタマイズすることを要求されます。これらの要求に応えていると安価な機器にはなりません。

品質に対する感覚は、日本の国民性というか文化かというか、限りなく品質の良いものを追求する姿勢があると思います。もしかすると、日本国民の品質にこだわる姿勢が、日本の通信機器メーカーさんが海外に打って出られない遠因なのかもしれません。

標準インタフェースを採用する

標準には、ITUのような国際機関によって制定されたデジュール標準とWintelのように市場でメジャーになったことで皆が使うデファクト標準があります。いずれの標準を使うにしても、他のシステムとのインターオペラビリティ（相互運用性）を確保するためには標準インタフェースを採用することは必須になります。

何年使うか

最近、環境問題が非常に大きく扱われていますし、家電の製品では廃棄をどうするかということをきちんと考えながら作らなくてはいけなくなっています。ここで言うシステムとは、通信システムあるいは情報システムというものを対象として考えています。プランニングからディベロップメントをやって、オペレーション・アンド・メンテナンスと進み最後には廃棄されます。

大きなシステムになると、プランニングから企画開発が終わるまで２年、３年かかるわけで、そうすると、ものができてから何年使うのですか、その間そのシステムというものが世の中の動きについていけるのですか。その次には、やはりこのシステムは５年間は使える。その後、多少の余命をということであれば、２年か３年は使えるけれども、やはり８年後には次のシステムを出す必要がある。そういうことを考えていかないといけないということです。

世の中の動きについていけるか

インターネットの発展でビジネスの状況も通信の状況も大きく様変わりしています。お客様の問い合わせ先であるコールセンターは、昔は電話だけでしたが、今ではインターネットや携帯電話のメールも扱えるように進化しています。ビジネスや技術の状況変化に応じてシステムを発展させることができないと、そのシステムはあわれ２・３年で陳腐化してしまうこともあります。しかし、ビジネスのルールの根幹の部分はそう急激には変化する物ではありませんので、根幹部分をきちんと作ったシステムは結構長生きします。

次世代をいつ出すか

システムの将来展開を見せるロードマップというものがあります。とかく日本におけるシステムは、開発してからの寿命が２･３年で、すぐに次のシステム開発に取り掛かるというせっかちなものが多いと思います。これに対し、欧米の大企業では、あるシステムを導入するときの判断根拠として、そのシステムのロードマップを示せと言われることがあります。このロードマップは道路地図ではなくて、このシステムは、「導入後２年目にはこういうバージョンアップが出来ます。」、「４年後にはこういう機能追加が出来ます。」といったシステムの将来の見取り図に相当するものです。

つまり、導入するシステムは何年位使えて、次世代のシステムはいつごろ考えれば良いかが分かる訳です。システムのライフサイクルを考えるということは、こういうことで、今開発中のシステムを作りっ放しにしてはいけないということです。

人間はミスをする

技術開発を進める上での大事な前提といいますか、私がこれは非常に大事だと思っていることを書きます。人間はミスをします。技術は進歩します。仕事のやり方は変わります。当然当たり前のことです。そうすると、開発にある程度時間がかかるということを考えれば、明日のシステムを今日設計しているのですから、そこにはやはり技術者としての読みが必要になります。

特に、この人間はミスをするという部分は、システムは設計者の思いもよらぬ使われ方をするという部分にも関わってきます。ネットワークマネジメントシステムを設計しようとするときに何を考えるかというと、オペレーターミスで事故が起きましたという話が出てきたとしたら、私はオペレーターミスではなくて設計者が悪いと考えます。

当然オペレーターだって悪意を持ってやるわけではありません。大体故障の回復のときには関係する皆さんは焦っていますから普段ならやらないようなこともやってしまうことが起きます。ですから、ミスは、人間が平常心であれば起きないのでしょうけれども、故障が起きて舞い上がってしまうと、当然ミスが出てきます。そういうミスがあるということを前提にシステムは考えていかなければならないと思います。

技術は進歩する

技術の変化というのは、これは技術者としての読みの問題になります。ですから、作ったシステムが何年使われるかでその読みの深さがわかります。これは自慢話に聞こえてしまうのですが、私が２０年前に開発に関わった通信システムの設計のコンセプトは、今でも十分通用すると思っています。作ったときは５年ぐらい通用するかなと思ったのですけれども、システムコンセプトは今の世の中で見ても決して古くないと思っています。

仕事のやり方は変化する

仕事のやり方は変化する。むしろ変化させるためにシステムを導入すると言ったほうがよいかもしれません。人が介在する仕事のやり方から、コンピュータに任せるやり方に変化する。各拠点でやっていた仕事を一箇所で集中してやる。

こういった仕事のやり方の変化は、次々に起きてきます。これに対する技術者の読みは、究極の仕事のやり方をどう想像するかにかかり、技術以外の人間の行動に関する思索も必要になります。

以上に述べた３点を考えると、システム開発とは「明日のシステムを今日設計する」ということになります。

出来ることと出来ないことの見極め

特にソフトウェアの場合、出来ることと出来ないことの見極めは非常に難しい問題です。お客様は、ソフトなのだから、当然これもできるだろう、あれもできるだろう。一方受ける方は技術者ですから、できませんとは言いたくない訳です。そうすると、お客様の要望というのは非常に大きなもの、期待も大きなものであり、技術者に聞くと、みんなできると言っているということになります。しかし、実際にはそうはいきません。

実際問題としては、期間も限られて、お金も限られている。このときに出来ることと出来ないことを技術者としてどう見極めて、お客様の要望に対してどう応えるかがポイントになります。本当は技術的に出来るのだけれども、技術的に出来ると言っていると永遠に要望が収束しなくなりますので、お客様には２枚舌になりますが、それはこういう意味で技術的に出来ないのですと言って、場合によっては技術者として出来ませんという答えをきちんと言うということが大事になります。

すべてがうまくいくことはない

特にトラブルが出たときにそのリカバリをどうするかというときに、これが非常にききます。ある大きなバグが出た。そうすると、担当者からバグを直すのに例えば１カ月かかるという数字が出てくるのです。

その数字の意味はどういうことかというと、このバグの修正をやって試験をやって、いろいろな手続を踏んできちんとした次のファイルを作るのに１カ月かかりますという意味で、その場合の条件は、すべてのことがうまくいくという条件でみんな考えるのです。ところが、実際問題としては、そのシステムでそういう大きなバグが出たとなれば、今までもうまくいってなかったものが、そのバグのリカバリだけ１００％うまくいくなどということはないのです。

ですから、担当者がそういうことを言っても、管理する側から見れば、すべてがうまくいくことはないので、そこはお客様に対しては、自分の判断で「２カ月かかります。その間はこういう運用対処をするのでお許しください」と謝ります。そういうマネジメントも一つのコツになると思います。１カ月で直りますと言って、１カ月後にまたお客様にもう１カ月くださいと言うと、それはもうお客様にばかにされて信用を失うだけです。お客様に対しては、マネージャとしてやはり２カ月かかりますと伝え、２カ月後にきちっと答えを出すということが非常に大事です。

ソフトウェアは人が財産

私は、NTTの研究所やソフト子会社でソフトウェアの研究や開発のマネジメントに８年ぐらいかかわってきました。その経験からとにかく言えることは、ソフトウェアは人が財産ですということです。これは、ソフトウェアに関する資質あるいは能力の極めて高い個人が作るソフトウェアは、規模が小さく高性能で品質が良いものになります。まさに人次第ということです。

一方で、大規模ソフトを作るということはグループワークですから、そのグループトータルのパワーを上げるという意味で、やはり人と人とのつながりがすべてです。

制約の無い環境が重要

この制約というのは、ソフトウェアを作るときに、例えばハードはこれを使いなさい、OSはこれを使いなさいという制約を課すことをいいます。そういう制約というのは、本来スキルある若いソフト技術者にとっては非常によくない。ですから、Linuxを使って自由にやっていいよ、ソフトウェア言語も何を使ってもいいよと自由にやらせることです。そういうスキルあるソフト技術者がいるのであれば、とにかく変な制約はつけないということが大事です。

最後は人の力！これを引き出すマネジメントが重要

最後は人の力と言っているのは、これは大規模システムを作ると、1M Lineぐらいのものをつくろうとすると、これはもうなかなか大変な力仕事になります。その人の力をどうやって引き出すかというマネジメントが非常に重要になります。

マネジメントで何が大事なことはトップの役割です。トップのマネージャとして大事なことはビジョンを示すこと。それは、今の仕事がどういう位置づけのもので、その会社にとってどのぐらい重要なものなのかということ。それから、自分たちの仕事の３年後、５年後はどうなるのか。５年後ぐらいまではビジョンだそうです。１０年後は夢でいいそうです。やはりマネージャは夢も語れなければいけませんが、明確に５年後ぐらいまでのビジョンは示さなければなりません。

今のソフトウェア技術の流れで言うと、現在手がけている仕事の延長線上では５年はもたないと思います。今の仕事は３年で終わってしまって、４年後、５年後何をやっていいかわからんということになります。何やっていいかわからんという職場は、若い人たちの元気が出ませんので、マネージャがビジョンを示す必要があります。それから、マネージャは部下に情報を隠さないということも大切です。

取り扱いが簡単なこと（ノー・マニュアル）

大量導入するシステムにはどうすればいいのか。ここで言う大量導入というのは、百万ぐらいの数は簡単に入ってしまうシステムを言います。大量導入するシステムの場合、一番大事なことは取り扱いが簡単なこと。マニュアルなしでだれにでも扱えますよということです。通信に関する身近な例でいけばADSLのモデムがこれに相当すると言えます。光ファイバーの家庭側の終端装置であるONUは、通信会社の工事の人が来てセットアップを行っていますので、残念ながらまだこの領域には達していないといえます。

壊れにくいこと（高信頼）

それから、壊れにくいということ。これは何か不良があって取りかえますといっても、何十万と出てしまったものを交換するのは非常に大変なことです。ということで、高信頼性を確保することは必須条件になります。これは、石油ファンヒーターや自動車のリコールの例からも分かるように、大量に出回ったものを回収あるいは修理することは、多くの手間と時間がかかり、企業イメージに大きな傷がつきます。

電気を食わないこと（低消費電力）

それから、電気を食わないこと、消費電力が低いということは、これは非常に大事です。エコであることは、今の世の中では当然のことになっていますが、現状の家庭内の通信機器は常時電源がＯＮの状態で使われている例が多いと思います。これは、通信機器の電源を商用１００Ｖからとるようになったためで、この電力を通信会社側から供給しようとすると通信会社のビルの電力設備に膨大なものが必要になります。

現在も３千万のユーザがいるアナログ電話は、ハンドセット（受話器）を上げたとき、あるいは何かボタンを押したときに初めて電流が流れて通話中しか電力は消費しない形になっています。この電力は通信会社側の設備から供給されていますので、商用電源が停電になってもアナログ電話は使えます。ただし、ワイヤレスのハンドセットが使える電話では親機が商用電源で動いているので停電の場合は使えなくなります。

話が少しそれましたが、大量に導入されている家庭内の通信機器やパソコンの電力消費を抑えることは、今後重要になりそれを目指した技術開発が必要です。

シンプルに考える

開発技術者として私自身の考え方は、まずはシンプルに考えるということです。

余り複雑なものを作るよりはシンプルなものの方がよく、最終的にいかにシンプル化するかが大切だと思います。

いかに楽をするかを考える

次は、いかに楽をするかを考える。これは、いい意味でさぼれと言っているのです。

今の世の中は、何から何まで自分でつくりますという時代ではないので、世の中にあるよいものがあればそれをうまく使ってシステムを作ろうということです。

技術の上にあぐらをかかない

それからもう一つは、先人が残したよいものはうまく利用させていただくが、技術の上にあぐらをかかないことが大事です。

もうこれでできたからこれで当分大丈夫というわけにはいかなくて、常に先を見て慢心しないことが大切です。

そういう意味ではインターネットの次をどうするかということを真剣に考えなければいけないと思います。

少数精鋭の開発チームを組む

アグレッシブなとは、短期で高い目標を達成することをいい、そのための条件の第一は少数精鋭の開発チームを組むことです。

社運を賭けた大事なシステム開発プロジェクトだと思って下さい。

なぜ少数かというと、チーム内の意思疎通をよくし意思決定をすみやかにすることが大切で、「船頭多くして船山に登る」ことが起きないようにするためです。

精鋭の人材をあてることは言うまでもないことです。

短期開発の可能な環境を整備する

短期開発では、シミュレーションのためのコンピュータリソースやデバグのための検証設備を十分に用意して、作業上のボトルネックが生じないようにすることが大切です。

社運を賭けたプロジェクトでは、社長特命の印籠を用意して最優先でリソースが使える環境を整備することが成功につながる鍵になります。

技術的、期間的に明確な目標を設定する

目標の設定は当たり前のことですが、特に、アグレッシブな開発をやる場合にはマイルストーンを細かく設定して、その時点、時点での技術的目標を明確にすることが大事です。

プロジェクト全体のスケジュールに対して、ある時点で技術的完成度を求めるのか、納期を優先するのかの戦略的判断をしなければならないことも生じます。

目標は明確にしなければなりませんが、目標は多層的に設定し、100点満点ではなくても実用的に問題を生じないレベルを想定しておくことが必要です。

顧客の潜在ニーズを引き出す

システム開発に当たって考えるべきことを、順不同で挙げてみます。

私の経験からいっても、１番目は顧客の潜在ニーズを引き出すことが大切です。

こう書くと非常に格好いいです。

悪く言うと、お客様は自分が欲しいものが全くわかっていないということになります。

要するに本当に欲しいものというのは、なかなかお客様自身はわからないのです。

後で出てきますけれども、姿形のないものを、こんなものができますけれどどうですかというのは、お客様にはなかなか受け入れていただけない。

出来上がってみると、ああそういうものなのかということになり、ああそうだよ、これこそ私が本当に欲しかったものだよというふうに言っていただければよいのです。

しかし、出来上がったものが全然違っているといわれるとだめなのですけれども、やはり潜在ニーズをどうやって引き出すかが非常に大切です。

現場の声は天の声ではない 自ら現場を見に行く

次は、これはちょっと難しいですが、現場の声は天の声ではないとみずから現場を見に行くという二つがあります。

よく言われることですが、何かやるに当たって、とにかく現場を見に行けと、現場が何を言っているか聞いてこいと。

聞いてこいと言うのは簡単ですが、潜在ニーズを聞いてこなければいけないわけです。

現場の声というものは、大体今のもののどこが悪いとか、どこが悪いからどう直して欲しいということは言えるのですが、今のものと違うものを作るときにどうですかという聞き方をしても、それに対する答えは出てきません。

ですから、今のシステムなり運用・保守作業なり、そういうものに対しての不満、それは出てきます。

ですから、その声だけを聞いて物をつくってよいかというと、そうはいかないのです。

現場の声はそういう声があると、それをやはり自分自身が見に行って確かめておかなければいけません。

その上でどう付加価値をつけるか考えるのです。

標準インターフェースを採用する

それと、ちょっととってつけたような形になるのですが、標準インターフェースを採用するということも大切です。

過去には特定の企業が強大な購買力で市場支配力を持っていて、その企業の固有の仕様というものがまかり通っていたこともありました。

これから先の世界はそうではなくて、国際標準があるもの、あるいはデファクトスタンダードがあるもの、そういったものに関しては標準インターフェースを使っていこうということです。

標準インターフェースは、使うだけでなく自ら標準を作ること、作る仲間を増やすことがさらに大切です。

実現可能なぎりぎりの目標を設定する

システムの仕様を決めるにはどんなところに気をつけていけばよいか。

ここら辺が、そのシステムがいいものになるかどうかという一つのポイントになると思います。

そのためには、実現可能なぎりぎりの目標を設定することが大切です。

簡単に達成できるような目標ではやはり達成感が得られませんし、また、実現不可能な目標をつくったら、それはやった結果として失敗するわけですから、それではだめです。

この実現可能なぎりぎりというところをどうやって設定するかが技術者として腕の見せ所になります。

これは、私自身はシステムの発注側の開発技術者でしたから、メーカーの技術者の方々に仕事をお願いするときに、最初に「こういう仕様でやりましょう」と言うと、「そんなばかな」、「そんことはできません」と言われる。ところが、やった結果として、「やればできるものですね」と言われる。

そういう技術的にかなりチャレンジャブルだけれども達成可能、そういう目標の設定、これが非常に大切だと思います。

技術的に実現可能なことと実際に実現してよいことを見極める

その次には、これは反語的になるのですが、技術的に実現可能なことと実際に実現してよいことを見極める。

これは技術だから何でもできる。

最近はいろいろ倫理的な問題、社会に与えるいろいろな影響ということで、技術的にできれば何でもやればいいというものではないということがかなり認識されてきていますが、社会に容認されるといいますか、受け入れられるものにするためには、やはりこの辺の見極めというのが一つ必要です。

デジタル化ということで言いますと、音声のデジタル化に関してはＤＡＴという、デジタル・オーディオ・テープというのが、今から見ると随分昔に技術としてはできていました。

ただ、それは著作権の問題にひっかかってなかなかうまくいかなかったという例が挙げられます。

システムに適用する要素技術のバランスをとる

それから、システムに適用する要素技術のバランスをとる。

これが結構難しいことで、どこか技術的に先端的なところも必要なのですが、全体としてはバランスがとれていることが必要です。

これは今の技術、あるいは今から一、二年後の技術で実現したときの性能が一番出るようなバランスをとるということです。

このバランスをとるということはかなり広い知識を持ってないとうまくいきません。

バランスのとれてないシステムは、要素技術の中の一番レベルが低い技術の性能がボトルネックになって全体の性能が落ちてしまいます。

そういうことに気をつけて仕様を決めることが必要だと思います。

無から有を生じさせる楽しみ

システム開発に関して、最近、世の中全体に物づくりに関しては余りおもしろくないという風潮があります。

それは、ソフトウェアを含めて物を作るということ、その作るということの経験が余りされなくなってきたためなのかも知れません。

私自身が感じるところで言うと、無から有を生じさせることは、なかなかしんどいことではありますが、これはひとつの楽しみです。

どちらかというと研究者の楽しみですね。

今まで世の中になかったものを作る。

これははっきり言うと、世の中からは見えなくても何か自分が思いついただけでも楽しい。

余り思いつきだけで楽しんでしまうと、そんな研究は要らないと言われることになるのですが、やはり無から有を生じさせる楽しみにはすばらしいものがあります。

ゴールに達したときの達成感、満足感を得ることの楽しみ

それから、実際に物をつくっていくという意味で言いますと、ゴールに達したときの達成感とか満足感、そういったものを得る。

そういうことの楽しみがあります。

達成感を得られるということの裏返しには、ゴールに至るまでの苦しい仕事がある訳で、苦労が多ければ多いほど喜びは大きくなります。

ゴールの設定レベルについては別のコラムで述べますが、易しすぎず難しすぎず、限られた時間の中で達成可能なレベルを設定するのが優れた開発技術者の腕の見せ所です。

自分が手がけたものが世の中を変える楽しみ

自分の手がけたものが世の中を変えていく。

これは世の中の仕掛けという意味では非常に大きな仕掛けで動いていますから、ごくごく一部のこともあります。

たまたま私が手がけたもので言うと、電気通信の分野で新しい通信システムを1990年ごろに開発し、その後順調に世の中に広まり、それが今でも現役として使われ続けていることがあります。

これは、たまたまそういうめぐり合わせで仕事ができたということなのですが、私自身にとってはそういうところに自分のやった足跡が世の中に残るというのは、これは非常に楽しいことです。

こういう楽しみがあるから苦しくても仕事をするのだと言わないと、若い人がついてこれなくなってしまうのだと思います。