同セッションでは、株式会社えにしテックの島田浩二さんより、設計や技術選定のような影響範囲の大きい意思決定をどのように扱うべきか。また、「絶対的な正解がない状況」において、何を根拠にどのように判断すべきかを整理し、最も現実的な意思決定を導くための具体的な指針をご紹介いただきました。
島田：島田浩二です、インターネットではsnoozer05というIDで活動しています。
普段は札幌を拠点に、株式会社えにしテックの代表をしています。個人としては技術書籍の執筆や翻訳に携わっていて、3月6日に『ソフトウェアアーキテクチャの基礎 第2版』が刊行になります。第1版以降の変化やフィードバックを取り入れて、内容が大きくアップデートされています。
本日は、普段の開発でも影響範囲の大きい意思決定を担っている方々に向けて、その大変さを乗り越えていくために、私が大事だと考えていることをお伝えします。
ソフトウェア開発における意思決定の難しさ
まず、ソフトウェア開発の意思決定がなぜ難しいのかを、失敗例として2つ挙げます。ここでの例は架空ですが、似た経験をされた方は少なくないと考えています。
例1 マイクロサービス採用の失敗
マイクロサービスアーキテクチャは、機能ごとの開発スピードを上げやすいとか、スケーラビリティを実現しやすいといったメリットが語られます。そこで、新しいシステムをマイクロサービスで構築したとします。
ところが運用が始まると、求められる運用能力の高さや技術力に、組織の体制や運用が追いつかないことがあります。結果としてメリットを享受する前に疲弊して、システム自体が負債化してしまう。そんなケースです。
例2 全面リプレースの失敗
もう1つは全面リプレースです。技術的負債が溜まっているから事業推進の速度が落ちていると判断して、既存システムを捨てて作り直すことを決める。これはよくある話だと思います。
最初はまっさらな状態から作れるので、きれいに作れている感触があります。しかしリリースが近づくと、見えていなかった制約や運用ルールが次々に出てきます。その結果、リリース遅れや並行稼働期間の長期化、障害などが起きて、当初の狙いを果たせないリプレースになるような失敗です。
