エンジニアリングでプロダクトに貢献するということ

こんにちは。スペースマーケットでエンジニアリング マネージャーをやっている齋藤と申します。この記事は スペースマーケットプロダクトチーム Advent Calendar 2019 の 12月16日の記事となります。

本稿のテーマをお伝えする前に、自身のキャリアを少し説明させてください。前職は SIer で官公庁向けのシステム インテグレーションや同業界向けのパッケージ開発や ASP 運営に携わってきました。

特に後者には長く関わりました。参画当初はプログラム作成から現地導入まで一通りを行い、ある程度事業が軌道に乗ってからは開発リーダーとして上流工程をこなしつつプロジェクトチームや協力会社の管理を行なってきました。

そして今年の2月からスペースマーケットにエンジニアとしてジョインしました。スペースマーケットは自社でサービス開発を行なっており、かつスタートアップですので、ジョインするエンジニアには当然、管理スキルのみでなく実際に手を動かす開発スキルも求められます。

本稿は「プログラマー35歳定年説」を優に超えている自身がこのような環境で、プロダクトへ貢献するために考えてきたことの振り返りとなっています。そのため幾分ポエム要素を含んでいると思いますが、同じような境遇の方に対して何らかの糧となれば幸いです。

ジョイン初期（〜1、2カ月）

前職では業務でプログラミングする機会はほとんどなくなっていましたが、稀にある検証作業や趣味の範囲で細々と続けており、ジョイン後の基本的な開発業務で特に違和感は感じませんでした。

しかしながらこれまで培ったスキルや経験値を駆使して生産性や品質が高いものをアウトプットしていけばバリューを発揮できている！といえるステージでもないなという思いはありました。

そんな中で最初に考えたのは、SIer で培った質実剛健な作業品質の知見や、幾度となく構築したインフラの知識が、組織に足りないピースとして役に立つのではないか、ということでした。

リスク対策を盛り込んだ作業計画、属人化を解消するための手順書の整備やツール適用、SPOFの排除など実際に取り組みました。

自身で述べるのは非常におこがましいですが、一定の効果はあったと思います。しかしスタートアップに求められるスピード感を考えると改善の余地があるとも感じました。

〜2、3カ月

とある機能のリニューアル プロジェクトを担当することになりました。設計レビューにより、当該機能は先行してマイクロサービス化していたドメインに分類するのがふさわしい、という結論になりました。

マイクロサービス化していたコードベースは当該機能と処理系が異なっており、統合には再実装が必要な状況でした。また統合先の実装が要素技術への依存が高い形となっていました。

これまでパッケージ保守開発を長年してきた経験と照らし合わせて、今このコードベースを改善しなければ、今後の改修や保守で必ず品質問題に直面すると考えました。

まずは既存のコードベースをドメイン駆動設計やオニオン アーキテクチャを取り入れて再実装することで拡張性・保守性の礎を築き、そこへリニューアル対象の機能を統合しました。

〜4、5カ月

比較的大型のプロジェクトを担当することになりました。担当のプロダクト マネージャーは企画・仕様化に忙しかったため、プロジェクト マネジメントを引き受けながら進めていました。

エンジニアリングの面では、当該プロジェクトがサービス広範にわたって影響する内容であったため、全体アーキテクチャの設計やコントロール、また要求仕様との整合を調整しながら、難易度が高そうな箇所を見繕って実装したりしていました。

それから

複雑な仕様で計算量が多めな機能の実装が必要なケースで、要求品質を満たすためによりスループットを確保できる処理系（Go）を導入したり、ビジネス スクール時代の課題研究から趣味で続けている機械学習の知見を活かしてデータ エンジニアリングの基盤を作ったりしましたが、こちらはまた別の機会に投稿したいと思います。

最後に

最後までお読みいただきありがとうございました。

こうして振り返ると仰々しいタイトルをつけた割にはまだまだなと感じましたので、今後一層努めて参ります！

次の Advent Calendar の記事はデザイナーの谷田部さんとなります。どうぞお楽しみに！！