勇者ヒンメルならそう書く、Coding War Gamesに学ぶプログラマーとしてのあり方

みなさんは自分のプログラムに自信がありますか？ここではプログラマの質が、所属する職場や企業に大きな影響を受けるという話をしたいと思います。

ヒンメルならこう書く

もしフリーレンがプログラマになったとき、そのプログラムのコードはきっとヒンメルが書いたものに近い品質のものになるでしょう。

人を大切にするヒンメルであれば、さぞかし他者が読みやすいコードを書いたことでしょう。

そんなヒンメルを見続けたフリーレンも、コーディングをしたらヒンメルと同じような品質になるでしょう。作中でもよく出てきた「ヒンメルならそうする」のようなセリフにもあるように、同じ組織に属している人は、リーダーや組織に影響を受けることがしばしばあります。

今回はなぜヒンメルのプログラムに引っ張られるようなことになるのかをお話したいと思います。

プログラマは職場に影響を受ける

今回の話は、プログラマのコード品質は、「プログラマー個人の腕前より、どのような会社で働いているかのほうが出来に影響を受ける」、というお話です。

Coding War Gamesによる実験

これはトムとティムが1980年代に実施した実験で、92名のプロのプログラマを

• 複数の企業から
• 同じ問題（仕様→コーディング→テストまで）
• 同じ言語
• 同じ環境（支給された仕様・時間）

で実施させた比較実験です。

この実験は2回に渡って実施されていますが、いずれも同じような結果が得られています。
・１回目は166人・35組織
・２回目は600人・92組織
で行われました。結果としてはいずれも各組織・会社ごとに似た点数で固まっていたそうです

実験結果について

各プログラマに大きなスキル差はなく、フェアな状態での実験だったにもかかわらずこの結果には個人のスキル差では説明できないほどの大きな差が発生しました。

• 最も早いチームと最も遅いチームで10倍以上の生産性の差
• 出力されたコードの欠陥数にも大きな差

この差は個人能力とは関係が薄く、所属する職場・企業ごとの「環境特性」に因果関係が見出される結果となりました。

• 同じA社から来たプログラマたち
  • 仕上げが速い人も遅い人も、似たような成績
• 別のB社から来たプログラマたち
  • こちらも同じ成績の傾向が現れる

なぜ「会社ごとに」結果が固まったのか？

著者らの結論はこうあります

プログラマは個人ではなく、
彼らが毎日働いている職場環境(騒音・中断・文化・管理方針)が生産性を決定していた

1. 中断の多さ(Interruptions)
   • 電話・無意味な会議
   • すぐ声をかけてくる上司
   • オープンオフィスの雑音
     などにより”Flow(作業没入状態)”が破壊されている
2. 作業環境（Workspace）
   • 狭い席
   • 周りの雑音
   • 落ち着けない環境
     集中時間の確保が生産性に非常に強く相関
3. 会社文化（Culture）
   • 品質を重視する会社
   • 雑に急かす会社
   • レビューをちゃんとするか
   • テストを重視するか

などが挙げられます。適切な指導などはもちろん重要ではありますが、基本的にはプログラマをのびのびと作業できる環境を与えられているか、というのは重要なファクターになっていますね。

Coding War Gamesに学ぶ自分の環境改善

じゃあうちの職場環境終わってるから頑張っても無理ぢゃん！と諦めるのは簡単です。こういうときのための転職なのかもしれません。ただし所属している会社の中で、やることやってから行動しましょう。出ていくのはそれからでも遅くない・・・と言うか、早すぎると逆に良くないことの方が多いですね。

まずやること。そもそも組織はダメなのか？

会社や組織のせいにするのは非常に簡単です。しかし本当にダメなのかどうか、ちゃんと客観的に評価できていますでしょうか？自分の評価がされていないからといって、それだけうちの組織がダメだ！と思わないように注意してください。

組織の評価についての確認しておきたいポイントを思いつく感じでまとめてみました。

確認項目	説明
自分のコードレビューが行われているかどうか	不明点やコードの書き方についてのレビューが行われているか また、レビューに対して自分はちゃんとコミュニケーションが取れているか
ミーティングなどで提案・発言ができているか	定期的に行われるミーティングなどで、参加者の意見を発言する機会があるかどうか。 ある場合は、自分から何か提案などが行えているか
上司・上長の方と話が十分出来ているか	自分を評価する対象の上司の方と月に１度ぐらいは話が出来ているか 職場改善の提案などをできる関係値を獲得出来ているかが大事
作業スペースは十分か	物理的に空間が狭いと感じたり、周りの音が気にならない状態は保たれているか PCのスペックなど、コードを動かすための環境は問題ないか
作業時間は十分か	自分の参加が必要かどうかよくわかんないミーティングに参加していないか。 ミーティングの時間というのは、気づいたら結構時間取られます。準備や場合によっては移動時間など

確認項目を見て、言うほど引っかるところがないなぁと思った場合はひょっとしたら自分の頑張りが足りてないだけかも・・・

コードの品質を上げる、プルリクエストのレビュー改善

多くの企業では何らかのコードのバージョン管理を行っていると思います。作業をするうえでGithubなどを使っている場合、そのプルリクエストなどをマージするときにコードレビューを行っていると思います。

このときコードレビューをちゃんとやっているでしょうか？これはレビューをする側もされる側も、どちらもしっかりと対応する必要があります。

