こんにちは、開発本部の石井です。個人的に関心のある分野に転向するために2022年の7月で退職することになったのですが、これは弊社でやったこと・学んだことをまとめておく良いタイミングなのでは？と思い、退職エントリの形でまとめてみることにしました。
やったこと
入社してから現在までに弊社でやったことについてまとめてみたいと思います。
入社時点で、私はWeb技術のことを何も分かっていませんでした。入社時の挨拶で「走りながら学ぶかんじでいきます」などと言ったような記憶があります。結局、製品の全体像を意識しながら開発を進められるようになるまで１年くらいかかりました。それまでの間(そしてその後も)サポートしてくれた方々には頭が上がらないです。
メール認証の導入
kintone連携サービスの管理画面ログインにいわゆるマジックリンクを使用できるようにしました。
アーキテクチャの複数の層にまたがった変更で、かつJWTやメールなどの仕様をきちんと把握することも必要だったりと大変でした。思うように動作しない原因が実はインフラの設定にあると気づかず、１〜２週間くらいリリースを遅らせたのもいい思い出です。Webの技術要素を広く知ることの大切さを実感できた経験でした。
新型コロナウイルスワクチン予約への対応
新型コロナウイルスの流行に伴い、kViewer・FormBridgeのワクチン予約用途での利用が急増することがありました。
アクセス規模の大きい利用例であり、予期されるリクエストスパイクに備えた対応が迫られました。と同時に、自分が携わっているサービスが多くの人に利用されていることやステークホルダーの存在を意識する出来事でもありました。適切な人に適切な情報を提供することが如何に重要かということを身を以て学びました。
また、ソフトウェアテストを使用した品質担保の重要性を知ったのもちょうどこの時期でした。
Toyokumo kintoneApp認証
kViewerとFormBridgeへのToyokumo kintoneApp認証の導入を行いました。
Toyokumo kintoneApp認証とは、kintone連携製品間をまたがったメールアドレスベースの認証基盤です。この仕組を公開ビューや公開フォームから使えるようにすることで、ビューやフォームの公開先を柔軟に制御することが可能になります。内部的には、複雑なリレーションを含むテーブル設計や多くの実装を必要とする非常に骨のあるリリースでした。幸運にも、私はこのリリースの設計策定段階から参加することができました。設計段階で「SQLアンチパターン」で紹介されているまんまのパターンを踏みそうになって制止が入ったり、実装段階ではフレームワークによる抽象化レイヤーのひとつ下の層にまで潜って問題解決策を探ったりしました。いかにも、自分はソフトウェアエンジニアだなあという気分で仕事をしていた記憶があります。
また、この時期はちょうど新しい開発体制への過渡期でした。タスク管理ツールの導入やデザインチームとの協業体制の策定などが同時に行われ、チーム内外の連携がぎこちなかった印象があります。しかし、完成品はこれらの要素がなければ絶対に叶わなかったクオリティのものとなり、やれば結果になるもんだなあと思いました。
公開ビュー/公開フォームのカスタムURL
公開ビューと公開フォームのURLを、もともとのランダムな文字列から変更できるようにしました。
これまではチームの先輩が決めた方針通りに実装を進めることが多かったのですが、このプロジェクトでは、仕様策定からリリースまでをはじめて自分主導で進めることになりました。ソフトウェアテストやチーム内外の情報共有についてこれまでの経験した学びが活きる場面も多く、私の中でちょっとした記念碑的なプロジェクトになっています。
また、1on1で「この機能に期待してる知り合いがいる」みたいな話を上司から聞いていたのもモチベーションになりました。
学び
在職中の発見や学びは数え切れないほどありますが、その中でも特に覚えておきたいと思ったものを備忘録として残しておきたいと思います。なお、筆者はWebエンジニア歴３年程度の若造ですので、チラ裏程度のつもりでご笑覧ください。
関係者の目線に立つことについて
入社当初、エンジニアとして自分がやるべきことのすべては以下のことだと考えていました。
- 製品をより便利で喜ばれるものに改善する
- 製品に関する質問に答える
極端な話「これを改善したら便利になるんだからいいじゃないか」「聞かれたときに回答できたら十分」などと考えているところがありました。振り返って思うに、入社当初の私には、製品に対する変更が製品を使って仕事をする人の活動に影響を及ぼしているという視点が欠けていました。また、製品に関わる人は使用者だけに留まらないこと、たとえば製品の販売・問い合わせへの対応・未来で開発にジョインするなどの関わり方があるということも、あまり理解していませんでした。これらの人の視点では、たとえば以下のようなことがあるかもしれません。
- ある変更が、その部分を前提とした誰かのワークフローを阻害するかもしれない
- 実装を見ないと分からない知識が、製品を使う上で生じる問題の解決に役立つかもしれない
- +αのソースコードコメントが、誰かがその箇所の影響範囲を正確に把握する助けになるかもしれない
- 仕様や事実よりもその経緯が知りたい場面の方が多いかもしれない
これらをどのような行動につなげるかはおそらくケースバイケースですが、自社のWebサービスをもつ企業で自分が働く上で、財産となる視点を得られた気がしています。
目的をもった勉強について
エンジニアとして働き始める以前の私にとって、技術勉強は自らの好奇心を満足させるためのものでした。しかし、仕事のための勉強の場合はより目的意識をもつことが要求されます。弊社で働く中で、私は以下のような目的で勉強することが有効であることを学びました。
経験を得ること
先人の経験を再利用するための勉強。代表的な例としては、アンチパターンを学んで先人の二の轍を踏まないようにすることなど。
理想像を知ること
たとえば技術設計などにおける理想的な状態を知るための勉強。開発に対して特に主体的だった同僚や先輩は、こうした理想像に関する知識が豊富だった。
自分が"あるある"な失敗をしそうなとき、描いている理想像がズレてるときなどに、関連する技術リファレンス等を紹介してもらえる環境は恵まれていると思います。弊社がそういう環境だったことは、ほぼ未経験だった自分にとってありがたいことでした。
過度な情報共有と注意すべきことについて
入社当初の私のスローガンは「情報過多」でした。これは文字通り「過度に情報を発信しよう」という意識をあらわしていて、その目的は、自分が今何に取り組んでいて、どう対処しようとしていて、何に悩んでいて、どういう発見をしたかということを常にトラッキングできるようすることでした。なぜ過度にやろうと決めたのかというと、経験の浅い新人にとっては報告するべき重要な情報とそうでない情報の見分けがつかないと思ったからです。このアプローチは、たとえば以下のような形で一定の成功をおさめました。
- 想定していた方針が誤っていたときに指摘してもらえた。おかげで、実行する前に軌道修正できた
- よい解決策が思いつかなくて困ったときに詳しい人からコメントをもらえた。おかげで問題に対する理解が深まったり問題が解決したりした
この「情報過多」は方針としては悪くなかったと思っているのですが、現在の私は情報の性質を見極めた上で注意して共有を行う方が適切であると考えています。弊社の業務においては、たとえば以下のような分類と注意点を意識しました。
notificationを伴うもの
急いで対応することが求められる情報、あるいは影響範囲が広い情報の共有。このケースでは、他者の作業に割り込んでしまう可能性がある点に注意する。notificationを伴った情報共有を頻繁に行うことは、生産性を重視する集団ではご法度である。notificationを伴わないもの
誰かがアクセスしたいと思ったときにすぐアクセスできるようにしておく情報の共有。再利用するもの
技術的なtipsや経験から獲得した教訓など。知識にあたるもの。このケースでは、「これらの情報を再利用可能な状態にするのは発信者の責任である」という点に注意する。ただメモしただけの情報は再利用されずに捨てられがちなので、たとえばメタデータをつけるなど、再利用のための工夫が必要である。再利用しないもの
進捗状況やタスク管理情報など。このケースでは、情報を常に最新に保つよう注意する。発信と受信のタイミングが異なることがほとんどなので、いつ受信されてもよい状態を保つことが重要である。
「当たり前じゃないか」と思う方も多いかと思いますが、実体験をもとにこうした気づきを「言葉」でなく「心」で理解できるようになったのは自分にとって大きな成長でした*1。ひとえに弊社という環境とサポートしてくれた方々の優しさの賜物です。
トヨクモでは一緒に働いてくれる成長に飢えたエンジニアを募集しております。
採用に関する情報を公開しております。 気になった方はこちらからご応募ください。
*1:会社の入っている目黒駅atre2ビルの２階にはプロシュート食べ放題のお店があります。
