ウチのチームがモブってるとき
はじめに
このブログは、モブプログラミング Advent Calendar 2018の3日目の記事です。
前日のエントリーは @mohiraさんの、「モブプロで技術書を攻略する!」でした。今日の話はベーシックに、自分の周りのモブプロ事情の話をします。
モブをやるときに悩んだこと
モブプロに可能性を感じて、導入するときにうまくいかなかった理、悩んだことがここまで多々あります。それは、既にTAKAKING22さんが初日のエントリーで言及していたこれにハマっていました。
大きな誤解の一つとして、多くの方が分担作業とモブワークを二者択一のように考えがちです。私達も1日中モブワークをしていますが、正確には仕事の質や状況に合わせて分担作業とモブワークを切り替えながら仕事をしています。
というわけで、ウチのチームでよくモブになってる状況、仕事をまとめてみます。
ウチでよくモブってるとき
障害対応
頻度は少ないですが、一番自然にモブになってます。場合によっては部署や組織を跨いで、壁一面のホワイトボードで状況確認したり、その中で必要に応じてソロワークして同期したり、といったこともします。
手戻りがあったとき
これはここ1年くらいで増えたケース、最初はリーンソフトウェア開発のラインストップを参考にしつつ、手戻り(例えば開発テスト中にバグが見つかった!みたいなとき)に必ず声をかけて集まるようにしていました。それまでは、何かバグが見つかると担当チーム間をそれぞれ引き渡して対応していたのですが、そうすると情報の連携不足や元々の知識・経験の違いなどがあって解決までにかなり時間を要していたのですが、それがググッと縮まりました。今では重大な手戻りなどがあった際に自然にモブになっているような状態になっています。
要件・案件の理解をしているとき
いわゆる要件定義のタイミング、案件を知るときに、全員で説明を聞き、質問をし、議論をします。一人だと観点として落としてしまうようなことをなるべくなくすためこの形です。この後の実際にコードを書いたりテスト設計したりするタイミングでは、ここで同期とった内容を元にソロワークで分担することもあります。
設計してるとき
設計もモブでやります。厳密には設計の場合はチーム全員ではなく、2人以上のユニットを組んで実施して、あとでチーム全員でレビューしたりもします。レビューするなら全員で設計したらいいのでは?と思われるかもしれませんが、ウチのチームでは「モード」を重視してこの形になっています(「設計者モブ」になっている時は気がつかないことも、「レビュアーモブ」になると気づいたりします。この差が「モードの違い」だと捉えています。)
困ったとき
何か自分で困った時、つまづいたとき、相談したい時、ねぇねぇと相談してからのペアプロ、モブプロに発展することがあります。(必ずというわけではない)
まとめに代えて
ここまで、ウチのチームがモブってる時をピックアップしてご紹介しました。
大事だな、と思っているのは、必ずXXしなければいけない、なんてことはないということです。今のやり方うまくいってる、効率的だ、うまくいっていない、非効率だ、というのは実際手を動かしているチームが一番肌で感じられると思います。やっていて違和感がないことを大事にしながら、これからも適材適所でモブっていきたいと思っています。
【翻訳】ストーリーポイントを使うのをやめよう
はじめに
このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。
誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。
ユーザーストーリーを使うのをやめよう
ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。
おそらくNoでしょう。
ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリティをそこない、プロセスの消化不良を引き起こしてしまう不自然な材料が含まれていることを知っています。
2007年に得た一連の経験で、ストーリポイントと、ベロシティ計算をやめることで、アジリティが高まることを同僚と私は経験しました。
同様の経験が、我々に固定した期間のスプリントからフローに基づくワークフローへの変更や、朝会から頻繁なチームのやりとりを行うプロセスへの変更をもたらしました。
我々の今日のプロセス*2は、我々のアクティビティはプロセスのムダと、より良い働き方を発見する経験に気を払うものでしたので、書籍に書いてあるようなものや、広く利用されているアジャイルの方法論とは異なるものでした。
このブログでは、我々がなぜストーリーポイントとベロシティ計算をやめ、それなしでどのように仕事を成功させられるかについて説明します。
ストーリーポイントを利用していた最初のころ
私がストーリーポイントを利用し始めたのは、サンフランシスコでのエクストリームプログラミングのチームで、1999年のことでした。
私はストーリーポイントがチームのキャパシティを明らかにするのを手助けることをとても気に入っていました。
ベロシティ(一定期間内に完了したストーリーポイントの数)として計算されたそのキャパシティは、チームにいる人(特にプロダクトマネージャー、プロダクトオーナー、あるいは内部の顧客)が、彼らの持ち物の中でどのくらい仕事をこなせるのかを理解する手助けをしました。
もしタイムボックス内の完了させるべき仕事がチームのベロシティと合わなくなる時があれば、それは絶対に必要なものとあると良いものを区別する重要な決定、考慮をするタイミングでした。
ストーリーポイントとベロシティは、本当に必要な機能を明らかにし、不要な(あるいはよく繰り返されてしまうマントラである『完了しない仕事を最大化してしまう』こと)ものを除去するのに役立ちました。
私はそれから8年にわたり、世界中の社内外のプロジェクトでストーリーポイントとベロシティを使っていました。
その間、沢山のストーリーポイントとベロシティへの誤解や誤用に気づきましました。
最初は、これらの問題は教育者としてよりよい仕事が求められているサインだと解釈しました。
しかし数年経つと、ストーリーポイントとベロシティの計算は重大な欠点を含んでいることが明らかになりました。
不合理なストーリーポイントのインフレ
もっとも大きな問題の一つは、フロリダ、タンパでの巨大有名企業で気がつきました。
我々がこの会社を知ったのは2002年のことでした。ディレクター(ジムとしましょう)がサンフランシスコにやってきてXPの集中ワークショップに参加した時のことです。
ジムはそこで体験したことを気に入り、すぐにフロリダのチームに持ち帰りたいと思いました。
我々はジムの会社で、2、3の部門を含む何百人もの人と4、5年にわたる付き合いがありました。
最初のチームでは、ジムは我々の準備、トレーニング、コーチングのサービスを含むアジャイル変革パッケージを購入しました。
彼は我々のアドバイスを取り入れ、25人のチームのために素晴らしいオープンスペースを用意しました(当時の基準からすれば大きなものでした)。
我々と一緒に働くのに先立って、彼はチームにPatrick Lencioniの5つのチームの機能不全*3、について学習して議論させていました。
暖かく良い日差しのタンパに着陸すると、我々は今まで経験したことのないもっとも準備の整ったチームの1つに会いました。
2年間を早送りすると、彼のチームはスケジュールを前倒して、素晴らしいソフトウェアを管理し、ボーナスを受け取り、親会社の権威あるプロセス改善の賞を勝ち取りました。
この会社を訪れた役員たちは、日常的にこのチームのオープンワークスペースを訪れ、彼らのプロセスを学んでいました。
我々はこのチームを誇りに思いました。しかし、彼らに起きつつあったことへの準備ができてはいませんでした。
2004年のある日、ジムはより早く進められるようチームを励ましました。
彼はスクラムに精通していないにもかかわらず、「スプリント」という用語を利用します。
このチームは、イテレーションごとに平均52ポイントのベロシティがありました。
彼らのベロシティは数ポイント上下することもありましたが、基本的には安定していました。
しかしジムがチームに「スプリント」という言葉を使った数週間後、チームのベロシティは80台に跳ね上がりました!
私は誰かに何が起きたのかを尋ねました。
彼女は笑いながら私を見て、「ここでは最近、あなたがくしゃみをするとストーリーポイントが得られるの」と言いました。
評価され、私と他のIndustrial Logicの二人のコーチにトレーニングとコーチを受けた成熟したアジャイルチームが、彼らが早く進んでいるように見せるために突然ストーリーポイントでの見積もりを膨らませてしまうことがあることにとても驚き、頭を振りました。
私のストーリーポイントとベロシティへの自信は、この経験のあと侵食され始めました。
あるいは、この問題は教育不足により引き起こされたものかもしれません。
そのため、2004年にストーリーポイントを捨てるのではなく、クライアント、特にマネージャーに対して、ストーリーポイントの誤用について教育を同僚と私はより力を入れて行うようになりました。
予測可能性のために品質を犠牲にする
TDDやリファクタリングのような技術的なプラクティスは、「見積もりをする」際に落とされる第一のものです。
我々は、トレーニングをする際、これらの行動が始めから出現するとわかっています。すなわち、全ての仕事をタイムボックス(2時間)で完了させるチームはしばしば品質を犠牲にしてこうするのです。
コミットメントを届けつつ、コード品質も向上するということがどういうことかを体験することを手助けすることを通じて、長年、この一般的な問題に取り組んできました。
素晴らしいチームが最終的にどのように技術的負債がない状態を維持し、一方で安定的なベロシティ(スプリントごとに同じ数のストーリーポイントを完了すること)を維持するについて、我々は説明しました。
しかし事実としては、そのようなチームは稀で、チームのサイズ変更や、その他のプレッシャーによって安定性も一瞬のものとなってしまいます。
とても長いあいだ、私は一定のベロシティを保持することが大事だと考えていました。なぜなら、計画時にいつプロダクトやシステムが完成するのかを予測するのを助けると考えていたためです。
しかし、バーンダウンチャートを良く見せたり、見積もりを作成したり超えたりするために、品質を犠牲にしたりただ技術的負債を積み上げるチームをいくつも見てきました。
ポイントでチームを比較する
長年にわたって、複数の会社のマネージャーがこう尋ねるのを聞いてきました。「Xチームは24ポイントをスプリントでDoneにできるのに、Yチームはたったの12ポイントしかDoneにできないのはなぜでしょうか? チームのサイズはほぼ同様なのに、この差はなぜできるのでしょうか?」
チーム特有のキャパシティのインジケーターとしてベロシティを利用するのではなく、これらのマネージャーはベロシティを成果を測定する(Jim Highsmithがベロシティがアジリティを殺す!*4と書いているように)のに利用するという思考の罠にはまっています。
ベロシティでチームを比較するなと我々が言うことはできますが、とても多くの人がこのような比較が正当だと考えてしまうことに本当の問題があります。
2005年前後から、私はこの問題に対し、ストーリーポイントの後に好きなフルーツ名をつけることで対処しようとしました。
あるチームはベロシティをオレンジで測定し、またあるチームはりんごで、あるいはキウイで、といった具合です。
そして、マネージメントの人がいつものようにベロシティでチームを比較しようとすると、「りんごとオレンジは比較できませんよ」と伝えていました。
このアプローチが、チームでベロシティを比較することを無実だ*5と明らかにしましたが、よりシンプルでミスのない方法論を見つけることはなく、ストーリーポイントの誤用を止めることにもっぱらつながりました。
ストーリーポイントの混乱:俺たちバカ?
多くのストーリーポイントの利用の正当化根拠は、人間は実際の時間での見積もりが得意ではない、というものです。
我々は仕事が終わるまでどれくらいかかるかを見積もっているのではなく、仕事の大きさを見積もっているので、ストーリーポイントは我々をよりよい見積もりをもたらしてくれると支持者は言います。
実際に、どんな尺度が利用されているかに関わらず、人間は一般に見積もりは得意ではありません。
後ほどお見せするように、チームがよい見積もりを得るのは、頻繁に見積もり直した時です。
ストーリーポイントは問題をさらに混乱させるだけです。
時間を使って見積もりをし(「いつ行く準備ができる?」とか「家に着くまでにどのくらいかかる?」といったような)て我々が成長したとしても、同じことはストーリーポイントには当てはまりません。
これらを利用するには、我々は下記について学ばなければなりません:
- それらは何か、
- どのように利用するか、
- 誤用しないようにするためのたくさんの方法
典型的なストーリーポイント教育の中には、かなりの摩擦を含んでいるでしょう。
新人は、ストーリーポイントと、それを毎回実際の時間に変換することに混乱し、やりづらさを感じるでしょう。
賢明なアジャイルのエキスパートは、全力で新人に教育します。
彼らはストーリーポイントがTシャツやフィボナッチ数列のようだと説明します。
2005年、我々の顧客の一人が、ストーリーポイントについてあまりに混乱し、NUTs(漠然とした時間のまとまり)と*6改名しました。
ストーリーポイントの誤解と誤用は、特にプロセスがチームから部署、企業へとスケールして行くときに、時間をかけて増幅されていきます。
これらの誤解と誤用を正すのは、時間と労力を要します。
ストーリーポイントとベロシティ計算は、アジャイルチームの初期で、彼らを不要に混乱させてしまう不自然なテクニックなのです。
忙しさ(Busy-Ness)会計学
先日、様々な完成の段階のある技術的なタスクでいっぱいの巨大カンバンボードのある会社を訪れました。
チームが価値あるユーザーストーリーに取り組んでいるかどうかは、その物理ボードからはわかりませんでした。
リリース計画への進捗もわからず、WEBベースのアジャイル計画ツールも、あまり役には立っていませんでした。
その代わりに、そのツールは綺麗なベロシティのチャートと、完了まで何時間必要なタスクかをレポートするものがありました。
多くのアジャイルショップは、忙しい仕事のトラッキングをするのに固執しているようです。
私の同僚Tim Ottingerは、それを「忙しさ(busy-ness)会計」と呼んでいます。
ユーザーストーリーをタスクに分解するのは、それを完了させるには何が必要かを理解するのには役立ちます。しかし、多くの時間をタスクの見積もりと、ボードやツールを利用してそれらのタスクをトラッキングすることはウォーターフォールの遺物で、多大な労力の無駄です。
アジャイルであるとは、素早く優雅に動くということです。
それは有用で、品質のあるソフトウェアを頻繁にリリースすることを意味します。
どのくらいの時間を技術的なタスクに費やしたかの忙しさ会計することを意味しません。
よりシンプルな道
2001年に、クライスラー総合補償システムプロジェクト(XPの発祥の地)で働いていた初期のエクストリームプログラマーである、ドン・ウェルズが言及していたシンプルな計画アプローチに衝撃を受けたことを思い出しました。
ドンはエクストリームプログラミングのメーリングリストからのこのメールで下記のように言及しました:
我々は完了した項目を数えています。毎週最も重要なアイテムを選んで、先週こなした数の分だけ印をつけます。見積もりに力をかけるか否かにかかわらず、先週とほぼ同じ数のアイテムができると判明しました。私たちは1週間イテレーションなので、イテレーションの計画ミーティングでブレイクダウンをします。
おそらく効果は、物事を正しいサイズに分割する方法を学んだことです。私はまだ分かっていませんが、我々は大体8個を毎週完了させられるというのがポイントです。見積もりは必要ありません。
その時は、私はドンのシンプルな計画のアプローチを試す準備ができていませんでしたが、よりシンプルなプランニング方法を求める気持ちを強くしました。
他の実験
2007年の春から、同僚と私は、ストーリーポイントとベロシティ計算に関連する、よりシンプルなソリューションを実験するための問題を十分に見ていました。
Industrial Logicでの我々の最初の実験はひどく失敗しました。
私たちはストーリーポイントの代わりに実際の時間をトラッキングしました。しかし私たちは何時間もストーリーポイントでやったのと同じことをやっていました。すなわち、見積もり時間と完了した時間、そして次の固定された長さのタイムボックスへの利用可能な時間をトラッキングすることです。
このプロジェクトは約6ヶ月間続き、プロジェクトの人々の半数以上が時間での見積もりを嫌っていると言っていました。
その夏私はワシントンDCで開催されたAgile2007会議に出席し、デイビッド・アンダーソンがオープンスペースでbirds-of-a-featherセッションでカンバンメソッドについて話しているのを聞きました。
デイビッドが述べたことをとても気に入っていて、私の会社のニーズと文化にフィットするプロセスを探し続けることにインスパイアされました。
2007年の秋、ストーリーポイントと時間の使用をやめ、私が「可変長イテレーション」と(当時)呼んでいた方法をスタートしました。
固定の長さのタイムボックスで作業することを無くし、私たちはただ行うべき重要な仕事を少し選び、完了させ、出荷する、というのを繰り返しました。
一般に、仕事を完了するまでに1日かかるか4日かかるかなどは気にしませんでした。
私たちは、固定されたタイムボックスで仕事をすることや、完成したストーリーポイントの数を追跡したりすることではなく、出荷することにフォーカスしていました。
新しいプロセスを利用して、平均で週に1〜2回出荷をしました。
我々のアジリティは、プロセスから一部神聖なものを除くことで増加しました。
アジャイルマニフェストの第一原則に則ってデリバーすることで、私たちはより良いものになりました。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
締め切りがある場合は、すべての仕事を完了するか、後のリリースまで安全に延期できる仕事を見つけるようにしていました。
我々のプランニングのセッションはとても短く、一貫したベロシティを維持したかではなく、貴重なソフトウェアを出荷したかどうかで自分たちを評価しました。
私が「可変長イテレーション」と呼んでいたものは、実際にはリーン開発のフローベースのワークフローに似ていることを知りました。
そしてリーンの用語を用いて、カロリーのないコーラのように、ストーリーポイントをムダと記述するようになりました。
直感
2008年、Industrial Logicはシリコンバレーのスタートアップ(現在はIBMが所有しています)に、社内の1つのチームがアジャイルになるように依頼を受けました。
私たちのコーチの1人は、そのチームと数週間働き、ストーリーポイントの利用を含む伝統的なアジャイルのプラクティスでコーチングしました。
当時、私たちは顧客にストーリーポイントフリーのアプローチを教えるのはまだ快適ではなかったのです。
この最初のプロジェクトが完了して数ヶ月後、その会社は全社的にアジャイルを展開するために我々が支援できるかを尋ねました。
そこで我々は、プロセスの移行をを既に終えていた最初のチームへのインタビューを含む移行計画を策定しました。
そのチームのオープンワークスペースに入ったとき、バーンダウンチャート、リリース計画、イテレーションの計画、そして日々のチームのベロシティをトラッキングしているチャートで覆われた壁が見えました。
私はこの会社の最高のプロダクトマネージャーであると評判の女性と座りました。
数分の会話の後、私は壁のポスターのいくつかを指さし、計画と見積もりでどのようなことが起こっているのかを尋ねました。
少しの間を置いた後、彼女は笑いながら私を見ました。
それから彼女はすべての物事は順調で、ストーリーポイントを利用したベロシティを測定し、イテレーションとリリースで正しい業務量をベロシティを用いてスケジューリングしていると言いました。
彼女の表現が、何かが間違っていることを示唆していました。
「確かですか?」私は尋ねました。
彼女は数秒間止まった後、「本当の答えを知りたいですか?」と言いました。
私がうなづくと、彼女は、「ベロシティの数が入ったポスターを見ましたか? 我々はあなたがここへ来ることを知っていて、あなたに我々の良いことについて上司に言って欲しかったので、我々はこれを作りました。」と告げました。
「本当ですか?!?」私は驚いて尋ねました。「それで、実際は何をしているのですか?」
彼女はチームが2週間のイテレーションや、2ヶ月のリリースに正しい業務量を選ぶために、単に直感を利用していると説明しました。
もし彼女たちが計画を修正する必要がある場合、ただ修正するだけです。それは常にステークホルダーに知らされます。
直感による見積もりと計画づくりというアプローチはうまく言っており、ストーリーポイントやベロシティの計算は不要だと彼女は言いました。
私は彼女のアプローチのシンプルさを褒め称え、彼女がやっていたことは完全にアジャイルで、ストーリーポイントの利用はアジャイルになることに不可欠ではないと彼女に保証しました。
そして一年前に、Industrial Logicがどのようにプロダクト開発でのストーリーポイントの利用をやめたのかを説明しました。
周期的なリリース計画
多くの人は、いつソフトウェアをユーザーにリリースし、おおよそどのくらいのコストがかかるのかを知るために見積もりを行います。
プロジェクトの初期は、ほとんどのリリース計画や日付は素敵なファンタジーです。
より正確な見積もりを得るために、数日や数週間を費やすこともできるでしょう。しかし、1ストーリーごとに分析と議論を10-15分し、ざっくりと見積もってしまう方が良いでしょう。
より高い勝ちを低コストで得るため、私はチームにバーゲンハンティングをコーチングしています。
より正確な見積もりを得るために、私はチームにリリース計画にあるストーリーの周期的な(例えば2週間ごとの)再見積もりをするようコーチングしています。
時間がたつと、定期的にリリース計画の内容を再見積もりするチームはより速くなり、リリース日が近づくにつれてますます正確になる時間に基づいたの見積もりを提供します。
これは必要なもの全てを上司に提供します。すなわちリリースの範囲、スケジュール、コストを正確に予測できるということです。
このアプローチによって、ベロシティの数にまつわるゲームはなくなり、フォーカスは反復的にスコープの議論と、何をリリースするかしないかに戻ります。
私はチームに「チーム週」を利用してリリースのためのユーザーストーリーを書き、見積もることを教えます。すなわち、チーム全体が作業を完了するのにかかる時間です。
10人のチームで2人しかその仕事ができなくても問題ではありません。ただ0.5, 1, 1.5, 2チーム週のどれかとして見積もりを提供するのです。
もしあるユーザーストーリーの見積もりが2チーム週を超過したら、私はチームにストーリーを分割して2チーム週以内で見積もれるように促します。
リスクをより良く管理するため、進化的な設計とリリース計画を合わせて考えることは有益です。
あなたの最初の初期の製品、システムのバージョンには、高い価値をもたらす機能が含まれ、最も高いリスクへの対処がなされているべきです。
そのリリース(作り出すのに1−3ヶ月くらいを要するかもしれません)は顧客へリリースする何かよりも、内部のマイルストーンかもしれません。
次のリリースでは、既存の機能に機能追加したり、新機能を追加することで、新しいソフトウェアがさらに洗練されたものになります。
そして、顧客にリリースする準備ができるまでそれを繰り返します。
いずれにせよ、チームはリリース計画にある見積もったチーム週の数が、リリースまでに残されたカレンダーの週数に合っていることを確認する必要があります。
もし不一致があれば、リリースのスコープ変更し、再考し、再計画することでチームのキャパシティと合うようにするタイミングです。
私は、このスタイルのプランニングは、ストーリーポイントを使って見積もるよりもシンプルで、あるスプリントで見積もったベロシティが当たっていないと不快に感じることもなく、結果として良い結果をもたらすとわかりました。
周期的なリリース計画は、何の価値ある機能がデリバー可能かに繰り返しフォーカスすることで、人々のリスク管理を助けます。
ストーリーポイントのポイントは何か?
ストーリーポイントとベロシティ計算は、有名な書籍で正当化され、計画のためのツールに組み込まれ、認定によって検証され、業界で広く実践されている、アジャイルのデファクトなパーツとなっています。
しかし、私が知っているベテランのアジャイル実践者のほぼ全員、何年もの間ストーリーポイントとベロシティ計算を利用していません。
アジャイルの初期には、我々はストーリーポイントにポイントがあると考えていました。
しかし、私たちは、私たちのアイデアやプラクティスが硬直化しないように注意していました。
今日では、よりシンプルで、欠陥の少ないアジャイル見積もりと計画のアプローチがあります。
現在、ドン・ウェルズが2001年にかつておすすめしたことを行う人もいます。ほぼ同様のサイズのストーリーを同じ個数、毎スプリントで行うというものです。
他の人は、スプリントではなく、周期的なリリース計画を含んだ、フローに基づいたモデルで仕事をしています。
見積もりや計画については唯一の正しい方法はありませんが、時代遅れで欠陥の多いテクニックは避けることができます。
言い換えるならば、アジャイルハッピーセットの中に何が入っているのか注意してください。
ストーリーポイント利用をやめたいものの、始めるには助けが必要な場合は、モダンアジャイル計画ワークショップをお試しください。
チャーターでのディレクションの設定、ユーザーストーリーマッピングを利用したプロダクトのディレクションの明確化、プロダクトの仮説の検証する、しないことによる業務効率化、カンバンを利用した業務の見える化と仕掛かり制限について学ぶことができ、さらには見積もりで多大な時間を浪費することなく、より良い結果を生み出すことを学ぶことができます。
最後に
このエントリーは、Recruit Engineers Advent Calendar 2017の18日目のエントリーでした。 adventar.org
*1:https://twitter.com/JoshuaKerievsky/status/942234091801403394
*2:訳註:とはいえ原文は2012年なので、その点には注意してください
*3:https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756
*4:http://jimhighsmith.com/velocity-is-killing-agility/
*5:訳註:原文は"While this approach helped to point out the fruitlessness (pun intended) of comparing team velocities" となっていて、意図的なダジャレが入っているのですがうまく訳せなかったのが心残り
*6:訳註:NUTsはNebulous Units of Timeの頭文字をとったもの
法務部門へのスクラムの適用可能性についての一考察 #legalAC
はじめに
本エントリーは、法務系 Advent Calendar 2017の3日目のエントリーです。 adventar.org
前日は、dtk1970さんの、エントリーでした。
私はエンジニアなのですが、dtk1970さんのエントリー中にあった、
自戒も込めて,あえて問う。企業法務の担当者の皆さん,法律の勉強していますか?自分の背骨となるべき法律の学習から「逃げて」いませんか?目の前に生起する新しめのことに,目を奪われていませんが,惑わされていませんか?
というのは、エンジニア界隈でもよく出てくるトピックでした。 個人的には、息を吸うように勉強し、息を吐くように発表するべき、と思っているのであんまり悩んだことはないのですが。また、ツイッターをみていると他人の基礎知識の欠如に嘆いているツイートを複数みましたが、基礎知識が明確ならその一覧を明示し、欠如している人にインプットしてあげると建設的かな、と思いました。それができるのは基礎知識のある人だけですので*1。
本日のエントリー
当初、「法務部員を嫁に持ってしまった旦那の苦悩」としようかと考えていたのですが、特に苦悩がなかったので、代わりに嫁と話をしていてちょっと考えたことを書きます。
前述の通り法務担当者ではないですし、その経験もありません。コンテクストについての理解も浅いので、その点ご容赦いただければと。
スクラムの適用可能性?
問題意識
仕事ではスクラムというフレームワークをよく利用します。嫁とお酒を飲みながらそういった話をしていると、「嫁の仕事にもスクラムは有用なのではないか?」という問題意識が出てきます。そこでここではその点を考えていきたいと思います*2。
スクラムとは
スクラムは、1990 年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークです。スクラムガイドという公式ガイドが提供されており、その中に定義されています。
嫁の仕事と課題意識
あまり深入りするのは避けますが、大要下記のようなお仕事と問題意識があるようです。
- コンプラ系部門
- チーム内のナレッジ共有に課題感がある
- 見ようと思えば共有場所に情報がありはするが、アクセスにうまくできない場合もある
適宜補完しながら、議論を進めていこうと思います。
目的から考えてみる
スクラムはフレームワークなので、どういった用途で利用したいかの目的から考えてみるのが第一です。前述のスクラムガイドからいくつか引用してみます
- スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである
- スクラム(名詞):複雑で変化の激しい問題に対応するためのフレームワーク
- スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プ ロダクト、サービス、所属する組織の管理に広く利用されている。
- スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。
もし上記によって今抱えている問題が解消しそうであれば、スクラムを検討・導入する価値はありそうです。 今回であれば、「反復的で漸進的な知識移転において特に有効」という点が問題意識に引っかかりそうです。この点についてもう少し詳しくみてみましょう。
反復的で漸進的な知識移転
これが具体的に何を指すのかはスクラムガイド上明示されているわけではありません。そこで、スクラムの考え方の基盤となったハーバードビジネスレビューの掲載論文である「The New New Product Development Game」の著者である野中郁次郎*3の知識創造の理論について見てみます。
この理論はとても雑に言うと、知識を形式知、暗黙知として整理し、それらの循環の中で新しい知識が創造される、と言うものです。詳しくは、第6回 アジャイル開発と知識創造:アジャイル トランスペアレンシー ~アジャイル開発における透明性の確保について~|gihyo.jp … 技術評論社 によくまとまっています。
そして、企業や組織はこの循環をいかに回すか、と言うポイントに工夫をする必要があります。その前提には、現在やっている作業や、向かっている方向性などに透明性が求められます。このことから、反復的で漸進的な知識移転を狙うならスクラムは検討の価値あり、と言えそうです。
実現性
さて、検討の価値があるとして、実際に法務部門への適用は可能(実際に回る)のでしょうか。個人的に検討が必要と考えるのはスクラムガイドに記述されている下記の点です。
つまり、これらの目的を理解したうえで、現場にそれらを適用させていく必要があります。 この部分については、さすがにコンテクストにとても強く依存するため、より詳細なコンテクストの理解が必要になります。このブログエントリーでは、その詳細まで立ち入ることはできないので、もう少しクローズドな勉強会などでLTでもできればな、と思っています(フラグ)
結びにかえて
このエントリーでは、嫁の抱えているコンテクストに置いて、スクラムによって問題が解決しそうかについて考察しました。結論としては、問題が解決する可能性は理論的にはあり、検討する価値があるが、実現性についてはより詳細なコンテクストの理解が必要、と言うものでした。 と言う訳でこの続きの検討は勉強会のLT枠ででも(←これが言いたかった)
明日のエントリー
明日はshibaken_lawさんのターンです! よろしくお願いします。