2018年12月21日
チャレンジして成長したい人のための
日本の大企業がプログラムのコードレビューを体系化するのは困難か
これって、会社員の方にとってあるあるネタじゃないですかね？？？
サラリーマン報告書あるある
課長のチェックで修正した箇所が、部長のチェックで再修正を受ける。
↓
上司たちの方向性の違いに辟易する若手社員「自分が書いた表現に戻ってるじゃん！」こんな経験ある人いますよね？ね？
— ikki@スタイリッシュ生活 (@motto_stylish) February 24, 2018
そう思って探してみると、似たような経験をしている人はちらほら。
報告書とかも上司に全部直されて心折れるときあるよね…幸いにしてそこまで酷いことは私はなかったけど
いちばん辛かった記憶は課長と部長の直しの方向性が真逆でそんとき中国にいた課長と電話して直した書類を部長に直された件をまた課長に電話するを繰り返す午前１時…
最終的に直接喧嘩してもらたw— らいちょうのさと (@margaret_merq) December 27, 2017
とか、
昔あった実話。
上司の課長に報告書Ver.1提出するも数度の手直し指示。
Ver.4でOK出てそれを部長に提出するも数度の手直し指示。
Ver.8でOK出てそれを役員に提出するも数度の手直し指示。
Ver.12でOK出てようやく稟議が下りた。
結果Ver.1と12がほぼ同一…。
報告書のテーマは生産性改革案でした。— Dai (@dai_machinist) December 24, 2017
お疲れ様です！
報告書やレポートの類が社員で共有されて活用されている会社は素晴らしいと思います。
そんな中、専門的なプログラマーたちにとっては当然行なっているプログラムのコードレビューについて、一部の大企業や古い体質の企業は体系的にできていないだろうなと思ったので、そのあたりを書いてみます。
増加するプログラマー
世の中の技術革新が進むにつれて、大なり小なりプログラミングに触れる会社員の人数って増えてきてますよね？
で、ある程度 社内にプログラミング経験者やソースコードが増えてくると、効率化の動きが出てくるはずなんです。
共有化できるところは共有化しようとか、他人が読めるようにこれからコーディング規約を導入しようとか。
でも、大きい会社って色んな会社を相手にして、色んなプロジェクトが並行して進んだりしているので結局は案件ごとに部分最適になるように進んでいき、結局、全体最適になるような効率化はいつまでも進まない的な感じかと予想します。
大きな会社ほどこういう動きは進めにくいと思いますが、逆にいうと小さなベンチャー企業やこれから作られる会社はその辺をしっかりしてスタートアップできるように準備できるので強そうです。
効率が段違いのはずです。
社内の無駄を排除するために、プログラミングのコード共有や、イチからプログラマを育成するにはどうしたら良いか？
まずは、これから作られるソースコードに対してコードレビューを行うと良いかもしれません。
コードレビューってどうやるの？
プログラミングの経験が浅い企業の方はこんな風に考える方もいらっしゃるかもしれません。
コードレビューの仕組み自体は難しくないと思うんです。
だって、考え方の基本は報告書のレビューと同じなのですから。
どこの会社でも、ノウハウを蓄積していくためにレポート・報告書をまとめて保管することってやってますよね？
その際、社員が書いた書類は上司がチェックしますよね。
簡単に例をまとめるとこんな感じでしょうか。
| 文書のレビュー | コードレビュー | |
|---|---|---|
| 機能 | 主張・結論が明確になっているか | エラーなく実行可能か |
| 全体のバランス | 読みやすい構成にまとまっているか | 読みやすい構成にまとまっているか |
| １文の長さ | だらだら長い文になっていないか | だらだら長い文になっていないか |
| 無駄な要素 | 不要な言葉が無いか・ 表現が冗長でないか | 不要な変数が無いか・ 冗長なコードでないか |
| 誤解を招く要素 | 誤解のない説明になっているか | 誤解のない変数名になっているか |
文書でもソースコードでも、基本的には文字のみで考え方や機能を表現しているので、レビューのポイントって同じなんです。
全体の構成を見る上では、パラグラフの配置（コード内だと関数の配置とかか。）や論理展開などは共通しています。
でも当然の事ながら、詳細な部分をチェックするのに必要なスキルは異なってきます。
日本語、C言語、JavaScript、Ruby、Python、PHPなど細かい表現は各言語で変わりますからね。
仕組みは似ているのですが、あなたの会社でできそうですか？
難しいですよね？
報告書の場合
報告書の文章を適切にレビューできる人は、きっと適切な日本語や、わかりやすい報告書の構成など、文書作成に長けているはずです。
これには日本語の作文技術というスキルが必要になります。
複数の上司がチェックをするとしたら、この記事の冒頭で挙げたように修正の方向性も同じでいてもらわないと、レビューを受ける側はどっち寄りで書けばよいか迷ってしまいます。
というか、必ずどちらかから修正を受けるので、書き始める頃からゲンナリしてしまうでしょうね。
とってもやるせ無い気持ちになってしまいます。
分かりやすい文書とは何かを知りたい方は、このような本がオススメです。
コードレビューの場合
コードレビューの方では、読んで理解しやすいソースコードとは何かわかっている人で、プログラム作成に長けている必要があります。
今の世の中、そんな上司に巡り会える若手社員がどれだけいるか、という話です。
Windows95が登場したのが、２０１８年から遡ること２３年前。
ということは、３０年前に入社した会社員の方はパソコン作業なんてほとんどなかったのだと予想されます。
ある程度は仕方ないのかもしれませんね。
とっても大きな壁が立ちはだかってそうです。
ジェネレーションギャップです。
パソコンとかプログラムって、物心ついた時からパソコンに触れられた若い世代の方がスキルがあって当然の分野かもしれません。
文書スキルは上司が上でも、プログラミングスキルでは若手社員の方が上。
詰まるところ、コードレビューを体系的に行える大企業がこの世界にどれだけあるかって話です。
プログラム書いても、しっかりレビューできる人がいません。
読みやすいコードとは何かを知りたい方は、このような本がオススメです。
Dustin Boswell,Trevor Foucher オライリージャパン 2012-06-23
プログラマーはプログラムを書きましょう
少し話は逸れるかもしれませんが、プログラムの説明書なんて作成していませんか？
プログラムの内容を説明するために、別の文書を作成するのは２度手間です。
（報告書を説明するための文書、と考えると無駄さが伝わりますかね？）
だって、絶え間なくアップデートされていく（理解不能な）プログラムを書いているとしたら、説明書の方も絶え間なくアップデートしないと使う側は使えません。
とすると単純計算で、プログラマーがコーディングできる時間が半分になってしまいます。
工数が２倍かかります。
溶接士に溶接以外の仕事を沢山やらせているようなもんです。
医者が治療以外の事務作業を沢山やっているようなもんです。
もったいないですねぇ。
終わりに
これからの日本は徐々に、プログラム書いてる世代が課長・部長となっていきます。
文書スキルもプログラムスキルも兼ね備えた人が管理職が会社で活躍しているでしょう。
（でも、本当に凄い人達は自分で起業してる可能性もありますが。）
報告書でもプログラムのコードでも、会社の中の集団知を共有化し業務効率を向上できるかどうかが、今後発展する会社かどうかの判断基準になるかもしれません。
優秀な人材を流出させている場合じゃないです。
時代は変わった、と感じざるを得ませんが、それはこれから先も続いていくでしょうね。
今の子供たちは逆に、パソコンに触れていないかもしれません。
スマホ・タブレットの時代です。
その後は、どうなるか分かりません。
気づいている人は、研鑽あるのみです。
自分の働き方は自分で改革したい、スタイリッシュ生活を手に入れたい方は一緒に頑張りましょう！
関連記事
Profile
湘南住まいの ikki (@motto_stylish)です。
大学では器械体操部で、大企業からの転職を経て、現在はリモートプログラマー。
毎日の少しずつの工夫で、明日をもっとスタイリッシュな生活にしていきましょう。
