1人目のエンジニアがスタートアップでどう動くといいのか

こんにちは、Azoopの庄司です。

↓前回は私の自己紹介を兼ねた入社理由を書いてみました。

今回はフルタイムなメンバーとして入社し、1人でやっていたとき意識したことを書きます。

どう動くといいのか？

https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp

上図を意識して動くと良いです。
特に入社1年目はこれを念頭において仕事をしていました。

あと『LeanとDevOpsの科学』の影響を大いに受けています。

以下は冗長な詳細となっております。

入社時の状況

2018年11月に入社しました。
プロダクトはトラッカーズマーケットのみ。

トラッカーズマーケットの最初のcommitは2017年6月。
1年程度の開発でトラックのマーケットプレイスとして必要そうな機能はひと通り揃っていました。

技術：

使用してる技術は普通かなーという感じ。

アプリケーション側はRailsとReact(一部でBackbone)
インフラはAWS

一部で古い箇所がありましたが、それ以外は普通だったと思います。

アプリケーションのコードについては少し散らかってるところあるかな、という印象。

概ねRails Wayだけど、たまによく分からないコードがある。
使ってないコードもありそう。

不安な点はあるが、機能開発は回せそうって印象でした。

人：

私の入社前から業務委託（週2,3）で手伝ってくださってるエンジニアとプロダクトオーナーと良好な関係を築いている点が良かったです。

プロダクトオーナー（朴）は機能開発で抑えるべきところは外さないので、作った後に『あれ？ここの画面って○○じゃないっけ？』っていうよくある手戻りがほぼありませんでした。
また、UXと工数とのバランス感覚が良く、その施策はやりすぎなんじゃないの？って思うことがなかった点も個人的には良かったです。

何をやっていたのか？

主に下記の3つをやっていました。

トラッカーズマーケット（旧・トラッカーズオークション）の改修

『取引量が活発になる』と『使いやすくなる』を重視した施策の開発を行いました。

・取引量が活発になる
　・車両の売り方や掲載方法を試行錯誤するための実装
　・SEO対策の実装
・使いやすくなる
　・車両のフリーワード検索を全文検索に対応させる
　・管理者（弊社スタッフ）向け画面の機能拡張
　・細々としたバグを修正

トラッカーズマネージャーの新規開発

トラッカーズオークションは運送会社さまのトラックの調達、売却をお手伝いをするサービスです。
調達した車両を有効に運用するためのサービスとしてトラッカーズマネージャーを新たに開発することになりました。

・インフラ構築
・アプリケーションの実装

採用活動

トラッカーズマーケット、トラッカーズマネージャーの機能開発をより高速、高度にするためにはエンジニア2人体制では難しいので採用を頑張りました。

・候補者の洗い出し
・スカウトメール送信
・面談
・入社前、入社後の流れを作成
・今は無理だけど将来助けてくれそうな人と会う

1人でどのように仕事（実装）をしていたのか？

仕事の種類が複数ありますが、ここでは実装について書いてみます。（採用でも色々やったのでいつか書きたい）

やりたいことはたくさんあります。
でも時間は有限です。

ソフトウェアエンジニアの仕事の１つが実装です。

実装は変化が大きく、陳腐化しやすいです。
というのも、実装は上位にある設計、施策、思想、環境の影響に振り回されるからです。
がむしゃらに実装するのも青春なんですが、YAGNIなんて言葉が誕生するくらいで、一生懸命作った機能が無意味になることはあるあるです。
外部環境は絶えず変化するってルールのゲームをしてるので受け入れなければいけない。

シード、プレシリーズAくらいのスタートアップは資源が少ないです。

で、スタートアップのソフトウェアエンジニアがやるべきことは実装だけではありません。

採用のスカウトメール書いたり、外部パートナーとのミーティングに出席して議論したり、プレゼンス向上のためにnoteを書くとか、いろいろありますよね。

なるべく無意味になりそうな実装は避けたほうが良いです。

そんな限られた資源で物事を進めるために、意識したことが１つだけあります。

『それはプロダクトのリードタイムを早くするか？』（※『LeanとDevOpsの科学』の影響を大いに受けています）

スタートアップに求められることは学習です。
学習の回数を早めるためには仮説を早く提供する必要があります。

営業やPOは、お客様にヒアリングで質問（仮説）をします。
デザイナーは、モックやペライチの絵で仮説を提供します。
ソフトウェアエンジニアは、実装で仮説を提供します。

我々ができる『実装』はコストが高いので

* 実装しない(手を動かさずに学習する)
* 簡単に実装する
* 実装する

の順で学習する方法を考えて、提案していました。

===

『それはプロダクトのリードタイムを早くするか？』の利用例を挙げてみます。

例：とりあえず実装する

それはプロダクトのリードタイムを早くするか？

実装はコストが高いです。
まず、そもそも実装すべきなのか？（今、学習or解決すべきなのか？）と問います。
プロダクトの使い方を説明して解決するなら説明すればいい、アフォーダンス
実装する場合は、どうすればリードタイムを早くできるのか考えています。

考えるのをやめて、手を動かしたくなりますが『考えるスピード>手を動かす』なので、できるだけ手を動かさないことを意識しました。

例：言われた仕様通りに実装する

それはプロダクトのリードタイムを早くするか？

○○したいという顧客の要望に応えるHowは1つとは限りません。
提案されたHowを鵜呑みにするのではなく、同じようなことができて工数が少ない方法を考えて提案していました。

例：今どき○○を採用するのは古いんじゃないか…？イケてる言語、フレームワークを使わないと！

それはプロダクトのリードタイムを早くするか？

技術の選定基準や開発手法はプロダクトのリリースサイクルの足かせにならなければ何でもOKと考えています。

弊社ではサーバーサイドのフレームワークとしてRailsを採用しています。
退屈かもしれませんが、リードタイムを早くして学習の回数を増やすことを目的にするなら悪い選択ではないと思います。

フロントエンド側はReactを採用しています。
アプリケーションの仕様として単純なCRUDで解決できない箇所が多々あることが分かっていたので、状態に応じて柔軟にViewの描画ができるReactを選択しています。

例：スピード命なので実装を優先してテストは書きません

それはプロダクトのリードタイムを早くするか？

ロジックが複雑な場合や、ビジネスとして検証中でコードの変更が頻繁に発生しうる箇所についてはテストを書きたいです。

===

実際にやった施策を具体例として挙げたかったのですが、前置きで長くなったのでまた別で投稿したいですね。

以上、何卒よろしくお願いいたします。