リモートワークをスイッチに使う

Webディレクター解体アドベントカレンダー19日目の記事です。昨日までで最初に立てた目次の内容については一通り書いたので、今日からはWebディレクターの仕事に関係していたり関係していなかったりする雑談で25日まで埋めていきます。今日はすっかりお馴染みになったリモートワークについてです。

私は去年の8月に福岡に引っ越してきて、リモートで仕事をしています。元々は3年くらい前、新しい働き方に挑戦したいと思って週に1日家から働くという試みを始めたのがきっかけでした。

ディレクターというのは仕事の内容が多岐に渡るし、担当しているサービスがあるとその対応で手一杯になってしまい、なかなか新しいことを考えたり挑戦したりしづらくなってしまうという課題を感じていました。サービスの方向性を決めるべき立場の人間がそれじゃだめだと思い、何か良い方法がないかと思って取り入れたのが週1回のリモートワークです。

会社に出勤している時は普段の定常業務を中心にやり、週1日のリモートワークの日は家やコワーキングスペースなどに通って新しいことを考える時間にあてる。そうしてメリハリをつけようとしたわけです。この試みを半年くらいやってみて、目論見通りそこから新しい事業のアイデアが生まれ、その後実際のリリースにまで漕ぎ着けることができました。環境を変えることで気持ちも切り替わり、良いスイッチを手に入れたと思いました。

それから家庭の事情もあって福岡に引っ越すことになり、本格的なリモートワークが始まりました。何も工夫しなければずっと家の中で過ごすことになるので、ここでも環境を変えることで思考もスイッチするという手法を取り入れることにしました。去年の段階ではまだコロナも流行っていなかったので、毎月出張の予定を入れ、切り替えのスイッチにしたのです。

当時開発チームは京都で働いている人が多くて、クライアントは東京にいました。そこで毎月1回京都に出張して開発チームとのコミュニケーションの機会にあて、もう1回は東京に出張してクライアントと一緒に会議をしたりブレストしたりユーザーインタビューをしたりというインプットの機会にあてました。これがすごく良くて、隔週で新しい刺激をもらって福岡に帰ってきて、1人家に籠っていろんなことを考え、また2週後に次の刺激をもらいに行くという循環が回るようになったのです。これは良い仕組みだ、良いスイッチを手に入れたと思いました。

だけど皆さんご存知の通り、今年の新型コロナウィルス感染症の流行によって、出張自体がなくなってしまいました。切り替えのスイッチを失って今に至ります。この流行が落ち着いたら、また以前のようにスイッチをパチパチ切り替えながら仕事をしていきたい。そう思うものの、なかなか出口は見えません。

仕方がないので、もっと潜って内省の時期だと割り切ることにしました。もう少し長いスパンで考えて、今しばらくは自分を見つめる時期なんだと。こうして毎日記事を書いたり、長々と自分語りを続けているのもそうした活動の一貫です。

世の中の流れに合わせながらも、それをうまく自分のモードを切り替えるスイッチに使う。そんな柔軟さを大事にしていきたいと思います。

f:id:nmy:20201202142730j:plain

一人称マネジメント

Webディレクター解体アドベントカレンダー18日目の記事です。25日間あるアドベントカレンダーの内、元々用意していた目次は今日まで。初日に書いたWebディレクターのスキルツリーの各ブロックごとにそれぞれ1つずつかいつまんで、ここまで17日間書いてきました。今日は最後のブロック、マネジメントについてです。

マネジメント。この遠大なテーマについて何か語るのもおこがましいのですが、普段自分がチームをマネジメントする時、特に評価や目標設定をする時に1つ気をつけていることがあります。

それは、一人称で伝えるということです。開発チームのメンバーや自分の部下に対して何かを伝える時に、なるべく一人称で伝えることを心がけています。

例えば仕事をお願いする時や、評価をする時、目標設定する時に相手と一対一で話す機会があると思います。日常の仕事の中でも、特にそういう時です。

私は貴方のここを評価していますとか、私は貴方にこれをやって欲しいと思っていますとか、私は貴方にこういうことを期待していますとか。自分を主語にして、一人称で話すわけです。

周囲がこう評価しているとか、他のメンバーと比べて相対的にどうだったとか、まあ評価ってバランス取らないといけないから基準が他者に左右されることもあります。組織全体のバランスで相手がそんなに得意じゃない仕事や好きじゃない仕事を依頼しないといけない時もあります。自分の意思よりも、組織の要請が大きいことなんてよくあります。それは仕方がないことです。会社から期待されていることもあるし、それを伝えないといけないこともある。中間管理職ですからね。

