サムライエンジニア再び

年末が近くなるとラジオでは今年一年放送した内容で面白かった話しを流すことが多い。そこで、このブログでもこれまで書いた記事の中で、もう一度思い返したいものを再掲しようと思う。

これまで組織の内外で活動を重ねてきて特に考えさせられるのは、ソフトウェアに関する改善を進めるには人間系の問題を乗り越える、解決する必要があるということだ。技術的な問題よりも人間的な問題の方がハードルが高いことが多い。

そこで思い返したのが、どのようなスタンスで日々を過ごすべきかについて書いた『サムライエンジニア』の記事だ。

人間は弱いものだから、何かしらのよりどころがないと気持ちが折れることがある。折れて肩の力を抜いた方がいいときもあるが、ここは折れてはいけなというときもある。そういうときは自分に負けて流されてはいけないのだ。そういうときが訪れたときはこの『サムライエンジニア』の姿勢を思い出して欲しい。



----- 2008.08.01 『サムライエンジニア』より -----

三冊屋というのが話題だそうだ。一冊ではなく関連のある三冊を束ねて本屋は売って、我々はそれを買って読む。

いろいろなジャンルがある中で、一番人気が次の三冊だという。この三冊の共通する特徴は、「日本を紹介するために書かれた初版が外国語の本」である。三冊合わせて Amazon で買うとちょうど 1533円となり送料が無料になる。

武士道（新渡戸稲造著）
茶の本（岡倉覚三著）
代表的日本人（内村鑑三著）
今は武士道の本を読んでいるが、なんせ新渡戸稲造が生きていたときの時代の本なので言葉が難しい。

まあ、それはそれとして「武士道」を読んでいるうちに、サムライエンジニアという言葉が頭に浮かんできた。サムライエンジニアとは武士道の精神を持ち合わせたエンジニアという意味だ。

自分が考えるサムライエンジニアとは次のような技術者のことだ。（字下げされている部分は『武士道』からの引用）

【義】　サムライエンジニアは義理堅く恩義は忘れない

義理の本来の意味は義務に他ならない。しかして義理という語のできた理由は次の事実からであると、私は思う。すなわち我々の行為、たとえば親に対する行為において、唯一の動機は愛であるべきであるが、そに欠けたる場合、孝を命ずるためには何か他の権威がなければならぬ。そこで人々はこの権威を義理において構成したのである。彼らが義理の権威を形成したことは極めて正当である。何ともなればもし愛が徳行を刺激するほどに強烈に働かない場合には、人は知性に助けを求めねばならない。すなわち人の理性を動かして、正しく行為する必要を知らしめなければならない。

サムライエンジニアは金や権威では動かない。受けた恩義を返すために動く。

【勇】　サムライエンジニアは正しいことを行うときこそ勇気を使う　

勇気は、義のために行われるのでなければ、徳の中に数えられるにほとんど値しない。孔子は『論語』において、その常用の論法に従い消極的に勇の定義を下して、「義を見てならざるは勇なきなり」と説いた。この格言を積極的に言い直せば、「勇とは義（ただ）しき事をなすことなり」である。

サムライエンジニアは組織や上司の命令あっても、コンプライアンスや顧客に不利益となることは行わない。顧客に不利益となることを指示された場合は勇気をもって義のために反論する。

【仁】　サムライエンジニアは仁愛を持って他者に接する　

仁は柔和なる徳であって、母のごとくである。真直なる道義と厳格なる正義とが特に男性的であるとすれば、慈愛は女性的なる柔和さと説得性を持つ。我々は無差別的な愛に溺れることなく、正義と道義をもってこれに塩つくべきことを戒められた。伊達政宗が「義に過ぐれば固くなる、仁に過ぐれば弱くなる」と道破せる格言は、人のしばしば引用するところである。

幸いにも慈愛は美であり、しかも希有ではない。「最も剛毅なる者は柔和なる者は最も柔和なる者であり、愛ある者は勇敢なるものである」とは普遍的に真理である。「武士の情け」という言は、直ちに我が国民の高貴なる情感に訴えた。武士の仁愛が他の人間の仁愛と種別的に異なるわけではない。しかし武士の場合にありては愛は盲目的な衝動ではなく、正義に対して適当なる顧慮を払える愛であり、また単に或る心の状態としてのみではなく、殺生与奪の権力を背後に有する愛だからである。

サムライエンジニアは誠実な隣人に対して仁愛を持って接する。クライアントとサプライヤの関係や上司と部下の関係を利用することはせず、誠実な技術者には立場を越えて協業する。

【礼】　サムライエンジニアは正当なる物事に対して尊敬の念を抱き礼を尽くす

作法の慇懃鄭重（いんぎんていちょう）は日本人の著しき特性として、外人観光者を惹くところである。もし単に良き趣味を損なうことを怖れてなされるに過ぎざる時は、礼儀は貧弱なる徳である。真の礼はこれに反し、他人の感情に対する同情的思いやりの外に現れたるものである。それはまた正当なる事物に対する正当なる尊敬、したがって社会的地位に対する正当なる尊敬を意味する。何となれば社会的地位に対する尊敬を意味する。

サムライエンジニアは高き技術に素直に感動し、その技術を吸収したいと考えるとともに、その技術、その技術を持つ者を尊敬し礼を尽くす。

【誠】　サムライエンジニアは誠実に徹し、嘘をつかない　

真実と誠実なくしては、礼儀は茶番であり芝居である。伊達政宗曰く、「礼に過ぐれば諂い（へつらい）となる」と。「心だに誠の道にかないなば、祈らずとても神や守らん」と戒めし昔の歌人は、ポロニウスを凌駕する。孔子は『中庸』において誠を尊び、これに超自然力を賦与してほとんど神と同視した。曰く、「誠は物の終始なり、誠ならざれば物なし」と。

サムライエンジニアは失敗やリスク、日程の遅れの可能性について嘘をつかない。真実を報告し、問題解決を誠実に遂行する。

-----------

来年もこのブログサイトをチェックしてくださいね。

最近買ったもの

1. ミレニアム１（最近話題のスウェーデンの小説）上下巻 まだ読み始めたところ。名探偵カッレ君のことが出ていてとての懐かしかった。子供の頃、大好きな小説だった。（特にバラ戦争が）

2. 時計バンド

今使っている腕時計は　SEIKO　Spirits　というシリーズのアナログ時計で、入社して何年目かに買ったものをもう20年以上使い続けている。当時確か二万円くらいだったように記憶している。時計自体の特徴は軽く、文字が見やすく、秒針が滑らかに動く。時計バンドは革なので、何年かすると交換する。そして今交換の時期がきたのだ。

3. ポメラ

そして、ちょっと大きな買い物がポメラ。ポメラは文房具で有名な KING JIMが売り出して話題になった電子メモ帳だ。キーボードが折り畳めるのが特長でPCのようなアプリケーションソフトはない代わりに起動が早く、軽い。（370g）



何か思いついたとき、アイディアが浮かんだとき、原稿を書かなければいけないときにPCのキーボードに近いキーボードでテキストをダッと打ち込むことができる。

実は今書いているテキストもポメラで打ち込んでいる。買ったのは二代目のDM20でDM10よりややＬＣＤ画面が大きい。

なかなか快適に打ち込めている。画面に出るフォントがいい感じのフォントを採用している。ＭＳゴシックよりも丸ゴシックに近い柔らかい感じのフォントである。

ポメラを買ったのはラジオで商品紹介していたときに「プロのライターが原稿を書くのに買っている」の一言に、自分もプロのライターと呼ばれたいと思い衝動買いしてしまった。

これまで何か思いついたら手帳に後から読めないような速記録のような字で書き込んでいたのだが、それが果たして電子メモ帳に変わるだろうか。

とりあえず、使い勝手を試す意味でもポメラを使い込んでみたいと思う。

就職氷河期をブレークスルーすための就活作戦

日経ビジネスオンラインの時事深層というコーナーに『6万人の「大学は出たけれど」』という記事が載っていた。

【日経ビジネスオンラインの時事深層　『6万人の「大学は出たけれど」より引用】

「誰でもいいから欲しい」終焉

　厚生労働省の調査によると、来春卒業予定の大学生の就職内定率は、10月1日時点で62.5％と昨年の同じ時期に比べて7.4ポイント低下。3人に1人の就職先が決まっていないことになる。

　ところが、リクルートワークス研究所が調べた大卒者の求人倍率は1.62倍。求職者を求人が上回る状況が続いている。求人倍率が1を切った2000年3月卒業生の採用時でも、同じ時期の内定率は63.6％と、今年よりわずかながらも高かった。

　求人はあるが内定率は低いーー。これは何を意味しているのか。

　日本企業が「質」による学生の選別を強めていることが背景にある。「企業を引っ張っていける優秀な人材しか採らない」ことを示している。

【引用終わり】

ようするに、不景気なので採用側の余裕がなくなり、長い間従業員を抱え込む日本の企業においては、どうせ採るならより後々組織に大きな貢献をする学生だけを採ろうと考えるようになったのだ。

そうなったら、もう競争だ。ここで学生のみなさんにアドバイスしたいのは競争は就活の期間だけではないということだ。

そこで、「もし、自分が超就職氷河期の時代にいる学生だったら、どんな作戦を取るか」について考えてみた。

まずは、企業がどんな人材を欲しているかである。日経ビジネスオンラインの記事を読むとどうも「即戦力」が欲しい訳ではなく、将来組織の幹部になってもおかしくないような人材を採ろうとしているということだ。技術者の場合は、少なくとも技術部長クラス、技術でその部門をリードしていけるような人材ということだろう。

ただし、ソフトウェアエンジニアの場合は技術的に修得しなければいけないことが満載だから、学生が就職試験を受ける時点でそれらの技術を身につけている可能性はほとんどない。

組織内で技術者教育を提供する立場から考えると、学んで欲しいスキルは山のようにある。

• プログラミング言語（C, C++, C#, Java)
• テスティング基礎
• 設計プロセス
• リアルタイムOS
• 状態遷移設計
• 構造化分析・設計
• UMLモデリング
• オブジェクト指向設計
• リファクタリング
• ネットワーク
• データベース
• セキュリティ
• プロジェクトマネジメント

などなど。これらを学生時代に修得しておいてくれというのは無理だし、これらの技術は実際の仕事でどんなフェーズで何をやっているのかをよく見極めながら、現状の問題解決に必要な技術を習得させていかないと身につかないと思っているので、実践に入ってから学習した方がいいものも多いと考えている。

このような状況を考えると採用する学生に求めるものは何かということになる。

ひとつは、その組織が対象としている市場・ドメインに対して強い興味、関心を持っているかどうか、ふたつめは技術をスポンジのようにどんどん吸い込むポテンシャルがあるかどうか、三つ目はそれらの技術を組織内に展開できるかどうかだと思う。

3つめは技術リーダーになれるかどうかという指標なので、まずは置いておいて、ドメインへの関心とポテンシャルがあるかどうかについて考えてみたい。

ドメインへの関心は面接の際に趣味や質問攻勢によってすぐに分かってしまうだろう。面接官は企業ドメインのことを裏事情も含めて学生の何十倍もしっているから、知ったかぶりしてもすぐにばれてしまう。2チャンネルなどで情報を収集しようとしてもそのような薄っぺらい情報でやり合おうとするとかえって墓穴を掘る。となると、学生時代は好きなものをとことん追求するのがいいと思う。自分が熱中したことと、就活先の企業ドメインとの関係性が何かについてだけ抑えておいて、そこを説明し、メインは自分が何に集中したのかについて語るという作戦だ。（何も熱中したことがないのはその時点で難しい）

２つめの技術を吸収するポテンシャルがあるかどうかの判断は、履歴書や面接ではなかなかわからないしアピールするのも難しいと思う。そこで、自分が考えたのは学生時代に自分の成長のブログを作るという作戦だ。

例えば4年制の大学生なら2年～3年になったころから、自分の興味があることに対してどんな取り組みをしてどんな成果があったのかをブログに綴ってみるのだ。毎日でなくても毎週、もしくは月に2～3回でも更新を続け、どんなことに取り組み、どんな成果があったのか、何を反省しつぎに活かしたのかを写真や動画を入れて書いていく。

それって卒論、修論と同じだというかもしれないが、大学の先生の指導が入っていないぶんブログの方がその学生の実力がわかるし、日々の記録だからごまかしやうそ、見栄が効かない。その人の人生や姿勢が見える。

そして、そのブログの URL を人事担当に送るのだ。人事担当は技術のことが分からないから、採用を希望している部門の技術部長クラスあたりに打診するのではないかと思う。自分なら、そのブログをざっと見ればその人がどんな人間でポテンシャルがあるかないかをだいたい判断できると思う。

文章がだんだんうまくなているかどうかも指標の一つになる。ようするに一夜漬けではごまかせないレポートだと思うのだ。

以上、自分の成果をブログに書いて就活に活かすという作戦いかがだろうか？

ちなみに、転職を考える技術者も内部情報を出さずに純粋にどんなスキルを獲得したかを綴るブログを書きためておくと自己アピールに効果があるかもしれない。

『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事も参照されたし。

