概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Why We Argue: Style — Sandi Metz
- 原文公開日: 2017/06/01
- 著者: Sandi Metz -- 名著『オブジェクト指向設計実践ガイド』の著者です。
コーディングスタイルで社内が揉める理由（翻訳）
本記事は私のChainline Newsletterで最初に公開いたしました。
私は長年の間、コードのことで議論になるのはなぜなのか、そして決定的に食い違う意見を建設的な方向に転換する方法はないものかと模索してきました。
私の見解は、非常に特異な文脈の中から生まれました。私は、ありとあらゆる業種の企業に出向き、数日間に渡るオブジェクト指向設計の講義を年に10回から12回は繰り返しています。私は部外者ではありますが、そうした場所で数日間を過ごすだけでも企業の裏舞台の一端を垣間見られます。
そのときに気づいたのですが、ある場所では誰もがおおむね幸せそうにしています。そういう場所ではプログラマーもうまくやっていて、一同は「連帯している」ように感じています。こういう場では、私の業務時間のほとんどを実際にオブジェクト指向設計の講義に充てられます。
かと思うと、社員一同が驚くほど惨めな状況に陥っているような場所もあります。社内のあちこちで意見の相違が噴き出し、プログラマーたちも「派閥」争いに巻き込まれてしまっています。そんな状況でのオブジェクト指向設計の講義は、根深い衝突をどうやって解決するかを広範囲に渡って議論するグループディスカッションの場に変わってしまいます。
トルストイの「幸せな家庭はどこも似たようなものだが、不幸な家庭はそれぞれ独特の不幸を抱えているものだ」という有名な成句は、アンナ・カレーニナの原則として知られています。そしてこの法則は、成功を収めるには膨大な判断基準をすべて満たす必要があることを示しています。幸せになる唯一の道は、そのひとつひとつを満たすことです。残念なことに、そうした判断基準のたったひとつが満たされないだけでも不幸は訪れます。すなわち、幸せな企業はどこも似たようなものですが、不幸な企業はいずれもオリジナリティにあふれた独自の不幸を体現しているのです。
相当な数の講義をこなすうちに、私はさまざまな「不幸の塊」のような職場を体験し、そして幸せとは何かを判断するためのいくつかの共通基準というものを理解し始めました。本ニュースレターでは、その中から1つだけを取り上げてみたいと思います。残りについては今後のニュースレターで扱います。
私が今回取り上げてみたいお題は「構文（syntax）の選択」です。自分の職場がスタイルガイドに同意し、それに従うかどうか、といった問題です。私がこんな世俗的と思える話題について書き始めるのを見て驚く方は、幸運にも今のあなたの職場はよい文法を選択しているとお考えください。悲しげに首を振りながら、この話題の重要性に同意いただいているそこのあなた、心から痛み入ります。
なぜスタイルガイドというものがあるのか？
私が個人的に吟味しなければならないあらゆるコードは、一貫した書式で私の前に現れるべきであると、固く信じています。コードは書かれる回数より読まれる回数の方がずっと多いのですから、コードの最終的なコストは読むときに発生するということになります。そこから、コードは読みやすさのために最適化すべきであるという結論、ひいてはアプリのコードはすべて同じスタイルで統一されるべきであるという決定が導かれます。共通のスタイルに合わせることで、コストを削減します。
ではどのスタイルがベストなのか？
ここまでの話にはほとんどのプログラマーが同意してくれるのですが、ここからが分裂の始まりです。私が考える範囲では、私の個人的なコーディングスタイルこそが明らかにベストだと思うのですが、きっと他の人も自分のコーディングスタイルがベストだと思っていることでしょう。プログラマーのチームにとって、すべてのコードでスタイルを共通のものに揃えるべきであることに同意するところまでは簡単なのですが、そこから共通のスタイルをどれに定めるべきかという段になると驚くほど困難になります。
コーディングスタイル上の選択の大半は（必須ではなく）任意であり、まったく個人の好み次第であることは間違いありません。スタイルガイドを選択するということは、些細な点で意見が真っ二つに分かれるような分野で合意を形成するということです。スタイルそのものが重要なのではなく、スタイルを揃えることが重要なのです。
なぜチーム内で意見が割れるのか
前述したとおり、スタイルガイドがなければ即コストに跳ね返ります。しかし、あるスタイルに反対する人には、反対することで自分の問題を最小限にできるというゴネ得の可能性があります。
私はこれまでに、スタイルガイドの合意形成に失敗してチームが分裂してしまった企業をいくつも訪れました。そこにいるプログラマーたちは口頭での交渉を随分前に諦めてしまい、代わりに変更リクエストを言い訳にして変更箇所の周辺を自分好みのスタイルに変えてしまっていました。コードは競合するスタイルの間で行ったり来たりを繰り返すはめになります。これでは実際の振る舞いがどう変わるかを把握することが難しくなるだけでなく、最後にコードに触った人が次回そこを見たときに激怒してしまいます。
こうした「スタイル戦争」は、表向きはコードの書式の問題のようでいて、実際には権力闘争、マウントの取り合いです。もう少し穏やかに言えば、スタイル戦争はチームの緊張感を煽ってコストを増大させます。もっときつい言い方をすれば、スタイル戦争はチームのやる気をごっそり削いでしまいます。
「俺ぐらいのレベルになれば自分流でもいいんじゃね？」
だめです。
ここではまさしく「誰が決定を下すか」が問われているのであり、そのような返答をしていては職場に亀裂を生むだけです。3つのコーディング派閥がそれぞれ異なるスタイルにこだわっているというのはよくある話です。
自分たちが正しいと信じ込んでいる古参プログラマー派閥が独自路線を突っ走るというのもよくある話です。こういう人々は上から目線での支配を目論み、それに失敗すると、今度はグループの合意を無視してもよい権限を与えられたつもりになって勝手に自分たちの好みのスタイルで進めます。こうなっては誰にリストラされるやら、です。
別の言語の経験者たちが古巣のスタイルをRubyに持ち込もうとするのも、これまたよくある話です。彼らは自分たちにとってコードがわかりやすくなるスタイルを選び、その選択によって他のプログラマー全員が困り果ててしまうという事実を無視します。
最後に、スタイルに対する持論が固まっていない新人がいます。新人はあらゆるスタイルをあれこれ実験するので、コードが一貫しないという特徴があります。皮肉抜きで彼らに幸多かれと祈りたくなりますが、他のメンバーは皆混乱に巻き込まれ、後始末に追われます。
ここでご紹介した「あるある」グループは3つだけですが、あなたの職場でこの種の頭の痛い問題が発生していれば、さまざまなスタイル上の争いが勃発している可能性があります。スタイル派閥がひとたび形成されれば、皆てんでに我が道を突っ走り始め、プログラマーの数だけスタイルができあがってしまいます。このような職場では、私が「このコード片だけを見て、これを誰が書いたか当てられますか？」と質問すると、皆口を揃えて「わかるわかる！」と答えるのです。
どのようにしてチームの合意を形成するか
コーディングスタイルの問題は、実際には2つの問題を抱えています。第1に全員の合意を取り付けなければならないこと、第2に全員がそのスタイルに従わなければならないことです。
あなたの職場でコーディングスタイル上の衝突が長年続いているのであれば、スタイルガイドに丸投げするのがベストです。既にコミュニティがスタイルガイドにさんざんマサカリを投げているのですから、同じ努力を繰り返す理由はありません。「Ruby Style Guide」（他の言語でももちろん可）でググってスタイルガイドを何か1つ選択すればよいのです。
訳注: RuboCopベースのスタイルガイドについては【保存版】Rubyスタイルガイドもどうぞ。
外部のスタイルガイドを使えば、内部での無駄な争いを回避してクラウドの知恵を借りることができます。ほとんどのガイドは嬉しい点も残念な点も同じぐらいあるので、どのスタイルを選ぼうとどこかで妥協は必要になります。外部のスタイルガイドを選べば、個人の好みに左右されることも、誰かに一方的に思い通りにされることもなくなります。
スタイルガイドを選定すればおしまいというわけにはいきません。スタイルガイドを定めたら、全員がそれに従わなければなりません。スタイルを徹底する最も簡単な方法は、各自のコードで違反を見つけて警告を発する手順を自動化することです。RubyであればRuboCopを一度チェックしてみましょう。RuboCopは既に設定済みですが、これが最もうまくいくでしょう。
人間による「スタイル警察」は避けましょう。人間スタイル警察が出動すれば、取り締まられる側が機嫌を損ねるだけです。代わりに、コード違反の修正方法をプログラマーに提供しましょう。スタイル違反は、プルリクが送信されるまでに正すべきです。プルリクでの会話は、コードの見た目よりもコードの内容に専念すべきです。
ここでちょっと個人的な話になりますが、私は最近Elm言語を試しています（訳注: ElmはPythonやCoffeeScript風の4スペースによるインデントブロックを採用しています）。何とも座りの良くないRuby流のスタイルではなく、Elmのようなより意識的なコードフォーマットにしたいという思いが募って、エディタに自動Elmフォーマッタをインストールしたのです。当初は自動修正されたコードの見た目に嫌悪感を覚えたものでしたが、ここ数週間のうちに、あれほど積極的にキライだったElmのスタイルをいつしか本気で好きになってしまいました。標準的なElmスタイルに繰り返し接しているうちにじわじわ好みが変わりだし、標準などというものはしょせん自分の慣れでしかないことを自ら証明する形になりました。自分の旧来のやり方を新しい思考法に合わせる方が、その逆よりもずっと簡単なのです。
今あるコードはどうすればいい？
触らないでください。既存のコードのスタイルまで修正する必要などありません。改善するのは今後書くコードの方です。古いコードは、他の理由で手を付けるときまで放っておきましょう。
この戦略の意図は、最も頻繁に使うコードから段階的にスタイルを共通化することです。既存のコードは今後二度と更新されない可能性もあるのですから、誰も顧みないコードなどどうでもよいのです。
手を付ける必要のないコードのスタイルをわざわざ修正するということは、積み残しの作業を片付けるよりも古いコードの見た目を修正する方がビジネス上の価値が高いと宣言しているようなものです（そんなことはありませんよね！）。美観上のためだけに修正することの機会費用には、その間に進められたはずの作業の損失分も含まれます。要は、既に安定している既存コードのスタイルに手を付けないことです（低コストで変更できるなら別ですが）。
新しいスタイルガイドをどうしてもどうしても好きになれないときは？
チームが合意したスタイルガイドをどうしても受け入れたくないのであれば、真っ当な選択肢は2つしかありません。
1つは、その気持をぐっとこらえてスタイルガイドに従うことです。先ほど書いたElmの話でもわかるように、スタイルガイドに従ううちにいつしか自分の考えも変わり、新しいスタイルを好きになるものです。スタイルガイドに実際に従ってコードを書いていれば好きになることは決して不可能ではありません。
さもなければ、そのスタイルガイドには従わないときっぱり腹を決めましょう。そうなれば、今の職を離れて自分好みのスタイルが使える職を探すことになります。新しい職場ではそこのスタイルガイドに従いましょう。
お気づきかと思いますが、どちらの道を進もうと結局何らかのスタイルガイドに従うことになります。「スタイルガイドに従わない」という選択肢はありません。
この話の教訓ですか？自由気ままにコードを書くよりも、すべてのコードのスタイルが揃っていることの方がずっと重要です。スタイルガイドに合意し、それに従いましょう。チームが合意に達しない場合は、その問題からは一歩身を引き、「権力争い」の方を議題に据えて議論を始めましょう。
それでは
Sandi
お知らせ
実用オブジェクト指向設計（POOD）一般向け講座をノースカロライナにて開講
次回の一般向け実用オブジェクト指向設計（POOD）講座は、ノースカロライナ州ダーハムにて5/2〜5/4に開講いたします。同好の士と楽しい3日間を過ごすチャンスです。オブジェクトについての考えががらっと変わる当講座に奮ってご応募ください。
チケットは現在発売中です。売り切れる前にぜひゲットしましょう！
書籍『99 Bottles of OOP』
『99 Bottles of OOP』がついに完成いたしました。現在はバージョン1.0.1をお求めいただけます。本書はKatrina Owenとの共著で、ここ数年は同書の執筆で苦心惨憺の日々を送りました。詳しくは豊富なサンプルページと第三者ブックレビューをじっくりご覧いただき、よろしければぜひお買い求めください。
訳注: もちろん同書は「Ruby Edition」と銘打たれています。