フリーランスエンジニア、ときどき、個人プロダクト

こちらの冒頭でも書いてたように、ソフトウェアエンジニアのフリーランスとして働き始めて3ヶ月経過。

最初はちゃんと働けるのか結構不安だったけれど、やってみると意外と問題なかったので一安心。若いわけでもないので、経験を糧に立ち上がりの初速もまぁまぁでは、と(勝手に)思っている。

フリーランスエンジニアになるタイミングは様々あるだろうけれど、個人的には会社員時代にプレーヤーからテックリード→部長職まで経験しといて良かったと感じている。

今回自分が選んだ役割はマネジメントではなく開発エンジニア。だから毎日せっせと手を動かして開発に勤しむ。なので、テックリードくらいまでの経験は直接役立っている。

一方で、先方が何を期待しているのかを把握するには、部長職くらいのマネジメント経験が活かされていると感じている。どう物事を進ませたいのか、相手のロールに応じて目線が違うのがよくわかるし、それに応じた受け答えができるから。

想定外だったことを一つ書いておくと、会社は採用をとても頑張ってカルチャーマッチする人を雇うから、同僚も割と能力も性格も極端に大きなばらつきは少ない傾向を感じた。

一方でフリーランスで現場に入ると、誰と仕事するか選べない。それゆえ各種のギャップを感じる時がある。このギャップも埋めて業務をうまく推進させるのが、フリーランスに求められる能力の一つなんだろうな。これは今後経験で学んでいくしかないだろう。

。。。

とここまで書いただけだと、単にフリーランス頑張ってます通信でしかないので、これまでの自分の経緯と合わせて考えていくことにしよう。

かなり前に自分のアイデアでプロダクトのプロトタイプを作って、いろんな方々に見てもらうという企画をやっていた。うまくはいかなかったけれど(その節はご協力ありがとうございました)。

個人的にはフリーランスだけをメイン事業としたいわけではなく、プロダクトビジネスも事業に含めたい。

実際にはキャッシュエンジンとして固く稼げるフリーランスエンジニアをやって、それを元にプロダクトビジネスを少しずつ進めるというのが今の所の形態。

上記の企画でもれなく失敗したように、そんなにプロダクト開発がうまくいくわけないので、数年単位で考えてやろうかなと考えている。

フリーランスエンジニアの経験を増やしていけば、もっと効率的に開発作業できると思うので、時間を調整して少しずつプロダクト開発に時間を捻出できればと考えている。

以前にnoteで散々書いたプロダクトのコンセプも、時間が開いたためか、少し冷静に見つめることができていると感じている。

前のプロダクト案(思考を成長させる)では、どっちかというとより良くなりたいとかより成長したいとかの欲求充足向けのプロダクトになっていて、それ自体が悪いわけじゃないけれど、今のビジネス立案初心者の自分には難易度高すぎたのではないかと反省している。

自分が欲しいプロダクトを作ろう、というスローガンは前も今も一貫しているんだけれど、『自分が欲しい』という動機の中には、自分が今以上に成長したいという欲求を満たすものと、自分がやっていて面倒なことを解決するという課題解決のために欲しいプロダクトが混ざっていた。

欲求充足方の場合は、正直それがなくても困らない。なのでどうしてもお金払ってまで使いたいかと問われると弱いところがある。ゲームみたいに中毒性があれば別かもしれないけれど、自分が作ろうとしていたツール系だとそれは厳しいのではないかと。

一方、課題解決型はストレス溜まりっぱなしを解決するものなので、欲しいという気持ちが出てきやすいのではないか。起業の本でも課題解決のことばかり書いてあるし。

ということでこれまでとプロダクトの本質は変わらないけれど、具体的にどの課題を解くプロダクトなのか、を明示できるようなプロダクトにしていこうかなと考えている。

今までのプロダクト案（思考を成長させる）は抽象度高めだった。プロダクトを使うと誰のなんの課題を解決するのか、をより絞り込んで考えていこうと。

で、具体的にどうするんだっけ？と、考え続けているのが最近の状況。

結局一番は自分が面倒だと思って、しかも、同じ話題が身近でも出ている、という課題を解決するのが良い筋に感じる。少なくとも最初のビジネスの出発点としては。

とすると、自分は今フリーランスエンジニアをやっていて、これまでもエンジニアをやっていたのだから、エンジニアの業務の中でよく出た問題を解決するのが良いのではないかと思い始めている。しかも自分が感じていた課題かつ周囲も面倒だと感じていたことで。

そこで思いつくのが、ドキュメンテーションについて。

エンジニアじゃない人たちには伝わりにくいと思うけれど、エンジニアはドキュメンテーションをやたら求められる職業だと思う。

でもエンジニアで文章書くのが好きな人ってあまり多くない印象で、できれば書きたくないよって人が多い印象。

でも組織の中で業務をしていくには、やっていることの可視化やなんのためになぜそれを実装するのか、をコンテキストを維持して伝えていくことが強く求められる。そこらへん面倒だけれど渋々やるって所なんだと思う。

自分はGitHub issueなどで文章をさまざまなissueやプルリクエストを参照しながら大量に書く方なんだけれど、それは結構稀。みんながそうするわけではなく、ばらつきが多い。

でも、マネジメントやプロジェクトマネージャーの観点から見ると、なんでその機能作るの？というコンテキスト含む理由づけは非常に大事に思うわけで、そこにエンジニアとの温度感のズレもある。

なのでエンジニアにドキュメント書いてね、が降り注ぐ圧力になるわけで、あー面倒だなと思いつつ文章書いてるというケースはかなり多いのではないか。

仕事でソフトウェアエンジニアがドキュメントを書かない、ということはほぼできないのだけれど、そして何でもかんでもAIに生成させるということも非現実なのだけれど、文章をもう少し書きやすくするツールがあればいいなとは思う。

すでに世の中に優れたドキュメンテーションツールはいくらでもあるけれど、そのうちいくつかはエンジニア向け、それでもエンジニア界隈でドキュメンテーションの話題がなくならないので、永遠の悩みと化しているのではないだろうか。

自分なりにGitHub issuesやRedmineを使ってきて、ここがこうなればドキュメントが書きやすくなってサイコー！！と思う具体的なアイデアがいくつかあるので、そのアイデアの検証から始めていくのが良いのではないだろうか。

対象ユーザーも前のプロダクトの時のように不特定多数ではなく、自分と同じエンジニアかそれに関連するプロダクトマネージャー、プロジェクトマネージャーなどにフォーカスを限定すると、もっとシャープにプロダクトコンセプトを構成できるのではないだろう。第一、それらの人たちの有り様をありありと思い描けるし。

なので、これまでのプロダクトのプロトタイプを改良を加えつつ、別のUIとアーキテクチャで再構築して今少しずつ実装している。

フリーランスの仕事の傍でやってるのでめっちゃ前より開発の進むスピードが遅いけれど、フリーランスの仕事はお金稼ぐためにしょうがないので、まぁ気長にやろう。