リスクは装置全体で受容可能なレベルまで下げる

■　リチウムイオン電池の発火を防ぐ新技術、台湾で発明　■

発火や破裂を防ぐ新素材を採用したリチウムイオン電池が、早ければ2010年第1四半期に登場する。（ロイター）

という記事が itmedia のニュースに出ていた。そもそも、リチウムイオン電池は内部でプラス極とマイナス極がショートすると、電池内部の温度が一気に上がり発火したり破裂したりして危ない。よく、ニュースでパソコンから煙が出ているような画像が出ていたりする。リチウムイオン電池のメーカーは両極がショートしないようにくふうするのだか、製造の不良などでまれに事故が起こる。煙がでるのは非常にインパクトがあるので大騒ぎになるし、実際にかなりのエネルギーを内包しているので危ない。

そんな折、この新技術（素材） Stobaは電池のプラス極とマイナス極の間に置かれ、電池の温度がセ氏130度まで達すると 多孔質物質が保護膜に変わり、反応を遮断するという。

【リスクを下げるということ】

ここで考えて欲しいのは、リスクを下げる対策は電気、機械、ソフトどれでもいいということだ。機器を使うユーザーからすればリスクをゼロにしろとは言わないから、どんな方法でもいいのでリスクを許容以下に下げて欲しい。それが電気的対策でも、メカ的対策でも、ソフト的対策でもよい。

ところが、メカ、エレキ、ソフトのそれぞれのエンジニアがそれぞれのチームと密に連携できていないときに事故は起こる。それぞれのチームが他のチームで安全対策をしていると思い込んでしまっているときなどが危ない。

このリチウムイオン電池の発火を防ぐ新技術が仮に世の中に浸透したときのことを考える。仮にある機器のソフトウェアが何かしらの電池ショート時のリスクコントロール手段を実装していたとしよう。次の製品では、この Stoba 技術が採用されるので、ソフトの対策は外してもいいやと考えたとする。しかし、電池は取り外し可能で古い電池とコンパチだったら古いものも使える。

そうなると組み合わせによっては、ソフトウェアで実装したリスクコントロール手段が効かないということになる。事故が起こって初めて「あっ」ということになる。

システムが大きく、複雑になるとこのような複合的な原因によるリスクが増える。これまで、装置全体を把握できるエンジニアがそのリスクを抑えてきた場合、一人で全体を見渡せない状況になってきたら、システマティックにリスクを低減する方法を採用していかなければいけない。

あっちのチームがやってくれていると思うから大丈夫という感覚が、ユーザーを危険にさらすことになるのである。

ソフトウェアが凶器となる日

しばらく前のクローズアップ現代で車が電気自動車になると小さい会社でも簡単に車を作れるようになると言っていた。（10月28日放送 “自動車”激変　現場で何が。スタジオゲスト ：宮内　洋宜：日本総合研究所創発戦略センター研究員）

「簡単に」というのはどうかと思うが、少なくとも新規参入がまったく不可能、設計、製造の実績がなければ相当ハードルが高いという状況ではなくなるようである。

素人考えで想像するに、複雑なエンジン制御がいらなくなり、バッテリとモーター、制動機能とボディと、ソフトウェアがあれば取りあえず動くものが作れるような気がする。ようするに、個々の部品を部品メーカーから調達してつなげ、それらをコントロールするソフトウェアを作れば、車が作れる時代がくるのだ。

クリティカルソフトウェアの開発に携わっている自分としては、この予想される未来に大いなる危険を感じている。なぜなら、そのドメインに長く関わっていない組織が作る、もしくは機器がどんな使われ方をするのかよく知らない外部協力会社に発注したソフトウェアが凶器になる可能性があるからだ。

我々は日々ソフトウェアが制御する機器に囲まれて暮らしている。それらのソフトウェアがまともだからこそ安心して生活することができる。映画ではロボットが突然人間に反旗を翻すシーンがよくあるが、現実には潜在的に埋め込まれていたバグが複雑な条件がそろったことで発現して利用者を危険にさらすことはある。プログラマが悪意を持って不具合を埋め込んだのではなく、未熟な技術者が作ったソフトウェアが意図せずに暴走したか、もしくは熟達した技術者達のが作成したサブシステムを結合したときにシステム全体としては思いも寄らなかった問題が発生するのだ。

大きなエネルギーを扱う機器を作っている組織やエンジニアは、その機器が危ないことを知っており、仮にそこにバグが残留していたとしても、ユーザーリスクが許容できるレベルに抑えるようなソフトウェアのつくりかたをする。例えば、モーターの駆動制御が暴走してコントロールが効かなくなったときに、制動の命令が指示されたら、駆動系の制御を切り離して制動が最優先に動くようなシステムを作る。

モーターチームと制動チームがそれぞれ完璧な仕事をしても、それらを結合したときにどんなユーザーリスクがあるのかを考える分析者がいて、リスクをコントロールする手段を実装しないと、その車は危ない。

安全を確保するには、危険とその危険をコントロール手段の実装を組織が分析してシステマティックにやる方法と、一人一人のエンジニアがエンドユーザーの使用状況を思い浮かべながら品質を作り込む方法と両方がある。

電気自動車の製造に新規参入する人たちはそのどちらのノウハウも持っていない可能性がある。これは間違いなく危ない。ソフトウェアが凶器になる可能性がある。

しかも、事故が起こってもソフトウェアが原因だった場合、どこに問題があったのかを調査するのが難しいし再発防止策を立てるのが簡単ではない。

このような状況にならないようにするための教科書として最初に読むべきは、『セーフウェア 安全・安心なシステムとソフトウェアを目指して』である。この本には、過去にソフトウェアが原因で起こった事故がなぜ起こったのか、どうすれば再発防止できるのかについて書かれている。

この本については『組込みソフトウェアの安全設計』の記事を参照して欲しい。つい最近、原書である Safeware の邦訳本が翔泳社から出版された。本の内容についてはまた後日このブログで掘り下げていきたいと思う。

自分のソフトウェアが搭載されている機器の制御がおかしくなると利用者に危険がある場合、あなたが作ったソフトウェアはいずれ凶器になる日がくる。だから、そうならないための技術を身につける責務があなたにはあるのだ。

　

CAPAができていない組織の先行きは危うい

CAPA （Corrective Action and Preventive Action：是正・予防措置）とは問題が起こったときに再発を防止するための考え方である。

【CAPAのプロセス】

1. 問題点を明らかにする
2. 是正アクションの実行
3. 類似した問題が起こらないようにするための予防アクションの実行
4. 予防アクションのデータによる検証

いたって当たり前のように見えるが、これが組織的にはなかなかできない。日本では「問題点を明らかにする」と「是正アクションの実行」を個人的にやるところまでしかいかないことの方が多いように思う。

組織的に再発を防止するためには「類似した問題が起こらないようにするための予防アクションの実行」と「予防アクションのデータによる検証」が必要だ。CAPAはシステマティックにやらないとうまくいかない。犯人捜し、個人攻撃のような様相を呈するようになると、みんな積極的に動かなくなる。

基本的には問題が起きたらQA（品質保証）担当が、淡々と実施していくのだが、日本人は過度にミスを犯したことを追求したように受け取ってしまうため、次回からは自分が気をつけて類似問題を起こさないようにするだけで、組織的予防処置まで行動が広がらない。

自分のミスをさらしたくないという恥の文化もあってそうさせているのだろう。

しかし、それでは組織的な対応としてはまったくできていない。関係部署がそれぞれの責任のもと、再発防止策を考え、実施し、検証することで、組織内に是正策が定着する。

このブログで欧米発の方法論をそのまま鵜呑みにするのは良くないと言っているが、CAPAは欧米発の考え方でよいシステムだと思う。

でもよくよ見ると CAPA はQC活動、カイゼン活動とよく似ている。最大の違いは、QC活動では問題点を自分達で抽出して、自分達で再発防止策を考え実行する。他のチームにその改善策を押しつけることは基本的にしない。（と思う）

他人から言われたからやる、のではなくあくまでも自浄能力を高めようという精神が根底にあると感じる。

ところが、今ではその自浄能力はすべてのチームにはない。そうなると組織的に問題に取り組み是正予防策を共有する必要がでてくる。責任と権限のもとルールを作ったたり、変えて、そのルールを守っていくということも必要になってくる。

CAPAのしくみがあるのにこれが形骸化している組織は最悪だ。チームには問題が見つかり外部から指摘されたら、本来は「問題を見つけてくれてありがとう」という気持ちで再発防止策に取り組む必要があるのだが、CAPAが形骸化している組織では「ああ、めんどくさい」「早く収束させて仕事に戻りたい」となる。

QC活動、カイゼン活動を普及させて自立的に乗り切る方法と、組織がシステマティックにCAPAを回す方法と現代の日本の組織には両面の活動が求められていると思う。

今起こっている問題を解決することよりも、再発防止に重きを置いている組織の未来は確固たるものがあるように感じるが、是正・予防に力が入っていない組織の先行きは危ういと思う。

　

なぜドキュメントを書かない？

久しぶりに『ジョエル・オン・ソフトウェア』を読んだ。Amazon で調べたら、最近、この本の続編である『モア・ジョエル・オン・ソフトウェア』が出たようだ。

ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。

彼がブログで記事にしたことをまとめた最初の本が『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用（例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等）がふんだんにちりばめられており、読みにくいと言えば読みにくいが、ところどころで「まさにその通り！」と膝を打ちたくなる部分がある。

まずは、『第5章 パート1：なぜわざわざ書く必要があるのか？　やさしい機能仕様』の一節を読んで欲しい。

【ジョエル・オン・ソフトウェア　第5章 パート1：なぜわざわざ書く必要があるのか？　やさしい機能仕様　より引用】

　私の考えでは、ちっぽけではないあらゆるプロジェクト（1週間以上のコーディング、あるいは2人以上のプログラマを要するようなもの）において、仕様書がなければ常に、より多くの時間を費やし、より品質の低いコードを作ることになる。理由はこうだ。

　仕様書の最も重要な役割はプログラムをデザインすることだ。たとえあなたがすべてのコードを1人で書いているのだとしても、純粋に自分自身のためだけに仕様書を書くのだとしても、仕様書を書くという行為自体によって－プログラムがどう機能するか詳細に記述することによって－プログラムを実際にデザインするように強いられるのだ。

－中略－

人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことにあるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせるこてはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになるのだ。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。

　これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くを想定されてるか知るために仕様書を読み、何をテストすればよいのかを理解する。

－中略－

　このコミュケーションは不可欠であり、あなたが仕様書を書いていない場合でも発生するが、その場合は行き当たりばったりに発生することになる。品質保証の人たちがしだいにあれこれとプログラムをいじり回し、そして何か奇妙なことが起きるたびにプログラマを邪魔して、どうなるのが正しいのかについてばかげた質問をする。これがプログラマの生産性を損なうという問題は脇に置いておくとしても、プログラマというのは「正しい答え」ではなく彼らがコードをして書いたことに即して質問に答える傾向がある。だから、品質保証の人たちは仕様に従っているかをテストするのではなく、プログラムの挙動に沿ってそのプログラムをテストすることになってしまうわけで、これは、なんというか、もう少しマシにやれたはずなのだ。

【引用終わり】

機能仕様書を含むソフトウェアドキュメントを書くことがムダである、役に立たない、その時間をプログラミングやデバッグに費やした方がマシだという声を間接的に聞くことがある。間接的にというのは、面と向かっては言わないが品質保証担当がいないときに、開発が遅れていることの理由としてやり場のない怒りに対して、要求されるドキュメントが多いということが開発が遅れる原因だとプロジェクトの内部で愚痴っているのだ。

自分がプロジェクトの遅れの原因にされているソフトウェアドキュメントだったら「それは、濡れ衣だ！」「 プロジェクトの遅れはドキュメントのせいじゃない！」と叫んでいるだろう。ドキュメントはしゃべれないから口をきけない者に問題の原因を押しつけているだけだ。ひどい話だ。

そう思っていたら、『ジョエル・オン・ソフトウェア』に上記のようなことが書いてあった。

ドキュメンテーションという行為はソフトウェアの設計に他ならない。いきなりプログラムを書き始めるのはもっともレベルの低い設計であり、自然言語や図表を使ってソフトウェアドキュメントを作るということがレベルの高い（抽象度の高い）設計行為だ。 Joel Spolsky が語っているドキュメントが必要な一つ目の理由が「ドキュメンテーションはプログラムをデザインすること」なのだが、2つ目の理由であるドキュメントがあることによって各部門とのコミュニケーションを効率的に行えると言う点は同意するものの、日本のソフトウェアプロジェクトでは難しい面があると感じる。

日本の小規模な組込みソフトウェアプロジェクトでは、プログラマが仕様も作成し、マーケティングもテストも品質保証もしなければいけないことが少なくない。品質保証という名が付く担当部門があってそこに担当者がいても実施的なソフトウェアの品質保証作業はプログラマがやっていることもある。

だれからも読まれないドキュメントを作るのは確かに辛い。誰かが読んでくれるから、自分や他の誰かのために役立つからドキュメントを書こうという気になる。

