この記事の内容

この記事は多分とても退屈です。正しい名前付けの記事なのに、口を開けば「仲間」がどうだ「組織」がどうだと、説教じみたことをクドクドと説かれる内容だからです。

しかし、どうしても「正しい名前を付ける」ことと「仲間と共に働く」ということを切り離すことができませんでした。

経験上、自分にとって必要なことはいつも「関心のない場所」に眠っています。もしあなたがこの記事を読んで退屈だと思ったのであれば、もしかするとこの記事はあなたにとって必要なことなのかもしれません。

この記事は「わかりやすさの重要性」と「働くことの本質」の深く知り、なぜ正しい名前を付けることが重要なのか根っこから理解する目的で作成されました。

美しいコードはわかりやすい

「美しいコードを書こう！」プログラマなら誰しも一度は耳にする言葉です。しかし美しいコードとは、いったい何でしょうか。

美しいコードとは、わかりやすさとパフォーマンスの良さを兼ね備えたものです。しかし、今ではパフォーマンスはそれほど考えなくてもよくなりました。

コンピュータの速度はムーアの法則に従い1.5年毎に2倍になります。そのため、現代は昔ほどパフォーマンスを意識してプログラミングする必要性は薄れています。かつてコンピュータに合わせて書いていたコードは、今では人の都合に合わせて書けるようになったのです。

変数や関数の名前付けに苦労を強いられるのはプログラマの宿命と言えます。そして、正しい名前を付けることは「わかりやすさ」を生み出すことの基本となります。当たり前ですよね！

しかし、どうしてそんな苦労してまでコードに美しさ（わかりやすさ）を求めるのでしょうか？どうして時間をかけてまで「わかりやすさ」を向上させることにプログラマはこだわるのでしょう？

その理由は、アウトプットしたものは誰かにインプットされるからであり、我々プログラマは一人で働いているわけではないからです。

働くための連携システム

僕はずっとチームで働くことに煩わしさを感じていました。プロジェクトに他人が関わると、コミュニケーションコストが増大し余計な仕事が増えるからです。

個人で仕事をすることと、複数人で仕事をすることとでは驚くほど働き方が変化します。このことをよく知らず、チーム開発の現場に足を踏み入れギャップに苦しめられる人は少なくありません。

個人での開発は、意思決定や進むべき方向を全て独断で行うことができます。しかし複数で仕事をするとなるとそうはいきません。

チームでの仕事は、互いにストレスなく効率よく働くためのルールや枠組みを必要とします。これは、チームによる開発は、働くためのシステムを別途求められるということです。

プログラマはシステムを構築しますが、働くための枠組みの中ではプログラマもまた「プロジェクトを遂行するシステム」の一部となります。

この、人間を基準としたシステムはリソースを元に自然的に生成されたりします。コミュニティのシステムというものは、コンピュータとは違い、小さな決定や場の空気が日々共有されることで自動プログラミングされる側面があります。

このメタシステムとも言えるコミュニティのシステムですが、このシステムが美しく構築され、日々気持ちよく仕事ができる環境というものはなかなか存在しません。考え方の違いや人間関係、共有物の環境整備など、共に働くシステムを構築することは本質的にとても難しいものです。（これが出来てる企業は絶対デカイと思う）

一緒に働くことは簡単なことではありません。そのため、上手く連携できずストレスとなるのは誰しも一度は経験することです。恐らく、ご自身の体験から「一人で働いたほうが効率がいい」と考える方は、少なくないでしょう。

しかしどうやら世の中を見渡してみると、プログラミングを職に一匹狼でプログラマをしている人はかなり珍しいようです。

たとえ、一人で働いたほうが効率がいいという話が真実だとしても、他の技術者が関わる現場に巻き込まれることは十分に起こりえます。どうやら私たちは、働くためのシステムの上で働くことを避けられないようです。

であれば「一緒に働くこと」をもう少しよく知っておく必要がありそうです。世界中の人が共同で働いていることには何か理由があり、そこには必ずメリットがあります。

そして、それらをよく理解した上でそのメリットを最大限に活かすことが賢い選択と言えそうです。

仲間と働くメリット

「3人寄れば文殊の知恵」というコトワザがあるように、チームで働くことは知恵を増幅させます。ヒトリの頭脳では偏りがちな考えや思考漏れを防ぎ、より適切な判断を下すことができます。チームでの仕事は、会議や打ち合わせを楽しく進行できるだけでなく、共に考えることでヒトリにかかる脳みその負荷を減少します。

