TL;DR

会社で提供するサービスがより良いものになっていくよう、
あらゆる方面から(その時点での)最善の方法を検討できるようなエンジニアでありたい。

キャリア達成のために伸ばすスキル

凡例

テーマおよび説明

実際に取り組んでいること
これから取り組んでいきたいこと

🔧 新規事業があった場合に技術やライブラリを適切に選定できるスキル

今や、新たなサービスをするにあたり、サーバー・OS・プログラミング言語・ライブラリなど、多くの要素を他の誰かが作ったものに頼ることが多い。
PHPでフルスクラッチ開発をしている人にとっても、PHPはオープンソースで、多くの開発者が仕事の片手間にメンテナンスして成り立っている。
だから、使用する技術やライブラリにおいては、メンテナンスされている頻度や利用者数、ドキュメントが充実しているかなどを考慮しつつ、適切な選択をしたほうが良いと考える。

日ごろから新しいサービスや新機能の登場など、最新情報のキャッチアップを欠かさずに行っている
能動的にたくさんの情報を得るのは時間的に難しい部分も多いため、
個人の Slack ワークスペースにフィードを登録して情報が勝手に流れてくるような仕組みを導入している
社内の Slack チャンネルでも AWS の最新情報および各種クラウド(AWS や Azure)の障害情報を流すことにより、
業務に役立つような仕組みを構築した

🧑‍💻 技術検証段階で小さな構成のアプリケーションを容易に作成できる実装力

選定した技術が運用に耐えうるかどうかを判断するには、実際にその技術を使用して検証してみるのが良い。
検証を他の人にお願いするには連絡の手間が生じるし、これから達成しようとしている要件を事細かに説明する必要がある。
予定の調整、ミーティングの設定、検証中に出てくる質問への対応など、プロセスが複雑になる。
検証する技術力を持つ要件決定者がいる場合、この説明の時間を大幅に省くことができ、会社の意思決定を迅速に行うことができると考える。

日ごろから既存サービスの新しい機能や新しいサービスについて情報をキャッチアップしている
気になったサービスは、時間があればチュートリアルの部分だけでもやることでイメージをつかむ

:thinking_face: 技術負債の解消と機能開発をバランスよく行う、または判断するスキル

参考リンク

技術負債が積み上がった状態では、少しの機能修正をリリースするにも時間がかかる。
実際に開発した案件で、コードの修正が1日(1〜2時間)で終わったものに対し、テストからリリースまでに1ヶ月以上を要するものがあった。
ところが、この技術負債はコードを読んでいる技術者にしかわからないことであり、このままでは経営層に説明することが難しい。
この回避策として、事実やデータを用意するという方法がある。コードを解析して、書き方が良くないところや将来メンテナンス外となる関数が使われているところを教えてくれる(可視化してくれる)ツールは山のようにある。SonarQube や Scrutinizer、CircleCI などのツールを使用することで、技術負債を優先すべき根拠が明確になり、マネジメント層へ訴えかけやすいのではないかと考える。
結論、技術負債の解消と機能開発のバランスは、感覚ではなく具体的な数値などを基準に判断したいものである。
また、技術負債にはバージョンアップのように大きいものや、コード整形のように小さいものまでいろいろある。技術負債解消プロジェクトを立ち上げるのも良いが、機能開発の片手間でできる簡単なものから取り組むようにすることでも、負債の解消が進むと考える。

書いてあるコードが技術負債であることを認識するため、コメント(TODO や FIXME)を記載するようにしている

開発者側でできる以下の取り組みを行った案件がある

  • 「コードフォーマッタや静的解析ツールを導入することで新たなコーディング規約への違反を避ける」
  • 「ユニットテストを記述、またはユニットテストの書きやすいコードを記述し、ビジネスロジックやデータ取得などの細かい要素ごとでは自動で何度でもテストが行える状況を作り出す」

🏡 サービスにおいて限りなくすべての事象を想定内に収めるようなプログラムと運用を設計するスキル

