開発技術者の方への最近のブログ記事

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

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

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

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

悪い情報は早く上げる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【参考書籍】

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

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

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

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

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

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

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

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

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

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

何年使うか

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

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

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

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

次世代をいつ出すか

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

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

人間はミスをする

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

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

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

技術は進歩する

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

仕事のやり方は変化する

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

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

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

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

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

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

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

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

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

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

ソフトウェアは人が財産

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

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

制約の無い環境が重要

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

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

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

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

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

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

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

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

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

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

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

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

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

締切りがあるから仕事は進む

線表とは、開発プロジェクトのスケジュールを時間軸を横軸にして、全体のマイルストーンと個々の作業を横線で表したものです。この線表の締切り、すなわち終点は装置開発なら納期、ソフト開発ならリリース日になります。逆線表の考え方とは、仕事の進め方を締切り日からさかのぼる形で決めていくことをいいます。最終締切り日には完成させなければならないのですから、その1ヶ月前には何が終わっていなければならないか、さらに2ヶ月前には何が・・・と、お尻から物事を決めていくと冗長な計画にはなりません。日頃の仕事でもそうですが、締切りのない仕事はついつい後回しになってしまいます。締切りがあるからこそ仕事が進むのですから、やるべき仕事の締切りは自分でのなかでは公の締切りより前倒しして設定することがよいと思います。

仕事の難易度と自組織の実力を見極める

線表を作るうえで、仕事の難易度と自組織の実力を見極めることは非常に大切です。仕事のどの部分を自組織で担当し、どの部分を外部委託するかを判断します。また、自組織の実力が足りない場合には、どの組織とタイアップして仕事を進めるのか、それともつらいけれども自組織の実力を上げるための研修期間をとるのか。これらのことを総合的に判断して線表を作ります。私の経験で、あるソフトは機能的に単純で雛形になるソフトもあるので大丈夫だろうと外部に発注したところ、受注した組織の実力が伴っていなくて、とんでもない品質のソフトが納入され、バグとりに苦労したことがありました。自組織の実力と他組織の実力を比べることは難しいことを痛感させられました。

一度決めた納期は後ろへはずらさない

特に短期開発では、一度決めた納期は後ろへずらしてはいけません。一回納期を後ろへずらすとプロジェクトに関係する人々の間に、一回後ろへずらせたのだからさらに後ろへずらせるのではないかという期待が生じ、それまでの張り詰めていた緊張感が緩んでしまいます。

できない理由を探すのではなく、どうやればできるかを考える

仕事は、前向きに積極的な思考で進めましょう。

シンプルに考える

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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