これが私たちの勝ちパターン【開発メンバーの型】をご紹介

f:id:tsukahara1991:20220125001537j:plain Free Office Image on Unsplash

こんにちは。エンジニアの塚原(@AkitoTsukahara)です。

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

tech.macloud.jp

tech.macloud.jp

tech.macloud.jp

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

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

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

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


これはなに

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

マインドセット

チームの仕事である

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

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

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

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

開発メンバーがやること

タスクをやる

着手するまえに

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

タスクの進め方

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

f:id:tsukahara1991:20220125113204p:plain
Jiraのカンバンボードでタスクの進捗ステータスを確認する

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

  • 詰まった時だけではなく、できれば今何をやっていてどういう風に進めようとしているのかもオープンにする
  • ※詰まるとは?
    • 調べて突破口になる解決策が全く見えない時
    • タスク内容によるが、以下のような目安
      • 仕様や背景が分からない場合。すぐに聞く。
      • 技術的に詰まった場合(調べていて新たな検討できる情報がない時)
        • まずはググってみる、関連実装探してみる
        • 15分程度で詰まりつつあるくらいであれば Slack などに投げ込んでおく。非同期できく。
        • 1時間以上詰まる場合には積極的に指名したり口頭相談したりヘルプを求める

実装について

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

ストーリーポイント*6が妥当かどうか

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

時間の使い方について

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

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

我々はユーザにアウトプットを届けるために仕事をしている。また、一人の力ではなくてチームのアウトプットとして外に出しているのでその過程もチームの力をうまく使うこと。

レビューをやる

1チケット制限

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

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

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

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

リリースする

他の人の仕事も含めて巻き戻しや修正の判断ができる状態になったら「リリたん」(リリース担当)の一人になります。

会議を前に進める

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

会議体

インフラ確認会

  • 新しいAWSコンポーネントを使ったりする時には、開発チーム全体に背景情報と知見共有のために「インフラ確認会」を開催する。
  • 既に何度も類似の設定がされている場合にはインフラの変更であっても小チーム内のみの確認でOK
    • ただし、設定する内容は開発チーム全体に影響する可能性があるのでSlackなどで全員が作業したことが分かるように連絡はしておく
  • 以下の情報を資料に含めてメンバーが設定する
    • 背景情報(解決したい問題など)
    • 設定概要(ここまでエンジニア全員が出席する会)
    • 設定詳細(興味ある人、小チームメンバーが出席する)
      • ドキュメントと見るべきところ。 ドキュメントが分かり易ければリンクだけ貼っておくでも良い

その他

人のマインドシェアを取らないように動く

前提: 仕事を任す人がリーダーであってもPdMであっても、リソースは限られているので全てのタスクについて詳細情報を持って適切なタイミングでリマインドすることは不可能。スケールするチームのためには、メンバーそれぞれが一番詳細度の高い情報を持ってタスクを進めることが肝要。

任された仕事について、責任を持って詳細まで含めて着地に持っていくこと。
仕事を任された時点でその仕事はメンバーの持ち物。
以下のように動く。

  • 最終ゴールまでにやらなければいけないことはメンバー側が情報を全て持っていること。また、そのように情報を集める
  • メインのタスク以外で任された細かいものも、いつまでに回答 or 終わらせるかなど明示的にコミュニケーションする

※「人を頼ってはいけない」とは違うので注意。前述の「時間の使い方について」の通り、チームとして成果を得るために情報が足りなければ他の人のリソースも積極的に活用する


採用やってます

弊社ではエンジニア採用を行っています。 スタートアップ企業でのWeb開発に興味のある方は、ぜひカジュアルにご応募ください🤝

www.wantedly.com

www.wantedly.com www.wantedly.com

*1:ソフトウェアの機能がユーザーにとってどのような価値をもたらすのかを示すもの

*2:受け入れ基準 (Acceptance Criteria):プロダクトオーナーの視点から何を持ってプロダクトバックログアイテムが完成したかを確認するための基準

*3:Jiraにおけるタスクの意味

*4:「 READY」、「IN PROGRESS」は Jiraのタスク進捗ステータスを表します。

*5:スクラムチームの開発者のための15分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。

*6:ユーザーストーリーを実装するのに必要なコストを見積もるための単位