これは一般向けに公開するサービスで「よくある質問」のページを充実させるということと同じである。
サービスを利用する上でよくあるつまずきポイントをあらかじめ記載しておくことで、カスタマーセンターにとって問い合わせ件数を減らすことにつながり、より重要な問い合わせに時間を割くことが可能となる。
サービスの運用において、想定されるエラーと対処方法をあらかじめ記載しておくと、サービスの開発者自身が対応する工数を減らすことに繋がり、結果として属人化の解消が期待できる。
そしてこの「想定されるエラー」は、開発段階で意図的に作り出すことが可能である。そのためには、エラーログの出力を分かりやすく行う必要がある。
例をいくつか挙げる。

  1. データベースに接続できない場合、「データベースに接続できませんでした。以下の手順に従ってデータベースのサーバへの疎通を確認してください。」や「接続情報が間違っています。開発担当者に問い合わせて接続情報を確認してもらってください。」など、その後の手順を示すことで、エラーを見つけた人が即座に行動しやすくなる。
  2. 不正なデータが検出された場合、「不正なデータが検出されました。(アクセス時間やリクエスト内容など)」というように詳細を記述することで、IP制限をかけたり、プログラムを修正したりと、対策を考えやすくなる。

以上のように、サービスの運用者が自走して対応できるようにエラーの種類や原因をできるだけパターン化しておくのが重要である。
サービス利用者がトラブルを自分で解決できるよう「よくある質問」のページを用意するように、開発者はサービスの運用者が自分でエラーに対処できるようマニュアルを充実させていきたい。

💝 新人エンジニアにエンジニアという職種を好きになってもらうための教え方のスキル

新人エンジニアは、その会社で初めてエンジニアという仕事を体験する。そのため、「エンジニアとはこういうものだ」というイメージが会社によって形成される。
私自身はあらゆる文化の人がエンジニアになって欲しいと思っており、「プログラミングは難しそう」や「理系のする仕事だ」といったイメージを抱かないように教え方や接し方を工夫したいと考えている。
「プログラミングは難しそう」というイメージに対しては、学校に留学生が来た話を持ち出す。
留学生が日本語を話せない場合、我々は留学生の話せる言語を覚えてコミュニケーションを取ろうと積極的に努力する。エンジニアにおいても、最初は1人につき1人、日本語の話せない友達(パソコン)がおり、プロジェクトの要件を達成するためにその友達が話す言語を頑張って覚え、説明することが必要になる。 「理系のする仕事だ」というイメージは、パソコンを使って黙々と仕事をする情景を思い浮かべやすいところから来ていると思われる。
エンジニアの本質は、自分がこれから成し遂げたい(実装したい)ことを筋道を立てて説明することであり、たまたまその説明する相手がパソコンなだけである。そのように新人には伝えようと考えている。

英語で提供されている各種オンライン学習サービスのコンテンツには、「そもそもプログラミングとはどういうことか」のような根本的な説明が豊富に含まれているため、参考にするようにしている

👴 ベテランの方々の体面を重んじながら自由に新しい文化を取り入れるためのコミュニケーションスキル

時代に合わせて新しい文化を取り入れる取り組みは必要になってくるが、文化を取り込んだり浸透させたりするためには、既存の社員の協力が必要である。
また、ベテランの方々のサポートを受けることで、最適な方法を見つけることができる。
そのためには、ベテランの方々の尊厳を失わずに説明し、文化を取り入れる本来の目的を共有することが大切であると考える。

ベテランの方々が持つ「ベストプラクティス」はなぜベストになったのかを分析し、新しい文化も同じ要素を持っているということを説明するようにしている

参考:ChatGPT にアドバイスを求めた結果

  • 相手の立場を理解する
  • コミュニケーションを大切にする
  • 具体的な事例を示す
  • リスペクトする
  • 小さなステップから始める

今後、エンジニア人生の中でやりたいこと

(無期限で、本業・プライベートは問わない)

コードレビューの体制を構築する
テストからリリースまでを高頻度で行えるような仕組みを構築する
コンテナ技術やクラウド環境の導入など、エンジニアが気持ちよく開発できるような開発環境を整備する
新入社員の開発環境構築にかかる時間を極限まで切り詰める取り組み
社員が自分の人間性と仕事の実績を分離して考えられるよう、面談で社員にかける言葉の表現選びに気をつける
会社の方針決定にデータという根拠を活用する