• 株式会社ヒトメディア
  • CTO Div. StartUP Team
  • 佐々木 達也

ITツール頼りはNG!オフラインのコミュニケーションが、エンジニアチームを強くする

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet

今回のソリューション:【Qiita:Team/キータチーム】

エンジニアの世界では「業務の効率化」は常に優先されるミッションのひとつだ。その実現のために世の中には多くのITツールが生まれ、特にコミュニケーション領域や情報共有の領域ではその進化もめざましい。そして、通勤時間を効率化するリモートワークという働き方も少しずつ浸透しつつある。

しかし、良いチームワークを生み出すために本当に大切なものを見失ってはいないだろうか?

アドウェイズ、クックパッド、Lang-8を経て、現在、株式会社ヒトメディアで働く佐々木 達也さん(通称ささたつ)。

NoSQLやHadoopに関する書籍の執筆、Rails初期からの技術者、そして「からあげエンジニア」としても知られる佐々木さんは、「エンジニアのマネジメントではなるべくオフラインのコミュニケーションを大切にするべき」だと語る。

佐々木さんのチームでは、週に5日のチームランチや日々の朝会など、対面でのコミュニケーションをしっかり確保することでチームワークを醸成している。

そのような前提があってこそ、「Slack」や「Qiita:Team」のような業務を効率化するツールも活きるのだという。佐々木さんに、詳しいお話を伺った。

「とにかく自分で手を動かしてサービスを作りたかった」

私は2007年にアドウェイズに新卒エンジニアとして入りました。その時点ではまだ、プログラミングは未経験でした。

そこで2年ほどWeb広告のシステム開発者として経験を積んだのですが、開発センターが上海にあったので自分で手を動かすことがあまりなくて。そこで転職を決めて、選んだのがクックパッドです。

当時は50名ほどの組織で、エンジニアもまだ6、7名しかいませんでした。最初はデータ解析がメインでHadoopを使っていたりしましたが、途中からは新規事業の開発を担当するようになりました。

クックパッドには技術レベルが高い人が多かったので、非常に鍛えられたと思います。自分が書いたコードが、翌朝会社にいくと「作り直しておきましたよ」なんて言われたこともあって(笑)。

自分が書いたものが直されて、明らかに良くなっているのを見るのは辛いですがありがたい体験でしたね。そのおかげで、技術的にも成長出来たのではないかと思います。

クックパッドには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日に4、5記事は投稿がありますね。

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

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

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

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

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

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

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

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

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

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

  • -
  • このエントリーをはてなブックマークに追加
    -
  • tweet