デブサミ2016夏でDevOpsお悩み相談室というセッションをやりました

 2016/07/31
このエントリーをはてなブックマークに追加

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

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


事前にアンケートに回答いただき、全部で10個のトークテーマを用意していたのですが、時間の関係で後半の3個は扱えませんでした。それをお待ち頂いていた方もいるかもしれないので、この場で私見を説明しておきたいと思います。

Q. スクラムの定着方法

開発プロセスをカイゼンするためにスクラムを導入しましたが、みんななんとなくこなすだけになっており、カンバンや朝会も形骸化しています。今のやり方はうまく回っているようにも見えますがが、みんなにもっと真剣にスクラムに取り組まないといけないと思ってもらうにはどうしたら良いですか? 現状では、スクラムマスターという役割の人がおらず、チーム内にスクラムについて深く理解している人はいません。またマネージャーはいますが、他の業務に追われてスクラムがうまく機能するような取り組みは行えていません。この状況でうまくいかせるには、一度、開発者の中から誰かをスクラムマスターにする、といった取り組みが必要でしょうか?

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

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

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

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

最後にテクニカルな話でいうと、カンバンや朝会が形骸化する理由は簡単です。以下に一例を列挙しておきましょう。

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


Q. カンバンを習慣化するには?

カンバンをやり始めてもなかなか習慣化できないのですが、何かよいアイデアがあれば紹介してください。いまは以下のような課題があります。

  • 付箋化しにくいタスクがある
  • 更新してくれない(レビュー後にDoneに移動してくれない)
  • リモートワークとの共存が難しい

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

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

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

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

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

Q. サービスの部分障害の把握方法

サーバーの設定を変更したことで、Webシステムの一部の機能が使えなくなってしまう問題が起こったことがあります。たとえばWebページ自体は閲覧できても、フォームやアクセス解析など一部のみで問題が起こると発見が遅れてしまいます。どのようにすれば機能単位の機能停止を早く発見できるでしょうか?

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

 2016/07/31
このエントリーをはてなブックマークに追加

サイト内検索


著作

寄稿

Latest post: