どうも！アプリケーション基盤チームの@yokotaso です。
先日のCybozuTechConference 2017で、「開発文化を育て広げる愉しみ」という内容で登壇させていただきました。 発表内容のカンペを公開します。
かわゆいまとめをしていただいたので、お忙しい方はこちらをどうぞ！
文章にはなってしまいますが、どうぞ！
「開発文化を育て広げる楽しみ」という話をさせていただきます。今日は宜しくお願いします。
2011年にサイボウズ新卒入社の横田と申します。Webアプリケーションエンジニアとして主に働いております。
本題の前に
本題に入る前にすこしお話しさせてください。
まずはチーム開発開発体制について。 ユーザー管理などの管理機能の開発を行なっています。 日本で開発と上海で試験の2拠点体制です。
開発のScrum化の波に乗りまして、我々もScrumを採用しています。 Scrum 開始当初は、1 Sprint内で開発から試験設計までを完了がDoneの定義になっていました。 最近はすべてのタスクというわけではないですが、 1 Sprintで開発から試験完了まで1個流しができるようになってきています。
なぜKanbanを採用したのかですが、マルチプロジェクト担当メンバーが多い問題がありました。 影の仕事の存在があったり、誰が何をやっているのかわからない問題がありました。
加えて、開発から試験完了までの仕事はどんどん高速化していきたいので、 上海と日本で多拠点でKanbanをやってみようということになりました。
開発文化の歴史
次に、開発文化の歴史についてお話させて下さい
サイボウズはもともとオンプレミス・ビジネス中心でした。年単位で開発・試験スケジュールが組まれていました。
ユニットテストがないプロダクトや開発Fixが近くなると動き出す名ばかりのデイリービルドなど悪しき慣習がありました。
開発文化らしいものはなかったんじゃないかと思っています
そこからクラウド・ビジネスに挑戦しはじめるわけですが、 前のスライドから開発効率が悪いというのはお察しいただけると思います。
あっという間に緊急リリースが乱発しまして、 品質の不安定化と開発工数の爆発に悩まされることになります。
こういった実務的な問題を解決するために、継続的インテグレーション・継続的デリバリーを利用するようになります。 今まではプロダクト開発をメインに投資を行ってきましたが、開発効率向上のために積極投資をするようになります。
ビジネスの主軸がオンプレミスからクラウドの移ろいと時を同じくして開発文化も変化していきます。
クラウド創世記の開発文化をベースに改善を続けてきました。 その結果、開発効率が向上したので開発のボトルネックが少なくなってきました。
そこで、開発から少し視点をあげてリリースまでのプロセス全体の改善したい欲がでてきました。 開発から試験工程までを含めて全体最適化をしていくために、Scrum/Kanban型の開発スタイルへ移行していきます。
開発効率向上のための仕組みから、価値を素早く届けるための開発文化に進化してきます。
開発文化は、サイボウズのビジネスを支える重要なファクターに位置付けられるようになってきています。
疑問
開発文化の歴史を話してきましたが、社会人経験がある人は、疑問を持ってるかもしれません。
クールにみえる開発文化がなんでうちには馴染まないんだろう？とか
開発のベストプラクティスと呼ばれるものを導入したけど、廃れちゃったとか
そんなのサイボウズだからうまくいくんだろうとか
ただ、これってサイボウズでもよくある話なんです。
失敗から改善したり、少しづつですが前に進み続けて今の開発文化があります。
開発文化を定着させるためのコツがあるっぽいので、
日本と上海のKanban導入と過去の失敗をネタに
開発文化を育てるためのプラクティス
開発文化を育てるためのプラクティスについてお話ししようと思います。
ボトルネックは文化の母
さて、一つめですが、ボトルネックは文化の母です。
開発プラクティスは開発プロセスのボトルネックを解消するでしょうか？ 無理に作ったり導入した開発文化というのはうまくいきません。 導入したら、どうボトルネックが解消されるのか？を考えましょう。
逆にボトルネックが解消されない文化は廃れがちです。 コードやチームの状況を見極めた上で、必要な開発文化を作っていく必要があります。
過去の失敗例です。UnitTestを広めようとして失敗したことがあります。 UnitTestが当たり前の開発体制にしたかったんですが、見事に失敗しました。 今思い返すと、当時はまだチームの開発文化として取り組むのは早かったと反省しています。
UnitTestのあるなしは大きなボトルネックではなかったのです。他にもっと大きなボトルネックがあったのでした。
その大きなボトルネックは、クラウドとオンプレミスのアーカイブが同時にビルドされないことから生じる問題でした。 そこで、オンプレ・クラウドのデイリービルドを自動化しました。
オンプレミスとクラウドのアーカイブを毎日好きな時間に作れるように刷新しました。 オンプレ・クラウドの同時試験が可能になりました。 試験が同時にできないのが実は大きなボトルネックだったのです。 こういうボトルネックが解消されて初めてオンプレミス・クラウドの環境を意識した開発を行うことができるようになるのです。
これだけだと開発文化も何もないんですが、これが新しい開発文化のベースになったりしていくわけです。 開発プロセスのボトルネックから導入する開発プラクティスを見極めていきましょう。
仲間を増やそう
次は「仲間を増やそう」です。
サイボウズで開発文化として定着したものを振り返ると全員参加型の勉強会を開いていることがとても多いです。
目的は、
- 知識のベースラインを揃える。
- 共通の語彙と知識をつける。
- 問題意識の共有をする。
です。
勉強会のコツですが、シンプルな原理・原則を理解を理解してもらうことが大事です。 そして、全員参加しやすい勉強会にしていきましょう。勉強会の目標をシンプルにして、妥協できるところは妥協していきましょう。
Kanbanを導入した時の話ですが、日本・上海で合同の勉強会を開きました。
カンバンの理解としては、WIP(Work In Progress/進行中の仕事)や仕事の流量制限がなぜ大事か？仕事の可視化について、重点的に勉強しました。
輪読に利用したカンバン仕事術は、日本語版と中国語版が出版されているので、こちらを利用しました。 言葉は、本質的ではないので使えるものは使いました。
また、カンバン仕事術特有ではあるのですが付録にゲームが付いているので、毎回の勉強会の最後にゲームを実施しました。 ゲームを通して、Kanbanの原理原則を体感してもらいました。
なぜ、重要なのか？を共有するのは、開発文化を作っていく上で、重要です。
逆に失敗してしまった例ですが、有識者で勉強会を開いてしまったことです。 開発文化にしていきたかったのに、特定メンバーのみで勉強会を開いてしまったことです。
メンバー全員と問題意識の共有ができないだけでなく、メンバー間で知識差ができてしまう原因にもなりました。
小さく始めよう
次はSmall Start、読んで字のごとく「小さく始める」という話です。
とにかく小さく、早く始めていきましょう。
1週間、1つみんなで決めた簡単なプラクティスに取り組んでみるくらいから始めてみましょう。 無理をしてすべてを取り入れる必要はありません。
うまくいったパターンでは、すぐにKanbanを始めました。 できるだけシンプル、簡単なKanbanを作ってみました。上海拠点も自分たちのカンバンを作ってもらいました。 自分たちのKanbanを作りながら勉強会を進めることで、勉強会のネタに合わせてKanbanを改造したり試行錯誤できるわけです。
やっていくうちに、改善アイデアを思いついたりや新たな気づきなどもあります。 改造することを前提に簡単に始めるのがおすすめです
失敗例として、知識を一通り身につけてから実践しよう としたことがあります。 ひとまず一通り知識を身につけてから開発プロセスに組み込もうとしました。
ベストプラクティスを謳っているにもかかわらず開発プロセスにそのまま組み込めないものは多いです。 その現実に疲れてしまって、本質的な開発プロセスの改善に時間を使えず、失敗しました。
開発プロセスや組織の状態を考慮して、プラクティスの改造、取捨選択が必要なのです。
効果的な振り返りをしよう
小さくはじめたら、いいタイミングで振り返りをしましょう。
開発文化を定着させてるために効果的な振り返りをしましょう。開発プラクティスの原理・原則を意識して、振り返ります。
振り返り内容に、開発プラクティスの原理原則を意識した内容がでてくればメンバーに知識が定着しているだけでなく、 日々それを意識して仕事にあたってくれているのがよくわかります。
例を見てみましょう
これは、我々のチームででてきた実際の振り返りの内容です。 原理・原則を意識してチームの問題を解決することができた例です。
褒めるポイントが明確で、どう解決したのか？の考え方がよくわかりますね。 チーム全体の処理中の仕事の量を意識して仕事ができるようになっているのがわかります。
今度はProblemを見てみましょう。
根拠が明確になり、kanban導入以前では見えていなかった開発プロセスの問題が出てきているのが分かると思います。
普通に開発していたら、WIPが多いとか気にしないですよね。 チームメンバーにKanbanの知識が定着して、それを使って考えることができている証拠ですね。
よくないパターンですが、ふんわりした振り返りをしてしまう。
根拠が明確でない・瑣末なProblemをとりあげて、複雑な回避策を採用していませんか？ 開発プロセスのボトルネックを解消できるProblemの発見、調査、解決に注力しましょう
KAIZENと守破離
振り返りを終えたらKAIZENです。
一般的なプラクティスをただ適用するのではなく、 それぞれのカルチャーに合わせて取捨選択して改造してきましょう。
なぜ、改造や取捨選択が大切なのかはあとでお話しします
たとえば、こういう Problemがあって、Kanbanを観察した結果、KAIZENするべき内容をきめたとします。 ちょっとわかりにくいと思うので、簡単なKanbanの図で説明します
プロジェクト開始直後はDoingのタスクはすくないですが、 レビューのフェーズに入ると途端にWIPが高まるのが分かると思います。
WIPが高い状態はKanbanでは避けるべき状態です。
これを改善するためにまず、アバターを導入しました。 そして、Review列を新設して、Reviewには関係者全員を配置します。
この改善のおかげでDoingに仕事が持ち込まれないだけでなく、 Reviewはアバターを2人で消費してしまうので、できるだけ早く終わらせたいプレッシャーになるのがお分かりいただけますか？
我々のチームのKanbanを改善例でした。
自分たちの状況、カルチャー、問題に合わせてプラクティスを取捨選択・改造して、組織にフィットする開発文化にしていきましょう。 プラクティスを単純に当てはめるのではなく、チームで開発文化を育てていきましょう。
海外拠点はどうしたのか？ですが、上海のKanbanも上海のカルチャーを尊重して管理はしていません。
我々とは別のカルチャーや問題を上海も抱えていてそれを解決すべくKanbanを使っています。仕事をしながら日々Kaizenをしてくれています。
私がやったことといえば、最初のKanbanを作るのをお手伝いしたことと、相談や注意喚起くらいです。 勉強会でやることをやった後は、あとは支援するだけです。 ことわざで言うところの魚を与えるのではなく、魚の釣り方を教えるのと同じです。
とはいうものの、最終的には日本、上海間で仕事を開発から試験完了まで行いたい目的もあります。
kintoneでタスク処理の基本的なところをやりつつ、各拠点の仕事の流れは各拠点のkanbanで管理しています。
仕事終わりに拠点ごとのKanbanの写真をアップロードしてもらっています。これで多拠点のタスク待ちや他拠点への仕事の依頼のしすぎに気づけるようになっています。
複利と再投資
さて、複利と再投資というお話。
開発文化として定着したら開発工数が減っていると嬉しいですね。その余剰時間を開発文化に再投資していきましょう。
開発文化を進化させていくのです。新しい挑戦をしていくために開発文化をKAIZENしていきましょう。
たとえば、テストエンジニアになるための勉強や今まで煩雑だった試験手順を半自動化するなどに投資できる時間がでてくるわけです。
サイボウズは改修後、即リリースというのはまだできていないのですが、実現のためにはさらなる開発文化の進化が必要だと思っています。
まだまだやることは盛りだくさんですが、自分たちで開発文化を作り変えてきたことが財産であり、組織と開発体制の基礎体力なのです。
アジャイルな開発プラクティスは実践しなくてもよいが、アジャイルな組織、開発文化を目指していきたいと思っています。
必ず何かの問題はあるので、また変わっていきたいと思っております。
まとめ
最後は、そして、夢の外へ。
サイボウズには拠点・組織をこえて開発文化を育てる取り組みをしてきました。 僭越ながら、開発文化を育て広げるコツをお話ししました。
100組織あったら、100通りの開発文化があって良いと思っています。 なので、自分たちの開発文化がよく知られた開発プラクティスでなくても良いのです。 ベスト・プラクティスと違っててもいいのです。 それよりはボトルネックを解消するための開発文化であってほしいと思います
オンプレミス時代から振り返ると隔世の感に驚くばかりなのですが、僕が入社した頃は開発文化がある組織を憧れていました。
頭の中の夢から開発文化のある組織が実現しつつあります。
そして、夢の外へこれからも開発文化を育てていく取り組みを続けたいと思っています。
このカンファレンスの大きなテーマに戻ってくるのですが、開発文化を育てることを愉しみたいエンジニアに 少しでも参考にしていただいただければ、幸いです。
「開発文化を育て広げる愉しみ」でした。ありがとうございました。
