うまく回る理由

プロジェクトが継続的に回る理由

この記事の方針

この記事はペアプロ・モブプロ、テストコードあり、スクラム開発、CI/CD環境あり、マイクロサービスアーキテクトで開発している際に 詳細な設計書等がなくてもうまく回っていくのはなぜなのかを探るため、日々気づいたことを書きためておくための記事となる。 なので気づきがあれば更新をする。

ペアプロモブプロの効果

  • 二人以上で作業を行うため複雑な仕様を一人が分からない場合
    または意思疎通しながら進行する場合にテキストが自然と生まれる。
    テキストが生まれることで、不明点の発見ややるべきことが明文化かされはっきりする。
    この影響でメモ的な詳細設計書が他者にも伝わる形で残る効果があるように思う。

体制が時々変わる

プロダクト内で
なぜうまく回るかわからないが体制が良く変わる
ただ、ジョブ型で対応していて必要な体制に柔軟に変わっていく。

横断的な会議が存在する

プロダクト会
チーム会(改善系、新規開発系、プロジェクト系)などの分類
プロダクト内でのバックエンド定例、FEBFF会 VD会
各チームの朝会
各層でのレトロスペクティブ

相談事をやろうと思えばできる場が用意されている。
個人が上位チームへ進言しやすい環境の一つであると考えられる。

うまくいかなかったこと

体制とスプリントが決定した後に人員が別チームに移動になり、結果、チーム内でタスクを扱うことができる人員が存在しなくなり、別チームが受け持つ必要が生まれた。
スプリント進行中に裏での引継ぎ、調整が発生し、メンバーからの不満の声も漏れた。
プラスアルファでこのとき、プルリクエスト途中のタスクがある状態で別チームに人員が回るような状態も発生し、チーム間でのやり取りタスクの引継ぎが発生したときに
弱い組織状態であることが判明。チーム間のやりとりは少ない方が良い?

横断的にレビューをするような文化

なぜこれがあるのか、どういうところにそれを感じるのかを記述すること。

企画主体だが、別途スクラムマスタが存在する

以下から思い出しました。

上記結果的に進行がスムーズ

DEV、STG、PROD環境へのデプロイがカジュアル。

マージボタン押すだけ。
あとはyaml定義に沿ってデプロイ。
社員以外もデプロイしている。
レビューは2人以上で可
社員以外の場合社員に最低一人はaprove貰う必要があるが、かなりカジュアル。

タスクを分割する

タスクを分割してチケットを作成する。
上記を行うことで何が良くなるのかわからないが、どういう風に進行しているかを周囲の人間が認識しやすくTeamを横断したチェックが入りやすくなる。
また、チェックをする敷居が低くなる?何をしているかが一定数の人間に伝播するためであると思われる。
チケットにはゴールを書くこと。
定量的なものでなくともよい。
気軽なチケット作成で多くの人に状況が伝播しやすい環境の効果があると思われる。

TDD

単純にTDDにすることで不要なドキュメントが減る。
TDD実施することで、設計も同時にできるため。
リファクタリングや機能追加も割合容易にできるためよく回る。

企画と開発とがともに話す場を設けることの意味

情報の開示-情報の共有-疑問点または心のもやもやの解消を行うことで、互いに信頼、知識や状況の把握があることによる安心感を得られ心理的安全性を本来の意味でのチームの中で得ることができる。 分断した話し合いを行うことは情報の伝達効率が悪く、解釈と思い込みが発生し、コミュニケーション摩擦により心が摩耗する。しんどくなる。そして、モブ性に甘えるという本来の性分に落ちて情報の非対称性が生まれてお互いのことを理解できなくなり、開発チームと企画チームまたはもっと細かい粒度でチームが分断し、本来の目的を見失う。個々の目的を達成するために企画と開発が対立して心理的安全性は下がる。 個々の目的は達成しているが、余計な労力もしていて、真の目的を達成できなくなる。 本来サービスを届けるチームなんだけどな。。 モブ性に甘えるのはよくある平均的な人間だと思う。人が落ちていかないように場を作ることは大切。 仕組み上分断していたチームも場を提供することで生き生きとしている場面を見たときに思ったこと。 上のことをやったときにスクラムマスタの存在は不在だった。 存在させたら何か変わるような気がする。スクラムマスタの役割を学習して今のチームにぶち込んで何がどう変わるのかを確認してみようと思う。 ※心理的安全性が下がるはいいかえると不安になる。ということ。話す場を提供して情報を共有することで別の役割の人間に安心を提供できるという話。