だから自分はレビューがあるときは事前に全部のドキュメントに目を通す。斜め読みするのは得意なので、数十ページのドキュメントでも10分くらいあれば問題点や「よく見てるね」と言われるような質問項目をピックアップすることができる。だから、レビューの数時間前に書類が送られてきてもへっちゃらだ。

的確に問題点や良い点を見つけてレビューで伝え、こういうときには何をチェックする必要があるのかをレクチャーする。時間かけて作ったドキュメントを読んで評価してくれる人がいれば次のドキュメンテーションの動機につながる。日本のソフトウェアプロジェクトがドキュメントを書かない理由のひとつに「誰も読んでくれない」ということがあると思う。

『あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。』という Joel Spolsky の主張はその通りだと思う。

これは個人的な感覚だが、自分はプログラムを書き直してプログラムがきれいになる、アーキテクチャが美しくなるのなら、今のコードを捨てることにぜんぜんためらいがない。（もちろん心に余裕だないとダメだけれど） 自分が作ったコードにきったないところがあって、後で誰かから「あれはないだろ」と言われるのは我慢がならないし、陰でクスクス笑われるのも嫌だ。やはり「いい仕事しているね」と言われたい。

だから、いつも自分がアウトプットした成果物をできるだけ第三者の客観的な目になったつもりで批評し、指摘されそうな部分があったらためらいなく直す。これを繰り返していると「ひとりピアレビュー（セルフレビュー）」ができるようになる。熟練すると質問されそうなことをいくつも想定できるようになるので、成果物をレビューされるときもスムーズな回答ができる。

ひとりピアレビューができるようになるのはそう簡単ではないので、やはりプログラマやソフトウェアエンジニアがモチベーション高く仕事を続けるためには、彼らの仕事を誰かがきちんと見て評価してあげないといけないと思う。成果物をほったらかしにせず、少なくともプログラムを作ったプログラマ以外の誰かが評価してあげることが、ドキュメントの必要性を理解させ、ドキュメントが役に立つことを体感させることにつながると思う。

P.S.

最近、昔作ったソフトウェアのことを聞かれ、10年前の日付が入っているドキュメントとソースコードを提供して再利用されたことがあった。ソースコードではなく、そのソフトウェアの元となる考え方自体が有用だったこともある。3年以上前に作ったソフトウェアだと自然言語で書いたドキュメントやモデルなどがあるととても助かる。こういうことがあると、あの時ドキュメントを作ったり、作らせたりして、キッチリいい仕事しておいて良かったと感じる。

カイゼンの実現にはジャーナリズムが必要

今、政治が面白い。政権が交代し新しい施策・政策が次々と打ち出され改善が進んでいく過程を見るのは心地よいものだ。

組織内でなかなか進まないソフトウェア系のカイゼンをうまく前進させるためのヒントが今の政治に見いだせるのではないかと思った。

そもそもこれまでどうにかボトムアップ＆技術的なアプローチで組織的なカイゼンが実現できないか考えてきた。時間はかかっても実績を積み上げることでボトムアップアプローチでもなんとかなるだろうと思っていたが、なかなか道のりは険しく組織上位層の理解や協力がなければ難しいのではないかという気がしてきた。特に、ソフトウェアの再利用戦略であるソフトウェアプロダクトラインはトップダウンのアプローチが不可欠と言える。

今の民主党の政治の進め方は、まずマニフェストという基本方針・基本計画を記したドキュメントを作成し、それを実現することを宣言し支持を取り付け、トップダウンで具体的な実現の手段を発信するというやり方だ。

何か迷いが生じたときに立ち戻るための基本方針が活動のトップにあるのはとても大事だ。広範囲な施策を講じていけばどこかでA施策とB施策の間に矛盾が生じたり、調整しなければいけなかったりするときが来る。そういうときには基本に立ち戻って何が本質に近いのかを判断しなければならない。

しかし、何よりもこれまでうまくいっていると思うのは情報公開の姿勢だと思う。政府は今、これからやることやろうとしていること、部下に指示したことが何かを特に隠すことなくオープンにしている。問題点があればすぐにマスコミや個人から「問題だ」という情報が発信されるから、行動や発言には基本方針と矛盾がないようにしておかないといけない。また、指示を受けた官庁の職員達は指示の内容がオープンにされてしまっているためサボりたくてもサボれない。ちゃんと仕事しているかどうか常に不特定多数の観客から監視されている。おそらく成果が上がれば観客から「よくやった」と評価もされるだろう。

注目したいのは、この行動や成果の情報をオープンにして議論することを恐れないという点だ。今、組織内の活動で足らないのはこのことではないかと思う。目標を示し、それをリーダーが自分の言葉で語り、活動と活動の成果を逐一公開して議論をする、これが大事なのではないか。

実際の政治の世界で重要なのはジャーナリズムだと思う。複数のジャーナリストが公平な立場でいろいろな確度から施策を分析したり評価したりすることで、その施策が正しいのか、見落としている問題がないのか精査される。施策を実行している者がその情報をフィードバックすれば軌道修正できる。

ちなみに、新聞やテレビを見ている限りジャーナリストの一部は自分の立ち位置をどこにおいていいかという迷いが見られるように思う。これまで政治の世界では見えない部分の闇が必ずあったから、体制に対して批判的な要素を突っついていればジャーナリズムとしてバランスが取れているように見えた。読者、視聴者から見て体制側に日和っているように見られないような記事、報道のスタンスを必ず入れるという習慣が付いてしまっていた。

だから、闇がないアプローチ、発言を次々とされると、突っ込みどころがなくなる。そもそも、闇のある体制に日和っているように見られる心配がなくなったことに気がついていない。突っ込むべきは掲げている目標に賛成なのか反対なのか、賛成ならば目標の実現を阻害する要因は何か、目標実現の陰で不利益を被っているものはいないかという点だ。そういう報道がこれまで体に染みついてしまった習慣で体制に日和っていると感じてしまうジャーナリズムは何でもいいからアラを探そうとする。誰と誰の意見が微妙に違っているとか、裏でこんなことでもめているといったワイドショー的なネタをニュースの枠で取り上げたりする。

ともあれ、情報をオープンにして自由な議論を許容するということがこんなに大事であり、プラスの効果をもたらすのかとこの数週間感じている。もちろん、おおもとの基本計画がしっかりしていて行動がぶれないようにしないと議論も発散してしまうと思うが、トップダウンのメッセージ発信と行動の公開、ディスカッションの誘導がカイゼンに役立つように思う。

そして、意外に大事なのは誰のための活動か、施策かを常に頭に置いた上での賛成や反対のさまざまな意見をオープンに議論するジャーナリズムであり、ソフトウェアのカイゼンの世界でもジャーナリズムは必要なのだと感じている。

このブログも組込みソフトウェアの世界でジャーナリズムの一端を担うことができればいいと思う。

　

P.S.

先の衆議院選の選挙期間中自民、公明両党がインターネット上で展開した、民主党を批判するコマーシャル（ネガティブＣＭ）を見た人のうち６割以上、63.5％が、批判している自公両党に対して逆に「悪い印象を持った」という調査結果がでた。このネガティブCMはラーメン編とプロポーズ編が特にヒット数が多かった。百聞は一見にしかずでまずは YouTube でご覧あれ。

自民党はこららのCMのヒット数が多かったことからプラスの効果があると考え、次々にネットCMを作ったようだが、実は視聴者は面白いので見るけれど、作り手側の悪意に嫌気を感じたということだろう。

ジャーナリズムはただ単に相手をあげつらえばよいという訳ではない。十分な根拠を持った批判が必要だということが分かる。

体調を崩して改めて考える日々の時間の過ごし方

はじめて気管支炎になった。風邪とは違ってなかなか薬が効かず、深く呼吸をすると咳が出そうになるのでそれがストレスになる。タミフルという特効薬があるインフルエンザにかかった方がましだっただろうか。気管支炎が治るには数週間かかることもあるらしい。

なにはともあれ、健康を害するといかに健康であることがありがたいかが身にしみて分かる。そう感じることはこれまで何回かあったが、「喉元過ぎれば熱さを忘れる」で調子がよくなるとすっかり忘れてしまう。

体調が悪いと集中して仕事をすることができない。知的労働力がほとんどを占めている21世紀の社会において知的生産性が低下するのはたいへんなことだ。

そう考えると健康で集中力が高いときにいろいろやっておけばよかったと感じる。貴重な時間をボーッとしていたりテレビを見てしまったりして過ごすのはもったいなし、一日一時間ずつでもやっておけば進んでいただろうという仕事もあった。ちょっとしたマイナスの気持ちが51対49の勝負を「今日はやめておこう」というネガティブな判断に導いてしまう。

生活にメリハリを付けて働くときは働き、休むときは休んだ方がいいのはわかるが、大人になるとプライベートな時間を自己研鑽の目的に使うには誰も束縛してはくれないので、楽な方向に流されないようにしなければいけない。

体調を崩して思うのは、健康管理をキチンとやることも自己管理の範疇なんだなということだ。身体が資本だということは病気になるとよく分かる。

　

品質改善に役立つ注目のツール

2009年8月末に発売される 組込みプレス Vol.16 で『品質改善に役立つ注目のツール』 という特集記事をコーディネイトした。

この記事では ソフトウェア品質診断ツール eXquto と アーキテクチャ分析ツール Lattix の2つのツールを比較している。

記事をコーディネイトするにあたって一番気をつけたのは、ツールを使うユーザーの利益が最大になるように情報を提供するということだ。

ともすればツールの紹介記事は売り手側の都合のよい情報だけが一方的に伝えられツールの弱点や有効に使うためにユーザーサイドが負うべき責務は隠されてしまうことがある。

そこで、今回の記事では、何十万円もするツールの購入は組織に対する投資と位置づけ、なぜ、そのような投資が必要なのかという前提条件について、まず、解説し、次に2つのツールのベンダー及びパートナーに、ツールの特長を紹介してもらい、最終章でツールを現場で有効利用するためのヒントを書いた。

【記事をコーディネイトしようと思ったきっかけ】

eXquto はソフトウェア品質診断ツール、Lattix はアーキテクチャ分析ツールで、どちらも現在あるソフトウェアシステムをよりよくするための道具である。1980年台、1990年台、ソフトウェア工学はどのようにシステムを分析設計するのかに注力を注いできた。リファクタリングという取り組みはあったものの、リファクタリングはどちらかと言えば、プログラマが個人の範疇でソフトウェアを再構築することを指していたと思う。

しかし、組込みソフトウェア開発の現場では、試行錯誤を繰り返しすでに30万行を超え、100万行を超えるようなソフトウェアを作り込んでしまっていた。

経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書によると、平均的な組込みソフト開発のモデルは次のようになる。

• 組込みソフト開発費：1200万円～3000万円
• 使用開発言語：C言語
• システム規模：20～50万行
• 新規開発行数規模：2～5万行

実際のソフトウェア開発では、新しい製品開発であっても20～50万行のソフトウェアをゼロから作ったりはしない。すでにある既存製品の大部分を使い、それらの10%程度のソフトウェアを新規に作成する。

それはかなり泥臭い世界であり、すでに作り込んでしまったぐちゃぐちゃのプログラムも嫌々ながら使い続けなければいけないのだ。形式手法を使って仕様とプログラムの関係の完全性を証明できるような取り組みができるのはほんのひとにぎりの開発に過ぎない。

情報工学の研究者達はこのようなすでに作り込んでしまった相当な規模のソフトウェアをきれいにするというエンジニアリングについて有効な方法論を考えるのが苦手だ。苦手かどうかのバロメータは彼らの研究が現場にどれだけ近いか、現場とともに問題の解決に取り組んでいるかどうかで分かる。

我々は、ソフトウェア開発の現場と研究者の距離が縮まることを待っているほど余裕はない。だから、2000年台は、ツールを使ってすでにあるシステムを分析し、捨てるのか、再構築するのかを判断する基準を作っていく必要がある。

【記事のメイキング】

今回はまず最初に組込みプレス編集部に企画案を提示し、了解を得て、eXquto の開発元である(株)エクスモーションさん販売もとの(株)東陽テクニカと、Lattix の販売元のテクマトリックス株と Lattix を使ったコンサルテーションを実施している イーソル/RCS の双方に記事の企画を打診した。幸い、双方からOKの返事をもらったので、イントロは酒井、eXquto の紹介記事はエクスモーションに、Lattix の紹介記事は テクマトリックスとイーソル/RCS に、まとめを酒井が書くようにした。

イントロでは経済産業省 2008年度版 組込みソフトウェア産業実態調査報告書のデータをもとに、どのような開発で今、何が求められているのか、ソフトウェア開発の効率化、品質向上にはどれくらいの投資がふさわしいのかを書いた。

ツールの紹介はそれぞれに同量のページ数ぶん書いてもらい、比較表は酒井が原案を作って双方に提示し、それぞれ修正を繰り返すことにした。比較表はツール屋さんに取ってはもっともシビアな部分であり結果的に延べ20回の修正を行った。

