手法、ツールを適用する真因の把握と概念

レポートではヤバさが今ひとつ掴めない案件に若手エンジニアからタレコミがあって、レポートを眺め直してみたら『そういうことか』と、まだまだレポートの読み方に工夫（リスクを最短で探す）が足らない（その案件で学習した）ということがあった。

このとき、結果的にカンバンを導入して、交渉力の知識を発揮して役員にお出まし願って色々とカタをつけたのだが、カンバンを導入するに至ったアプローチというか、意思決定はなかなかよかったのではないかと今でも思う。

見切りをつける

プロジェクトメンバやリーダである尻に火が付いていることに気づかないプロジェクトマネージャの時間を削ってまでインタビューに直接会うことは、立て直しではやらないと頓珍漢なことになるのでやらなくてはならない。

一見、外野が乗り込んできて、エンジニアの時間を占有してまで状況を聞くのは見切りをつけるためである。何の見切りかといえば、プロジェクトを今のまま続けさせるか、手を入れるか、である。

言い方を変えれば、手の入れ具合の程度を知りたいのである。軽傷なのか重症なのか。リソース的に移植しなければならないのか、とかとか。

これが軸にあるから、手法やツールを導入して何とかしようとはならない。軸を持つというのは囚われてしまうと厄介だが、上手に支えているのであれば強い。

真因と手法またはツール

伝統的なシステム開発手法でやっていて、誰もそれを選択したことを疑わないとき、その手法で上手くいっていないこと自体に誰も疑念を持たないものだ。

機能していない手法やツールはプロジェクト上の障害にしかなり得ない。文書管理ツールを入れたけど誰も使わないとか、チケット管理システムを入れたけど結局付箋でやっているとか、似たような経験をしたことがあるのではないだろうか。

ツールや手法を導入するなら、それをやらないと業務が進まないように作業プロセスをデザインし直すのが自分としては当然のセオリーなのだが、上手くいかない案件ではツールや手法を何も考えずに追加してしまう。追加された作業を誰が喜んでやるだろうか、という話である。

現行の機能していない仕組みの、その真因を解決するだろう手段を足を運んで情報収集し、シミュレーションしていけそうかを判断し、案件の進捗上の障害を解消する手法なりツールを導入して、軌道に乗るまで面倒をみる。

機能していないのはそれなりに理由があるので、何かを足すのはさらにリソース不足を招くだけでしかない。

ネットを検索して、キーワードを求め、手法の概要を理解する。google検索して、ブログを読んだり、slideshareでスライドを読む。さらに、勉強会やイベントちっくな催に参加して複数ある手法から案件の進捗上の障害を取り除く候補を絞り込む。

実施は単純な話で、スクラム関連の勉強会にいくつか出て、スクラムではなく、カンバンがその案件にフィットした、というだけの話である。

プロジェクト上の障害をカンバンで赤裸々にし、機能していない手法を機能させるべく、二足歩行ができるまで伴走する。

赤裸々にすることで、流石に尻に火がついていると自覚症状のなかったプロジェクトマネージャも自覚するようになったが、手に余るものはさっさとこちらで引き受け、本来のステークホルダを巻き込み、アナーキーな状態を制御にかかる。

こんな風に人が絡む面倒くさい事案はサクッと進められるのに、sourcetreeの概念がよくわからない。根本がわかってないのだろう。