しょ〜うぃん広場

おもにTech系なブログ、ときどき個人的なブログ

プロダクトオーナーとして機能開発の優先度を決めるのは難しい

今年の7月から(スクラムにおける文脈の)プロダクトオーナーを担当していて、そろそろ4ヶ月ぐらいが経つわけですが、機能開発の優先順位を正しくつけるのはめちゃくちゃ難しいなぁと感じています。
BtoB のサービスを開発しているので、カスタマーサポートのメンバーからお客さんが普段どんなところに困っているかという声はちょこちょこ聞こえてくるのですが、それを統合して課題の大きさを判断するのは(情報がバラバラで)難しいし、同じテーマで顧客の声を吸い上げるにはヒアリングをする必要がありコストがかかるなぁという印象です。

PCゲーム業界ではうまくいっている?

ぼくは Steam でベータ版のゲームをやることが多く、面白そうだなーと思ったものは Steam に登録される前のアルファ版から手を出して遊んでいることもあります。(好きなジャンルが経営シミュレーション系なのですが、そもそも市場にゲーム数が多くないので、ベータ版が出た段階ぐらいから早めに目をつけています。)
最近のゲームは、昔のように完成したゲームをどーん!と発売するのではなくて、一通り遊べるレベルになったらベータ版としてリリースして、ユーザの声を聞きながら正式版としての完成を目指していくものが多いです。特にPC版のゲームはそれが顕著ですが、SwitchやPS4のゲームソフトでもあとからアップデートをかけられるような仕組みになっており、ユーザの遊び方を観察してそれに合わせてバージョンアップをしているように見えます。
(勝手な推測ですが) なぜ業界全体がそういう方向に向いているかというと、ゲームがどんどん複雑化していて1本のタイトルを作るコストが増大し、1本失敗すると大打撃を受けてしまうからでしょう。(スプラトゥーン2も発売当初は1年間だけバージョンアップしていくよ。と宣言していましたが、売れ行きが好調だったのでその期間を延長することになりました。)
この状況はWebサービスを開発しているスタートアップも同じで、(少し大袈裟ですが)自社プロダクトが失敗したら会社はおわりなので、ユーザの声を聞きながら市場にフィットするプロダクトに少しずつ方向修正していかなければなりません。

Steam がプラットフォームとして成功している1つの理由に、ユーザからの声がゲーム開発者に届きやすい構造になっているというものがあると思っています。 ゲームごとにフォーラムがあり、レビューも集まりやすいのでゲーム開発者にユーザの声がどんどん届くわけです。その意見を参考にしながらゲームを拡張していくことで、よりユーザのニーズに沿ったゲームを作ることができ、結果的に面白いゲームが Steam に集まることになるのではないでしょうか。
また、最近遊んでいた Oxygen Not Included というゲームは、起動するとゲームタイトルの部分に「次に開発して欲しい機能は次のうちどれですか」と四択で選択できるような機能がありました。これは、開発優先度を決める上で非常に有効な手段なのでは?と感じており、弊社のプロダクトでも取り入れてみようかなと考えています。
よく聞く話に「ユーザの声を真に受けるな」というものがありますが、私はこれに半分同意で半分不同意です。ユーザが(自由に発言した)「〇〇の機能が欲しい」という声は真に受けてはならず、その背後にある真の課題は何なのかを読み解き、プロダクトとして一貫性のある機能改善でその課題を解決すべきです。お客さんの声を鵜呑みにしてしまうとプロダクトの思想が失われていき、ぐだぐだなものが出来上がります。一方で、上の例のように、こちらで開発したい機能をいくつか提示してどれが欲しい?と聞くことは非常に価値があり、こちらが(製品の方向性を考えた上で)開発しようと思っている機能のうち、ユーザのニーズが高いものから順にリリースができます。 (すべての選択肢がイケていないこともあるので、「その他の機能」という選択肢が必要かもしれませんが…笑)

優先順位付けのベストプラクティスって皆どう勉強しているの?

SaaSでそのようにユーザに直接開発順位を問うているプロダクトは今まで触れたことがなく、ユーザの声を聞きながらプロダクトの方向性を修正していくのはゲーム業界の方が進んでいたりするのかな?と思って記事を書いてみました。
プロダクトオーナーの皆さんはどこでベストプラクティスを学んでいるのでしょうか… 良い書籍などあれば教えてください。。

社内ISUCONでISHOCON2を使用するための手順まとめ

概要

この記事では、ISHOCON2を皆で解くイベント を開催した際に使用したISHOCON2のベンチマーカーとポータルサイトの構築手順を紹介します。

