クックパッドには3年半ほど在籍し、その後、いわゆる「ベンチャー」の経験をしたいなと考え、Lang-8に転職しました。

この頃まではずっと、とにかく自分でサービスをちゃんと作りたいという想いが強くて。特にLang-8では社長とデザイナーと3人だったので、開発は1人でひたすら手を動かしていましたね。

チームだからこそできることがある！マネジメントへと興味が進化

そういった経験をしたことで最終的にわかったのは、1人で出来ることには限界があるということです。1人でガリガリ開発をするのも楽しいのですが、やりたいことがあってもいつも手が足りなくて、出来ないことだらけで。

そこで、次はチームとしてやりたいな、と思ったんです。そういった視点で転職先を探していたんですが、その中で一番「よくわからなかった」のがヒトメディアだったんですね（笑）。

私の座右の銘は、「迷ったら危険な方を選ぶ」なんですが、危険な選択肢だけれども迷う、ということは、不安だけど本当にやりたいことなんだと思うんです。

ヒトメディアの持つ「よくわからなさ」への興味と、ちょうど求めていた企業規模だったこともあり、2014年7月に入社しました。

現在はとある案件で、学校向けのアプリケーションを開発しています。今年の3月にリリースしたのですが、学校の中で先生が生徒に向き合う時間をもっと増やしていくことを目指しています。

先生って、すごく忙しいんです。テストの採点などの日々の公務に追われてしまって、生徒と向き合う時間がなかなか取れていないんですよね。

そのような先生の業務を効率化することで、結果的に先生が生徒と向き合い、1人ひとりの生徒の新しい可能性がどんどん見つかったらいいなと思っています。

チームに一番大事なのは、オフラインのコミュニケーション！

現在の開発チームは、メンバーの所属先企業が異なる混合チームで、私はそのチームにリーダーとしてジョインした形です。所属先が違うので、バックグラウンドもバラバラです。例えばスーツで出社するメンバーもいれば、私のようにカジュアルな格好だったり（笑）。

そのようなチームをまとめていくために一番意識していることは、「なるべくオフラインのコミュニケーションを大事にする」ことです。

もちろん、オンラインの仕組みを使うことで効率化できる部分にはチャットツール等を使っています。ただ、全てをチャットツールで済ませると逆に効率が悪い部分もあると考えていて。

例えば仕様やデザインに関しては、文字では細かいニュアンスを伝えるのは難しいですよね。それに意見が対立した時にも揉めやすくて、ずっと平行線のまま議論が続いてしまうこともあります。

チーム開発の良さのひとつは、課題にぶつかった時に皆で解決することができるということです。その良さを最大限に活かすためには、そもそもチーム内の雰囲気が「話しやすい」状態になっていることが大前提だと考えていて、その雰囲気を作るためにはオフラインのコミュニケーションが必要不可欠です。

対面で話さなければ、例えば個人のモチベーションの上がり下がりといったことには気付き難かったりするなど、チーム運営に支障が出るリスクが高くなると思います…。

今では「週5で」チームランチをする仲に

そこで、このチームに来た時に、まずは毎週金曜日に、全員でランチに行くチームランチ制度を作りました。一緒に食事をする、ということが一番仲良くなる方法だと思っていて。

そしてそれを続けていくうちに、いつの間にか金曜日以外にも皆でランチに出るようになったんです。

実は今では、ほぼ週5でチームランチをしています（笑）。Slackにランチのチャンネルがあるのですが、11時過ぎになるとbotが「そろそろお昼だよ」と教えてくれるので、そこでどこに行こうかと話し合って。

開発以外のメンバーも含めて、毎日行けるメンバーで一緒に行っています。ランチでは業務の話をすることもありますが、やっぱり主に雑談ですね。でもこのランチのおかげでチームの雰囲気は本当に良くなったと思います。

もちろん業務の面でもオフラインのコミュニケーションは大切にしていて、毎朝、朝会を行って全員の業務を確認しますし、それとは別に週に1度の定例会も実施していますね。

チームの雰囲気が良いからこそ、ITツールも活きる！

私自身のスタンスとして、オフラインのコミュニケーションを大切にするからこそ、ITツールの有効性があると考えていて。今のチームでは、チャットツールのSlack、タスク管理にはBacklog、そして情報の共有と蓄積にはQiita:Teamを使っています。

SlackとQiita:Teamに関しては私が主導して導入したのですが、Slackの役割としては、「皆の目に止めたい」ことを書くイメージです。

とにかく仲がいいチームなので、かなりアクティブに会話がされていますし、皆、絵文字を使いまくってます（笑）。割とライトなコミュニケーションのために楽しんで活用していますね。チームに絵文字職人もいるので、独自絵文字はいっぱいあります。

▼Slack上ではBotが様々なワードの反応し会話を盛り上げる

導入に苦労したのはQiita:Teamです。もともとメール文化が根強かったので、最初はなかなか使ってもらえなくて。まずは日報から始めることで書く習慣をつけるようにしたのと、なるべく自分が率先してどんどん書きました。

開発のTips的な情報からはじまり、「コードの品質を上げるためにこういうことに気をつけよう」というポエム的なものまで…。「なんでも書いていいんだ」と思ってもらえるような雰囲気作りを行っていきました。おかげで今では1日に４、５記事は投稿がありますね。

▼アクティブに活用中のQiita:Team

今このチームで開発しているのは、非常に大規模なシステムです。それを皆で分担して作っているので、どうしてもすべての詳細な仕様を全員が把握することは難しかったりします。

そこでQiita:Team上で「プロダクト検定」というクイズ形式の投稿を始めました。これこれの仕様のうち正しいのはどれか、みたいな。レベル1とかレベル３とかレベル別になっていたりするのですが、ちょっと面白い形で情報共有をするだけで一気に活用度が上がりますね。

ユーザー、エンジニア、ビジネスサイド。全ての声を聞くのが役割

エンジニアのマネジメントって本当に難しくて、最初は試行錯誤の連続でしたが、ようやく現在の形でチームが回るようになりました。

とは言っても、今も日々、壁にぶつかっている感覚はあります。技術の話であれば、課題に対して解決策があるんですが、マネジメントは「人」の話なので正解がなく、1人ひとりのメンバーでやりたいことも違うし、更に会社として目指すものやビジネスサイドの要求など、目の前には色々なことがあって。

私はエンジニアなので、やはりエンジニアがやりたいと思っていることはなるべくやらせてあげたいという気持ちはあります。必ずしも、常に「最適解」を実現しなくてもいいと思っているんです。

例えばインフラエンジニアが「Railsをやりたい！」と言うのはビジネスを全体として考えた時に最適とは言えないかもしれない。でも、やりたいのであれば少しずつでもチャンスを渡すことで、その個人の技術レベルや全体的なモチベーションが上がって、チームが生き生きとして最終的にプラスの方向に進むかもしれない。

そういったことはエンジニアチームのリーダーとして、うまくバランスをとって回していかないといけないですね。ユーザーの意見と、ビジネスサイドの要求と、技術的な課題、そして個人のモチベーションやチームワーク。

全てに対してしっかり皆の意識を擦り合わせた上でこちらのアクションに落とし込み、良いサービス開発に繋げていく。それが私の役割だと思っています。(了)