プログラミングセンス | プログラマーに必要な10のセンス

今回はプログラマー歴20年以上の僕がプログラミングセンスを解説します。
個人的な意見ですのでご参考まで。

センスよりプログラマーの適正を知りたい方はこちらへどうぞ
プログラマーの適正 – プログラマーに向かない7つのタイプ

概要

プログラミングセンスを10個にバラしてみます。

現実の問題に気付く力
現実の問題を課題に落とし込む力
問題を抽象化し汎用的な問題に落とし込む力
概念や状況をわかりやすく伝える力
効率のよい解決策を考えだす力
効率の良いプログラムを書く力
現象から不具合箇所を想像する力
わかりやすいドキュメントを書く力
効果の高い技術を見つける力
好きであること

「問題」と「課題」という言葉が出てきますが

問題＝あるべき姿と現実のギャップ
課題＝やることリスト

くらいに捉えて読んでいただければ幸いです。

能書き

プログラミングじゃなくね？
と思った方もいらっしゃるかもしれません。
何なら6,7だけじゃね？と思うかもしれません。

答えはノーです。
プログラミングはアナログをデジタルと融合させる技術です。
画面だけ見ているようでは片手落ちです。

世の中の事象すべてに、
人・モノ・カネ・情報の動きがあり原因と結果があります。

我々プログラマーはアナログ世界（物理モデル）を論理モデルに落とし込み
抽象化しデジタルの世界で表現します。

そのため先に列挙したセンスがないと
効率の悪いデジタル世界を作り上げてしまいます。
しかしセンスは鍛えることが可能です。

詳細

1. 現実の問題に気付く力

社会はシステム（ソフトウェアではなく仕組みの話）で動いています。
そのシステムにどんな欠陥があるのか？
何がおきているのか？本来どうあるべきか？
そういうことを考えながら街を散歩すると良いでしょう。

世の中には困りごとがたくさんあります。
一方でプログラマーの仕事はドキュメントに書かれたことを正として実装するケースが多いです。
つまり誰かが定義した「困りごとが何か」「解決策が何か」に対処します。

今はあなたにとってドキュメントに書かれたものが全てかもしれません。
しかし実現したい仕様に対し解決したい現実世界の現象があるはずです。
そこに目を向けるとあなたのセンスはぐっと上がります。

2. 現実の問題を課題に落とし込む力

例えば、部屋の中で火が燃えているのが窓の外から見えてるとしましょう。
しかしそれはただの現象です。

目を背けたりおろおろしたりカーテンで目隠ししたり
やみくもに飛び込んで火を消そうとしたりするのではありません。

あなたの課題（やるべきこと）は何か？

火を消すこと？
火を発生させないこと？
火をうまく使うこと？
燃えない家を作ること？
火で割れない窓を作ること？
火を消す道具を作ること？
火事に遭った人に保険を提供すること？

何でも良いのです。
正解を教えてほしいと思うかもしれませんが正解なんてありません。
あるのは「効果が高いか否か」だけです。

楽しみながらあなたの解くべき課題を探し
あなたの時間の価値を最大限に引き上げるのです。

3. 問題を抽象化し汎用的な問題に落とし込む力

目の前の火を消すだけでは単なる対処です。
類似性のある現象をどこまで想定できるか？

火事・地震・落雷・洪水・ハリケーン・・・
火・水・地・空・風・・・
室内・倉庫内・工場内・店舗内・・・
晴れの日・雨の日・曇りの日・カミナリの日・台風の日・・・
放火によるもの・失火によるもの・事故によるもの・・・

切り口は色々あると思いますが、
結局我々はソフトウェアに働かせるのが仕事です。

一人の困りごとしか解決できないソフトウェアより
多くの人の困りごとを解決できるソフトウェアを作った方が得でしょう。

抽象化してより広範囲に適用できるようにします。
そっちの方が面白いですし。

4. 概念や状況をわかりやすく伝える力

コミュニケーション能力と言ったりしますが、
多くしゃべることではありません。

