ご無沙汰しております。エコモットの板橋です。
ブログを書くのは５年ぶり（前回はコードのコメントについて記載しました）になりますね。
わたしは相も変わらず、プロジェクトリーダーとして開発プロジェクトが無事に終わるようにガイド役に徹している日々を過ごしております。
今回は、開発プロジェクトにおけるゴールの設定と罠について少しお話したいと思います。
1.ゴールの設定について
システムの開発プロジェクトは、お客様からのシステム導入に関する相談や自社での新サービスの立ち上げなど色んなきっかけにより立ち上がります。
その際、お客様の中では実現したい目標が設定されるはずです。
- 老朽化したシステムを更新して、スマートフォンやタブレットで屋外でも利用できるようにしたい
- 会社組織の改編に伴って、業務フローが大幅に変更されるのでそれに対応したい
- 新サービスを立ち上げて、3年後に黒字化、5年後には利益を〇〇〇出せるようにしたい
いわゆるビジネス視点でのゴールというやつですね。
一方、エンジニアサイドでのゴールの設定はどの様になるでしょうか？
- 半年後、機能限定版での初期リリース
- 1年後、フルスペック版での機能リリース
このようなマイルストーンが設定され、それが開発チーム内へ共有されゴールとして認識されるのではないでしょうか。
今回の話は、ここに罠が潜んでいるという話なんです。
もう少し詳しく見ていきましょう。
2.システムのライフサイクルについて
私たちは、お客様の要望するシステムを構築してリリースするのが主な役割ではありますがそれだけで終わるわけではありません。
特別な事情がある場合を除き、リリース後もシステムの保守運用を担います。
運用管理として、主に以下の様な作業があります。
- 技術的トラブルのヘルプデスク業務
- 不具合が起きた時の調査・修正対応
- セキュリティパッチの適用（サーバーOS、ミドルウェア等のバージョンアップ）
細かい話ではもっとあるのですが、主に、お客様がシステムを円滑に利用できるようにサポートしていきます。
これらの業務は運用終了されるまでずっと継続的に発生します。
…ん？
リリースして終わりじゃないの？
なんて思った方もいらっしゃるのではないでしょうか？（苦笑）
一部（保守運用専門のチームが別にいる場合など）を除いては、基本的に開発を担当したチームで保守運用を担います。
時間軸で表すと以下のようになります。
開発スタート リリース／保守運用開始
▼ ▼
┣━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━・・・（5年？10年？）
ここで重要なのは、リリースから運用終了するまでの保守運用期間の長さです。
システムというのは、大きなコストをかけて作られるものなので、大部分は5年から10年、長い場合は20年以上使っている場合もあります。
その期間ずっと保守運用を行っていくのです。
そう考えると、システムのライフサイクルは大げさに言うと「開発は一瞬、保守運用がほとんど」と言えます。
3.「リリースおめでとう」は、戦いの始まりに過ぎない
開発を担当したエンジニアから見ると、確かに「リリースする」という目標は、システム開発という作業のゴールであることは確かです。
しかし、上記で記載した通り、お客様はそのシステムを今後何年間もビジネスで使用していきます。
技術的なトラブルや、開発時に潰すことのできなかった不具合の多くは、運用（稼働）後のこの段階で見つかります。
また特に意識すべき点として、お客様からの信用を失う出来事もこの段階に多く起こるという事です。
- 機能が正しく動かない
- 動きが遅い（待ち時間が多い）
- 不具合が多い
この段階で起きる出来事は、意図しない突発的なものです（万全を期してリリースしているので当たり前ですよね）。
これらの対処に失敗してしまうと、結果的にお客様の信用を失ってしまう重大な結果を招いてしまいます。
この段階での対処には
- 原因の説明と対処の提案
- 対処に時間が掛かりそうな場合の回避方法の説明
- 提案した対処でトラブルが解消される事の説明
など、お客様に対してしっかりと説明して対応の内容に合意する必要があります。
なかなか、精神を削る作業ですね。
なお、重要な点を補足すると、システムがリリースされた後のエンジニアたちは、他の開発プロジェクトに順次投入されていき、新たなプロジェクトで活動を始めます。
つまり、リリース後のトラブル対応は、新たに投入されたプロジェクトの作業と並行して行う必要が出てきますし、緊急度の高い不具合が出てしまった際は全ての作業を中断して対策を講じる必要が出てくるのです。
プロジェクトの作業はどんどん遅延していきますし、出てしまったトラブルの対応も早急にかつ正確にしなくてはいけない。
想像するだけで、いろんなプレッシャーに押しつぶされてしまいそうになりますね。
このような状況は、お客様・エンジニアの双方にとって幸せな状況では無いので、品質をしっかりと確保しましょうというのは、こういった事を開発工程の段階で未然に防ぎましょうという事なのです。（今回の本題ではないのでいつか…）
品質の話と並行して、あらかじめシステム開発時に保守運用フェーズでのトラブルをどれだけ想定して事前に機能や仕組みとして設計に盛り込むか、、、という事が重要になるのです。
4.本当は保守運用をゴールに設定する方が良い？
結果から言うと、私はそう考えています。
保守運用をゴールに設定するという事自体が少し分かりにくいので、具体的な例をあげておきます。
私の場合は以下の様な”状況が実現できる状態”をゴールと設定します。
- 手離れを良くし、平時には放置できる状態としたい
- 問合せには最短で回答したい
- 調査時のログ解析は最短で終えたい
- 修正箇所の特定を正確かつ最短で終えたい
- たとえ一部であっても新人が迷わず作業できる状況を想定する
上記は私が良く考える理想的な状況の一部です。（基本的に楽したい…笑）
つまり、「トラブル対応は最短で実施でき、平時は可能な限り放置したい」という事です。
この状況を達成できた時に、開発プロジェクトとしてのゴールを迎えることができると考えているのです。
5.リリースにゴールを設定するのは誤りなのか？
そうだと断定はしませんが、認識を改める方が幸せになれる可能性が高まるのではないでしょうか。
確かに、エンジニアが魂と精神を削って作り上げたシステムが日の目を見る瞬間ですから、そこをゴールとしたくなるのも十分理解できます。
ですが、システムのライフサイクルの所でも述べましたが、お客様にとってはリリース時が運用スタートです。
お客様とエンジニアの双方が、リリース時が本当のスタートであるという事を認識して足並みを揃えて進んでいくのはとても重要なことだと思います。
本当の意味でのトラブル（お客様が業務での利用に問題意識を持つ）が発生するのもこの段階からです。
そういう意味では、リリースは「マイルストーンのひとつ」であると認識したほうがよさそうです。
もし、リリースをゴールとして設定した場合、事前の想定も甘くなることから、トラブル発生時に以下の様な状況に陥りやすくなってしまいます。
- 意図しない状況に現場が混乱する
- トラブルに対する仕組みの構築が不足し、お客様に調査・報告するための時間が掛かる
- 場当たり的な対応により、2次災害（別な場所でさらに深刻な不具合）が発生する
- 短期間に問合せや不具合が多く発生しており、対応にエンジニアが忙殺される
他にもあげるときりがないのですが、対応は後手に回り、状況が好転する事の無い消耗戦に突入してしまいます。
もし、開発工程上流の時点で、理想とする保守運用の状態を実現するための計画や設計を入れ込んでおけば、もう少し状況をコントロール出来ると思いませんか？
最後：まとめ
開発プロジェクトには、期間や予算、構成メンバー等の制約があるので、何をどこまで追及してゴールと設定するのかは、各プロジェクトにより異なってきますが、理想とする未来の状況から逆算して必要な要素を現時点のプロジェクトに適用するような事が必要となります。
この時点からルール化することによって、トラブル発生の対応もある程度手順化出来ますし、自然とそういう体制の準備が出来るものだと考えています。
理想の未来から現在の方向へ逆算し、プロジェクトの制約に応じたカスタマイズを加え適用する
そういった事を可能にするため、まずはプロジェクトのゴールを保守運用フェーズの理想的な状態に設定するのが良いと思っています。
この時に大事なことは、何の制約もない状態での理想を考えるという事です。
この時点で制約事項を考えてしまうと、実現したいことを見失いかねません。
それだと本末転倒ですし、何を使うかとか、どのように実装するかなど、本質ではない部分に気が向いてしまい手段が目的になってしまいます。
ここでは、保守運用フェーズでどのような状況を迎えたいか、どのような状況でいたいか、、、その一点のみに集中します。
という事で、今回も相変わらず文章多めのブログになってしまいました（善処します）が、お客様に対してどのようなシステムを提供するかを考えるのと同時に、私たちがどういう状況で保守運用していきたいかについて考え、それを仕組みとして用意する事も大切ですよ、、、
という話でした。
私たちと一緒にモノづくりをしていく仲間を募集しています。
弊社に少しでも興味のある方は、ぜひ下記の採用ページをご覧ください。
