「前提編」「運用フェーズ編」に続き、今回は開発フェーズのチームについて書こうと思います。

プロジェクト初期

最初に読んだ本

今まで運用リーダーをやっており中規模機能については経験があったものの、本格的な開発プロジェクトでのリーダーとしては経験がありませんでした。そのため以下の本をまず読んでみました。

アジャイルサムライ――達人開発者への道
https://www.amazon.co.jp/dp/B00J1XKB6K

カイゼン・ジャーニーたった1人からはじめて、「越境」するチームをつくるまで
https://www.amazon.co.jp/dp/B078HZKLMB/

また、これは後にチームメンバーに勧められて読みました

ピープルウエア　第3版
https://www.amazon.co.jp/dp/B00I96CJWO

「ピープルウェア」は現場のエンジニアと言うより管理職向けな部分もあるように見えますが、ぜひリーダーと呼ばれる人全員に読んでほしい。。

リーダー以外に意思決定できる人を決める

リーダーが何でもかんでもやるのはバス係数も低いし、なによりそこまでできるスーパーマンでもないし、口を出したいわけでもなかったので、そのため誰に何を任せるかをまず決めました。

アーキテクチャを決めるボス

アプリケーションの全体的な設計を決め、メンバーの相談に乗ってもらえるような人を決めました。

既存の資産があり捨てられるもの・捨てられないもの・ユーティリティクラスがいろいろあったため、この人についてはそれらについてのレクチャーを行いました。

開発環境を作るボス

強い人だったので、既存のansible資産を見せては「現状どんな構成になっているか」を解説し「GitlabCIの設定をしてくれ」「botを作ってくれ」「ここの環境にJenkinsを置いてくれ」と何をしてほしいかを頼むぐらいでした。

アーキテクチャや開発環境については、後々「この場合はどうする」「こんな問題が出たけどどうする」ということが必ず発生するので、スキルの高い人を配置するべきでしょう。

また、アーキテクチャについてはエヴァンジェリストとなってくれる人であればなお良いです。

運用業務を行うボス

前の記事にも書いたように「運用をしながら新規開発が発生する」という特殊な状況のチームだったため、開発を行う上でも運用業務は行っていく必要がありました。

今までどのようなことをやってきたか
メンテナンスへの入れ方等、運用方法のレクチャー
定例運用にはどのようなものがあるかをレクチャー

実際に作業や対応を任せつつも背後霊（本番環境を直接操作する時に別の人に後ろに立ってもらって間違いがないかダブルチェックすること）をする、質問に答えるなどを行いました

ボスたちに対してリーダーが取るべきムーブ

これらのボスに対しては、ドメイン知識や経験上のアドバイスはするものの、彼らが決めたことには口を出さないように心がけたほうが良いです。

もちろん意見や質問などはしますが、リーダーの意見を押しつけないように気をつけるべきでしょう。

暗黙的な役割を明確にする意味

社内で人材を手配してもらう上でも、欲しい人物像と役割を明確にしておくと社内との折り合いがつけやすくなったように思います。具体的に「××な人がほしい」「○○ができる人がほしい」と言うことができるためです。

今回の場合は同僚氏も優秀だったので、本当になにも言う必要がなかったというのも大きかったかもです。

開発フローのルール策定

対社内

（具体的な内容は割愛しますが）コードレビュー時のmergeタイミング、デプロイ方法の共有を行うようにします。まぁこのあたりはどんな状況のチームにも大抵存在するかとは思います。

対お客さん

業務フローにお客さんを早い段階で巻き込む

お客さん（仕様を作る人や我々と違う領域を担当するエンジニア）との開発フロー策定も早い段階で行っていきました。暗黙のまま進めると待っているのは混乱だけです。

また、仕様の進捗を共有スプレッドシートで管理し、実装項目に対してどの項目に対して仕様ができてる・できてない・今作ってる・もうできてる等といった状況を共有できるようにしました。

仕様書ができたり、画面レイアウトができたり、実装に取りかかるタイミング、実装が終わったタイミングでお互いに状況を把握できるようにするためです。

あくまで細かすぎず、「だいたい状況がわかる」にとどめるのがミソ。あまり細かく書いてしまうと工数の交渉をされてしまうし、なによりメンテするのがつらくなります。

ステークホルダーを早い段階で巻き込むこと

意思決定できる人を早い段階から巻き込み、いつでも仕様の話ができる状態にします。

お客さんとの定例会議には議題の担当者を必ず同席させるようにし、伝言ゲームにならないように努めます。

この辺の話はSHIROBAKOを見てもらった方がいいかもです

開発ツールなど開発項目外の工数を削減すること

Kibelaやbacklog等、有用なSaaSサービスはたくさんあるので、本来はこれらに課金してくべきでしょう。

しかし　諸事情によりそのような恩恵を受けることができなかったので、GoogleDriveを活用したり、お客さんに用意してもらうことにしました。

こちらが立ててしまうとそれ自体へのメンテナンスをしていく必要があり、余計に工数を取られてしまうためという理由もあります。