次に、チームで働くことは、確認、点検、チェックの精度を高めます。自分が出力したものを自分自身でチェックするという行為は、スコトーマ(盲点)に陥りがちで、気がつかないものです。それらを確認してくれる仲間がいるというのは、事故やミスを防ぐことに貢献します。

また、チームは仕事を並列遂行させることができます。一人で働くことには限界があり、書類の内容を熟読しながら、同時にプログラミングするというような芸当はできません。仲間がいるとヒトリでは不可能な並列遂行ができるようになります。

責任に関しても仲間の存在は有難いものです。一人で仕事をしていて計画的ミスを負った場合、その責任は全て自分に降り注ぎます。しかし、仲間と相談して決定した組織の計画の中で発生した問題は組織の責任となり、責任が個人に集中することはありません。

個人の失敗はモチベーションを大幅に削ぐものですが、組織の失敗はそれを補うために結団力を生み出します。トラブルが発生した時は、その問題にどう向き合うか仲間と相談することで共に解決に向かうことができます。仲間の存在は、モチベーションに大きく影響し、助け合い共に成長していけるというのは、意識を大きく向上させます。

つまり、仲間と働くことのメリットは以下が得られることにあります。

• 知恵の増幅
• 事故やミスの防止
• 並列遂行
• 責任の分散
• 意識の向上

これらのメリットを見て「そんな仲間は漫画やアニメの世界にしかいない！」と思われた方がほとんどではないでしょうか？

煩わしさは無く、お互いに意識を高めることができ、チームワークを発揮して効率良く仕事をこなし、問題が発生した時は真剣に向き合ってくれるだけでなく、普段から目標に向かって助け合いながら歩んでいける仲間...確かに夢のような存在です。

実際、チームのメリットを発揮するためには根本的に良質な仲間が必要であり、そのような仲間を見つけることは容易ではありません。

しかし、もしあなたがこの記事を見て「そんな仲間いたら素敵だな」と思ったならば、あなた自身は誰かにとっての良質な仲間となり得るのではないでしょうか？

仲間と働くということは本当に困難なことです。しかし、仲間なくして出来ることには限界があり、良質なチームはヒトリの限界を突破するのです。

どうやらメリットを引き出せる場合、仲間と働くほうがヒトリよりも強い力を発揮できるようです。

プログラマはドキュメンター

つらつらと仲間に関する話を続けてますが、そろそろコードの話に戻しましょう。

コードは書く時間より読む時間の方が圧倒的に多いです。たとえヒトリで働いていたとしても、その事実は変わりません。目を閉じたままコード書くことができないのは、コードを書いている時もコードを読んでいるからです。

あなたが書いたコードは、コンピュータに読まれ、同僚に読まれ、まだ居ぬ新人に読まれ、数年後の自分に読まれます。クライアントに読まれるかもしれませんし、一般公開した場合は、世界中の人々の目に止まります。基本的に、あなたが書いたコードは誰かに読まれるのです。

コードは機械を動かすためのものであると思われがちですが、仲間と働いている場合はそれ以上にコードは「人のための読み物」となります。つまり、コードは具象度MAXのシステムの説明書なのです。

ですから、我々プログラマはドキュメントを作成するドキュメンターという事になりますね。

え、ちょっと待ってよ！俺プログラマだよ？ドキュメントなんか作らないよ！と思われるかもしれません。しかしよく考えて見てください。

コードに書くコメントは人間のために存在し、コードの「わかりやすさ」を向上させる代物です。コメントを書いたことのないプログラマは居ませんから「コードはドキュメントである」という認識は本来誰しもが持っているはずです。そして、コメントの存在はコードをよりドキュメントたらしめていますよね。

実はこれ、コードに限った話ではありません。あなたが書いた文章や図や表、何らかのアウトプットしたコンテンツは基本的に全て読み物であり、誰かにインプットされるドキュメントです。

プログラマはドキュメンターですから、プログラマが作成すべきドキュメントはソースだけではありません。システム概要、導入手順書、利用ライブラリ一覧、ディレクトリ構造解説、DB設計書、設計哲学、クラスリファレンス、などなど様々なドキュメントの作成を必要とします。

