この1年くらいずっと自社サービスの開発に関わっています。(リリースしたのは半年前)
前職でも製品のプロトタイプ開発に関わったりしていましたが、営業もマーケティングも自分が行っているわけではなく、開発も単なるプロトタイピングなので業務コードではないし、プロダクト開発という意味ではかなり限定的な仕事でした。
今回は、営業、マーケティング、開発など、サービス運営に必要なタスク全てに関わっています。(一応念のため言っておくと一人で100%全部やってるわけではないです。あくまでチームの一員として全てのパートに関わっているというだけ)
サポート、プリセールス、ポストセールスとキャリアを歩んできましたが、そのキャリアを通してずっと悩み続けていたのが「なぜお客様の課題を解決する製品やソリューションを提供できないのか」というものでした。
サポート時代はプリセールスやポストセールスと違い製品軸の技術的課題解決しかできないことに苦労していて、もっと幅広いアプローチの仕方で課題解決したいと考えていました。
プリセールスやポストセールスのときは、お客様だけでなく、営業、プロダクトマネージャー、開発など、ステークホルダー全体での課題の共有や解決策の共有などに苦心していました。
結局お客様の課題の解決がうまくできないことも多く、本当に正しく価値を出せているのか分からなくなることもありました。
結果、たどりついた結論が「じゃあ営業から開発まで全部自分でやればいいじゃないか」というものでした。
自分でお客様の声を聞き自分で開発するのなら、そこにミスコミュニケーションは発生しないはずです。
そこでネックになるのが開発力です。
今までの自分のキャリアでは、業務サービスとして提供するコードを書くには力が不足していました。
なので、とにかく開発力を短期間で上げられるように以下のようなことに特に気をつけて努力していました。
- コードを読む。どの行を読んでもきちんと意味が説明できるようにする。サードパーティライブラリのコードも必要に応じて追いかける。
- 公式ドキュメントを読む。サードパーティライブラリが使われているコードが出てきたらその挙動を正しく理解する。
- 速く書く。速く書くというと「コピペとかしていい加減に書く」ように聞こえるが、そういう適当な書き方すると大抵の場合もっと時間がかる。頭をフル回転させて素早く実装を設計して書き出していくと、結果としてコードがきれいになる。
- PRにはきちんと説明を書く。どういうPRなのか、何をしようとしているのか、なぜこういう実装になっているのか、なぜこのPRを出そうとしたのかなどを書く。必要に応じて別途設計書を書く。
- テストをきちんと書く。きちんと書くとは、上記PRに書いた内容をテストしてることがわかるテストを書くということ。
- テストデータは時間をかけて作る。テストデータが正しくないと全部の結果がおかしくなる。
- コメントをきちんと書く。きちんと書くとは、コードから読み取れないコンテキストをコメントとして残しておくということ。
- レビューの指摘は、なぜその指摘なのかを一言一句ちゃんと理解してから指摘を直す。
- レビューするときは、レビュー対象のコードが何をするものなのかを自分が説明できるレベルまで読み込む。
- テストだけでなく、自分の手できちんと動作確認をして、期待した挙動に本当になっているのかを確認する。
その結果1年でそこそこコードを書けるようにはなった気がします。
営業から開発まで全部できるようになると以下のような流れで仕事ができるようになります。
- お客様と話をして、解決したい課題を確認する
- 手元でPoCのコードを書いて、課題を解決できるかを確認する
- 新規開発で解決できることがわかったら、設計を書く
- 設計のレビューを受けたら開発する
- 開発したらお客様に見せて、課題解決ができているか確認する
- できていない場合は再設計、再修正する
- 完成したらリリースする
「お客様の課題を本当に解決できているのかわからないけど開発しなければならない」といった開発サイドの悩みや、「開発側がお客様のペインをきちんと理解してくれない」といった営業サイドの悩みが一切ないというのが大きいです。
デメリットというか懸念点としては、こういう何でも屋的スキルセットは世の中の需要がないので今後のキャリアにはあまりプラスになりそうにないということですね。
どれか一つの専門性を高めていった方が転職市場での需要はあると思います。
サービスとしては始まったばかりなのでまだまだ課題はたくさんありますし、自分個人としても営業、マーケティング、開発など全ての方面で能力をもっと高めていかないといけないので、まだまだどちらも発展途上の身ではありますが、近況報告を兼ねて書き出してみました。
