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