セーフウェアの解説その二

『セーフウェア』の解説その二として、【安全性と信頼性は別なものであって、混同してはならない】を説明しようと思う。

安全性：Safety と 信頼性：Reliability は異なる。異なるというよりは区別して考える理由がある。ナンシー・レブソンが言いたいのは、信頼性：Reliability を高めることで安全性：Safety が確保されると考えてはいけないということだ。

多くの人は「なぜ」って思い、ピンとこないかもしれない。でも、「このソフトウェアに何か問題があると、人を傷つける可能性がある」というソフトウェアを一度でも作ったことがある人には分かると思う。それだけ重要なソフトウェアであっても、問題を起こさないという絶対的な自信はなかなか生まれてこないのだ。責任感が強いエンジニアほど、この現実は辛い。テストをいくら積み重ねても、100%の安心にはつながらないことは直感的に分かる。ソフトウェアの規模が大きくなればなるほどエンジニア個人の無力さを感じると共に、個人の範囲を超えたときから「自分だけではどうしようもない」を考えるようになり責任感も薄れていく。

ソフトウェアの規模が大きくなると、完成度を高めても、悪意がなくとも誰も気づかないうちにプログラムが修正されてしまう危険もある。

ソフトウェアを部品と考え、十分に信頼性を高めたと思われる部品を結合したソフトウェアシステムは必ずしも安全ではないことは、このような経験から感じるのだ。

もちろん、ソフトウェアモジュールの信頼性を高めることは、ソフトウェアシステム全体の安全性を高めることに貢献する。しかし、それでもなおナンシー・レブソンが「安全性と信頼性は別なものであって、混同してはならない」と言うのは、信頼性の高いソフトウェア部品をつなぎ合わせて作ったソフトウェアシステムが、システムとしてのユーザーリスク、プロダクトリスクを分析して対処する、もしくは、リスクを制御するシステムアーキテクチャを採用していないのであれば、安全なシステムであるとはいえないからである。

そこには次のような具体的な要因が考えられる。

• AモジュールとBモジュールの制御判断が背反した場合のシステムとしての動作をモジュールは規定できない（部品の信頼性では解決出来ない）
• 検証が終わり信頼性を高めたモジュールが改変できなようにすることは難しい
• システム全体でリスクを軽減しようとしても、部品が完成してしまっていると実現しにくい。
• ソフトウェアを変更しないで再利用できるようにするためには、高度なスキルが必要であり、簡単ではない
• システム全体のリスクを分析してコントロールしようとしない者は、すでに存在するソフトウェア部品の組み合わせでシステムを構築しようとし、リスク低減よりもソフトウェアの早期リリースが優先する

開発効率やコストダウンを優先するあまり、信頼性の高いソフトウェア部品を組み合わせてシステムを構築したいと考える者は必ず存在し、その考え方が事故を誘発する。

このことが分かっているからセーフウェアには「安全性と信頼性は別なものであって、混同してはならない」と書かれているのだ。

これは手段が目的になってしまい、本来の目的が忘れ去れれてしまうこととよく似ていて、「物事の本質を見極めない」、「どうして今これをやらなければいけないのか」と考える習慣がないと陥る危険性のある心理的なトラップである。

「信頼性を高める」ことは手段だと思う。一方で「安全性を高める」とは目的だ。「安全」と言う言葉の後ろには、人や財産など失ってはいけない重要なものがはっきり見える。

「信頼」は誰のための「信頼」かがはっきりしない。クライアントがサプライヤーに求める「信頼」は、エンドユーザーの「信頼」であるとは限らない。例えば、産地偽装を指示したクライアントに対して、言われた通りにラベルを偽装したサプライヤーはクライアントの信頼を得るが、エンドユーザーの信頼は裏切っている。

安全は常にエンドユーザー（場合によってはオペレータも含まれる）が対象になる。安全は誰も裏切らないが、信頼は場合によってはだれかを裏切る可能性がある。

「安全性と信頼性は別なものであって、混同してはならない」の深い意味をお分かりいただけただろうか。『セーフウェア』を読む方はこの点について気にしながら読んでいただきたい。

P.S.

Dependability や Functional Safety ということばも最近 ISO規格の中で出てきており、

Wikipedia によると  Dependability は

Dependability is a value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.

とあり、 次の要素を含むとある。なんと Safety も Reliability も含まれている。

