アウトプット力が低下してきている？

最近は、「検索の時代」になったため、大学でのレポートで、検索して、コピペして、仕上げる学生が多いのではないかと思います。確かに、大学で出される課題レポートであれば、検索して答えが見つかる可能性が高いと思います。しかし、企業内の文書作成では、そもそもネットで検索しても答えなどないものが多いです。たとえば、社内で作成されたソフトウェアフレームワークの仕組みを調べて、文書を作成する仕事が与えられたとして、ネットでは検索できません。

そうなると、フレームワークを調べる能力に加えて、それを分かりやすく文書にすることができないとだめです。しかし、残念ながら、そのような文章作成を学生時代行っていないため、レビューで「こんなことから指摘しなければならないのか」と思う低レベルの日本語の指摘もしなければなりません。例としては、「話し言葉」と「書き言葉」の違いとかです。たとえば、「機器へコマンドを送信する」ではなく「機器へコマンドを投げる」と、普段の会話で本人が使用している話し言葉でそのまま書いてきたりします。

ネットで検索すること悪いことではありませんし、昔と比べてはるかに多くの情報を簡単に調べたり手に入れたりすることができます。一方で、アウトプットは意識して行っていく必要があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない

いつも講演や教育で話をしている「ソフトウェアエンジニアの心得」の講演スライドの中に次の一文があります。

初心者だからと言って、汚いコードを書くことが許される訳ではない

会社で給与をもらいながらソフトウェア開発に従事する場合には、資産を残すことが求められます。

ソフトウェアエンジニアの責任は、何年も使われ続けるビジネス資産を作り出すことです。ソフトウェアエンジニアが、他人の書いたコードを理解することができない場合には、そのコードはあっさりと捨てられ、一から書き直されてもおかしくはないでしょう。残念なことに、このような書き直しは頻繁に起きています。コードを読みやすく保守性を高めることは、コードを正しく動作させることと同じくらい、あるいはそれ以上に重要です。正しく動作しないコードは、動作するように修正することはできます。保守できないコードは、がらくたに過ぎません。

Taligent’s Guide to Designing Programs

どこかの建築会社に自分の家の設計・建築をお願いして、完成したら、出来上がりがひどい箇所があった時に、そのことを指摘して、「経験の浅い新人が担当したのでそうなりました」という言い訳されたらどう思いますか？

プログラミング経験が浅いという事実によって、会社におけるソフトウェア開発で、汚いコードを書いて残すことが許される訳ではないのです。しかし、実際には、何が良いコードで何が汚いかを初心者が判断することは難しい訳です。そのため、新人が書いたコードであっても、開発組織としてレビューを行い、きちんとした品質に仕上げさせる必要があります。

このことは、コードに限った話ではありません。作成してもらう文書もそうです。当然、作成された文書をレビューして、説明不足や分かりにくい日本語表現などを指摘したりして修正させます。

ところが、最近は、大学でもそのような文書作成の指導を受けてこないようで、何度も何度も分かりにくい日本語を指摘されて、修正を指示された結果、文書作成そのものが終わらなかったり、完成までに非常に長い期間を要したりします。その場合、レビューでレビューアがOKを出さないので、自分の仕事（文書作成やコーディング）が終わらないのであり、自分の責任ではないと考える人がいたりします。

若手に対するレビューは、単にアウトプットの品質を担保するだけのものではありません。数年後には、その人が次の若手をレビューして指導できるようになることも期待しているのです。もし、数年後に次の若手を指導できるようにはならないと判断されたら、レビューを通した指導もされなくなるかもしれません。