はじめに

こんにちは。@akr-takaです。
今回はアジャイルで開発を行い、不具合を多く残したまま
運用フェーズに入ってしまった地雷システムを引き継いだ中、
なんとか運用をできるまで立て直した時の話をしていきます。
別の案件を引き継いだはいいけど炎上しかねない案件をなんとかしたいと思っている人に
見てもらえたらと思います。

対象読者

アジャイルってウォーターフォールよりも仕様変更に強い開発手法だと思っている人
よくわかんないけどアジャイルで開発してたらいいんじゃないと思っている人
案件を引き継いだはいいけど問題がある案件をどうしようか悩んでいる人

簡単な自己紹介

Web系をメインにJavaやPHPや色々な言語でシステム開発をバック・フロント共に
携わっていました。
この数年はアプリ開発を行ったり、アジャイルでの開発をやっていたりしていましたが、
紆余曲折あって今となってはPMでもSEでもPGでも時と場合に合わせて与えられたポジションで
求められる動きをする様になっていました。
家には妻子（7歳と2歳の子供が2人）とポメラニアンがいます。

そもそも

アジャイル案件が失敗したと書いていますがアジャイルが悪い、ウォーターフォールがいい。
というつもりは全くありません。
アジャイルのやり方をしっかりと理解し、スプリントを回したらアジャイルが
仕様変更に強いのは確かです。
そこだけは誤解しかねないのでしっかりとご理解いただきたいです。

やったこと

現状分析
なんでこうなったか？を考えてみる
何をすべきか計画立案
改善策考案
実施

現状分析

営業から事前に聞いたことと実際に自分でシステムを触って判明した現状分析結果は以下でした。

案件開始時に営業から聞いていたこと

不具合が多い
デザインがいけていない
ドキュメントがほとんどない
前任の開発会社に作業依頼はできるのでドキュメント作らせることもできるかも

蓋を開けてみた結果

不具合が多い
- 正解。不具合がぽんぽん出てくる
デザインがいけていない
- 正解。使い勝手を意識していない
ドキュメントがほとんどない
- ある意味正解。設計書はあるけど、嘘だったりちゃんとした仕様が書かれていない
前任の開発会社に作業依頼はできるのでドキュメント作らせることもできるかも
- 微妙。自分たちで作る方がいい

なんでこうなったか？を考えてみる

なんで今回ドキュメントがないのかを考えたらよく陥る
「アジャイル開発なんだからドキュメントを作らない」
という都合の良い解釈をしたからだと把握しました。

アジャイル開発は要件（Scope）が変わるので
「仕様変更の度にドキュメント変更していたら時間がかかる。
コードをちゃんと書いていたら仕様がわかるので
ドキュメントは最低限でいい。」
という考えでドキュメントを作らないという話も聞きますが
ドキュメントを作らなかった時の失敗点は以下が多いです。

コードを書く人が認識間違えてても気づけない

仕様変更が発生していたことを忘れている
提供すべき仕様が時間経過と共に記憶から失われる
動作確認した時、正しく動作しているかの根拠がない

人の入れ替えが発生した時に新しく入った人には正解がわからない

ある特定ケース（夜間バッチや管理者権限で操作した時など）でしか発生しない仕様は忘れられがち
仕様を精査した中で理由があって除外した理由を新しい人がわからないなど

お客様やステークホルダー、営業の人に説明する時の情報がない
仕様の履歴がわからない

今回はステークホルダーも知らない仕様があったことからドキュメントを作らなかったことで
開発チームと認識合わせが出来ていないことは推測出来ました。

何をすべきか計画立案

ドキュメントがないことで不具合が多いことに直結している事はすぐわかりました。
しかし、ドキュメントを全て作るのは明らかに時間がない上にそれにお金と時間を
かけられない状況ということもあり、システムとして不具合が発生すると
運用が成り立たない箇所に注目してドキュメント作成をすることから始めました。

ドキュメントを作る目的

ドキュメント作成しないといけないからと言って単純に詳細設計書、API設計書、DB設計書を
作る気はありませんでした。
ドキュメントとは要件からシステムに起こすのに必要な情報の集合体なので
よくある詳細設計書の形式とかにこだわるタイプではありません。

正直gitのIssueでもいいですし、メモ帳に箇条書きでもホワイトボードで話した内容の写メでも
なんでもいいのであとで見返せてエンジニアの人以外（営業やお客様など）に説明することが
できればいいと思っています。

設計が必要、ドキュメントが必要だからしっかりとした詳細設計書を作らないといけないのは
間違っていないんですがある意味思考停止とも思っていて状況に適していないとも思っています。

そういう意味でPJ標準の詳細設計書フォーマットがあったので使いましたが
PJメンバーに言っていたことは

書き方や内容についてはこだわりはない

すでに存在しているコードを決められた形式で書こうと思うと書きにくくなるので柔軟に対応する

コードの内容を文章化できないのなら該当のファイル名・行数を書いておくだけでもいい

文章化できない時点でコードの質がよくないことはお察しなので皆で解析していく

バグを修正するためのきっかけにできればいい。

完全な仕様書を最初から作ろうとしてもシステムを完全に把握していない後付け設計でそこまで求めていない
システムに習熟したらその時はもっと書くべきものを精査すればいい
設計書だからここまで書くべきという思い込みは不要

仕様が正しいか正解がないのでおかしい挙動・コードは推測しない

自分たちで決めつけてしまうのではなく上位の会社に確認・進言していく

結論システムを触った結果とコードを査読した結果をアウトプットして、チームで共有できればいい

お客様と話す時の方針

前任の開発会社の仕事のやり方や引継ぎに至った経緯から話をするのに
慎重にいかないといけないのはわかっていました。
そのため、以下を意識してお客様とやりとりをすることで関係性の構築も
うまく行くことができました。

相手の要望に対してそのまま否定しない。
- 工数が足りない、大幅な変更になるなど理由があってできない時は代替案は出す
工数見積もりの根拠を提示する
口頭で説明するのではなく、資料を作成し共通の仕様を見れる様にする
ただ仕様を確認するだけでなく、意図や想定などの仕様の背景まで確認する
不思議な挙動しているところは逆にこちらが修正しやすい方針を提示してやりやすいよう誘導する
同件調査、影響調査の必要性を説明し、動作確認を時間かけることの大事さ
レスポンスは早く対応する。不具合に対する問合せについて事象調査には大体の工数も合わせて回答する
- 緊急で不具合対応をしてほしいとなった時に優先度低い他の作業とトレードオフを持ちかける
- 言えばなんでも対応してくれる便利屋にならない

最後に

アジャイルであろうとウォーターフォールであろうとやる事はあまり変わらないと思います。
必要な作業の見積もりと工数計算、お客様含むプロジェクト関係者間のコミュニケーションを
しっかりととることにつきます。
形だけのアジャイルで問題を解決できると思い込むことが一番の問題になりますので
プロジェクト管理に関わる立場の人間としてはやり方ではなく何をすべきか、お客様と
プロジェクトメンバーにとっていいやり方はどうかを考えて行動していくのを心掛けていくのが大事です。

参考記事