カンバンによって仕事の流れと意味を設計する

  • このエントリーをはてなブックマークに追加
  • このエントリーをはてなブックマークに追加

workflow at the most basic level

カンバンの形はそれぞれに違いますが、いろいろ違いがあることが発見につながります。たとえば、カンバンを作る前にメンバーそれぞれに「理想のカンバン」を書いてもらえば、それぞれの考え方やアイデアを知ることができます。

カンバンの設計
この写真は僕が考えたカンバンのデザインです。「Backlog」と呼ばれるやることリストがあります。ここは可能であれば優先順位順に並んでいると、やることの選択が楽になります。まぁ必須ではなくてもよいです。

そこから今週やる分として「TODO」があります。カンバンをはじめるところだったので、まずは短く1週間でチェックできるのが良いと思いました。このTODOというバッファを作ることで、「今週これぐらいやる」という量が見えるようになります。やる量は残りの量にもなるので、「なんか全然終わらない」といったことに気がつけます。

次に「Doing」が続き、ここでは作業者ごとに領域を分けています。この領域がWIP制限となり、「ひとり2個まで同時で作業して良い」という形になります。自分の周りでは「ひとり2個」の制限をかけることが多いです。

作業が終わると「Release」に入ります。正確に言うと「リリース待ちステージ」です。もちろん、Doingにリリースを含めることもできますが、複数人で同時作業をしていると、タイミングを合わせてリリースすることが多いので、リリースステージというバッファを用意することで、自然に同期させています。

リリースが終われば「Done」です。しばらく貼っておけば、何が終わったかが見えるようになり達成感が生まれます。また、このDoneの量を定期的に計測すれば、自分たちのスループットを理解できるので、計画づくりも簡単になります。

カンバンの設計
続いては、あるエンジニアリーダーが設計したカンバンです。彼は現場に詳しいので、現場の流れをよく理解しています。それぞれ見ていきましょう。

バックログの下にある「Problem」は問題が発生したら貼り付ける場所です。バックログと並べることで、チームへの入力が2つになります。2つになるということは、どちらからどれぐらい選ぶか? をよく考えなければ、バックログばかりやってしまったり、プロブレムだけやってしまったりしてしまうので注意です。ただ、やることを大きく分類することで、問題の量がわかったりするメリットもあります。

Doingは上と同じ。その次に「Review」というステージが登場します。よく聞いてみると、作業の確認としてレビューを行うという仕事の流れがあるそうです。ここで検討する点があります。

  • レビューをDoingに含める場合、レビューステージが必要なくなります。ただし、Doingの終了条件(完了の定義)がひとつ増えます。
  • Doingとレビューを分ける場合、レビューNGの作業がDoingに戻るという運用が発生します。

どちらがいいかはそれぞれ試してみるのが良いと思います。自分の経験だとDoingに多くの完了の定義を入れると、カンバン全体の流れが遅く感じるので、ある程度細かくステージを区切ってすごろくのようにやることが多いです。

カンバンの設計

2人のカンバンの設計を見せ合い、それぞれのメリット・デメリットを検討した結果、はじめてのカンバンはこのようなデザインになりました。

あとはカンバンを実際に作りながら、ステージの幅などを決めていきます。そのときに「大きく2つのレーン(横の区切り)にわけたい」といった意見を反映してこうなっています。実際には働いている人間であっても、無意識にやっていることがあったりするので、そういった暗黙の知識を取り入れていくのは重要です。

自分たちで考えたカンバンのデザインであれば、やりはじめるのはとても簡単です。ただ、メンバーに説明するときはカンバンのルールを説明するのではなく、ルールの意味を説明すると良いでしょう。

そうすることでやりにくい仕事流れに気がついたり、「この作業は流れを工夫すればもっと効率良くできそう」といったさらなる発見を促せます。ルールは自分たちを守るためであり、ルールを守ることはそれほど重要ではありません。

あとはそういった発見をカンバンに反映しながら、自分たちのやり方を作り上げていけば、カンバンを活用したプロジェクト運営やタスク管理が実現できます。

タグ:
カテゴリー: 記事

コメントを残す

アーカイブ