社内のチーム外に協力者を増やす

助言を求めることができる人をふわっと巻き込む、その人が所属しているチームのリーダーに根回しをしておく等、チーム外に協力者を増やしておくとスムーズです。

当然業務執行するのはチームですが、人の貸し借りや他チームのノウハウを見せてもらうなど、得られるものは大変大きいです。

チームごとに前提条件やさらされている状況が違っているので、他チームがどのような努力・アプローチをしているのか知ることができるのも良いです。有用な取り組みはぜひパクりましょう。

生産性を上げるために

チーム内の様子

進捗報告だけの定例~~が嫌い~~に意味合いを感じていなかったので、思い切ってやらないことにしました。

その代わりSlack上で簡単な週報を書いてもらいます

今週やったこと
これからやること
現在のお気持ちや懸念点

基本的にリーダーはここに書かれることや、普段のチームメンバーの様子を見ながら、ミツバチのように横断的にチームを見ていきます。

CRCや設計会議、インフラアーキテクチャなど議題が存在するミーティングしか行わなかったです。

強制されなくても自分から問題発信するチームだったので、進捗報告定例を行う必要がなかったというのも助かりました。

もりもりタイム

pixiv社の「開発もりもりタイム」という取り組み~~をパクリ~~にインスピレーションを受けて、特定の曜日に会議を入れないようにするということもやっていました。

「開発もりもりタイム」という言葉が突然でてきています。これはピクシブで毎週木曜日に行っている、もりもり手を動かして成果を生み出すことに集中する時間帯のことです。こちらはまた別の機会にご紹介します。

「一斉Slack channel整理タイム」のご紹介
https://inside.pixiv.blog/bash/4148

お客さんとの定例は毎週行った

幸いなことに同じ市内にいるお客さんだったので、毎週来てもらって仕様の話やスケジュールの話をすることができました。

毎週水曜にチーム内で「定例で聞きたいこと」を募集しておき、議題issueを発行、それに沿って進める
関係する担当者は必ず顔を出す

という方針で行っていました。

プロジェクト中期

仕様がだんだん出そろってきて開発が回り始めるとこのようなことを考え始めます。

工数管理と実装項目

実装項目の粒度は少しだけ大きめに出すようにしました。

というのも、開発が佳境に入ってきたタイミングで**「この機能を実装しているとリリースに間に合わないから、リリース後実装とさせてくれ」「この機能を実装するには工数がかかりすぎるから仕様自体を簡略化してくれ」**といったオミット交渉が必要になってくるだろうということが容易に予想できたためです。

お客さん（非エンジニア）にもわかるぐらいの粒度にして、開発項目をそのまま見せられるようにしました。

見積もりはファンクションポイント法で行ったのですが、ここで出したポイント数や人日換算数はそのまま公開しないようにしていました。

ポイント数は具体的に見せないようにしました。ポイント数を見せると工数を具体的に見せることになり、「見積もりの交渉」が始まってしまい不毛だと思われるためです。

「見積もりの交渉」の典型的な例

PM「機能xyzの件だけど、開発期間はどのくらいだと見積もってる?」
プログラマ「1ヶ月ですね。」
PM「長すぎる。1週間で何とかならないか。」
プログラマ「どんなにがんばっても3週間は必要ですよ。」
PM「2週間、それ以上は無理だな。」
プログラマ「わかりました。それで手を打ちましょう!」

プログラマが知るべき97のこと見積もりとは何か
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E8%A6%8B%E7%A9%8D%E3%82%8A%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B/

実装項目のオミット交渉の様子

※ここは開発メンバー氏にアドバイスしてもらった部分が大きい。大変感謝

まず実装項目を一通り出し、実装工数を大雑把（3L/2L/L/M/S/2S/3S）に振っていった
そのリストをお客さんのステークホルダーに見せ、リリースまでに必要なもの、リリース後いつまでに必要なもの、いつでもいいもの、廃止するものをお客さんに自分で決めてもらった

お客さんに自分で決めてもらうのは有効で、後でトラブルになってしまうのを防ぐことができたように思います。

見積もりの粒度について

他のプロジェクトに参加していると「hogehogeのテーブルを作る（ジェネレータ使って1分でできる程度）」「××の機能を作る（3人日程度）」といった、粒度が混在してしまっている状態がままありました。

そのような状態ではあまり管理しにくいなぁと思っていたので、このように見積もってもらいました。

