メインコンテンツへスキップ
見出し画像

【初めてのロードマップづくり まとめ後編】手元に置いて使う20点と道具

     こんにちは。クオリティアーツの池田です。ソフトウェアの品質とテストを中心に、ソフトウェアエンジニアリング全般が専門です。コンサルタントとして、組織の伴走支援をしています(自己紹介)(noteホーム)。

     連載「初めてのロードマップづくり。田口さんの奮闘物語。」の巻末記事、その後編です。連載の趣旨と全16回の一覧は、扉記事にあります。

     前編では、9つの問いで紙がどう変わったか、承認された紙の3つの層、見ていた側は何をしていたか、承認のあとの4歩まで並べました。後編は、手元に置いて使うものだけです。止まりやすい20点、アジャイル開発の道具との対応、この連載で書かなかったこと、参考にした資料。

    この記事のポイント

    • 止まりやすい20点を、作り始める前・書きながら・紙が出来たあとの3つに分けて並べた。判定の仕方、裏付けの現物、数えたときの定義。この3つは、あとから足すのが難しい

    • 目標には階層がある。上の数字は書き写さず、自分の領域の言葉で言える分を切り出す。測りかたが目標になると、測りかたのほうが壊れる

    • 枠を先に決めてから中身を入れる。減らすのは依存関係の後ろ側から。借りた道具はアジャイル開発と重なるが、スプリントとは5つ違う

    1. 止まりやすい20点

     田口さんが3か月で通った点と、よくある止まり方を並べます。どれも、私も一度は通りました。 作り始める前・書きながら・紙が出来たあとの3つに分けてあります。1から13は前編2章の9つの問いを自分の紙に当てる形に(1と6は、その手前の構えです)、14から20は前編6章の4歩をチェックリストの形に書き直したものです。

     20点ぜんぶは要りません。紙の見た目を変えるのは、2(名詞で終える)・3(3年目から書く)・4(今の延長の外に置く)・9(状態で書く)の4つです。時間が取れないなら、ここだけでも効きます。そのうえで、あとから足しにくい3つ(7・8・11)に手を伸ばしてください。理由は1-2の末尾にあります。

    1-1. 作り始める前に

    • 1. 書き始める前に、ロードマップ・ToBeポAsIsぎ3語を自分の言葉にしておく。ここがそろうと、あとが速い

    • 2. 年度の欄は、名詞で終える。動詞で埋めると、3年後の姿が書かれない作業計画書になる

    • 3. 3年目の欄から先に書く。1年目から積み上げると、3年目が「定着」で埋まる

    • 4. 3年後の欄は、今の延長の外に置く。届く範囲で書くと、届く範囲までしか行かない

    • 5. 兼務前提で検算する。人数と週の時間から枠を先に出し、入らない分は期をずらす

    • 6. 分からない言葉は、その場で出どころに聞きに行く。自分の知識に引き寄せて処理すると、意味が痩せる

     作り始める前の6点が、図表1です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_1_20点_作り始める前に

    1-2. 書きながら

     この7点の前に、言葉をひとつ置いておきます。状態とは、ある時点で時間を止めて見たときに、そこに「ある」もののことです(第9回)。作業には時間の幅があって、終われば消えます。状態には幅がないので、その日に見れば、成り立っているかどうかが分かります。7から13は、この違いを前提にしています。

    • 7. 3年後の状態は、判定の仕方まで決めて書く。「誰が見て、そうだと分かるか」に答えることができない行は、文の形が状態でも、中身はまだ作業のまま

    • 8. 状態ごとに、裏付けのアウトプットを決める。獲得した力は、人・型・仕組み・資産のどれかに現れる。逃げ道が4つあって、「〜が向上している」で止める、満足度アンケートに頼る、実施回数を裏付けにする、数字だけを置く。どれもその場の紙は埋まりますが、3年間ずっと判定を議論し続けることになります

    • 9. 年度の欄は、状態で書く。見分け方は4つ。文末を見る、誰が見て分かるかを聞く、来年の同じ時期にも同じ問いが立つか、達成されなかったとき何が言えるか

    • 10. 3年後の5行に効く打ち手だけを残し、残りは別の紙に取っておく。次のロードマップの材料になる

    • 11. AsIsは、数える前に定義・範囲・時点を決めてから数える。決め方に正解はなく、選んだ定義を紙に書いておくこと。それが、3年後に同じ数え方で比べるための条件です。数えた数字の下に、経緯・制約・使える資産・周囲の動きまで書く

    • 12. 直近6か月は、2週間のコマまで落とす。集まった日から動ける

    • 13. 打ち手は仮説として置き、3か月ごとに確かめて組み直す。3年目は方向、2年目は輪郭、1年目は具体。先まで決め切らないほうが、直しやすい

     書きながらの7点が、図表2です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_2_20点_書きながら

    1-3. 紙が出来たあと

    • 14. メンバーは、ロードマップの欄から逆算して選ぶ。選んだ理由が、そのまま説明になる

    • 15. 頼む中身が1行で書けない席は、人を探さずに空欄のまま残す。何を作って、いつまでに、どうなっていたら終わりか。ここが書けてから、社内か社外かを考える。空欄は、足りないものが見えている状態です

    • 16. 上長に持っていくのは、名前ではなく量。担当の紙と、週あたりの時間と、どこから出すかをそろえて行く。「全面的に協力します」は、工数の予約ではありません

    • 17. 名簿が出来たら、会議体と置き場所を決めてから初日を迎える。ここまでそろえて、立ち上げ

    • 18. 説明会では、一人ひとりの担当と時間を先に渡す。そこが決まると、あとは自分で動ける

    • 19. 立ち上げの発表は、なぜやるのかから始める。やることを並べた資料は、進捗報告になる

    • 20. キックオフの聞き手は、部の全員・他部署・上位の役職まで数える

     紙が出来たあとの7点が、図表3です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_3_20点_紙が出来たあと

     7・8・11は、あとから足すのが難しいところです。判定の仕方も、裏付けの現物も、数えたときの定義も、時間が経つと当時の事情を思い出せなくなります。9・12・13は、3か月ごとの見直しで直すことができます。先に手をかけるなら、この3つです。

     2と9は、作業を並べる計画に慣れた人ほど起きます。年度の欄は、動詞ではなく名詞で埋める。そこだけ覚えておけば、だいぶ防ぐことができます。

     14から20は、紙を作る練習では身につきません。人に説明し、時間を取りに行くところで覚えるものです。

    2. 計画を、技術として見る

     1章は手順でした。ここからは、その手順がなぜそうなっているかを、道具の側から見ていきます。

    2-1. 目標には、階層がある

     3年後の姿は、ひとつではないのです。部のToBeがあり、その下にWGのToBeがあり、年度末の状態があり、2週間のコマのアウトプットがある。下の層は、上の層が成り立っているかを判定するために置きます。 逆ではありません。

     ここでいちばん間違えやすいのが、上の数字をそのまま書き写してしまうことです。部が「手戻りを半分に」と言っているからといって、WGの紙にも「手戻りを半分に」と書くと、4つのWGが同じ数字を掲げることになります。3年後、誰の成果か分からなくなる。上のToBeにぶら下げるというのは、上の数字のうち、自分の領域の言葉で言える分を切り出すことです(第5回)。田口さんの場合は、部の4,000人日のうち、テストの手戻りと差し戻し7件を自分の領域として切り出しました。

     階層にしたのが図表4です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_4_目標の階層

     ぶら下げる先が見当たらないこともあります。そのときは、自分の紙のいちばん上の行を自分で書いてしまってよい、というのが第4回の結論でした。仮に置いて、上長に確認をもらう。正しく読めていれば承認が取れますし、外れていれば訂正が返ってきます。どちらに転んでも情報が増えるので、黙っているより早い。

    2-2. 判定できる形にする

     年度の欄に要るのは、読んだ人が「出来ている」「出来ていない」を判定できる形です。言われれば当たり前ですが、書いていると崩れます。第9回の見分け方は4つでした。文末を見る。「誰が見て、そうだと分かるか」を聞く。来年の同じ時期にも同じ問いが立つか。達成されなかったとき、何を言うことができるか。

     このうち効くのは2つ目です。文末だけなら化粧ができます。「テスト自動化を導入する」を「テスト自動化が導入されている」に書き換えても、中身は同じです。判定する人と、判定の材料まで決まって、はじめて状態になります。

     開発の現場の言葉で並べると、こうなります。

    • 「先行3チームの回帰テストが、毎晩自動で流れていて、朝に結果の一覧が出ている」 … 誰が見ても同じ判定になります。年度の欄に書くのは、この形です

    • 「テスト自動化が導入されている」 … 導入の定義しだいで動きます。1本でも流れていれば導入なのか、全チームで回っていることなのか

    • 「品質への意識が高まっている」 … 時間を止めて見ても、成り立っているかどうか分かりません

     状態そのものを直接は見ることができない行もあります。そのときは、裏付けとなるアウトプットを置きます。状態は時点を指し、アウトプットはその時点に残っている現物を指す。この2つで1組です(第5回)。獲得した力は、人・型・仕組み・資産のどれかに現れます。5年前の活動が立ち消えたのは、力が人にしか現れていなかったからでもありました(第6回)。

    2-3. 測りかたが目標になると、測りかたが壊れる

     裏付けを数字にすると、別の問題が出ます。その数字を上げること自体が仕事になる。

     第5回で挙げた逃げ道4つは、どれもこの形をしています。「〜が向上している」で止める。満足度アンケートに頼ると、アンケートの文面を工夫する仕事になります。実施回数を裏付けにすると、12回やって何も変わらないことが起こります。数字だけを置くと、流出の定義を狭める、報告の基準を変える、集計の対象から外す、という方向に力が働きます。

     この性質には名前があります。「測りかたが目標になると、よい測りかたではなくなる」。この短い言い方はグッドハート本人のものではなく、Marilyn Strathern が1997年の論文で書いたものです("'Improving ratings': audit in the British University system", European Review, 5(3), 1997, p.308)。もとになったチャールズ・グッドハートの言明は1975年のもので、「観測された統計的な規則性は、それを制御の目的で使おうと圧力がかかった時点で、崩れる傾向がある」という、もう少し広い言い方でした。

     3年の計画では、ここがそのまま効きます。3年間ずっと同じ数字で評価される仕組みを先に作ると、3年かけてその数字を作る仕事に寄っていく。 防ぎ方は、派手な手ではありません。数字と現物をセットで置くこと(第5回)。数えかたの定義を紙に書いておくこと(第6回)。そして、3か月ごとの見直しで「この数字は、まだ測りたいものを測っているか」を確かめることです。

     現物がどうしても思いつかない行には、代理の指標を置いてかまいません。「テストがやりたい仕事になっている」を直接示す文書はありませんが、アサイン希望の件数なら数えることができます。代理だと分かって使う分には、問題ありません。 困るのは、代理であることを忘れたときです。

    2-4. 数える前に、決める

     AsIsを数えるとき、先に決めることが3つあります。定義、範囲、時点です(第6回)。何を1件と数えるか。どのチームまでを数えるか。いつの時点を取るか。決め方に正解はないのですが、選んだ定義を紙に書いておくことだけが、3年後に同じ数え方で比べるための条件です。

     手戻りの工数をどの区分で数えるかにも、既製の枠があります。予防・評価・失敗(内部・外部)の4区分で、PAF法と呼ばれます。A.V. ファイゲンバウムが1956年に示した品質コストの考え方が元です(第6回)。自前で区分を考える前に、この枠に当ててみると早い。

     そして、ここがいちばん言いたいところです。測れるようにすること自体を、初年度の打ち手に載せる。 工数入力に手戻りの区分を足し、基準を決め、月次で集計を始める。これは改善の前提ではなく、改善の一部です(第6回)。1年目に派手な成果は出ません。出るのは基準年です。基準年をつくることが、初年度のいちばん最初の成果物になります(第1回後編)。

    3. 量と順番の技術

    3-1. 枠から決める

     改善のWGは、たいてい専任ではないと思います。ここを見ないまま年度に割り付けると、紙の上では収まっているのに、4月から誰も手をつけられない計画ができあがります。

     検算は単純で、先に枠を決めて、中身を入れます(第9回)。中身を決めてから必要な時間を足し上げるのとは、順番が逆です。手順を図表5にまとめました。

    画像
    図表_初めてのロードマップづくり_まとめ後編_5_枠から決める

     田口さんの場合、主査が週8時間、メンバー5人が週4時間ずつで、合わせて週28時間。1年目の前半は26週あるので、枠は約730時間です。最初に見積もった打ち手は700時間ほどで、ぎりぎり収まっていました。ところが、学ぶと試すの時間を足し直すと1,200時間を超えます。1.7倍です。

     減らすのは、依存関係の後ろ側からです。 手前、つまり道具と情報を削ると、後ろに並べたものが全部動かなくなります。分類の欄がないまま集計の打ち手だけ残しても、集計できません。田口さんは「広げる」の打ち手を全部後ろへずらして、580時間にしました。枠の8割です。見積もりは外れる前提で、2割空けておくと、3か月後の見直しが楽になります。

     もうひとつ。主査の週8時間は、枠全体の3割近くを占めます。 ここを会社として出してもらうことができるかで、計画に入る量が変わります。承認では人の時間は出てきません。紙が通っても、メンバーの本業の予定は動いていない(第12回)。だから上長のところへは、名前ではなく量を持っていきます。担当の紙と、週あたりの時間と、どこから出すか。「全面的に協力します」は、工数の予約ではありません(第13回)。

    3-2. 自分たちだけでは、日程が決まらないコマ

     12コマのうち、自部署だけでは日程を決めることができないものがあります。他部署の手が要るコマです。田口さんの第2コマは「工数入力に手戻りの区分が追加されている」で、これは情報システム部の仕事でした。4月に相談に行くと、年度の変更管理の枠はもう埋まっていて、早くても半年先だと言われます(第16回)。

     他部署に依存するコマのリードタイムは、自分たちの見積もりの外にあります。 相手の年度計画、変更管理の枠、稟議。どれも、こちらの都合では動きません。別のWGの主査は、同じ相談を1月のうちに済ませていました。

     手当ては2つです。ひとつは、直近6か月のコマのうち自部署だけで日程を決めることができないものに印を付け、いちばん早いもの1つだけでよいので、今月のうちに一度当たっておくこと。もうひとつは、断られたときの代替を先に考えておくことです。田口さんの手帳には「ダメなら先行3チームだけ別の表で」と書いてありました。

    3-3. 広げ方には、順番がある

     先行3チーム、次に7チーム、3年目に14チーム。この並びは、順番待ちの列ではないのです。新しいやり方が組織に広がるときは、まず少数が採り、そこで起きたことを見て次の層が動く、という見方があります。エベレット・ロジャーズは、採り手を早い順に5つ(革新者、初期採用者、前期多数派、後期多数派、遅滞者)に分けました(第8回)。

     1年目の先行3チームがやるのは、2年目に使う材料を作ることです。 うまくいった話も、やってみて駄目だった話も、両方が材料になります。だから先行の選び方は、やる気のあるチームではなく、差し戻しが多かったところから選ぶほうが筋が通ります(第16回)。

     打ち手の段を「学ぶ・試す・入れる・広げる・戻す」の5つに分けたのも、同じ理由です(第8回)。落としやすいのは「入れる」と「戻す」で、どちらも自分たちの活動の外側に働きかける段です。学ぶと試すはWGの中で完結しますが、入れるには現場の協力が要る。勉強会で終わった計画は、たいてい「入れる」が無い計画です。

    4. アジャイルの道具と、重なるところ

     ここまでの順番に見覚えがある方もいると思います。アジャイル開発の道具立てには、骨組みの共通したものがいくつもあります。読み手が開発の現場にいるなら、ここはそのまま社内の言葉として使うことができます。

     用語は、スクラムガイド2020の定義のまま使います。インクリメントだけ先に書いておくと、「プロダクトゴールに向けた具体的な踏み石」で、完成の定義を満たさないものはインクリメントと見なされません。

    4-1. 言葉の対応

     スクラムガイド(2020年11月版)は、プロダクトゴールを「プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる」と定義しています。そして「プロダクトバックログの残りの部分は、プロダクトゴールを達成する『何か(what)』を定義するものである」と続きます(スクラムガイド2020)。将来の状態が先にあって、やることの一覧はそこから導かれる。 問い1と問い2(やることの一覧を、3年後の状態に書き直す)でやったことと、順番が重なります。

     Gojko Adzic, Impact Mapping(2012年)の図も、中心にゴール(なぜ)を置きます。そこから、アクター(誰が)、インパクト(振る舞いがどう変わるか)、成果物(何を作るか)の順に外へ広がります(impactmapping.org)。作るものは、いちばん外側です。打ち手を先に並べてから理由を足した紙が通りにくいのは、この向きが逆になっているからです。

     『アジャイルサムライ』(オーム社、2011年)のインセプションデッキも、1問目が「我々はなぜここにいるのか」。詳細な計画より先に、完成したときの姿を言葉にします。4問目の「やらないことリスト」は、効かない打ち手を落とす作業と同じ役割です。

     対応を一覧にしたのが図表6です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_6_アジャイルの道具との対応

    4-2. 区切りが、入れ子になっている

     田口さんの紙には、長さの違う区切りが3つ入っています。3年(行き先は動かさない)、3か月(見直して組み直す)、2週間(コマの終わりに現物を出す)。アジャイル開発では、こうした決まった長さの区切りをタイムボックスと呼びます。上の区切りほど動かさず、下の区切りほど頻繁に引き直す。 これが、紙を3年もたせるための仕掛けです。

     スクラムガイドは「一貫性を保つため、スプリントは1か月以内の決まった長さとする」としています。2週間のコマは、見た目こそスプリントに似ていますが、別のものです。似せに行くほど、違いのほうが見えてきます。 違いを5つ挙げます。

    1. 検査と適応の場が無い … スプリントには、終わりにスプリントレビュー(「スプリントの成果を検査し、今後の適応を決定する」)とスプリントレトロスペクティブ(「品質と効果を高める方法を計画する」)が必ず付きます。WGの2週間のコマには、その場が定義されていません。見直しは3か月ごとです。この連載の背骨が「終わりに出来たものを出して意見をもらう」である以上、ここがいちばん大きな違いです

    2. 専任ではない … スプリントは、その期間チームが当該プロダクトに向かう前提で組まれます。WGは全員が兼務で、週4時間です(第13回)。同じ2週間でも、入る量が桁で違います

    3. 誰が計画するか … スプリントプランニングは「スクラムチーム全体の共同作業によって作成される」もので、開発者はプロダクトオーナーとの話し合いを通じてアイテムを選び、やり方を決めます。WGのコマは、主査が担当と割り付けを先に作って渡しました(第14回)。立ち上げの時期だからこの形ですが、回り始めたらメンバー側へ寄せていくのが筋です

    4. 役割が置かれていない … スクラムにはプロダクトオーナー、スクラムマスター、開発者の3つの責任があります。WGにいるのは主査1人です。推進役を2人にする話は第13回で触れましたが、役割を分ける設計まではしていません

    5. 出てくるものの性質が違う … インクリメントは、完成の定義を満たして使える状態になったものです(スプリント中に複数作られることも、終わりを待たずに届けられることもあります)。コマの終わりに出るのは、手順書だったり、集めた事例だったり、設定だったりします。使ってもらえる形まで届いているかは、コマによって違います

     5つを一覧にしたのが図表7です。

    画像
    図表_初めてのロードマップづくり_まとめ後編_7_スプリントとの違い

     借りたのは、期間を先に区切って、終わりに出来たものを出して確かめるという骨組みだけです。そこから先は、別の道具だと思っておいたほうが安全です。

    4-3. 「完了の判定」は、完成の定義ではなく受入基準に近い

     第10回で部長が聞いたのは、「終わったかどうか、誰が判定できます?」でした。これをスクラムの言葉に置き換えるとき、完成の定義(Definition of Done)に当てるのは、少しずれます。

     田口さんが置いた完了の判定は、コマごとに別々でした。第1コマは「WG内で読み合わせ済み」、第2コマは「実際に1件入力できたこと」、第5コマは「先行1チームが自分の開発で書けたこと」(第10回)。アイテムごとに条件が変わるので、これは受入基準(Acceptance Criteria)に当たります。 完成の定義のほうは「プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述」で、どのインクリメントにも一律にかかる下限です。アイテムごとには変わりません。性質が逆なので、名前を取り違えると、現場では話が通じなくなります。

     借りることができるのは、判定の基準を、作る前に文章にしておくという作法のほうです。これは、どちらの道具にも共通しています。

     開発の現場の言葉にすると、こうなります。

    • 「先行3チームの回帰テストが、毎晩自動で流れていて、朝に結果の一覧が出ている」 … 見れば分かります。年度の欄に書くのは、この形です

    • 「テスト自動化が導入されている」 … 導入の定義しだいで動きます。1本でも流れていれば導入なのか、全チームで回っていることなのか

    • 「品質への意識が高まっている」 … 時間を止めて見ても、成り立っているかどうか分かりません

    4-4. 「アジャイルだから計画は要らない」ではない

     スクラムガイドが求めているのは、プロダクトゴールを置くことです。ゴールを置かなくてよい、という話ではないわけです。

     一方で、直近は細かく、先は粗く、という粒度の付け方は、スクラムガイドには書かれていません。 2017年版には「上位のアイテムほど明確で詳細」という趣旨の記述がありましたが、2020年版では落ちています。2020年版のリファインメントは「プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動」までで、時間軸の話には踏み込んでいません。

     では、どこから来ている作法かというと、第10回で触れたローリングウェーブ計画法です。直近の作業だけを細かく分け、先の作業は粗いまま置いておく。アジャイル特有のものではなく、情報処理技術者試験のプロジェクトマネージャ試験にも出てきます。ロードマップで粒度を変えるときに後ろ盾になるのは、スクラムガイドではなく、こちらです。

    4-5. 準備期間そのものが、1回の反復だった

     部長がキックオフの最後に明かしたのは、この話でした。準備期間の3か月そのものが、ひとつのイテレーションとして回っていたのです。行き先を決め、期間を区切り、終わりに出来たものを出して、その場で意見をもらう。出たのは、ロードマップとメンバーとキックオフ資料の3つでした。

     ここが肝で、「準備」だけをして何も出さない期間にはしていません。出来たものが3つあるから、その場で意見がもらえて、次の3か月の中身が変わる。出来たものが出ない準備期間は、いくら区切っても、区切っただけになります。

     開発の現場で説明するなら、ここは追い風です。プロダクトゴール、バックログ、受入基準、タイムボックス、インクリメント。この語彙はすでに通じます。新しい方法を輸入するのではなく、いま使えている道具の適用範囲を、プロダクトから部の計画へ広げるだけだと説明すると、周囲の反応が変わります。この言い換えは、私の経験ではよく通ります。

    5. 任せる側の技術

     ここまでは、紙を作る側の道具でした。最後に、任せる側の道具を2つだけ。前編4章・5章で部長と中村さんが何をしていたかは書きましたが、それが何という道具だったのかは書いていません。

    5-1. 任命で渡す5つは、プロジェクト憲章にあたる

     部長が主査に渡したのは、何を作るか、どこまで決めてよいか、時間をどう確保するか、いつ誰に見せるか、困ったときの行き先。この5つです。この5つをひとつの文書にまとめたものが、プロジェクト憲章と呼ばれるものです。 JIS Q 21500:2018 では、その作成の目的として最初に「プロジェクト又は新規のプロジェクトフェーズを正式に許可する」ことが挙げられています(JIS Q 21500:2018 プロジェクトマネジメントの手引 4.3.2)。

     ここから2つ出てきます。

     ひとつ。許可は、本人に届いてはじめて許可になります。 名簿が上長の承認を通っただけでは、本人のところには何も届いていません。だから第13回では、内々の打診、任命、上長への話、本人への連絡、説明会、という5つの段を飛ばさないことになりました。

     ふたつ。同じ文書が、WGの中にも要ります。 主査が渡す1枚が、部長の1枚の下にぶら下がる形です(第14回)。ただし原資が違うので、中身は書き換わります。時間は「上長と詰めた範囲まで」、困ったときの行き先は「まず主査、そこで決まらなければ部長」。枠はそのまま、中身は書き換える。 文書の名前は要りません。A4で1枚、5つの見出しがあれば足ります。

     渡されなかった側から見ると、これは聞きに行くための持ち物の一覧になります。5つとも、聞けば答えが返ってくる質問です。「決めていない」と言われたら、それは「自分で決めてよい」という答えです(第2回)。

    5-2. 聞き手を数えてから、場を設計する

     キックオフの発表は、進捗報告とは別物でした。違いは、聞き手の範囲です。立ち上げの場に来るのは、WGのメンバーだけとは限りません。人数でいちばん多いのは、プロジェクトの外にいる部員です(第15回)。

     聞き手を数えると、10分の配分が決まります。 5種類の聞き手がいて、それぞれ要るものが違う。すでに2回説明したWGのメンバーには確認で足ります。これから協力をお願いするチームには、なぜそのチームが先なのかの説明が要ります。上の役職には、部の何に効くのか、どれだけの投資か、いつ確かめることができるか、の3つです。

     そのうえで、持ち帰ってもらうことをひとつだけ決める。 10分で全部は伝わりません。残りは、壇上で話すもの、付録に回すもの、その場では決めないものに分けます。公開の場で取った「はい」は、断りにくい場で取った返事なので、あとで動きません。依頼には受け皿を付けて、誰にいつ返すのかまで決めておく。

     この2つは、ロードマップの技術とは別物です。紙が出来たあとに要る、別の技能です。 田口さんが3月に一度ずつ転んだのも、ここでした。

    6. 書かなかったこと

     この連載で扱わなかったものを、短く挙げておきます。どれも実務では出てきます。

     「走り出したあとの運営」(4月1日で終わっているので、回してみてどうなるかは別の話です)。「複数WGの調整」(他WGとの連携の行は第10回で足し、メンバーの分け方は第13回で相談しましたが、重複と依存を調整する場そのものは扱っていません)。「予算の取り方」。「効果の測り方の精度」。「主査や部長が代わったときの引き継ぎ」。「協力が得られないとき」(この連載では、関わる人が最後まで協力的です)。「3年後に届かなかったとき」。

     残りの3つ、「WGとしてのMVVの作り方」「効果検証の設計」「活動を支える基盤」(置き場所、版の管理、改訂の手順、現場への届け方)は、第16回で田口さんが「自分には無かったもの」として見つけたものです。どれも、それぞれ一本になります。

     テストプロセスを外から見るモデルにも触れていません。TMMi、TPI NEXT、CMMI。見るべき項目の一覧としてよく出来ていますが、初めての一枚では要りません。2周目、3周目で、見落としの点検に使うものです。

     それでも、順番だけは持ち帰っていただけたらと思います。先に行き先、あとから手段。 ロードマップでも、メンバー選びでも、発表の組み立てでも、効いたのは同じ順番でした。

    7. 参考にした本と資料

     主なものを挙げます。各回の本文にも、その回で使った出典を書いてあります。この連載は、どれも使い方をひとつだけ借りた形です。 実務で使う段になったら、原典に当たってください。

    7-1. バックキャスティング

    • John B. Robinson, "Energy backcasting: A proposed method of policy analysis", Energy Policy Vol.10 No.4, 1982, pp.337-344珏3回。書誌はRePEc)

     借りたのは、先に終わりの姿を決めて、そこから逆に並べるという向きだけです。

    7-2. ロードマップの層

     前編3章の3段は、この考え方をWGの紙に引き直したものです。

    7-3. AsIs/ToBe/ギャップの並び

     上の階層に説明するとき、この並びは後ろ盾になります。

    7-4. プロジェクトマネジメントの規格

     任命で渡す5つをひとつの文書にまとめたものが、4.3.2 のプロジェクト憲章にあたります。その目的の最初に挙がっているのが「プロジェクト又は新規のプロジェクトフェーズを正式に許可する」こと。許可は、本人に届いてはじめて許可になります。 名簿が通っただけでは、本人のところには何も届いていません。第3回で触れたWBSの定義も、同じ規格にあります。

    • ローリングウェーブ計画法(第10回。情報処理技術者試験 プロジェクトマネージャ試験 嚳成29年春期 午前Ⅱ 問4。問題冊子、解答例)

     直近を細かく、先は粗く置いておく進め方の名前です。上の階層に説明するときに使うことができます。

    7-5. 改善の回し方

     3か月ごとに確かめて組み直す、という回し方の出どころです。CheckではなくStudyである、という読み方をしました。

    7-6. 目標の置き方

     3年後の欄を高く置くことの根拠です。研究が言っているのは努力と成果の水準が上がるということで、高く書けば必ず届くという話ではありません。7割という目安は、OKRの運用から来ています。

    7-7. 新しいやり方の広がり方

    • Everett M. Rogers, Diffusion of Innovations, Fifth Edition, Simon and Schuster, 2003(初版1962年。経緯はDiffusion of innovations。第8回)

     先行3チーム、次に7チーム、3年目に14チームという並びは、この見方を借りています。順番待ちの列ではなく、広がり方の順です。

    7-8. 品質コストの区分

     手戻りの工数をどの区分で数えるかに使いました。予防・評価・失敗(内部・外部)の4区分です。

    7-9. 5Sと3M

     この連載の出発点です。整理・整頓は環境美化ではなく、探す時間と聞き直す時間を減らす技術として扱いました。

    7-10. アジャイル開発の道具

     4章の対応表の出どころです。借りたのは、将来の状態を先に決めて、やることはそこから導くという順番です。

    7-11. テストプロセスを外から見るモデル

     書誌です。使いどころは6章にあります。

    7-12. ゆとり

     浮いた時間の使い道を先に決めておく、という読み方で使いました。決めておかないと、その時間は次の案件に吸われます。

    8. おわりに

     この連載で書いたのは、3年のロードマップを初めて作る人が、3か月で何を手に入れるかでした。田口さんは毎週持っていって、毎週書き直しました。7回の金曜を重ねて、12月には持っていなかったものが手元に残りました。

     最初にやることは、3年後に自分たちがどうなっていたら嬉しいかを、3行から5行くらい書いてみることだと思います。残業が消えているのか。夜と休日が自分のものになっているのか。新しいことに手が出せているのか。やらされ仕事ではなくなっているのか。裏付けの行は、そのあとで足すことができます。

     書けたら、誰かに見せに行ってください。行き先は一人で書く。現状と手段は、聞きながら作る。 戻ってきた問いが、次に紙へ足すものを教えてくれます。

     ロードマップは、作った直後がいちばん立派に見えます。実際に効いてくるのは、2年目の秋に「あの順番で正しかった」と分かる瞬間です。逆算でその瞬間を手前に引き寄せることができたら、この連載の役目は果たせます。

     みなさんのWGが描く3年後が、今より嬉しい世界でありますように。

     扉記事に戻ると、全16回の一覧があります。


    #ロードマップ #バックキャスティング #ギャップ分析 #プロセス改善 #アジャイル開発 #組織開発 #IT企業


    本記事をお読みいただくにあたって

    • 出典について 統計・研究・法令につきましては、一次情報で確認のうえ、出典のリンクを本文中に記載しております。ただし、誤りの可能性を完全に排除することはできません。お使いになる際は、リンク先の原典をご確認ください

    • 観察と事実の区別について 現場の事例および見立ては、筆者の観察によるものであり、統計ではありません。また、特に明示していない限り、特定の企業・個人を指すものではありません

    • 執筆・調査時点について これらを確認したのは、記事公開の時点です。統計は更新され、法令は改正されますので、現時点の内容とは異なる場合があります

    • 生成AIの利用について 本記事は、調査および推敲、図表作成に生成AIを利用しております

    • 商標について 本文中に記載されている会社名、製品名、サービス名等は、一般に各社の商標または登録商標です。なお、本文中では ™ および ÂŽ の表示を省略しております

    • 見解について 本記事の内容は筆者個人の見解であり、筆者が所属または関与する団体・企業の見解を代表するものではありません

    • 免責 本記事は、筆者の調査および考察に基づく情報提供を目的としたものです。ご利用にあたっての最終的なご判断は、お読みいただく方ご自身でお願いいたします。本記事の情報を利用されたことにより生じた損害等について、筆者は責任を負いかねますので、あらかじめご了承ください

     
    クオリティアーツ代表としてソフトウェア工学全般,特にQA分野の伴走支援しています. ソフトウェアテストや品質保証だいすき.ミュージカルやゴルフもだいすき. ※記事はすべて個人の立場での発信です