組込みソフトエンジニアの終焉

この時期、団塊の世代の方達の定年退職の送別会がいくつかあった。そのような方々のこれまでのエンジニアとしての人生を聞いていると一芸に秀でた技術者は最後は多くの人たちに感謝されながら見送られるのだと感じた。

実際、その方は電気系のエンジニアの方だった。そこでふと思ったのは組込みソフトエンジニアは現役を引退するとき、周りの人たちからどのような見送りを受けるのだろうかということだ。そもそも、ソフトウェアは表に見えにくいものだから、実績を語るのも難しいだろうなと思う。

やっぱりソフトウェアも同じで「○○の専門家」とか「品質保証のプロ」など、何か一芸に秀でるところがないと引退を惜しんではもらえないに違いない。または、後身を指導して人を育てたかどうかだ。現役バリバリのエンジニアという時期を越えて30代中盤を過ぎるようになってきたら、若いエンジニアをどう育てるべきかということをいつも考えておかなければいけないと思う。

そうしないと、若い技術者を育てるどころか、世の中の新しい技術に追いついていけず、若い人たちの足を引っ張るだけの役に立たないおじさん、おばさんエンジニアになってしまう。

人を育てることを考えるときには、自組織で生き残れるスキルだけでなく、世の中に放り出されてもきちんと食べていけるようにするには何を教育すればよいかを考えよう。そうすれば、自ずと組織の外に目が向いて外の世界から見た自分を見つめ直すきっかけにもなる。

若いエンジニアを一人前に育てることができ、そんな技術者が徐々に増えていくようなら、現役の組込みソフトエンジニアを引退するときにも感謝してもらえるに違いない。

人から感謝されるためには、自分の周りにも組織にも社会にも貢献しなければいけない。

P.S.

『働くことの本質は貢献であるという考え方』の記事も参照されたし。

侍ジャパンとサムライエンジニアを重ねてみる

WBC決勝でアジアの列強がレベルの高いいい試合をした。めずらしくスポーツ新聞を買って隅々読んでみたら、張本勲氏が次のようなことを書いていた。

　私にとって日本プロ野球は「育ての親」。逆に韓国プロ野球にとって私は「生みの親」になる。1982年、李容一初代事務総長、李虎憲同次長と3人で立ち上げた。当時の目標は、日本とアジアのチャンピオンを争えるレベルまで持っていくこと。そのために何十人もの選手やコーチを韓国に送り込んだ。その韓国が昨年の北京五輪金メダルに続いて大リーガーが参加するWBCで決勝に進出。ここまできただけで感慨無量、私としてはどちらが勝ってもよかった。

　　：

　プロ野球75年の歴史を有する日本に対し、韓国は27年。野球部のある高校が4000以上ある日本に対し、約50しかない。そんな中でよくぞ・・・。「アッパレ！」である。

　　：

　堅い守りを中心として、恵まれた体格とパワーだけに頼る野球を粉砕したアジアの野球。これを機に日本、韓国の野球がより発展することを願ってやまない。

この記事で感じたのは日本は4000もの高校の野球部が甲子園を目指して日々トレーニングを重ねていて、その下支えがあってWBC優勝という栄光を掴むことができたということだった。

野球選手は、なぜ厳しい練習を続けてそれほどまでにうまくなりたいのか、また、辛くてもがんばれるのか。一つは今回のWBCのようなスポーツの祭典で活躍する選手達を見て自分もいつかそうなりたいと思うからだろう。誰しもヒーローになってみんなから祝福をされたいと思う。

ただし、自分の欲望のためだけでなく、プロフェッショナルのアスリートとしては、自分のプレーを観客に見せ感動し満足してもらいその対価として年俸を受け取るという職業人としての側面も忘れてはいけない。

松坂はWBCの期間中もメジャーリーグのシーズンでも十分に力を発揮できるように自分のコンディションを気遣っていたという。松坂のコメント「代表でも（メジャーリーグの）チームでも両方で結果を残さなければプロではない」。レッドソックスのフランコナ監督は「通常の調整ではないし、急に球数を増やして98球を投げた。帰ってきたら彼にとってベストの（調整）方法を話し合う。」と不機嫌だったそうだ。どちらもプロのプレーヤーとして本業の顧客への満足度が下がらないように気を遣っている。

エンジニアはプロのアスリートのように表舞台に上がることは滅多にない。特に日本では組織を渡り歩くようなコンバートもほとんど発生しないため、技術者としての力を内外に示す機会がほとんどない。