そしてまとめの部分は、酒井がユーザーの目線でツールを宝の持ち腐れにせず、有効利用するためにはどのような覚悟が必要か、どれくらいツールメーカー、ツールベンダーと真剣に対峙する必要があるのかを書いた。ツールに対する注文も書いたためツールベンダー、ツールメーカーとぎりぎりの調整も行った。

この特集記事の最後に「ツールを宝の持ち腐れにしないためには」について書いたので是非読んでいただきたい。

【品質改善に役立つ注目のツール 第4章 ツールを現場で有効利用するためのヒントより引用】

■ ツールを宝の持ち腐れにしないためには

　この特集記事を読んでいただいているソフトウェアエンジニアのみなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということです。ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身（正確に言えばエンジニアの頭の中）がある状態から別の状態に変わるということなのです。したがって、自分自身が変わる気はさらさらなく、ツールが問題解決のソリューションを提供し、ツールを導入するだけで成果物がよい方向に変化してくれるはずだと考えているとたいてい失敗します。

　ソフトウェア開発を支援するツールには何らかのソリューションが隠蔽されているのは確かです。しかし、利用者はそのソリューションがどんな問題を解決するのに有効であるのか、どのようなケースの問題解決に向いていて、どのようなケースの問題解決は苦手であるのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をツールメーカーやツールベンダーにカスタマイズしてもらったり、改善してもらわないといけないこともあります。

　品質改善に役立てる目的で販売されているツールは、そのツールを使うことで実システムの品質改善やアーキテクチャ改善ができなければ、導入してもまったく意味がありません。今回紹介したツールベンダー、ツールメーカー、コンサルテーション会社は筆者がみな個人的にも付き合いがある会社です。ユーザーサイドが自分のプロジェクトやソフトウェアシステムの改善を本気で取り組もうとしているのならば、彼らも途中で投げ出さずに付き合ってくれることは分かっています。ツールベンダー、ツールメーカーはすべての組込み開発の現場を知っているわけではありません。彼らのセールストークを信じてツールを購入し改善が進まないのなら、何が問題なのかを彼らに伝える義務がユーザーにはあると思います。そのようなユーザーの意見をフィードバックするからこそツールメーカー、ツールベンダー、ツール自体がよりよく進化していくのです。

　ツールを宝の持ち腐れにしないためには、ツールが持っている効果、効能を正確に判断し、長くつきあえる正直なツールメーカー、ツールベンダーを探し、壁にぶち当たっても簡単にあきらめずに、ツールとともに彼らと長くつきあう覚悟で改善を進めることです。それができないプロジェクトや組織はせっかく購入した高価なツールをいずれは放置し腐らせることになります。ツールを選ぶ確かな目を育てるには、失敗の経験を積むことも必要ですが、失敗の経験はできるだけ影響の小さい範囲で積み重ねて、百万円クラスのツール選択では失敗のないようにすることが大事です。

【引用終わり】

見える化、見せる化、そして、見られる化

かつてこのブログで『組込みソフトは「見える化」より「見せる化」』という記事を書いた。「見える化」というのはよくよく考えてみると隠れているものを見せたいのか、見られたいのかはっきりしない。実際の問題を抱えた現場にとって「見える化」ということばはいわばきれい事のように思える。

ソフトウェアの世界で「要求仕様が見えない」「設計思想が見えない」「アーキテクチャが見えない」「インタフェースが見えない」「どこが再利用されているのか見えない」「そのモジュールの開発やバグ取りにどれくらい費用がかかったのか見えない」といった問題が蔓延している。

かつて「見える化」より「見せる化」と言ったのは、プロジェクトサイドがポジティブに見えないものを見えるようにして、悪循環を脱するために踏みだすべきだという意味だった。

しかし、問題を抱えているプロジェクトは必ずしもポジティブであるとは限らない。いや、どちらかと言えばネガティブなことが多い。そういうプロジェクトは「見せる化」どころか「見せないように」「見られないように」さえ振る舞うこともある。苦しい内情を知られてより強いプレッシャーをかけられるよりも、現状を隠して取りあえず今降りかかっている嵐をしのぎたいという心理だ。

ただ、残念ながらこのようなアプローチを繰り返しているとプロジェクトは徐々に疲弊し、モチベーションが下がり、長期の視点で改善の活動ができなくなっていく。

そのようなプロジェクトに対して必要なのは、「見られるのが普通のこと」という状況に持って行くことだ。ソフトウェアエンジニアは誰もがある程度の権限を得ると、自分のやりたいようにプロジェクトを運営したいと思う。その気持ちは、外部から余計なことを言われないように知られたくないことは見えないようにしておこうという行動を誘発する。

そのような状態でプロジェクトを放置していくと、「やってることはやってるんだから、文句は言わせない」という非常にわがままなプロジェクトになってしまう。このようなプロジェクトに対して、問題点を指摘し是正や予防を要求するのはやっかいだ。

解決方法は、プロジェクトに常に「見られていることを意識させること」だ。どのプロジェクトもみな、同じような環境で見られているという意識が広がると、自分達の行動に自覚を持つようになるし、外部からの指摘に過剰反応しなくなる。

そういう意味で「見える化」ということばは、改善を受け入れるか、拒絶するかといった真剣勝負からほど遠い甘っちょろい台詞に聞こえる。「見せる化」は、プロジェクトの「文句あるなら言ってみろ」という自信の現れでもある。そんな自信がないプロジェクトに対しては「見られる化」を定着されなければいけない。

よっぽど強靱な精神力を持ったプロジェクトでなければ、常に見られているということが必要であり、見られているという状態は、自分達の行動に自信を持ち、責任を持つというステージに導くために役立つのである。

ソフトウェアを教える学校

ハリー・ポッターの第６作『ハリー・ポッターと謎のプリンス』を見た。このところ地上波テレビでも旧作を放映していたため、我が家ではちょっとしたハリー・ポッターブームになっている。

ハリー・ポッターを見ていて、ソフトウェアエンジニアもホグワーツのように魔法（ソフトウェア技術）を学ぶ学校が必要かなあ、と思った。

ソフトウェア開発というよりはプログラミングは、こもろうと思えばかなりの部分自分の中にこもって仕事ができる。自分だけの世界の中で自分だけの価値観で突き進み、たまに外界から呼ばれたら「しようがないなあ」とつぶやきながら出て行って「はいはい」と適当に対応して、また自分の世界に戻るという時間の過ごし方も可能だ。

プロジェクトマネージャ、プロダクトマネージャの立場からすると、こういうエンジニアばかりいるととてもやりにくい。Aグループが作ったソフトウェア再利用資産をBグループのメンバーに利用させるとか、AグループとBグループとCグループの共通のインタフェース仕様を共同で策定するなどといった活動がなかなかうまく進まない。

ソフトウェアエンジニアを魔法使いに見立てれば、彼らは魔法使いとしては未熟な部分があり、集団生活、集団学習の中で、設計の規範や再利用の技術や、ソフトウェア工学を学ぶ必要がある。

自分を客観視できるエンジニアは書籍を先生に見立てて、自分自身で教室を開けるので学校にいかなくても、学校に行っているかのような環境を作り出すことができるし、組織内部で教育やトレーニングの環境、システムが整っているところは心配ない。

問題はそのような環境がなく、自分の中に閉じこもろうと思えばそうできてしまうような多くのソフトウェアエンジニアはどうすればいいのかということだ。

社会人が大学院で1年くらい学べるような環境が整っていればいいが、仕事を抱えているとなかなかそうもできない。社外研修やシンポジウムへの参加はできるものの、ホグワーツのような系統だった学習ではなく断片的な知識の習得になりがちた。日科技連などの長期的な学習カリキュラムもあるが、魔法学校のように学習すべき技術が体系化されていないためどれに参加していいのか困ることもある。

産学の間で「教えて欲しいこと」と「教えること」を合意し、将来を期待するソフトウェアエンジニアを定期的に送り出して魔法（技術）を教えてくれるような、ホグワーツのような学校ができないかなあと、ハリー・ポッターのシリーズを見ながら思った次第である。

【ホグワーツのようなソフトウェアエンジニアリング学校の条件】

• 学校の名前に権威があること。
• 優秀な魔法使い（エンジニア）を多数輩出していること。
• 実績のある教師を有していること。
• 実技実習も充実していること。
• 誰もが学びたいと思うような魅力があること。

組込みソフトの現場を垣間見る本

技術評論社から『組込みライフ 知識ゼロから一人前になるためのすべて』という本が出た。

SESSAME関係者も多数出ている。いろいろな組込みソフトの具体的な業務ドメインの一端を垣間見ることができるので、就職を目指す学生や、他の業界が気になる組込みソフトエンジニアにはお勧めの本だ。

この本の概要

デジタル家電（ゲーム機，携帯電話）やAV機器（テレビ，HDD/DVDレコーダ），そして自動車などの「組込みシステム」で世界を走ってきた日本。その技術を支えているエンジニアから学ぶことは多数あります。本書では，これから組込み製品開発をしていきたいと考えている学生や，IT業界からの転職を考えているSEに向け，組込み業界の魅力やそこで働くために大切な要素をわかりやすく解説します。実際に開発現場の第一線で活躍している若手エンジニアたちへのインタビューなどを通して，製品開発のおもしろさを知ることができます。

こんな方におすすめ

• 組込み・制御エンジニアにこれからなろうとしている学生
• IT系から組込み系に転職を考えているエンジニア
• 教育担当者
• 組込み業界のことを知りたいIT系エンジニア

スペシャルインタビュー

• 本田技術研究所
  “好き”からはじまる開発へのこだわり

起業人インタビュー

• 1クリックで世界と繋がる「ネット家電」を目指すCerevoの野望

特集　組込みエンジニアに必要な3つの力

Part 1 技術力

• Chapter1 「技術力」とは
• Chapter2 「組込みシステム」ってなに？
• Chapter3 汎用システムと組込みシステムの違い
• Chapter4 “自信”を与えてくれるモノづくり
• Column 若手エンジニアに聞いた組込み業界の印象

Part 2 価値力

• Chapter 1 「価値を生む」とは
• Chapter 2 技術開発なんか必要ない？
• Chapter 3 モノづくり立志伝・栄光か転落か？
• Chapter 4 売るに時あり―時流と市場

Part 3 人間力

• Chapter 1 「人間力」とは
• Chapter 2 「技術者」としての人間力を磨く
• Chapter 3 「社会人」としての人間力を考える

組込み製品開発ってどんな感じ？

• HDD/DVDレコーダ
• カーナビゲーション
• 内視鏡
• 宇宙システム
• 車載ソフトウェア（ECU）

就活女子大生から“組込み”お父さんへの業界Q&A

• SEってなに？
• 組込みってなに？
• 7Kって言われているけど…
• エンジニアはネクラ？

若手エンジニアインタビュー

ソニー

• ユーザの声を原動力に，より洗練された機能を目指して

京楽産業．

• 妥協を許さず，情熱を形に

東芝情報システム

• エンジニアこそコミュニケーション能力が必要

ZMP

• ロボット技術により，ライフスタイルを楽しく便利に

Let's電子工作 ライントレーサを作って組込み疑似体験

• Chapter1 ライントレーサを作ってみよう
• Chapter2 必要な電子回路を用意する
• Chapter3 電源投入後にマイコンはどのように動くのか
• Chapter4 ソフトウェアの制御方法を考えよう
• Chapter5 入出力ポートを制御しよう
• Chapter6 入力処理で注意事項

アラカルト

• 社員教育受講の苦悩
• メモリ不足で…
• はんだ付けの誤解
• 新人君の理想と先輩のチカラ
• 組込み関連のお勧めWebサイト＆イベント

ユーザー要求の多様化とペルソナ法

『自分の中で失った信頼を一部回復したSONY』の記事に ZACKY さんから以下のようなコメントをもらった。

ZACKY さんは書きました...

お久しぶりです．

起動時間もそうですが，最近思うのが，テレビやHDD レコーダーの電源をオンにするとテレビ番組がいきなり表示されるのに違和感を覚えています．

HDD レコーダーだったら録画リストの方を出してほしいし，テレビでも番組表を先に出してほしいです．いきなり見たくもない騒々しい番組を見せられるのにゲンナリしています．

それから，番号ボタンでチャンネルを切り替える機能，これも僕にとっては要らないです．こんなボタンをつけるぐらいだったら，一発でHDDレコーダーやDVDプレーヤーに切り替えるボタンをつけてほしいです．現状だと入力切り替えボタンを延々と押す必要があります．

顧 客要求については，僕もいろいろと，たとえばペルソナ法を中心に研究している最中ですが，なかなか難しい問題をはらんでいます．難しいと思うのは，顧客の 要望をそのまま機能化するのではなく，顧客の要望を抽象化して使いやすいデザインにする部分だと思いますが，この部分の方法論を探しているところです．も し何か情報をお持ちでしたら，ご教示ください．

ユーザーの要求は多様化している。折しも、本日 25日 社長に就任したトヨタ自動車の豊田章男社長は就任記者会見で、今後の経営指針として「マーケットに軸足を置いた経営」を掲げた。