Availability - readiness for correct service
Reliability - continuity of correct service
Safety - absence of catastrophic consequences on the user(s) and the environment
Integrity - absence of improper system alteration
Maintainability - ability to undergo modifications and repairs

こうやって、いろいろな視点をまとめて体系化することで、特定のドメインにおける安全または実際に起きた事故の再発防止策が抽象化されてすべてのドメインに通用する銀の弾丸があるかのように思われることを自分は心配している。

また、Wikipedia によると Functional Safety は

Functional safety is the part of the overall safety of a system or piece of equipment that depends on the system or equipment operating correctly in response to its inputs, including the safe management of likely operator errors, hardware failures and environmental changes.

となっている。この Functional safety（日本語では機能安全）が、なぜ Functional を Safety にくっつけたのか未だにその真意を理解していない。いずれこのブログで話題にしたいと思う。

セーフウェアの解説その一

安全ソフトウェアの教科書的な存在であるセーフウェアを読み始めた。656ページもある分厚い本なので、まずは30分くらいで斜め読みした。

自分は約20年近くクリティカルデバイスの開発に携わってきたので、書いてあることがよく分かったが純粋なソフトウェアエンジニアにはピンとこないかもしれないとも感じた。

具体的な事故の事例も多く掲載されているので、取っつきやすいと思うがやっぱり解説が必要にも思える。

そこで、できるところからこの本に書いてあることの意味について解説してみようと思う。

どこがいいかざっと見ていたら、エピローグ「これからの展望」にいいことが書いてあったので、ここからいこう。

【『セーフウェア』エピローグ これからの展望 より引用】

• 安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。

• 安全性と信頼性は別なものであって、混同してはならない。

• 確率論的リスクアセスメントに依存し過ぎるのは賢明ではない。

• システムに安全を組み込むことは、完成した設計に防護装置を加えるよりも、はるかに効果的である。安全が、開発プロセスのより早い段階で考慮されるほど、より良い結果が得られる。

• 進歩するためには、事故を単純化しすぎるのを止め、事故の、複雑で複数の要素がからんでいるという本質を認めなければいけない。根本原因に手を着けずに、症状だけを処置しても、事故の再発はほとんど防げない。問題の数少ない側面だけに集中しても、望ましい効果は得られない。特に、技術的問題だけに着目して、管理上や組織上の欠陥を無視したのでは、有効な安全プログラムは得られない。

• 単に人間をコンピュータに置き換えても安全問題は解決しない。人間の「エラー」は人間の柔軟性と創造性に不可避に結び付いている。人間をコンピュータに置き換えるのではなく、むしろコンピュータを用いて人間の能力を増強する方法に取り組むべきである。

• 安全はシステムの問題であるので、異なる分野の専門家が共同して働くことによってのみ解決することができる。特にソフトウェアは、システムの他の部分から独立していては、効率よく開発できない。ソフトウェア技術者は、システム安全の概念と技法を理解しなければならない。同時に、システム安全担当者は、より深くソフトウェア開発にかかわり、システム安全のプロセスにソフトウェアを取り込むようにしなければならない。

• そのソフトウェアが動作するシステムという状況の中でのみ、ソフトウェアの安全性を評価することができる。ソフトウェア単独で見るだけでは、一片のソフトウェアの安全性も評価できない。

• 自己満足はおそらくシステムで最も重要なリスク要因であり、それを最小にする安全文化が確立されなければならない。

• 事故につながる事象が予測できないからといって、事故が予防できないということにはならない。ハザードは、通常分かっていて、しばしば、除去され、かなり軽減される。必要な機能性や費用の低さのような、他の目標とのトレードオフが最も少ないために、（ハザードよりも）先行する事象を除去しようとする決定がしばしば下される。複雑な決定は科学を超越したものである。しかし、技術者には、上位の意思決定者のためにリスクを明らかにし、自己満足または他の要因、または圧力が、意思決定において当然の考慮されるべき工学上の問題またはリスクを妨害しないようにする義務がある。

• われわれは同じ過ちを繰り返さないよう、過去から学ばなければならない。

【引用終わり】

これらを全部解説していたら終わらないので、まずは『安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。』から

【安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである】

「安全」と「シンプル」は親和性が高い。特にソフトウェアは見えにくいので単純か複雑化を見分けるのも難しい。だからこそ、クリティカルデバイスのソフトウェアエンジニアは常にシンプルなアーキテクチャを目指す必要がある。

