アジャイル開発のテクニックを使って改善しつつ保守する

エンジニア TS
2021年08月09日

アジャイル開発マーク

もともと受託開発で開発したシステムを、月ごと時間固定での改善、保守形式に切り替えた事例をご紹介します。

Contents

事例の概要
その後起こったこと
- 「計測して改善」を繰り返した
- ユーザーの問題に集中する
大変なこと
- 毎月成果を出さないといけない
- 成果物に対してクレームが発生するリスク
これからの保守のやり方

事例の概要

そのシステムは上にも書いたとおりもともと受託開発で開発して、改修要望があるたびに改修仕様を作り、請負契約を結んで改修していたのですが、改修速度が遅いなどの問題が発生していました。

発生していた問題点

1時間程度で完了する小さな単位の作業でも、作業ごとに要望ヒアリング、仕様作成、見積作成、仕様/見積額承認しているのが、オーバーヘッドになっていた。
発注を受けてから社内リソースを確保していたため、発注を受けてから実装、納品までに時間がかかっていた。
受け入れテスト開始から時間がかかると作業者が他の案件にアサインされてしまい、受け入れテストで修正指示が発生するとさらに納品までに時間がかかってしまった。

これらの問題があり、発注元からは納品量が安定しないこと、発注から納品までに時間がかかることに不満を頂いてました。

弊社としてもこの問題をなんとか改善したいと思い、いくつか提案をしました。そのうちの一つが月ごとの作業工数を固定し、その中で改善作業や保守作業をまかなう形での保守契約の提案でした。

提案した固定時間での保守契約

この提案を大まかに説明すると、それまで案件ごとに見積もり提出/承認していたのをやめ、固定時間内で作業できるぶんだけ作業し、積み残しが発生するなら翌月にまわす、というやり方です。

月あたり固定額で保守を請け負う。
時間あたりの単価 x 時間数が月あたりの保守費に至るまで作業する。
時間数での契約なので、予めその時間でできそうな作業はお知らせするが、確実に完了するかは約束できない。その点を顧客に了承してもらう。
弊社と発注元が共同で作業予定リストを管理し、月の初めに今月どの作業をするかを決める。

時間を固定して作業することで、以下のようなメリットを見込みました。

メリット

検証しつつ開発できる

案件ごとに仕様を作成して合意を取る方式ですと、大規模な作業をするときに仕様が大きくなります。
そういう大きな仕様を一度に開発すると、実装が終わって機能を確認していただく時に、意図したように問題を解決できないことが判明することも多いです。
固定時間での作業形式にすると、大きな単位で仕様を作るメリットが無くなります。代わりに検証可能で小さい単位で開発するほうが、手戻りを少なくする観点から有効になります。

定期的に予算を消化できる。

これは発注元特有の都合なのですが、年ごとにシステム改修予算が割り当てられる都合上、月ごとに決まった工数を消化する契約形態は先方にとってメリットになりました。

見積もり作成のオーバーヘッドを減らせる

案件ごとに見積額を提出するやりかただと、そのたびに弊社の足が出ないように慎重に見積もりし、バッファも設定する必要がありました。
固定時間方式ですと作業ごとに見積額は提出する必要がありません。
工数は見積もりますが、それはどの程度時間がかかり、見通しを立てるためのものなのでバッファを乗せる必要などはなく、見積もり時間を削減できます。

上記のようにいろいろとメリットはありますが、受託開発に比べると先方にとっては決まった予算で作業が完了する保証がなくなるという大きなデメリットがあります。
この点は先方にとっても大きな不安点ですので、どのように開発が進むのか、問題があれば元のやり方に戻してもらえることを丁寧に説明し、試しに固定時間での保守形態で試していただくことになりました。
それまでの作業を通して、弊社の納品物を評価していただけていたことも、この提案を受け入れていただけた一因だと思います。

その後起こったこと