背景

ISUCONも今年で8回目となり、最近では多くの会社で社内ISUCONが行われています。 pixivさん(catatsuy/private-isu)、Yahoo! Japanさん(yahoojapan/yisucon)、Recruitさん(recruit-tech/r-isucon)では独自で問題を作成されており、他の会社で社内ISUCONを実施する際にはこれらの問題が再利用されることが多い印象です。(特にpixivさんの問題はISUCONのインスパイアとしては(ぼくの知る限りでは)最初に登場したため知名度も高く、よく使われているように思います。)

ぼくは社内ISUCON向けという形ではなく、個人で楽しむことを目的としてISHOCONシリーズを作成しています。

ISHOCON1は沖縄で開催されたISUCON模擬試験イベントや、Wantedly さんの新卒研修で使って頂いています。

ISUCONイベントを開催する場合、作成済みの問題を使用することで問題作成のコストは下がりますが、ベンチマーカーのインフラを用意したり、参加者がスコアを確認するポータルサイトを準備したりと意外とやるべきことが多いです。 そのハードルが高くてなかなか社内ISUCONが実施できない。という組織も多いのではないでしょうか。

この記事では、ISHOCON2を皆で解くイベント を開催した際に使用したベンチマーカーとポータルサイトの構築手順を紹介します。この記事で主催者の心理的ハードルが下がり、より多くのISUCON関連イベントが開催され、より多くのエンジニアがアプリケーションの高速化に興味を持ってもらえたら嬉しいです。
(とかいいつつ、ISHOCON2はベンチマーカーとポータルサイトでそれぞれ1点ずつ不具合を抱えているのですが。。ASAPで直します…)

ちなみに、今回のイベント準備は右往左往して結局15~20時間位かかってしまいましたが、この記事を読めば2,3時間で環境構築できるのではないかと思います。
(サーバーレスにしようとして上手く行かなくて、結局ECS使うことに落ち着いた話はまた別記事で書きます…)

ベンチマーカーの準備

ここからが本題です。
ISHOCON2はアプリケーションとベンチマーカーが別インスタンスで動くようになっており、(現時点での)最新のベンチマーカーAMIは ami-78b66107 です。ただしこれは個人で取り組む用の実装になっているので、こちらは使用しません。
使用するのはこちらのコンテナイメージです。 showwin/ishocon2_bench_for_contest
このイメージは、HTTPリクエストを受け取ると、ベンチマーカーが起動して、ベンチマーカーの実行ログを Firebase に吐き出されるようになっています。 (WebアプリケーションはPython, Flaskで書かれており、このあたり に実装があります)

Firebase の Database は現在 Cloud FirestoreRealtime Database の2種類がありますが、今回は後者の Realtime Database を使用します。
ベンチマーカーの実行のためには POST /run に以下のパラメータをJSON型で投げますが、今回説明するポータルサイトとセットで使う場合には、特に意識する必要はありません。

key 説明
ip ベンチマークする対象のIPアドレス
name 実行した人の名前(ポータルサイトに出す用)
workload ベンチマークの負荷量

コンテナを動かす環境はどこでも問題ないですが、ぼくは使い慣れているECSを選択しました。 ECS + SpotFleet な構成だと金額的にかなり低コストに収まると思います。
コンテナを起動するときに以下の環境変数を設定してください。

