成長したことを書いていくシリーズ、今回はtsu-neraさんです。

Meister Hackersで、主にディレクションを担当しているtsu-neraです。今回は、Meister Hackersに３ヶ月間関わってきた感想を書こうと思います。

今回の開発では、私はコーディングをほぼやりませんでした。この開発に参加したときは、別のチームでの開発にも加わっていたため、コーディングまでしていると時間がとれませんでした。そのため、私は、別のプロジェクトとこのプロジェクトは7:3くらいの割合で関わっていました。

リードエンジニアとして

開発に加わったときの私の主な仕事は以下でした。

・開発体制を整える
・仕様設計・アーキテクチャ検討
・コードレビュー
・インフラ

まず、チーム開発をする上で、開発体制を整えるのにとても時間がかかりました。２週間はまったく開発は進みませんでした。特に苦労したのは、今回GitHubを用いたプルリク駆動開発をしたのですが、GitHubをつかったことがないメンバーが多かったので、GitHubの使い方の共有からでした。tsu-nera先生のGitHub講座みたいなのものを開いたりもしました。ただ、GitHub経験がない人も、２週間もすれば使えるようにはなります。

また、仕様の設計にもかなりの時間を割きました。だいたい、１ヶ月。わたしは、もともとSIer出身で、会社員だったころは仕様書を書くWord、Excel職人だったのですが、今回集まったチームでは、そういう文化を知っているのは、私とdh-meganeさんの２人だけでした。他のメンバは、とりあえず適当に意識の共有だけしたら作っちゃえ的な認識でした。私は、上流がグダグダだと下流もグダグダになると思っていたので、このプロジェクトでは、ある程度仕様を固めてから作りたいと思いました。各自、機能ごとに担当を割りふって仕様検討をしてもらって、私がレビューするという形で進めました。結果として、仕様検討もみんなでレビューすれば、それなりのものができました。

実装段階に入ると、わたしはコードレビューとインフラ周りに注力しました。今回、Railsできるひとが私とtakaaa220さんだったので、２人で重点的に他のメンバーのサポートをしながらレビューを共同で進めました。GitHubをつかったレビュー文化も、はじめはみんな戸惑っていましたが、すぐに慣れました。レビュー依頼を待っている裏では、わたしはHerokuやDocker周りのインフラを整えるという作業もしていました。

マネージャーとして

タスク管理も私の主な仕事でした（途中で、THさんと交代しました）。GitHub Issuesを利用したタスク管理を行いました。

タスク管理をするようなマネージメントは今まであまり経験がないことだったので、新鮮でした。作業を適切に割り振り、チーム開発が滞りなく進むように配慮するのは、とてもおもしろいです。GitHub の Projectかんばんボードを見ながら、優先順位など次の戦略を練っていくのは、船の舵を切っている気分で、とてもワクワクします。

細かなタスク割り振りは私がやっていましたが、大きなテーマを扱うときは、チーム内の定期ミーティングやリーダーのTHさんと相談しながら進めました。情報共有して認識をあわせながら進めることは大事です。別のチームでやっているときは、私に権力が集中する独裁政治だったのですか、このMeister Hackersはかなり共和制なところがありました。なので、みんなで議論して合意をとりつつ進めていきました。そのため、ときどきスピード感がないなということを感じたりもしました。権限をどこに置くかは悩ましいテーマです。

ストラテジストとして

途中から、みんなのモチベーションアップのため、このプロジェクトでDIVE INTO CODEが主催する、DEMODAY 6thに参加することを決めました。DEMODAYでは、エンジニアリング的な視点だけではなくて、サービス的な視点が求められます。我々は、もともとは各自の技術力の向上がこのプロジェクトへの参加のモチベーションとなっていましたが、私とTHさんはサービス面でも検討をすることが増えました。

わたしは、DEMODAY参加の１ヶ月前くらいから開発からは外れて、主にDEMODAYで勝つための戦略を練り始めました。具体的な作業は、リーンキャンパスシートの作成と、DEMODAYでのピッチ準備です。リーンキャンパスシートの作成のために、 リーンスタートアップの手法や、MITのDisciplined Enterpreneurshipの手法を学びました。リーンスタートアップの考え方はエンジニア一筋の私からすると、カルチャーショックでした。とともに、とても興味深いものだと思いました。ユーザ視点でマネタイズを目指してWEBサービスをつくることは、当たり前なのですが、開発者の視点から見えにくいです。

まとめと今後について

リーンスタートアップを学ぶと、私たちのプロダクトもちゃんとユーザインタビューをして企画から練り直してつくりなおさないといけないなと思いました。もし、本気でサービスを成長させるならば。それとは別に、サイドプロジェクトとして技術力の向上のために続けていくのもよいですが、わたしは技術的な部分に今回の開発では関わっていないので、技術的な学びは皆無です。

もしサービス面で関わり続けるならば、今の企画のまま進めるのは、かなりリスクがあり、かなりの時間と労力を投資して、ちゃんと仮説検証からやりなおさないといけなさそうです。サービス面を捨てて、技術的な興味で続けるならば、バックエンドのRailsを削除して、Firebaseでのサーバレスか、Goでのマイクロサービスくらいしないと、やる気が起きません。そのため、どこにモチベーションの軸を置くかでとても悩んでいます。

今までよりはコミットの力点をおかず、細々とこれからも継続していくことになると思います。これはサイドプロジェクトであり、各自の時間を投資してなにかのリターンを求めて各自が参加してもらっているプロジェクトですので、メリットがあればコミットし、メリットがなければコミット比率は減らします。

ただ、せっかくはじめたプロジェクトで、とても思い入れがあるため、やめることはなく、これからも関わっていきますので、よろしくおねがいします。