この記事は Akerun Advent Calendar 2024 - Qiita の4日目の記事です。
はじめまして。SW開発部の @yooda です。Photosynthに入社して2年半ほどになります。 Miwa Akerun Technologiesが運営する賃貸住宅管理システムの開発チームでエンジニアリングマネージャをやっています。
はじめに
ソフトウェア開発プロジェクトにおいて、Q（品質）、C（コスト）、D（納期）の３つの要素が重要と言われています。
ソフトウェア開発の生産性を考える際、バグが少ない高品質なソフトウェアを、人手をかけずに低コストで、より短時間で作成できる能力が指標となっていきます。１人月で、どれだけのソースコード量を作成できるか、という物的な生産性の指標として、開発工数の見積もりをする際にもよく使われる観点です。 前職では車載系の組み込み開発に従事しており、顧客の要件から開発規模を類推して、人月あたりの製造ステップ数を指標として、開発工数の見積もりを行っていました。
Photosynthに入社後、Webエンジニアをマネジメントする立場となり、生産性について考えていくと、以前は当たり前と思っていた物的生産性の考え方があまり馴染まず、別の視点で生産性と向き合う必要性を感じました。
「量」から「質」に視点を移して、2024年は付加価値の高いソフトウェア開発を進めていくことをチームの方針として、どうすれば価値ある開発ができるか、言い換えると付加価値生産性が高い開発が進められるかを考え、行動しました。
付加価値生産性を高めることを目的として1年の活動をした中で、今回は付加価値の高い開発にリソースを投入できるようにした取り組みについて書きたいと思います。
開発の進め方
賃貸住宅を管理するWebシステムを開発し、保守運用を行なっています。開発手法としてはスクラムを取り入れており、１スプリントを２週間で回しています。
保守のフェーズでは、このWebシステムに対しての追加機能や改善したい機能に関する要求をプロダクトマネージャが定義して、JIRAのチケットを発行して要求をプールしており、プールされた要求のチケットの中からスプリントで実現したいことを選択して、機能改善・機能拡張を行なっています。
どの要求から実行するかは、プロダクトマネージャが優先順位をつけて決めていましたが、プールされた要求チケットを都度見直ししており手間がかかっていました。また、その優先順位がどういった意味を持つのかが明確ではありませんでした。
そこで、プロダクトマネージャに各要求がビジネスにとってどのような意味・価値を持つのかを定義してもらい、重要度という指標でビジネス的な価値を数値化する取り組みを行いました。
重要度の定義
ビジネス的な価値を示す重要度を定義するにあたり、以下の観点を用いて５段階で数値化することとしました。
- 賃貸住宅の管理システムの利用者全体に対して、影響割合がどの程度あると想定されるか？
- 賃貸住宅の管理システムの利用者に対して、どの程度の良い効果をもたらすと想定されるか？
- 上記の想定がどの程度の確実性があるか？
例えば、新しい機能を追加したいという要求であった場合、その機能は利用者の全員に影響し、非常にメリットがあり大きく売上増加に貢献すると想定されて、その想定の確実性が高いと考えられると、重要度５になります。
また、機能改善の要求であった場合、その機能が利用者の全員に影響し、抱えていたデメリットが解消されることで運用コストが低減すると想定されて、その想定の確実性が高いと考えられると、重要度５になります。
逆に、限られた利用者にしか影響がなかったり、良い効果が低かったり、想定の確実性が低い要求の重要度が下がることになります。
要求チケットに重要度をつけた結果、重要度の割合は以下のようになりました。
| 重要度 | 割合 |
|---|---|
| 5 | 18% |
| 4 | 21% |
| 3 | 24% |
| 2 | 23% |
| 1 | 14% |
要求チケットを整理すると、重要度４、５までが実現できると、このシステムがかなり理想に近づくことがわかりました。もちろん、重要度１〜３も実現できれば、なお良いと言えますが、ビジネス的な価値という観点では重要度４、５が占める39％に注力することが大事であると感じました。
この重要度の高い要求から開発していくことで、ビジネス的な価値の高い機能開発・機能改善に開発リソースを投入し、運用する賃貸住宅の管理システムの価値を高めることに貢献できるプロセスを構築できたと考えます。
取り組みの結果
24年11月までの取り組み結果についてまとめます。 実現率は、各重要度の要求件数を分母として、その中で実現できた件数を分子として計算します。
| 重要度 | 実現率 |
|---|---|
| 5 | 95% |
| 4 | 30% |
| 3 | 10% |
| 2 | 5% |
| 1 | 25% |
重要度５の要求は100％の実現率を目指したかったものの、難易度や修正規模の大きい要求もあり、100％には至りませんでしたが、最重要な要求の大部分は実現でき、これまでの不満や不便をかなり解消できたと考えます。
重要度の高い要求に注力すると言いつつも、重要度の低い要求への対応も行いました。これは、パラメータを変更するだけで対応できるものなど、容易に短時間で対応できるものであれば先送りにする理由もないと考え、プロダクトマネージャと協議の上で実行した結果となります。
最後に
付加価値を語る上で、本来であれば金額ベースで価値を表現できるとよいのですが、簡易的な方法を用いて実現しようとする機能の価値を表現する方法を取り入れました。
この取り組みにより、プロダクトマネージャにとっても要求がビジネスにとってどの程度重要なものか（もしくはあまり重要でないのか）を考える機会にもなり、また、開発エンジニアにとっても、開発対象の要求のビジネス的な価値を理解できることで、仕事のモチベーションにつながっていると感じます。
今回は要求の付加価値を明確にする取り組みを行いましたが、さらなる取り組みとして、バリューストリームマップを作成して、製造・サービスの提供までのプロセスを明確にして、付加価値を生まないプロセスの低減・削除を検討していきたいと思います。
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 photosynth.co.jp
Akerunにご興味のある方はこちらから akerun.com
