「アジャイル導入」や「プラクティス導入」といった大きい一歩を踏み出してうまくいかないと嘆くあなたに送るたったひとつのアドバイス

ついついフレームワークとかプラクティスとかパターンとか世に溢れているものをそのままヤりたくなりがちな皆さんへ

Takeshi Kakeda

·

Follow

Published in

kkd’s-remarks

·

8 min read

·

Feb 16, 2018

--

Share

はじめに

この記事は一年くらい前に書きかけて放置していたのだけど、市谷さんが同じようなことを言ってるスライドをアップしていたので、二の矢として挙げることにする。

プラクティス導入がうまくいかない！！

これまでも多くの人がそうだったし、これからもきっと多くの人が同じような状況に陥ると思われるのでメモしておく。

「現場でXXXを実施してみているのだがうまくいかない」という話は、色々なところで耳にする。XXXXはプラクティスでもいいし、スクラムでもいいし、ツールの導入でもいい。

例えば、プラクティスというのは、名前がついていて、各所で実践した例もいろいろあって、希望に満ち溢れているようにみえる。なので、ついつい手にとって試してみたくなる。TDD、ペアプロ、リファクタリング、カンバン、あー、たまらない！早くヤリたい！試してみたい！！

しかし、ぐっとこらえて、考えてほしい。

あなたが、その「キラキラ」したプラクティスの裏に何をみているのかを。どんな課題を解決したいのだろう？今をどんな状況に変えたいのだろう？

そして考えてほしい。

今の現場でそのまま試して大丈夫なのかを。反対しそうな人はいる？周囲の人はなんて反応しそう？そのまま始めたら真っ先にぶつかりそうな課題ってなんだろう？

プラクティスは「大きい」

気をつけないといけないのは、プラクティスっていうものは往々にして大きいということ。言い換えると、プラクティスの中に幾つもの要素や前提が含まれている場合が多いということ。

例えば、「タスクボード」（カンバンじゃないよ）を始めたいと思ったとする。しかしこれは言うほど簡単ではない場合が多い。

• 個人がある程度の粒度（２時間程度くらい）のタスクに分解できること
• （有効に活用するためには）チームとしてタスクをやりとり・交換できる程度に仕事を共有・分担できていること
• 貼り出す壁（ないしはスペース）があること
• 張り出しても怒られない環境であること
• チームの仕事のリズムが存在する（週単位の計画づくりなど）こと

などなど

テスト駆動開発（TDD）なんかも、同様に含まれる（求められる）要素が多すぎる。

• 自分のタスクのゴールを明確にできること
• プログラミングを細かいタスクに分解できること
• プログラミング設計ができること
• テスティングツールを使えること
• 自動テストを書けること
• リファクタリングができること
• etc

一言で言ってしまうと、いきなり「巷に溢れるプラクティスをはじめる」のは一歩として大きすぎることが多いということだ。

これを深く考えずに、始めるとどういうことになるか？…当然うまくいかない可能性が高い。

プロダクトを成長させるように小さく刻む

とりあえず試してみて「うまくいかないなー。本は教科書だから役に立たないなぁ。他の所はどうしてるのかなー」という事例マンセー君にならないために、次を意識するといいだろう（必ずしも順番に拘る必要はない）。

1. なぜ自分がそのプラクティスを始めたいのかを自問しよう
2. プラクティスによって何を得たいのか、何を解決したいのかを考えよう
3. 期待する結果を仮説としよう
4. 言語化して他人に説明できるようにしよう
5. 今の状況をよく観察してみよう
6. プラクティスをより小さいステップに分解してみよう
7. 自分の現場ではどのように進めればいいかをシミュレーションしよう
8. 一番やりやすいステップから始めよう
9. 少しづつやれることを増やしていこう
10. 試した結果に向き合い、当初の期待通りか評価しよう
11. １に立ち戻りつつ、フィードバックループを回そう

エマーソン・ミルズ氏の戦略の例

プラクティスを小さく刻む例で、特に印象に残っているのは、日本の初期のスクラムコミュニティに貢献していたエマーソン・ミルズ氏の話だ。１０年以上前に聞いた話なので記憶が正確ではないかもしれないが、氏が発表していた内容がとても印象に残っているのでここに紹介する。