世界各地域の市場特性に合致した事業展開を目指すもので、地域ごとに「攻めるべき分野と退くべき分野を見定め、経営資源を重点配置する」方針を示した。市場によってはトヨタの特徴でもあった商品の「フルライン」政策を見直すと明言、各地域で「必要十分なラインナップ」にしていくと語った。

このため、新経営体制では日・米・欧および新興諸国地域にそれぞれ副社長を地域責任者として張り付け、現地の実情に即した事業展開を図っていく構えとした。

ユーザー要求が多様化し、ソフトウェアができる範疇でものすごく広くなった。（なってしまった）　だから、「ユーザー要求」だからということで、各方面での要求を機器に入れていくとあっという間に機能満載の使いにくい組込み機器ができあがる。

このことに気がついている日本の組込み機器メーカーはまだそれほど多くないと思う。どんな要求でもユーザー要求を機器に取り込むことができれば、お客さんは満足してくれるはずと思い込んでいる人は驚くほど多い。

そういう人は会社の中で売り上げが上がったとか下がったとか言いながら数字だけを見て毎日を過ごしている。現場を見ていないのだ。ユーザー要求が多様化したのは時代の流れだが、上司が部下に「技術者は現場を見に行け」と檄を飛ばしていたのは昔の話しであり、そう言われてきて偉くなった人たちが、今になって若いマネージャやエンジニアに「商品が使われている現場を見に行け」となぜ言わないのかさっぱり分からない。

さて、ZACKYさんお尋ねのペルソナ法だが、自分の認識では具体的に存在するユーザー像（例えば、東京に住んでいる女子高生など）のプロフィールを定義し、そのユーザーならどんな機能や性能、サービスを欲するだろうかと考えるやり方だと思う。

これは昔のベテランエンジニアならば誰でもやっていたことだ。自分達の製品が使われている現場に行きどんな風に使われているのがじっと観察する。そして、いくつかの現場を見てもっともポピュラーなユーザー像（ペルソナ）を自分の中で想像し、そのユーザーが一番使いやすいと思われる商品を開発する。

ところが、ユーザーの要求が多様化したためエンジニアが想像するユーザー像が欲すると思われる機能や性能、サービスが必ずしもユーザー要求の総意ではなくなってきた。だから、何を作るにしても想定したユーザー像をエンジニアの頭の中の想像にとどめずに、明示しておく必要がでてきた。これがペルソナ法が確立されてきた背景だと思う。なぜ、明示しておく必要があるのか。それは、あるユーザー像を想定した造った商品が売れなかったら、それは想定したユーザー像が間違っていたと考え、より大きな層のユーザー像（ペルソナ）にシフトするための検証材料に使うからだ。

場合によっては、複数のペルソナを想定してそれらの要求に応じて商品の味付けが変わるような工夫をするとよいのかもしれないが、よくよく考えて作らないと、機能満載の使いにくい機械ができあがってしまう。

商品を使うユーザー像を想定するという話しは、トヨタ自動車の新社長 豊田章男氏が「前経営陣までの拡大路線について、前経営陣までの拡大路線について、身の丈を超えていた」と反省し、「今後は地域に合った商品構成に改めるべく、日本、北米、新興国など地域ごとに販売車種を絞り込む」という新戦略を示し、「国内では広告・市場調査を担う新会社を１０年初めにも設立し、消費者の要望や販売現場の意見を、新車開発や生産に反映させる」と語ったことと符合する。

要求が多様化したので、地域によって異なる要求（ペルソナ）別に商品を変えるということだ。何でもかんでも機能を突っ込めばよいと考える時代は終わった。しかし、逆に想定したユーザー像が間違っていたときの傷も大きくなるので、そこは長い年月の間に商品をモデルチェンジしながら、その時代に最適なユーザー像（ペルソナ）を軌道修正していく必要がある。

これまで組込みソフトの世界でこの作業は、商品が使われる現場、パフォーマンスや制約条件、デバイスの特長などの知り尽くしたアーキテクトが担ってきたが、今後はマーケッターやユーザーインタフェースの分析者とともに共同で分析し、分析した結果を目に見える形で残していかなければならない。

P.S.

日科技連のソフトウェア品質研究会でユーザビリティをずっと研究しているグループがある。2006年度の研究論文に『ターゲットユーザを明確にするためのペルソナ手法の実践と課題抽出』というのがあるので参考にしていただきたい。それと、組込みプレス vol.8 で紹介したQFD 品質機能展開も使えるのではないだろうか。「顧客の要望を抽象化して使いやすいデザインにする」というのは具体的には、さまざまな顧客の要求や、市場環境や、他社状況や、ステークホルダの好みなどに優先度付けし、最終的には想定したユーザーへの価値が最大になる点を見つけることだと思う。そのためには QFD が有効だと感じる。

http://www.juse.or.jp/software/study_data2006_4.html

http://gihyo.jp/magazine/kumikomi/archive/2007/vol8

自分の中で失った信頼を一部回復したSONY

定額給付金とエコポイントが出そろったところで、我が家も古くなったブラウン管テレビを地デジ対応の液晶テレビに買い換えた。

これまで使っていたブラウン管テレビは 2003年製の29インチ SONY製のBSデコーダ内蔵テレビ。地デジ対応までのつなぎのつもりで5年ほど前にすでに型落ちになっていたこのテレビを確か5万円台で買った。

あのときはまあ安いからいいやとよく比較もせずに買ったこのブラウン管テレビには買ってから後悔したことがあった。電源を入れてからテレビの画面が表示されるまで12秒もかかる点だ。音声は約3秒ほどで出てくるが画面表示まで12秒もかかるのはせっかちな自分には我慢ならない。

この事実は日本の電機メーカーがカタログスペックに載る機能しか見ておらず、本質的なユーザーニーズを分析できていない典型的な例として、（TVとDVDレコーダーの電源投入に時間がかかるところをビデオに撮って）いろいろな場面で紹介させてもらった。

【これがTVの起動時間の様子】

【これがHD/DVDレコーダにDVDを入れたときの起動時間の様子】

※画面右上のローディングマークが消えるまでの時間に注目

そんな中で、2008年2月に日本ビクターが起動時間を10秒から3秒に短縮した液晶テレビを発売したことをブログで話題にした。『パフォーマンスを商品の価値に置き換えられない日本の企業』

起動時間という「当たり前品質」に相当するユーザー要求を前面に出してきた新しい試みといえる。

一度痛い目にあったら次の買い物では二度と同じ過ちを犯さないのが信条なので新しい液晶テレビを選ぶ際にはかなり慎重に選んだ。

普通なら一度イヤな思いをしたメーカーの同じ分野の商品は買わないのだが、ここ数年ずっといろいろな情報誌等での液晶テレビの評価をリサーチしていて結果的にまた SONY の40インチの液晶テレビを買った。

BRAVIA KDL-40V5 という機種だ。買ってから約一週間たったが、意外や意外本当によくできていると思った。テレビの起動時間は約7秒でストレスをそれほど感じることなく立ち上がり、待機電力を時間帯を指定してあげることでさらに高速起動が可能になる。

SONYだからたぶん OS には Linux を使っているはず。普通ならLinux の起動には30秒くらいはかかる。今や多くのメーカーはハイバネーション機能を使ってOSをゼロから立ち上げることはせず、高速で立ち上がるために必要なメモリの状態をあらかじめハードディスクにコピーしておき、それをダイレクトにメモリに読み出すことで起動時間を早くしている。

だから、この液晶TVも指定したチャンネルの画面は早くでるが、画面表示以外の設定などを電源投入直後に行おうとしても、それは待たされる。すぐにやりたいことと、そうではないことの区別と対応ができている。「そんなこと簡単じゃないか」と思うかもしれないが、設計の初期段階でそのような仕様の選択ができるエンジニアは非常に少ない。ユーザーが何を求めているかを熟知していて、かつ優先度の高い機能や性能と優先度の低い機能や性能を整理できて、優先度の低い機能を勇気を持って切るくらいの決断力が必要になる。

総じて、SONYの液晶TVの何がいいかというとユーザーインタフェースがいい。これは間違いなく、エンジニアが試行錯誤で作り上げた機能仕様ではない。プロのユーザーインタフェースのデザイナーが使い勝手をかなり研究して作った仕様だ。情報家電は機能や性能がよければいいのではなくユーザーに対するサービスがよくないと、より多くの人には受け入れられないし結果的には競争に負けることが家電メーカーにも分かってきたのかもしれない。

【SONY の液晶テレビで感心したこと】

• デフォルトで平均的なユーザーの好みの設定になっている。
• 映像の画質をあえてデフォルトダイナミックにしてスタンダード設定は選択できるようにしている。（ダイナミック設定はとてもくっきりはっきりしている。家電量販店で他社の機種より目立つには有効。どぎついと思ったユーザーはそう感じたときにスタンダードにすればよいという考え方。よく考えていると思う。マーケッターのアドバイスがなければスタンダードをデフォルトにするだろう。）
• いろいろな設定をグルーピングして大まかに好みのグループをユーザーが分かりやすい言葉で選べばよいようにしている。
• 操作に対するレスポンスはストレスを感じないほど改善している。（一年前に買ったHD/DVDレコーダに比べるとその差は歴然）
• 接続する機器やアナログ、地上デジタル、BS、CSのチャネルと選ぶ項目がとてつもなくたくさんになった。これを選択しやすくするために、リモコンのHOMEキーを押すと、縦横の十字の選択インタフェースが表示される。これは非常に分かりやすい。階層を深くすることなく全体の中のどこを選択しているのかが直感的に分かる。（設定メニューの階層が深くで自分がどの位置にいるのか分からない製品は多い）
• 電源投入時間を短縮したいユーザーに対するトレードオフ（消費電力を朝など時間帯を設定して上げることで早くする）を用意している。
• 待機電力を限りなくゼロにしたい人のための主電源スイッチが用意されている。

ちなみに、これだけいろいろなことができ、いろいろな機器を接続できるようになっていると普通なら取扱説明書が相当読みにくくなる。それに関しては SONY はWEBサイトをうまく使っている、購入したTVの取り扱いに関するナビゲーションのサイトが用意してあり、自分がやりたいことを選択していくと、どのような接続、どのようなオプションが必要であるか分かるようになっている。紙の取扱説明書でできないことをWEBサイトを使って上手にナビゲーションしている。

時代は変わった。組込み機器のインタフェースはエンジニアがいろいろな人（ステークホルダ）の言うことを聞きながら試行錯誤で作り込む時代ではなくなった。ユーザーインタフェースはユーザーの使い勝手や市場での競争力が最大になるように、プロのデザイナーが考え実現可能かどうかをエンジニアと詰めていくように変わってきた。この液晶TVを見ている限り、機能が優先され性能が置いて行かれることもなくなったように見える。

ただ、そんな設計を分業でできるのは大企業だけかもしれない。ユーザーインタフェース専任のデザイナーを用意できないような組織ではエンジニアがその役割も担う必要があるのだ。

P.S.

消費電力をブラウン管TVと比較してみたら、29インチのブラウン管TVが130W, 待機電力が 0.07W で、新しく買った40インチの液晶TVが 129W, 待機電力が 0.12W だった。画面が大きくなっているから効率はよくなっているが、絶対値だけ見ると消費電力はほとんど変わらないし、待機電力はアップしている。エコポイントも23,000ポイントもついてものすごくエコに貢献しているように見えるが絶対値で比較すると実は貢献していないというのが現実だ。

個人的にかなり投資もして愛用していた CLIE を市場から撤退したSONYに対する怒りはまだ消えていない。（iPod touch がこれだけ売れているのだから市場はあったはずだ） 一度失った信頼を回復するには時間がかかるのだ。

　

貴重な情報ソースから見る「企業が学生に求める能力」

支援部門にいると組織に動いてもらわなければいけないときに提案書に相当するものを作る必要が出てくる。組織上位層と価値観を共有するためには、プレゼンテーションの資料に次のような内容を入れておくとよいというのもだんだんわかってきた。

1. お金の話し（○○をやらないと損失が大きい、△△をやると利益が上がる）
2. 他社、世の中のトレンドの話し（××社はこんなことやっている、世の中では＊＊が常識）
3. お客さんの話し（ユーザーがこのような不満を持っているから解決する必要がある）
4. 現場の話し（開発の現場では、○○のようなことが起こっており、△△をしないと開発期間が縮まらない）
5. 品質の話し（○○の指標でソフトウェアの品質が低下している。△△をして品質を向上する必要がある）

そんなこんなで、コンサルタントを生業にしている人たちが日頃どんな情報にアンテナを張り、上記のような話しをサッとプレゼン資料に盛り込めるようにしているのか何となく分かってきた。

人や組織を動かすとき、説得に使う情報はかなり重要だ。ソフトウェアのことを詳しく知らない人が財布と権限を握っているケースはハードウェアを扱う組込み系の企業には多い。この人たちを動かしていくには、ソフトウェアのことを相手が分かることばで説明し、かつ、相手の価値観に合わせて「それを今、実行することが必要である」と考えてもらわなければいけない。

そのために必要な情報ソースはいろいろあるが、今回は google でも引っかかりにくいが、かなり役に立ちそうなネタもとを見つけたので紹介しようと思う。