それでも、たった一つでも私が貴方をどう思っているか。それをきちんと伝えることが、私はマネジメントにおいて何より大事なんじゃないかと思うのです。所詮中間管理職だし会社の歯車の1つに過ぎないわけですが、一応心があるわけです。その心を伝えないんだったら、何のために間に挟まってるのでしょうか。右から左に受け流す伝言係に、何の意味があるのでしょうか。

間に挟まるものの叙事として、せめてものささやかな抵抗として、自らの意思を持ちたい。自分の裁量を発揮して、自分の意思で自分の言葉で人と接したい。そう思っています。

f:id:nmy:20201217225920p:plain

ユーザー体験の設計をどこまでやるべきか

Webディレクター解体アドベントカレンダー17日目の記事です。今日はユーザー体験の設計についてです。ディレクターがどこまで設計に関与するべきか、結構議論の別れるところだと思います。曰く、ユーザー体験の設計はデザイナーに任せてディレクターは口を挟むべきでないとか、ユーザー体験はプロダクトの根幹なのだからプロダクトの責任者は当然そこに責任を持つべきだとか。もちろんプロジェクトや開発メンバーによって違うから一概に何が正解とか無いでしょう。

個人的には、弊害が無ければどんどん踏み込んだらいいと思っています。弊害というのは、最初にディレクターの作ったワイヤーフレームに引っ張られ過ぎちゃって全然良く無いものができてしまうとかそういうやつです。この立場の人はこれに口を出すべきでは無いなんて、それこそ心理的安全性を脅かす言動ですし、画面の設計にもどんどん踏み込んだらいいんです。

でも必須のスキルでは無い。たまにワイヤーフレームの美しさを誇るディレクター(自己紹介)がいますけど、美しさなんてどうでもいいんです。意図が伝われば何だっていい。大事なのは、調査や分析の結果からユーザーニーズを一番汲み取っているべき立場のプロダクトマネージャーが、汲み取ったニーズを言語でも視覚的にでもどういう形でもいいからきちんとチームメンバーに伝えていいものを作ってもらうことです。

その伝える時の手段として、ペーパープロトタイプだったりワイヤーフレームだったりがある。だからここでも、伝えるべき意図が先にあるべきです。その次に手段があります。前置きが長くなりましたが、今日はその手段の例を紹介します。

紙に描く

最も手軽で、個人的にも一番よくやる方法です。クロッキー帳が好きで、そこにスタッドラーのサインペンでガシガシ描くのが気持ちいい。最近は格好つけてiPadにペーパーライクフィルム貼って、アップルペンシルで描いてます。アプリはコンセプトっていうやつをよく使います。

f:id:nmy:20201215203316p:plain

とにかく自由。こういう感じにしたいんだよねっていうフィーリングに従って描いて、こういうのどうよって言いながら開発メンバーのところに持っていきます。まだ設計初期の段階で、固め過ぎない状態でみんなとああでもないこうでもないと会話する時に良いです。

スマートフォンと同じくらいのサイズに紙を切って、スマホの画面みたいに握りながら触ってみるのもいいですね。画面内でUIが動いていく時のイメージは、画面のパーツをハサミで切り抜いて重ねたりしながらフローを試してみるのも楽しいです。図工の時間みたいで、とにかく楽しいのが最高です。

画面遷移図

よく画面遷移図と呼ばれる、作る画面を全て洗い出してフローに沿って矢印で繋げた図を作ることもあります。入力された情報ごとに分岐していくような複雑な遷移を表す状態遷移図とも似ています。一方で作る画面の抜け漏れを防ぐために網羅性を重視した画面一覧というのもあります。

f:id:nmy:20201215203328p:plain

  • 状態遷移図
    • 入力された情報に応じて遷移を出し分ける時など、複数の状態を遷移と共に洗い出しておきたいときに作る。
  • 画面遷移図
    • ユーザーがどの画面からどの画面に遷移していくか、その体験の順番に画面を並べた図。作るものの全体感を把握するときに作る。
  • 画面一覧
    • 作るべき画面を網羅するために作る一覧。遷移よりは階層構造を表現することが多い。

画面遷移や画面一覧を作って欲しいと要請されることもありますが、その場合相手が求めているのはどれなのか、何を把握したいのかを確認してから作るといいと思います。