単純の最大のメリットは何だろうか。単純なソフトウェアはテストケースを有限にできる可能性がある。テストケースが有限ならば、テストに漏れがないと言える確率が上がる。

ちなみに、仮にテストケースが有限でテストに漏れがなくても安全とは言えないということは『安全性と信頼性は別なものであって、混同してはならない。』の解説で述べたいと思う。

でも、シンプルなアーキテクチャである方がテストもしやすいし、より安全に近づけることが可能であることは直感的に分かると思う。

さて、「知的に処理できるシステムを構築することである」の意味は英語の原文が手元にないので絶対そうだとはいえないが、たぶんこういうことだろうと思う。

要するに、安全を実現するアーキテクチャ、別な言い方をすればリスクコントロール手段を実現するアーキテクチャがある＝きちんと設計されているということだと想像する。

世の中、ソフトウェア搭載デバイスへの要求はどんどん多様化している。車だってセンサが障害物を感知して自動でブレーキをかける時代はすぐそこにきている。しかし、便利と安全は少なからず背反する部分がある。便利にしようとすればするほど、ソフトウェアは複雑になりユーザーの安全を確保するのが難しくなる。

センサーが障害物を感知したからといって、自動でブレーキをかけるとかえって危ないケースをあなたは簡単に想定できるだろうか。（日頃から訓練しているとできるようになる）

例えば突然ボールが自分の車の前50mくらいのところに転がってきたとする。冷静なあなたはバックミラーを見て、後ろから来ている大型トラックがよそ見をしているのを確認した。ここで自分の車が急停車すると後ろのトラックからかなりのスピードで追突される可能性がある。この場合、あなたの車はブレーキをかけないでボールをはね飛ばすか踏みつぶす方がリスクが低い。

ユーザーはいろいろなシチュエーションを想像することもなく、安易に車が自動でブレーキをかけてくれる機能があるといいと言うが、上記のような複雑なシチュエーションでその自動システムが働きかえって事故が起こったりすると、「そんな事態も想定して対策しておくのがメーカーの役目であり、過失だ」と結果論でものをいう。高い金を払って買っているのだから、どんなに複雑でも安全にできていて当然だという論理だ。ちなみに、その考え方は正しい。安全はタダでは確保できない。安全には価値があり、その価値を実現するにはそれなりの対価が必要だ。安全の対価をユーザーからいただいたメーカーは安全を確保する責務がある。しかし、システムが複雑になればなるほど、当たり前品質を確保するのは難しくなり、安全を確保する技術が必要になってくる。

だからこそ、「知的に（安全を）処理できるシステムを構築すること」は価値がある。システムを複雑に作ってしまってから、後からとってつけたようにリスクコントロールのソフトウェアを付けることは、目的を果たせない穴ができる可能性がある。

リスクコントロール手段は、最初からきちんと分析設計されたものであり、かつ、できるだけシンプルなアーキテクチャであることがいいのだ。単純で分かりやすいアーキテクチャであれば、ソフトウェア変更時の影響範囲の分析や、テストのポイントも絞り込むことができる。総当たりでテストすればよいという考え方では必ず漏れがでる。構造をシンプルにして抑えるべきポイントを絞り込むことが有効である。

こんな感じで、今後も、機会があるごとにセーフウェアのエピローグを解説していこうと思う。

Forecast と Backcast の視点

エコの世界にはフォアキャスト（Forecast）とバックキャスト（Backcast）という言葉があるらしい。

そもそも、フォアキャスト（forecast）やバックキャスト(backcast)は、釣りの世界の専門用語で、フライフィッシングにて、釣り糸と仕掛けの重さだけで自分の思うポイントに疑似餌を投入する竿と糸の振り方（キャスティング）で、前に振るのをフォアキャスト、後ろに振るのをバックキャストと言うのだそうだ。

で、エコの世界でどのようにフォアキャスト（Forecast）とバックキャスト（Backcast）が使われているかというと・・・

【「バックキャスト」と「フォアキャスト」とはどかが違うの？ より引用】