それは、社団法人 日本機械工業連合会（JMF: 日機連）のWEBサイトだ。ソフトウェアとは全く関係ないようでいて、実はそんなことはない。

日機連は、毎年度調査事業を行っており調査事情の報告はPDFで公開されている。工業会の調査報告など対した内容ではないだろうと思うかもしれないが、日機連の調査報告書は価値が高いことに最近気がついた。

その理由は、（推測によると）スポンサーに競輪とオートレースがあることが大きいと踏んでいる。要するに潤沢な資金を持つスポンサーが社会貢献のために日機連を通じて調査事業の費用を肩代わりしているのだ。そして、日機連が窓口になっていろいろなテーマについてさまざまな専門家を集めて200ページ以上の報告書を作成する。

報告書の作成にはその道のプロが仕事を請け負うことが多いが、調査をするのは各種の専門家であり、一般的な講演等では表に出てこない資料が報告書に載ったりすることもある。

試しに、日機連の調査報告書のページで平成15～18年度の報告書について「ソフトウェア」というキーワードで検索をかけてみた。

そこで、まずビビっときたのは『平成1 8 年度サービスロボット運用時の安全確保のためのガイドライン策定に関する調査研究報告書 』だ。普通企業は、ノウハウが少しでも含まれているような資料は一般にプレゼンテーションすることはあっても資料として公開することはめったにない。特許で権利が保護されているといっても、真似されたことを証明するのは困難だからである。

しかし、この報告書では National 屋外用自律走行型掃除ロボット SuiPPI の安全確保の構造について説明された資料がかなりくわしく掲載されている。さらに、滅多に資料が公開されることのない TOYOTA の資料「医療用介助ロボットのロボット運用に向けた安全確保に関するもの」も掲載されている。本業に関するものではなく、未来の事業について企業間を越えてディスカッションした内容だから公開OKとなっているのだろう。（その他 ALSOKのガードロボの情報も載っている）

今回、話題にしたいのは、この報告書のことではなく、『17高度化-13 ものづくり中核人材育成に関する調査研究報告書』のほうだ。ものづくり中核人材育成だから、その中に組込みソフトエンジニアも含まれている。

企業が求めるビジネス基本能力

項目/グループ	大学卒	大学院卒	短期大学卒	専修・専門学校卒
熱意・意欲	71.7	64.0	68.6	66.4
専門知識/研究内容	14.2	34.6	6.3	18.4
協調性	29.6	23.7	43.0	38.4
創造性	15.5	18.5	6.6	8.8
一般教養・教養	5.6	3.3	16.5	10.4
表現力・プレゼンテーション能力	21.5	17.1	14.0	13.6
実務能力	2.1	2.4	19.0	16.0
課題発見力	7.7	10.4	9.1	10.4
問題解決力	15.5	18.5	10.7	10.4
判断力	2.6	1.9	3.3	4.0
（学業以外の）社会体験	1.7	0.5	2.5	0.0
コンピュータ活用能力	1.3	0.9	4.1	4.8
論理的思考力	27.5	29.4	11.6	15.2
行動力・実行力	49.8	40.3	34.7	38.4
国際コミュニケーション能力	7.7	4.7	1.7	0.8
常に新しい知識・能力を学ぼうとする力	16.7	17.1	16.5	16.8
その他	6.9	7.1	10.7	9.6
回答(社数）	233社	211社	121社	125社

このデータ以外にも興味深い情報がたくさん載っているレポートなのだが、まずは是非これを見ていただきたい。企業が学生に求めているものは、「熱意・意欲」「行動力・実行力」「協調性」であり、次いで「論理的思考力」「表現力・プレゼンテーション能力」「常に新しい知識・能力を学ぼうとする力」「問題解決能力」「創造性」だということが分かる。

どこをどう見ても、小・中・高・大という長い14年の教育の中で子供がテストで評価されてきたものではない。本ブログサイト人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』は、おそらく学校では授業で教えていないが、少なくともコンピュータ活用能力よりは期待されている。

先日、NHKのクローズアップ現代で超氷河期と呼ばれる就職最前線で、企業がどのように学生をテストしているのかを紹介していた。テストとか面接とかそんなもんではない。今や、学生は面接で聞かれたときにどう答えると印象がよくなるのかをあらかじめシミュレーションしている。自分に能力があってもなくても、上記のようなことを期待されているのは分かっているから、その期待に添うことができるという回答をきちんと用意している。

そして、企業側も学生がそんな準備をしてきていることを知っているので、面接の受け答えを最重要視はしない。何をやらせるのかというと、例えば営業職ならば、商品の売り込みのロールプレイングをやらせるのだ。「実際に売ってみろ」と突き放し、「現場で問題が起こったとらどう行動するのか」を見るのだ。企業は人材を育成する時間と費用をセーブしたいと考えており、すぐに使える即戦力を欲しがっている。需要より供給の方が大きいから、応募してきた学生の中から、上記の表の能力を潜在的に持っている学生を選ぼうとしているのだ。

学生の方はたまったものではないだろう。テストでよい成績を取り、偏差値で評価されてきた評価指標とはまったく異なる土俵で勝負させらるのだ。

上記の表が示しているのは、画一的に教えられている勉強とは別に、自分で好きなものを見つけ、熱意意欲を持って探求し、問題が起これば課題を発見し、論理的思考力を使って問題を解決し、プレゼンテーション能力を活かして、協調性を持って創造力を使う訓練をしておけということだ。

こんなことができるスーパースチューデントは滅多にいないから、会社に入ってからも、これができるように訓練しておく必要がある。

組織内ではだれもそれが必要なんだよと面と向かって教えてくれないが、全体を見渡せる人が潤沢な資金を使って調査すると、実は組織がどんな人材を求めているのかがわかったりするのだ。

再利用資産を作る勇気

最近、「別製品の過去のソフトウェアを参考にして（とある）機能を実装した」という変更履歴を見た。その行為に対して「同じ機能を実装するのになぜ修正が必要なのか？」「再利用できる資産を使うという解決方法はないのか」という突っ込みを入れる者はプロジェクト内に誰もいない。これこそが、「あたたかい人間関係の中のやさしい一員」の特徴だ。プロジェクトリーダーの承認やプロジェクトメンバーのレビューなしに変更が進められ、誰からも「ちょっと待った」と言われることはない。直近の問題解決が優先され、長期的な改善活動のことは視野には入っていない。

厳しい言い方をすえば、再利用資産を作る技術も勇気もない。コピペして直して動いたら終わり。それを続けることでソフトウェアエンジニアは楽になれるのか？　それとも末端の技術者に問題意識を持てという方がおかしいのか？

それはそのソフトウェア資産の価値と寿命で判断する。価値が高く、寿命が長いソフトウェア再利用資産は技術を駆使し、勇気を持って再構築する。顧客に対する価値がそれほど高くなく寿命が短いソフトウェアは無理して再利用資産にする必要はない。資産化するコストに見合わないことが多い。

価値は高いが寿命が短い、価値はそれほどではないが寿命が長い場合はよく考える。価値は表に出やすい顕在的価値だけでなく、バグがあるとユーザーに多大な不利益が降りかかるような潜在的な価値（当たり前品質）もあるので注意が必要。

ソフトウェア再利用資産を構築しメインテナンスするには技術だけでなく勇気もいる。特にボトムアップで再利用資産を構築するときは自己犠牲を払う覚悟もいる。だから、コピペしてお茶を濁してしまう技術者があちらこちらに出てきてしまう。

日本でソフトウェアの体系的な再利用戦略を実践するには、「開発効率と品質向上の向上」についての現場からの必要性の叫びと、組織的トップダウンの取り組みの両方がかみ合わないと難しい。どちらかだけでもダメだ。一度構築したソフトウェア再利用資産を使い続けるには組織的マネージメントも必要だ。統制が取れていないプロジェクト、組織ではせっかく作成したソフトウェア再利用資産が使われなくなってしまう。実質的にはソフトウェア資産の可視化と、その資産がどれくらい価値があるのかの周知ができなければ、見えにくいソフトウェア資産はすぐに埋もれてしまう。

価値を見えるようにするということがいかに大事かということである。 

　

エンジニアに投資しない組織にいて成長するには

エンジニアに投資しない、投資できない、投資する必要があると考えない組織はそこら中にある。技術者への投資がどのように組織にフィードバックされるのか、人材を育てることに金や労力を使わないと組織がどのようにやせ細ってしまうのかイメージできない人に技術者への投資を提案するとそれにかけた費用に対する効果を説明せよと言われる。そこで「分かってないな」と思うのは当然だが、だからといってエンジニアへの投資をあきらめてはいけない。

ソフトウェアエンジニアは100%知識労働者である。「プログラムコードを何行書いてなんぼ」などと考えていると、すぐに優秀なコンパイラやツールに仕事を奪われてしまう。新しく入っている若い世代のソフトウェアエンジニアが持っていないスキルを常に身につけていかなければいつの日か組織からいらないと言われる日がくる。

組織の中で誰からも計画的なスキルアップの道筋を提示されないエンジニアは辛いが、心配しなくてもいい。ほとんどの技術者がそんなものだ。小・中・高・大おまけに塾では手取足取り何を勉強すればいいのか、次は何に取り組めばいいのか、四六時中先生や親がかまってくれたが、社会人になるとそのようなケアは激減する。そのような環境に計16年もいれは、社会人になっても新人教育のアンケートで「もっと教育を提供してください」「まだまだ教育が足りません」と書いてくるのもうなづける。新入社員研修が終われば、ほとんどの組織では後はOJTで何とかしろと突き放される。ソフトウェアは周りから何やっているのか見えないから、自分で「ここが分かりません」とか「ここはどうやったらいいのでしょう」などと積極的に聞いていかないと、「どれどれ苦労しているようだね」と誰かが声をかけてくれる確率は低い。そして、どんなに未熟な技術者でも何百回も試行錯誤でプログラムをいじくり回していればいずれ動くようになる。実は、それが一番怖い。中身ぐちゃぐちゃで、すべてのテストケースを検証しておらず、爆弾入りのプログラムがひっそりとソフトウェアシステムの中にビルトインされてしまうのだ。

新人の時期を過ぎればソフトウェアエンジニアは教育という側面から見れば孤独だ。それまでの人生と比べてその突き放され感にショックを受ける者もいるだろう。

技術者教育を計画できない、実施できない自転車操業の組織にいて、それは自分が悪いのではなく組織が悪いのだと考えるのは簡単だが、残念ながらそのままほおっておいても何も変わらない。学校や塾のように成績が悪くなると家庭教師を付けてくれたり、「もっと勉強しろ」と尻を叩いてはくれない。ETSSというスキルのものさしでエンジニアのレベルを計測し、それによって弱いところをトレーニングするという取り組みは始まっているが、それができるのはエンジニアに投資できる組織であり、今回と前回の記事の対象外としている。（これを実行するには人・モノ・金がいるから大企業で儲かっていないと難しい）

技術者に投資しない、投資できない組織はたくさんある。そのような組織の中で技術者が何もしないでいると、ソフトウェアに依存する組織の業績はじりじりと下がり技術者に過度な負担がかかるようになる。このような状況でも組織が生きながらえていられるのは次のような原因があると考えられる。

1. ソフトウェアエンジニアの需要が供給を上回っている。（不景気な今もそうだろうか？）
   
2. その組織、そのプロジェクト、その技術者しか知らない、対応できないドメイン知識を持っているから切られる心配がない。（組込みの世界ではよくある話し）
3. 過度な負担（例えば残業月100時間以上とか）に対して技術者がまだ耐えられるレベルにある。

1と3は放っておけばいつかは破綻するときが来る。問題は2だ。2は実際かなりのアドバンテージであり、曖昧な仕様でしか仕事を出せない組織では特に特定の技術者に蓄積されたドメイン知識や経験は重要であり、このような人に頼った製品開発が行われことは多い。しかしながら、そのアドバンテージは永遠には続かない。

製品に使用されるハードウェアデバイスの使いこなし方や商品にまつわるドメイン知識だけで生きながらえているソフトウェアエンジニアは、大規模ソフトウェアシステムを効率的かつ品質高く開発する技術を持ち合わせていないから、いつの日か破綻するときがくる。ドメイン知識と試行錯誤のアプローチで開発できるソフトウェアシステムの規模はだいたい決まっている。自分の経験では実行コード行数で30万行を超えてくると、何かしらのソフトウェアエンジニアリングの技術を使わないと品質を確保できなくなってくる。

よって、どのようなソフトウェアを作っていたとしても、いずれはソフトウェアに関する設計、検証の技術は身につけなければソフトウェアエンジニアに明日はない。日本で今若い人たちがソフトウェア開発技術者に魅力を感じられないのは、自転車操業の組織で試行錯誤のアプローチでしか仕事をしておらずどんどん疲弊していく技術者の噂を耳にするからだろう。

前置きが長くたっぷりと危機感をあおってしまったので、ここからはエンジニアに投資しない組織いて、スキルアップの方策を組織に期待できない場合、どうやって自己投資すればいいのかを考えていきたい。

1. 仕事の中で鍛える

多くの組織がこれ（要するにOJT：On the Job Trainning)で技術者は成長すべきだと考えている。大工の棟梁が弟子を一人前にするという徒弟制度をイメージしてもらえばよい。20年前の組込み機器開発は、メカもエレキもソフトもそうやって技術者は成長してきたし、その経験をしたエンジニアが組織の中でプロジェクトリーダーやプロダクトマネージャや技術部長になっているのだから、そう考えるのは当然といえば当然だろう。

