技術書の現在と未来
2006年3月に『組込みソフトエンジニアを極める』を書いてからはや5年が経過した。このブログ自体、この本の読者と双方向で情報交換をするために書き始めたことを思い出す。
第一回目の投稿は今でもここに残っている。
この本が出版されるまでは自分も技術書の一読者だった。それ以降は技術書の出版や雑誌の編集についてその裏舞台も知ることになる。
読む側の立場だとあまり実感がないと思うが、今技術系の雑誌や本は売れない。技術系だけでなく本や雑誌全体が売れていない。2005年から2010年までの約5年間、ソフトウェア特に組込みソフトの雑誌や本が次々と出版された。今はそのブームは去っている。
製造業自体が大幅な落ち込みを見せている訳ではないので、出版業界が「組込みソフト」というキーワードに踊らされていたのかもしれない。
さて、2006年3月に日経BP社から出版された『組込みソフトエンジニアを極める』は初版の4000部がほぼ市場からなくなりかけたところで、増版はされないことが決定された。
理由は過去一年の売り上げのペースから考えると、増版したときのコストが見合わないという判断からだ。
本は出版するときに出版社がかなりのリスクを背負う。本を少しずつ刷るとコストが高くなるので、技術書なら概ね1000部以上は刷らないといけない。本を印刷するまでに、著者への印税の支払いやイラスト作成代、編集者の人件費等もかかり、印刷費用も数十万円はかかる。紙代、インク代も馬鹿にならない。
そして本の場合、日本では再販制度があるため書店はいくら書籍を仕入れても返品が可能で、倉庫代も出版社が持つことになる。
技術書の場合、1万部も売れればヒットの部類に入り、10万部売れれば大ヒットだ。しかし、それだけ売れても著者はその印税だけではとても食べてはいけない。何しろきちんとした本を作ろうとすると時間と労力がかかるので、まったく割に合わない。
しかも、今の技術者はインターネットから情報を仕入れてしまうので、あまり本や雑誌を買わない。技術系の出版社は非常に苦しい状況に立たされていると思う。
それでいいのかと思うが、これが現実だからしようがない。ちなみに電子出版に未来があるかというと必ずしもそうではないようだ。そこら辺の事情を知りたい方はペーパーバックスの『出版大崩壊 電子書籍の罠』文藝春秋 800円を読んでいただきたい。
読者のみなさんにアドバイスしておきたいのは、これからは絶版になる技術書も増えてくるので、「これはいい本だな」と思ったらためらわずに今かっておいた方がよいということだ。ネット書店だからといって在庫切れが起こらないとは限らない。中古品もネットで流通するようになったが、市場に出回らなくなってくると中古品でも定価の倍以上の値が付くこともある。
ところで、日経BP社から発売された『組込みソフトエンジニアを極める』は絶版になってしまい、Amazonを見ると中古品も品薄状態になりつつある。
もしも、将来この本を読みたいと思う人が現れたときに買えないのは著者としては非常に残念である。そこで、いろいろな方々に協力してもらいこの本を新刊として再出版することになった。
再出版といっても最初に出版した日経BP社にイラストや編集の権利があるため、自分自身のオリジナル原稿と図表をもとにまた編集を一からやり直した。編集は結果的に8ヶ月かかった。
この本や他の技術書に比べても異常とも言えるくらい図が多い。この図をトレースし直すのに時間がかかっている。
編集は、フレデリック・P・ブルックス Jr. の名著『人月の神話』の翻訳者で株式会社エスアイビー・アクセス 社長の富澤 昇氏にお願いした。
タイトルは前とは少し変わって『リアルタイムOSから出発して 組込みソフトエンジニアを極める』とした。理由は、リアルタイムOSのを使った実際の組込み製品のアプリケーションソフトの開発を題材にした本はあまり見たことがないのと、やはり組込みソフトエンジニアはリアルタイムOSから出発して、システムの時間制約をクリアし、大規模システムのアーキテクトもこなせるようになることがキャリアパスの本流ではないかと思ったからである。
前作と『リアルタイムOSから出発して 組込みソフトエンジニアを極める』の違いを示すと次のようになる。
- 一番大きい変更点。価格を買いやすくするために2800円から1800円に変更した。
- ページ数は296ページから260ページに減った。（1ページの文字数が増えた）
- 本の厚みが2/3ほどになった。（紙が薄くなったから。内容は同じ）
- 人物イラストは省いた。
- 5年経過して時代に合わなくなった文言等を修正。
人物イラストは若いエンジニアが成長していく姿をドラマ風に見せるために付けていたのだが、台詞だけでも十分にその雰囲気は伝わるし、やはり技術書なので中身で勝負しようと思い省いた。（イラスト入り外伝はまだ生きているので参考にされたし）
また、若いエンジニアに是非読んでもらいたいという気持ちから2800円だった定価を1800円に下げた。
中身は同じなので前作同様よい評価を得られることを祈っている。
若い技術者の方たちにはもっと本を読みなさいといいたい。もしかすると日本人が日本語で書かれた本を読む時代ではないのかもしれない。英語なら読者の数は一気に増えるので、英語の本を英語のままで読めるようになった方が情報収集の効率はよい。
でも、日本人の気質、日本特有の技術や仕事の進め方は英語の本の中には書かれていることはまれだ。そんな本を書くことを目指している。
ソフトウェアアーキテクチャの改善はなぜ進まないのか
ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ（構造）を改善するということには意味がある。
家が完成してしまうと外面からはどのようなアーキテクチャ（構造）でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。
ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない人には見えない、理解できないからやっかいだ。
ソフトウェアアーキテクチャの改善（＝ソフトウェアプロダクトラインの導入）は組織のトップからおろしていくのであれば、品質面のメリットよりも、コストメリットや開発期間の短縮のメリットが強調されると思う。ただし、改善の実現には一時的にソフトウェア資産の再構築が必要になるため、成果が現れるまでには2〜3回製品を開発するサイクル（1年以上）を回す必要がある。その投資期間をじっと我慢することができれば、その後から劇的な効果が現れる。
日本の組織ではそのようないったん我慢をして後々の利益を取るという判断ができる企業は少ないので、なかなかソフトウェアアーキテクチャの改善に踏み出せない。
そこで考えるのは、プロジェクトやエンジニアにアーキテクチャ改善の重要性を諭して取り組んでもらうというアプローチだ。しかし、それもなかなかうまくいかないケースがあることに気がついてきた。
既存のソフトウェアシステムのアーキテクチャを可視化して問題点を共有しても、思ったより改善に対する気持ちがイマイチ盛り上がらない場合がある。それはそもそも既存のソフトウェアシステムのアーキテクチャ設計を外部の協力会社の技術者に任せているケースだ。建築業界においてハウスメーカーが自社の商品の構造設計を外注することはないと思うが、ソフトウェアの世界ではソフトウェアシステムのアーキテクチャ設計を外部の技術者にゆだねることはよくある。悪い言葉で言えば丸投げだ。
アーキテクトがプロジェクトのメインメンバーの外にいる場合、アーキテクチャの改善は非常にやりにくい。なぜなら、アーキテクチャに問題があることに対してアーキテクトはすぐに理解できるが、プロジェクトのステークホルダには十分に理解できないからだ。協力会社のアーキテクトはアーキテクチャの改善をプロジェクトに進言するということは、これまで納品してきた自分たちのソフトウェアに問題があったことを告げることににもなる。アーキテクチャの改善とはこれまでのソフトウェアシステムの中にある問題点を自ら認め、未来のために一時的な苦労を強いることである。そのためには協力会社のエンジニアを含めたプロジェクト全体で現在のアーキテクチャの問題点について認め合い、目標となるゴールについての認識を一つにしなければいけない。
エンジニア個人としては、アーキテクチャが改善したことでどれくらい自分自身が成長し、仕事が楽になるのか感覚的に分かっていないと改善への第一歩を踏み出せない。
鶏と卵のような関係で、アーキテクチャの改善に必要なトレーニングを与えるのが先か、それともアーキテクチャの改善によるメリットを実感させることが先かは微妙なところだ。前者はメリットが実感できないと学習効果が上がらないし、後者はスキルがないとメリットを実感できないからだ。
日本でソフトウェアアーキテクチャ改善の話題がいまいち盛り上がらないのは、ソフトウェアアーキテクトの存在が組織内で認識されておらず、その職務が不明確で地位が確立していないからではないかと思う。建築業界では建築士という資格によってその地位が認められているが、ソフトウェアの世界では、そのような資格は存在しない。（資格があればいいってもんじゃないが）
ソフトウェアアーキテクチャを改善し、ソフトウェアコンポーネント間の関係がすっきりすると、開発は非常に楽になる。簡単に言えばソフトウェア資産に一切手を入れずにコンポーネントを再利用できるようになるから、資産の再利用のコストは限りなくゼロに近くなる。
かつて作ったソフトウェアの“流用”すると言っておきながら、新規にソフトウェアを開発するのと同じくらいの費用や期間がかかっていることに疑問を持つプロジェクトやクライアントの会社が少ないことに驚きを隠しきれない。ソフトウェアの再利用に成功したことが一度もないから、ソフトウェアはよく分からないが金がかかるものだと思っているのだ。
また、ソフトハウスの経営者としても再利用資産が増えることで工数が削減されることは利益の減少につながるから積極的にアーキテクチャ改善には動かない。しかし、それは発想を変えるべきで、ソフトウェアのアーキテクチャを改善し、再利用性が高まったら、その資産を利用して新たな派生製品を作り、そのアプリケーション開発のための仕事を受注すればよいのだ。前者の考え方は長期的な視点に立てば、コストダウンで開発費を縮小され、少人数で仕事量が増えるから悪循環に陥り、後者は資産の再利用により開発効率が高まるので長い目で見れば好循環につながる。
新しい技術を学びながら、自分のスキルと市場価値が向上し、開発効率が上がって、よりクリエイティブな仕事ができるようになるのに、なぜアーキテクチャの改善に積極的に踏む出そうとするソフトウェアエンジニアが少ないのか自分には理解できない。
その答えの一つは、自分や自分のプロジェクトが作成したソフトウェア再利用資産が他のプロジェクトや他の商品に利用されても、再利用できたことのメリットが表面にでてこないという現実がある。
どんなに自分自身が成長しても、その成果を自分の中だけにとどめておいたのでは自己満足に終わってしまう。組織に認められてこそ、組織貢献を果たすことができ、顧客への貢献につながる。
そんなこんなの問題が山積していることから、ソフトウェアアーキテクチャの改善は難しいのだ。
最後にソフトウェアエンジニアに言いたいのは、これからも続く長いソフトウェアエンジニアのキャリアパスを考えたときに、10年後、20年後に振り返ったら日々忙しくしていた自分しか見えないというのはあまりにも悲しくないかということだ。自分が組織に残したソフトウェア資産やアーキテクチャは「これだ」と言えるようになりたくないのか。一回やってみるとそのありがたみが分かるはずなのに、日々の忙しさを言い訳にして最初の一歩を踏み出せない技術者が多すぎる。
「部下に任せないとダメだ」と考えさせられる一冊（その2）
小倉 広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。
小倉氏は CHAPTER 3 任せる、と伝える の中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。
【CHAPTER 3 「任せる、と伝える」 より引用】
部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。
「給料が上がるわけじゃないないし、だったら面倒だから断ろう」
このように考えるのがごく普通の判断というものだろう。しかし、もし、彼に将来の夢があったならどうだろう。例えば独立して社長になりたい。もしくは他社からスカウトが来るようなプロフェッショナルになりたい。そんな夢があったら、きっと判断は変わるに違いない。
「将来独立するためには、この経験はプラスになる。自己成長のために是非やらせてもらいたい。」そのように答えが変わってくるだろう。
【引用終わり】
小倉氏は組織人事のコンサルタントだったからこう書いているが、この話しはソフトウェアエンジニアにも全く同じように当てはまる。
ソフトウェアの開発効率や品質を高めるためには、高度なスキルを学んだり、自動化のシステムを構築したり、アーキテクチャを見直したり、プロセスを組み直したりするため一時的に仕事量が増える。日々忙しいのなら、さらに忙しくなるということだ。
ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）もそうだが、最初に再利用資産を構築する際には通常の作業よりも1.5倍くらいは軽く工数も時間もかかる。それを乗り越えて「今やろう」と決断できなければ、その先開発が楽になることはない。エンドレスの悪循環が待ち構えている。
エンジニア個人やプロジェクトにスキルアップや新しい取り組みを進言するとき、必ず聞かれるのは「それをやるとどれくらい工数や時間がかかるのか」だ。目先の損得だけで判断されると大抵は辞退される。だからこそ、エンジニアとしての将来の夢を語りたいのだが、なかなか自分自身がエンジニアとしてどう成長したいのかを頭に描いている人はいない。
新人は夢があっていいのだけれど、職場に配置されて1年もたつと、夢を語らなくなる。上記の引用のように、夢のないエンジニアに仕事を任せても成長のスピードが遅い。
本サイトでよく読まれ低r記事「問題解決能力（Problem Solving Skill)：自ら考え行動する力」の「どうせどうせ子ちゃん」や「評論家君」が多く、「問題解決キッズ」が少ないのだ。
小倉氏は、『任せる技術』のなかで「世の中には、明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たないと思う。これまで3万人の管理職に研修や講演をしてきた僕の実感値では、1〜2%がいいところだろう。」と言っている。よって、上司は部下が自分の人生のビジョンを描くお手伝いをする必要があり、そのためには定期的な面談が欠かせないと書いている。
【CHAPTER 3 「任せる、と伝える」 より引用】
■ビジョンなし、なら今に集中
実際に部下と人生のビジョンについて面談するとわかることがある。それは何度質問を繰り返してもビジョンが見つからない部下がたくさんいるということだ。これまで彼らは「ベキ論」に縛られて生きてきた。だから突然、「どうしたい？」「どうなりたい？」と聞かれるとうろたえてしまうのだ。「やりたいことが見つからない」。そういう若者が増えているのだという。では、僕たちは彼らに対してどう接すればよいのだろうか？これまで言ってきたことと矛盾するようだが、僕はその場合は、ムリしてビジョンを描かなくてもいいと思う。今、目の前にある仕事に120%集中するよう導いてあげればいいのではないか。
キャリア・ドリフト理論という考え方がある。キャリアはデザインするものではない。偶然に出会うものだ、という考え方だ。ただし、そのためには条件がある。今、目の前にある仕事に120%集中することだ。「自分には向いていないかもしれない・・・」などと言わずに、その仕事に集中するのだ。そのときに初めて偶然が、幸運が訪れる。
「明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たない」というのは悲しいことだ。そうなっているのは、人生のビジョンを描く訓練をしてこなかったからだと自分は信じたい。「ベキ論」に縛られることなく、やりたいことをやるにはどうしたらいいのかを考え、実行し、ダメだったらなぜそうなったのかを反省するそれを繰り返していけば、人生のビジョンを描けるようになると思う。
本当ならば、それを学生の時代に訓練しておいて欲しいのだが、その訓練をする機会もなく社会で出てしまった人達は大勢いる。
【引用終わり】
だから、上司は部下に仕事を任せなければいけない。
【CHAPTER 3 「任せる、と伝える」 より引用】
■任せる、とういことは、自分の違うやり方に異を唱えないこと
任せた以上は、自分と違うやり方を許容しなくれはならない。
「オレだったらこうするのに・・・」
「そのやり方をすると後で必ず問題が起こるぞ。あ〜。やっちゃった・・・」
そう思ったとしても、部下のやり方に異を唱えてはいけないのだ。失敗することも含めて部下に経験させなくてはならない。それが本当の意味での任せる、ということなのだ。
【引用終わり】
もう一つ、重要な教訓。
【CHAPTER 4 「ギリギリまで力を発揮させる」 より引用】
■相手に矢印を向ける人は成長しない
先にお伝えした通り、上司が持っていた仕事を部下に任せると、部下には大きなストレス負荷がかかる。能力以上の仕事にチャレンジする部下は思い通りにならない仕事にイライラを感じるのだ。これを心理学の言葉では認知的不協和と呼ぶ。これは前にも説明したが、そのイライラを解消する時に常に選択肢は二つある。一つは自分に矢印を向ける方法。つまり、問題の原因を自分にあると考え、自分を変えることで問題を解決しようとするアプローチだ。これを選ぶ部下は成長していく。仕事を任せたかいがある、というものだ。
しかし、もう一つの選択肢を選んだ場合はそうはいかない。それが他人に矢印を向けるという方法だ。
「目標達成できないのは不景気のせい」
「期限内に提出物を出せないのは、仕事の量が多すぎるから」
「チームの目標達成率が低いのは、人員を補充してくれない人事部のせい」そうやって問題をすべて他人のせいにすることで自己正当化する。自分は悪くない、悪いのは他人だ、と言って必死に自分を守るのだ。
当たり前にことではあるが、このタイプの人は成長しない。自分は変わる必要がない。すべては他人が悪いと思っているからだ。
【引用終わり】
相手に矢印を向けずに、「自分に矢印を向ける」ように指導する、これが難しい。どうすればいいかを考えるのも自分の仕事だ。
「部下に任せないとダメだ」と考えさせられる一冊
いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。
【CHAPTER1 ムリを承知で任せる より 引用】
そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。
部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。
【引用終わり】
耳が痛い。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。
小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。
- 部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。
- 部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。
- 部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。
- 部下に教えられるほどにノウハウが整理体系化されていない。
- 口べたであり、うまく部下に教えることができない。
- 部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。
- 仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。
- 部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。
- 上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。
- 部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。
- 部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。
まさに図星だ。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか？」という恐怖が強い。しかし、そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。
「自分がいなくなったら？」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。
【CHAPTER2 ムリをしなければ脳の筋肉はつかない より引用】
「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。なぜ、やりがいがないの？ と聞くと返ってくる答えは2種類に大別される。
1つ目は「今の仕事が自分には向いていない」というものだ。例えば営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。
2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。だからあきらめて転職する、と言うのだ。
僕はその2つを聞くたびにこう思う。
「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。
「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。決して壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。しかし、先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。
【引用終わり】
部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。
【CHAPTER3 部下が失敗する「権利」を奪うな より引用】
失敗が喉の渇きを引き起こす
なぜ人は「任される」と育つのだろうか。
もちろん答えは一つではない。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。
しかし、それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。つまり「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。つまりは、うまくやるための方法という「水」を求めて「喉が渇く」のだ。
そして様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。やがてうまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。そうして全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。
【引用終わり】
この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。また、ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。
さらに、大規模プロジェクトでは自分の作ったソフトウェアに失敗（＝バグ）があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。
自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。
「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。
失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。
コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。もっと、この本を読み進める必要がありそうだ。
「それは仕様です」とは絶対に言ってはいけない
浜岡原発の停止に際して、中部電では「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだとの意見が出ているという。
これを聞いて「ああ、やっぱりそういう考え方をする人はいるのだな」と思った。こういう発言をする人はリスクマネジメントの本質が分かっていない。
リスクに対する保証というと生命保険や損害保険などの金銭的保障がすぐに思う浮かぶが、多くの人の命が関わっている場合、話しはそう簡単ではない。
人の命に関わるようなハザードの発現を、防げるのに防ぐための対策を取っておらず、金銭的な保障で備えるという選択肢はない。
よって想定したリスクに対して、リスクを分析しリスクコントロール手段を講じる必要がある。そのときにリスクコントロール手段によって100%リスクを回避できれば、それに超したことはないが、ほとんどの場合は100%のリスク回避などできないため、リスクコントロール手段によってリスクが受容できるレベルまで軽減されているかどうかを確かめる必要がある。
そこに保証という概念はない。リスクコントロール手段を講じる当事者ではない者は誰も保証などはできない。世の中にはそれが分かっていない人が大勢いる。
例えば、契約書や取扱説明書に禁忌・禁止事項を記載して、それをよく読まずに実行してしまったらそれはユーザーの責任だという人がいる。それは正しいが、現代のリスクマネジメントの考え方からすると正しくない一面もある。
社会通念上ユーザーがやってしまっても不思議ではないことに対して、契約書や取扱説明書に禁忌・禁止事項が記載してあったとしても、事故が起これば機器の製造業者やサービス提供者は社会的責任を求められる。
刑事裁判では勝訴しても、民事裁判では負ける、もしくは裁判には勝っても社会的な制裁を受けて、会社は潰れる。そんな事件は世の中でしょっちゅう起こっている。
さて、リスクコントロール手段によって事故の発生を誰も保証してくれないのならば、どうやってGO か STOP かを判断するのか。
それは一にも二にもリスクコントロール手段にの有効性の根拠による。GO か STOP かを判断した結果ではない、根拠が大事なのだ。
よく、クリティカルデバイスのリスクマネジメントに関する判断で最終的な結果を求めてくるエンジニアがいる、というか、ほとんどがそうなのだが、そういうときは最終判断の案と共に判断の根拠を必ず伝えるようにしている。自分がエンジニアに聞きたいのは、結果を受け入れるかどうかよりも、その根拠に同意するのかしないのかだ。
何も考えずに、結果だけを受けているのだけは絶対やめてくれと常に言っている。大事なのはリスクが軽減できると考える根拠だ。もちろん、客観的な証拠、統計的なデータに裏付けられた根拠に基づいた判断がベストだが、ソフトウェアの場合は障害の特徴がランダムではなくシステマティックでることが多いため、客観的な根拠だけではなく、エンジニアの自信の大きさで判断をすることも少なくない。
冒頭の中部電の「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだという意見は、その観点から考えると保証だけを求めていて、「リスクコントロール手段に対して自分達はまったく自信がありません」と言っているのと同じだ。
本来ならば、「これこれのリスクコントロール手段と根拠となるデータを用意したので、これで判断して欲しい」と言うのは正しい。
リスクが受容できるかどうかは、どんなリスクを想定し、どんなリスクコントロール手段を用意し、どんな根拠によるのかを説明しないといけないのだ。
そして、それは誰も保証はしてくれない。ユーザーが納得するかどうかは機器やサービスを提供する側がどれだけ客観的なデータを使って、自信を持って説明できるかどうかにかかっている。
そのことが分かっていないエンジニアやマネージャが多いと感じる。ある講演で自分は「レビューの席で技術者が“それは仕様です”という台詞を発すると心底むかつく」と言った。
実際そのとおりで、「それは仕様です」という言葉は「私はまったく何も考えていません」と言っているのと同じであり、自分はそういう発言をする者はなぜそうなっているかという根拠を説明できない最低のエンジニアだと思っている。
リスクマネジメントでもまったく同じであり、誰かに保証して欲しいという発言は、自分はリスクコントロールに関して何も考えていませんというと言っているのと同じだから、絶対に言ってはいけないNGワードなのだ。
是正・予防駆動のプロセス改善アプローチ
ソフトウェアの開発をし商品に実装し、その商品を売って対価を得て、最終的にサラリーをもらう。ソフトウェアの一行一行の向こうには、そのソフトウェアを使うユーザー（お客様）がいる。それが医療機器などのクリティカルソフトウェアであった場合、そのソフトウェアは利用者の命を左右する可能性もある。
クリティカルでなくても、危険なエネルギーを制御したり、大切な情報を扱ったり、重要な設備を管理したりするソフトウェアもある。
ようするに職業としてソフトウェア開発に携わっている技術者はユーザーに対して何かしらの責務を負っている。これは、ソフトウェアがハードウェアと違うのは、Systematic Failures/Faults（決定論的原因故障/障害）と呼ばれる障害が多いことだ。Systematic Failures/Faults（決定論的原因故障/障害）は出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
故障や障害がランダムに発生せず、ある複雑な特定のシーケンスを実行すると必ず発生する故障や障害、それがSystematic Failures/Faults（決定論的原因故障/障害）だ。
Systematic Failures/Faults（決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去する。
そして日本人は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去のが苦手だ。
どちからというと、問題が発生した時点で修正し、個人個人が是正・予防する方が得意だ。だから、プロジェクトメンバーが入れ替わらなければ、是正・予防を繰り返すことで設計の規範が醸成され、そのプロジェクトからアウトプットされるソフトウェアの品質は徐々に上がっていく。
ところが、最近ではソフトウェアの開発をどんどんアウトソースしてしまうので、ソフトウェアの委託元では設計の規範どころか設計技術自体が醸成されないし、アウトソース先は人が入れ替わるため、是正・予防を繰り返す方法ではソフトウェアの品質は上がっていかない。
日本人が苦手な、Systematic Failures/Faults（決定論的原因故障/障害）をプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない。
しかし、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャなどは感覚だけは昔のままなので、気がついたら修正し、個人個人が是正・予防するマネージメント以外の成功体験がなく、プロセスアプローチによってソフトウェア品質が高まるというイメージがわかない。
その結果、Systematic Failures/Faults（決定論的原因故障/障害）は増加する一方で、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャはいらだつ。
これが今多くのソフトウェアプロジェクトが抱える悪循環の構図だ。
このままでは、ソフトウェアを使うユーザー（お客様）への責務が果たせない。ではどうすればいいか。
ひとつの解決策として、トップダウンでプロセスアプローチにシフトするのもいいが、日本人の得意な是正・予防で改善を進めるというのはどうだろうか。
問題が起こったら、関係者全員で問題が発生した原因を分析し、どうやったら予防できるのかを考える。これを進めていくと、当然のことながらソフトウェア開発の上流を改善しなければいけないことに気がつく。結局、プロセスアプローチを導入するという結論に至ると思うが、人から押しつけられるのではなく、改善の取り組みの中でプロセスマネージメントの重要性を学ぶ方が日本の技術者には合っていると思う。
問題が起こったときに、エンジニアを責めるのはたやすい。難しいのは問題の原因を分析し、是正、予防し、同じような問題が起こらないようなオペレーションを決断することだ。
結果を批判するだけの評論家はたくさんいるが、未来に起こるかもしれないリスクを皆に知らせ、プロジェクトを止めたり、方向を変えたりするには技術的な裏付けもいるし、何よりも勇気がいる。
ユーザーの顔を思い浮かべて、ユーザーリスクを防止するための決断ができる者こそ、プロジェクトのリーダーとなるべきだと思う。
事故の再発を防止する技術
3月8日の金曜スーパープライム「池上彰くんに教えたい10のニュース」のラストで3月一杯でTVの仕事から離れる池上彰氏が、「自分が生きている間にベルリンの壁が崩れるなどとは思っていなかった。チュニジアのデモからエジプトのムバラク大統領の退陣までこんなに早いとは思わなかった。時代の変化は早くなっている。今流れているニュースはいずれ歴史になる。そういう目でニュースを見なさい。」と言って去って行った。
3月8日は東日本大震災が起こる前だったから、想像もできなかっただろうが、まさに日本で流れているニュースは今後、歴史に刻まれることになる。
そう考えると、今、乗り越えなければならない問題の解決のプロセスは現在だけのことだけではなく、未来から見た歴史になるという意識で対峙しなければいけない。
品質マネージメントの観点から考えたときに、問題が起こったときに重要なのは、同じような問題が起こらないように予防と是正を行うことだ。
品質をマネージメントする技術者はCAPA （Corrective Action and Preventive Action：是正・予防措置）に注力を注がないといけない。問題が起きたときに犯人を見つけて責任を追及することは容易だが、再発防止の取り組みを築き上げるためには技術もいるし、組織的なマネージメントもいる。
再発防止を実現するためには、何よりもまして、同じ問題を起こしたくないという強い意志がエンジニアやマネージャになければいけない。
日々のビジネスシーンでは、QCD（Quality, Cost, Delivery）のうち、コストや納期が品質よりも優先される、優先しろという指示、圧力がかかることが少なくない。真の技術者は製品やサービスにおいて当たり前にできていることの技術、その品質を維持することの難しさをよく知っている。一方、製品やサービスを表面からしか見ていない者は当たり前にできていること＝潜在的な価値の重要性を常に意識することができない。
潜在的価値が意識されるのは、当たり前品質が当たり前でなくなったときだけだ。すなわち当たり前できているはずのことが、できなくなり故障、障害、事故が起きたときに当たり前品質の重要性と、その潜在的価値を支えている技術が十分出なかったことが分かる。
このときに、組織や社会が認識しなければいけないのは、当たり前にできていることの裏にある技術や、どんなリスクを想定し、どんなリスクコントロールをしているのか、していなかったのかというリスク分析である。そして、品質マネージメントのプロセスに従い、CAPA （Corrective Action and Preventive Action：是正・予防措置）を実施する。そのとき、技術者やマネージャは同じ故障、障害、事故を起こさないという強い意志を持たなければいけない。
エンジニアは事態の収拾でホッとするのではなく、再発防止の取り組みに力を注ぎ、組織はQCD（Quality, Cost, Delivery）の Quality を軽視しない、コストや納期を優先させて品質への意識を忘れてはいけないことを心に誓う必要がある。
実際には、Quality, Cost, Delivery の間にはトレードオフの関係があることが多い。納期やコストを優先させると品質が低下する可能性は高い。しかし、技術力によって QCDのバランスを確保することは可能だ。
例えば、商品群のコアとなるソフトウェア資産を抽出し再利用可能な管理ができれば、品質とコストと納期の要求を満たすことはできる。ソフトウェアプロダクトラインの技術だ。このとき、医療機器などのクリティカルデバイスにおいては、機器を取り巻くリスクに対して、そのリスクを受容可能なレベルまで引き下げるリスコントロール手段（設計上の対策）がコア資産に含まれいるとなお、その資産価値は高まる。（コア資産の顕在的価値と潜在的価値の両方を含めることができるとなお良い）
そのソフトウェア資産の安全性や信頼性を高めることに注力を注ぎ、その後何世代にも渡ってコア資産を再利用することができれば、QCD の要求を同時に満たすことができる。
クリティカルデバイスの開発は、失敗や事故との闘いであるとも言える。失敗や事故を再発されないためのノウハウを製品につぎ込み続けることが当たり前品質を高めることにつながる。だから、新規参入が難しいとも言える。ただし、大規模複雑化したソフトウェアの場合、単純に安全装置としてのソフトウェアを追加し続けると、これまで正常に動いていたシステムをデグレードさせてしまうこともあるから注意が必要だ。
ハザードやリスクがどう変化したのか、見落としていたのかを再評価し、リスクコントロール手段を要求としてとらえ、実現するアーキテクチャを設計する。日本人はこの設計上流の分析や設計がとても苦手に見える。試行錯誤で付け足しや修正をするのは得意だが、上流に立ち戻って再設計するのは下手だ。
障害や事故を再発されないという強い気持ちとリスク分析、リスクコントロールのアーキテクチャ設計ができないとないと、障害や事故はまた起こる。気持ちだけでもダメだし、技術力がなくてもダメだ。
そして、是正・予防措置は、気持ちだけでは進まない、組織に品質マネージメントを仕組みを根付かせ、日々前向きな気持ちで回していなければできるものではない。
そして、ジャーナリズムにお願いしたいのは、障害や事故が起きたとき、その後組織が再発防止の取り組みを続けているかどうかを監視することと、今は起こっていないが何かあったら大変なことになる社会インフラ、重要デバイスに問題が起こったらどうなるのかという視点を持ってもらうことだ。
何か起こってから追求するのは誰でもできるが、これから起こるかもしれない障害、事故を防ぐためには経験や知識、幅広い視点が必要になる。ジャーナリズムには事故を未然に防ぐ技術やマネージメントについての報道を期待したい。