画面構成図

画面構成図はいらないとよく言われます。ワイヤーフレームとも呼ばれるやつです。デザインの専門家でも無いディレクターが作る画面構成に大した意味なんてないと。まあ言わんとすることはわかります。でも、ディテールから生まれる企画もあるんです。

以前にあるコンテンツのビューワの企画をしたことがあったんですが、その時は一番最初にワイヤーフレームから作り始めました。もっとSNSで拡散されやすいようなビューワを作りたいということで始めた企画だったんですが、拡散されやくするにはもっとパーマリンク感が欲しいと思ったんですね。だけど「パーマリンク感を出す」とかテキストで企画書に書いてあってもわけわかんないじゃないですか。どういうことやねんと。画面のイメージがあるか無いかで、企画が成立するかどうかまで左右されることもあるわけです。ああなるほどこれならアリだよねと、デザイナーに発注する前に企画すら立ち上がらなかったら終わりですからね。

そういう意味でも、企画時点で前提となるイメージする画面があるのなら、汚くても綺麗でも何でもいいからとにかく描いたらいいと思っています。

意図に応じて

意図があって、それを開発メンバーやステークホルダーに伝えたい。そういう時にやっぱり、ビジュアルがあったほうが話が早いです。

自分のイメージを伝えて、それぞれの立場からのフィードバックをもらって、それを反映してブラッシュアップしてまたぶつける。そういうキャッチボールを通じてユーザー体験を磨き上げていくなら簡単に素早く描けるものがいいでしょう。チーム全員で最初に眺めて作るものの認識を揃えるためならとにかく網羅性が大事ですし、開発前に画面イメージをユーザーさんに見てもらって感想を聞いて不確実性を減らしたいならある程度デザインされたものが必要です。

設計する時に作るものの選択肢をいくつか持っていれば、意図に応じて使い分けられて便利です。

私のバックログを管理してきたツールたち

Webディレクター解体アドベントカレンダー16日目の記事です。今日は私がこれまでにプロダクトバックログやスプリントバックログを管理してきたツールたちを紹介します。

プロジェクトが始まって企画の大枠が決まった時、一番最初に行うのはプロジェクトをどう進めるか、その計画から始めると思います。最初はインセプションデッキなどの認識を合わせるためのドキュメントを書くところから始めることが多いでしょう。

そして次に、もしくは同時に、プロジェクトの進め方を考えると思います。ウォーターフォール式に進めるのか、アジャイルに開発していくのか。スクラムを導入するとしたら、スプリントの期間はどれくらいで、デイリースクラムやスプリントレビューをいつやるのか。

そうした検討の中で、何のツールを使うかという問題も出てきます。チャットツールやドキュメントツールはだいたい普段使っているものがあるでしょうから、あまり議論の余地はないでしょう。よく問題になるのは、バックログを何で管理するか、そしてタスクの管理ツールをどうするかです。

Github

おそらくほとんどの開発現場でGithubが使われていると思います。そのままGithubのIssueやProjectを使ってバックログやタスクの管理まで完結してしまうこともあるでしょう。特にProjectを作るとカンバン形式でIssueを扱えるようになるので便利です。

f:id:nmy:20201214231924p:plain

使うツールが増えないので開発メンバーにとっては見る場所が減って良い一方、タスク管理に特化したツールではないので少し複雑なことをしようとすると困ることもあります。例えば工数を見積もってベロシティを計測する時です。Issueには見積もった工数を入力しておく欄がないからです。

あとはGithubは主にエンジニアやデザイナーがソースコードを管理するためのツールで、Issueは彼らの備忘録としても使われます。ちょっとやり残したことをIssueに切り出しておいて後でやろうとか、思いついたちょっとした改善をIssueにしておこうとか、そういうケースでどんどん増えていきます。

Issueをバックログの管理に使おうとすると、そうした改善系の細かいタスクとプロダクトオーナーが切り出したやりたいことが、全部同じ場所に集まるので混乱することもあります。もちろんラベルを使ったりProjectの決まったレーンに乗せるなどしてうまく工夫をすれば良いのですが、そうしたルールを開発チーム全体に浸透させるのにもコストがかかったり、徹底できなかったりすると大変です。

  • 良い
    • 使うツールが増えずに1本化できる
  • いまいち
    • 見積もった工数を入力する欄がなく、ベロシティの計測やバーンダウンチャートの作成をしたい時に困る
    • みんなが自由に作るissueとPOが管理するバックログが1つのツール内でごちゃまぜになることがある