• プルリクエストを作るとき、説明を十分にしているか
  • 原因・修正方針などを記載する
  • 必要があれば画像などを追加
  • 再現手順などの記載
• 疑問がある場合、レビューコメントで質問が取れているか
  • このときレビュイー（レビューされる側）は指摘されたから直さなきゃ！ではなくコミュニケーションをしっかり取る。
  • 疑問があるだけのときは、コメントでしっかり説明をして理解してもらうように心がける

昨今レビューをしていないところは少ないと思いますが、漫然とせずに細かい積み重ねを行うことでメンバー全体にちゃんと書こう！という意識を共有するのは大事ですね

開発環境の見直し・必要な打ち合わせの精査

続いてプログラマが作業に十分集中できる環境が取れているかどうか。

色々とあるかもしれませんが、私の基準としては１日8時間の業務時間がある場合、4時間以上は一人で黙々と作業ができる時間があるかどうかが一つの基準にしています。このあたりは立場によっても変わるところではありますが、こういった一つの目安を持つと、打ち合わせがどのぐらいで、相談や指導時間があるため自分の時間が十分に取れているかどうかが判断しやすくなります。

また、いろんな打ち合わせに呼ばれるのも、本当に重要かどうかの確認が必要です。皆さんのチームには作業内容を管理するリードプログラマの方はいますでしょうか？可能であればそういったまとめる方に相談・連絡を行うことで、出る必要がない打ち合わせなどにはアサイン自体しないようにお願いできるといいですね。

評価制度や定期面談などの提案・トップダウンで意識を変化させる

みなさんは上司・上長の方とどのぐらい定期的に1on1などを行っていますでしょうか？多すぎても大変ですが、大変ですが１ヶ月に１回ぐらいは話ができているでしょうか？

組織を変えるにはまず自分から！と思いたいところですが、これもなかなかハードルが高い問題です。もっとも簡単なのはトップの人が変化することですが、いきなり言ってもなかなか変わらないことのほうが多いでしょう。

そこで直近の上司の方と話す機会を増やし、組織全体でもっと良くなる提案をして行き、ちょっとずつ変化を開始させることが大事です。

このとき重要なのは「まず自分から変わる・良くなっていく」ということをアクションしなければなりません。所属する組織が変化を起こしづらい状態だとしても、それに流され続けるようではずっと変わらないでしょう。最初はしんどいかもしれませんが、少しずつ提案をしたり、自分の力をちょっとずつでもアピールできるようになり、上司の方からアクションしてもらうのを待ちたいところ。

ここでの注意点は、変化を起こすことに気を取られて、現在の組織体制を無視するような行動を起こすと誰も話を聞いてくれなくなるので気をつけましょう！

色々やったけど変わんねーわ！いざ転職

まぁ一人で、しかも大きな組織であれば色々やっても変わることが少ないですね。いろいろと手を尽くしたけれどもはやここまで！となったら転職も考えましょう。といってもいきなり動くのは愚策。しっかりとやったことをまとめましょう。

組織を変えるためのアクション・具体的にどうした？

転職活動というのは基本的に自分をどこまでアピールできるかという活動です。今回は自分の職場に見切りをつけての転職活動です。理由の一つに「所属している組織では、力が十分に発揮できなかった」「自分が成長出来ない」あたりが含まれることになると思います。もちろんこれだけでは転職活動はうまくいきませんが、まずはこっちの問題について片付けておきましょう。

あなたは先程の行動確認で、組織を変えるためのアクションを行っているはずです。まずはそこで起こした行動を書き出してみましょう。こういった自分のトライした行動というのは結構鮮明に覚えていると思います。

いざ書き出してみたら結構トライしたなぁと感慨深いかもしれません。が！転職活動時にこちらのアクションをメインで話すことは基本的にNGです。

こちらのエピソードに関しては、あくまで補足的に話をするタイミングを伺って、ここぞで話すのがポイントです。

転職先の企業に合わせて、転職理由をまとめる＋組織改革アクション

実際に転職活動を行う場合、次の理由は必ず用意しておく必要があります。

• どうして転職を？
• 元の会社では出来なかった？
• 他社を選ばなかった理由

最低でもこれらは必要で、このあたりは自分のしたいことと相手側の企業でマッチする内容をちゃんと話せるようにしておきましょう。これ事前に転職先の企業を調べて、自分のやりたいことをちゃんと話せる準備をしていないと、面談などの中で矛盾が発生したり、正当な理由として話が出来なくなってしまいます。

そして面談の中で、この質問が来たときがチャンスです！

「あなたが弊社に来たとき、どのようなことが出来ますか？」

これ系の質問が来たときに、組織改革として行ったエピソードを話してみてください。基本的には喜ばれるはずです。

• 組織全体を良くするための提案・行動ができる
• 実際に率先して改善を試みた
• 作業環境の問題点を指摘できる
• それらを行う際、周りのメンバーに反対をされないように進められる

という感じのエピソードを添えてください。「ただの言う事を聞いてれば良い系の作業員が欲しい」ような会社以外だとかなり迎え入れたい人材に近いと思います。

まとめ

プログラマというのは属する組織に大きな影響を受ける生き物です。

それを理解しつつ、まずは組織をちょっとでもよくできる人材になれるよう努力をしましょう！

そしてダメだったときは、その失敗談すらも自分の血肉として次の職場への糧として上手に利用しましょう！