最近、常々思うことがあります。
Webエンジニアに必要なのは、思いやりなのではないだろうかと。
エンジニアはつねに改善するように常日頃から心がけることが必要な職業です。だからこそ、エクストリームプログラミングやスクラムといった手法が考案され、実行されているのだと思います。
スクラムのふりかえりには、KPTといってよかったこと（Keep）、問題点（Problem）、改善したいこと（Try）を振り返ります。社会人１年目が習うPDCAサイクルを回すといったことに近い事象でしょう。
その中で、今日は、思いやりにかかわるWebエンジニアがやるべき３つのことを述べたいと思います。
１．テスト
エンジニアはテストを書きます。これは、昨今は当たり前となっていることです。「テスト書いてないとかお前それ@t_wadaの前でも言えんの」などと言われるこのご時世。テストのないシステムは、自ら破滅へ向かいたいのかと言わんばかりの自殺行為とも言えます。
しかし、中には様々な事情をつけて、テストを書きたがらないエンジニアもいます。その理由は様々です。「リリース優先で時間がなかった」「動作確認しているからテストはいらない」などやらない理由はたくさん出てきます。
私は、テストは必ず必要なものだと思います。いちばんの大きな理由は、このシステムが自分の手から離れたとき、後から参画するエンジニアの開発効率に大きく影響するからです。
テストは、いわば仕様書といって過言ではありません。後から参画するエンジニアは業務要件がわかりません。ソースコードを読んだり、業務がわかるエンジニア、サポート、経理等々に聞いて要件を理解していきます。その大きな手がかりとなるのがテストです。不具合があって初めてコードを見るということは良くあります。その時にそのケースが事前に考慮されていたものなのか、意図したものなのかということは、理解する上で、そして修正する上で大きな手がかりとなります。意図しているのであれば、そもそもの実装が間違っていたということですし、意図していないのであれば単純に考慮漏れということもありうるでしょう。それを開発した前にいたエンジニアがどこまで考慮したかを知ることは、当時の開発の様子を把握する上で非常に貴重な資料となるのです。
それだけではありません。多くのソフトウェアは、常に修正が繰り返されます。後から参画したエンジニアは自分がした修正が既存の仕様を破壊していないかに常に気を配らなければなりません。自信を持てなければ、開発なんてできませんし、破壊しないようにするために冗長なコードが多数生み出されることもあります。そうすると、保守性が著しく低下し、同じ内容の修正をしなければいけない箇所が複数存在して不具合の温床となります。後世のエンジニアが自信をもって機能開発するためにも、テストは必ず必要なものなのです。
テストに関して、必要性を２つほど述べました。まだ他にもあると思いますが、一旦ここまでにして、この２つに共通することは何かを考えてみます。
それは「思いやり」です。最初に作った人がいなくても、後から入ってきたエンジニアは、テストによって仕様が理解でき自信を持って開発ができます。会うかどうかわからない人に思いを馳せ、テストを書くのです。
なぜソフトウェアを開発するのでしょうか？それは、ユーザーに価値を提供するためでしょうか？私は、違うと思います。いっときだけ価値を提供すれば良いのではありません。ソフトウェアによって、ユーザーに価値を継続して提供し続けるのです。いっときであれば、なにもシステム化する必要などないのです。ユーザーに価値を提供し続ける。これが、経営陣も望むことでしょうし、ユーザーが望むことでしょう。それこそが私の思う思いやりです。
２つ目は、コードの品質です。
私が仕事で使っているRuby on Railsであれば、Rails newと同時に行うことの一つにGemfileにrubocopを入れ、.rubocop.ymlを置くということがあります。rubocopは、コードの静的解析をしてくれ、コードに改善すべき点があれば、指摘してくれます。また、CodeClimateというサービスを使ってソースコードの品質を評価してくれるサービスもあります。こうしたツールを使うことで、テストコードと同様に不具合の芽を摘むことができます。品質が良いコードというのは、保守・運用性に優れたコードであるとも言えます。
こうしたツールを利用することは、技術的負債を後世になるべく残さないようにという意図が明確になります。ソースコードは生まれた瞬間から多かれ少なかれ技術的負債となります。それをなるべく軽減しようとする意識は、後から参画したエンジニアからみれば、とてもありがたいものと言えます。
例えば、１００行ぐらいあるメソッド（関数）と遭遇したらどう思うでしょうか？
１行に１０００文字ぐらい書かれていたらどうでしょうか？
if文が10回ネストされたコードを見たらどう思いますでしょうか？
それを見た瞬間にまともなエンジニアならば拒絶反応を起こすと思います。これを書いた人は、これを読んだ人がどう感じるかを考えなかったのだろうかと思ってしまいます。
上記に挙げたツールでは、こうしたとんでもないコードに対して警告を発してくれます。静的な解析であるにせよ、警告は、統計的に不具合が起こりやすかったり、保守・運用性の観点から一般的に許容されない箇所に対して行われます。
後世のエンジニアが読んで拒絶反応を起こさないようなコードをを書くためにも、品質を向上させるためのツールの利用は、リポジトリを作成した直後から利用する必要があるでしょう。これも思いやりがあれば、自然と行うことでしょう。
３つ目は、コードレビューです。
信じられないことに、世の中には、コードレビューなしでリリースされるコードがまだまだあります。
第一に言いたいのは、エンジニアはコードレビューなしでリリースしても良いと絶対に思ってはいけないということです。エンジニアとはそういう職業ではありません。人間は間違える生き物です。それは古今東西当てはまる真理です。
そうした前提に立てば、その間違いをいかに最小限に留めてリリースをするためには、コードレビューは不可欠です。前述のテストコードを書くことや解析ツールを利用することも間違いを未然に防ぐための方法の一つですが、コードレビューも同様です。静的解析では発見できないミスや業務知識が必要とする箇所などは、レビューによって発見しえます。
そして、コードレビューにおいてもう一つ重要なのが共有です。システムは1人で作るものではありません。自分のプライベートなプロジェクトである場合を除き、システムは複数で作り上げるものです。コードレビューをすることで、知識の共有することができます。
エンジニアの中には、1人で作り、他の人に共有しない人がいます。いわゆる属人化です。これはエンジニアに限った話ではないかもしれませんが、仕事を他人に教えず自分しかできないようにして自分の存在意義を高めようとする人は一定数います。そうした属人化は、百害あって一利なしです。もし、1人しかできない仕事だとしたら、その人がいなくなったらどうなるでしょうか？その業務が滞ってしまいます。それは会社にとっては大きなリスクでしかありません。そして、そのような社員はそうしたリスクを考慮しないという点でプロとは言えません。プロフェッショナルは常に様々な状況に対応できるように準備をします。その一つが業務知識の共有であり、エンジニアにとってはコードレビューがその形態の一つです。
人は突然いなくなります。交通事故かもしれません。急に病に侵される場合もあるでしょう。身内の突然な不幸で、１週間出社できないということもあるでしょう。本人が健康でも、他のことで仕事に打ち込めない場合は十分に考えられるのです。
共有ができていれば、仕事ができる状態であっても、他のタスクで手一杯で、他のメンバーの方が余裕があるのであれば、その人に任せることも可能になり、より柔軟なチームを作ることができます。
これも全て「思いやり」があれば容易に想像ができることです。会社への思いやり、経営者への思いやり、突然任されることになるかもしれないまだ見ぬあなたへの思いやり。
エンジニアは、すべからく「思いやり」を持つべきだと私は思います。
それがエンジニアとしての矜持なのではないでしょうか。
自分への自戒も込めて。
本日も、ここまでお読みいただき、ありがとうございました。
という本を読んだ。そこには企業組織がどうあるべきかについて、