key 説明
FIREBASE_URL 結果を投げるFirebaseのURL。(e.g. https://xxxx.firebaseio.com )
MYSQL_USER 後述するDBにアクセスするためのユーザ名
MYSQL_PASS 後述するDBにアクセスするためのパスワード
MYSQL_HOST 後述するDBのホスト

ベンチマーカーのバックエンドにはデータベースが必要で、アプリケーション実装の初期値と同じデータが入っている必要があります。 ISHOCON2/ishocon2.dump.tar.bz2 at master · showwin/ISHOCON2 · GitHub にDBのダンプファイルがあるので、こちらを解凍してデータベースに流し込んでください。

ベンチマーカーのクラスタサイズの目安としては、25人が参加したイベントで、1コンテナあたり2CPUを割り当てて、20コンテナぐらい用意したところ、クラスタ全体のCPU負荷が常時<20%でした。 少し余裕を持つとして、1コンテナあたり2CPUで、参加者2人につき1コンテナぐらいの割合で良いかと思います。(競技終盤はガンガンベンチマーカーが実行されるので、終盤だけ少しスケールさせておくと良さそうです。)
DBはRDSでt2.microを使用していましたが、もう一つ上のインスタンスサイズでも良かったかなと感じました。CPUへの負荷はかかりませんが、ベンチマーカーからの接続数はそこそこな数があるため、メモリにもう少し余裕が欲しかったです。

注意すべき点として、後述するポータルサイトからは workload 30 までしか実行できませんが、workload > 50 ぐらいで実行するとベンチマーカーが途中で止まる可能性があるバグが存在しています。(https://github.com/showwin/ISHOCON2/issues/27)

ポータルサイトの準備

ポータルサイトはこちらのレポジトリにあります。showwin/ISHOCON2-Portal
使い方は こちら をご覧ください。

設定しなければいけない値としては、上で用意したベンチマーカーのURLと上で用意したFirebaseのデータベースURLの2つになります。

Issue に上げていますが、webpack の1系でしか動作確認できていないので、注意してください。

当日のマニュアル

今回のイベントで使用したものを元にテンプレートを作ってみました。よろしければ使ってみてください。 https://gist.github.com/showwin/8c2ff3f3c57c0135f7fbf4383942e1b8

ISHOCON2を使ったイベントを開催したら…

showwin/ISHOCON2#関連リンク追記しますので、イベントレポートを書いていただいて、@showwin まで連絡いただけたら嬉しいです!

Enjoy ISHOCON Life !

ホラクラシーを導入して3ヶ月経った感想

会社で5月ぐらいからホラクラシーという組織のフレームワークを試験的に採用していて、3ヶ月が経った。 結論から言うと、3ヶ月ではまだ良いかどうかはわからない。 ホラクラシーの恩恵を十分に得られていない感じはするが、Pros/Consはいくつか思うところがあるので忘れないうちにメモしておく。

導入の背景

ホラクラシーを導入しよう!となったのは、だれかが組織に関する本を読んで…のような理由ではない。 もともと会社の採用方針が「社内の人間が持っていないスキルを持っていること」であったので、そもそも今社内でどういうスキルが足りないんだっけ…?今後どういうスキルを持っている人を集めないといけないんだっけ?と考えることが多かった。 HR担当が入ったタイミングで今の採用状況を上のように伝えると、それってホラクラシーの考え方に近いから社で導入してみる?という話になった。(実際にはそこまで近い考え方ではなかったが、、、)

(話は逸れるが)HRの専門家がいなければホラクラシーなんて言葉も知らなかっただろうし、社内にない知識が外から入ってくるのはいつも大変嬉しいことだなと感じる。

導入前の準備

HR担当も含めて、ホラクラシーの詳細は社内でだれも理解していない状態だったので、HOLACRACY 役職をなくし生産性を上げるまったく新しい組織マネジメントを読んで勉強した。Holacracy One というホラクラシーの組織管理ツール(GlassFrog)を作っている会社の代表が書いている本で、ホラクラシーを導入すべき理由からホラクラシーの運営方法まで一通り書いてある本でよくまとまっている。 現在日本語で読める本はこれ一冊のみ!という感じなので、丁寧に翻訳されていてよかったという感想だ。

英語ではWebでホラクラシーの運用方法が公開しており、うちの代表が抜粋して和訳している。 本を買う前にどういう組織運営をすることになるのか知りたい方は読んでみると良いかもしれない。

メリット

個人的にはホラクラシーを導入したときに得られる一番大きなメリットは現場のメンバーが経営層の目から届かなくなった時に得られると考えているため、まだ社員20人弱のうちの組織ではホラクラシーのメリットが十分に得られていない可能性がある。それでもいくつか良い点を感じることができた。

1. 責任範囲が明確になり、意思決定の速度が早くなった

実際にあった例でいうと、Product Manager と UX Designer がそれぞれ製品の仕様を決めるときに、ホラクラシー導入前、つまりお互いがどこまでを担当するか明文化されていなかったときには、お互いの考えが衝突したときに「PMがそこまで言うならもうそれでいいよ」というように決めてしまうことがしばしばあり、時間をかけて議論した結果お互いスッキリしない意思決定を下してしまうこともあった。ホラクラシー導入後はUX Designerのドメインを「プロダクトの情報設計 / インラタクションデザイン」と明確にしたことにより、UX Designer が最終決定権を持つことになり、意思決定の速度を早めることができるようになった。PMや開発者など周りのメンバーも「こういうデザインのほうが良いのでは?」という意見は投げるし、Bizサイドからもお客さんの声をUX Designerに投げるが、それらの意見を聞いて総合的に判断した結果、なにをどうするかはUX Designerの独断で決まる。そういった意味では、ホラクラシーはお互いを尊敬し信頼し合えるメンバーで構成されたチームでないと上手くワークしないフレームワークかもしれないと感じるところがある。

2. だれがなにをやっているのか明確になる

(うちはスクラムで開発しているのだが)最近ぼくはスクラムで言う「開発チーム」を抜けて「プロダクトオーナー」になった。まだ小さな組織なので意識的に共有しなくてもBizチームもその変化を知っているが、これが100人超の組織になると今だれがどういう役割を担って仕事しているのか正確に把握するのは難しくなる。 そうなったときにも、ホラクラシーで役割が明確化されていれば、今自分が持っている課題は誰に相談しに行くべきか瞬時に把握することができ、「誰に相談してよいか分からないからとりあえずマネージャーに相談する」というような非効率なコミュニケーションルートはなくなるだろう。 ただしこの一覧性/検索性はツールに依存するところもあり、一番メジャーであろうGlassFrogではそれが実現できていない。

(また脱線するが) GlassFrog は本当にひどいプロダクトで、ホラクラシーが広がらない理由の一つにこのプロダクトがイケてなさすぎることが挙げられるレベルだと思う。 今から真面目にホラクラシーの組織管理サービスを作ったら容易に世界No.1を取れるので、暇をしている人は作ってみると良いと思う。

デメリット

ミーティングに取られる時間が長い

ホラクラシーのミーティングは特殊な進行方法を取っており(詳細は割愛)、これは普段あまり声をあげない人の意見も汲み取るためのプロセスのように感じる。良くないMTG例の1つに、声の大きい人の意見がなんとなく通ってしまって、なんとなく意思決定が行われてしまうものがあげられるが、ホラクラシーのMTGはそういった事はない。 それはそれで良いのだが、1つの意思決定を行うために複数のフェーズで全員が発言をする必要があり、予想以上に時間が取られる。成熟したチームにおいては、もう少しそのプロセスを簡略化するほうが効率的かもしれない。

おわりに

久しぶりに記事をかいたら、「です・ます調」から「だ・である調」に変わってしまっていたが、書き直すのも大変なのでこのまま公開することにする。

新1分間マネジャー を読んだ

読み終わってから2週間ぐらい経ちますが、新1分間マネジャー――部下を成長させる3つの秘訣 を読んだのでそのまとめです。 (若干記憶が薄れているので、誤ったことを書いていたらすみません)

私はマネジメントをしたことがなく、そこまでガッツリマネジメントもされたことがないのですが、このような人が初めてマネジメントをする立場になった時に、初めに読む本としてすばらしい本だと感じました。

"新" とは

「1分間マネジャー」は1982年に書かれたもので、当時はトップダウン型のリーダーシップが当たり前だったためそれを前提に書かれた内容になっていましたが、「新1分間マネジャー」は2015年に出版されており、現代的な横並びの協調的関係が反映された内容になっています。

満足することでパフォーマンスが上がる

「自分自身に満足している人は満足できる結果を生み出す」という真理が書かれていました。最近1年の仕事振りをふり返ってみても、確かに自分自身に満足している時の方がパフォーマンスが高かったように感じます。例えば、スケジュール通りに開発できていて、自分の開発速度に自信を持てるようになってさらに高速に開発できるとか、新しい技術を身につけられている実感があってさらに新たなことに挑戦したくなる等ですね。
これからは1on1で「あなたは今の自分に満足していますか?」と聞いてみるのも良いかなと思いました。

マネジャーは答えを教えない

マネジャーが意思決定をしてしまうのではなく、部下に自分で意思決定させることが大事だと書かれていました。自ら意思決定することで、"自分で" 成功を掴み取ったという自信になり、そしてその自信が高パフォーマンスに繋がっていくようです。(上で言及した内容ですね)

部下が困っている時には

  • なぜそれが起きていると思う?
  • それを解決する方法は例えば何がある?

というように自分で答えを見つけるための道筋を提供してあげると良さそうです。

1分間マネジメント

マネジャーは複数の部下を持っており、また自分自身のタスクもあるため、マネジメントに多くの時間をかけることはできません。その中でどう効率よく部下のパフォーマンスを上げるのかが大事になります。1分間でマネジメントするために「1分間目標」「1分間称賛」「1分間修正」という3つの秘訣があります。

1分間目標

  • 何をいつまでに行うのか、3~5つ目標を立てる。目標は1分で振り返ることができる量にする。
  • 目標を見えるところに貼っておくことで、部下は毎日自分自身をマネジメントすることができる。
  • 目標がなければピンのないボウリングと一緒で、何を倒したらいいのか分からない。

1分間称賛

  • 最初(初めの1ヶ月)のうちは部下の行動やパフォーマンスを観察し、正しいことを行っていれば称賛する。
  • 逆に問題があった場合には、1分間修正を行う。きちんとフィードバックをするので、最初のうちはぎくしゃくするかもしれないよと事前に伝えておく。
  • (褒め方については後述)

1分間修正

  • 誤った行動をした時に修正を促し、さらに高パフォーマンスで働けるようにする。
  • 事実を検証し、一緒に振り返る。
  • マネジャーがそのミスによって組織がどれぐらい影響を受けるのか説明する。その後部下に考えさせる時間を数秒与える。
  • そのミスは取り返せること、このミスによって信頼が揺るがないことを伝える。
  • 部下の成功を応援していることを伝える。
  • 起こした行動に対してのみ指摘を行い、人間性は肯定しなければいけない。

褒め方

私は子供のころから「すごいね!まぁでもできて当然でしょ〜」という感じであまり褒められることなく育てられたことが影響してか、他人を褒めることがニガテです。笑
本には小さなステップごとに褒めるという方法が書かれていて参考になったため紹介します。

覚えたての段階では最初から100点を求めるのではなく、60点ができたら褒める、80点ができたら褒める、最後に100点ができたら褒めるということが大事です。 例えば、「水をください」と幼子に言わせたいとする時、最初は「みじゅ」と近い音を発しただけで褒めてあげます。そうすることで、この発音は正しそう!ということが理解できます。しばらくしたら「みず」と正しく言えた時だけ水をあげ、次のステップでは「ください」まで付けて言おうね、と教えます。
概ね正しい方法でやっていたらその都度褒めてあげることが大事なようです。

最後に

物語になっていて2,3時間で読める短めの本でしたが、勉強になることが大変多い本でした。 気軽に読めるので、定期的に読み返そうと思っています。

この方法は仕事だけではなく家庭でも使えると書かれていました。
1分間目標の存在を知る前から私も取り入れていて、「一緒に住んでいて相手の気になる部分を3ヶ月で2つ直そう!」といって彼女と一緒に紙に改善目標を書いて壁に貼り、月末にお互いの行動を評価しています。(お互いコレを直そう!と共通認識化するのと、3ヶ月で2つという少数に的を絞って行動を改善するのが肝)
まわりの人にも勧めていますがこれが結構オススメで、問題を目標化しておかないと「また今日も指摘された…」「もうわかってるよ…!!」「4つも5つも一気に言われても困る!!」と喧嘩のもとになりがちですが、重要度の高い問題1つ2つを目標として管理しておくと「最近ちゃんとできてるね〜!」や「これ未だに習慣化できてないけど、どう工夫したら良いかな?」などポジディブなコミュニケーションが増えるような気がしています。 みなさんも是非試してみてください!

スクラム向けの残業時間集計ツールを作りました

先週会社で1on1をやった時に、最近showwinさんのブログ更新されてないですよね…?と言われてしまいました…笑
ということで、今回は最近作ったコマンドラインツールの紹介です。

sokot

最近2週間ぐらいで sokot というコマンドラインツールを作りました。

github.com

会社では KING OF TIME で勤怠管理をしているのですが、そのAPIを叩いてチームごとの残業時間を集計するものです。

Regional Scrum Gathering Tokyo 2018 に参加してきました - しょ〜うぃん広場

の記事にも書きましたが、スクラムの手法においてスプリントのベロシティーが上がっているように見えていても、実はチームの開発効率はあがっておらず、単に労働時間が増えているだけだった。という可能性があります。 そのような事態が起きていないことを確認するために、このツールを作成しました。

sokot の名前は Scrum-Overtime-KOT(KING OF TIME) の頭文字から来ています。

インストール

Python3 が入っている環境で

$ pip install sokot

だけで完了です。

使い方

まずは初期設定です。

$ sokot configure
Token:  # APIトークンを入力
Saved to '/Users/showwin/.sokot/token'

Sprint Length (Default: 2):  # 何週間のスプリントで実施しているか入力
The First Scrum Day (Default: 2018.01.01):  # スクラムを始めた日を入力
Saved to '/Users/showwin/.sokot/config.json'
OK

設定ファイルはすべて ~/.sokot/* 配下に保存されます。

トークンが有効であることを確認しましょう。トークンを発行する時に指定したIPアドレス以外からリクエストを送ると False が返ってきます。
(私はIPアドレス制限があることをすっかり忘れていて、貰ったトークン使えないじゃん!ってサポートに問い合わせました…笑)

$ sokot available
True

次にチームの登録をします

$ sokot group add dev_team_1 0003 A0004 0011

このコマンドではメンバー3人の dev_team_1 チームを登録しています。 メンバーの番号はKOTの管理画面に出てくる、下の枠内の数字です。 f:id:showwin:20180226090426j:plain

これで準備完了です。

$ sokot overtime
+------------------------------------------+------------+
|                Sprint No.                | dev_team_1 |
+------------------------------------------+------------+
|   Sprint #1 (2018-02-05 - 2018-02-18)    |   45.97    |
+------------------------------------------+------------+
|   Sprint #2 (2018-02-19 - 2018-03-04)    |   26.35    |
+------------------------------------------+------------+
|   Sprint #3 (2018-03-05 - 2018-03-18)    |   34.73    |
+------------------------------------------+------------+
|   Sprint #4 (2018-03-19 - 2018-04-01)    |   28.01    |
+------------------------------------------+------------+

チーム dev_team_1 の3人が2週間の間に残業した時間が出力されます。

Future Work

今後の追加機能としては、残業時間合計をメンバー数で割って、一人当たりの平均残業時間を出力することと、HTTP Proxyの設定を追加できるようにすることを考えています。 APIが固定のIPからしか叩けないので、おそらくどこかIPを固定したサーバーからこのツールを叩くことになると思うのですが、毎回そのサーバーに入るのが面倒なので Proxy 機能欲しいなぁという感じです。

requestsのproxy を使えばサッとできると思ったのですが、squid で立てているプロキシサーバとなぜかうまく繋がらずハマッています…

Team of Teams を(途中まで)読んだ

2018年は3週間毎に技術の勉強と、組織/マネジメントの勉強を繰り返す予定を立てていますが、1月21日~2月10日は後者の勉強期間です。 (1月1日~20日はVue.jsを勉強してたのですが、思ったより時間がかかっていて終わってません…)

2017年末から TEAM OF TEAMS (チーム・オブ・チームズ) を読んでいたので、今回の勉強期間ではその続きから読むことにしました。 全体の55%ぐらいしか読んでいないですが、簡単にまとめます。(途中で諦めた理由は後述)

本の概要

本の主張としては「トップダウンでマネジメントしていく従来の方法では、変化が激しくより複雑である近年の課題を解決するのは難しい。下部のチーム/個人に十分な権限を与えて主体性を持って行動させることによって、それらの課題を解決することができる。」というものであったと思います。

この主張の正当性を主張するために、米軍とアルカイダの戦闘の例や、NASAアポロ計画についての事例が取り上げられています。(こういった事例の紹介が本のほとんどを占めていたため、残りの45%は読むのをやめてしまいました。。実は後半の方が大事だったりして…)

米軍とアルカイダの戦闘の例を紹介すると、 米軍は過去の成功体験から、ピラミッド型のトップダウンな組織で構成されており、各チームにはプロジェクトの目標とそれに関する必要最低限の情報のみが与えられている状況でした。 そのためあるプロジェクトの途中に他のチームにとってはとても貴重である情報を見つけたとしても、その価値が分からずに見逃してしまい、与えられた目標のみを追いかける内に向いた組織になってしまっていました。 一方でアルカイダは、末端の戦闘員までアルカイダの最終目標を認識しており、それを達成するために全員が同じ方向を向いて、目標達成のために何をすべきなのか自分で考えて行動するような組織構造ができあがっていました。 (個人的には「ピラミッド vs WWW(ワールドワイドウェブ)」な対象的な組織構造だと感じました。)

そのためアルカイダの幹部を暗殺しても、組織全体が方向を見失い壊れてしまうようなことはなく、アルカイダの撲滅には苦労したようです。 また毎回目標や戦略が上から降ってくる形になっていた米軍は、その間に戦況が変わっていてそれが全く役に立たないものになっている場合もあり、素早い状況の変化に対応できない構造になってしまっていました。

そこで、米軍は「チームの中のチーム」という方針で、配下のチーム同士の関係が単独のチームの内でのメンバー同士の関係に似た組織構造を作ることにしました。 つまり今までは上下関係の間でのみ情報共有がなされていましたが、方針の転換によりチーム同士の横関係の間でも情報共有が許されるようになりました。 情報共有についてだけではなく、役割、意思決定権限、リーダーシップに関しても、従来とは全く逆の手段が導入され、アルカイダと同じように末端のチームで意思決定が行われるようになったのです。


この本は、某なんとかStationというゲーム機を作っている会社のマネジャーさんにオススメされて読み始めた本なのですが、某社ぐらいの大きな組織だと、この本から学ぶことは多いのかもしれないと感じました。 私自身大きな組織に属したことがないので、ピラミッド型組織の課題感を肌で感じたことがないのですが、これから弊社が大きくなっていく中でどういう組織構造を作っていくべきなのか、少し明確になった気がします。

組織/マネジメント勉強期間はあと1.5週間あるので、昨日から 新1分間マネジャー という本を読んでいます。こちらは薄い本なので、1時間で60%ぐらい読んでしまったのですが、マネジメント素人にはこちらのほうが学びが多いです(笑) こちらも読み終わったらまとめ記事を書こうと思います。

Regional Scrum Gathering Tokyo 2018 に参加してきました

気分が良いので、1日で2記事書きます。笑

1月11,12日で Regional Scrum Gathering Tokyo 2018 に参加してきました。 イベント自体は13日まであるのですが、2日間で得た学びが多く、これ以上インプットすると頭が弾けそうだったので、2日でやめておきました。

参加したきっかけ

弊社 scouty では複数人開発が始まった2017年10月からスクラム(っぽい)開発を始めています。 開発メンバーはだれもしっかりとしたスクラムでの開発経験がなかったため、始めの一ヶ月半ぐらいスクラムの経験が豊富な外部の方にアドバイザーとして入ってもらっていました。

プロセスの改善を続けて、最近では落ち着いてスクラムな開発ができるようになってきたのですがまだまだ不安な点もあり、ちょうど関わりのあった eureka の @kajinari さんに相談したところ、このイベントを紹介してもらいました。

イベントで学んだこと

聞いていた発表はだいたいTwitterでリアルタイムまとめをしていました。 #RSGT2018 showwin で検索するとみれます。

twitter.com

自分的に良いなと思ったものをいくつか列挙すると、

これは1日目のKeynoteの内容なのですが、会場でも頷いている人が多かった話でした。 今回のイベントでも、これ帰ったら試してみよう!というものがいくつもあった(後述)ので、 うまくいくかわかりませんが自分のチームで試してみたいと思っています。

Run the experiment !!


(スレッド機能でつなげてかいていたので、前のツイートも表示されてしまっています)

サイボウズさんで、ウォーターフォールからスクラムに切り替えたことで得られたメリットの話です。 うちのチームではまだまだこれらのメリットを享受できていないので、こうなれるようになりたいなと強く思いました。

・残業がほとんどなくなった

(発表では触れられていませんでしたが)ベロシティが上がっているように見えているけど、実は残業時間が増えているだけだった、ということが起きうるなと自分で勝手に思っていました。

スプリントレビューの時にベロシティの確認と一緒にチーム全体の残業時間を確認してみると面白そうなので取り組んでみます。

・スプリントの計画を達成した後のんびり過ごす (空いた時間でKAIZEN)

に関しては、いろいろと思うことがあります。

私はスタートアップ(scouty)で働いているのですが、完全に同じことをしている競合は今のところいないため、先行優位性を活かして(なるべく早く製品を成熟させ)今のうちにマーケットを取りに行きたいという会社としての思いがあります。

そのため、今スプリントの計画を達成したら、次スプリントのバックログからタスクを引っ張ってきて新しい価値の提供に取り掛かりたいのです。 そしてまた、そうすることでのみチームのベロシティが向上していることが測れるのでは?とも思います。

一方で、その方法ではスプリントの計画を早く達成しても何のアメ(ご褒美)も与えられず、高いモチベーションを保って開発を続けるのは難しいとも感じます。 KAIZEN系のタスクを定義してスプリントに突っ込むのは、"やらされてる感"があってちょっと違うなぁとも思い。なかなか自分の中で納得いく答えが出ません。 (私も"やらされてる感"のある仕事って大嫌いなので、ちょっと空き時間に「ちょっとこのページの描画遅いと思ってたから高速化しといたよ🤤」みたいなことをしたいんですよね。。)

ここは組織の状態によって答えが違う部分な気がするので、POとちゃんと話し合う必要がありそうです。

・ペアやモブワークを行うことが多くなった

この発表に限らず、いろいろな人と話していても、うちでも取り組んでいるよ。という話をよく聞きました。 スクラムガイドには、開発チームの特徴として

• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
(略)
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。

とあり、開発チーム全員が共通なスキルセットを持ち、どのタスクでもこなせることが理想であると書かれています。 そのために、みなさんスキルトランスファーを目的として実施しているようでした。

その他にも複数人で開発することで、タスクを誤解していてレビューされてやり直しになる、のようなことも起きなくなり、レビュー済の状態に近い精度で開発ができるメリットもあるとのことでした。

弊社でも、ネット上の不定形/非構造なデータを扱っていることや、(機械学習まではいかないレベルの)複雑なドメインロジックの実装が多いこともあり、タスクによってはレビュー→差し戻しが多く発生するものがあるため、そういった難易度の高いタスクに関してはペアワークをすることで開発効率があがるかもしれないと思いました。


これについては私も同意で、技術が発達したことにより高い専門性を保つためには、多くの時間を学習につぎ込まないといけない世の中になっていると思います。

個人的には、バックログのうち8~9割ぐらいのタスクについては全員ができ、他プロダクトとの優位性に関わるような1~2割の部分は高い専門性をもった人しかできなくても仕方ないと思っています。 むしろその1~2割ができる稀有な人材を確保できているからこそ、その組織が他に勝てるのではないでしょうか。

弊社では採用基準の一つに「既存のメンバーが持っていない特長(スキル)をもっていること」というものがあります。当然人が増えていくにつれてこの条件を満たすのは難しくなっていくため、どこかでこの条件を諦めないといけなくなるフェーズは来ると思っていますが、なるべく長く続けていき最強のチームを作りたいと思っています。

今回答えがわからなかったところ

私自身 SCRUM BOOT CAMP THE BOOK を読んで、イベント中に スクラムガイド の存在を知ったぐらいの勉強不足スクラム初心者なので、CSMの研修などを受ければわかるようになるのかもしれませんが、デイリースクラムのフォーマットの価値が未だによくわかっていません。 スクラムガイドには

• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
• 私や開発チームがスプリントゴールを達成するときの障害物を目撃したか?

を共有すると書かれています。「輪になって口頭で共有する」とは書かれていませんが、イベントに参加してこのようにやっているチームが多いように感じました。

弊社では、上記2つについてはデイリースクラム前にSlackで各自文字ベースで報告するようにしており(そもそもKANBANを見ればわかる)、デイリースクラムではBurndownが予定通りかと、障害物がないかの2点のみ確認するようにしています。それにより時間短縮ができ、Burnが予定どおりではなかった場合に、小さなふりかえり/スプリント計画をデイリーで行えています。

デイリースクラムの目的が "スプリントゴールを達成するため" であれば、単なる報告会よりもこちらの方が有効な気がしているのですが、どうなんでしょうか。 答えをお持ちのスクラムマスターな方々 @showwin にツッコミ頂けたら嬉しいです! (答えを頂いたので最下部に追記しています)

帰ったら試すもの

  • スプリントレビューでベロシティと一緒にチーム全体の残業時間を確認する
  • 複雑なタスクはペアワークで取り組み、生産性があがるのか、働き方に対する満足度が上がるのか確認する
  • スプリントレビューで機能開発タスクとバグ修正タスクの比率を確認する (長期的に見て70%機能開発が理想)
  • スクラムイベントのファシリテートを別の人にやってもらう (スクラムマスターがでしゃばりすぎず、開発チームにも主体的に動いてもらうために、一度経験してもらって何か変化があるのかみてみたい)
  • POもリファインメントに参加する。(現状開発チームがメインでリファインメントしているが、タスクの定義が曖昧なものもあるので、事前にPOに行ってもらう)
  • リリース可能かどうかはPOが判断する。(POが忙しいので、SMの私が品質の確認もしてしまっている状態)

代表がPOをしているのですが、経営に集中させたいので、(エンジニア社員が増えたら)そこからPOを任せる人を別で立てないと、今のままでは役割を十分に果たせないなと感じています。

おわりに

Regional Scrum Gathering Tokyo 2018 の運営に関わっていた皆さん、ありがとうございました!とても勉強になったカンファレンスでした。来年も参加します!

繰り返しになりますが、イベントを紹介してくれた @kajinari さんありがとうございました!!

追記

@ryuzee さんと @haradakiro さんからデイリースクラムについてご意見頂きました。ありがとうございます!

上で私が参照していたのは、2016年7月版のスクラムガイドでしたが、2017年11月にスクラムガイドの改訂があったようです。

2017年11月版では、デイリースクラムの章に以下のような説明がありました。

デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のやり方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえば、以下のような例を使用するといいだろう。
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
• 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?

中身の例として上の3つが提案されている形になっており、 "開発チームがスプリントゴールを達成する可能性を最適化する" 方向を向いていれば他の方法でも問題ないようでした。