フォアキャストでは、過去の実績を延長して（たとえば）25年後の目標を決めます。この場合、25年後の目標はたとえば努力の程度、実現の難易度などで複数個（～無限個）のものを設定することができます。これとは全く違って、バックキャストでは、たとえば「炭酸ガスの排出量を25年後に6億トン以下に抑える」といったことを「決めます」。目標は動かさない（動かせない）のです。そうしておいてから、「では今、そして来年から25年後まで、何を何時迄にやらなければならないか」を決めます。これにも幅（余裕、選択）は（ほとんど）ありません。そして実行してみてたとえば1年後に結果を見て、もし計画からずれていたら直ちに今年の計画に組み込まなければなりません。

【引用終わり】

要するに、このまま放っておけば地球は滅亡する。それを防ぐためにはこれこれのことを積み上げていかなければいけない。今年の目標が達成できなければ、来年は今年実現できなかった分も実施する。生き延びることができた場合の未来から過去を振り返ったときに、やるべき事を考えるのがバックキャストということだ。

そこでふと思った。エコの世界だけでなく、フォアキャスト（Forecast）やバックキャスト（Backcast）という視点は大事だということである。

フォアキャスト（Forecast）とは、「前を見通す」という意味で、現状分析から出発して、将来どのようになっているかを考える。楽観的な人は楽観的な未来を悲観的な人は悲観的な未来を予想するだろう。どちらにしも、ある意味未来に対しての責任があるという色彩は薄い。

しかし、環境問題で使われているバックキャスト（Backcast）の例を見れば分かるように、バックキャストには目指すべき未来を実現するための責任という意味も含まれる。

これは、ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）の実践にぴったりじゃないか。

ソフトウェアプロダクトラインが日本での成功例がなかなか見あたらない一つの理由に、日本人の未来を見通す力の低さと、来るべき未来を実現するための今の責任という視点に欠けているという点があると思う。

これこそ、フォアキャスト（Forecast）とバックキャスト（Backcast）の視点だ。

ソフトウェアプロダクトラインは、コアとなるソフトウェア資産を構築して、それを使ってさまざまな派生製品を作っていく戦略だ。簡単に思えるかもしれないが、実現するのは極めて難しい。難しい理由は、次の三つだ。

1. 再利用可能なコアアセットを作るスキルが足らない
2. コアアセットを作るための一時的に時間とコストがかかる
3. せっかく作ったコアアセットを我慢できずにすぐ修正して派生させてしまう技術者を組織が制御できない

これらのハードルを越えてソフトウェアプロダクトラインを成功させるためには、次のようなことが必要であろう。

1. 開発効率が上がりこれまでの半分くらいの工数で楽々新製品のソフトウェアができてしまうソフトウェアプロダクトラインが成功したときのプロジェクトの姿を想像する。
2. そのための必要なスキルや、組織構成、時間、コスト、必要な技術支援は何かを考え、実現のための計画を立てる。
3. 最初（コア資産ができあがるまで）は辛くとも、未来の自分達の姿を夢見てスキルアップに精進する。

ここにはフォアキャスト（Forecast）とバックキャスト（Backcast）の両方の視点が入っている。大事なのは、未来のあるべき姿を実現するためには、辛くとも努力を続けあきらめずに途中で取り組みを放り投げないことだ。

そのためには、あるべき姿、未来の成功した自分から現在をバックキャストして何が足らないのかを考えることも必要だし、現状を分析して未来に向けて何をすべきかというフォアキャストの視点もいる。

辛い現実があるとつい近視眼的な視点になりがちだが、5年、10年というレンジで、フォアキャスト（Forecast）、バックキャスト（Backcast）の視点で、左うちわで価値の高い商品を生み出すことに成功している自分を想像しつつ、そのために今やるべきことは何かを考え、実行することが大切ではないかと思った。

バックキャスト（Backcast）したときに、今の自分の双肩にかかっている責務を感じることができない人は、結局はいろいろな誘惑に負けて想定した未来を掴むことはできないのだと思う。　

Validation（妥当性確認） と Varification（検証）

他人の失敗をネタにするのはちょっと気が引けるが、同じような失敗を犯さないように教訓として紹介しようと思う。

MATLAB / Simulink を販売する Mathworks から送られてきたダイレクトメールの話しだ。

MATLAB / Simulink は1988年より、日本での販売展開はサイバネットシステム株式会社が代理店業務を行っていた。しかし、2009年7月1日から販売代理店業務をMathWorks Japan(MathWorks社の日本法人)に移管された。

このように、日本で代理店が売り上げを伸ばしてくると本国が直営の法人を作って販売権を取り上げるという話しはよくある。そして、少なからずサービスの質が低下するシーンをよく見かける。

