はじめに
私がプログラマーとして働き始めて１年半がたちました。幸いなことに環境に恵まれ、私の身の回りには成果を出し続ける優秀なプログラマーがたくさんいます。
1年半彼らの仕事を観察して気づいたことは、成果を出すプログラマーは共通して 「コードを書かない努力をしている」 ということでした。
この記事では彼らが業務で行なっている、 「コードを書かないための思考、習慣」 についてまとめていきたいと思います。
前提
多くの人は「プログラマーはコードを書くことが仕事」だと考えています。この考えに基づくと、プログラマーが「コードを書かない努力をする」ということが、ひどくおかしなことに思えてしまうかもしれません。
そこでまず前提として3つの誤解を解くところから始めましょう。
[誤解１] プログラマーの仕事は「コードを書くこと」である
私たちプログラマーの多くは会社から給料をもらいながらコードを書いています。そして会社が私たちに給料を払う理由は「私たちが利益を生むことを期待しているから」です。
つまり、私たちの仕事の本質は 「利益をうむこと」 にあり、コードを書くことはその一つの手段に過ぎません。
極端に言えば、成果さえ出せればコードを書く必要はなく、逆にどんなにきれいで高度なコードを書いたとしても、それによって利益が生じなければ、会社が私たちを雇う意味はありません。
[誤解2] 「コードを書くこと」が利益を生む
利益を生むのは常に 「コードを書くという行為」ではなく、「コードを書いた結果の制作物」 です。
コードを書く時間はあくまで成果を出すための過程であり、同じ成果を出せるならその時間は短ければ短いほど効率が良いと言えます。
[誤解3] 「コードを書くこと」はシステムに良い影響を及ぼす
私たちがコードを書くのは、大抵の場合「やろうとしていることが既存のシステムだとできないから」です。
すなわち、コードを書くことは、システムに対して新たな機能、条件を生み出している のと同義です。
いたずらにコードを書くことはシステムの複雑性を上げ、バグや業務ミスの原因になり得ます。
この３つの前提に基づけば、業務において「コードは書く機会は少ないほどいい」ということが、少し理解しやすくなったと思います。
コードを書かないための思考
ここまでは「コードを書かない方がいい理由」を説明してきました。では、具体的にどうすればコードを書くことを回避できるのでしょうか。
私の身の回りのプログラマーは施策の依頼を受けた際、 コードを書く前に以下の４つのステップで施策を評価することから始めていました。
1. 目的にあっているかを判断する
2. 既存のシステムを使ってできないかを判断する
3. ミニマムにできる方法を考える
4. 「資産化」できる方法を考える
以下詳細にそれぞれのステップの考え方について解説をしていきます。
[ステップ１] 目的にあっているかを判断する
「依頼内容が目的とあっていない」ということは意外と多いものです。
例えば以下の例を考えてみましょう。
目的: サイトの回遊率を向上させたい
依頼された施策: ほとんど見られていないページに新たに回遊導線を設ける
このような依頼を受けたら、あなたはどう思いますか？ 多くの人は「そのページを改修しても意味がないのでは...?」と感じるはずです。
上記は極端な例ですが、「プログラマー」という役割意識に縛られると、無思考で頼まれたことをやってしまいがちです。
コーディングを始める前に、まず 「依頼された施策内容は目的とあっているか」 を考えてみましょう。そして施策が目的とあっていないと感じたら、着手する前に依頼者とすり合わせを行ってみましょう。
結果「施策をやる意味がない」という合意がとれれば、あなたはその時間を別の仕事に当てられるはずです。
[ステップ2] 既存のシステムを使ってできないかを判断する
長く続いているシステムであれば、システム内には様々な機能が存在しています。一見新しく感じられる施策も、それらの機能の組み合わせでできてしまうということはよくあります。
新しく機能を作り始める前にまずは 既存の機能の組み合わせで、ノーコードで施策実現できる可能性 を考えてみましょう。
社内の機能の組み合わせで実現が無理でもあきらめてはいけません。世の中には素晴らしいサービスがたくさんあり、その多くでAPIが公開されています。
外部のサービスを使う可能性も考えながら「車輪の再発明」を極力避けるようにしましょう。
[ステップ3] ミニマムにできる方法を考える
企画書には大抵の場合依頼者の理想が詰め込まれています。
依頼されたものをそのまま作るのではなく、まずは 目的に対して必要のない部分を削る ところから始めましょう。ミニマムに作り、計測し、うまく行きそうであれば後から完璧に仕上げればいいのです。
初めから完璧に作り込むべきではないもう一つの理由は 「大抵の企画は失敗するから」 です。企画が失敗し不要になったコードはシステムから消すべきです。ところが、手間をかけて書いたコードは消すための手間もそれなりにかかるものです。
ミニマムな方法を考えることは、 「作る手間を減らし」「（大抵の場合）消す手間を減らす」 という２重の意味で、あなたの工数を大きく減らすでしょう。
[ステップ4] 「資産化」できる方法を考える
以下の例を考えてみましょう
目的: 新商品のPRをしたい
依頼: お客様ページに該当商品のバナーを設置して欲しい
この依頼に対して、「マイページに該当商品のバナーをハードコードする」とどうなるでしょうか。新しい商品が出るたびに、依頼者はあなたにバナーの差し替えを要求してくるはずです。
代わりに、「管理画面から出すバナーを変えられる枠を設置した」場合はどうでしょうか。今後同じような依頼が来ることはなくなるでしょう。
このように、場当たり的なコードではなく、今後似たような作業をする必要のなくなる 「資産」となるコードにできないか を考えてみましょう。
うまく「資産化」されたコードは、将来的にあなたのかけるはずだった工数を大きく減らすはずです。
※ 気をつけなくてはならないのは、「資産化」と「ミニマム」は時に衝突するということです。 まずはミニマムに、うまく行きそうであれば資産化 の順で考えるようにしましょう。
4つの思考をもとに、あなたが今取り組んでいる施策を振り返ってみましょう。あなたが今書いているコードは本当に書く意義のあるコードですか？
コードを書かないための努力
もちろん、これら４つの思考は意識したからといって最初からうまくいくわけではありません。普段から努力を重ね、「コードを書かない思考」ができる地盤を固めることが重要です。
以下ではこの思考をするために、私の身の回りのプログラマーが習慣的に行なっている３つの努力について説明します。
ドメイン知識をつける
「依頼された施策が目的とあっているか」を判断するには、技術だけでなく、会社のビジネスそのものへの理解が必要です。
「ビジネス理解はビジの仕事」という意識を捨て、プログラマーであっても会社の重要な方針や目標は理解するようにしましょう。
簡単に始められる一歩として、何かを頼まれた際に「背景は何か」「目的は何か」を聞き、正しく理解しようとしてみましょう。
職場の仲間との関係性構築
「施策をやる必要があるか」「施策の中で削ぎ落とせる仕様がないか」
こういった議論をするためには 相手との関係性の構築が不可欠 です。関係性のできていない状態で議論を交わしてしまうと、ともすれば相手はあなたが「自分のことが嫌いだから考えを否定をしようとしている」と受け取ってしまうかもしれません。
関係性を構築するにはどうしたら良いでしょうか。まずは 当たり前の礼儀をつくす ところから始めてみましょう。
- 出社した際に挨拶をする
- 相手の目を見て話を聞く
- リモートの会議の際に画面をオンにする
当たり前のことができるようになったら、雑談や飲みに誘ってみましょう。関係性の構築にはお互いの人となりを知ることが大事です。
技術に対する理解を深める
皮肉なことに、「コードを書かない」ためには、技術への理解が不可欠です。様々な技術に精通していてこそ「ある目的を達成するためのミニマムな技術構成」を考えつくことができます。
常に学習を欠かさず、使っている言語やフレームワークの情報をキャッチアップし続けましょう。
おわりに
私が上司から言われた中で非常に深く心に残っている言葉に「我々はプログラマーである前にビジネスマンである」というのがあります。
自らをプログラマーと捉えてしまうと、「コードを書かなくてはならない」という呪縛から逃れられなくなってしまいます。が役割意識に囚われず自らをビジネスマンと考えれば、できることの幅は一気に広がり、成果も出しやすくなるはずです。
まだまだひよっこの２年目ですが、今後も「コードを書かない技術」を身に付け、成果を出すための努力を続けていきます。