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

今、「設計の規範の重要性を技術者に実感してもらう」　演習コンテンツを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割以上の企業が不十分な状況
仕様は変化しやすいが、要求の寿命は長い
日本の組込みソフトの作り方の特徴
働くことの本質は貢献であるという考え方
アメリカ人と日本人