Man in white dress shirt sitting beside woman in black long sleeve shirt photo – Free Happy Image on Unsplash

こんにちは。エンジニアの塚原（＠AkitoTsukahara）です。

弊社の開発チームでは業務の知見を「型」として文書化し、チーム内で共有しています。これまでにもいくつか型の紹介をさせていただきました。

tech.macloud.jp

今回は型の中でも一番読み返されているであろう「開発メンバーの型」について、ご紹介させていただきます。この型はメンバーが高い生産性を実現するためのルールでもあり、新しく入社したメンバーがチームで活躍するための道標にもなっています。ですので以下のような方におすすめの記事になっております。

開発メンバーのルールを明文化したいリーダー
新しく入社したメンバーをサポートするメンター
チームで活躍したいメンバー

これより以下はほぼ原文ままになります。

弊社ではプロジェクト管理にJira、開発手法にスクラムを採用しています。これらの専門的な用語には注釈を付けさせていただきました。

これはなに

M&A クラウドにおける開発メンバーの型です。
これに沿って生産性の高い状態で作業できるようにする目的です。

マインドセット

チームの仕事である

開発チームの仕事はチームでやることである。
成果物はチームの共有物。自分だけの仕事が進んでもユーザに大きな価値は届けられない。そのために以下のことを前提として意識する。

自分の仕事を終わらせるために人のリソースを使う（無駄使いはしない）
人の仕事を終わらせるために自分のリソースを使う

理解が甘いものは外に出さない

仕様について
- 自分がタスクとして取り組む作業の仕様は、自分が納得いくまで理解してから取り組む
  - 背景の理解
  - 影響範囲の理解
    - ページや機能の影響範囲
    - 社内ユーザ含むユーザへの影響範囲
コードについて
- コードに対しても納得して人に説明できる状態になること
  - 自分が書いているコード
  - 他人が書いたコードも、自分がレビューした場合、自分のものとして納得して説明できるようにする

開発メンバーがやること

タスクをやる

見積もりをする

ストーリーポイント*1をつける。

ストーリーポイントは基準となるタスクをあらかじめチームで決めておき、0.5,1,2,3,5,8,13とフィボナッチ数列の数から決める
- 8ポイント以上の大きいタスクの場合は、1ptの調査タスクを実施してから残りの作業分を1,2,3,5に振り分ける
ストーリーポイントの決め方や基準となるタスクに違和感があったらそれ自体を議論する

着手するまえに

「ユーザーストーリー」*2と「AC」*3を理解する
想定されていた仕様や影響範囲に誤りがないかコードや仕様を調べる
小さいタスクでも情報を持っている人に仕様の認識合わせをする
- 急ぎでなければSlackでも良いが、口頭や通話も積極的に活用する
- 口頭で話した内容は Jira issue*4に経緯と結論を記録しておく
タスクをやる前にタスクが属する一連の作業の全体像を掴む
具体的にコードをどのように変更すれば良いかイメージする
- 必要に応じて書き出して抜け漏れを防止する

着手する

他の人にやっていることを表明する。Jiraでのステータス管理はその一つの形。

「 READY」のタスクを受け取り「IN PROGRESS」に移す*5
着手前に想定した方針にしたがって変更を行う
方針を立てる前にとりあえずコードを書くはNG

自分の状況をオープンにする

詰まっていない時。今何をやっていてどういう風に進めようとしているのかをオープンにする（推奨）
- Slack につぶやく
- デイリースクラム *6で共有する
詰まった時
- 15分程度で詰まりつつあるくらいであれば Slack などに投げ込んでおく。非同期できく。
- 1時間以上詰まる場合には積極的に指名したり口頭相談したりヘルプを求める

※「詰まる」とは？調べて突破口になる解決策が全く見えない時。タスク内容によるが、以下のような目安。 - 仕様や背景が分からない場合。 - 調べていて新たな検討できる情報がない時

実装をする

「すでにある実装」はあくまで参考にとどめ、あるべき形考えてそれを表現するコードを書く。
- ただし、大きく設計が変わる場合には他との整合性が取れなくなる可能性があるので、チームに提案ベースの相談をしてから進めると良い
変更するコードの影響範囲を調べ、それぞれの箇所でユーザに価値が変らず届けられているか確認する
アーキテクチャに関わる実装変更が必要であると判断した場合は、コードを変更する前にメンバーを集めて意見を募る

レビューをやる

１チケット制限

M&A クラウドの開発チームでは「１チケット制限」を導入してます。
基本的にタスクは１つだけを持つこととし、二つ以上のタスクは並行して行わないようにしています。
目的は、複数のタスクが並行で走ることによるコンテキストスイッチの増加による生産性の低下を防ぐこと。

レビューは自分の仕事と同等か、やや優先するくらいの気持ちで

１チケット制限の前提において、誰かのPRが来ているということは、その人は手が空いてしまっているということ。
合間の時間にチケットとは無関係の仕事を進めることはできますが、あまりに時間が開くと優先度の低い仕事をやってしまうことがある。
そのため、レビュー依頼が来たら30分以内で最初のチェックをする。

マージされなければ１チケット制限は解除されないので、マージまで伴走する気持ちで進める。
例えば良く分からないコードがあった場合に「よくわからないから後回しにしてしまおう」ではなくて、「よくわからないので口頭で解決しよう」が推奨される。

リリースする

現在はトランクベース開発が導入されたので、通常リリースはPRのマージのみ。feature toggle の on はリーダーと共に行う。

会議を前に進める

チームでの成果や合意の方向に向いて発言をすること。
会議目的からずれる発言は、一旦メモをしておき、後で適切な会議に持ち込んだり非同期で話すなどする。
単に自分が言いたいだけの話は、会議以外の少人数の集まりの時にする。

その他マインドセット

時間の使い方について

自分のタスクをやっているときに詰まったり、トラブルがあったときの動き方。

時間をかけないこと
- 他の人の助けがあればすぐ解決するものは人の力をうまく使う
  - 誰かに聞けば分かることなのに半日や一日使うのはNG
  - 明確に、その領域に対しての学習のために幅広く何かを学ぶという目的があればある程度時間を使っても良いが、右往左往している時間は勿体無いので減らすこと。誰かと協力して短時間で解決した後に、腹落ちのためにちゃんと調べても近い学習効果は得られる
時間をかけていいこと
- 誰かに聞いても分からなかったこと
- 他に回避の道がない場合。自分しかできない仕事の場合
  - 記録を残しつつ、進捗や学びは共有しつつ進める