WBCの戦いの中で岩隈は「松坂さんの登板間隔での準備の仕方、当日の試合前のブルペン、そしてマウンドへ・・・。その背中を見て勉強しました。」といい、ダルビッシュも藤川からクローザーとしての気持ちの持ち方や調整方法について教わったと語った。超一流のアスリートの話ではあるが、スポーツの世界ではここぞという場面で勝ったり負けたりしながら、いろいろなことを学び、自分を成長させる機会がある。

エンジニアにはなかなかそういう機会がない。エンジニアの能力を伸ばし、鍛えるためには、組織がチャレンジする機会、チャレンジしたことに対する評価を与える機会を用意する必要がある。アスリートもエンジニアも生身の人間だから、スキルを身につけるために練習する機会が必要という点は同じだ。もしも、組織がその必要性を認識することができないのなら、職場で上司や先輩がそういう場面を作るしかない。チャレンジした結果、評価がプラスであればなおよいが、マイナス面であってもエンジニアにとっては教訓になるから無駄ではない。

大事なのは遠くの目標を見据えて指導することだろう。スポーツ選手はうまくなるために必ずトレーニングをする。そうしないと生き残れないし、高いスキルを得ることができないからだ。ところがソフトウェアエンジニアはどうだろうか。知識労働者としてトレーニングを積んでいると答えられる者が周りに何人いるだろうか。

忙しいからトレーニング（勉強）する暇がないというのは簡単だ。仕事の中でもトレーニングはできる。ソフトウェア開発の方法論についてわかりやすく書いてある書籍を探し、通勤電車の中で読み、自分の仕事に試してみることはやろうと思えばできる。誰かから指示されていないからやらない、試してみていいといわれていないからやらないというのは自分の深層にプロのエンジニアとしての自覚が育っていないからだ。

WBCなどで世界中から優れた選手が集まって一緒にプレーすれば、自ずとプロ意識は高まる。勝負だからやらなければやられる。エンジニアの世界には勝負はないのか？　そんなことはないだろう。日々ライバル会社と戦っているはずだし、自分との戦いに勝てば組織の中で発言力を高めることもできるし、高見を目指してコンバートも可能だ。出世することが戦いだとは思わないが、ライバル会社に勝る商品を開発してより顧客満足を得ることができれば、それはエンジニアにとっての勝利だと思う。

現在スポーツのトレーニングは根性だけではなく科学的な要素も取り入れられている。システマティックにやらなければ十分な効果がないし、実際にはよいトレーニングを受けるには費用もかかる。

ソフトウェアに関するトレーニングも同じで、根性だけではスキルは身につかない。費用を抑えたいのなら、よい書籍を複数購入して試してみることが効果的だが、トレーナーが横についてくれる訳ではないのでトレーニングを続けるためには精神力が必要になる。野球なら試合に勝ちたいとか、甲子園に出たいとか、WBCで活躍したいとかいった明確な目標を立てやすい。ソフトウェアエンジニアの場合は自分の中で気持ちがくじけてしまわないような目標を立てるのが難しい。

今仕事で困っていることを解決するためのトレーニングをしようというのは直接的でわかりやすいが、この考え方はあまりおすすめしない。身につけた方法論が目的になってしまう危険性があるからだ。目標を持つならWBCで優勝するみたいな大きな目標がいい。イチローのような尊敬できるプレーヤーに相当するエンジニアを超えるといった目標でもいいかもしれない。

ともあれ、ソフトウェアエンジニアもトレーニングをして自分を鍛えることを続けていかないと決して一流にはなれない。ソフトウェアの世界の変容のスピードは速いのでトレーニングを数年間休んでしまうとすぐにおいて行かれてしまう場合もある。（逆に普遍的なスキルを身につけると陳腐化しない）

WBCを見て思ったのは、みんなを満足させるプレーを見せる（＝多くの人を満足させる商品を世に出す）ためには、日々のトレーニングといざ勝負しなければいけないとき※の精神力を磨き続けることが必要なんだということである。

※例えば、顧客満足に背反するような選択をプロジェクトや組織が取ろうとしたときに勇気を持って反対しなければいけないときなど。

P.S.

侍ジャパンを命名した原監督は新渡戸稲造の名著「武士道」を熟読したそうだ。「野球道は武士道に通じる」と語り、選手のあり方についても「誠実、素直、朗らか」をよしとした。エンジニアの方もサムライエンジニアを目指したいものだ。

