法務部門へのスクラムの適用可能性についての一考察 #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さんのターンです！ よろしくお願いします。
タスクボードで手戻りを見える化したい（のでスプレッドシートに書いてみた）
発端
なんだか手戻りが多そうなんだな、と思うことがあって、なんとかそれを可視化したいなと思ってスプレッドシートで見える化してみました。 雑なやり方だったけど効果があったのでメモしときます。 もっといいやり方知ってる人いたら教えてください。
やったこと
前提
これができてる必要があります。
- 開発の各ステップが分かれている（タスクボードが運用されているならそうなっているはず）
- 各ステップから次のステップにいつ移動したかが追える（私はJIRAでこれをやっていたのでステータスの変更で追えた）
作ったもの
これだけだと意味わからないと思うので補足説明します。
何を書くか
このルールに則って書くだけです。
- ステップが進むごとに、そのステップに入った日時をプロットする。
- この例ではスプリントの何日目かをプロットしています。
- もし手戻りがある（ステップが前に戻る）場合は、その案件の行を追加し、戻ったステップのところに日時をプロットする。
何がわかるか
この図からは
- 手戻りの多い案件がわかる
- 行数が多いのがそれなので
- 手戻りによってどのくらいリードタイムが伸びたのかがわかります
- 手戻ったところのステップと、そのステップを最終的に通過した日がわかるので
がわかります。図を書き足すとこんな感じ。
この例だと、
- 案件A
- コードレビューでめっちゃ手戻ってる
- これによってリードタイム3日伸びてる
- 案件B
- 最後の受け入れで手戻った
- 結果もう一度受け入れに行くまで+5日かかった
あたりがデータから読み取れます。
効果
手戻り多っ！という共通認識
これを見せると、ほぼ確実に、A案件の手戻り多い！と言います。共通認識の構築にバッチリ。
リードタイム観点で、自分たちの行動を振り返れる
例えば、コードレビューの行ったり来たりで、3日リードタイムを失うのって良いことなんだっけ？と言った議論ができます。
ペアプロやモブプロした方が早かったんじゃ？と言ったことが感覚的に出てくるので、そう言ったTryも出て来やすくなります。
また、大きな手戻り（ステップを大きくまたぐもの）があった場合に、それによるダメージの大きさのインパクトが伝わります。それによってどうしたらこれ前ステップでなんとかできるかな、と考えるきっかけになっています。
まとめにかえて
カンバン運用していたりすると、手戻りの可視化、改善ってラインストップで防いでいると思います。ただしラインストップは、初めてやる場合は心理的負担が高いと思います。その手前でこう言った形で手戻りを見える化できると、その観点でのカイゼンに目が向くのでやってみてよかったな、と感じました。
ScrumButしてリードタイムがクッソのびちゃう話。
ScrumButは簡単にいうとスクラムアンチパターン集みたいなものです。
上記によればこういうフォーマットをとります。
(ScrumBut: スクラムやってるよ。けど)(Reason：理由)(Workaround： 応急処置)
今回はそのScrumButの一つの話です。
スクラムやってるよ。けど...
今回の例のScrumButは下記のような事例です。
スクラムやってるよ。でも1スプリントでundoneが多くあるから、 doneにできるように開発しやすい形にタスクを分けて、1スプリントで完結できるようにしたんだ。
例えば、調査、サーバーサイドのAPI開発、フロントエンド開発、というタスク群があったとして、下記のようにしてしまう状態です。
何が起きるか？
これによって、doneはすると思います。doneするようなタスクわりにしているわけですから。 でも、これは結局APIだけリリースしてもユーザーに価値を提供しません。
むしろ、元々のやり方に比べ、途中に他の案件をしてしまったりして待ちが発生し、doneしているのにリードタイムをいたずらに伸ばしてしまっている状態になってしまっています。
なぜこうなるのか？
引力は色々あるかと思うのですが
- 何がなんでもdoneしなければならない
- 調査は見積もりをぶらしてしまうので、スプリントを分けたい
といった引力があるのかな、と思います。
派生して起きる厄介なこと
この事例にはまってしまうと、開発内部は自分たちを「予定通りに安定して開発をしているチーム」と認識するかもしれません。 しかし、ステークホルダーから見ると、これはリードタイムがただただ長くなっているだけの状態です。
こうなると、開発に何かを依頼する側は「開発してもn週間かかるから、よく練って確度上げてから開発に依頼しよう」となる引力が働きます。 しかし、開発内部がもし勘違いしていると、「俺らアジャイルなのに、ステークホルダーが全然案件を小粒で出さねーから仮説検証できねー」といった軋轢がおきかねません。
どうするのか
月並みですが、なんのためにスクラムやっているんだろう？を問い直すことからかな、と思っています。
スクラムをやっている、ということは検査、適応、透明性のサイクルが回っているということなので、スプリントを回すことによって何を明らかにしたいのか、あるいは明らかにしたことから何を考察してきたかをトレースすると良いのではないでしょうか。ここまでの例で言えば、undoneになるのが課題だったとすると、それがなぜ課題なのかを考えるとか。undoneはとにかくいけない、なので無くさねば、というのはその背後にあった目的を見失ってしまう場合があります。
その明らかにしたいものに開発のリードタイムが入っているのであれば、その観点でふりかえりしたり計測してみたりすると良いですね。場合によってはスクラムにこだわる必要もないかもしれません。 私が似たような経験をした時は、手戻りの可視化してたりしました。それは別エントリーで。
まとめ
結局は目的に忠実な点にフォーカスした検査・適応・透明化をしていきましょう。って話でした。
