天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

チームの新規参入障壁を下げるためにしている(し始めた)取り組み

タイトルの通り、チームの新規参入障壁を下げる(なるべく早くチームに馴染み、チームが行う仕事をできるようにする)ためにしている取り組み、し始めた取り組みをざっくりではありますが紹介してみようと思います。

チームのコンテキスト

人数

4人

プロダクト

数十年稼働しているレガシー目な金融システム。ドメインがかなり複雑*1な一方で使用している技術要素は限定的。

障害が大事故になるリスクがある。*2

具体的な取り組み

モブワーク

至る所で紹介されていることですが、モブワークをすることでなるべく早く仕様やチーム内にある暗黙知をキャッチアップしてもらうようにしています。
モブワークなので、コーディングだけではなく仕様策定やカスタマーサポート、改善活動といった仕事もモブワークで実施します。
また、ふりかえりの時間ではリーンコーヒーを導入してチームの関係の質を上げることに焦点を置くなど、モブワークをなるべくスムーズにしやすくするための準備を定期的にしています。

WIPを下げる

個人個人が全く別々の仕事に取り掛かることがなるべくないようにWIPを極力下げています。
これも至る所で言われている内容ですが、リソース効率よりもフロー効率を意識し、誰か手が空いている状態をチーム全体で許容するようにしています*3

機能を消す

膨大な影響範囲調査コストやソースコードの可読性の低さを減らすために、ゾンビコードや使われていない機能...をひたすら消す取り組みを実施しています。

(簡易的な)パターン・ランゲージづくり

これは最近始めた内容ですが、Miroで簡易的なパターン・ランゲージを作成しています。
分散アジャイルチームできょんさんが実際にチームでやられているパターン・ランゲージ作りを参考に、とにかく一つ一つのパターンを小さく分けて(全部が全部ではありませんが、数十秒~1分程度にまでできる限り分けて)、パターン同士のつながり*4をMiroで作ることで、パターンの再現性を高め、ドメイン知識が少なかったりチームでの開発歴が短い状態でも再現できるようにしています。

 

以上です。
今回の記事は超ざっくりかつ取り組みを絞って書きましたが、より具体的な効果や今回書かなかった取り組み(まだそこまで効果が出ていない取り組み)に関しては、また別の記事で書いてみようと思います。

*1:日常生活で聴きなれないドメイン用語が膨大にある上にドメイン用語に方言的なものが混じっているため一つの概念に多数の名前がついていたりする、利害関係が一致しないステークホルダーが複数いる、数学的な知見が必要、数千の仕様、業界がかなりクローズドなためインターネットや本といった媒体で知見が確立されていない(どのロジックも変更の可能性が常に高い)...

*2:先日あった東証障害やみずほの障害をイメージしてもらうと良いかもしれないです

*3:ただし、この記事では書きませんが空きすぎてしまい幾つかの問題も起きてしまうこともありました

*4:パターンAがパターンBの基になることを示すようにする