自分の成果物は点数で評価してもらえると考える新人

今、「設計の規範の重要性を技術者に実感してもらう」　演習コンテンツをSESSAMEで開発している。内容はいずれ SESSAMEで公開されると思うが、次のような流れを想定している。

【Cプログラミングの初心者に対して】

1. ある簡単な仕様を満たす関数をC言語で設計させる。
2. 数時間するとなんとか要件を満たす関数ができる。
3. 時間を切って、あらかじめ漏れのないように設計した11程度のテストケースを対象者が作った関数に通し、テストフレームワークを使って関数の仕様満足度を採点する。
4. プログラミングの経験年数で点数がばらつく。
   
5. 採点結果を公表すると受講者達はとたんに目の色が変わり、用意した11のテストケースをクリアできるように関数を作り直し始める。
6. ここで、ほとんどの受講者が11のテストケースをクリアする100点の関数を作ってくる。

これは、受講生が小学生以来何度となくテストを通じて経験してきた、「ハードル見せて全部越えられるまでやってみろ、ほら、あっちの生徒は全部クリアできているぞ」という学習パターンを再現したものだ。

上記の作業では、仕様満足度が100%になるようなブラックボックスのテストケースを用意して、中身プログラムコードの内容について深く考えるより、テストケースを通すことが目的になってしまう場合が多い。とりあえず動くものを作ることを目標にするという学生にありがちなパターンだ。

そうなると、変数は必ず初期化してから使うとか、関数の出口は一つにするとか、フェイルセーフの設計を心がけるといった、設計の規範がおろそかになる。（大学のソフトウェア教育では、取りあえず動くプログラムを作るのではなく、設計の規範を教えて欲しいと切に願う。こちらの記事参照のこと。）

そこで、次に以下のようなアプローチを試みる。

1. 11のテストケースをクリアした関数に対して、あらかじめ用意した「変数は必ず初期化してから使う」などの設計の規範に対する適合度を100点満点で点数化し、優良可不可の判定を行う。
2. 大方の受講生はテストケースをクリアしていても設計の規範には十分に適合できていないため、可や不可の評価になる。
3. それまで自信満々だったのに落第と言われ、ちょっとしたショックを受ける受講生もいる。
4. 場合によっては求めてもいないのに課題を再々提出してくる者もいる。
5. そこで、最後の最後に回答例と回答例の設計コンセプトについて解説講義をする。

