初めに
こんにちは、カンムのpongzuです。
カンム社のアドベントカレンダー day7として、カンムでこれまでにやってきた仕事やその感想等について書きます。
プログラミングを始める前の話
本題に入る前に僕がソフトウェアエンジニアになった経緯について触れたいと思います。
僕がプログラミングを始めたのは、ソフトウェアエンジニアの友人と会った時に、横でコードを書いていて、「それ、楽しいの？」と聞いてみたら、「めっちゃ楽しいから一回やってみたら？今やるなら、Goかな」と言われた事がきっかけでした。就職活動も終盤戦に差し掛かり、進路に悩んでいたタイミングの事でした。
次の日、ProgateでJavaのコースをやってみて、「よく分からないけど面白い。自分が手を動かして作ったプロダクトを多くの人に使ってもらえたら最高なのでは…?」と自分の中に衝撃が走ったのを覚えています。
その後、初心者に優しいと勧められた「スターティングGo言語」を読み始めましたが、この本はプログラミングとは無関係の世界に生きてきた僕にとって非常に難しいものでした。
例えば、最初の方に書いてある「Goをインストールすればバイナリが /usr/local/go にインストールされます」という説明を見た時、当時の自分は /usr/local/go の “/“ って何を表しているんだ…？ バイナリって調べても、0と1で表現されるデータって出てくるけど、これがインストールされると何が起きるんだ…？ というような状態でした。
CSの基礎知識があまりにも欠如していたので 、高速にビルドができるとか、クロスコンパイルが便利といったGoの利点を説明されても全くピンとこないし、その都度調べていては永遠に読み終われないと考えたので、とりあえずProgateでRubyとRoRのコースをやった後に、0からウェブアプリケーションを作る事にしました。
この決断は結果的にすごく良かったと思ってます。
なぜなら、RoRは「内部的にどうなってるか理解はできていないけど何か動く」という感覚ではありますが、CRUDなどのウェブアプリケーションで必要な概念を理解する良い練習になったからです。
このステップを省いてGoで書かれたAPIを読んでも、文法的には理解できるけど、なんのための処理が書かれてあるのかを理解するのに時間がかかったと思います。
こうして１つウェブアプリケーションを作り終えた後に「スターティングGo言語」を読むと、別の本を読んでいるのでは？と思うほどスムーズに理解できたのを覚えています。
その後はGoでCLIを作れるだけ作りながら、net/httpパッケージを使って簡単なAPIを書いたりしていました。このタイミングくらいで、会社に入ってプロダクションコードを書いてみたい欲が出始めていたので、インターンで数社受ける事にしました。
カンムはその時に受けた企業の１つで、面接を終えた後に絶対にここで働きたいと感じたのを覚えています。
その理由は色々ありますが、一番印象的なのが、面接時に佐野さんが「うちはAPIだけでなく、決済プロセッシングシステムも内製化しているんだぜ」ってホワイトボードに書いて説明してくれた時に、「何かやばい人たちだ…超楽しそうだな」と素直に思ったからです。
このような経緯でカンムに入り僕のエンジニアライフが始まりました。
余談ですが、面接で「Goで一番になりたい。とにかく強いエンジニアになって良いプロダクトを作る事が目標です」とか言った気がします…笑
詰まったところ
カンムに入ってまず課題に感じたのが、仕事としてプログラミングをする上で最低限に必要な知識や経験が不足していた事です。
「こまめにGitHubにあげてキリの良いタイミングでPR出してね」と言われたので、コンパイルエラーになる && テストが通ってないとんでもないコードをPRにあげて、「これはなんのためのPRなの？」と言われた時に、「今書いたところまでをとにかく出しました」と言ってhiroakisさんを困らせたり、
丸2日間コミットをせずに編集を加えまくったトップディレクトリで `git checkout .` を叩いて差分を吹き飛ばして号泣したり
とあまりにもひどい有様でした。Gitの使い方に限らず、基礎知識が単語レベルで理解できず、Goも毎回ドキュメントを参照しながら書いていたので、コードを書くというより、殆どググってました。笑
このようにして毎日コードを書き続けてきたので、ある程度Goは書けるようになったと思います。
今の課題は綺麗なテーブル設計、インフラ周りの諸々も含めて一人でなんでもできるようになる事、またその運用等です。
やっている事
最初のタスクはSQLをフォーマットするツールを作ることでした。詳しい事はここに書いています。
フォーマッター作りは、Goを書く（というより、エンジニアとして働く）上で必要な事が多く学べた仕事でした。
インプットとして文字列を与えて、アウトプットして整形された文字列を返すという機能はとてもテストが書きやすいので、「対応できる構文の追加 -> テストの追加 -> 他のテストが落ちる -> 悩む」
というサイクルを永遠に繰り返し、その過程で、「ここはもう少し共通化した方が良いかな？」とか、「そもそも機能追加の度に異なる結果を返す設計ってどうなのか？」など色々な事を考えたり、コードをもっと速く読み書きするための工夫をしてみたりと試行錯誤できたからです。
このタスクは本当に難しくて、hiroakisさんには1日に何度も質問に答えてもらったり、夜遅くもレビューしてもらったりと手厚いヘルプが無かったら永遠に完成してなかったと思います。（まだ修正中）
フォーマッター作りの後は、管理画面を修正したり、アプリと通信するAPIに機能追加をしたりしてます。今後は決済プロセッシングシステムにも手を加える予定で、めちゃくちゃワクワクしているところです。
感じている事
僕がカンムに入って感じた事は大きく分けて以下2点です。
① そんな事まで気にするの？と思うようなユースケースに対応す設計と実装が求られる
カンムでは「ぶつかり」と呼ばれる設計レビュー大会が定期的に開かれ、ユーザが不利益にならないか？後から運用しやすくなっているか？テーブルの用途と命名が正しいか？など設計に穴がないか徹底的に詰めます。
具体的には、
「〜のようなケースの時に問い合わせがあると思うけど、その時にSQLで追える形になっているの？その場合、サポートチームがこのカラムをWHERE句で使うと思うけど、インデックスを貼ってなくて大丈夫？」や、
「リトライが走った時に二重実行がされないようになっている？その時後から如何様にも修正できる構成になってる？」
などです。また、設計だけでなく実装においても、PRに大量にコメントがつきます。直近のパッチでは120件コメントがつきました…笑
② 自分の仕事領域を限定しない
これは多くのカンム社員が既に言っている事ですが、カンムの人は本当になんでもできます。Biz側の人がSQLを書いて分析をしたり、中にはPythonを書いてる人までいます。
エンジニアチームも「これは私の仕事じゃないから知らない」と言わず、フロントエンド、バックエンド関係なくなんでもやられている印象です。だからこそ、上記のサポートチームの目線に立った設計が可能になるのだと思います。
自分の専門領域を極めるだけでなく、垣根を超えて活躍する強さをカンムに入ってから学んでいるような気がします。
最後に
最後まで読んでいただいてありがとうございます。
冒頭にも書きましたが、本記事はカンム社のアドベントカレンダー day7 です。こちらでカンム社員による記事が見れます。
また、カンムにご興味がある方はこちらをチェックお願いします！！
