ブログ

みなさんこんにちは。@ryuzeeです。

7月29日に御茶ノ水のソラシティでおこなわれたDevelopers Summit 2016 Summer (デブサミ2016夏)で、「DevOpsお悩み相談室〜カイゼンの文化を組織に根付かせるために」というタイトルのパネルディスカッションを実施しました。当日は多くの方にお越しいただきありがとうございました。当日の資料は以下になります。

なかなか難しい質問です。まず最初に明らかにした方がいいのは、「スクラムを導入したのはなぜか？」という点ではないかと思います（はっきりしていなければもう一度やってみてください）。 もともと何か組織として解決すべき課題があったので、それの対応のためにスクラムを導入したはずです。 改めてそれを明文化して、解決したかったことを優先順位順に並べ、いまどこまで解決しているのかを確認してみるとよいでしょう。 そこで上位の課題が解決しているのであれば、それが「スクラムなのか？」はチームにとっては最重要ではありません。 言い換えれば、問題を解決するのと、ソリューションを導入するのを同一視しないことです。

うまくいっているように見えている状況で、さらにそれに真剣に取り組んで貰うのも大変です。 チームに対して「なぜもっと真剣に取り組まないといけないか」を説明できないと、ただの掛け声で終わったり、自律性のない押し付けになったりしてしまいます。 したがって、以下のようなことを全員で議論してみるとよいと思います。インセプションデッキのようなフレームワークを使うのもアリでしょう。

• 自分たちはなんのためにここにいるのか
• 自分たちはビジネス側の期待に応えられているか
• どうなれば、もっと期待に応えられそうか

なお、スクラムマスターのいないスクラムはスクラムとは成り得ない（スクラムの要件を満たしていない）ので、「スクラムをやりたい」のであれば、まずスクラムマスターをアサインしてください。 ただしアサインしたからといって問題が解決するわけではありません。 またマネージャーが忙しすぎて協力してくれないのだとすると、マネージャーにとっての「スクラム」はその程度の優先順位でしかないという可能性もあります。 マネージャーがどんな期待値を持っているか確認するとともに、必要な権限を委譲してもらうといった対応も必要ですし、もしくは、そもそもマネージャー自体のタスクを見える化して本当に大事なところに力を貸せるように改善する必要もあるでしょう。

最後にテクニカルな話でいうと、カンバンやデイリースタンドアップが形骸化する理由は簡単です。以下に一例を列挙しておきましょう。

• タスクの単位が大きすぎて昨日も今日も同じことをやっている
• タスクの内容が自分以外よくわからない感じになっている
• 専門性の違いによって、人がもっているタスクを取りようがなくなってしまっている
• 計画どおりに進めないと詰められるような文化がある等の理由で、悪いニュースを伝えにくい
• そもそも仕事がたくさんありすぎて人を助ける余裕がない
• したがって人が話している内容に関心を持てない
• したがってボードがメンテされていなくても気にならない

前の質問とよく似た質問です。まずやらないといけないのは、カンバンに何を期待するのか、チームのメンバーそれぞれに何を期待するのかを明らかにすることでしょう。 個々の悩みについてみていきましょう。

まず付箋化しにくいタスクですが、実はこういうタスクは本当はあまり無いはずです。一度、自分たちのタスクにはどのような種類のものがあるのか洗い出してみるとよいでしょう。 よくあるのは、機能の追加要求・不具合の修正・技術調査・メンテナンス・障害対応・報告・レビューなどです。チームで付箋の色の使い方や書き方の凡例を共有する（ボードのそばに貼っておく）のもベストプラクティスの1つです。

また、あわせて自分たちの仕事のワークフローの認識が正しいのかどうかも確認するようにします。 質問のケースでは、レビュー後にDoneに移動されない、とあります。 レビューが必要ということはプロセスのワークフローの中にレビューというステップが存在することになるので、分かりやすくするのであれば、「レビュー待ち」「レビュー中」「レビュー完了」といったカラムをカンバンに作ります（前のステップとの繋がりなので、前者2つを使ったり、後者2つを使ったりします）。次に、それぞれのステップに同時仕掛り数（WIP）の制限をかけます。 レビューしたあとに、次のステップに付箋を移していない場合は、仕掛りに項目がたまるので、そもそもそれ以上のレビューを行うことはできません。 WIPの制限がある項目がボトルネックの場合、その直前にタスクがたまるので、カンバンが流れていないことが見えるようになります。問題が見えるようになれば手を打たざるを得なくなります。

そして随時更新してもらうためにも、デイリーミーティングとの組み合わせは有効です。毎日WIPの制限に引っかかっている箇所がないか、何日も同じステップに滞留しているタスクがないかをチェックして対応を促すとよいでしょう。僕が支援しているあるチームでは、特定ステップでの滞留があれば毎日ドットシールを1つずつ貼っていき、何日間滞留しているか確認するとともに、それはいつまでに誰がどのように解決していくのかを確認するようにしています。

最後にリモートワークについてです。 全員同席でできないことはリモートでもできないので、チームのプロセスがしっかりしないうちに毎日リモートにしてしまうと非常に大変です。 したがって初期のうちはオンサイトの回数を増やしておいた方がよいでしょう。 なお、ツールに関してはオンライン上で使えるカンバンもあります（Trelloなど）ので、そういうものを活用しつつ、上述のとおりデイリーミーティングをSkypeやハングアウト、チャットと組み合わせて実施します。

最後はテクニカルな質問です。大規模なアプリケーションになってくると、リリース後に一部が動作していないといったことは発生する可能性があります。 これを防ぐためには、リリース後にスモークテストを自動で実行することです。 また重要機能であれば、常時動作の監視が必要なこともあります。その時は監視システム上に、そのような機能の動作を確認するテストを登録し、一定間隔で実行するようにします。 スモークテスト自体は、それらのテストのサブセットになることもあります。 ほかにも、アプリケーションのログなどをリアルタイムで集約し、エラーログをチャットに通知するといった対応も必要になってくるでしょう。