「創業と出会った課題」 NapAntストーリー
株式会社Onikle（オニクル）ブランドマネージャーの 大平敦尊と申します。
我々はチーム開発のパフォーマンスを高めるために
ログの収集とその可視化をする開発ツール
NapAnt（ナップアント） をサービスとして提供しています。
NapAntはいままでのプロダクト開発で感じていた
「開発者の日々の業務報告や
開発サイクル改善のためのデータを取るのが大変」
という課題を、Botで自動化したことから始まったプロダクトです。
NapAntはvisionとしてwork smart, not hard を掲げているように、
仕事の仕方・価値観を改善することを日々模索しています。
完全フレックスで自由な時間・場所で仕事をすることができる
時間に関係なく、アウトプットでの評価を徹底
これらの特徴的な働き方をはじめ、
なぜ我々がwork smart, not hard というビジョンを掲げるのか、
この初回の記事で、
創業から今までのストーリーをお伝え出来たら幸いです。
# 出会いと創業
創業者達の出会いは、企業の業態や大きさに関わらず、
「奇跡的であり、運命的だった」と、
どの創業者も口を揃えて言うのではないでしょうか。
私たちも例に埋もれて、奇跡的かつ運命的だったように思います。
始まりは、大学が運営する小さなシェアハウスでした。
起業もビジネスも関係なく、
生命環境を学ぶ20歳の現CEO 立野温と工学を学ぶ19歳の現CTO 鹿間謙伍が
他の学生と一緒に衣食住を共にしていました。
彼らは一緒に住みながら毎晩のように
夜更けまで未来・哲学・科学について議論していました。
議論の中で特に引っかかったのは
CTOの鹿間の専門でもあるコンピューターサイエンスの研究分野でした。
鹿間は毎日山のように発表される何千もの科学論文の影響で、
研究者の間では情報過多の問題があることに気づきました。
「もし、他の研究者が自分にとって有益だと思った
論文をシェアしてくれるプラットフォームがあれば
研究者のリサーチする時間を大幅に短縮できるのではないか。」
と考え、私たちはこれをベースに研究者が自由に論文のまとめを
簡単に共有できるサービスを作りました。
我々はサービスを作る中で私たちは大きな問題を抱えていました。
これは他のCTOやプロジェクトマネージャーに通じると思いますが、
開発チームの管理にとんでもなく手こずっていたのです。
特に手こずっていた部分は、コミュニケーションでした。
フロントエンドエンジニアとデザイナー、
フロントエンドエンジニアとバックエンドエンジニア間の
コミュニケーションを円滑に進めるために
マネージャーがミーティングを設定することが多く、
ミーティングが終わった後も
テキストベースでのコミュニケーションが続く状態が頻発していました。
また、日々開発の進むフロントエンドの業務において、
大量のマイナーチェンジやメジャーチェンジを管理することは難しく、
ミーティングでアップデート内容を共有しても、
内容に漏れがあることもしばしばありました。
わたしたちの理想として
「各エンジニアが何に取り組んだのか、
どの過程に時間がかかったのか、
開発上の障害は何だったのかを知りたい」
そう思い始めるのはごく自然なことであり、明確なペインだったので、
私たちはエンジニアの生産性を測るいくつかの方法を導入し始めました。
最初は Trello と呼ばれるカンバン方式のツール で、
エンジニアにタスクを追加してもらいました。
そのタスクを終えた後に完了に移すことにしましたが、
チーム全体に通知されることが迷惑だと感じたメンバーが徐々に通知をオフにし
時間が経つにつれて、一番使ってほしいはずのエンジニアが使わなくなりました。
なぜ使われなかったのか？
「進捗状況を報告するために毎回違うアプリを開くのは面倒だろう」
という仮説を立て、
次は社内コミュニケーション ツールである Slack を使用して
毎日の進捗状況を終了時間に報告することにしました。
しかし、数週間後、エンジニアは毎日の進捗状況を投稿するのをやめ、
毎週投稿するようになりました。
さらに時間が経ち、エンジニアからの報告はなくなりました...。
まるでイタチごっこです（笑）
ここで、私たちはもう一度仮説を立てました。
エンジニアにとって手入力による報告は深刻な負担となっており、
報告する意味も分からないため、マネージャーへの報告を怠っている。
このイタチごっこを終わらせるべく
「わたしたちは報告の作業を自動化できないか、
そもそも報告すると何がいいのか？」
と課題の沼にはまっていくのです。
次回につづく。
この記事が気に入ったらサポートをしてみませんか？