最後の解説講義のときに、冒頭に掲げたSystems Engineer Vol.1 特集1 SEが20代で身につけておきたいこと(技術評論社¥1280円）の一節を紹介する。

【学生時代とはまったく異なる社会】
　 周囲にいる同僚や先輩は、過去の背景が異なれば、現在やっている仕事も異なり、個別の価値観を持っています。背景がほぼ同じで評価は試験によるという、条 件が平等だった学生時代の環境から、平等性を取り払われた途端に感じる不公平感からくる不満。また、学生時代とは異なり、「ああしなさい」「こうしなさ い」と指示してくれる先生もいません。そのため、自分はいったいどうしたらいいのかと、途方にくれてしまうのが20代です。

【考え方の転換】
　学生時代は、履修科目をまんべんなく勉強していれば、いい評価を得ることができましたし、周囲が自分に期待している役 割も明確でした。しかし、社会に出てソフトウェア技術者として仕事を始めた途端に、勉強すべき範囲は無限にあり、周囲からの期待も不明確になるため、自分 の果たすべき役割は自分自身で考え、つくっていくことになります。それは、資格や職種など、「外から見た姿」をつくることではありません。自分の内側を成 長させ、力をつけることです。

【勉強をする】
　優れたソフトウェア技術者や、勉強することが習慣になっているソフトウェア技術者は、勉強に対してまったく異なるイメージを持っています。
　まず、「勉強＝何かを覚えること」とは考えていません。学生時代と違ってテストはないのですから、読んだり聞いたりすることを、すべて頭に詰め込んでおく必要はないのです。
　システム開発・ソフトウェア開発という仕事は知的労働であり、ソフトウェア技術者は「考える」ことを求められる職業です。一つの事柄に対し、複数の考え方を持っていることは、思考を柔軟にします。

--- 引用終わり ---

新人技術者は長いことテストで評価されることに慣らされてしまっているため、会社に入っても先輩や上司が自分の成果物を事細かに精査し、よい評価になるまで付き合ってくれると考えてしまう。

ところが、多くの職場では関数の一行一行に対して、設計コンセプトにまで立ち入ってレビューしてくれることはほとんどないので、自分自身で自分の成果物の完成度をどこまで高めなければいけないのか考えなければいけない。（eXterm Programming のペアプログラミングは、先輩がコード一行一行に対してアドバイスできるので設計の規範を伝承する効果が非常に高い）

このとき大事なのは、たった一つの関数であっても揺るぎない設計のコンセプトや設計の規範をベースにしてプログラムの作成に望むことだ。設計の規範はプロジェクト内で、コーディングルールを示したり、コードレビューをする際にたたき込まれると思うが、ソフトウェア設計にはいろいろなケース、パターンがあるので、例外や規範を逸脱した方がかえってプログラムが読みやすくなったり、効率的であったりすることもある。だから、確固たる設計コンセプトが自分の中に固まっていないと迷う場面が出てきて自信をもって設計を進められない。安定したトレードオフを行うには設計の規範とともに、設計ポリシーや設計コンセプトが必要になる。

受講生の中には「どんどん指摘して欲しい」と言ってくる新人がいる。一見積極的でよい姿勢のように見えるが、実はヒントを与えた後じっくりと考えて、自分の成果物を洗練させてくる技術者の方が組織にとってはプラスになる。

前者は他人への依存性が高く、後者が自立しているということだ。テストで良い点を取ることに慣らされてしまうと依存体質になってしまうことが多い。

組込みソフトウェアエンジニアに求められているのは単に言われたことを実行する、仕様を満たすプログラムを作るということではない。たった一つの関数であっても、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えてソフトウェアを設計することだ。

もしかすると、それができるのは日本の組込みソフトエンジニアだけであり、職業プログラマしか確保できない地域ではこのようなアプローチはできないのかもしれない。職業プログラマしか確保できない地域では、要求仕様の漏れをなくす、プロセスを切ってインプット、アウトプットに不整合がないかどうかチェックするようなアプローチを取るしかない。しかし、日本の組込みソフト開発のように同じメンバーで同じ市場に同じような製品を投入し続ける環境であれば、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えてソフトウェアを設計することができる可能性がある。

そして、PDCAが上手く回ればがちがちにプロセスで開発に縛りをかけなくても、品質の高いソフトウェアをアウトプットできる可能性もある。

ただ、現在は組込みソフトも規模が大きくなって、複雑度が増しているので、このような取り組みだけでは品質を高めることはできないし、明確なコンセプトを持って設計ができるソフトウェア技術者が減っていくのなら、プロセスアプローチを強化するしかないだろう。

さて、新人教育の話題に戻ると、成果物の価値を最終的に判断するのは先輩や上司ではなく、エンドユーザーだと考えると、たった一つの関数でも設計コンセプトとして何を考えなければいけないのかが見えてくる。これを身につけるために有効なのは次のようなサイクルを回せるようにすることだ。

1. 焦点をあてる問題領域を選択する
2. 集中して作業できる環境を整える
3. エンジニアが達成感を感じる
4. 改善点を冷静に分析し洗練させる

3の時点ではまずは動くものを作ることをめざし、その後、自分の成果物を冷静に分析して、自分の成果物がインプリメントされた商品を使うユーザーに満足を与え、成果物の価値が市場で認められ、再利用に値する資産になっているかどうかを考えて洗練させることができるかどうかが、非常に重要になる。

「改善点を冷静に分析し洗練させる」を実行するには精神的な余裕が必要だ。たった一つの関数の作成でもいい加減にせず、きっちりプロとしての仕事をして、その成果を積み重ねていけば、徐々に設計の効率が上がってきて精神的な余裕を作ることができる。だから、組込みソフトウェア技術者は最初が肝心だ。20代は負荷がかかったとしても設計の規範を身につけ、自立し、30代以降に成果物を洗練させる余裕を生み出せるように努力する期間だと思う。

【参考になる記事】

組込みソフトの品質を高めるには設計の規範が必要
スキルの伝承は8割以上の企業が不十分な状況
仕様は変化しやすいが、要求の寿命は長い
日本の組込みソフトの作り方の特徴
働くことの本質は貢献であるという考え方
アメリカ人と日本人

日本の組込みソフトの作り方の特徴

今回は10万行以下で小中規模の日本の組込みソフトの作り方の特徴について考えてみたい。

【日本のすり合わせ開発の特徴】

－前提となる環境－

• 開発者の入れ替わりがほとんどない。
• 開発者が商品企画から保守にまで関わる。
• 同じ市場に同じような商品を投入し続ける。
  

日本の組込みソフトウェア開発では開発者の入れ替わりがほとんどない、同じ系列の商品開発をだいたい同じメンバーでシリーズに何機種も作る。そして開発の規模が小さいと商品企画や保守に対してももソフトウェア開発エンジニアが深く関わる。同じ市場に同じような商品を投入し続けるので、自然と顧客要求がどんなものか、過去にどんなクレームが来たのか、どんな技術を使うとより顧客満足を高めることができるのかが分かってくる。

ビジネス系のソフトウェア開発では要求分析の重要性がクローズアップされているが、組込みソフトの世界では、わざわざ要求分析をしなくても、エンジニアの頭の中に要求がすり込まれていくという特徴がある。

組込みソフトの世界ではエンドユーザーが不特定多数のコンシューマーであることが多く、ユーザーニーズを把握することが難しい場合がある。サプライヤーにとってはソフトウェアを委託してくるクライアントが直接の要求の発信者となるが、このクライアントがエンドユーザーの要求を正確に把握しているとは限らない。

組込みソフトでは、リリースした製品が市場で売れたのかどうか、どんなクレームが上がっているのか、他社がどんな機能や性能を取り入れているのかといった情報が、要求の把握につながる。そうなると、「開発者の入れ替わりがほとんどない」「開発者が商品企画から保守にまで関わる」「同じ市場に同じような商品を投入し続ける」といった環境は組込みソフトの開発には有利な点が多い。

－改善の手順－

• まず、最初に類似商品のスペックを参考にして製品を開発し市場に投入する
• ユーザークレームを吸い上げ、これまでの機能性能を落とさないようにしながら、クレームを克服する
• クレーム対応と同様に他社製品にあり、自社製品にはない機能を追加する
  

－このアプローチの結果（傾向）－

• 市場に最適化された組込みソフトウェアができあがる
• すべてのユーザーの要求を取り入れるため機能がどんどん増える

ここで気をつけたいのは、このような付け足し付け足しのアプローチで解決できるソフトウェアの開発規模はソースコードが10万行以下のソフトウェアであり、数十万行、数百万行の規模のソフトウェアでは通常ではムリということだ。数十万行、数百万行の規模のソフトウェアでこのようなアプローチをしている開発チームでは、誰かが泣きを見ている。多くの場合泣きを見るのは下請けが孫請けのソフトハウスの技術者だろう。

－このアプローチのデメリット（メーカーサイド）－

• ソフトウェアが複雑になる
• 実装済みの機能や性能が劣化していないことを確認するのが大変
• 全体を把握できる技術者でなければ機能追加はできないし、不具合が発生したときの対応もできない
• ほとんど使われないどうでもいい機能のメインテナンスに多大な工数がかかる
• アーキテクチャデザインとしての強み（保守性、再利用性、変更容易性など）が消える（見えなくなる）
• ソフトウェアの開発効率が下がる
• その商品の強みがなんだか分からなくなる
• 自社のコアコンピタンスが相対的に目立たなくなる
  

機能を付け足しまくって、自社のコアコンピタンス（他社がまねできない技術）が相対的に目立たなくなるというのが、日本の企業に特徴的な現象だと感じる。ソフトウェアで性能を落とさずに機能を追加することができれば、材料費はアップしない。単価の安いエンジニアをこき使って開発費を抑えることができればソフトウェアが魔法の杖になるという考え方だ。

そして、営業員に「自社の商品が売れないのは他社がこんな機能を持っているからだ」と言われると、たいした機能でもないのに入れてしまう。日本のソフトウェアエンジニアはそれが出来てしまうから不幸になるのだとも言える。

そして、言われるがままに機能を追加しまくって性能を落としてしまったり、もともとあった自社の強みを目立たなくしてしまう。なんともはや、よかれと思ってやったことが逆効果という悲しい結末だ。

マーケティングをきちんとしなくてもクレームの克服や他社製品との機能比較だけで、商品開発していくとこういう事態におちいる。

－このアプローチのデメリット（ユーザーサイド）－

• 使わない機能がいっぱい付いていて使いこなせない
• 自分にとっての基本機能の使い方がわからない
• 商品コンセプトがよく分からない
• 不具合が起こるとソフトウェアアップデートを強いられる　

機能いっぱいでユーザーにもメリットはありそうだが、実はユーザーは機能を使いこなすことができず、ちっともいいことはない。

－デメリットを克服する施策－

要求の分析

• 市場要求・ユーザー要求の分析結果を可視化する
• 過去に起こった事故・クレームの分析と対策を蓄積しこれも可視化する
• 5年後、10年後を見据えた商品群のロードマップを作成する（商品ラインナップ、技術ロードマップ、規制ロードマップなど）
  

制約条件の分析

• 自社のコアコンピタンスが何かを明確にする
• 制約条件やトレードオフする項目（コスト、時間、性能、ビジネス目標など）を明確にする
  

実現手段の設計

• 要求と制約条件のトレードオフについてあたりを付ける
• システムを実現するためのソフトウェアアーキテクチャを考え、可視化する

アーキテクチャの変更

• 市場環境の変化によりアーキテクチャの変更が必要になったら、上記の要求分析から見直しをする。（安易に機能を付け足さない）

5000万件と1年

安倍首相が5000万件の年金データの照合を1年で終了させると約束した。この話を聞いて部下は全員ムリだと思っているのに製品の開発を1年でやると宣言してしまうプロダクトマネージャのことを思い浮かべる。

この話のポイントは簡単だ。プロジェクト計画を立てる際には、目標を達成するための作業をWBS（Work Breakdown Structure）を作って細分化し、工数を割り出して必要なリソースを割り当て、マイルストーンを設定する。ようするに、Microsoft Project で計画を作るようなものだ。

このプロジェクト計画をプロジェクトメンバでレビューすれば、本当に1年で終わるのかどうか見当が付く。不確定な要素、作業については一部だけ実際にやってみてそのときにかかった工数や時間から全体を予測する。

そういったことをやらずに、精神論だけで1年でやりますと宣言してしまう人は、おそらく、実際のプロジェクトマネジメントをやったことがないのだろう。プロジェクトをスケジュール通りに終わらせるためには、その計画の根拠が必要だ。

怪しい計画には実現できる根拠が薄い場合が多い。もちろん、リスクのない計画など存在しないが、最悪のシナリオの際にどれくらい日程が遅れるのか見積もらないのはまずいだろう。

仕事上で日程の話がでたら、まず、その日程の根拠を聞いてみることをおすすめする。勢いだけよくて根拠のない日程ほど最後の結末がむなしい。

仕様は変化しやすいが、要求の寿命は長い

先日あるソフトウェア技術者の方から以下のような質問を受けた。

【現場の問題点】

新製品のソフト設計を最適な手法を模索しながら行っています。仕様の明確化が重要だと思いますが、ハード設計に依存してしまい、洗い出しても保留になることが多くあります。こういった場合、どう対処すべきなのでしょうか？

そこで、以下のように回答した。

【回答】

まず、第一に要求品質を明確化することが重要です。要求品質には2種類考える必要があります。

1. ユーザー要求、市場要求から展開した品質
2. 同等の製品、製品群で発生した不具合の対策から展開した再発防止策に基づく品質
   

次に、1と2の要求を細分化して優先度を付けます。顧客要求・市場要求だけでなく、ビジネス目標などの要因も加味します。

ここまでで、要求品質が明確になり、どんな機能や性能が重要なのかがわかります。

仕様の明確化よりも要求の明確化の方が大事です。仕様は変化しやすいですが、要求の寿命は長いからです。

次に、要求を実現できる技術があるのかないのかを明確化します。この段階で試行錯誤しているのなら、それは要素技術検討の段階ですから実現できる目処を立てます。（部品の入手性、安定的に生産できるかどうかも検討します）

この作業にはトレードオフが必ず発生するので、その製品が使われる市場や実現技術など広い知識と経験が必要です。知識や経験が不足しており見切り発車すると、後工程での手戻りが多く発生します。未確認の技術要素は早め早めに実験して目処を立てます。

ソフトウェアの設計で注意すべき点は、今回の開発だけでなく次の開発、またその次の開発で共通なソフトウェア資産は何か？　固定的な要素は何か、変動的な要素は何かを見極めることです。要素技術検討の段階でハードウェアが確定していない機能については、ハードウェアに変更があったときのことを考えてチューニングしやすい構造（アーキテクチャ）を選択します。

上記のアプローチが成功すれば、寿命が長く変化に対応しやすいソフトウェア資産ができあがるはずです。

【引用終わり】

回答を書いてみて、「仕様は変化しやすいが、要求の寿命は長い」というフレーズはいいなと感じた。

この話はオンデマンドで作るソフトウェア開発と組込みソフト開発の最大の相違点であり、組込みシステムでは同じ市場に同じような製品を投入し続けるということは、要求に普遍性があるからだということに通じる。

普遍的な市場要求、ユーザー要求がキチンと把握できていないと、次の製品を作るときに「他社がやっているから」とか「組織のお偉いさんが入れろと言っているから」といった理由で、付け足し要求を実装し、現在の製品がクリアできている市場要求・ユーザー要求を実現している機能や性能をデグレードさせてしまうケースがある。

一通り一般的な要求を実現すると、カタログスペック上で他社と比べて負けているところだけが目に付き、強いユーザー要求でもないのにそのおまけの機能を実装しろという輩がかならずいる。

営業担当は自社の商品が売れない理由を他社の商品ができていて自社の商品ができない機能や性能があるからだということが多い。

実際、それが理由で売り上げが低迷していることもあるのだろうが、その機能を実装したからといって売り上げが大幅にアップすることはほとんどないように思う。

ここの問題点は、作る側も売る側も商品のコンセプトをちゃんと理解しておらず、市場要求・ユーザー要求の本筋で勝負することを忘れてしまっているということだ。

商品のコンセプトが明確になっており、市場要求・ユーザー要求の本筋の部分でどんなくふうや、トレードオフをしているのかがいつも頭の中に入っていれば、「（枝葉末節的な）このスペックが足らないから売れないのだ」という販売サイドの主張に対し、「それは市場やユーザーの本筋の要求ではなく、それを実現しようとすると、レスポンスや複雑性が増すことによる安全性や信頼性の面でリスクが生じる」「この製品のこの機能や性能は今も昔もお客さんに満足されており、その満足度を下げるリスクが現実になると売り上げを下げる危険がある」「基本機能のこの面を強化すれば、より顧客満足度を高めることができる」というような意見を即答できる。

組込み機器は制約条件が多いので、要求と制約のトレードオフがいろいろなされ、その微妙なバランスで現在の製品ができあがっていることが多い。実現した機能や性能にソフトウェアが絡んでいる場合、なかなか外には見えないので、どんな影響があるか何も考えずに「こんな機能も、あんな機能も、全部追加してしまえ！」という乱暴な指示を出す者もいる。

その結果、要求と制約のトレードオフがくずれ、いままでできていた基本機能を損ねてしまったら、元も子もない。

だいたい、市場要求、ユーザー要求だって実は十分に満たせていないことに気がついていないだけかもしれない。要求はあるけれど、さまざまな制約条件で十分に満たせていない状態で商品をリリースしていることはよくある。その本質的な要求と制約条件を忘れてしまうと、技術革新が起こって制約条件が緩和されたにも関わらず、その新しいデバイスや技術を使うことを忘れ本質的な要求実現を改善することよりも、どうでもいい付け足しの機能を追加することに走ってしまう。（「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」を参照のこと）

組込みソフトエンジニアは「仕様は変化しやすいが、要求の寿命は長い」ということを忘れずに、この商品やサービスに求められている要求は何か、その要求に優先度を付けると何が一番大事なのかを常に頭の中にいれておかなければいけない。

それを忘れてしまうと、ステークホルダかクライアント、声の強い者に、こねくり回し的な仕様変更や仕様追加を指示され安易に受け入れてしまう可能性が高くなる。

組込みソフトエンジニアのモチベーションが最も下がるのは、お客さんの満足を高めることに貢献しないような仕様変更や仕様追加を突きつけられたときだ。「あーあ、こいつ分かってないな・・・」と思いながら、仕様を押しつけられそうになったら、本質的なユーザー要求に戻ってとことんディスカッションすべきだと思う。