しかし、21世紀の組込み開発において、特にソフトウェア開発において、20年前の徒弟制度的な棟梁と弟子の関係が組織のあちこちで成り立っているだろうか。エンジニアに手取足取り技術を伝承する時間や機会を組織は先輩技術者に与えているだろうか。今ではかなりの割合を占める協力会社のソフトウェア技術者に仕事を丸投げし技術伝承の流れを切ってしまってはいないだろうか。

実際、組織内で伝承するソフトウェア技術が減っている感覚がある。ソフトウェアの世界ではいつの日か技術は伝承するものではなく、技術者が自分で修得するものになってしまったような気がする。

ただ、一部の技術者は自分の仕事の体験から、どうすればうまくいくか、どうすれば失敗しないかという法則を体系化している組織、プロジェクトもある。まったくのゼロからでなくても、書籍や雑誌、友人からのちょっとしたヒントにより有効な方法論を確立できる技術者がわずかながらいる。このように具体的な事象から抽象的な法則（例えば、設計の規範となるコーディングルールの策定や、ソフトウェアシステムをブロック図で表現することなど）を編み出すことのできる技術者はそんなに多くはないがいると思う。こういう改善の気質がある技術者はできるだけ組織の外にもアンテナを張っておいた方が効率がいい。

上記の例では、設計の規範なるコーディングルールのヒントはIPA SEC が副読本としてまとめたものがあるし、ソフトウェアシステムの概観を表す方法としては、構造化分析手法におけるDFDや、オブジェクト指向設計で利用するUMLなどの表記法、ツールがすでに存在している。これらの表記法や分析・設計の方法論は先人が自分たちの経験をもとに構築し、多くの技術者に支持されたものだから、それらに乗っかる、もしくは自組織向けにテーラリングすると、ゼロから構築するよりも早い。

自己投資の必要性を認識したソフトウェアエンジニアが、自己投資の結果をすぐに自分の仕事に結びつけることができればこれに超したことはない。すでにスキルを身につけている先輩や社員が近くにいるのならこれほどラッキーなことはない。スッポンのようにくっついていろいろ教えてもらい技術を盗めばよい。資金がなくても「ありがとうございます」の感謝のことばだけで自己投資できる。「あたたかい人間関係の中のやさしい一員」という特長を持つ日本人の中では、教えを請えば見返りを要求されることなく喜んでいろいろ教えてくれるはずだ。教えた相手がスキルアップしても給料に差が付くようなことはないから安心して技術を教えてくれる。

ちなみに、そのような学ぶべきスキルを持った技術者が近くに見あたらないときは、以降に書く2や3で知識を仕入れて、今の自分の開発に一番役立ちそうなものを上手にピックアップして試してみることが必要になる。このとき、何を持って試してみるかという選択の目がどれだけ肥えているかどうかが成功のカギとなる。ただ、どんなに優れた目利きでも失敗を繰り返して経験を重ねていくので、最初は小さい成功と失敗を積み重ねるように心がけるとよいと思う。いきなり大上段に構えて、高度なことに挑戦するのはやめた方がよいだろう。

2. 本

もっともポピュラーな自己投資の方法は、本や雑誌を読むことだ。ここでは2つだけアドバイスを書いておきたい。一つ目は、問題解決のために買う本や雑誌は同じ分野の違う視点の本を2冊以上用意するということ。ソフトウェア工学は自然科学とは違うので一つの方法が普遍的にどの開発にもどの時代でも効果があるとは限らない。そのことを忘れずに、実際の問題解決に適用する際の可能性の幅を広げる意味でも同じテーマに対して別々の視点があることを認識することは重要だと思う。一冊本命の本を買って、もう一冊は図書館で借りるというのもよいかもしれない。

二つ目は、本や雑誌に書いてあることを、どんな形でもいいから必ず自分の仕事の中で使ってみるということだ。これをしないのなら自己投資ではなく、単なる読書だと思った方がいい。問題解決のために本や雑誌を使わないのなら自己投資の意味がない。流行の手法が解説されている本や雑誌を読んだだけなら、それは単なる自己満足に過ぎない。「○○について書かれた本を読んているのはウチの中では自分くらいだろう」などと思っているだけでは何も解決しない。評論家くんにはなれても問題解決キッズにはなれない。（『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事参照）

本や雑誌を買う行為を常日頃、自分が抱えている問題を解決するための自己投資だと考えているとだんだん目が肥えてきて、自分にとって使えない本や雑誌には手を出さなくなる。無駄な投資が減る。仮に購入した本を参考に自分の仕事に適用してうまくいかなかったら投資に失敗したと考えれば、次回は同じ失敗を繰り返さないようになる。本や雑誌の購入が自分に向けての大切な自己投資だと考えていると、投資に成功したときの本と失敗したときの本の違いが見えてくるはずだ。

本や雑誌の書き手側からすると、そういう読者が増えるとライター側もどんどん淘汰されてスキルが上がっていくので、読み手と書き手の両方が切磋琢磨して成長できるのだ。（消費者の目が厳しい市場では技術が成長する）

3. コミュニティに参加する

1で自分の身の回りに高いスキルを持った人がいないときは、自分が抱える問題を共有しているであろう人が集まっているコミュニティを探して、そこに積極的に参加するのも手だ。その中に解決する手段を知っている、解決した実績を持っている人がいる確率が高い。

時間がなかな取れない上に余計な仕事をもらってしまうのがイヤとか、どんな人がいるのか分からないから恐いとか、自組織が認めてくれないという理由で尻込みしているのなら、コミュニティへの参加は自己投資だと考えればよい。2と同じで自己投資にならないと分かったら、あまり迷わずにコミュニティを去ればいい。コミュニティは無理に留まる義務はないところが会社組織とは異なる。

ただ、遊びの集まりではないから、何かしらのタスク、ミッションはこなす必要がある。それらが、自分自身の仕事や問題解決に少しでも役立つと思うのならポジティブにこなしていけば必ずスキルアップにつながる。

例えば、自分はSESSAMEで、WEBサイトの構築を買って出たり、ワークショップのレポートを書いたり、e-Learning コンテンツを開発したりして、結果的にそれらを訓練することになり技術が身についた。一見ソフトウェア開発にはまったく関係ないような事ばかりだが、自組織においてそれらの技術はとても役立っている。

座談会や講演を録音したテープを文字に起こすような作業は誰もがやりたくないと思うかもしれないが、その内容に興味があったり、自分の勉強のネタだったりすると繰り返し聞くことで話している内容が頭の中に刻みこまれていく。

下働きみたいな仕事でも、その中から何か役に立つものを盗んでやろうという目を持っていると、決してその時間は無駄にはならないのである。

さてこれまで紹介した1,2,3の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。

でも少ない自己投資でスキルアップという効果を得る醍醐味を一度味わうことができると、問題解決のスキルはどんどん上がる。問題解決のスキルが上がると、自分の仕事を効率化したり、品質を高めたり、より評価の高い組織に移籍するなどいろいろな選択肢を選べるようになる。

自分に取ってどんな自己投資が効果的かこれを期に考えてみて欲しい。

　

組織はソフトウェアエンジニアに投資できるか

このブログで、日本のソフトウェア技術者は試行錯誤的アプローチで組込みシステムのソフトウェアを作ってきたと書いてきた。それでも組込み機器の品質が保たれているのは、日本人に特有の「あたたかい人間関係の中のやさしい一員」という性質と職人気質、そして品質を心配する強い意識があるからだとも書いてきた。

これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢（高収入を求めずにオーバーワークに耐えるということ）しているからまだ破綻していないのであって、システムソフトウェアの規模が増大（例えば実行コード行数ベースで30万行を超えるような規模）し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込みソフトウェアの品質と開発効率が著しく低下し始めるはずだ。

もしも、ソフトウェアに関してどうにもならなくなってしまったら、組織はこの状況を打開するためにソフトウェア開発に対して何らかの投資をするしかない。今回は組織がソフトウェア開発（実際にはソフトウェア技術者教育）に投資できるかできないかの境界について考えてみたい。ソフトウェア開発に関して悪循環が始まっているかどうかの指標は、組織がアウトプットしているソフトウェアが結果的に利益を生んでいるかどうかで簡易的に判断できる。どのプロジェクトも利益を出せていないのなら、悪循環のフェーズに入っていると考えられる。利益が出ている商品、製品、プロジェクトと利益がでていない商品、製品、プロジェクトが混在している場合は必ずしも悪循環のフェーズに入っているとは言えない。

何はともあれ、ソフトウェアエンジニアという末端の立場から離れて、自分が経営者になったつもりでこの後の記事を読んでいただきたい。

なお、ソフトウェアは毎日のソフトウェアの活動で構築される。ツールにノウハウを隠蔽することはできるが、ツールを使いこなせるようにするにはトレーニングが必要になるから、結局はソフトウェアエンジニアに対する教育やマネージメント、インフラに対して投資をしなければ、ソフトウェアの品質や開発効率は上がらない。そう考えると、よっぽどの裏技を使わない限り、ソフトウェア開発に対して何らかの投資をしない組織のソフトウェア品質と開発効率は上がらない。

そして、プロジェクトマネージャーより上の立場の者は、まずは、ソフトウェアエンジニアに対する投資を組織からどうやって引き出すかについて考え、それが無理だと分かったとき、もしくは自分自身がエンジニアに投資を進言する立場にない場合は、組織を見限るか、それとも組織に留まって、どれくらい自己投資できるかどうかという方向に考えを切り替えるべきだと思う。

【組織がソフトウェアエンジニアに投資できるかどうかの境界】

1. 儲かっている会社は投資できる

当たり前だが、潤沢に利益を出している会社はソフトウェア技術者教育やツール、インフラ整備、プロセス構築、技術コンサルの導入などに投資できる。人を動かすだけで一見投資が必要ないように見える社内コンサルのような支援部隊を組織するような場合でも、人材を外から引き抜くのにお金がかかったり、現場から人材を外すことで工数の穴埋めをしなければいけなかったりするから投資は必要だ。

儲かっている会社はいろいろな手を打つ選択肢がある。ただ、気をつけなければいけないのは、ソフトウェアに関する投資ははっきりとした効果が見えにくいから、投資が役に立たなかったとしても口先だけで継続的に組織からお金を引き出そうとする人たちもいるということだ。

でも、儲かっている会社はある程度の無駄をしても原資があれば、何かしらの手を打ち続けることはできる。現在のように不況に陥ってしまうと、儲かっていた会社も利益が減ってしまい、ソフトウェア開発に対する投資を絞ってしまう傾向はあるだろう。

2. 儲かっていない組織でも技術者への評価に差を付けることで投資はできる。

利益がそれほどない組織でも、ソフトウェア開発に投資する意志とある程度の金（例えばソフトウェアエンジニア一人に対して年間最低10万円以上）を捻出できれば、新入社員や将来有望な技術者、今後、利益を生むアーキテクチャ（再利用資産を構築できるアーキテクチャ）を設計できるアーキテクトに対して集中的に投資するという方法はある。

アメリカではプログラム言語の書き方を知っている程度のスキルのエントリーレベルのソフトウェアエンジニアの年収は200万円以下だと聞いたことがある。そこから、スキルがアップするにつれて年収が上がっていく。日本も同じようにスキルがゼロに近い新入社員への報酬を減らしたら、優秀な技術者への投資分の数十万円/人くらいは出せるだろう。

しかし、このやり方は日本人にはなじまない。日本では長い間その組織、業務を経験させ、その時間の中で成長させるというところが多い。あえてこれを教育と呼ばないのは、組織的な戦略を持たずに現場に任せきりで、日々の業務をやらせているだけで技術を引き上げようという意志を持っているプロジェクトは多くないと感じているからだ。だから、組織が意識的に取り組む「投資」とOJTという名の実際には何もしていない状態は分けて考えている。

逆に、新入社員こそ組織として投資しやすい対象であるというのが日本の特徴だ。もっと、やってくれと言われることはあっても新入社員ばかり金をかけて不公平だという中堅、ベテランエンジニアはほとんどいない。

ソフトウェアエンジニアの中に年功序列ではなく、スキルの高さによって評価に差をつけて、実際にサラリーに差をつけて、そこから投資の費用を捻出するという方法は、よっぽど組織の上位層に強い意志と決断があって、目指すべきゴールがはっきりしていないとできるものではないと感じる。

なぜなら、日本人の「あたたかい人間関係の中のやさしい一員」という性質は人と人に差を付けるというのをいやがるからだ。自分もあまり好きではない。テストの点数で評価している訳ではないから、何をもって投資対象として選択されたのかについて技術者の中に疑念が生じると「あたたかい人間関係の中のやさしい一員」という性質を活かすことができない。