Googleスプレッドシート

最初はGithubのIssueで管理していたのですが、大きな新サービスの立ち上げプロジェクトをやることになったとき、工数見積もりをしてベロシティを計測し、スプリントごとにバーンダウンチャートを更新して進捗を可視化したくなってきました。そこでバックログをGoogleスプレッドシートで管理することにしました。

f:id:nmy:20201214231942p:plain

マイルストーンごとに、優先度ごとに、それぞれ残りのタスクの工数がどれくらいあって、これまでのスプリントでどれくらいのベロシティが出せていたか。その全てを数値化して確認できるのが便利でした。別シートに集計用の表を作ったり、バーンダウンチャートのグラフを作ったりして欲しい表やグラフを作れるのでとにかく自由度が高い。

ただ関数を駆使して自分で全部作らないといけないからメンテナンスのコストは高いし、作った人の個性が全面に出るので俗人化してしまう。それにただの表計算ソフトだからUIが洗練されてないのも難点です。ドラッグ&ドロップで移動させたりできないし、なにより触ってて楽しくない。泥臭いツールを我慢して使ってる感じがイマイチでした。

  • 良い
    • グラフを作ったり、カテゴリごとに残り工数を計算したり、エンジニアに頼まなくても自由に可視化できる
    • だいたいみんなGoogleのアカウントは持っているので、様々なステークホルダーに共有しやすい
  • いまいち
    • 最初にシートを作って値を参照する表を作ってグラフを作ってと、全部自分で作らないといけない
    • 自由度が高すぎて作った人の個性が強く出るため管理する人が変わると形式も変わり、開発チームに使い方の学びが蓄積されない

Trello

サービスをリリースした後、工数見積もりやベロシティの計測が不要になったこともあって、Trelloを使うようになりました。Trelloは何より視覚的で操作もわかりやすい。まさにカンバンに特化したツールです。タスクはカード状になっていて、レーンを移動させたりラベルをつけたりするのが直感的で触っていて楽しいのが良かった。

f:id:nmy:20201214231959p:plain

でも、良くも悪くも非常にシンプルなカンバンなので、プロジェクトごとに進捗を管理したり、タスクの依存関係を確認したり、工数やベロシティを管理するのには向いていませんでした。そういうものが不要なシンプルな少人数のプロジェクトならいいのですが、複数のプロジェクトを同時進行させる規模の大きめのチームだと、だんだん物足りなくなってきました。

  • 良い
    • ドラッグ&ドロップでレーンの移動ができるので、開発中とかレビュー中とかタスクの進捗を細かく管理したい時に移動させやすい
  • いまいち
    • 見積もりを入れるフィールドがなかったり、依存関係を表現できないので複雑なプロジェクトに不向き
    • 1プロジェクト1ボードという概念でボードを横断してタスクを登録できないので、1つのチームが同時並行で複数のプロジェクトを進行しようとすると面倒

Asana

そうしてたどり着いたのがAsanaです。最近はもうAsanaの思想にどっぷり浸かって、彼らの提唱する使い方をそのままなぞっています。こういうツールはだいたい設計思想があって、その思想通りに使うことが求められます。特にAsanaはこう使ってくれという思想がはっきりしていて、ヘルプでユースケース毎の利用方法を詳しく説明していて「Asanaでのスプリントプランニング」というそのものズバリのページがあり、言われるがままにその通りやってみました。

  • 開発に1スプリント(2週間)以上かかるものはプロジェクトを作成する
    • どのプロジェクトにも属さないタスクはバックログ用のプロジェクトを用意しておいて、そこに置く
    • スプリントごとにスプリントバックログ用のプロジェクトを作って、次のスプリントでやることも可視化する
    • スプリントバックログ用のプロジェクトは、スプリントが終わったらレビューしてアーカイブしてしまう
  • スプリントレビューの度に、各プロジェクトの進捗を記入する
    • ステータスが「順調」「リスクあり」「要対応」「保留中」から選べるので、必ずスプリント毎にステータスを更新する
    • あとは自由記述で進捗を記入できるので、スプリントでやったことや次のスプリントでやることを書いておく
    • 事前に書いておいた上記のレビューを、スプリントレビューの場で確認する
  • ポートフォリオで複数のプロジェクトを俯瞰して確認できるようにする
    • 複数のプロジェクトを同時進行するため、チームの全体感を把握するためのポートフォリオを作り、属するプロジェクトを紐づけておく
    • スプリントレビューの度に更新する進捗のステータスが一覧できるので、黄色信号や赤信号の灯っているプロジェクトが一目でわかって把握しやすい
    • 各プロジェクトのマイルストーンも横断して時系列に見られるビューがあるので、デイリースクラムなどで確認する

