SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

【デブスト2021】セッションレポート(AD)

チームを形作る2つの要素とは? サイボウズの若手エンジニアがチームワークの形を模索した果てに気づいたこと【デブスト2021】

【A-7】新チームに飛び込んだ若手エンジニアが、チームの形を考え続けた2年間の軌跡

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

「理想を達成するために役割分担し協働する」チームワークの実践に向けて

 チームが発足して半年から1年弱ほどはJavaScript用のREST APIクライアント開発をしていた。現在ではnpmパッケージで@kintone/rest-api-clientが公開されている。また公式に扱うツールを整理し、リリースやメンテナンスを一元化することも進めていった。

 一段落すると、今後チームで何に取り組むかがテーマとなった。メンバーで話してみても、対象や方向性がうまく定まらない。何を基準に優先度を判断すればいいのか、チームが最終的に達成したいことは何か(公式ツール開発は手段にすぎない)を決められないのだ。「軸がないので優先度判断ができないという状況に陥りました」と永田氏は言う。

 そこで思い出したのが「理想を達成するために役割分担し協働すること」と定められたサイボウズ流のチームワークだ。手段は定まっているけど、理想があやふやだから迷走するのだと永田氏は気づいた。

 しかし、DX開発チームにとって「理想のDX」とは何かと議論しても、発散し続けてしまった。例えば「あのツール/あの体験はよかった」「確かに。分かる分かる」と具体的なところでは共感できても、そこで終わってしまう。永田氏の分析では、全員がプログラマで実際の顧客について知見がなく、決め手を見いだせなかったという。そもそも公式ツール開発だけでいいのかという疑問もわいてきた。

 そこで「チームに足りないことは何だろう」と考えた。当時の課題はチームの活動目標や開発戦略が決められないことだった。製品機能を含めた検討が必要ではないかという意見も出た。そうして「PM(プロダクト・マネージャ)の役割がいないのでは?」という仮説にたどり着いた。

 「PMの役割が足りないならPMを学べばいい」と永田氏は考えた。そこで製品開発のPMに体験入部することにした。サイボウズでは「体験入部」として、他部署の業務を学ぶために期間限定で異動できる制度がある。開発者が営業やマーケティングを体験する、営業が開発を体験するといった経験を通して、知見を広げられるようになっている。

 実際の体験入部では現職PMの活動を直に見ながら、一部の仕事を体験してみた。開発戦略の策定業務にも加わった。ここでは製品の全体戦略から重点領域を絞り、その領域の問題を解決するための機能候補を考えるなど、開発戦略のロジックや流れを学んだ。その中で永田氏が重要だと感じたのは問題設定だ。登場人物や場面を想定し、各機能の効果や影響を考え、優先順位や仕様を判断していく。

 PM体験からは多くの学びを得た。永田氏は「これをチームに持ち帰り、DX開発チームを最高にしていくぜ」と意気揚々とチームに戻った。

チームの理想は合議だけでは決まらない、大事なのは役割との関係性

 ところが永田氏がチームに戻ると、それぞれが効率良く成果を出していたものの、とりとめのない状態になりつつあった。明確な全体方針やとりまとめる役割が不在のまま、それぞれが関心のある活動に取り組んでいたためだ。

一方そのころ、チームは崩壊寸前の状況に
一方その頃、チームは崩壊寸前の状況に

 永田氏はPM体験で学んだことを生かそうと試みるも、うまくいかなかった。問題設定して話を進めようとしても「それを調べても成果物を出しにくい」と指摘されると答えに窮してしまった。根本的な問題設定に目を向けたいという気持ちと、成果物を出していかなくてはならないという責務の間で板挟みとなってしまった。

 そこで今度は「チームを導くことができる理想があるといい」と永田氏は考えた。しかし合議で意見集約することは難しかった。それなら誰かが中心になり理想を決めるのがいいのではないかと考え、関係者と相談していくうちに「それ、永田君がやったらええんとちゃう?」と促された。結果的に2021年4月から、永田氏がチームの理想を言語化する役割を担うことになった。

 ここでPM体験で学んだ「製品戦略とのつながり」を生かすことにした。想定ユーザーの視点で課題や解決策を考え、言語化を試みるも……、これも思うようにいかなかった。つまずいてしまったのは役割だ。全体戦略から位置づけを言語化しても、実際にDX開発チームがどこまで担当するのかがつかめなかった。「DX開発チームがツール開発以上の役割をやるべきではないのでは?」「そもそもツール開発の意味づけも未検討だ……」とますます困窮した。

 最終的に永田氏は、「そもそも役割が与えられていない状態だから、理想を考えることに窮するのではないか」と考えた。では「やるべきこと」をチームで決めればいいのかというと、チームの役割は製品戦略での優先度によって決まるのが自然なので「自分たちでは決められない」と立ち往生。

 再び永田氏はサイボウズ流チームワーク「理想を達成するために役割分担し協働すること」を思い出し、「そうだ、DX開発チームには明確な役割が与えられてない」と気づいた。そこで製品PMに「このチームの役割は何ですか?」と問うことにした。現在はPMやエンジニアリングマネージャーとともに「絶賛議論中!」だそうだ。

 永田氏は最後にこう述べた。「理想と役割の関係性は大事だと思いました。チームの役割や範囲が定まっていないと、チームでやりたいことを納得できる形で見つけられません。メンバーの合議で決められればいいのですが、製品が成し遂げたいこととの親和性が判定できないので、問題の範囲を定めたうえで活動しなくてはいけないということを学びました」

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
【デブスト2021】セッションレポート連載記事一覧

もっと読む

この記事の著者

加山 恵美(カヤマ エミ)

フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレーターも担当しています。Webサイト:http://emiekayama.net

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/15386 2022/02/04 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング