2022.12.08 Thu

【エンジニア入社3カ月目のリアル】白木さんに聞いてみた

PRを担当している植野です、こんにちは！

前回・前々回の記事に引き続き、プロダクトデベロッパーの白木義彦さん、そしてそのバディ（メンター）である脇野友視さんに、入社3カ月目のリアルな様子をざっくばらんに聞いてきました！

前回の記事

『【エンジニア入社1カ月目のリアル】白木さんに聞いてみた』
『【エンジニア入社2カ月目のリアル】白木さんに聞いてみた』

話を聞いたエンジニア

白木義彦
機械学習モデルを使った自動応答システムのバックエンドエンジニアなどを経て、2022年8月にプロダクトデベロッパーとしてグラファーに入社。

脇野友視
SIer、受託開発、スタートアップでバックエンド開発、フロントエンド開発、プロジェクトマネジメントなどを経験。2021年7月、プロダクトデベロッパーとしてグラファーに入社。

——入社して3カ月目ですが、プロダクトデベロッパーとして、どんな仕事をされましたか？

白木：入社して2カ月目まではアプリケーションの対応が主でしたが、3カ月目はインフラもスコープに入れたタスクとして、「Graffer スマート申請」のメール通知成功ログの取得に取り組みました。

この機能は、「Graffer スマート申請」を利用している自治体がシステム内で市民に向けて送信したメールの成功ログを取得する機能です。これまでは送信失敗時のログの取得はしていましたが、成功時のログを取得する機能はありませんでした。実装の進め方としては、既に実装されている失敗ログ取得のコードリーディングを行って仕組みを理解し、成功ログの場合の要件検討・実装・インフラのセットアップなどを行いました。

脇野：白木さんは、React、Goの経験があったので、オンボーディング期間中にアサインするものとしては、比較的難易度が高めのタスクをお願いしました！

——徐々に業務範囲が広がっている感じですね。前回のインタビューのときにお話しされていた、新機能の実装もされましたか？

白木：はい、3カ月目には大きめの機能として、データ削除機能の実装に取り組みました。

グラファーでは一つの機能開発を一人のプロダクトデベロッパーが受け持つことが多いのですが、今回は、バディ（メンター）の脇野さんと共同開発しました。

※バディ制度
上司とは別のチームメンバーが、オンボーディングを3カ月間フォローする制度です。

グラファーのプロダクトは行政に関するものなので、仕様を決めるときは個人情報や行政文書の取り扱いといったものに気を配る必要があります。

今回は脇野さんがあらかじめ機能要件を詳細に整理してくれていたため、法令周りでどういうことを気にしないといけないかを学ぶことができ、行政特有の考慮ポイントの理解を深めることができたのが良かったポイントだと思います。

業務システムの開発に関わっている方なら分かるかもしれませんが、業務システムのデータの削除機能では考慮しないといけないポイントが非常に多く、入社して3カ月目に一人で取り組むには難しいタスクだと思います。そういった意味で、脇野さんと一緒に取り組めたことは、とても良いオンボーディングとなりました。

——論点が多いタスクにも取り組まれたんですね。他に3カ月目に取り組んだタスクはありますか？

白木：リポジトリ内のディレクトリ構造の最新状況をREADMEに定期的に出力するOSSを作成し、それをグラファーのリポジトリに適用しました。

グラファーでは、デプロイ用の設定ファイルだけを一元管理するインフラ用のリポジトリが存在します。そのリポジトリでは、設定ファイルのディレクトリ名がそのままデプロイされる環境を表しており、ディレクトリとファイル名の把握が重要な意味を持っています。

ディレクトリ構造を把握するには、その都度ディレクトリの階層をたどって確認する必要があり、過去に類似の構成で開発していた頃から手間だと感じていました。グラファーではそのディレクトリ構成をREADMEに記載する文化があり、目から鱗なプラクティスに感じました。

ただ、READMEは手作業で更新されていたので、内容が更新されていない部分もありました。最新ではない情報が書かれているくらいなら削除してしまったほうが良いのかなとも感じましたが、「このせっかくいいプラクティスがあるのに削除するのはもったいない」、「似たような悩みを持つ方の役に立てるのではないか」と考え、OSSとして作成して公開しました。

白木さんが作成した「readme-tree-writer」
https://github.com/shirakiya/readme-tree-writer

——グラファーのバリューでもある「資産と仕組みの最大化」を体現していますね。1カ月目が0.2馬力、2カ月目が0.5馬力ということでしたが、3カ月を経て1馬力に近づいた印象ですか？

白木：そうですね（笑）周りから1馬力と思われているかどうかは分かりませんが、分からないことがあっても誰に依頼すればよいのかというところは明確になった感じがします。分からないポイントが分かるようになったといいますか。他のメンバーがどういう業務を担当しているのか、それぞれのプロダクトにはどういう機能があって誰がどの機能に詳しいかということが、分かってきたことで業務は進めやすくなりました。

——脇野さんはバディとして意識していたことはありますか？

脇野：バディとしては、自立してワークできるようになることを意識していました。白木さんから色々な質問をもらうのですが、「単純な疑問」と「白木さん自身に意志決定してほしいこと」に分けて対応を変えていました。「単純な疑問」は即回答をするように、「意志決定してほしいこと」は、白木さん自身が答えを導き出せるようにナッジすることを意識しました。白木さんはもう一馬力になってると思います！

白木さんのバディの脇野さん。関西在住のプロダクトデベロッパーです。

——脇野さんからみて今後、白木さんにどんなことを期待していますか？

脇野：白木さんには今後、メインのアプリケーションだけでなく関連するマイクロサービスの基盤整備、技術的負債の解消にも取り組んでいただくことを期待しています。白木さんは開発チーム全体の動きを見ながら仕事を進める方なので、チームの生産性向上につながる仕組み化の推進やアプリケーションの機能開発など、チームのモメンタムを生んでいただけると思っています。

白木：脇野さんがおっしゃる、技術的負債の解消はとても重要だと思っています。私自身、プロダクトデベロッパーとして機能開発を行うことと技術的負債の返済を両輪で取り組んでいきたいと考えています。グラファーは「Why」、「What」、「How」を考えて価値ある機能を追及する力が強い組織です。一方で、アプリケーションが大きくなってくると、修正の難易度が上がり、結果的にビジネスの変化にシステムが追いつかない状態となってしまいます。そのため、リファクタリングや基盤の刷新を行うことによって、技術的負債の解消や品質の向上を進めていきたいです。

——最後に、候補者の方に向けてメッセージをお願いします！

白木：行政のデジタル化は、全国民に対して価値を届けられるポテンシャルがある領域です。プロダクトの力で社会を変えたいという方や、サービスを作っていくことが好きな方、エンジニアリングの力でサービスを良くしていきたいと考えていらっしゃる方がもっと増えたらいいなと思っています。共感していただける方がいらっしゃったら、ぜひお話ししましょう！