特にポートフォリオと進捗の組み合わせが便利でした。プロジェクト毎に進捗を記入できるのですが、ステータスを「順調」「リスクあり」「要対応」から選べ、それぞれが青信号、黄信号、赤信号を表していて、まさに進行管理を行うのに明確でわかりやすい。スプリントレビューの時に要対応になっているプロジェクトがあったら、何かしらの手札を切らないといけないという具合で、スクラムとの相性がとても良いのです。

f:id:nmy:20201214232033p:plain

あとはやっぱり依存関係を可視化して、マイルストーンと一緒にタイムラインで見られるところがいいですね。大規模な仕組みを作る時はタスクに依存関係が生じ、単にベロシティの管理だけしていたら優先すべきタスクを後回しにしてしまうこともあります。依存関係を付けて日々進捗に応じてアップデートしていくのは少し大変ですが、ちゃんと可視化されていることで得られるメリットも大きいと思います。

f:id:nmy:20201214232046p:plain

  • 良い
    • スクラムでの利用を想定した作りになっていて、進捗のステータスが把握しやすい
    • 依存関係が表現できたり、タスクだけでなくマイルストーンが建てられたり、サブタスクを作れたりしてタスクの性質を可視化できる
    • APIが用意されていて拡張性も高い
  • いまいち
    • 複数プロジェクトをまたいで管理できるポートフォリオなど、ガッツリ使い込もうとすると有料になって値段も高め
    • できることが多くて複雑なので学習コストがかかり、シンプルなプロジェクトには不向き

コストが高いのが難点ですが、今のところは気に入って使っています。ただツールはあくまでもツール。手段が目的化しないようにだけは、いつも心のどこかで気をつけておきたいです。

プロジェクトマネジメントの基本は進行管理から

Webディレクター解体アドベントカレンダー15日目の記事です。今日はプロジェクトマネジメントについて書きます。

市場の状況やユーザーの動向が刻々と変化していくWebサービス開発においては、如何に柔軟に不確実性と付き合っていくかが求められます。その不確実な状況に日々柔軟に対応していくためのプロジェクトマネジメント手法として、最近はアジャイル開発やスクラムというフレームワークが浸透していて、複数人がチームを組んでWebサービスを開発する時の方法論が確立されています。アジャイルやスクラムに関する書籍も多数出版されており、Web開発の現場でも当たり前のように導入されていると思います。

かつてのWebディレクターが企画から進行管理まで1人でやっていた時代から、専門職としてのプロジェクトマネージャー(PjM)が求められるようになってきました。スクラムの文脈でもプロダクトオーナーとスクラムマスターは兼任すべきではないとされており、それぞれの専門職が担当するのが理想です。

私もこれまでディレクターという肩書きでプロダクトマネジメントとプロジェクトマネジメントを兼任することも多かったのですが、肌感としてもう限界が来ていると感じます。求められる専門性も、使う頭も全く違うからです。もうWebディレクターという職種として、両方を担当していく時代は終わりかけている。そう感じたことも「Webディレクター解体アドベントカレンダー」とかいう仰々しい名前を付けた理由の1つです。ロックは死んだと言ったジョン・ライドンやヒップホップは死んだと言ったNasみたいで偉そうですが。

それでも企画やプロダクトマネジメントを行う立場の人が、プロジェクトマネジメントを兼任することもあるでしょう。いつもいつも理想的な開発チームが組めてその道の達人が揃うわけでもない。もちろんそれが理想だし組織がそうなっていないのなら体制を構築し直した方がいいけど、目の前にある現実に向き合わないといけない時もあります。

そんな時のために、企画やプロダクトマネジメントを中心にやってきた人に向けて、プロジェクトマネジメントの一番基本であり日々の業務に直結する進行管理について書いてみます。アジャイルやスクラムの詳細は各種書籍に詳しいので、何のためにやるのかという部分です。

何のために進捗を確認するのか