日本に独自の顧客環境があることを説明しても理解せず、シンガポールや中国、韓国でうまくいっているのに日本だけがダメなわけがないと突っぱね、強引に販売権を奪ってしまう。

自分は MATLAB / Simulink のユーザーではないが、MATLAB EXPO などでリサーチはしているので、ダイレクトメール2010年1月5日にオフィスに届いた。

宛先を見ると、郵便番号は空欄で、住所のフレーズのところどころが一文字ずつ欠けている。

例えば

東京都 の都が欠けて 東京 に
：
酒井 由夫 の酒が抜けて、 井 由夫 に

なっている。日本郵便は民営化後も優秀だ。郵便番号のなく、住所の各フレーズが欠けていている住所でも郵便物が届く。たぶん、意地でも送り主に返送したくなかったのだろう。なぜならスウェーデンから発送された郵便物だったからだ。

MathWorks は世界中のユーザーに スウェーデンからダイレクトメールを発送しているのあろう。それが、もっともコストが安いのかもしれない。スウェーデンから国際郵便でダイレクトメールを送っているが、住所は漢字で書いてある。JAPANだけが英語で書いてあるから、漢字に不備があっても日本までには届くのだ。スウェーデン人が漢字を読めるわけがないから、住所に問題があっても発送される。

中に入っていたのは無料CDの発送の申し込みと MATLAB EXPO 09 の申し込みの案内だった。

“はい、MATLABデモ、Webセミナー、ユーザー事例などに興味があります。無料CD をすぐに送付してください。” という文章の頭に□があってすでにチェックが入っている。この文章も日本人的には少し押しつけがましいように思えるが、世界中同じ内容で送っているのだろう。

送付先は シンガポールの郵便局の私書箱のようだ。

そして、MATLAB EXPO 09 の申し込み開始のご案内は 2009年12月2日に開催する展示会の案内で、展示会は一ヶ月前に終わっている。

この郵便が2009年中に発送され、スウェーデンのクリスマス休暇や日本の正月休みの影響があったのだとしても、これは明らかに MATLAB EXPO 09 が終わってから発送されたのだと思う。（消印はないのでいつ発送されたのかはわからない）

ダイレクトメールの中身は全部日本語で書いてあるから、発送作業者はこの間違いがまったく分からずに発送してしまっている。

この話しは単なる笑い話ではあるのだが、実は V&V ( Validation & Verification ) ができていないという教訓でもある。

Validation: 妥当性確認 は、要求仕様を満たしているかどうか、ユーザーニーズに合致しているかどうかの確認であり、 Verification: 検証は、仕様通りにできたかどうかのチェックである。

最大の相違点は ユーザーニーズに合っているかどうかを確認しているかどうかということだ。今回の Mathworks のミスは、Varification は実施していたのかもしれないが、 Validation をしていなかったということだ。

要するに、発送時にダイレクトメールを受け取る日本のユーザーのニーズに合っているかどうかを確認せずに商品をリリースしたということになる。

※この手の問題は日本の代理店が口を酸っぱくしてミスを訂正させるのだが、今回は代理店を通さずに送ったからミスが見つからなかった。

たぶん、スウェーデンのダイレクトメール発送センターに日本人のスタッフが一人もいなかったのか、もしくはいても Validation を実施するプロセスがなかったのだろう。

グローバルマーケットで商品を作っているとこのようなことはよくあるし、外国語の部分を業務ドメインに特化した情報と置き換えて見ると、このような問題（事故）は国内でも起こる可能性があるのだ。

例えば、商品の使用環境がよく知らないプログラマにソフトウェアの作成を外部委託し、要求仕様の漏れがあって、使用環境を想像してプログラムを作ったら、それが勘違いであり、ユーザーに迷惑をかけたというようなケースだ。これは外部委託されたときの仕様書がどれだけ完成度が高くても、発生する可能性がある。仕様書自体に間違いが含まれるからである。

このようなケースは Verification （検証）はOK だったが、Validation （妥当性確認）が NG だったということになる。

ユーザーの嗜好や思考は全世界で同じではない。すべてのユーザーを満足させることができる仕様があるとは限らない。だからこそ、Validation （妥当性確認）という行為は非常に重要なのだ。

ちなみに、QA担当は問題がわかったときに、問題を指摘し是正と再発防止策を打たなければいけない。この件に関しては自分自身では是正と再発防止策を採ることはできないので、キチンと、Mathworks Japan にこのようなミスがあったことを教えてあげた。（イヤミの意味ではなく、QA的立場から通知の義務があると思ったからだ）

