コードの生み出す価値
4半期の締めが近づいて職場は変な緊張感に包まれてきました。
これも営業やマーケティング担当者と同じチームで仕事をしているからこそ味わえる緊張感だと思います。実際には僕の両隣にディレクターがいて、容赦なくWebサイトの改修依頼が降ってきてます。
ディ「1週間でこのABテストの結果出るから、そのタイミングで次の改修ね」
僕「あれ？スケジュールに実装の期間がとられてないんですけど…？」
ディ「あ…、」
こんな具合でいくつものサイトを回してます。なんだかんだ言いつつも、この状況が面白い理由がいくつかあります。
- 実装時にひらめいたアイデアに対して、ディレクターからソッコーでフィードバックをもらえる
- 自分の仕事がチーム（会社）の予算目標達成にどの程度寄与したか分かりやすい
一つ目がこれまでできなかった理由は、物理的に離れた場所にいることで、フワッと浮いたアイデアや、何となく試しに作ったものについて、フィードバックを受けにくかった、ということがあります。これはかなり大きいメリットで、アイデアって結構熱いうちに叩かないと消えてなくなっちゃうと思うのです。もちろんアイデアブックとかに書き溜めておくって手もあるんですけど、思いたったその瞬間の熱量でって維持できないんですよね。そういう意味でフィードバックを瞬時にもらえる環境ってとても重要だと感じています。
二つ目については、良い意味でカルチャーショックを受けました。僕は転職でSIerから社内SEに転身したんだけども、その時の変化以上に大きな変化をがありました。まず、自分が所属するチームの目標が全く異なるのです。
求められる結果が全て数字（利益）なのです。1.と2.の違いは本質的にはそんなに無くて、顧客が社外の人か社内の人かの違いかな、と思います。要は顧客満足の最大化です。その顧客満足の先にあるものがまさに3.で、「顧客が儲かる▶︎顧客が満足する」ということになります。こうして整理してみると、案外2.と3.に違いが無いように思えます。しかし、現実にはこのワンクッションがあることでビジネスへの熱はかなり冷めてしまうのです。
3.の目標に対してコミットしようとしたとき、これまでの部署で仕事をしている時には無かった考えを常に念頭に置いています。それは、このプログラム一行が、いくらの価値を生み出すのか、を考えて提案、実装することです。プログラミングは僕のスキルのコアであることは間違いありません。しかし、今チームから求められていることはプログラミングをすることではなく、お金を稼ぐことなのです。もちろん必要に応じて今でもかなりの量のプログラムを書いていますし、プログラミングはとても面白いです。でも、そのプログラムが生み出す価値を知るためには、対象のビジネスの仕組みや、チームの強みと弱み、競合他社の状況、業務フローなど、様々なビジネスの要素を理解することが必要なのです。
この「ビジネスを知る」ということがとても面白いのです。お金の流れや、（システム部の、ではなく本当の意味での）顧客との生々しいやり取りの中で、会社としてどんな価値を出すのか、その中で自分が何をするのかということを考えるのです。（もちろんまだまだわからないことだらけですが）
たまには感じたことを書いてみようと思ったらだいぶ長くなってしまった。要は自分の書いたコードがどんな価値を生み出しているのかが分かると、とってもやりがいがあるってことです。