その後起こったことはどうだったかというと、結果として発注元はこのやり方を大変気に入って、今でも固定時間の保守契約を続けていただけてます。
弊社としてもメリットが多くありました。定期的に作業が発生するのでリソースの確保が用意になり、オーバーヘッドを減らせて納品できる成果が増えて先方の満足度も上がり、工数がオーバーして赤字が出ないか心配する必要がなくなりました。
想定していたメリットは享受することができて、最も心配していた成果物が納品されないという自体は発生しませんでした。

これと同じ形で発注元と契約すれば、だれでも、どの会社でもうまくいくのかはわかりません。

でも開発がうまく進むように気をつけたことはいくつかあります。

「計測して改善」を繰り返した

固定時間で作業するようになったので、大きな機能を最初に設計する必要はなくなり、今困っている問題を改善することに集中するようになりました。問題を分析し、小規模で検証可能な改善を設計し、実装して問題が改善されたか検証し、次の改善を設計する。この改善サイクルを繰り返し、ユーザーに価値を提供し続けることを重視しました。

ユーザーの問題に集中する

システム開発のゴールはユーザーの問題を解決すること、ユーザーに価値を提供することです。
ですが受託開発をするときには問題よりも機能に興味が向いてしまいます。受託開発で開発をするとき、開発会社が履行すべき義務という観点では、発注者との約束は仕様に書かれた機能を納品することであり、先方の問題を解決することではないからです。
このしがらみから開放されたので、機能ではなくユーザーの問題を理解することに、それまでより多くのエネルギーを使うようにしました。先方の業務を理解すること、先方が困っていることを聞くこと、安直な解決策に飛びつかず問題の本質を理解しようとすること。そうすることで、開発したものの役に立たないと言われる機能を減らし、ユーザーが抱えている問題の解決に集中することができました。

大変なこと

開発のやり方を変えたことで良いことも多かったですが、大変だと感じることもありました。

毎月成果を出さないといけない

月ごとに成果を出さないといけないので、それまでと計画の立て方は変わりました。
先方に確認していただく機能のサイズは、1週間以内のサイズになるように計画してリリースするようになりました。
また、リリース後、どのように機能の効果を検証するかも先方と事前に相談して、リリース後の検証まで含めて小さなバッチサイズに収めるようになりました。

これに関して気をつけたのは、計画通りに作業が進んでないことも含めて、作業の状況を先方と共有するようにしたことです。それによって実装中に判明した問題による計画変更を相談し、計画を変更しても先方に定期的に価値を届けることができました。

決まった時間で成果を出し続けないといけないことはプレッシャーでしたが、これに適応することで、定期的に価値を生み出し続ける仕組みを作ることができました。

成果物に対してクレームが発生するリスク

仕様を合意して作ったものが、発注元がイメージしていたものと違うということもありました。
発注元からすると納品される機能数が保証されないため、意図の違う開発に時間が使われるのは困ると申し入れがありました。
この問題を軽減するために、仕様をより理解しやすくしたり、仕様の読み合わせを工夫して認識違いを少なくするようにやり方を改善しました。難しいところは、仕様を作ることに時間をかけすぎて工数がかかりすぎることは先方にとってもメリットにならないので、短い時間で効果的に設計、情報共有する必要があるということです。問題が発生するたびに先方と改善方法を相談して、やり方をアップデートしてきました。

これからの保守のやり方

固定時間制による継続的なシステム改善が可能であること、うまくやれれば発注元の満足度を上げて喜んでもらえることがわかったのは弊社にとっても大きな発見でした。
この記事で書いたこと以外にも、固定時間制の改善手法はスケールしやすい(スケールアップもスケールダウンもしやすい)などのメリットを感じてます。
個人的には契約で約束した機能に対してでなく、ユーザーが抱えている問題の解決に集中できるようになったことが、価値をユーザーに届けるために効果的だと感じてます。
アジャイル開発手法の利点を取り入れて、より良い価値提供ができる組織を目指していきたいです。