正直なところ、コードを書く時間よりこれらドキュメントを作成する方が圧倒的に時間がかかります。そしてこれらドキュメントの存在が運命共同体とも言える仲間の運命を大きく左右するのです。

醜いアウトプットの罪

わかりにくいものをアウトプットするということは、多くの読者に混乱やストレス、分からない箇所の解析や調査の必要性といった非効率性やボトルネックという損害を与えます。

そしてほとんどの場合、この大きな損害はアウトプットした人が「ま、いいか」と数分数秒の手間を怠ったことで発生します。そしてその被害を第一に受けるのがチームの人間です。

醜いアウトプットは、チームで働くことのメリット（知恵の増幅、事故やミスの防止、並列遂行、責任の分散、意識の向上）を失うばかりでなく、非効率な仕事やコミュニケーションコストを増大し、最悪「一人で働いたほうがマシ」といった状況を作り出します。

誰が書いたかわからん滅茶苦茶なプログラムと何ヶ月も睨めっこして「これ全部書き直したほうが早いよォォォ！！」と発狂するのは、プログラマなら誰しも経験があることです。

とある国では「俺が食べるわけじゃないからいいや！」といった気持ちで肉饅にダンボールを入れたり、「俺が使うわけじゃないからいいや！」というスタンスで、便器のブラシでグラスを磨いたりするそうです。

この話を聞いた世間はざわつくものですが、汚れたコードが量産されることに対して世間は無関心です。それがニュースに取り上げられたり、ネットで騒がれたりするようなことはありません。僕は時々、プログラムに物理的衛生面が無いことや、目に見えない代物であることに嫌気がさします。

たった一人の人間が生み出した「醜いアウトプット」によって、多くの関係者が苦しめられます。ときにそれは病を引き起こしたり、自殺に追い込むこともあるほどです（いやマジで！）

1分の手間を抜いたことで、それを理解するのに120分時間を要する場合、チームが8名居たら合計で960分もの仲間の時間を奪うことになります。しかもこれ、関わる人の数が増えれば増えるほど掛け算で増えていきますよね。

むかし、半年解析してもシステムの全体像が掴めないスパゲッティプロジェクトに関わったことがありました。僕はこのシステムが、どれだけのボトルネックを生み出しているのか計算するのも恐ろしいです。

美しいアウトプットは人々を幸福にしますが、醜いアウトプットは人々を不幸に陥れます。そしてその不幸は仲間に伝染し、回り回って自分に巡ってくるでしょう。組織を不幸に陥れた自身も組織の人間ですから。

「わかりにくいもの」をアウトプットするという行為は、想像以上に重大な罪であり「コードはコンピュータが解釈するもの」という偏った考えは、仲間と働く仕組みを崩壊させます。プログラマがメンテナンスすべきシステムは、もはやコンピュータシステムだけではないのです。

テキスト不要のわかりやすさ

働くためのシステムを崩壊させないために、わかりやすいドキュメントを作成することの重要性をお伝えしましたが、ここで衝撃的な事実をお伝えします！

実は可能な限り「ドキュメントは無いほうがいい」のです。なぜなら、本当の美しさとはiPhoneのように説明が無くとも直感的に理解できることだからです。

究極のわかりやすさは「思考コストが低く、素早く広まる」という性質があります。そしてこの性質はデザインによって生み出されます。

誰が見ても直感的にわかるモノを作り出すことは容易ではありません。美しいデザインとは繰り返し思考して反映することでしか得られないものです。

デザインとは、目的を達成するために人間をプログラミング（誘導）するということです。もし、コンピュータをプログラムするのと同じように人間をプログラムすることができたら驚異的だと感じませんか。

プログラムは機械を動かすものですから、人間は関係ないように思えるかもしれません。しかし、機械は人のために存在しているため、プログラマがプログラミングするべき対象は、もはや機械ではなく人間です。我々はプログラミングによって機械を操っているように思えますが、実際は我々のプログラムに関わる人を操っているのです。

プログラムは機械を通して人間を操りますが、デザインは人間を直接的にプログラミングします。そのパワーを引き出すためには「わかりやすいもの」「考えなくともわかるもの」「自然とそうしてしまうもの」「さも自分で思いついたような錯覚を与えるもの」を作らなければなりません。

そして、デザインによって究極のわかりやすさを手に入れたものは拡散力を得て広がります。（普及すると皆の共通のインターフェースとなって、更なる利便性を生み出す特典付き！）