基本的に見積もりは担当者が自分で行う
- ちょっとした機能であれば担当者が見積もりますが、大きめのドメインについてはこのカードを使ってチーム内でプランニングポーカーを行ないました
- 実際に「あ、これは見落としてたわ」「なるほどこれは考慮してなかった」「これは別にいらなかったな」といった会話が発せられ、多角的な視点で見積もりを行うことができました。
- リーダー自らが全部やるのは望ましくなくて、リーダーは納期へのプレッシャーから認知バイアスがかかり過小評価してしまう傾向にあるため、やらない方が良い。あくまで担当者やチームメンバーがやるべきです
hogehogeがhugahugaできるようにするといった感じに出してもらった
これを「タスクゴール」と読んだ。対応のゴールがこの時点で明確だと望ましい
とはいいつつこのあたりの粒度というのはなかなか統一させるのは難しいので都度実装担当者と相談し、粒度を統合したり分けたりした
- 例えば画面対応（Controllerやテンプレートの実装）と内部実装（テーブル設計やドメインの設計実装）をわける、など
幸い運用中のものがあったので、そのうちのいち画面を1ポイントとした
指標を1ポイントとし、そこからの相対見積もり（この機能は指標に比べて多いから2ポイントだ、少ないから0.5ポイントで済むだろう、等といったこと）
- このあたりはアジャイルサムライの第Ⅲ部第７章の記述が詳しいです

実装内容が出揃ってきてオミットが難しい場合の工数削減交渉

だんだんいくつかの機能が実装できてくると、**「この機能をオミットするにはすでに作ってしまったものが無駄になる」「機能Aと機能Bは密結合になっているが、機能Aをオミットしようとするも機能Bにもう着手してしまった」**といったように、単純なオミット交渉が難しくなってきます。

仕様再検討や工数の手戻り、残り開発期間の少なさといった事情が関わってくるためです。特に「すでに実装された部分」への影響は大きいので、その点に注意する必要があります。

物理的な工数の他にも、担当者の「せっかく頑張って設計考えて作ったのに無駄になるのか……」といったモチベーションにも関わってきます。

幸運にも今回のプロジェクトでは実際の手戻りはほぼなく進めることができたのですが、基本的には前述の**「開発項目ごとに開発状況を共有していく」**ことで前もって避けることができたように思います。

チーム文化・流行文化を作る

これは意外に重要で、そんなものリーダーが心を砕かなくても勝手にできるだろという面もあります。

「今日も一日」と書き込んでslackbotが反応する
おもしろreaction画像を充実させる

などといったくだらないものが結構重要で、肩の凝る職場では誰でも仕事はしにくいものです。

飲み会を頻繁にやるのも悪くないですが、費用もかかるし時間も拘束するしなにより飲めない人が置いてけぼりになるので、個人的にはあまりやりたくなかったというのもあります。

心理的安全性を高める上で、真面目すぎる態度はやりにくさを出してしまうと思ったので、お遊び的なものは取り入れていきました。

（今回はできませんでしたが、SHIROBAKOの上映会を事前にやれば良かったと軽く後悔しています。。）

タスクアサインと教育

タスクアサインや新人の教育についてはこのようにしていきました

心苦しかったが、最初にチームメンバーをスキルで「Aランク」「Bランク」に分けさせてもらった
- ランク分けには**「大きめの機能開発経験がある」「テストコードを書いたことがある」「ある程度大きな機能の設計経験がある」「自分の作ったそれらが実際にサービスとして稼働している」**といった指標をもうけて提示しました
- 「何で俺がAランクじゃないんだ」などという不公平感を防ぐためです
カイゼンジャーニーに「スキルセット表を作る」というのがあったが、あれをもっと抽象的にしたイメージ
ランク分けの理由は、個人のスキルをわけてタスクアサインの目安とするためである。
Bランクの人は簡単なタスクしかできないのかというとそうではなくて、難しめのタスクにもアサインできるようにしていた
ただその場合、必ずメンターをAランク人員から選出して二人で取り組んでもらうことにした
設計や仕様の読み合わせ等は二人でやってもらった

ポイントとなるのは経験者が必ずメンターになることです。

Bランク人員とされた人は都度アドバイスをもらったり経験者と組むことで、難しいタスクや設計の必要なものでも自信をもって取り組んでもらうことができたように思っています。

また、メンターになったAランク人員も「人に教える」ことで得られるものができたように思います。

プロジェクト終期

開発期間が減ってきてソースコードフリーズ日が迫ってくると、開発速度も増していきます。

この段階になってくるとあれこれ考えるよりも手を動かしていくことを優先していきますが、どうしても休日出勤せざるを得ない時が出てきます。

休日出勤をせざるを得ない時に気をつけたこと

任意出勤とし、強制しない
また、強制するような空気にもしない
最大週６日勤務とする。７日以上連勤させない

ということを心がけるようにしました。

結果的に「７日以上連勤させない」の部分が達成できないこともあり、力不足を感じていたこともありました。。。

おわりに

本当はインフラ・アプリコード内負債の返済のための（対外的実装項目外の）自主的な実装や、新卒社員への教育プロセス、プロジェクトを阻害するチーム外要因と戦う等もあったのですが、さすがに長くなりすぎる上に今後への応用が利きにくいかと思ったのでやめました。~~聞きたい方は個人的にお願いします~~

いろいろと施策を行ってきましたが、なんだかんだいって開発フェーズチームのリーダーはいろいろと心労が絶えないものです。

次回の不安編で、「そうはいっても気持ち的にこんな不安を持っていたよ」ということを書こうと思います。