フルリモート勤務だと情報が降ってきにくい…なのでタスクを共有しにくい部分がある。
少人数のプロジェクトであれば PM が 1 件ずつマネジメントすることが可能であるが、自律的に動くメンバーの進捗を PM が管理しきるのは難しい。(複数件持ちまわるケースもあるし・・・)
そこでどういった管理方法を選定していくかになるが、カンバンとガントチャート(WBS)を比較しつつ、カンバンのメリットについて書いていきたい。
(ここでは引用以外の表現はカンバンとする。)
カンバン方式について、なぜ使うのか
ウォーターフォールモデルと比較して。
1.小さな単位での実装と検証ができるようになる
2.メンバー間の関係調整やタスク割り振りが視覚的に分かる
3.フィードバックができる仕組みになる
4.プロジェクト管理の良いインフラストラクチャーになる
カンバンとは
トヨタのスケジュール管理を元に、ソフトウェア開発にも適応されたプロジェクト管理方法です。
下記は Jira というツールのカンバンボードです。
各カラムに入っているタスク(WIP)の状態を定義し、右にいくほど製品は仕上がるようになっています。
このケースでは、
・TODO(やることリスト)
・分析
・進行中
・検証
があります。
各タスクはどういった状態にあるのか外部から見ただけでも知ることができます。
メンバーの人数が多くなればなるほどコミュニケーションのコストは増えてきますので、小さな効率化が図れます。
こうした分割をすることでいいことはあるのでしょうか。
小さなサイクルを回す
大きなプロジェクトではない場合、小さなサイクル(要件定義~リリース)を回して顧客からフィードバックを受け取りたい場合があります。
ウォーターフォール型、いわゆる全ての工程で開発 → テストを行うと、修正、手戻り発生時のコストが大きくなりがちです。
機能が分割可能である場合は、分析 → 実装 → 検証までをカンバンのフローで作成し、顧客の望むタイミングで小さなリリースを提供できるような仕組み作りができます。
分析から検証までを短いスパンで行うことは手戻りのリスクを抑え、開発者が書いたコードを忘れる(本当に忘れる)といったことを防ぎます。
タスクの振り分けが一目瞭然
タスクは数日で消化できる量及び完了日数を明記することで見積もりの精度の向上やタスクの消化率や進捗率をツール内で管理することができます。
また、タスクの割り振りはツールを利用することで、レポートとして出力可能ですし、同じ人にタスクが集中していないかレビューを行うことができます。
更にタスクについては追跡も可能ですので、過去の実装分のバグが万が一見つかってしまった場合、適任者をピックアップすることができます。
いい品質の人には MVP を!
他人のコードはあまり触りたくないのが人情ではないでしょうか。カンバン方式では、各カラムについての状態を定義しておくことで、最低限の品質を保つことができます。(少なくともユニットテストと静的解析を通過しないと検証には進まないといった風に)
品質を追跡することでフィードバックだけではなく、顧客への説明、更に人事評価まで(よろしくお願いします)。タスクの消化量と品質はあまり言いたくはありませんが、目に見える成果として評価しやすい部分です。
顧客満足度を上げるためのツールとして
カンバンはウォーターフォールモデルを否定していません。締め切りを設定し、品質を守って期日までに仕上げるという点は同一です。
ただ、短いサイクルで顧客と密にやり取りを行うような開発体制になった場合、カンバンというツールがあると、コミュニケーションがもっと便利になるということです。カンバンはタスクの管理方法と実装のスケールが変わるだけで、他はチームが望む分だけカンバンのエッセンスを取り入れることができます。
まずは、小さく始めてカンバンの良さを体感してみましょう!
下記の本がとても参考になりました。