そのまま自社サービスとして予防医療の分野でやっていくことも考えましたが、ちょうどその頃にFiNC代表の溝口と出会いまして。

当時のFiNCは技術部門が無く、ビジネスモデルが出来たばかりの状態でした。それなら一緒に進めた方がスピードも上がるだろうという話になり、その時の会社にいたメンバー全員と一緒に入社しました。

プロジェクト間の連携を強化し、入り口から出口まで徹底サポート

弊社では現在、10を超えるプロジェクトが同時進行で走っています。元々は私と代表の溝口が全プロジェクトを管理する体制でしたが、数が増えたことで2人で全てを管理するのが難しくなりました。

そこで、それまでは私たちが行っていたことを仕組み化して、全てのプロジェクトで同じ高いクオリティを担保できるようにする必要があったんです。そのためにGitHubをタスク管理のツールとして活用し、プロジェクトの可視化を進めていきました。

プロジェクトの状態を可視化することが重要な理由は、弊社のビジネスモデルにあります。弊社のダイエット家庭教師サービスでは、まず血液検査や遺伝子検査を行い、体の状態をチェックします。

その情報を元に実際のダイエットソリューションが始まり、それに加えて健康食品の提供まで行っています。つまり「チェック」「ソリューションの提供」「健康食品の購買」という、3つのフェーズを継続してサポートしているということがポイントなんです。

この特性上、プロジェクト間で密に連携した情報を正確に受け渡すことが重要になります。

チェックのフェーズで「野菜をもっと食べましょう」と出たのにソリューションが「肉を食べましょう」になると変ですよね？　入口から出口まで一貫したサポートを行うために、プロジェクトを横断した連携を上手く作っていかないといけないというのが課題でした。

まずは小さなチームから、職種横断でGitHubを導入

世の中には数多くのタスク管理ツールがありますが、弊社ではGitHub Issueをデザイナーやビジネスサイドのメンバーも含めて活用しています。カンバン形式のツールも一度導入してみたのですが、プロジェクト数もタスク数も多すぎて管理が難しく、弊社にはマッチしませんでした。

開発メンバーは普段からGitHubを使っているので、ツールを集約したかったというのも理由の1つです。非エンジニアのメンバーも同じツールを使う、ということに対してエンジニアメンバーからは心配する声も上がりましたが、実際に導入してみると特に問題はありませんでした。

GitHubに限らず、何か新しいものを導入するときは慎重に試すようにしています。何も考えずに一気に導入して失敗すると、ツールの移行期間が無駄な時間になってしまうので。

今回も全社ではなく、小さなチームから導入して実験しています。今回使ってみた感覚から、全社に導入しても絶対活用できると感じているので、今後は全社に広げていきたいですね。

会議は「次にやること」を決める場。タスクを徹底管理

弊社のプロジェクトでは、朝会を大事にしており、そこで数十ものAI（Action Item）が出てくることもあります。

会議では徹底的にAIを洗い出すということが重要だと思っていて、それが出てこないということは、つまり何も決まらない会議だったということです。

集まって議論をしたのに次に何をやるか決まらない会議は、イケていない会議だとしっかり定義しています。出てきたAIは何月何日までにやるか、というところまで確定させています。

出てきたAIは全てGoogleスプレッドシートに残しておき、そこから個別にGitHub Issueを立てて議論していきます。

エンジニアのタスクと混同しないよう、「企画・デザイン」専用のレポジトリを作ってIssueを管理しています。そのレポジトリ内で決定した項目を、エンジニアリングのタスクに分割してWeb/iOS/Androidの各レポジトリのIssueに登録するという流れで開発を進めていきます。

各オーナーが責任を持ってタスクを管理する体制を実現

GitHubでタスク管理を始めて、各プロジェクトのオーナーが以前と比べて自分の責任でプロジェクトを進めるようになりました。Issueがクローズされずに残っていると、そのタスクが進んでいないことが明確に分かるので良いですね。

議論が止まっているIssueに「クローズしますよ」と書き込むだけで、そこから思い出したように意見が出てくることもあります。「最後までやり切る」ことが仕事なので、それを徹底出来るようになったのは良いポイントですね。

もちろん、当初から問題だったプロジェクト間の横の連携も改善されました。例えばデザイナーがデザインに行き詰まった時、作成途中のデザインをIssueに上げておくと他のメンバーや別プロジェクトのデザイナーから早めにフィードバックが貰えるようになります。

方向性の修正が早い段階でかけられるので、結果的により早く、高いクオリティのものをアウトプットすることが出来ます。

エンジニアのプロジェクト管理は、別業種にも応用可能！

エンジニアの仕事の進め方って、非常に良いと思うんですよね。開発は基本的に締め切りがマストじゃないですか。遅れたり、バグを出した分だけ機会損失になるので。これが営業になると、あとで取り返せばいいやと思いがちです。

私が自分の会社を経営していた時も、今日電話したら契約が取れていたかもしれないのに、来週で取り返せばいいやと考えてしまう事があって。この考え方が、開発だと命取りになる可能性があるんですよ。

タスクを全て洗い出して、分解してスケジュールを引いて、メンバーそれぞれに役割を振り分けてアサインするというエンジニア流の方法で、全てのビジネスを合理的に進められるのではと考えています。

GitHub Issueを全社で活用出来ればマイルストーン機能で締め切りも明確になり、誰に何がアサインされているかもひと目で分かります。今後はこの方法を全社に拡大して、よりいっそうプロジェクト管理を明確に行っていきたいですね。(了)

▼Githubの使い方についてはGithub入門の連載記事をご覧ください。

チーム開発を変える「GitHub」とは？導入方法・使い方を徹底解説！【第1回】【導入編】