抽象的な概念や考えといった分かりづらいものを
我々プログラマーはデジタル嫌いに説明することが多いです。

効率よく正確に情報を伝達する力が必要です。
別に声でも文字でも構いません。
文字は再利用できますが、スピードでは声に劣ります。

言語・言い回し・手法・ツール・話の組み立て方
伝える手段をいくつ持ってて何を選択するか。

要は知識です。

5. 効率のよい解決策を考えだす力

プログラマーはソフトウェアを使って問題や課題を解決します。

戦略の失敗は戦術では取り戻せません。
あなたが描いた戦略（解決策）がお粗末なものであったら関係者全員が不幸になります。
効率の良い解決策はひらめくものではありません。
自分の中にストックしている知識を組み合わせるのです。

新聞・事例・書籍・論文・GitHub・他人が書いたソースコード・資格
等様々なところに情報が転がっています。

どれだけ積み上げられるかですね。

6. 効率の良いプログラムを書く力

これは勘違いする人が多いものです。
短く書くことを効率が良いと考える人がいます。

ソフトウェアのライフサイクルは保守期間の方が開発期間に比べ圧倒的に長い。
効率面では読みやすいソースコードが正義です。

コーディング規約
丁寧なコメント
少し遠回りでも理解しやすいコード
組織内で常識となってる暗黙のルール
直属の先輩・上司・リーダー独自のこだわりやルール

こういったものを意識すると良いと思います。

7. 現象から不具合箇所を想像する力

最近の開発環境は優秀で
コンパイルに何時間もかかることはありません。
デバッガもサクサク動きます。

しかしその便利さに頼りすぎてはいけません。
とりあえず実際に動かして不具合箇所を特定しようとする人がいます。

現象や動きから「どういう処理がかかれているのか？」「何が起きているのか？」を想像するようにします。
難しいかもしれませんが訓練です。センスとやらを磨くのに非常に有効な手段です。

頭の中でプログラムを動かすのです。
頭の中のプログラムは現実よりも柔軟で高速に動きます。

8. わかりやすいドキュメントを書く力

プログラマーの9割が苦手なやつです。
ぶっちゃけ僕も苦手です。

しかし繰り返しになりますが
ソフトウェアのライフサイクルは保守期間の方が開発期間に比べ圧倒的に長い
のです。

ソースコードを見た方がマシなドキュメント
ではなく
ソースコードを開かなくても情報が得られるドキュメント
を書いてください。

保守する際に何が必要かを意識して書くと良いでしょう。
ソースコードを開くよりマシかどうかが基準です。

そのドキュメントは「どういう状況で使われるのか」「何のために使われるのか」について考えてみてください。

将来のあなたの一時間は今のあなたの一時間よりも高い価値を持ちます。
優秀な将来の自分が現在の自分に苦しめられないように。

9. 効果の高い技術を見つける力

ソフトウェアは常に進化を続けています。
え？今ってこんな書き方するの？
とか
え？こんな高度なことがたった一行で？
とか、ずっと使ってる言語ですらそう思うことがしょっちゅうです。

今この瞬間にも世界初が実現され無償公開されたりしています。

大量の情報の中から使えるものを見つけ出す力。
運要素も多いですが普段から情報に触れておくことをおススメします。

10. ソフトウェアやものづくりが好きであること

最後は好きであることですね。
好きこそものの上手なれ。

まぁソフトウェアの世界は広いです。
色んな分野のソフトウェアに触れてみると良いでしょう。
これだ！！と思うものが見つかるかもしれません。

目安は「頑張ってる」とか「勉強しないと」と感じないもの。
何となく好きでずっと触ってられるようなものが良いですね。

まとめ

センスというテーマでお話してきましたが、そんな高次元で戦う人はまずいません。
努力しつくした先のお話です。

「お前はセンスがない」とか「プログラミングはセンスだ」とか僕も散々言われました。
そんな語彙力のない指摘は無視しましょう。

ゆめゆめ「センス」という努力不足の泣き言で諦めたりしないように。
コードコンプリートでも読めばよいと思います。

おわり