コメントやドキュメントの話をしていたため「わかりやすい文章を書く」ということに意識を向かわせてしまいましたが、本当のわかりやすさとは根本的にテキストを必要としないのです。

ピクトグラムとUI/UX

昔のアプリケーションは基本的に情報配置やレスポンスが悪く、自転車のように滑らかに動かせる代物ではありませんでした。コンピュータゲームでさえ昔はレスポンスが悪かったほどです。（滑らかゲームの代表格はファミコンの登場からです。）

しかし、iPhoneの登場によってその常識が覆され、コンピュータシステムはゲームのように直感的にコントロールできるものとなりました。もちろん、iPhone登場以前からもそういったものはありますが、直感性や滑らかさが大きくアプリケーションの世界で意識され始めたのはiPhoneの登場からでしょう。

デザインという言葉は時と場合によって意味が変化するためその本質が分かりにくいものです。しかし簡単に言ってしまえばデザインとはUI/UXのことです。

UIとは扉に取り付けられた取っ手など、情報源としてユーザに接触する部分のことをいいます。そしてUXはユーザ体験のことを指します。単に接触と接触して得られるフィードバックと考えてしまって構いません。

僕はデザインを意識して様々なものを見てきましたが、ほとんどの場合正しい情報の配置がなされていないためにわかりにくいデザインとなっているものが本当に多いです。

たとえば、関連の強い項目が離れ離れになっていたり、右から読ませたり上から読ませたり、あちらこちらに飛び回る作りになっていたり、余白が無いために関連のない情報に不要なつながりを持たせてしまうなど、様々です。

デザインには守らなければならないルールがあります。そしてわかりやすさに貢献するものとして、様々な意味を持ったアイコン（ピクトグラム）もまた意識されてきました。

今では「回転矢印マーク」を見れば誰もが「更新」であると認識でき、これらアイコンは自然言語を超えて人々の理解に貢献します。

なるほど！わかりやすいドキュメントも大切だけど、デザインはドキュメントを使わずにユーザに意図を伝えることができるのか！そしてアイコンは世界共通の言語であると！スゲー！！

確かにアイコンは素晴らしく、明確な意図を瞬時に伝え、直感性に大きく貢献するためデザインに欠かせないものです。しかし複雑な意図をアイコンに詰め込むことはできません。

アイコンに置き換えることのできない意図はどうしたらユーザに伝えられるのでしょうか？

正しい名前をつける

名は体を表すという言葉がある通り、説明しなくとも分かるというのは、そのものの名前が適切であることが多いです。

例えば「栓抜き」という道具がありますが、名前の通り「栓を抜くための道具」です。もしも栓抜きの名前が「アイウエオパーイパイ」だったら、栓を抜く時にアイウエオパーイパイを使おうと判断するには思考コストを必要とします。しかし「栓抜き」であれば「栓を抜きたい、栓抜きが必要だ」とスムーズに連想できます。

デザインは人間をプログラミング（誘導）するという話をさせていただきましたが、名前もまた人々の意識に強く働きかけます。しかも名前はアイコンと違って複雑な意図も明確に伝えられるのです。

美しいコードを書こう！という話をしましたが、実のところ「わかりやすいコード」は適切なファイル名とディレクトリ構造をもったプログラムを言います。（もはや中身のコード関係ないじゃん！）

かつて、優秀なプログラマさんが構築したシステムに携わった時、プロジェクトのファイル名とディレクトリ構造が適切だったため、中身を確認しなくとも全体像が把握できる素晴らしい現場に立ち会ったことがあります。（クラス図とかもあったけどほとんど見てない）

そのプログラマさんは僕に「おお！よく分かってるね！ちゃんとソースを読み込んでる様子がうかがえるよ」なんて言ってましたがゴメンナサイw 全く読んでません。

このような素晴らしいことが起こったのは決して僕が優れてた読解力があるからではありません。適切に名前付けされたものは、ドキュメントよりも明確で、アイコンとは比較にならない情報量を持たせることができます。

ディレクトリ構造のわかりやすさは、まさに適切な名前付けでしか表せないものです。「わかりやすさ」の奥義とは、そのものに正しい名前をつけることなのです。

もしもread()というメソッドが、なぜかプロパティの初期化を行うメソッドだったらどうでしょう？まともにプログラミングできなくなり現場の空気が悪くなることは想像に容易いです。

