こんにちは、サイオステクノロジーの佐藤陽です。
「SIOS社員が今年一年で学んだこと」のアドベントカレンダー 21 日目です。

私は元々サーバーサイド側のエンジニアでしたが、今年は自身初となる PM（プロジェクトマネージャー）として多く活動した 1 年でした。
この 1 年の経験から、プロジェクトマネジメントにおいて特に重要だと感じたポイントを備忘録も兼ねて紹介します。

1 はじめに
2 なぜ最後の 1 ヶ月が苦しくなったのか
- 2.1 ウォーキングスケルトンを早く作る
- 2.2 フェイルファストで早く失敗する
3 まとめ
- 3.1 参考リンク

はじめに

私はプロジェクトマネージャーとして、とある Web システム開発プロジェクトを担当しました。 Web システムの内容としてはよくあるもので、ここでは仮に「オンライン書店システム」を構築したとします。
概要としては、ユーザーが本を検索・購入できる機能を持ち、管理者が在庫管理や注文処理を行うシステムです。

システムの構成としてはフロントエンドがあり、バックエンドがあり、外部 DB があり、Azure 上にデプロイされるというものです。

はじめに要件定義を行い、設計・開発と順を追って進めていきました。開発の中でいくつか課題は出たものの、致命的な遅れは発生せず、なんとかバッファを使いながらも予定通り進めていきました。

しかし、プロジェクトの終盤、リリース直前のタイミングにおいて多くのバグが発生し、ラスト 1 ヶ月は非常に高い負荷での対応に追われる形となってしまいました。

このとき、メンバーには非常に負担をかけてしまい、とても反省したポイントです。
そこでこの経験を踏まえて、なぜプロジェクトが最後の 1 ヶ月で非常に高い負荷の状態になってしまったのか、そしてそれを防ぐためにはどうすればよいのかを考えました。

なぜ最後の 1 ヶ月が苦しくなったのか

直接的な要因は、リリース直前のタイミングにおいて多くのバグが発生したことです。

ただし、アプリケーション開発を行うにあたってバグが発生すること自体は、ある程度は避けられないものだとも思います。
そのため、このときに本当に問題となったのは、「リリース直前のタイミングで、大量の」 バグが見つかってしまった点だと考えました。

なお、バグの主な原因としては以下のようなものがありました。

仕様の解釈ズレ
フロントとバックエンドのインターフェース不整合
クラウド(Azure)環境特有の制約

そして、これらのバグがリリース直前まで潜んでしまっていた要因として、次のような点が挙げられます。

フロントとバックエンドを結合した構築が遅れていた
クラウド上にアップロードしての動作確認が遅れていた
1 と 2 のような環境が、気軽に触れられる状態になっていなかった

それぞれの実装時に、各機能の単体での動作確認などは行っていましたし、コードの品質も一定のレベルでは担保できていたと感じています。

ただし、いざクラウドにデプロイしてみると想定外のエラーが発生しましたし、フロントとバックエンドとの連携がうまく取れておらず、リクエストやレスポンスに不整合が多く発生しました。

また、実際のアプリケーションを気軽に触れられる環境がなく、 UI を操作しての総合的な動作確認というものが十分に行えていなかった点も大きかったと感じています。

これを踏まえると、今回の記事で伝えたいことは次の 3 点です。

早めにフロントとバックエンドを結合しておきましょう
早めにクラウド環境へデプロイしましょう
誰もが最新の環境を気軽に触れるようにしておきましょう

ただ、こういったことは既に色々なところで提唱されているはずだ、と思い少し勉強してみました。
そうすると以下のようなキーワードが引っかかりました。

ウォーキングスケルトン
フェイルファスト

せっかくなので、これらの考え方について学んだ内容を少し体系的にまとめていきたいと思います。

ウォーキングスケルトンを早く作る

1997 年に Alistair Cockburn によって名づけられたもので、「小さなエンドツーエンド機能を持つ、ごく小さな実装」として定義されています。

本番さながらの構成すべてを作り込む必要はなく、主要なアーキテクチャ要素（フロント、バックエンド、データベース）などが必要最低限に繋がった状態を指します。スケルトン（骸骨）でありながら、ウォーキング（歩く）ことができる、というイメージと直結しますね。

例えば、上記の「オンライン書店システム」の例でいうと、

フロントエンド：検索画面のみ
バックエンド：書籍一覧取得 API のみ
データベース：書籍情報テーブルのみ

といった主要な要素がひとまずすべて繋がり、「検索画面から書籍一覧を取得して表示できる機能だけが動作する」状態がウォーキングスケルトンにあたります。
機能としては最終想定のものから大きく欠如していますが、主要な要素がすべて繋がって動作している点が重要です。

ここで気になるのは「MVP（Minimum Viable Product）」との違いです。

MVP はユーザーに提供することを前提とした「最小限の製品」です。つまり、「最小限」といいつつ、ユーザーが目的を達成できるレベルの機能を持ちます。
ここで求められているのは、ユーザーの要望を実現できているか、です。

一方、ウォーキングスケルトンはあくまで内部向けの成果物であり、求められているのは「ちゃんと端から端まで動くか」を確認することです。

ウォーキングスケルトンが作られるのは、プロジェクトのかなり早い段階であるべきと考えられています。 Cockburn 氏の書籍では、以下のように述べられています。

大規模なプロジェクトが進行中でした。それは、リングを介してシステム間でメッセージをやり取りするというものでした。もう一人のテクニカルリーダーと私は、最初の1週間以内にシステム同士を接続し、リングを介して単一のヌルメッセージをやり取りできるようにしようと考えました。こうすることで、少なくともリングは動作するようになりました。そして、毎週末には、その週にどんな新しいメッセージやメッセージ処理が開発されても、リングが完全な状態を維持し、前週のメッセージをすべて確実に通過させることを義務付けました。こうすることで、システムを制御された方法で拡張し、各チームの同期を維持することができました。

要するに、最初の 1 週間で「動く全体像（骨組み）」を作り、その後も常にリング全体が壊れていないことを保証し続けることで、複数チームが安心して機能追加できる状態を保っていた、という話です。

一度骨組みができたら、そこに少しずつ『肉付け』をしていきます。具体的には、新しい API や画面を追加していく、既存の機能を拡張していく、といった形になります。
この時重要なのが、「ウォーキングスケルトン全体が常に動作する状態を保つ」ことです。
新しい要素を追加したり、既存の要素を拡張したりするたびに、全体がちゃんと動くかを確認しながら進めていきます。

また、こういったウォーキングスケルトンが存在すると、早めに様々なメンバーに触ってもらうことができ、様々なバグ報告やフィードバックが早期に得られます。

まさにこれがウォーキングスケルトンを用意する最大のメリットで、「いつでも触れる環境が早期から整備されている」ことで「後からまとめて問題が噴き出す」のをある程度防げることです。

また、ここで重要になるのが、「早めに CI/CD 環境を構築しておくこと」だと感じました。

例えば、次のような仕組みをプロジェクト序盤から用意できていると、ウォーキングスケルトンを常に動く状態で保ちやすくなります。