携帯電話価格の怪

訳あって携帯電話を新規で買うことになった。そのときの話である。最初にお断りしておくが、今回の携帯電話の購入に際して携帯電話のキャリアや販売店、携帯電話のメーカーに対して怒っているわけではない。個人的には不満はなかった。ただ、これって携帯電話の業界に取って本当にいいのだろうかと思っただけだ。

さて、総務省は平成19年の秋に（総務省の通達：携帯電話に係る端末価格と通信料金の区分の明確化に関する携帯電話事業者等への要請）という通達を出した。

携帯電話に係る端末価格と通信料金の区分の明確化について（要請）

　 携帯電話（ＰＨＳ等を含む。）に係る現行の販売モデルにおいては、端末価格と通信料金が一体となっている事案が多数存在し、利用者から見て負担の透明性・公平性が十分確保されているとは言えない状況にある。

　 総務省においては、本日、「モバイルビジネス活性化プラン」を策定・公表し、端末価格と通信料金が一体となっている現行の販売モデルについて、2008年度を目途に、端末価格と通信料金が利用者から見て明確に区分された新料金プラン（利用期間付契約を含む。）を部分導入すべく所要の見直しを図る等の方針を示したところである。

　 ついては、貴社において、上記の趣旨を踏まえ、携帯電話に係る端末価格と通信料金の区分の明確化を図るべく積極的かつ速やかに所要の措置を講じるよう検討することを要請する。

要するに、携帯電話のキャリア各社に対して携帯電話の本当の価格を隠して、使用者の通信費に上乗せし、販売店に販売奨励金を支払うという構図はやめなさいと指導をしたのだ。（携帯ゼロ円のカラクリ）

『三菱電機の携帯電話事業撤退で見えること』の記事に書いたように、このシステムのおかげで日本では機能満載の本当の価格を知ったら購入を躊躇するような高機能携帯電話をホイホイ買うような特殊な環境ができてしまった。日本の携帯市場はガラパゴスと呼ばれている。

グローバルな世界では、$100～$200 クラスのシンプルな携帯電話（例えばノキア製とか）が最もよく売れていると聞く。

総務省の勧告で携帯電話の本当の価格がユーザーの目に明らかになった・・・はずだった。その証拠に今回購入した携帯電話の価格は 42,960円と書かれていた。これが定価だ。

家電などの場合、この定価からいくら引いてくれるのかで、客と販売店は真剣勝負をする。ところが、携帯ショップではこの42,960円を割り引いてくれる気配がまったくない。どの店を見ても同じである。

しかし、24回の分割払いにすると月々の（実質）負担額は600円と書いてある。合計すると14,400円になる。だったら、なぜ、一括払いで 14,400円か、それよりも安い価格で売ってくれないのか？ 一括払いより月賦払いの方が安い世界などあるのか？

このからくりは複数の店で何回か説明を聞いてやっと分かった。結論から言うと、次のようなことだ。

• 一括払いで買う人は 42,960円（定価） を払う。
  
• 分割払いする人も42,960円 の1/24(1,790円) を毎月払う。
• 一括払いする人にも分割払いする人にも携帯キャリアが24ヶ月月額通話料を1,190円割り引いてくれる。（新規購入の場合）
• 分割払いする人は、携帯の購入代金を月々1,790円払うが、月額通話料を1,190円割り引いてくれるので、相殺すると月々の負担は600円になる。

結論からいうと、この携帯電話は定価42,960円だが、実質的に 14,400円 で購入できる。携帯電話のキャリアは携帯電話の代金全額(42，960円)を購入者に成り代わって販売店に立て替え払いする。携帯電話メーカーは42,960円のうち卸価格分を受け取り、販売店はその差額を得る。そして、携帯電話の価格の月額分割支払金を24回払い金利なしで、キャリアがユーザーから徴収するが、月賦払いしている間キャリアやユーザーに対して通話量を割り引く。

かくして、目的の携帯電話が 実質 14,400円 で買えることが分かったものの、最初に 42,960円 を払うことに抵抗を感じた自分は、渋々、携帯電話キャリアの戦略に乗って 月々 600円 を24ヶ月払うことに同意した。

結果的にその携帯電話を 14,400円で買えたのは「安い」と思うので、その点は不満はない。しかし、以下の点で釈然としない。

• 販売店同士の販売競争が起こらない仕組みのように見える。
  
