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 の要求を同時に満たすことができる。
クリティカルデバイスの開発は、失敗や事故との闘いであるとも言える。失敗や事故を再発されないためのノウハウを製品につぎ込み続けることが当たり前品質を高めることにつながる。だから、新規参入が難しいとも言える。ただし、大規模複雑化したソフトウェアの場合、単純に安全装置としてのソフトウェアを追加し続けると、これまで正常に動いていたシステムをデグレードさせてしまうこともあるから注意が必要だ。
ハザードやリスクがどう変化したのか、見落としていたのかを再評価し、リスクコントロール手段を要求としてとらえ、実現するアーキテクチャを設計する。日本人はこの設計上流の分析や設計がとても苦手に見える。試行錯誤で付け足しや修正をするのは得意だが、上流に立ち戻って再設計するのは下手だ。
障害や事故を再発されないという強い気持ちとリスク分析、リスクコントロールのアーキテクチャ設計ができないとないと、障害や事故はまた起こる。気持ちだけでもダメだし、技術力がなくてもダメだ。
そして、是正・予防措置は、気持ちだけでは進まない、組織に品質マネージメントを仕組みを根付かせ、日々前向きな気持ちで回していなければできるものではない。
そして、ジャーナリズムにお願いしたいのは、障害や事故が起きたとき、その後組織が再発防止の取り組みを続けているかどうかを監視することと、今は起こっていないが何かあったら大変なことになる社会インフラ、重要デバイスに問題が起こったらどうなるのかという視点を持ってもらうことだ。
何か起こってから追求するのは誰でもできるが、これから起こるかもしれない障害、事故を防ぐためには経験や知識、幅広い視点が必要になる。ジャーナリズムには事故を未然に防ぐ技術やマネージメントについての報道を期待したい。
2011-03-27
2009-05-12
再利用資産を作る勇気
最近、「別製品の過去のソフトウェアを参考にして（とある）機能を実装した」という変更履歴を見た。その行為に対して「同じ機能を実装するのになぜ修正が必要なのか？」「再利用できる資産を使うという解決方法はないのか」という突っ込みを入れる者はプロジェクト内に誰もいない。これこそが、「あたたかい人間関係の中のやさしい一員」の特徴だ。プロジェクトリーダーの承認やプロジェクトメンバーのレビューなしに変更が進められ、誰からも「ちょっと待った」と言われることはない。直近の問題解決が優先され、長期的な改善活動のことは視野には入っていない。
それはそのソフトウェア資産の価値と寿命で判断する。価値が高く、寿命が長いソフトウェア再利用資産は技術を駆使し、勇気を持って再構築する。顧客に対する価値がそれほど高くなく寿命が短いソフトウェアは無理して再利用資産にする必要はない。資産化するコストに見合わないことが多い。
価値は高いが寿命が短い、価値はそれほどではないが寿命が長い場合はよく考える。価値は表に出やすい顕在的価値だけでなく、バグがあるとユーザーに多大な不利益が降りかかるような潜在的な価値（当たり前品質）もあるので注意が必要。
ソフトウェア再利用資産を構築しメインテナンスするには技術だけでなく勇気もいる。特にボトムアップで再利用資産を構築するときは自己犠牲を払う覚悟もいる。だから、コピペしてお茶を濁してしまう技術者があちらこちらに出てきてしまう。
日本でソフトウェアの体系的な再利用戦略を実践するには、「開発効率と品質向上の向上」についての現場からの必要性の叫びと、組織的トップダウンの取り組みの両方がかみ合わないと難しい。どちらかだけでもダメだ。一度構築したソフトウェア再利用資産を使い続けるには組織的マネージメントも必要だ。統制が取れていないプロジェクト、組織ではせっかく作成したソフトウェア再利用資産が使われなくなってしまう。実質的にはソフトウェア資産の可視化と、その資産がどれくらい価値があるのかの周知ができなければ、見えにくいソフトウェア資産はすぐに埋もれてしまう。
価値を見えるようにするということがいかに大事かということである。
2009-01-24
ソフトウェア資産の価値を可視化すべし
メカ（機械設計）、エレキ（アナログ、デジタルを含む電気設計）、ソフト（ソフトウェア設計）の3つを比べたとき、開発の効率化、高品質化がやりやすいのは、メカ＞エレキ＞ソフトの順番ではないかと思う。
たぶん、その理由は各設計ドメインにおける開発の成果が見えやすいか否かの違いだろう。メカはできあがったものを見て動かしてみればできの善し悪しを判断できる。評価はできあがったものをみんなで触ってみればいいし、うまくできたら上司に「動かしてみますので見てください」と言えばいい。ソフトウェアの場合、上司に「いい関数ができたので見てください」と言っても明確かつ一般的な評価指標がないから面倒くさいと言われるだけだ。（共通の価値を見いだすのが難しい）
エレキはそもそも完成された部品を組み合わて回路を構成するため部品単位の検証を行う必要はない。また、ブロック図や回路図といった抽象化されたモデルが必ず存在し、さらに、部品が実装されたプリント基板をまじまじと眺めることができる。
それに比べてソフトウェアはどうだろうか。「いやー、この間の開発で作った○○モジュール、あれはいい仕事だったね」とか「△△のソフトウェアはライバル会社の××のよりも数段性能が高かった」などという会話を聞いたことがあるだろうか。そんなのエレキでも同じだと言うかもしれないが、エレキの場合物理的な実装プリント基板がある。電気屋さんは発注したプリント基板が上がってきたとき、そのプリント基板に部品を実装して正常に動作したとき、喜びを感じることができるし、同僚とも喜びを分かち合えるし、上司に「できました」と物を持って報告にいける。
ソフトウェアの場合は同じことができるのは、ソフトウェアが製品に実装されたときだけだ。そこに大きな問題がある。ソフトウェア部品、ソフトウェアサブシステムが完成したとき、喜びをかみしめることができるのはごく少数の技術者であり、完成したと思ったサブシステムもさみだれ式に変更を繰り返していたのでは完成したという区切りが見えないので「終わった」という感覚がない。だから、組込みソフトウェアエンジニアはソフトウェアが製品に実装されたときにしか周りの人たちに評価されないという問題がある。ソフトウェアの部品単位で評価されることはないから、ソフトウェア部品の作りかたやソフトウェア部品の品質がいいとか悪いなどと評価される機会は残念ながらほとんどない。
ビジネス系のパッケージソフトウェアならばソフトウェア部品であったとしても、ソフトウェア部品としての売り上げで、そのソフトウェアの価値を推し量ることができる。ところが組込みソフトの場合はメカ、エレキ、ソフトが一体となって出荷されるために、もし商品がヒットしても、売り上げに貢献したのがメカなのか、エレキなのか、ソフトなのか分かりにくい。
メカやエレキは性能を計測するこができるから評価する指標を作りやすい。ソフトウェアの場合はどうか。「この製品は1000行あたりのバグが少ないんです」などとハードウェア出身の上司に言おうものなら「バグはゼロにして出荷しろ」と言われるだけだ。「いや、そうじゃなくて」としゃべり始めたときには上司はもう向こうに歩き始めているだろう。
要するに組込みソフトウェアの場合、プラスの価値を表現するのが難しいのだ。パッケージソフトウェアの場合と同様に、ソフトウェア部品を売る会社は、そのソフトウェア部品の売り上げで価値を評価することができるが、実はここにも問題がある。
エレキの場合、部品の検証は相当厳しく実施され、検証が十分に終わらないと出荷はしない。なぜなら、電気部品に不具合があって、その部品を使って商品を作成し、電気部品の不具合が原因でユーザーが被害を被った場合、部品メーカーはそれ相当の責任を負うことになる。エレキの場合、どの部品が不具合の原因かは正確に分かるし、不具合の状況を部品メーカーに突き付けることもできる。問題が起こったら部品メーカーは逃れようがないのだ。だからこそ、エレキの部品メーカーはリリースする部品が完全であることを確認して出荷する。電気部品の場合、検証に必要なテストケースは有限な場合が多い。その有限のテストケースをパスすれば、後は生産の問題に引き継げる。
ただ、エレキの世界でもワンチップマイコンのように、いろいろなデバイスをパッケージした製品を作ると、検証に必要なテストケースは爆発するようになり、すべてのケースをテストするのは不可能になる。だから、まれにワンチップマイコンにはバグが報告される。実際にはバグとは言わず、機能制限ということばで説明され、「これこれ、こういう使い方はしないでください」という注意書がデータブックなどの説明書に書かれる。これを見落とした場合の責任はデバイスを使う側にある。
さて、それでは市販されているソフトウェア部品を使う場合、そのソフトウェア部品はエレキの部品と同じように完全に検証され、不具合はないと言えるだろうか。その答えが NO であることは、組込みソフトウェア開発をやったことがある技術者ならすぐわかるだろう。実際、市販ソフトウェアに瑕疵（不具合）があったら賠償を請求できるだろうか。それは多くの場合できないし、そもそもバグがゼロだなんでだれも思っていないから賠償請求もしない。市販ソフトウェアは部品単体で完成度を表すことは難しいし、そこに問題がないことを証明するのは市販ソフトウェアを製品に組み込む側の責任であるという認識であることが多い。
そう考えると市販ソフトウェアのように明確に部品化されたソフトウェアであっても、そのソフトウェア部品が正しく動くということは部品メーカーサイドは保証することはできないので、そのソフトウェア部品が仕様どおりに動くという当たり前品質における価値は確定することがほとんどできない。ソフトウェア部品の場合、完成を確定することができないので、市販されるソフトウェア部品であってもその価値を確定することが難しいのだ。
ソフトウェアは簡単に変更できてしまうので、ソフトウェア部品のメーカーは出荷したソフトウェアに問題が発覚するとその情報を保守契約している使用者に流し、バージョンアップしたソフトウェア部品を配布する。でも、その市販ソフトウェアを使った製品を出荷してしまったメーカーはいったいどうすればいいのか。それは、その問題がユーザーにリスクを与え、そのリスクが許容できないと判断された場合は、製品のソフトウェアをバージョンアップし、場合によってはリコールするしかない。
ソフトウェア部品の価値の議論にもどると、このようにソフトウェアは当たり前にできているべきことが出来ていないときに負の評価が表面化する。負の評価の評価指標はソフトウェアの作り直しの費用や、ユーザーに対する弁済の費用だ。リコールにかかった費用がもっとも分かりやすい。ソフトウェアが原因でリコールしたら、そのリコールの費用がソフトウェアの負の価値として組織内外を駆け巡ることになる。
そこで、今回の記事のタイトル「ソフトウェア資産の価値を可視化すべし」となる。もちろん、可視化するのはソフトウェア資産のプラスの部分だ。
エレキの場合、性能を評価することがしやすいと書いたが、コストダウンも評価しやすい。同じ性能を安く実現できた場合、コストダウンぶんは直接利益になるからだ。
ソフトウェアの場合もエレキと同じような作戦でソフトウェア資産の価値を可視化する作戦を考えた。ソフトウェアの開発はほとんどが人件費だ。市販ソフトウェアだってもとは技術者が作るわけだからもとは人件費となる。したがって、ソフトウェアは再利用すればするほど、再利用するソフトウェアが問題を起こさなければ起こさないほど価値が高まる。ソフトウェアは複製しても劣化しないから部品を削減するのではなく、開発にかかる費用をセーブし、かつ、品質を高めることができればコストダウンにつながる。
【ソフトウェア資産の価値を可視化する作戦】
ソフトウェアシステムは大抵の場合サブシステムに分割される。ソフトウェアは見えないとよく言われるが、10万行を超えるようなソフトウェアシステムのソースファイルを一つのフォルダで管理しているプロジェクトはないだろう。多くの場合、ソフトウェアシステムのアーキテクチャに考慮して、フォルダを分けるはずだ。非常におおざっぱだが、そのサブフォルダの名前がサブシステムの責務を表しており、そのサブフォルダに入っているソースプログラムを作るのにかかった費用を計算する。これはそのサブシステムの価値の一つの評価指標になる。
サブシステムを協力会社に発注したのであれば、協力会社にいくら払ったかでサブシステムの価値を金額で表すことができる。もしも、設計と検証でかけた費用を分けることができれば、設計にかけた費用が顕在的な価値、検証にかけた費用を潜在的な価値と見なすことも可能だ。
もし、サブシステムを組織内で作成したのであれば工数を集計して、その工数に何かしらの金額（時給）をかければいいだろう。
それらの評価指標が使えない場合は、しょうがないからプログラムソースコードの実行コード行数にある一定の金額をかければよい。ソフトウェア開発がそもそも人件費で成り立っているのならそれもある程度の根拠となる。
これをすべてのサブシステムに実施すると、どのサブシステムがどれだけの価値を持っているか（いくらかけて作ったのか）が見えてくる。そして、次の開発でそれらのサブシステムのうちどれかをそのまま使うことができたら、使ったサブシステムの価値（開発にかかった費用）ぶん、新しい製品の開発費をセーブできたことになる。一つのサブシステムの開発費が数百万、数千万円になることはよくあるから、サブシステムをまるまる再利用すると数百万円、数千万円ぶん開発費をセーブできたことになる。
これができれば、リコールが発生したときにマイナス側でしか評価されていなかった組込みソフトエンジニアは初めてプラス側の評価を得ることができるようになる。これが定着していけば2010年代には日本でも「開発費をよりセーブできるアーキテクチャを設計したエンジニアが評価される」というソフトウェアエンジニアに対する評価のパラダイムシフトが起きるかもしれない。
日本のソフトウェア開発がぐだぐだになるのは、日本人の「あたたかい人間関係の中のやさしい一員」という特性のせいだとこのブログで書いているが、もうひとつの側面はソフトウェアの価値がハードウェア出身のマネージャのみならず、ソフトウェアエンジニア自身のも見分けがつかないからなのだと思う。
ソフトウェアの価値を高めるにはどうすればいいのかの議論は誰でもする。でも、価値が高まったかどうかの評価指標がないので、声の大きいものの発言に引っ張られ、やってみて成功しても失敗しても結果的にソフトウェアの価値が上がったのか下がったのかがわからない。開発期間の短縮という評価指標は、要求の変更などに振り回されるから正確な判断材料にならない。
だから、ソフトウェアサブシステムに開発費がいくらかかって、次の開発でいくら開発費をセーブできたのかでソフトウェア開発プロジェクトやエンジニア、アーキテクトを評価すると道は拓けるはずだ。再利用が進めば進むほど開発費は数百万、数千万円単位でセーブされていく。それが可視化されると、ソフトウェア資産の再利用が進み、ソフトウェアエンジニアは次の開発でできるだけ手を入れないで資産を再利用するにはどのようなアーキテクチャにすればよいのかを真剣に考えるようになる。アーキテクチャを工夫して再利用が成功すれば、数百万、数千万円単位で費用をセーブすることができ、セーブした費用ぶんがそのアーキテクトのソフトウェア開発効率化の実績になる。
ソフトウェアサブシステムは再利用しているといっても、実はかなり手を入れてしまって実際には派生してしまっていることも多い。しかし、これは構成管理ツールなどと連動してフォルダ内のプログラムソースがどれくらい変更されたのかをウォッチすれば変更量がわかるし、また、どれくらいソフトウェアサブシステムが他のアプリケーションから参照されているかもわかるだろう。ソフトウェアの資産価値のみならず、サブシステムが変更されたことによる注意信号（赤、黄、青）を灯すことも可能だ。
このような情報をソフトウェアサブシステムの価値に換算することで、ソフトウェアの開発を行うたびにソフトウェア資産の価値がダイナミックに変化することが見えるようになる。そのソフトウェアサブシステムを作るためにいくらかけたのか、そのサブシステムは何回再利用されたのかという指標がもっともベーシックな価値になるが、ソフトウェア検証やデバッグにどれくらい費用をかけたのかという指標もソフトウェアの信頼性の価値を判断する指標になるだろう。
「このソフトウェアの性能は最高です」とか「バグを減らしました」とか「バグが出にくいソフトウェアを作りました」なんて主張しても、ソフトウェア開発の経験のない組織の上位にいる人たちは表面的には「良くやったね」と言ってくれるかもしれないが、実際には何のことかさっぱり分からず、それらの情報でソフトウェアエンジニアを評価することはできないだろう。所詮、人間なんて自分の中にない価値基準で説明されても評価なんかしないものだ。
環境が違う場所で育った人たちが互いに理解しあうためには共通の価値基準で語りあう必要がある。メカ、エレキの出身の人たちとソフト屋さんの間で共通理解を得るためには共有できる価値基準を用いて話しをするしかない。
げすな話しと思うかもしれないが、ソフトウェアを作ったことがない、もしくは何十年も前に現役を離れてしまっている人達との共通の価値というのはここではお金のこと指す。ただ、よく考えて欲しいのはお金というのは人類が発明した全世界共通の価値基準であり、金に換算することでほとんどの人がその対象に対して共通の価値を認識できる。
だから、ソフトウェアエンジニアはソフトウェアが見えにくいということを嘆いているのではなく、また、リコールによる負の価値でマイナスに評価されることに甘んじるのではなく、ソフトウェア資産の再利用でいくら開発費用をセーブできたかを可視化すればよいのだ。
そして、開発費用をたくさんセーブできるアーキテクチャが評価され、そのようなアーキテクチャを設計できるアーキテクトが評価される。これこそが、日本版 Value-Driven Architecture である。
ソフトウェア資産の価値を簡単に評価して表現できるようなソフトウェア構成管理ツール、例えば、プログラムソースファイルをチェックイン、チェックアウトするたびにサブシステムのフォルダにソフトウェア資産の価値を表す金額が表示される、フォルダ内のファイルの変更が増えるとフォルダの色が青から黄、赤に変わる、変更が減ると青になるような構成管理ツールが現れたら是非教えて欲しい。すぐ導入するから・・・
登録:
投稿 (Atom)