うまく回る理由

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

この記事の方針

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

ペアプロモブプロの効果

  • 二人以上で作業を行うため複雑な仕様を一人が分からない場合
    または意思疎通しながら進行する場合にテキストが自然と生まれる。
    テキストが生まれることで、不明点の発見ややるべきことが明文化かされはっきりする。
    この影響でメモ的な詳細設計書が他者にも伝わる形で残る効果があるように思う。
    やるタイミングはレアコアな部分を複数人でプログラムすることで属人性の排除、特殊技術の伝播が効きやすい。 コーディングスタイルの衝突による新たな理解。認識融和、 休めるという意識。 ただし、仕事の好みのスタイルは人によって異なるのですべてを操作せることは最適解ではないのではと考える。

体制が時々変わる

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

横断的な会議が存在する

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

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

うまくいかなかったこと

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

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

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

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

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

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

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

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

タスクを分割する

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

TDD

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

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

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

認識の齟齬が発生

あると思っていなかったが、上位の企画者から指摘が入ったため画面仕様の打ち合わせと企画立案使用策定会議が発生した。 これがなぜ発生したか。。？ これが発生する段階は正しかったのか？ これが発生したのは巻き込みが少なかったからか？ なぜか問題は何だったか自分の中で整理できていない。 だが、一旦入ってもらっていないチームにも定期開催の会議に入ってもらうことにした。 自律的に能動的に動けているのチームとしては機能しているがプロダクトをチームが所有していない事態ではあったと思われる。 もう少し精査が必要。 あ時になるのは、可逆的な判断は、少人数または、個人が決定するべきとある。 迅速に判断が行えるから。今こうやって関係者の巻き込みを増やしていく状態は正しいだろうか？という懸念がある。。。 様子を見る。上記の仕様変更に伴う時間は計上され、仕様変更による工数はプラスアルファされたことはきちんと押さえたいポイント。 ただアジャイルであるなら一旦機能の分割投入を検討するくらいの冷静さが欲しいがもう少し意見を聞いて様子見したい。

うまく回るとは？

ここまでうまく回るが何かをうまく定義できていなかった 自律的に立ち回れ、課題を改善しながら良いプロダクトに進んでいけるチームがうまく回っている状態なのかなと思う。。健康には気を付けた行動することは絶対条件(保留)

フィードバックループが小さくあれば良い理由とうまく回らないことについてのメモ

大きなフィードバックループをしているうちは、問題が表面に現れてから問題に対応することになってチーム自体が疲弊して、チーム内の余計な不信感、疑念、疑惑が発生してしまう。 結果、炎上しうまくいかない。

自律とは何か？

再考するべき。

ペアワーク

ペアワークのメリット チームへの信頼感が無い状態の時に、カジュアルに聞ける環境構築できるので、できる人でも実直にやるしかないと思えること。 不安な時間減少と調査時間、諦める時間などが減少するので効果的。 ペアプロよりもカジュアル。カジュアルに技術を伝播できる。ペアプロだと画面凝視して疲れる。 ペアプロでは発生しづらい思い付きの発露、アイデアの種うえ、雑談が少ない問題の解決につながる。 これは試していないが横断的領域においても効果は発揮するのではないかと予測する。 ペアプロだと横断的な領域での実現は厳しいが別分野でも同じチームで作業する場合余移行が生まれるかもしれない 単純に仕事に対する心理額の専門用語でいうところの強化も発生するだろう。