こんにちは！株式会社RemitAidのremitaid_wataruです。
ここ数ヶ月は開発から離れて、新規事業の立ち上げに向けた業務をメインでやっていました。規制要件の整理、社内マニュアルの作成、システムとして対応すべき機能の洗い出し。コードを書く時間は1~2割ほどでした。
現時点でのRemitAidはまだ小さな会社なので、エンジニアでもこのような開発以外の業務を担うことがあります。
営業から聞いた話
営業メンバーと話をしていた時、こんな話がありました。
「◯◯のニーズの方が多くて、今の機能だけだと契約取りきれないんですよね」
ニーズはあるのに、今のプロダクトでは対応しきれていない。なので契約が取りづらい。
準備が整ってその機能を提供できるようになれば、顧客のニーズを満たせるので、契約がとれ、会社としても売上があがります。
当たり前の話ですが、以下に整理してみます。
全部「手段」だった
改めて整理すると、こういう構造になっています。
- 顧客には「こういうことがしたい」というニーズがある
- そのニーズに応えるために、ある機能が必要
- その機能を提供するには、事業上の準備が必要
- そのためには、規制要件を満たす必要がある
- 規制要件を満たすには、業務フローやシステムの整備が必要
この流れを見ると、事業準備も、マニュアル整備も、システム開発も、全部「手段」なんですよね。目的は顧客のニーズに応えること。そして売上を上げること。そこが起点で、他はすべてそこに繋がる手段です。
言葉にすると当然のことなのですが、普段コードを書いているとこの感覚が薄れがちでした。どうしても「どう作るか」「どういう設計にするか」に意識が向いてしまいます。
開発から離れて見えたこと
今回、新規事業立ち上げの業務をやる中で、ビジネス側のメンバーと話す機会が増えました。営業が何に困っているか、顧客がどんな課題を抱えているか、会社としてどこに向かおうとしているか。そういう話を聞く時間が増えたことで、「なぜ作るのか」の解像度が上がりました。
エンジニアの仕事の1つは技術で課題を解決することですが、その「課題」がどこから来ているのかを知っているかどうかで、アウトプットの質も変わってきます。機能の優先度を考えるとき、設計の判断に迷ったとき、「これは誰のどんなニーズに応えるものなのか」が分かっていると、判断軸がブレにくくなります。
開発に戻るときの視点
今後は少しずつ開発業務にも携わるようになる予定です。書くコードは今までと大きく変わらないと思いますが、見え方は少し変わる気がしています。
自分が実装している機能は、どんなニーズから来ているのか。その機能が使えるようになると、誰がどう嬉しいのか。そういうことを意識しながら書けると、仕事の手触りが変わりそうだなと思っています。
とはいえ、すべてを「手段」と割り切ってしまうと、技術の面白みが半減してしまう気持ちもあります。ユーザーから見えない部分、たとえばアーキテクチャや内部設計については、あえて目的化して追求するのもありなのではないかと思っています。手段として最適かどうかとは別に、「こう作りたい」というこだわりがあっていいはずです。そのバランスは、これからも探っていきたいと思います。
開発から離れていた数ヶ月は、エンジニアとしてのアウトプットはあまり出せていなかったと思います。しかし、とても貴重な時間でした。もう少しこのスタイルが続きますが、今のフェーズだからこそできる経験だと思って引き続き励みたいと思います。
ポエムな投稿になりましたが、最後までお付き合いいただきありがとうございました。
告知
Podcast 「RemiTalk」では普段の会社の様子を赤裸々に語っています。
もし良ければ聴いてみてください！
Podcast 文字起こしはこちら
Discussion