当時、氏が働いていた職場（某日本のメーカー企業）でタスクボード（スクラムボード）やスプリント計画づくりをはじめる前段として何をしたかと言うと、まず自分ひとりで週のタスクを洗い出すところから始めたそうだ。もちろんこの時点でチームとして始めようということは一切口にしていない。

次に、彼は自分の洗い出したタスクリストを、他のメンバーの所に持っていって「タスクを洗い出してみたんだけど、ちょっとレビューしてもらえないか」と頼んだそうだ。これを行うことによって、自分が挙げてみたタスクを他人にチェックしてもらうことがとても効果的である、ということを、レビューしてもらった当人だけでなく、フィードバックを与えた側にも気づかせることができた、ということだ。

次の段階には、「皆でタスクの洗い出しをして、その結果を相互レビューしませんか？」と提案したそうだ。そして、それが全員が同じ場所でタスクを洗い出すようになり、最終型としてはスプリント計画ミーティングやタスクボードへと進化した、という内容を話していたと記憶している。

道は一つじゃない、正解もない

「スクラム」や「XP」という方法論・フレームワークの単位は当然として、プラクティスという単位でも、それまで試したことのない現場では、一歩の歩幅としては大きすぎる場合がある。その時は「早くヤりたい！」と焦らずに、ちょっとだけ立ち止まって考えるといい。

アジャイルな開発を進めるのと同じように、事前に完璧目指した綿密な計画を立てるのではなく、さりとて、何も考えずに無謀に突っ込むのでもなく、大事な点は押さえ、リスクは洗い出し、あとは走りながら修正していくのが肝要だ。

アジャイル開発で、いきなり大きなユーザーストーリーを作ろうとしても失敗する確率が高い。同じように大きすぎるプラクティスも失敗する可能性が高い。ユーザーストーリーをスライスするように、プラクティスもスライスするんだ。もっと正確に言うと、プラクティスによって実現したいゴールを目指して、刻みながら一歩一歩進むんだ。

向かいたいゴールに対して、何を最初の一歩とすればよいのだろう？そのためには、自分の周りをしっかりと見えていないといけない。目をつむって一歩踏み出すって怖いでしょう？

「何かを変えたい」「何かをやりたい」にばかり着目していると、「今自分がどこにいるのか」を失ってしまう。まずは「今自分はどんな状況の中にいるのか？」「何が問題で、何が制約なのか？」「そもそも自分はなぜそうしたいのか？」という現在地点（＝周囲の状況・自分の意志）を意識的に確認しよう。

今どこにいるか・どんな状況か、これからどこに向かいたいかの両方が分かって初めて、目的の方向に向かうことができる。もしも、今の状況を把握するのが困難であれば、少しづつ確認しながら進むしかない。

もちろん、チームに「ペアプロやろうぜ」と提案して、いきなりやってみるのもありだろう。チームで試行錯誤しながら、あるプラクティスを試して合わない部分を修正しながら馴染ませていくのもひとつの醍醐味だ。ただ、その時にもチームとして合意するために「なぜ」は明確でないとならないだろう。

同じように「スクラム始めるぜ！」とガラッとやり方を一気に変えることも場合としてあり得るだろう。しかし、それだけがやり方ではないし、むしろアジャイルとは逆のやり方かもしれないことを留意しておいてほしい。

一言でまとめてしまうと、アジャイル（プラクティス）の導入も、状況に合わせてアジャイルに行うということだ。

変化は小さければ小さいほどいい。誰も痛みを感じずに、気づいたらいつのまにか全体がガラッと変わっていた、というのが理想かつ最高だ。一言で言ってしまうとベイビーステップですけどね（書いてしまうと普通過ぎる。。。）。

山に登るルートはひとつじゃない。ルート自体に囚われることなく、うまく登頂できそうな道を選ぼう。そのためには、向かいたい「山頂」がどこにあるのかをまず見極めよう。もしかすると、その時点では山頂ははっきり見えないかもしれない。でも、山頂のある方向は見据えていこう。一歩一歩足元に集中して歩を進めていくうちに、段々と山頂が見えてくるはずだ。そして山頂にたどり着いたかと思うと、すぐ次に新たな山頂が目に入るはずだ。

皆さんの現場の登るべき山と、その山頂、そしてよりよい登頂ルートが見つかり、頂まで登れますように。