私は約4年間ほど、フルで一つのプロジェクトの開発メンバーとして活動してきました。4年間ずっと同じプロジェクトに100％関わり続けるのはあまりないことなのかなと思います。プロジェクトの初期段階は課題が多くあり残業も大きく増えた期間もありましたが、その過程でさまざまな課題を発見し、プロジェクトメンバー全員で解決していきました。そのおかげでプロジェクトの後期はかなり安定していて、保守のフェーズへも綺麗に移行できたと思います。これらの経験を備忘録として記録しています。
プロジェクトで実施していた内容と、その効果や問題点を記載しています。
当たり前のことを記載していると感じるかもしれませんが、この備忘録が新たに開始する長期プロジェクトの参考になれば幸いです。
プロジェクトの概要
- デスクトップアプリのアドイン開発
- 開発手法：アジャイル
- プロジェクトメンバー：4～8人 (うち開発メンバー：2～5人) ※変動あり
- 言語：C#
- コード管理 (バージョン管理)：git
実施していた内容
プログラミング作業関連
プロジェクト運営関連
プログラミング作業関連
単体試験仕様書のレビュー
プロジェクトが始まって数か月後の初期の段階から、単体試験仕様書に対してレビューを行うよう取り組んでいました。
試験仕様書の記載は開発 (PG) を担当した開発者が行い、レビューはお客さんからの要望を直接聞いていて仕様を把握しているPMが行っていました。
効果
-
試験仕様書自体の品質が上がり、効果が高いテストケースを実施することができた
自分がPGを組んだ箇所に対して試験仕様書を記載することは、心理的にテストケースが緩くなりがちかと思いますが、他者のレビューが介入するという工程が挟まれたことで、試験仕様書の記載内容自体の品質もあがりました。そのため、効果が高いテストケースをもってテストに臨むことができました。
-
仕様漏れ (バグ) を未然に防ぐことができた
レビューの際に、PMが想定していた仕様だが開発担当者が考慮できていなかった動作パターンを見つけることができました。漏れていた原因としては、開発担当者の考慮漏れや、PMから開発担当者へ情報が100％伝達できていなかった場合等、様々なパターンがありました。
他開発者への仕様の連携
プロジェクトが始まって1年経過したころから、実装が完了しプルリクエストを送る際、プルリクエストの本文にどういう仕様で機能追加や変更を行ったか、可能な範囲で他の開発者に共有するような取り組みを行いました。
効果
-
メインで開発したメンバーでなくでも、その機能の改修作業をスムーズに行うことができた
一つ下のコードレビューを行うにあたり仕様の把握もある程度必要ということもあり、実施していました。ただ良い副産物もあり、基本的に他の開発メンバーが担当している作業は教えてもらわない限り仕様の把握は難しいと思いますが、この取り組みによってAさんが新規開発した箇所をBさんが仕様変更の修正を加える、といった担当者の割り振りを柔軟に行えるようになりました。
問題点や気を付けること
-
細かな仕様の連携が必要な際は、別途必要な際に伝える
複雑な仕様がある機能の場合、プルリクエストの文章に全て記載していると時間が掛かってしまいます。その場合は少し簡略化してプルリクエスト文に記載しておき、追加の情報の連携が必要になった際はそのタイミングで別途連携する、という方法をとっていました。
※PMは全ての仕様を把握していたので、追加の情報は別途PMに聞くという場合もありました。
コードレビュー
プロジェクトが始まって1年経過したころから、コードレビューを開始しました。各開発メンバーがプルリクエストを行う際には、開発者間のコードレビューを通す必要があり、他の開発メンバーの承認を得られた後に初めてコードをマージするというルールで実施しました。
効果
-
可読性や保守性の高いコードがプルリクエストされるようになった
コードレビューを通じて、開発メンバーは最適なコードを書くことを意識するようになりました。その結果、プルリクエストには開発者が精一杯考えたコードが提出されやすくなりました。また自身で疑問が残るようなコードは、レビューに出す前に他開発者に相談してより良いコードに仕上げてからプルリクエストを送る、というメンバーもいました。
-
開発者メンバーのスキルアップに繋がった
開発メンバーでも、スキルがある人やセンスがある人、逆にプログラミング初心者など、さまざまなメンバーがいました。
なので他のメンバーが書いたコードを見ることはレビューする側にとっても大きな刺激になりました。レビューを通して初めて見た書き方を自身で調べてそのスキルを身に着けたりするメンバーもおり、コードレビューする側のスキルアップにも繋がっていました。
-
バグの早期発見ができた
コードレビューによってバグの早期発見が可能になりました。可読性が高いコードでもバグが潜んでいることはあります。特定の動作パターンでバグが発生するような処理を、レビュー中に指摘できていた場合も多くありました。
問題点や気を付けること
-
レビューに時間が取られる
特にプロジェクトが忙しい時には、レビューに十分な時間を割けないことがあります。その場合、レビューイがプルリクエストの際に、特にレビューしてほしい箇所や不安な箇所を他の開発メンバーに伝えておくことで、短時間でもレビューの質を高めることができました。
リファクタリング
プロジェクトが始まった初期のころ、開発作業が進むにつれて徐々にコードが煩雑になってしまっていました。なので、プロジェクトの開始から半年ごろのタイミングで、プロダクトコードに対して大きなリファクタリングを行いました。
効果
-
開発効率がアップした
コードが綺麗になったことで、実装や改修が行いやすくなりました。
リファクタリング直後は体感で半分以上、リファクタリング前と比べて工数が削減できていたと思います。
-
バグの発生率が減少した
リファクタリング前は「想定外の不具合」が多発していました。そしてその調査から修正までも多くの工数が発生し、修正を行ってもまた別の箇所の不具合がおきる、といういたちごっこ状態にもなっていました。リファクタリング後はコードが追いやすくなり、実装している最中もコード上の影響範囲がわかりやすくなったことで、「想定外の不具合」が起きるという現象は少なくなりました。
-
開発者の意識の変化
リファクタリング前はどちらかというと「割れ窓理論」的な状態となっており、煩雑なコードにさらに煩雑なコードが追加される、ということもありました。
リファクタリング後は、リファクタリングされた後のコードを触る、という意識の変化があり、「ボーイスカウトルール」のような状態になっていて、リファクタリングを行ったこと自体が開発メンバーの意識の変化にも繋がっていた思います。
また、リファクタリング担当者には、どういうコードが悪いコード (リファクタリング対象) か、逆に良いコードはどういうものかをリファクタリング後に周知していました。
プロジェクトの開発者にはほぼ未経験の初心者もおり、その周知によってどういうコードを書くべきか、という意識の変化もあったようです。
問題点や気を付けること
-
リファクタリングの進め方
リファクタリングの進め方は非常に重要です。特に以下の2点を事前に決めておかないと、大規模プロジェクトではその後に大きな影響を及ぼす可能性があります。-
担当者の選定
リファクタリングを行う担当者は、プロジェクトメンバーではない外部から知見のある人を採用するか、既存の開発メンバーの中でスキルの高い人に任せるかのいずれかになるかなと思います。スキルが高くないと、リファクタリング後に再度リファクタリングが必要になる可能性があるため、担当者の選定は注意が必要です。 -
期間の設定
リファクタリングは際限なく続けることができるため、一定の期間を設け、リファクタリングが必要な実装の中でも優先順位をつけて行うことが重要です。プロジェクト全体のコードがほぼリファクタリング対象となっていても、その中で優先度をつけて進めていくことが大事です。
-
担当者の選定
-
リファクタリングを開始するタイミング
リファクタリングは必要そうだと思ったら、早めに行った方がよいかと思います。
後々機能が大きく拡張されたあとにリファクタリングを行うと、複雑さも増して工数も大きくかかりやすいからです。また、上の「リファクタリングの進め方」と少し被りますが、一度に一気にリファクタリングをするのではなく、優先度が高い箇所から徐々に始めていくと、始めやすいと思います。
-
リファクタリング担当ではない開発者メンバーの作業
プロジェクトやリファクタリングの規模にもよりますが、リファクタリング中は、もしかしたらコードを触れない開発者も出てくるかもしれません。そういったメンバーは、リファクタリングの期間中は、資料更新の作業などを行っていました。
上記のような大規模なリファクタリングだけでなく、通常の改修作業の際にも、関連部分でリファクタリングが可能な場合は小さなリファクタリングを行っていました。その際にも必ずプルリクエストを通じてレビューを受けていました。
プロジェクトの運営について
KPT法の活用
プロジェクトが始まって1年半ほど経過したころは、仕様の共有やコードレビュー、リファクタリングを行ったことにより、プロジェクトが順調に回り始めました。その後プロジェクトをさらに良くする目的で、3か月に一度、プロジェクトのメンバー全員で、KPT法というフレームワークを使用してプロジェクトの振り返りミーティングを開始しました。
効果
-
モジュールの品質が高まった
最初はKeepが少なくProblemとTryが多かったのですが、何度も振り返りミーティングを続けていくうちにKeepが増え、逆にProblemとTryは減っていきました。
KPT法によりとても良い効果が出たのですが、成功した一番の要因としては、前回Tryで決めたことの達成状況を次回のミーティングで振り返るというサイクルで実践していたことだと思います。
-
プロジェクトをより良くする好機会になった
優先度の高いProblemやTryの数が減ってくると、次第にプロジェクトをより良くするための改善案のようなProblemやTryが上がるようになりました。今まであまり深く考えずに行ってきた作業やプロジェクト資材の管理方法についても、改めて見直して改善可能なところは改善を行い、さらに良いプロジェクトに進化することができました。
問題点や気を付けること
-
効果的な振り返りミーティングにするために (参考まで)
可能なら、KPTは振り返りミーティングの前までにメンバーひとりひとりが考えておく形が良いかと思います。携わっていたプロジェクトでは、メンバーひとりひとりが事前にKPTを考え、KPT法のフォーマットにのっとり各自のKPT表を作成していました。その後、会議でそれぞれのKPTを発表し合い、プロジェクト全体のKPTの方針を話し合う、という方法をとっていました。
事前にひとりひとりKPTを考え出すことにより、ある程度時間に余裕をもってKPTを考えられることや、前もって自分で考えたKPTがあるため会議でもディベートしやすくなり、その結果プロジェクトにとっても良いKPTに仕上がっていたと思います。
Wikiの活用
Wiki (プロジェクトメンバーで情報を共有できる掲示板) も多く活用していました。
基本的にメンバーが好きなタイミングで更新したい部分を更新できるようにしていました。ただし勝手に更新して終了するのではなく、更新開始前と更新完了後に他のメンバーに通知し、特に更新完了後には記載内容を他メンバーに確認（精査）してもらっていました。
効果
-
作業の属人化を防ぐことができた
例えばテスターがテストを行う際の作業の流れや注意点を記載しておくことで、テスター以外もテスト作業を行うことができました。また、開発メンバーも開発開始から完了までの一連の流れを記載しておくことで、テスターの方が簡単な開発作業に入りやすくなりました。これにより、例えばテスターが不在の日に急なテストが必要になった場合でも、プロジェクトメンバーが柔軟に対応できるようになりました。
-
新規参画メンバーのキャッチアップが少し容易になった
ある程度の作業の流れをWikiに記載しておくことで、新規にプロジェクトに参画したメンバーのキャッチアップが少し容易になりました。
もちろん口頭で伝えなくてはいけないこともありますが、新規参画者は最初は覚えることも多いと思います。なので、例えば作業の流れを忘れてしまった場合も基本的なことがWikiに記載されていれば、Wikiを確認しながら少しずつ自身で作業を進めることができます。
問題点や気を付けること
-
記載内容や記載方法の工夫が必要
例えばリリースごとに変わってしまうような、更新頻度が多い情報がWikiに記載されていた場合、リリースごとにWikiも更新しないといけません。また、よく変更があるUIのキャプチャをWikiに添付していても、すぐにWikiの情報が古くなってしまいます。なので、更新頻度が高そうな情報は、特に記載する必要がない場合はなるべく書かない方がよいです。もしくは、記載する場合は情報が更新されても、Wikiには更新が発生しないような書き方の工夫が必要です。
-
ある程度の期間で、ページ構成の見直しが必要
更新頻度にもよりますが、ある程度の期間 (1年～2年？) 書き込みを続けていると、当初よりもWikiのページ数が多くなり、階層構造も複雑になってきやすいです。
あまり重要ではないと思う人もいるかもしれませんが、プロジェクトのWikiの構成が見辛くなっていると、単純にWikiを確認しようというモチベーションが低下してしまいます。
そうなると、Wikiを確認する前に他の開発メンバーに情報を聞いたりと、そういったことが発生し、無駄な工数が取られてしまいます。
なので、一定の期間が立つとページ構成を整理する必要があると思います。
整理する際は、記載されてから期間が経っていて情報が古くなっていた箇所の更新も同時に行いました。また整理の開始前や完了後は更新時と同じようにプロジェクトメンバーに通知し同意をとってから行っていました。
ただし、構成の見直しにばかり工数を使っているとそれは本末転倒なので、見直し範囲が多そうな場合は優先度をつけて修正する必要があります。
エンドユーザーの運用イメージの周知
作成中のモジュールがエンドユーザーの環境でどのように使用されているかを、PMを通じてプロジェクトメンバー全員に可能な範囲で共有してもらっていました。
効果
-
不具合の原因解明の時間が短縮された
不具合報告には開発環境では再現できないものがあり、例えば別チーム（私が所属していたチームの他にも、別のアドインを開発している他のチームが複数ありました）のモジュールが原因だったり、お客様の操作ミスによるものも含まれていました。このようなすぐに原因が解明できない場合の不具合報告でも、運用イメージを想像し俯瞰的な視点で調査を行えたことで、不具合の原因の予想を立てる難易度が大幅に下がりました。
-
開発者から仕様の改善案を提示することができた
運用イメージを把握していないと、PMから伝えられた仕様通りに開発するしかありません。しかし開発者も運用イメージを持つことで、より良い仕様を提案できることがあります。お客様も開発者もWin-Winとなるような仕様の改善案を提示することもできました。
-
開発者のモチベーションがアップした
3人のレンガ職人の話ではないですが、運用イメージが把握できると、自分がどのように業務に携わっているのか把握することができます。そのため、「言われた通りの機能を開発するだけ」という意識から、「〇〇の経緯から△△の理由でこの機能を開発している」という意識になることができます。運用イメージの共有により視界が開けたことで、モチベーション向上に繋がった開発者もいました。
問題点や気を付けること
-
どの作業の運用イメージを連携いただくか
運用フローが膨大な場合、すべてを開発者に伝えるのは工数的に困難です。そのため、開発に関わる部分で特に運用イメージが想像しにくい箇所を優先して共有することが重要です。
終わりに
プロジェクトを良い方向に導くには、プロジェクトの規模や開発手法によっても方法が変わってくると思いますが、何よりメンバーひとりひとりの意識がとても大切だと感じました。
その中で、厳しすぎない適度なルールの策定や、メンバーが改善案を発信しやすい環境を整えることが大事だと思っています。