目に見えないプログラムの世界で「名前」はそのものの印象となります。美しさとは、機能や役割が名前通り一致しており、適切に分類されていることを言います。

デザインは直感的理解に大きく貢献するものですが、デザインされたものに正しい名前をつけなければ全て台無しであり、正しい前付けは「わかりやすさ」の貢献につながる最も重要な要素なのです。

時間との均衡点

ここまでわかりやすさについて話してきましたがもう一つ大切なことをお伝えします。「時間」です！

もしも飲食店で注文した料理が「せっかくきてくれたお客さんだ！とびきり美味しい食事を提供しよう！」といった身勝手な考えで、1時間以上待たされるようなことがあったら、たとえ美味しかったとしても「二度と利用するもんか！」と鼻息を荒くして店を後にすることでしょう。

約束を果たさない人間は信用を失うことは当然で、遅すぎたり期限に間に合わないことは、相手の予定を狂わし多大な迷惑をかけます。逆にレスポンスが早いことはボトルネックを緩和し活力となるものです。

「わかりやすいもの」を作るということは時間のかかる行為ですが、「わかりやすさ」に囚われすぎて時間を蔑ろにすると、せっかく時間をかけて生み出した価値が失われることがあります。

ですから、場合により「わかりやすさ」を犠牲にしてスピードを優先しなければならないことがあります。わかりやすさとスピードとの均衡点の見極めを誤ってはいけません。

ほとんどの場合スピードが要求され、そしてスピードを優先しすぎてできた身勝手なコードやドキュメントはボトルネックを生み出します。

ですから、そのようなものを作った場合は「いま自分は未来の悪魔を生み出している」という意識を持ち、後で必ず退治することを胸に刻まなければなりません。（予言しよう！仕事は次から次へと舞い降り、君が胸に刻んだそれは忘れ去れれるだろう！）

スピードの重要性については、世間ではほとんどの人が理解しています。しかし長期的に考えたときに重要となるのはスピードよりも「わかりやすさ」です。このことについて理解のない組織に未来はありません。

まとめ

仲間と共に働くとことは個人に比べ驚くほど働き方に変化が生じます。共に働くことは「連携システム」を必要とし自らがそのシステムの一部となって配慮する必要が生まれるからです。仲間と働くメリットを活かすことができれば、個人とは比べ物にならないパワーを発揮することができます。

プログラマはコンピュータに指示する仕事と思われがちですが、コードは「具象度MAXのシステムの説明書」であり、プログラマは本質的にドキュメンターです。ですから我々はソースコードに限らず、全てのドキュメントに美しさ（わかりやすさ）を考慮して作成しなければなりません。

コンピュータは「詳細な情報」により動作しますが、人間は「わかりやすい情報」に影響されて動作します。ですから、仲間と働くメリットを最大限に活かすためにまず「仲間に対してわかりやすいものをアウトプットする」ことが重要なのです。

ドキュメントは重要ですが、本当のわかりやすさとはテキスト必要としないものです。この優れたわかりやすさは、デザインすることによって作り出すことができます。デザインは明確さと直感性を生み出しますが、複雑な意図を伝えることに不向きです。

そこで「正しい名前付け」です。正しい名前付けは、わかりやすさに最も貢献する要素であり基本にして奥義なのです。

忘れてはならないのがスピードです。わかりやすさは仲間に対する配慮と言えますが、レスポンス速度もまた仲間に対する配慮となります。求められていることがいつまでも終わらないと言う状況は、仲間の予定を大きく狂わせるため、わかりにくさ同様のボトルネックを生み出す可能性があるだけでなく、場合により破壊的なリスクを生み出すこともあります。

ですから、わかりやすさとスピードの均衡点を誤らないことが最も価値ある仕事を生み出すと言うことになります。

仕事の本質とは、目的のために「わかりやすさ」を生み出し人間を誘導することにあります。この、わかりやすさを生み出すために必要なことは「デザイン」と「正しい名前付け」なのです。（ここでデザインの本質がカプセル化であり、オブジェクト指向の心得と一緒じゃん！と思った人はイケメン）

神の力とも言える「人間のプログラミング」は、正しい名前をつけることから生まれます。優秀なプログラマはコンピュータだけでなく、人間をもプログラミングするのです。