「自転車置き場議論」発生のメカニズムと有益な議論の作り方について
「自転車置き場議論」というのをご存知でしょうか。
「くだらないこと議論しているね」というニュアンスで「それは自転車置き場の議論だよね」という言葉を聞いたことはある人もいると思います。
ではなぜ「自転車置き場」なのでしょう？
これはもう少し詳しく説明すると、「自転車置き場」という言葉は「パーキンソンの凡俗法則」から来ています
この法則の論旨は「重要な問題(原発問題)」は議論されず、「些末な問題(自転車置き場の屋根)だけが熱心に議論される」ことを問題視しています。
では、この現象を起こさないようにするにはどうするか、を私は注意しました。
上の法則によれば「人は自分が理解出来る議論に加入し、自分が理解できない議論に加入しない」という問題があります。
そこで、上の法則が起きる原因は「議論すべき重要な問題が、理解できず、十分な議論がなされない」ことというように読み取れます。
なので、マネージャーがすべきことは「議論すべき重要な議論を、参加者が理解出来るよう下地を整える」ことだと私は結論しました。
参加者は議論が理解できない、とはなぜ理解できないのでしょう？
問題が２つあると私は考えます。
「問題が大きすぎる」：原発問題のどこを話し合えばいいのかわからない。
「背景情報がない」：議論に使う背景の情報や数字がない。そのためふわふわした空中戦以上のことができない。
そこで問題をこのように解決しました。
「問題を分割する」：「原発問題」を「原発の費用対効果の問題」と「原発の安全性検証とリスク対策の問題」と「社会のためにコストを押し付けられる現地への利益再分配の問題」に分割します。このレベルなら検証するための数字を用意できそうな気がしてきました。
「背景情報を用意する」：話し合うべきトピックの背景情報を同時に用意します。大きな長所、トレードオフと考えられる要素、懸念すべき要素、それぞれを準備します。
これで、「議論すべき問題」が「参加者に理解出来る問題」となり、議論可能になりました。
会議のホストの役割として、「議題を定め、議論を行うために議題の論点の分解と数字の用意を行う」ことが必須だと私は考えます。
１５ポイントルール
最近チームが改組されました。
メンバーも入れ替わりました。
さて、私はイテレーションの最後に、常にふりかえりを行っています。
目的はいくつかあります。
・成功を再現するため
・失敗を再現しないため。
・開発を改善するため(スクラムにおける適応)
・われわれのプロダクトやリリースが市場にどのような変化を与えたかをフィードバックするため(スクラムにおける検査)
・チームで持つべき情報が何かを判断するため(スクラムにおける透明性)
ところが新しいチームのメンバーはこの行為に意義を見出しづらい人が多かったように思います。
「なぜそんなことをしないといけないんです？」
「いまでもプロダクトは十分成功しているでしょう？」
「今までのやり方でいいじゃないですか。なぜ不要な苦労をしてまで新しいことをしないといけないんです？」
振り返りの意義をメンバーに浸透させたいと思いました。
そこでふりかえりに１５ポイントルールというものを追加しました。
チームのヴェロシティが現在２００ポイント弱程度あります。
「もし、新たに１５ポイント使えるとすれば、何に使うか」
を各人が３分で発表します。
プロダクトバックログアイテムの特定のアイテムの消化に当ててもよいですし、CIシステムの改善をしてもよいです。ベータテストやその評価をする提案もありです。
最初は、振り返りによって開発が改善されれば１５ポイントが仮定ではなく実際に使える、という点を意識させることで振り返りの意義を定着させる目的で始めました。
たしかに振り返りの意義は定着しました。
しかし運用してみると、異なる効果も得られました。
[メンバーのマネージメント力が分かる、上がる]
自分一人で情報を取得し、次はどれをやるか？を判断する訓練を行う必要があります。そこで以下の成果が得られました。
「メンバーの全体の見わたし力が分かるので、各人のマネージメント力の成熟度合いがわかる。」
「メンバーのマネージメント力が上がるので私のチームのマネージメント負荷が大きく提言された。」
[メンバーの興味関心の方向がわかる]
メンバーが提案するのは自分が興味あるトピックであるケースが多いです。なので、提案した人間にそのカテゴリのタスクのエキスパートと判断できます。突発タスクでも、誰に任せるべきか、という判断で迷いません。
メンバーの提案が一方向に集中している場合は、より優先すべきタスクがほかのものによってブロックされているケースが多いです。バックログの見直しが必要な兆候です。
メンバーの提案が二方向に分かれている場合は、どちらを優先すべきかをプロダクトマネージャーが決断すべき兆候です。
メンバーの提案が四分五裂に見える場合は、プロダクトの検査や適応、あるいはビジョンがメンバーに浸透しておらず「何をすべきか」がメンバーに明示されていない状態です。あらためてプロダクトマネージャーとメンバーが同期すべき兆候です。
メンバーのモチベーションとスキルが上がるとプロダクトマネージャーの負荷を上げずともヴェロシティは上を向きます。
１５ポイントルールはチームのメンテナンスプラクティスの１つとして現在有効に機能しています。
「競合」となにか
リーン・キャンバスを書くときに競合という項目があると思うのだけれどそれについて書きます。
会社に不満があるなら社長にプレゼンすべき #BLOGOS http://blogos.com/outline/160371/
記事の内容の引用ですが
自分が一番注目したのが、「車を購入したときにほかのなにと比較したか」という項目なのであった。その関連項目を読み込んでいき、生の調査データも紐解くと、びっくりする事実が浮かんできました。ひとことでいうと新車と中古車のユーザーはほとんど別モンだったのであります。
この部分。
ユーザーにとっての「競合」とはなにか。が大変重要な部分であります。
だいたい２年くらいパッとしないベンチャーのお話などを聞かせていただきますと、この競合がふわふわしていたり、あるいは私の目からもわかるくらい読み違えているケースが多いです。
２０万円の時計を買う層にとって「２０万円の時計」と競合するプロダクトとはカシオの時計ではないのです。
宝石やブランドバッグなどです。なぜなら、「２０万円の時計」は見せびらかすものであって、時間を見るものではないから。
競合を読み間違えているケースとしては実際にはコンビニが競合であるのに
「スーパーマーケットを競合だと理解しているケース」や、「コンビニの機能を自販機程度だと理解し、自販機を再実装するケース。(当然ユーザーは必要な品質が得られないので見向きもしない)」などがありました。
アウトラインという設計前工程について
我々のチームにおいて、アウトラインという工程を作っています。
ビジョンを固めた。次の大きなリリースブロックの方向性はこんな感じだ。ターゲットのポートフォリオはこんな感じ、という方針策定のところまで定めた時に設計＆実装以降の工程との乖離が大きいことを問題視してこの工程は作られました。
企画やグランドデザイナーは設計＆実装工程には加わらないが、ここで離れられるとどうしても設計＆実装でズレが出てきます。
方針策定の粒度が粗いのではないか、というのが我々がたてた仮説です。
そこで方針策定と設計＆実装工程のギャップを埋めるためにアウトラインというフェーズを定義しました。
ペーパープロトタイプやモック、プレイアブルデモなどで「今回の狙い」を共有する工程です。
アウトライン工程の導入により、実装後のデモレビューからの手直しの量が３０％程度減りました。また、デモ段階で「定義」で揉める、本来でもレビューフェーズに含めるべきではない要素のレビュー行為が大きく減りました。
ここで大事なのは設計＆実装においてアウトラインの成果物は上書きされがちです。
未知の要素や、作ってみてわかった改善のフィードバックなどがあるからです。
アウトラインの上書きは好ましいものとして上書きを是認してます。
アウトラインは「守るもの」というよりは本体の製造コストの5%程度で作れる軽量なプロトタイプという認識で作った方がいいと思いました。