• キャリアが実質的に携帯電話の価格を大幅に値引いてくれているのは嬉しいが、それってユーザーがどこかでそのぶんを負担することになっていないか？

これって日本における携帯電話の異常な高付加価値・高機能マーケットをグローバルマーケットの需要と供給の関係に引き戻すブレーキになっていると思う。携帯電話の本体価格の負担は24ヶ月で終わるため、携帯電話の本体価格負担込みの不当に高い通話料をずっと払い続けることはなくなったが、日本人だけが身分不相応な高価な使わない機能満載の携帯電話を持ち続ける状況は解消できそうにない。

販売契約書をよくよく読むと、購入者は 42,960円 をこつこつと24回の月賦（毎月1,790円)で払うことになっている。しかし、その間、通信料をキャリアが1,190円割り引く。本体価格の負担金 1,790円と通話料の割引1,190円は互いに関連はないという論理だが、関係ないはずはないだろう。

実質的には月々 600円 の支払いとなり、携帯電話の価格は実質 14,400円であるが、あくまでも 携帯電話の価格は 42,960円だといいたいようなのである。

一言で言えば、これはまやかしだ。普通なら高くて買えないもの、普通なら「こんなに高いのなら買うのをやめよう」というものを安く見せかけている。

本当にこれでいいのだろうか。日本の携帯電話市場だけこんな異常な状態にしておいて、日本の携帯電話メーカーは世界で生き残れるのだろうか。世界で売れ筋の携帯電話にもっとも力を入れる携帯電話メーカーが日本で育たなくても本当にいいのだろうか。人ごとながら、心配になった次第だ。（でも、恩恵には預かったので大きな声で文句は言えない）

　

ソフトウェア開発における暗黒面の誘惑

『西洋の真似をするだけというのはそろそろやめよう』の記事に ssw さんから以下のようなコメントをもらった。

初めまして。共感する記事だったので、サムライエンジニアの話も読んでみました。

仰る武士道エンジニアは、私の知る限り多くの場所にいました。しかし、成果を上げる能力を持った誠実なエンジニアほど、業界を去る例が多いように思っています。いくら注意してもバグやトラブルで切腹を余儀なくされる侍に重なって見えないでしょうか？

私も侍エンジニアを目指したいと思いますが、SW風に言う暗黒面の誘惑を断ち切れず、過剰防衛や飛び道具を捨てられません。もうちょっと修行が必要なようです。

面白い記事ありがとうございました。

sswさんの言う「暗黒面の誘惑」はソフトウェアの世界では特に多いように思うので、今回はソフトウェア開発における暗黒面の誘惑について考えてみたい。

ソフトウェア開発は「見えない」とよく言われる。だから「ソフトウェアの見える化」が大事であるとよく言われる。ソフトウェア開発が外から見えない状態ではソフトウェア開発における暗黒面の誘惑を減らすことはできないが、ソフトウェア開発を見えるようにしただけでは暗黒面の誘惑を断ち切ることはできない。

本題に入るまえに、ソフトウェアが原因となった事故とその事故を詳細に調査したナンシー・レブソン教授（現 MIT教授）のことばを見て欲しい。

【放射線治療器 Therac-25 の事故】

1985年～1987年 セラック25による事故。複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者（6名）がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソンらの努力により事故原因が詳細に調査され、レポートが発表された。このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられている。

英文ではあるが次のアドレスからレポートを読むことはできる。

http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

http://sunnyday.mit.edu/papers/therac.pdf

ここでは、事故を調査したナンシー・レブソン教授のいくつかのことばを見ていただきたい。

• どんなに慎重に作ってもソフトウェアは満足できるほどに完璧にはならないため、ソフトウェアがどんな動きをしたときでも、人命に危険が及ばないようにシステムを設計する必要がある。
• ソフトウェアの信頼性をできるだけ高めるのは悪いことではないが、それでソフトウェアが安全になるわけではない。プログラマは要求を満たすようにコードを書くが、要求が正しいとは限らない。事故のほとんどは、プログラミングのエラーではなく、要求が間違っていたり、不完全であったりしたために起きている
• われわれの目標は、だれもがこの経験を生かせるようにすることであり、装置のメーカーや他の人を批判することではない。間違いは、このメーカーにだけ起きたのではなく、残念ながら、安全が最優先されるべきその他のシステムにも、きわめて日常的に起きている。
• いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。

