見出し画像

情報量でも、同期量でもなく、密度を問う

 ウォーターフォールからアジャイルへと変遷したチームが、さらに「全員リモートワーク」の状況に移行した場合、どのような問題に直面するか。おそらく多くのチームで、意思疎通が上手くいかなくなる。物理的に場所を隔てるようになったのだから、当然の問題? 

 まあ、そうなのだけど、問題の芯を捉えなければ、解決策を誤りかねない。ウォーターフォール、アジャイル、リモートワーク、それぞれのスタイルでどのようにして情報の受け渡しをしているのかを考えよう。

ウォーターフォールの狙い

 そもそもウォーターフォールとは、あるタスクに特化したフェーズ(工程)を設けて、リソースの集中による効率化をはかる作戦と言える。フェーズ毎に必要な能力を宿したメンバーを配し、まとまったアウトプットを必要十分な期間で仕上げていく。アウトプットをフェーズ間で受け渡し、フェーズを繋げていくことで最終的な成果物を完成させる。各フェーズの活動の中心には次のフェーズで必要となるアウトプット、ドキュメントが据えられる。「生産能力を余さず使い切る」という観点では理に叶った作戦だ。

 だが、フェーズを遡るような変更が発生した場合の適応が非常にやりにくい。相応のコストを要することになるため、基本的にフェーズを下っていく方向性を維持する力学が働く。言うまでもなく、何を作るべきか正解が無い状況下では向いていない。

アジャイルの狙い

 そのアンチテーゼたるアジャイルとは、フェーズというそれぞれに意味のある切り方(要件定義フェーズ、設計フェーズ、開発フェーズなど)ではなくて、単なる時間の区切り(タイムボックス)を中心に置く。

 その時間の区切りの中に、フェーズでばらしていたタスク(要件定義、設計、開発など)を詰め合わせるスタイルを取る。こうして「フェーズを遡れない」という問題自体を発生させなくする。

 このスタイルはタイムボックスあたりでみると、アウトプット量が小さくなり、開発のために必要な情報量を抑えることができる。そのため、各スプリントの活動の中心にドキュメントを置くとかえって効率が悪くなる。短い期間(1〜2週間)の中で、情報を伝え合うための手段=ドキュメントの作成に従来どおり時間を割いていたら、それだけでスプリントが終わってしまう。

 だから、アジャイルでは最小限の記述(情報)を元に、会話で「開発のために必要な情報」を補完することになる。会話して確認できたことや決めたことは記録として何らか残していくことになるが、従来のドキュメントと呼ばれる記述形態までにはならない。

 会話中心のコミュニケーションで、進めていくためには情報同期(共有する、確かめる、決める)のタイミングを1回や2回ではなく、頻繁に行う必要が出てくる。ゆえに、このスタイルの場合、同じ場所同じ時間をともにすることがほぼ前提になると言える。

リモートワークでアジャイル

 このように整理すると、リモートワークでアジャイルを取った場合の問題が明白になってくるだろう。頻繁な同期が生命線のスタイルにおいて、同期のコストが高まる環境に移行するからである。

 結果、「開発のために必要な情報」が不足しがちになり、期待どおりではないアウトプットが生み出されたり、そもそもアウトプット自体が滞ったりする。これを、リモートワークでも「頻繁な同期」で乗り越えようとして、行き着くのは「オンラインでの常時接続」である。常に、Zoomなりを繋ぎ続けるといったスタイルは、人を選ぶことになるだろう。誰もが、そういう働き方を望むわけではない。

情報の密度を見直す

 もう一つの選択は、「情報の密度」を見直すことだ。情報量を出来る限り増やしてやりとりするのがウォーターフォール。情報量を小分けにして頻繁にやりとりするのがアジャイル。いずれの方向でも無いとしたら、やりとりに際して受け渡す「情報の密度」を高めることが考えられる。

 つまり、出来る限り少ない記述量で豊富な情報量を込める、イメージ。「長い文章をたくさん読ませて、いくつか理解が得られる」ではなく、いかに簡潔にして、それでいて意味のある情報を詰め込むか。具体的な方法は、表現方法として図やモデルの活用を高めることだ。

 モデルの活用は一昔前によく用いられた手だが、使いこなすためのスキルが相応求められるのと、アジャイルに移行する中でその出番が減っていったものだ。ただし、現代においては昔に比べてより多種多様なモデルの選択がありえる。キャンバスも、ジャーニーマップもモデルの範疇に入る。

 なお、モデルというと何か型から入らないといけないように思うかもしれないが、そうして大上段から構える必要もなく、言葉を図に置き換えて表現する、という手短さでまずは十分だ。こうした考えは実際、miroなどのリアルタイムホワイトボードツールの活用が広がっているように見えるのとも合致するように思う。

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
ありがとうございます。
29
白と黒の誘惑 https://ichitani.com/

こちらでもピックアップされています

DevLOVEのノート
DevLOVEのノート
  • 126本

開発現場と越境する人のためのコミュニティDevLOVEのNoteです。イベント告知、案内、関係者のnoteを投稿していきます。

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。