30年以上エンジニアをしてきましたが、「これは本当に終わるのだろうか」と計画表を見たまま手が止まったことは、一度や二度ではありません。
特に数千人が利用するシステムの更新では、ログイン、データ連携、バックアップ、権限設定、データ移行など、確認することが次々に出てきました。全体をまとめて考えようとするほど、最初の一歩が分からなくなります。
そのとき私が行ったのは、作業をできるだけ細かく並べることではなく、「何ができれば、この作業は終わったと言えるのか」を決めること。これを失敗したときの影響が大きい箇所から確認していきました。
この記事では、実際のシステム更新で仕事をどう分けたのか、完了条件をどう考えたのかを書いています。細かく分けすぎて、一覧表の管理自体が仕事になった失敗も振り返ります。
数千人規模の更新で手が止まった
数千人が利用するシステムの更新を担当したとき、最初は仕事全体の大きさに圧倒されました。
ログイン機能、外部システムとのデータ連携、バックアップ、権限設定、データ移行、更新後の動作確認。一つずつ書けば別の作業に見えますが、実際には互いに影響し合っています。確認する範囲を広げるほど、やるべきことが減るどころか、増えていくように見えました。
正直、計画表を見るのも嫌になっていました。
「システム更新を終わらせる」という大きな目標のまま考えていたため、どこまで進めても終わりに近づいている感覚がありません。何かに手を付けても、別の課題が気になり、また全体へ戻ってしまいます。
そこで、いったん全体の完成を考えるのをやめ、機能ごとに分けて見ることにしました。ただ、「ログインを確認する」「バックアップを確認する」と項目を並べただけでは、作業を始めたことと、終わったことの区別がつきません。
分けるだけでは足りない。何を確認できれば一区切りなのかまで決める必要がありました。
作業項目ではなく完了条件で分けた
最初は、確認することを細かく書き出せば進めやすくなると思っていましたが、項目を増やすほど一覧表の更新に時間を取られ、何のために分けたのか分からなくなってきます。
そこで、細かさを競うのではなく、「ここまでできれば終わり」と判断できる大きさに分け直しました。
ログインや連携を機能ごとに整理した
システム更新では、まず機能ごとに整理しました。
- 利用者がログインできる
- 必要なデータが外部システムへ連携される
- 障害時にバックアップから復旧できる
- 利用者ごとの権限が正しく反映される
バックアップは、「データを保存できること」と「保存したデータから戻せること」を分けて確認しました。
保存処理が動いていても、必要なときに復旧できなければ意味がありません。作業名だけを見ていると、「保存できたから完了」と判断してしまい、実際に戻せるかどうかの確認が後に残ります。
機能単位に分けることで、少なくとも何を確認しているのかは見えやすくなりました。ただ、それでも「ログイン確認中」「連携確認中」という状態では、どこまで終わっているのかが分かりません。
終わったと判断できる状態を決めた
そこで、機能ごとに完了条件を決めました。
たとえば、ログイン画面を修正しただけでは完了にしません。正しい情報で入れることに加え、間違った情報では拒否されること、一定回数失敗した場合にも想定した動きになることまで確認して、一区切りとしました。
以前の私は、画面を修正した、処理を一度動かしたというところで、仕事が進んだつもりになることがありましたが、後から確認不足に気づき、終わったと思っていた作業へ戻ることもあります。
完了条件を先に決めておくと、「作業した」と「確認まで終わった」を分けて考えられます。
一日が終わったときも、「いろいろ触ったが何も終わっていない」ではなく、「ログイン機能は完了した。データ連携はまだ確認中」と言えるようになりました。
小さく分けることも作業を分ける、という点では重要だと思いますが、終わったかどうかを判断できる形にすることの方が大切だったのだと思います。
失敗時の影響が大きい箇所から確認した
仕事を分けた後は、どこから始めるかも考え直しました。
簡単に終わる項目から片づければ、一覧表の完了は増えます。目に見えて進むため、気持ちも少し楽になります。ただ今回の更新では、簡単な作業よりも、問題が見つかったときに影響が大きい箇所を先に確認しました。
特に気になっていたのは、外部システムとのデータ連携と、障害時の復旧確認。
どちらも、自分たちの作業だけで解決できない可能性があり、後から問題が分かると関係者への確認や修正に使える時間が少なくなるからです。
準備ができた段階でデータ連携を試したところ、一部のデータ形式が合わず、想定していた通りに動きませんでした。
見つけたときは冷や汗が出ましたが、早い段階だったため、関係者へ確認し、修正方法を考える時間が残っていました。先に簡単な項目を終わらせていたら、一覧表の完了数は増えていたかもしれませんが、データ形式の不一致は後まで残り、使える時間は確実に減っていました。
それ以来、着手順を決めるときは、簡単かどうかだけでなく、問題が見つかった場合の影響と、確認や修正にどれくらい時間が必要かを見るようにしています。
機能ごとの完了状態で進捗を伝えた
完了条件を決めたことで、進捗の伝え方も変わりました。
それまでは、進み具合を聞かれても、「まだ確認中です」「いくつか問題があります」「全体としては進めています」といった曖昧な説明になりがちでした。自分でも、何が終わり、何が残っているのかをうまく説明できていません。
そこで、全体が何％進んでいるかではなく、機能ごとの状態を伝えるようにしました。
- ログイン機能は完了
- データ連携は修正中
- バックアップは試験待ち
- 権限設定は未確認
こうして並べると、現在地がかなり具体的になります。
「データ連携の修正には何が必要なのか」「バックアップ試験はいつ始められるのか」といった話もしやすくなりました。全体で何％という数字だけでは、どこに問題があるのかまでは分かりません。機能ごとの完了状態が見えれば、次に確認することも考えやすくなります。
小さな完了を作ること自体が目的だったわけではありません。完了条件を決めたことで、自分だけでなく周囲も、何が済み、何が止まっているのかを把握しやすくなったということです。
分解しすぎると管理が仕事になる
仕事は細かくすればするほど進めやすくなるわけではありません。
私も一時期、確認事項をできるだけ細かく一覧表へ書き出していました。というのも抜けを防げると思ったからです。
ところが、項目が増えるにつれて、表の状態を書き換えたり、関連する項目を探したり、重複を整理したりする時間が増えていき、気づけば、本来のシステム更新より、一覧表を維持することに時間を使っています。
これでは、仕事を進めるための分解が、新しい仕事を作っただけです。
そこからは、細かな操作を一つずつ別項目にするのではなく、同じ目的の確認を一つの完了条件へまとめるようにしました。
ログインであれば、入力欄を一つ確認するたびに別項目を作るのではなく、正常時と異常時の動作を確認できた状態を一つの区切りにします。終わったかどうかを判断でき、後から見ても内容が分かる程度の大きさなら、それ以上細かくしない方が管理しやすい場合があります。
一覧表を更新する時間ばかり増えてきたら、分け方が細かすぎないかを見直すようになりました。
分けるだけでは解決しない場合もある
完了条件のある単位へ分けても、それだけでは進まない仕事があります。
仕様がまだ決まっていない、外部の担当者から回答が来ない、確認に必要な環境が用意されていない。作業量そのものが、使える時間を大きく上回っている場合もあります。
こうした問題は、担当者が分け方を工夫してもなくなりません。
ただ、仕事を分けておけば、どこで止まっているのかは説明しやすくなります。「仕事が多すぎて終わらない」ではなく、「データ連携は外部担当者の回答待ち」「バックアップは試験環境がないため未確認」と、進められない理由を具体的にできます。
仕事を分けたからといって、作業量そのものが減るわけではありません。分解によって見えやすくなるのは、自分で進められる作業と、自分だけでは進められない問題の違いです。
そこを混同すると、「分けたのに終わらない」と再び抱え込むことになります。
まとめ
大きな仕事を進めるときは、項目を細かく増やすのではなく、次のように整理しています。
- 機能や目的ごとに分ける
- 何ができれば完了なのかを決める
- 失敗時の影響が大きい箇所から確認する
- 進捗は機能ごとの完了状態で見る
- 管理作業が増えたら、分けすぎていないか見直す
完了条件を決めると、作業を始めたことと、確認まで終わったことを分けられます。問題が見つかった場合も、どこで止まり、何が足りないのかを説明しやすくなりました。
数千人規模のシステム更新を一度に終わらせようとしていたときが、いちばん手が止まっていたと思います。必要だったのは作業項目を無数に増やすことではなく、一つずつ「ここまでできれば終わり」と判断できる形へ変えることでした。
コメント