これらをことばを聞いて思うのは、Therac-25 の事故から20年以上たった現在でもソフトウェアに関する問題は何も変わっていない。20年間の間進化したであろうソフトウェアシステム、ソフトウェア開発の方法論はソフトウェアに起因するこのような危険を回避できていないということだ。20年間技術が何も進化していないのはない。いろいろな技法、手法を使ってソフトウェアを作るのは人間であり、ソフトウェアの設計は人間が行っているのであり、安全なソフトウェアはナンシー・レブソン教授が事故調査で痛感した教訓を技術者が十分に理解し、意識し、設計の規範を組織が先輩が後輩に伝承させなければいけないことを20年もたっているのに多くの人が理解していないということである。方法論が先行して、目的が忘れ去られ、結果的にソフトウェアを作っているのが人間であるということが置いて行かれてる。

ナンシー・レブソン教授が残した「いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。」ということばについて考えてみよう。

ソフトウェアに関する問題が起こったときの分析者の問題分析の仕方、分析能力の低さに愕然とすることがある。一番多いどうしようもない指摘の仕方は、ソフトウェアにおける問題が発生したときに、原因を一通り担当技術者に説明させ「そのプログラムは一体誰が作ったのだ」と問いただし、問題の原因をそのプログラマの「うっかりミス」ということで帰結してしまうケースだ。

「プログラマのコーディングミス」。この原因ほど結論づけるのが簡単なものはなく、「プログラマのコーディングミス」が問題の原因であると結論づけるような組織は Therac-25 のような事故を起こす可能性が高い。

「プログラマのコーディングミス」を問題の原因とするのは、問題の分析者がソフトウェア開発の十分な経験を持っていないからだろう。ソフトウェアのことはよく分からないから、誰かのせいにしてしまうのが一番簡単なのだ。品質保証担当は問題の原因を特定し、再発防止策を指示する責務を持つ。だから、ソフトウェア開発の経験を持たず、品質保証についてスキルを高めることを怠っているQA担当は、問題が起こると、原因を聞いても内容がよく分からないから、誰がバグを作り込んだのかを特定し、そのプログラマに何かしらの教育を行うことで再発防止策としようとする。

ナンシー・レブソン教授が言う「事故の原因を一つに特定することは、大きな間違いだ。」を思いっきりやってしまっている。

かなり昔のことだが、ソフトウェアに関する問題が起こったとき原因が「境界値テストが十分でなかった」という報告が現場から上がってきたことがあった。「プログラマのコーディングミス」となっていないだけよいと思うが、「境界値テストを行っているかどうかを水平展開しチェックしろ」というおふれが回ってきた。

「チェックしろ」というのは「うちは境界値テストはやっているのか」という問いに対して「・・・はい、たぶんやっていると思います」という答えでもよしとしてしまうレベルのチェックである。当時、この話しを聞いたときに、組織の上位層はいかにソフトウェアのことをブラックボックスとして見ているのか、ソフトウェアの品質を評価する客観的な指標を持っていないと思った。

境界値テストというのは、システムやサブシステムやソフトウェアユニット（関数やクラス）に対する入力に範囲があったときに、その範囲の最大値や最小値、範囲の外側の入力を与え、期待通りになるかどうかをテストすることだ。

しかし、システムレベルでの入力に比べて、ソフトウェアユニットレベルでの入力値は非常に多いし、入力に対して同じ出力がでるとは限らない場合もある。入力に対して同じ出力がでないのは、外部の関数とグローバルな変数を共有している（外部結合：External coupling または、共有結合：Common coupling) ようなことがあるからだ。組込みソフトウェアの場合、外部の状況をセンシングして、センシングした内容によって、システムの振る舞いを変えることがあるから、出力値が入力データだけで決まるデータ結合になっていない関数やモジュールが少なからずあるのだ。

仮に、データ結合(Data coupling)だけの関係を持つ関数 1000個で構成されるソフトウェアシステムがあったとしよう。1000個の関数に引数がそれぞれ3つずつあったとする。関数一つに対する入力値の境界値テストは最低でも6のテストケースが必要だ。したがって、すべての関数に境界値テストをすると6000のテストケースが必要となる。

「うちは境界値テストはやっているのか」と聞かれたら、「今回開発しているソフトウェアシステムの関数は現在1000であり、それぞれの関数の引数の合計は3000で、各引数に対して取り得る範囲の最大値と最小値の入力テストを実施しています。」と答えるのが回答例となるが、この答えもこのシステムの安全性や信頼性が高いかどうかの根拠として完全ではないと、ベテランのソフトウェア技術者の方なら感じると思う。