だから、技術者に格差を付けて集中的に投資する方法は日本の組織ではなじまない。

3. 自分で自分に投資する

組織がソフトウェアエンジニアに投資しない、選択的でも投資できないのなら、自分で自分に投資するしかない。お金をかけようとかけまいと冒頭のような状況でエンジニアに対して投資する気がないのなら悪循環からは決して抜けられない。（誰かがスキルアップするトレーニングを自分に提供してくれる筈だと考えるのは、そうならなかったときにスキルアップできないのは人のせいだと考え自己努力しなくなってしまうから危険だ）

自分自身の投資の仕方については次回の記事に回すとして、もしも、自己投資に成功してスキルアップした時に起きる問題について触れておこう。

何らかの投資の結果、自分のスキルが向上しソフトウェアの開発効率や品質をアップできるようになるとどうなるか。そもそも、組織が投資してくれないので自己投資しているのだから、スキルアップが成功したとしても、組織貢献を明確に示すことができないのなら、組織からの評価を期待することはできない。

自分のお金や時間でスキルアップして、組織貢献を実現できたのに評価されないかもしれないのだ。評価されないどころか、スキルアップして開発効率や品質向上を実現してできた余裕につけ込まれて他人の開発効率や品質の悪いソフトウェアを何とかする仕事を回されてしまう危険性さえある。

これはやりきれない。頑張ってスキルアップした技術者の努力が報われない社会、業界が発展する訳がない。

でも、現実はこんなもんだ。だから、頑張ってスキルアップできた技術者はその組織で報われないことが分かったとき、例えば組織を出てコンサルタントになり、1 の儲かって利益を出せている会社を助ける側に回ることになる。

そうなると、成長した技術者が去ってしまった組織が潤沢な利益を出せていなかった場合は、さらにソフトウェアの開発効率が悪くなり、品質も悪化し、残った技術者が残業することでしか対応できなくなる。

この論理だと、ソフトウェアエンジニアは自己投資でスキルアップしても報われないから、自己投資しないでじっとしていた方がいいのかということになってしまう。

そんな筈はないから、こう考えるしかないと思う。

組織がエンジニアに投資をしないのなら、エンジニアは自己投資してスキルを上げ、スキルアップしたことでソフトウェアの開発効率と品質を高め、顧客満足が高まったことに対して満足を感じるようにする。顧客満足を高めたことで自分のモチベーションを保ち、顧客満足を高めることに貢献したことを組織に示し評価を得、同じことを他の技術者もできるようにするには投資が必要であると説く。

4.  ソフトウェア開発やソフトウェアエンジニアに投資しないという選択

組織がソフトウェア開発に投資しない、技術者も自己投資しないとう選択肢はないのか。ないことはない。以下のようなケースが考えられる。

a) 投資せずに技術者に負担を強いる。

b) ソフトウェア部品を外から買い自組織では作らない。（サプライやにaを強いるか、逆にソフトウェア部品の価格をつり上げられるという問題あり）

c) 安い海外の労働力にシフトする。（「あたたかい人間関係の中のやさしい一員」という特性は使えない）

d) ソフトウェアでは勝負せず、真似できないハードウェア技術で勝負する。

以上、組織もエンジニアに投資を行い、エンジニアも自分自身に投資をし、投資の結果、ソフトウェアの開発効率と品質が上がり、顧客満足が高まり、それが自己満足につながって、組織にもその成果を認めエンジニアを評価し、投資の効果を確認するのが一番いい。それができないのならソフトウェアエンジニアは幸せにはなれないように思う。

次回は、お金をできるだけ使わないでソフトウェア技術者に対する投資をする方法について書こうと思う。

　

ルールに振り回される日本人

日本人が本質的な目的を忘れルールに振り回された典型的な例がニュースで流れた。

制服ワッペン２万枚作り直し、３４００万どぶ…都下水道局

4月10日3時6分配信 読売新聞

東京都下水道局が昨年、制服に付ける都のシンボルマークを添えたワッペンを２万枚作製したところ、シンボルマーク使用に関する内規に反したとしてこれを使わず、新たに約３４００万円をかけて、ワッペンを作り直していたことがわかった。

　デザインは組織名の下に５センチ余の波線を付けたシンプルなものだったが、この責任を問い、都は担当幹部２人を訓告処分にしていた。内規を杓子(しゃくし)定規に解釈した「お役所仕事」の典型とみられ、公費の支出の在り方に批判が集まりそうだ。

　都下水道局では、所属する計約３０００人の職員用に、予備を含めて計約２万着の制服を作っているが、１９７８年から同じデザインだったため一新することにし、右胸に付けるワッペンも新たに作ることにした。

　ワッペン（縦２・５センチ、横８・５センチ）はシリコン製で、イチョウ形をした都シンボルマークの横に局名を記し、「水をきれいにするイメージを出したい」との願いを込め、その下に水色の波線（約５センチ）を添えることにした。職員が考案したものだった。

　ところが、約２万枚のワッペンが完成し、一部は制服への縫い付け作業が始まった昨年１１月に開いた局内の会議で、ワッペンのデザインが、シンボルマークの取り扱いについて定めた都の内規「基本デザインマニュアル」に抵触する疑いが浮上。内規には、マークの位置や文字との比率などが細かく記載されており、誤った使用例として「他の要素を加えない」と規定。同局では今回、この規定を厳格に解釈したという。

　ただ、この規定は例外も認めているが、同局では、波線部分を取り除いて作り直すことを決定。制服を含めた費用は当初、約２億１３００万円だったが、新しいワッペンの作製費と縫い替えの費用として、約３４００万円を追加支出した。

　都は今年３月、最初のワッペンのデザインを決めた担当の部長と課長（いずれも当時）を訓告処分とした。今月から制服を一新したことは発表したが、ワッペン作り直しに関する一連の事実は公表していない。

　下水道局は「事前に規定を見ていれば防げたもので、担当者のミス。多額の費用負担を生じさせて申し訳ない。次のデザイン更新は何年先になるかわからず、それまで誤ったワッペンを続けることはできなかった」と説明している。

　下水道局を巡っては、ＪＲ王子駅（北区）のトイレの汚水が、約４０年にわたって近くの川に流れ込んでいた問題で、２００７年６月にこの事実を把握しながら、対策を取らずに放置していたことが判明している。

冒頭の図の上が東京都下水道局が当初、採用する予定だったワッペンのデザインだそうだ。波線が入っていることがルールに違反している＝あってはならないという考えにとらわれてしまったわけだ。

この東京都下水道局幹部の判断について石原慎太郎知事は１０日、定例記者会見で「本当にたまげた。骨身に染みて反省するよすがにさせる」と述べ、作り直しを決めた同局の幹部らを処分する方針を明らかにした。石原知事は、この問題を報じた読売新聞を掲げながら、作り直す前のデザインについて「東京の下水はきれいだなって感じがするし、いいじゃない」とし、「規格に合わないからと作り直して、バカじゃねえかほんとに」と怒りをあらわにしたそうだ。

このニュースを聞いてたしかに「バカじゃねえか」と感じたが、実はこのような「バカじゃねえか」という話しは身近でよく見かけると思った。

この話しには日本人特有の2つの問題があると思う。ひとつは「組織やプロジェクトを構成するメンバーが組織やプロジェクトの目指す目的について十分に意識していない」ことと、もう一つは「組織やプロジェクトを構成するメンバーがルール作りに参加しておらず、ルールを改善することができると考えていない」ということだ。

【組織やプロジェクトの目指す目的について十分に意識していない】

ようするに組織目標という遠くにあるゴールを見ずに、自分の直近にあるものしか見ないため近視眼的な思考となり結果的に、遠くにある組織目標に背反するような判断や行動を取ってしまうケースだ。

東京都下水道局のホームページを見ると経営計画2007というページに以下のような3つのスローガンが掲げてある。

○安全で快適な都市生活をめざして　

○お客さまサービスの向上・経営効率化の取組

○危機管理対応の強化・地球環境保全への貢献

職員が組織内で一つ一つの判断をする際に、この3つの目標を常に頭に入れておいて、これらの目標に向かった行動になっているかどうか考える癖をつけていると今回のような問題は起こらなかったと思う。

都の内規「基本デザインマニュアル」でマークの位置や文字との比率などが細かく決め、使用例として「他の要素を加えない」と規定したのは、シンボルマークの基準を定めることによって、一般市民がシンボルマークによって都の各部門とその責務を一目で判断でき、分かりにくかったり、勘違いすることを防ぐことが目的だったと推察される。

一方で東京都下水道局の文字の下に水色の波線（約５センチ）を添えることにしたのも「水をきれいにするイメージを出したい」との職員のアイディアであった。どちらも、東京都民へのサービス向上が目的だった。

それに比べて、約３４００万円を追加支出してワッペンを作り直すという判断は、結果的にユーザーである都民の税金を無駄にすることになるから、組織目標であるサービス向上の目的にそぐわない。

こういう一見どっちを取るべきか判断が難しい事例は日々組織の中で発生している。本末転倒と思われる顧客の利益にならない小さな誤った判断、行動は組織の中で意外にも頻繁に発生している。「これはセクショナリズムだ」と思ったときは、組織目標に照らし合わせると顧客満足の向上を疎外するような判断や行動がなされていることが多い。

この違和感をすばやく察知できるようになると組織の中のどこを改善すると流れがよくなるのか、組織目標の達成率が高くなるのかが見えてくる。（組織目標というのは目標売り上げ達成というような低レベルの目標ではなく、顧客満足の向上や社会貢献といった本質的な目標のことなのでお間違えなく）

組織目標や組織のポリシーと自分の中にある価値観がオーバーラップしていて、組織の価値と個人の価値を一部でも共有できていれば、いつも正しい判断ができる確率が高くなる。ただし、組織の目的が金儲けで、個人の目的も金儲けというようなケースではいくら価値観が共有できていてもいい方向にはいかない。

上司から命令されたからとか、クライアントからの要求だからといった近い視点ではなく、その判断や行動はエンドユーザーの利益になるのかどうかという視点を常日頃持っていると、確実にプラスの実績が積み重なっていく。そうでないと、やったけど役に立たなかったとか無駄だったというマイナスの実績ができてしまう。ソフトウェアエンジニアとしての活躍できる時間は限られているため、日々の活動はプラスの実績につながるようにしていかないといけない。

【ルール作りに参加しておらず、ルールを改善することができると考えていない】

ルールは天から振ってくるものであり、絶対に守らなければいけないと信じ切っている人をよく見かける。外部のセミナーに行ってきてセミナーの講師から「これこれを守らないと大変なことになりますよ」と恐怖心を植え付けられてきた担当者は、ルールの本質を外れて枝葉末節にこだわり始める。組織内で改善活動を行っている者にとっては、この手の話しは自分達の活動に水を差されることがよくある。

セミナーの講師やツールベンダーの営業の一部の人は、自分達の売り上げを確保したいために、必要以上に法律や国際基準、業界ルールを強調して、それを守らないと大変ですよと吹聴する。それを真に受けた担当者が過剰反応すると開発の現場にそのしわ寄せがくる。

そもそもの法律や国際基準や業界ルールが作成された背景はすっとばされて、○○した方がよいという文言は、末端にいくにつれいつのまにか○○せねばならないという強制の言葉に置き換わってしまったりする。

法律だって時間がたてば、時代にそぐわなくなって修正しなければいけないときがくる。国際基準や業界ルール、組織ルール、プロジェクトルールだって同じだ。組織の目標を達成するためにルールは常に改善する必要がないかどうかを考えている必要がある。

日本人は自分達で自分達が守るべきルールを作るということがどうも苦手なようだ。自分にはルールを作る権利があるという意識も低いし、その権利を行使しなければ自分が損をするという意識も薄い。たぶんデモクラシーの教育や文化が弱いのだろう。（誰かが決めたルールに従うのが普通と考える日本人としての国民性もある）

そういう環境に慣れてしまうと「ルールは変えられるもの」という感覚がほとんどなくなり、まじめであればあるほどルールには絶対に従わなければいけないと思い込んでしまう人がたくさんでてくる。

実は自分はこの日本人の特性を理解した上で、その特性を利用している。組織内で支援活動をするときに相手のルールに対する考え方見定めてこちらの攻め方を変えているのだ。

例えば、「ルールは絶対」と考えている技術者に対しては、必要な活動の目的よりもルールの方に重きを置いて指導、支援し、やることが決まっている以上やらなければいけないよという持って行き方をする。そして、その活動がプロジェクトに浸透したところで、ルールの向こう側にある本質的な目的を伝えて、何をどう判断するのか、どういうときにルールを逸脱していいのかを説明する。

一方で「ルールなんかくそ食らえ」と考えるチームには、逆にルールの向こう側にある本質について説明し、その本質が目指している価値とチームの目指す価値は一致している筈であり、そのために必要な活動であると諭す。そしてその結果ルールに沿った取り組みとなると説明する。

どっちにしても、必要な活動をして、最終的な目標（顧客満足の向上や社会貢献）につながればいい、そう考えれば、最善の判断、最善の行動は何か自ずと見えてくるはずなのだ。