すばやく体験しフィードバックループを回す大切さを身をもって実感した

こんにちは。モバイルコア開発チームでエンジニアをしている日下部（み）です。

12/27の記事「ネットワークなにもわからないマンが何もわからないままラボ構築プロジェクトのリーダーになった話」で紹介されているラボ構築プロジェクトに私も参加しています。このプロジェクトについて、@voice726さんとは別の視点でふりかえり記事を書いてみます。

ラボ構築プロジェクトを通して、高速にフィードバックループを回すことの大切さを実感した体験記です。

ラボ構築ふりかえり会

voice726さんが書いているとおり、ラボの初回構築では目標としていた状態にたどりつけませんでした。構築後、メンバー内でふりかえり会を行いました。

このプロジェクトの目的は物理機器で実験できるラボ環境を作ることですが、教育的な目的もありました。つまり、ネットワーク初心者や物理作業の経験が少ないメンバーが構築を行うことで知識・経験を得るという目的です。

これについては、初期構築未完成ではありますが機器選定・調達・設計・構築と一通り経験したことによってメンバーそれぞれ構築というものに対する解像度が上がり、ふりかえり会では、次回作業に向けた具体的な改善策を話し合うことができました。このことから、一定の成果は得られていると感じています。

技術的・知識的な観点でのコメントとおなじくらい、プロジェクトの進め方についても反省点が挙がりました。このことから、構築経験を積むという目的よりひとつ抽象度を上げて、プロジェクトを推進するということも、体験として得られたことがわかりました。以下、構築の観点、プロジェクト推進の観点それぞれの反省点について考察しながら紹介します。

構築の観点

最初は最小限の構成（ルータ、スイッチ、サーバ各1台など）で構築し、動くことを確認してから拡張していけばよかった
- 小さい単位に区切って完成させ、意図通りに動くかどうか確認したり、利用者からの声を聞いたりというフィードバックを得ることを行えばよかったというコメントです。実際には「あれもこれもやってみたい」とルータを2台冗長化しOSPFでルーティングしたり、LAGを組んだりと、最小限ではない作り込みをしようとし、結果として成功せず、ラボとしての機能を社内に提供できないという状態になってしまいました。
検証機の相談など早めに機材に触れられないか働きかければよかった
- 早く機材に触れられればその分早く手を動かして検証することができました。実際にはスケジュールの見積の甘さもあり、機材が手元に届いてから構築まで時間がなく、充分に検証できないまま構築作業を行うことになってしまいました。
仮想環境で同様の構成を作って試せばよかった
- 物理機器がなくても構築より前に手を動かし検証する方法を取ることはできました。一部CML2を利用して検証できたこともありましたが、構築しようとしているものと同様の構成を試すことはしていませんでした。同様の構成で試すことをしていれば、構築の日に起きた問題にもう少し早く気付けていたはずです。
構築当日の作業手順に、段階ごとの検証項目を充実させておけばよかった
- 細かい段階に区切って意図通りの状態になっているかどうか確認するべきでした。ルータ・スイッチ・サーバ・RaspberryPiすべての機器にconfigを入れてパケットを流そうとしてみてからデバッグを始めたので、疑うべき箇所が多くなっていました。

プロジェクト推進の観点

チームビルディングの場を初期から作ればよかった
- 構築を終えてからふりかえり会を実施しましたが、プロジェクト開始からそのときまで約半年、互いの困りごとや良かったと感じていることを話し合う場を設けていませんでした。もっと早い段階でそのような場を設けていれば、チームとして強みを補強し合い弱みをカバーし合いながら進むことができたはずです。
メンバーそれぞれの得意分野を知って互いに相談できる状態にしてよけばよかった
- それぞれの得意分野を互いに知っていればその分野についてその人に相談したり、質問したりすることができました。チームとして補強し合う状態になるために必要なことでした。
わからないことが多いタスクを2, 3人で組んで早めに相談できる状態を作りたかった
- 1つのタスクは1人で担当することがほとんどで、わからないことにも担当者1人で手探りで調べながら取り組んでいました。複数人で担当していれば、相談し、知識やアイディアを提供し合い、コミュニケーションの中からより高速に解決策にたどりつくことができていたかもしれません。
構築の観点の反省点も見方を変えればプロジェクト推進の問題だった
- 最小構成から背伸び構成までのスコープ・ステップを整理すること、適切なリスク判断をすること、各ステップで早期に検証することは、構築に限らず他のプロジェクトにも適用できる反省でした。

得たこと

構築、プロジェクト運営、どちらの経験からも共通して得られたのは「短い期間・小さい単位で手を動かしてみてフィードバックを得ること、そのフィードバックを次の行動に活かすことが大事」という教訓でした。
こう書いてみると、あたりまえのことです。ですが、実際に自分たちが行動し経験したことで、このあたりまえのことが実感を伴って理解できるようになりました。失敗経験を通して実感することで、ラボ構築以外のプロジェクトでも、これまでよりもより自信を持って「すばやく体験しフィードバックループを回す」やりかたを推進できると感じています。