その後、日本の営業担当の方から次のようなコメントが送られてきた。

お世話になっております。

マスワークスジャパン担当営業の○○と申します。

この度はMATLAB Expoのご案内でお見苦しい文面をお送りしてしまい。大変申し訳ございませんでした。

謹んでお詫びを申し上げます。また、ご指摘を頂き大変ありがとうございました。

只今原因調査と改善に向けて対応しておりますが、現状ではまだ不正確な文面が出力される可能性を消去出来ていない状況でございます。

ご迷惑をお掛けしました旨、重ねてお詫び申し上げます。

何かございましたらお気軽にご連絡頂ければ幸いです。

以上、宜しくお願いいたします。

何しろ、発送元がスウェーデンだから原因調査と改善は難しいだろう。（ブログネタにしてしまってゴメンね）

グローバルビジネスとはいかに難しいものか・・・

P.S.

スウェーデンと言えば、話題の スウェーデン作家 スティーグ・ラーソンのミステリー『ミレニアム1 ドラゴン・タトゥーの女』を読み終えた。出てくる人物が多く名前を覚えるのが大変で、上巻は読むスピードが鈍ったが、下巻は一気に読み切った。なかなか面白かったし、この原作の映画化したものが近々日本で公開されるらしい。是非見に行きたいと思う。

スウェーデンというと日本とはほとんど関係がないと思っていたら、リンドグレーンの「長靴下のピッピ」「名探偵カッレ君」「IKEYA（最近話題の激安家具屋）」「H&M」「ボルボ」などが小説の中にでてきて親しみを感じた。

立場が変わっても胸張れるように行動しよう

NHKの大河ドラマ『龍馬伝』が始まった。福山雅治が最近、なんでカーリーヘアーにしているんだろうと思っていたら、龍馬を演じるためにそうしていたんだ。

龍馬伝を見ていたら、当時土佐藩には上士（上級武士）と下士（下級武士）の厳しい階級制度があり、下士は上士に逆らえないという理不尽な世界が広がっていた。

これを見ていたふと思ったのは、現代におけるクライアントとサプライヤの関係も同じようなものではないかということだ。クライアントは発注者でサプライヤや受注者という上下関係があるため、基本的にはサプライヤはクライアントに逆らえない。これは坂本龍馬の時代と同じではないかと思ったけれど、絶対に立場が逆転しないわけではない。

クライアントの組織からその人が離れれば、サプライヤの立場になることも大いにあり得る。自分の実力ではなく組織の後ろ盾で偉そうにしている者は立場が変わると本当に情けない。

妹尾河童の小説『少年H』で、戦時中の学校で偉そうにしていて少年Hをいじめていた教師が終戦後に態度が180度変わる場面があった。環境なんていつどんなふうに変わるのかわからない。だから環境や立場が変わったときに情けないことにだけはなりたくないと思う。

ツールベンダーの営業員と話しをするときにこのことを忘れないようにしている。自分が動かそうとしているのは自分のお金ではなく組織の金であり、そのツールに投資するのは、自組織の商品やサービスを向上するために役立てるのであって、それが達成できなかったら自分の責任だ。

だから、そのために自分とツールベンダー、ツールメーカーは協力しなければいけない。技術者教育ベンダーについても同じ事が言える。技術者教育にお金をかけるということは、その結果、技術者のスキルが上がり、結果的に価値の高い商品をリリースすることに貢献できなければならない。

すぐに結果が分かるようなことではないが、「役に立つ」という確信がなければ投資してはいけない。

そのためには、ツールベンダー、ツールメーカー、教育ベンダーにも努力してもらう部分があるし、自分もできる限りの情報を提供する必要がある。

ツールベンダー、ツールメーカー、教育ベンダーも何も言わずにお金だけ払ってくれるお客さんよりも、いろいろな注文を付けながらも長く付き合ってくれるお客さんの方がありがたいはずだ。

クライアントもサプライヤも顧客満足を高めることを第一の目的として行動をしていれば、よりよい互恵関係が築かれ、後から売り上げも付いてくるはずだ。

日頃からそういう行動を取っていれば、立場が逆転したときでも共通の価値感のもと、態度を変える情けない状況にはならないと思うのだがどうだろうか。