はじめに
私は社内向けプラットフォームチームに所属しており、スクラムの手法でプラットフォームの構築・運用を行っています。
執筆時点で、私は現在のチームに約2年間所属しました。当チームでは、メンバーの入替がそこそこあり、参画時のスキルもバラバラでした。開発が進むにつれて求められるスキルはどんどん増えており、オンボーディング1など持続可能なチーム運営の工夫が必要でした。
一方、「アジャイル宣言の背後にある原則」では、アジャイル・プロセスを進めることで持続可能な開発を促進すると紹介されています。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
アジャイル・プロセスでは、具体的な改善点を議論して開発に反映していきますが、反映する内容はチームごとに異なります。2年という節目を迎え、様々な気付きやノウハウが溜まったため、当チームの事例を本記事で紹介します。
属人化とは
属人化の定義について、本記事では以下を引用します。
属人化とは、特定の社員が担当している業務が、当人しかわからない状態になっていることです。
出典：https://business.ntt-east.co.jp/content/cloudsolution/column-396.html
一般的に、業務で高い専門性が求められる場合は属人化してもよいと言われています。しかし、持続可能なチームを運営する上で、特定の開発業務が特定のチームメンバーに依存してしまうのは避けたいです。もし、有識者に頼り切りとなっている場合、以下のような問題があります。
- 新メンバーが育たない
- 有識者のモチベーション低下
- 有識者離任時のノウハウ損失リスク
一方、以下で紹介されている通り、有識者（スペシャリスト）のノウハウは、高い専門性であっても工夫次第で共有可能です。
スペシャリストの業務は専門性が高いといえども、業務実態の可視化や共有は可能です。知識やスキルをマニュアルや業務フローで整理し、新たなスペシャリストの育成に貢献するケースもあります。
出典：https://www.nec-solutioninnovators.co.jp/sp/contents/column/20221021_individual-dependence.html
本記事では、メンバー全員が専門性を高められるように工夫した点を紹介します。
開発プロセスに取り入れた8つの習慣
以下では、属人化しない持続可能なチームを目指して、当チームが開発プロセスに取り入れた8つのプラクティスを紹介します。
1. 退勤時点における進捗・活動実績時間を記録する
当チームでは、各メンバーが退勤時点における進捗・活動実績時間を記録しています。
水面下で作業が遅延している場合、担当者自身がヘルプを求められればよいのですが、もう少しで完了できそうという心理になりがちです。このような場合、まだチームに慣れていない新メンバーなどは中々声を上げづらいです。一方、退勤時点での進捗や、どのくらいタスクに時間がかかっているのかを可視化しておけば、翌営業日のデイリースクラム（朝会）で周囲がフォローしやすくなります。また、担当社員に突発的な休暇が発生した場合、他のメンバーに引継ぎしやすくなります。さらに、活動実績時間をきちんと記録しておくことで、次回以降同様のタスクが発生した際に、作業時間の見積もり精度が向上します。
当チームでは、コーディングの途中であっても、退勤時の断面で Commit して、リモートブランチに push することをルール化しています。また、担当している作業チケットに作業経過・残タスク・実績時間を記録しています。
私自身、子供の急な発熱により突発的な看護休暇をいただく場合がありますが、本プラクティスによりスムーズに引継ぎができるため、とても助かっています。
2. ドキュメント作成の時間を確保する
当チームでは、スプリントプランニング（計画）でドキュメント作成の時間を必ず確保しています。
新メンバーがキャッチアップするためには、プロダクトコードだけでなく、理解しやすい視認性に優れたドキュメントがあると良いです。既存メンバーにおいても、このようなドキュメントは開発を進める上で有効です。当チームでは、構成図やユースケース図などに加えて、設計根拠を書くようにしています。そもそも外部の公開記事に書いてある内容は、設計の参考としてリンク一覧を載せています。
アジャイルソフトウェア開発宣言2に則り、開発者が内部で参照するドキュメントでは、包括的なドキュメントを目指していません。あくまで開発の補助的な位置づけとして、ドキュメントを作成しています。こういった内容を書いた方がよいという擦り合わせはしていますが、記述の融通を効かせるため、ドキュメント構成などに対して厳密なルールを強いていません。ドキュメント作成者以外の開発者が疑問に感じた際は速やかに会話し、必要であれば修正するようにしています。
対照的に、ユーザー向けの公開ドキュメントは不特定多数の方が見るため、開発者や管理者など複数のロールの方に理解してもらえるよう、形式をある程度決めています。また、ユーザー向けの公開ドキュメントについては、理解しやすいかという観点で開発者以外にも確認してもらっています。
3. ペアプログラミングを実践する
当チームでは、基本的にペアプログラミングで開発します。単純な修正や検証などを除いて、個人でプログラミングするケースは殆どありません。
ソースコードをチーム内へ共有・精査するために、コードレビューを行うのは一般的です。プログラマが知るべき97のことでは、コードレビューの目的が以下のように紹介されています。
コードレビューの目的は、ただコードの誤りを修正するだけではありません。重要なのは、チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立することです。自分の書いたコードを他のプログラマと共有することで「コードの共同所有(collective code ownership)」が可能になります。
出典：https://プログラマが知るべき97のこと.com/エッセイ/コードレビュー/
ペアプログラミングでは常にコードレビューしながら実装を進めるため、品質向上に加えて、知識共有も容易です。コードの文法だけでなく、メンバーの GUI 操作なども共有することができ、コマンドやショートカットキー、メモの取り方など色々と発見があります。
現状、当チームでは個別のコードレビューを設けていません。知識が偏らないように、スプリントプラニングで開発対象のペアプログラミング担当をローテーションしています。個人の希望を大切にしているので、担当分けは機械的なローテーションではなく、対話で決めています。
余談ですが、一部スクラムイベントのファシリテーターは、開発メンバーで機械的にローテーションしています。ファシリテーターを定期的に行うことで色々な気づきがあり、チームの自己組織化にも繋がるプラクティスだと感じています。
4. テスト駆動開発を実践する
当チームでは、最初にテストコードを書いてから、プロダクトコードの実装を進めるテスト駆動開発（TDD）を取り入れています。テスト駆動開発は、敢えてテストを失敗させる Red から始まるのがミソで、Green、Refactor のフェーズを繰り返して開発を進めます。
以前は、プロダクトコードの後にテストコードを書いていました。しかし、テストを後回しにしていたため、良かれと思って設計にない項目まで実装しており、時間が不足するといったことがよくありました。その結果、以下のような問題が発生し、メンバー間のコード共有に課題を感じていました。
- 本来の設計に対する実装漏れ
- コードが冗長で読みづらく、保守性が低い（リファクタリング不足）
テスト駆動開発では、まず実装前に設計からテストの ToDo 一覧を洗い出します。そのため、本来の設計に対する実装漏れを、開発の早い段階で抑えることができます。また、設計から ToDo を洗い出すことで、必要な機能だけを実装する「YAGNI（You Aren't Going to Need It）原則」を準拠しやすくなり、不必要な実装で時間が不足するといったことも抑えることができます。
その後、ToDo 一覧に従って、Red → Green → Refactor のサイクルを繰り返します。このサイクルでは、リファクタリングが常に行われるため、コードの冗長性が抑えられ、保守性が高まります。TDD が特に効果を発揮するのは既存資産に対する追加開発時で、テストコードから小さく取り掛かることができ、リグレッションテストが容易です。
当チームでは、新メンバーもまずは既存のテストコードを動かして仕様を確認しており、TDD のサイクルが習慣化されています。テスト駆動開発をペアプログラミングと組み合わせると、品質の向上だけでなく、新メンバーもキャッチアップしやすくなるため、とても良いプラクティスだと実感しています。
5. 自動チェックできる仕組みを設ける
当チームでは、人に依存せず自動チェックできるように、静的解析ツール（Linter）の導入範囲を徐々に拡大しています。
当該プロダクトの開発言語では TypeScript を主に利用しています。当初は、以下のランドスケープで紹介されているコーディング規約チェックツールの ESLint とコード整形ツールの prettier のみを導入していました。3
出典：https://typescriptbook.jp/overview/ecosystem
その後、ドキュメントやセキュリティ設定などのチェック漏れに関する課題があがりましたが、チーム内レビューでチェック漏れを防ぎきるのは難しいです。そこで、自動チェックできるツールを模索し、文章校正ツールの textlint やセキュリティ・コンプライアンスチェックツールの cdk-nag などを導入しました。その結果、各種ルールのチェックが人に依存しなくなり、品質が向上しました。自動チェックが進むと、本来の議論から外れるような細かい指摘を人がしなくてよくなります。そのため、チームの雰囲気も良くなったと感じています。
特に、文章校正ツールの textlint は、単純な「てにをは」系や表記ゆれの指摘・対応で消耗することが減ったため、重宝しています。最近は、図中の文章も textlint でチェックできるように、テキスト形式のファイル（PlantUML）で図を作成しています。
言わずもがなですが、各ツールは導入して終わりではなく、適宜ルールを見直しています。
6. 生成 AI を活用する
現代では、ChatGPT を代表とする優秀な生成 AI が存在し、様々な用途で活用できます。当チームでは、開発プロセスで生成 AI を積極的に利用しています。有識者の負担を減らすという観点で、生成 AI は非常に便利です。
当チームでは、以下のケースで ChatGPT を活用しています。
- 要件に対する実現手段の提示
- textlint では修正しきれない文章表現の見直し
- 技術要素に関する解説・仕様の提示
- サンプルコードの提示
- リファクタリング
- エラートレース
- etc...
生成 AI が台頭する以前は、まず自身で調べて、分からない点を有識者に聞くといったことが一般的でした。しかし、
業務で ChatGPT を使えるようになってからは、開発時に困った点を気軽に質問できるようになりました。そのため、経験の浅いメンバーが有識者に頼りきりといったケースが少なくなりました。
導入当初、人によって生成 AI を使う頻度がまちまちだったので、「その疑問、ChatGPT に聞いてみる？」といったことを積極的に声がけしていました。その結果、メンバーが自発的にプロンプトを投げるケースが徐々に増えて、 チームで生成 AI の利用が浸透しました。ふりかえりの中でも、度々良かったこととして、生成 AI の活用が上がっています。
なお、私の所属部署では ChatGPT をチャットのオープンチャンネルで利用できます。ペアワーク時に期待するような結果が返ってこない場合は、交互にプロンプトを投げることが多々あります。当初、オープンチャンネルに投稿するのはやや抵抗がありましたが、他者のプロンプトからテクニックを学べるので、良い体験だと感じています。現在では、チームメンバー全員がオープンチャンネルから ChatGPT を活用しています。（※ChatGPT をプライベートで使える環境もあります。）
また、コーディング支援サービスの Amazon CodeWhisperer も活用しています。簡単に導入でき、コーディング中に CodeWhisperer から自動で提案が出てくるため、便利です。特にテストコードを書く際に重宝しています。過去の投稿で紹介していますので、詳しくは以下をご参考ください。
7. 定期的な開発者の共有時間を設ける
当チームでは、各スプリント（開発期間）を終えた後に、開発者のノウハウ共有時間を設けています。
ペアプログラミングを実践しているとはいえ、新しく試したことや細かな実装内容などをチーム全体へ共有するのは、スプリント中だと難しいです。そこで、各スプリントのふりかえり後に、開発者が自発的にテーマを持ち寄って勉強会を開催しています。1回あたりの開催時間は概ね1時間ほどです。共有事項がない場合は、無理して開催しません。
具体例として、ほぼ全員がテスト駆動開発（TDD）未経験だったため、導入初期にこの時間を使って勉強会をしました。実際に触ってみないと分からない部分もあるため、モブプログラミング形式の勉強会も行いました。分からないところがあれば都度質問するようにしているため、1時間の勉強会では足りない場合も多々あり、次回の勉強会に持ち越しています。質問しあえる雰囲気にも繋がっており、チーム全員のスキル平準化に寄与しているプラクティスだと感じています。
なお、勉強会でのノウハウは、後から見返せるようにチーム内 wiki へ残すようにしています。最近は、チームメンバーが登壇・ブログ投稿した内容をベースに、勉強会を行うといったことも実践しています。
8. カイゼンするという意思をもって「ふりかえり」に参加する
スクラムイベントでは、必ずふりかえり（スプリントレトロスペクティブ）を行います。そこでは、カイゼンアクションに繋げるための議論を重ねます。でてきたアイディアについては、基本的に次の期間（スプリント）で計画・実行します。
このふりかえりでは、各メンバーの悩みや懸念が共有されます。キャッチアップに不安が出ている場合など、フォローアクションを全員で考えます。これまでの Tips で紹介したものは、全てふりかえりで議論され、実際にカイゼンアクションとして実行されました。スクラムの基本ですが、やはりふりかえりは重要ですね。
ふりかえりになんとなく参加すると、課題やアクションが挙がりづらいです。以前、当チームでも課題が全然上がらない期間（スプリント）がありました。ふりかえりのふりかえりを毎回やっていますが、そこでスクラムマスターからカイゼンへ繋げようという促しが度々あり、少しずつメンバーの意識が変わっていきました。ふりかえりで「カイゼンするぞ！」という意思をもつだけで、議論・アイディアが活発になっていくので、ちょっとした意識の変革が重要ですね。
おわりに
本記事では、属人化しない持続的なチームを目指して、2年間のスクラムで開発プロセスに取り入れた8つの習慣を紹介しました。
これらのプラクティスは、あくまで当チームの事例です。スクラムでは、チーム毎に適したやり方があるため、本記事の各プラクティスは取捨選択の材料にしていただければと思います。
本記事がどなたかのお役になれば幸いです。