そもそも、境界値テストが不十分で問題が起こったのであれば、プロジェクトに対しては「うちは境界値テストはやっているのか」などというミクロな質問をするのではなく、「うちのソフトウェア開発における安全性や信頼性の評価指標は何か？」と聞いた方がいい。この質問に明確に答えられないプロジェクトは、「どうなればソフトウェア品質が確保されている」をいう評価指標を持っていないということだから、日程のプレッシャーに負けて、問題が残ったままのソフトウェアをリリースしてしまう危険性が高い。

※さらっと「ソフトウェア開発における安全性や信頼性の評価指標」を持っていないといけない書いたが、実はその評価指標を確立することは簡単なことではない。評価指標を確立することは非常に難しいし簡単な指標にしてもキチンとできてることを内外に示すのにどんなに苦労することか・・・

もちろん、完璧なソフトウェアを作るために検証を続けていたら、時間がいくらあっても足りないから、どこかでベースラインを切る必要はある。しかし、どこでベースラインを切るか、どうなったら品質が確保されたと言えるのかという評価指標はあらかじめ開発の上流で決めておかなければいけない。

だから、「うちは境界値テストはやっているのか」と聞くのではなく「今回の問題を考えたときに、うちのソフトウェアの開発計画における品質の評価指標を見直す必要はないか？」と問うべきなのだ。

上がこんな感じだと、下は「何か問題が起こっても簡単にごまかせる」と思ってしまう。これが、ソフトウェア開発における暗黒面の誘惑だ。「上はどうせソフトウェアのことなんかこれっぽっちも分かっちゃいないから、適当な理由をつけていい訳しておけば、この場の辛い立場を逃れることができる」と考えてしまう。

「ソフトウェア開発における暗黒面の誘惑」の結果、もっとも悪い台詞はクライアントサイドの場合は「それは○○外注さんのミスです。」「○○外注さんにはきつく言っておきます。」であり、サプライヤーサイドの場合「あんなに納品を急がされたらミスもするよな。」といったものではないだろうか。クライアントサイドの台詞は自分達の問題として受け止めずに、サプライヤーに問題の責任を先送りして、根本的な再発防止策を取っていないから罪は重い。

「ソフトウェア開発における暗黒面の誘惑」をなくすことが難しい理由は、ソフトウェアに関連する問題やその原因、責任をごまかすことが簡単だからだと自分は考えている。

「ソフトウェア開発における暗黒面の誘惑」を断ち切るため是非、次のことを考えて欲しい。

【ソフトウェア開発における暗黒面の誘惑を断ち切る方策】

• 不具合や問題が発生したら正面から向き合い、プロジェクトとして再発を防止するための方策を関係者全員で深く掘り下げて考える。（個人の責任にしない）
• 再発防止策（設計の規範）はプロジェクトが始まる前にメンバ全員で確認し、規範に対する逸脱が見つかったら注意を促す。
• 誰のために、何のためにソフトウェアを作っているのか日々考えておく。
• ソフトウェアの開発フェーズによって気持ちを切り替える。集中的なテストを実施した後、リリース後のソフトウェアの変更に対する責任の重さはとても重いことを忘れない。

「あたたかい人間関係の中のやさしい一員」の日本人には苦手かもしれないが、ソフトウェア開発における暗黒面の誘惑を断ち切るためには、プロジェクトリーダーの「品質を気にする意識」に関するリーダシップが不可欠であることがお分かりいただけると思う。

ここ何回かの記事を読んでいただければお分かりかと思うが、日本のソフトウェア開発はシステムと職人気質の両立が必須の世界であり、どちらかだけに偏っていては大規模、複雑化するソフトウェアを高品質に保つことはできない。ソフトウェアの品質の高さを維持することができなければ、日本の組込み機器は世界で生き残ることはできない。

ソフトウェア開発は「見えない」ことの問題よりも、ソフトウェアの安全性や信頼性について「自分はよく分からない＝見ない、見たくない」とあきらめ、「問題を理解して確信を持って判断すること、責任を取ること」を放棄する人間がたくさんいることの方が本質的な問題であると思う。ソフトウェア開発における暗黒面の誘惑に負けると、暗黒の力に支配されてしまっていることさえ忘れてしまうから怖い。