ワンオペ開発組織をどうにかしたかった駆け出しチームリーダーの話
レガシーもとい未熟もとい、まさにこれから新しい文化を作っていこうとしていたエンジニア組織の中で、小さいチームを持った駆け出しエンジニアが無い頭をしぼって行った取り組みを箇条書きにしてみた。
環境・経緯の詳細を書き始めると長くなるので、一部適当に書いてある。なぜこの記事を書いたかは最後に書く。
環境
- 会社
- 上場企業
- 社員数150人くらい、うちエンジニア職20人ほど
- 部長レベル以上にエンジニア経験者はいない
- 部署
- 自分
- 25歳♀
- 文系未経験エンジニア()
- 内定後、1年間のインターンを経て入社
- この記事に書いてあるのは正社員1年目の終わり〜2年目半ばまでの話
チームを持った経緯
チーム ①
- リーダー私：当時1 〜 2年目
- エンジニアAさん：中途入社2 〜 3年目。1児のママ。中国出身。日本語は9割方わかる。
- エンジニアBさん：当時3 〜 4年目。元メンター。社内で数少ない勉強熱心なエンジニア。
1年目の12月、当時だいたい7人が各自ワンオペ開発をしていたのが、突然マネージャーを除く6人を3人ずつ×2チームに分けると発表された。
各チームが追うべきKPI（？）も一応設定されていたものの、実情はただ事業サイドから要求された開発を空いてるリソースでやるだけだったので、さして話題にはならなかった（査定時にも特に言及されなかった気がする）。
なんのために分けたのか当時も今もよくわからないけど、部署内を細かく分けることで組織構造はこうなった↓↓
部署マネージャー（給与査定時の評価者） ↓ チームリーダー ↓ メンバー
（当時も自分でよく言っていたけど、この「チームリーダー」というのはただの名ばかり中間管理職である）
私が振り分けられたのは、部署内では技術・経験のある2人と同じチームだった。
当初、リーダーという立場にあったのは1児のママであるAさんだった。
年が明けて1月の終わり、Aさんがプライベートな事情で数カ月後に会社を離脱することが決まった。
Bさんが後任に乗り気でなかったこと、私が早く昇進したかったことの2点から、私がリーダーになった。
（このへんはマネージャーがさらに上を説得して回ってくれたんだと思う）
そういうわけで、2018年の2月からおおよそ7月までの6ヶ月間この3人のチームのリーダーとしてあれこれやっていた。
ここでの主な仕事は下記だった。
- リソースの調整
マネージャーに開発の候補を渡され、話し合いながらいつ誰に何を担当してもらうか考える - チーム内外のインタフェース
マネージャーとメンバーの間で情報のやり取りやスケジュール調整の仲介をする - レビュー全般
- 評価者へのアピール
半年に一度の供与査定時、評価者に対してメンバーそれぞれのアピールをする
チーム ②
- リーダー私：当時2年目。1ヶ月半後に退職予定
- エンジニアCさん：当時8年目くらい
- エンジニアDさん：当時3年目
これは2018年10月半ばから11月末までの話。
この少し前に、前述のチームにいたAさん・Bさんが会社から離脱した。他にも人員の入れ替わりがあり、チーム①結成時に存在していたチーム分けは空中分解していた。
私も離脱を決意して転職活動をしていたけど、うちにしては珍しくまとまった人数を要する開発があって、その一員をしているうちにリーダーになった。
（退職時期も決まってる中でのことだった、今思うと完全に失敗だったけどそれはまた別のお話。）
ここでの仕事は、とにかく開発をうまく進めることと、マネージャーとスケジュールを調整することだった。
本題
というわけで、上記2つのリーダー在任中、気をつけて実行していたことを箇条書きにしてみる。
要件レビュー
背景
当時、1つの開発が生まれて終わるまではこういう流れだった。（PDCAやリーン/アジャイルという概念は無い）
- マネージャーが開発案件を事業サイドと調整する
- マネージャーからリーダーに開発概要と目的が共有される
- リーダーがざっくりと要件精査＆影響範囲調査
- リーダーから担当メンバーに目的・要件・概要を共有する
- 担当メンバーが設計 → リーダーと設計レビュー
- 担当メンバーが開発、事業サイドの人と一緒にテスト → リーダーがコードレビュー
- リリース
見ての通りいくつかの伝言ゲームを経ているおかげで、次のような問題が起きていた。
- 設計レビュー時に、担当メンバーが要件を誤解していたことが発覚する → 設計手戻り
- 要件どおりに作ってみた後、ふと当初の目的を思い出すと要件に過不足があった → かなしい気持ち
特に1つ目の問題は大小の規模で多発していたように思う。
取り組み
私のチームでは4の後、設計に入る前に「要件レビュー」を新設した。確認するのは主にこういう点だった。
- 目的
- なぜこの開発・改修を行うのか？
- この開発・改修を行うことで期待される効果は何か？ その重要度は？
- 要件
- この開発・改修でクリアするべき要件は何か？
- 反対に、関連しそうなことがらでこの開発・改修で対応しないことは何か？
これらを担当メンバーがチケットに書いて口頭で説明し、リーダーや、必要に応じてマネージャーも参加してレビューする。
会議自体は20分ほどで終わる。
効果
この要件レビューで得られたのは次のような効果だった。
- 開発の目的および要件について、担当メンバーとリーダー・マネージャーの間で認識がそろう → 設計の手戻りが減る
- 担当メンバーが自分で要件を再構成することで、当初想定していたものに比べて必要十分な要件に洗練される
- 開発を振った側であるマネージャーやリーダーも、自分が気づいていなかった要件に気づける
- 担当メンバーが自分から能動的に開発案件にコミットしやすくなる
目的を明確に咀嚼することで、与えられた要件を淡々と実装するより自分ごとな感覚が強くなるっぽかった - 給与査定時、実績をアピールしやすくなる
担当した開発の重要度をマネージャーと確認しているため、どこをどうアピールすればいいかわかりやすい
開発規模によっては設計に入る前に1〜2日くらい時間をとったけど、設計が手戻るより全然良かった。
開発進捗の見える化
背景
もともと、部署内でのスケジュール共有にはbacklogのガントチャートを使っていた。
backlogはタスクの親子関係が設定できる（孫は作れない）ので、親タスクに案件自体を置いて、子タスクとして設計、開発、テスト、リリースを置いていくことが多かった。
ただこれだと「開発2週間」というだけひいてあって、その中で何が起きているのか、順調なのかヘルプやリスケが必要なのか、よくわからなかった。
心理的安全性の問題もあるのだけど、見た感じワンオペで担当していると特にヘルプやリスケは言い出しにくいようだった。
それで担当メンバーが誰にも言わずに無理をする、結果どうしようもなくなり、完了予定日の前日になって「間に合いません」と言い出す。数日のばす。また間に合わなくてのばす。
そういうことが過去によく起きていた。
一度ならまだしもこれが続くと本人のテンションも下がるし、中間管理職である私としてもマネージャーに事情を説明する必要があり面倒くさい。
別にリスケが悪いとは思っていない。問題なのは「どうしようもなくなるまで担当メンバーが一人で抱え込んでしまい、結果スケジュール調整がうまくいかない」ことにある。
取り組み
チーム内で動いている開発について、全てホワイトボードに進捗を書くようにした。我流カンバンみたいなもの。
形式は試行錯誤で良い点悪い点あったけど、ここではチーム②でやっていたものを取り上げる。（チーム②は3人で1プロジェクトの開発を分担して行っていた）
表はこんな感じ↓↓で、一般的なサイズのホワイトボードいっぱいに書いた。
表中の空欄部分には、タスクを書いた付箋（5cm四方）と、付随して担当者や完了予定日 が書いてある。
（表の構成に「担当者」という視点が無い点については後述する）
| 機能A | 機能B | 機能C | |
|---|---|---|---|
| 設計 | |||
| 開発 | |||
| テスト | |||
| リリース |
タスク付箋と附記には、たとえばこういうことが書いてある↓↓
- 設計：要件レビュー後、設計レビューでOKが出るまでのタスク
- 開発：設計レビュー後、コードレビューでOKが出るまでのタスク
- タスク付箋の例：「API叩く処理の開発」「レビューで付いたコメントの検討・修正」
コードレビューを経て生まれた修正タスクは付箋の色を変えてみる - 附記：担当者、コードレビュー依頼予定日
※ コードレビューは開発途中でも適当なタイミングではさむようにしていた
- タスク付箋の例：「API叩く処理の開発」「レビューで付いたコメントの検討・修正」
- テスト：コードレビュー依頼後、リリース準備完了までのタスク
- タスク付箋の例：「ステージング環境で疎通確認」「テストケース作成」「負荷確認」
※ リリースは開発ブランチからmasterに直接マージするというフロー。開発ブランチを都度ステージング環境に反映できるようになっていた。 - 附記：担当者、実施予定日、事業サイド待ち等のステータス
- タスク付箋の例：「ステージング環境で疎通確認」「テストケース作成」「負荷確認」
- リリース：リリース準備完了後、リリース後確認までのタスク
- タスク付箋の例：「事業サイドへのスケジュール共有」「リリース後負荷確認」
- 附記：担当者、実施予定日
付箋には自席からでも見えるようにホワイトボード用のマーカーで大きくタスクを書き、完了したら大きく☓印を付ける。
現在進行中のタスクについては、横に色付きのマーカーで担当者名を書き、完了予定日も書く。
担当者や完了予定日はホワイトボードに水性ペンで書いてあるので、いらなくなったら消すし変わったら書き直す。
「担当者」という情報の扱いが雑なのは「『誰がやるか』というのはさして重要でない、メンバー間のタスク分配は流動的であるべき」という空気を作りたかったことによる。
ただホワイトボードを眺めるとやたらと名前が書いてあるメンバーがいたりして、それを見つけると「タスク過多じゃないですか？」という話をしていた。
要件レビューを終えると、設計するべき点もほどよい粒度で見えているので設計の枠にタスクを貼る。
設計レビューでOKが出たら、開発タスクとテスト内容がおおよそfixするので開発とテストの枠にタスクを貼る。
……という感じでフェーズが進むにつれて表が付箋で埋まっていく。そして作業が進んでいくと☓印が増えていく。
タスクの粒度について「2日に1つは☓がつくように付箋を細分化する」ということをメンバーによく言っていた。
1枚の付箋に2週間かかるタスクを書かれては、もとの「開発2週間」と同じ状況になってしまう。
3日以上☓がつかないようだったら、付箋に書いたタスクの粒度が大きすぎると判断して、内容を一度口頭で表現してもらってタスクを分け直してもらった。
ホワイトボードにしたのは個人的な好みである。そこに物理的に置いてあると否が応でも目に入って良い。
Webサービスでもアプリでも、PCやスマホを使うものは自分で開かないと見えない。プッシュ通知が来ようが何をしようが、そこに置いてあるものには負ける。
最初は「担当者（行）×作業進捗（列）」で表を作って、タスク付箋が進捗によってTODO列→DOING列→DONE列へ移動していく式にしていた。
ただこれだと開発案件単位で進捗が追いにくく（このへんは開発の単位がちょっと特殊だったのかもしれない）、またワンオペの意識がさらに強くなってしまうような気がして途中でやめた。
効果
- リリースまでのタスクが常に、誰の目にも明らかであり続ける
- 担当メンバー自身だけでなくリーダーや他のメンバーがリスケやヘルプを提案できる
- レビュー依頼が飛んでくるタイミングをつかめる
それまではけっこう突然「これ今日中にレビューしてください」と来て焦ることもあったが、他のメンバーの進捗が把握できるので「来るぞ……」と内心で準備できた - タスクを細分化する癖がつく
- ☓のついた付箋がたまっていくことで達成感が得られる
当初解決したかった問題は上記の2番目にあたり、十分に解決された。
イメージだけど「API叩く処理のとこ明日いけそうですか？」「微妙そう」「じゃあ開発全体ちょっとスケジュール見直しますか」みたいな会話がしやすくなった。
加えて、リーダーである私が声をかけて回るのは当然として、他のメンバー同士でも「これ手伝おうか？」と言い合えていたのも良かった。
地味だけど想定していなかった効果として、4番目のタスク細分化がある。
「開発2週間」とガントチャートをひくだけだった頃に比べて、メンバー間で「それって具体的に何をするの？」「ちょっとみんなでタスク細かく洗い出してみよう」という会話が増えたように思う。
結果、担当者も自分がやるべきことを明確に理解できる → 工数見積もりの精度も作業スピードも上がる → 余計なリスケが起きにくい、という良い流れができた。
昼会
背景
チーム①が生まれた経緯で少し触れたように、リーダーの主な仕事に「チーム内のリソース調整」と「マネージャーとのスケジュール調整」があった。
ホワイトボード問題でも書いたように、そのためにはチーム内で適切なヘルプやリスケをスムーズに行える必要があり、もっと言うとメンバーの進捗状況を常に正しく把握する必要があった。
もともと週に1回1時間ミーティングをしてみたり、適当なタイミングで個別に進捗を聞いたりはしていた。でもなんだか効率悪いねーという話になっていた。
- たとえば毎週火曜日に進捗報告ミーティングをしても、水曜日に起きた問題についてキャッチアップするのが翌週火曜日になる
- 1週間あたためると問題が大きくなる
- リーダーと各メンバーで個別に話をすると、たとえばメンバーAの進捗についてメンバーBだけが知らないという状況になってしまう
取り組み
ミーティングを「週に1回1時間」から「毎日15分」に変更してみた。
実施の時間帯は、Bさんの提案で昼の12:00 〜 12:15になった（ゆえに「昼会」と呼んでいた。ちなみに定時は10:00 〜 19:00で昼休憩1時間は好きなタイミングで取れる）。
試行錯誤はあったけど、最終的には前述のホワイトボードの前で実施し、内容は↓↓に落ち着いた。
- 話すこと：
- 開発案件ごとのタスク状況
- いま困っていること
- レビュー依頼の予定
- 軽い愚痴
- やること：
- 小さい困りごとの相談
- リスケ
- 担当者変更
- タスク追加
- 会議設定
- やらないこと
- 10分以上かかる決めごと
必要になったら、決めるための会議設定だけ昼会で行う
- 10分以上かかる決めごと
効果
- 困りごとについてチームで気軽に相談できるようになった
「声かけるのは気が引ける、でも1週間は待てない」という問題でも、毎日軽く相談できる場ができた - 必要十分なリスケやヘルプができるようになった
- レビュアーの予定が立てやすくなった
- チーム内のコミュニケーションが活発になった
毎日おしゃべりしたおかげか、なんかちょっと仲良くなった気がした
2番目と3番目について、朝や帰りではなく昼にやるのが良い効果を生んでいたと思う。（ちなみに部署全体で朝会と夕会は存在していた）
当日2時間ほど仕事をした後に昼会をするため「今まで2時間やった進捗」をもとに「今日残り6時間で進められそうな作業」を確度高く見積もることができる。
すると「今日ここまでやろうと思っていたけど駄目そう」「予定通り今日の午後にレビュー依頼出せそう」という共有がしやすい。
聞く側（私）もだいたい自分の一日の余力が見えているので「じゃあこれ私が代わります」「手伝えなさそうなのでリスケしましょう」と返せる。
あと、声かけたりSlackに書いたりするほどでもない良いこと・悪いことを軽くしゃべれたおかげでちょっと仲良くなった。
こういうの地味に大事だったように思う。
Slack「決めなきゃチャンネル」
背景
自分の仕事をしている中で「これ決めておかなきゃ」と思いつきながらも後回しにすることがよくあった。他人とちょっと相談したほうがいいような内容だとことさら後回しにしがちだった、例えばみんな使いそうな定数の名前とか（もうチャンネルを見ることはできないので具体例がぱっと出てこない）。
いちおう小さい付箋に書いてデスクに貼ったりSlackにリマインダーを設定したりするものの、なんとなく後回しにし続けて数日後に「あそういえば」と慌てて相談するようなことが多発していた。
聞くところによると、私以外のメンバーも「後で相談しよう」と思ったまま忘れることがたまにあるらしかった。
必要な決めごとはいつか決めねばならないタイミングが訪れるから、致命的に困るようなことは無い。
でもプロジェクトとしてやらないといけないことが個人に閉じていること、個人に「いつかやるべき小タスク」が積まれてしまうことはチームとしても個人のメモリ管理としても良くないように思った。
取り組み
Slackに「決めなきゃチャンネル」を作った。
- 「必要だけどそこまで喫緊じゃない、小さい決めごと」に出会ったら、その場で決めなきゃチャンネルに一言で投稿する
- 昼会で担当者を設定し、担当者名のスタンプを押す。（発案者が自分で担当するときは投稿時に自分のスタンプを押す）
- 担当者は一人で決めごとを進めながら、調査過程や決めた結果について元投稿のスレッドに投稿する
- 他のメンバーも思うところがあればスレッドに投稿する
- 担当者が決め終えたと思ったら「済」スタンプを押す
- 昼会で決定内容を共有して、みんなが納得したら「完」スタンプを押す
チャンネルにはひたすら小さい決めごとが並んでいき、ひとつひとつにスタンプが押されていく。
「返信○件」と表示があったら担当者が何かしらの進捗を生んでいることになる。
効果
- 小さいタスクが個人のメモリで管理されるのではなくSlackに永続化されるので、気が楽になる
- プロジェクト内に存在する小さいタスクをメンバー全員が把握できる
- 個人が軸になって決めたものごとについて、議論や結論がテキストで残る
- スタンプわいわいして楽しい
結果、チーム全体のタスク管理は「大きいタスクはホワイトボードの付箋で公開」「小さいタスクはSlackで公開」という形になった。
TODOを即オープンにすることで個人のメモリが解放されていったのは間違いないように思う。
（ちなみに後日「やらなきゃチャンネル」という名前で決めごと以外の小タスクが同じように管理されていった。「情シスにこれ確認すること」とか）
ちなみにSlackのスレッド機能について、普段使いにくい印象だったけどこのチャンネルではちょうどよかった。
だいたい投稿されるのが小さい話題なので、流れていく分には別にかまわなかったというか、Slackスレッドの使いにくい部分は今回の用途だと無視された。
ふりかえって
4つの取り組みについて背景から効果をまとめてみたけど、チームを持つ上で一貫して目指していたのは「あらゆる情報をオープンにすること」だった。
最初にしれっと「ワンオペ開発」と書いたように、当時は1人が1案件を担当し、テスト含めて「案件はその人の責任」という考え方が強かった。
でもそれだとミスも起きやすいし疲れるし、何よりその人ができることしかできないというか、チームとしても個人としても成長しにくいのではないかと個人的に懸念していた。
加えてドキュメントを残す文化が無かった（ふざけてよく「ドキュメントインマイハート」と言っていた）ため、開発者本人しか手をつけられないコードも散見されていた。
そういう問題意識から、私のチームではできるだけ誰でも、すぐに、他のメンバーのタスクを肩代わりできる状態にしたかった。
そのためにはあらゆる情報に全メンバーが同じように触れ、かついつでも簡単にアクセスできるようにする必要があった。
なんだかんだ言ってずいぶん前のことなのでそれぞれの取り組みについて具体的な改善案は出てこないけど、全体を通してもっとちゃんと勉強すればよかったとちょっとだけ後悔している。
『エンジニアリング組織論への招待』（の特に↓↓のQiita記事のあたりとか）をもっと早く読んでおけば、いまだに未読の『カイゼン・ジャーニー』を読んでいれば、もっと体系だててチームや組織の問題点を整理して適切なアプローチを取れたかもしれない。
不安とストレスから解放される見積りとスケジュール方法 - Qiita
なぜこの記事を書いたのか
先に書いたとおり、ここに書いたあれこれのあった職場は昨年の11月にやめた。
12月から新しい職場で働いていて、そこではひたすらコードを書いている。
引き続きWebアプリケーションエンジニアではあるものの言語も開発文化も変わって、かなしいかな小さい開発すら手間取る始末だったりする。
事業やチームの戦力になるために今はとにかく数をこなして開発者としての力をつけるのが最優先だと考えている。
そんな中、1ヶ月経ってふと前職の頃のことを思い出して、当時は開発以外のことにばかり心を砕いていたなと懐かしくなった。
やったことやその効果が元の組織に残っているかは不明だけど（たぶん残ってない）、このまま私の中からも当時のことが消えてしまうと本当に無に帰してしまう気がして、せめて自分の成長の糧にしたくて、こうして文字に起こしてみた。
最後に
ここに書いたことを含めて、チーム①でやっていたことを部署内LTで話したことがあった。
当時のスライドが残っていたので貼っておく。
この記事では触れなかったけど「自分より給料が上の人たちに対して、リーダーとしてフォローして回る」というのはなかなかに難しいことだった。接し方とか、何より内心の葛藤とか。
あと、中間管理職の大事な仕事の一つに「自分の下にいるメンバーを守る」というのがあると個人的に思っている。私は給与査定には加われない立場だったから、評価者であるマネージャーにメンバーの成果や成長をアピールする必要があった。
これらも当時の私の中で重要なテーマだったから、気が向いたときにどこかでまた書こうと思う。
ちょっと恨み節っぽくなってしまったところがあるのはご愛嬌ということで。今年もよろしくお願いします。