スクラムについて書かれた本を読んでいると、専門用語が沢山でてきます。プロダクトバックログを作って、スプリントごとにスプリントレビューとスプリントレトロスペクティブとスプリントプランニングをやってスプリントバックログを作り、日々デイリースクラムをやりましょうと。それぞれに意味があり、本にはそれぞれの意味とやり方について詳しく書かれています。それぞれ教科書に書かれた通りにやることが推奨されていて、実際その通りにやると良いと思います。

でも、根底に何のためにやるのかを本当に意識できていないと、ただ表層をなぞるだけになってしまう。ただスクラム本に書かれた手法をそのままなぞっているだけの状態、テンプレートをただ埋めているだけの状態。あくまで手法でありツールであるスクラムを使いこなすには、目的が必要です。なぜ進捗を確認して可視化するのか。なぜわざわざ開発の手を止めて開発チーム全員を集めてスプリント会をやったりデイリースクラムをやるのか。

その目的に自覚的であることと、スクラムやアジャイル開発といったフレームワークを目的のためにどう使うのか、そのイメージを持つところが、プロジェクトマネジメントの始まりだと思っています。

手を打つため

進捗を確認するのは、進捗に応じて手を打つためです。スクラムなら毎日行うデイリースクラムや、スプリントごとに行うレビューが主に進捗確認の場になると思います。それぞれ扱う期間のスコープが違い、日々の微調整を行うのか、思い切った手を打って予定を変更するのか判断していく必要があります。例えばこんな風に。

  • デイリースクラム:進捗確認して微調整する場
    • そろそろ終わりそうだから、次のタスクを用意しておこう
    • そろそろ終わりそうだから、リリースに向けた告知文の用意などを進めておこう
    • 予定より遅れてそうだから、この人には差し込みのタスクを振らないようにしよう
    • 予定より遅れてそうだから、待っている間デザイナーに他のタスクを振ろう
  • スプリントレビュー:進捗確認して方向変換する場
    • 予定よりも順調だから、早めにリリースしよう
    • 予定よりも順調だから、優先度Shouldにしていたタスクの要件を固めておこう
    • 予定よりも遅れているけど、まだバッファの範囲内だから静観しよう
    • このままだと間に合わないから、この要件を削ろう
    • このままだと間に合わないから、他のメンバーをヘルプで加えよう
    • このままだと間に合わないから、リリースを遅らせるためにステークホルダーと調整しよう

ただ開発メンバーや各プロジェクトの進捗を聞き流すのではなく、次の一手を常に考えておく必要があります。それぞれの進捗報告を聞きながら、何か手を打つ必要があるかどうか、そこに意識を持っていくのが進行管理の第一歩です。

手元に手札を用意しておく

状況に応じて手を打つためには、手元に手札を用意しておく必要があります。手札がないと、ただあたふたして終わってしまう。それでは進捗を確認する意味がありません。あらかじめどれだけ手札を用意しておけるか。それはプロジェクトが始まる時点である程度決まってきます。

f:id:nmy:20201212142328p:plain

プロジェクトが始まる時にインセプションデッキを作るのも、この手札を用意するためという側面も強いです。インセプションデッキの一項目にトレードオフスライダーというものがあります。

トレードオフスライダーとは「品質」「コスト」「期間」「スコープ」の4つの項目の内、何をどれくらい優先するのか決めておくことです。期限が決まっているプロジェクトの場合はリリースを遅らせるという手札は切れないし、かけられるコストが予算で決まっている場合は人員の追加が難しくなり、スコープが決まっている場合は機能を削ろうとしても限界が出てきます。もちろん全てがきっちりと計画通りに行けばいいですが、何かを優先すると何かが犠牲になるのが世の常でまさにトレードオフの関係にあります。

だからあらかじめ、どの手札は使えてどの手札は使えないか確認しておくのです。そして可能なら、最初にプロジェクトを始める時に手札になりそうなバッファを予め仕込んでおきます。よく推奨されるのは、期間と機能の両方のバッファを積んでおくことです。特に期間が決まっている場合は要注意。手元に持てるだけの手札を用意して挑む必要があるでしょう。

進行管理とは、開発メンバーの進捗を監視して遅れが出てきたら鞭を振るうことではありません。その時々の状況に応じて、適切な手札を切って軌道修正したり、ステークホルダーと調整したり、先回りして必要な準備を進めたり、とにかく手を打ち続けるためにやることです。適切なタイミングで適切な手を打つために、状況を確認しつづける。それが進行管理を行う理由です。