そーだいなるらくがき帳

そーだいが自由気侭に更新します。

適切な問題と文化がサービスを育てる

って話をPHPカンファレンス2018でしてきます（1時間後に過去形になります

って話をPHPカンファレンス2018でしてきました。

2018/12/16時点で動画とFAQの内容を追記しています。

phpcon.php.gr.jp

当日の登壇資料はこちら。

当日の動画です

www.youtube.com

※ 5:41:20 くらいからが僕の動画です。
※3ヶ月以内を目処にセッション毎に割ってくれるみたいです

内容補足

Webサービスは成長と共に変化していくので、つまりは変化に強いチームというのは重要になります。 では変化に強いチームとはどうやってつくるのか？って話が今回のテーマです。

チームビルディングってとても重要なのは周知の事実だけど、じゃあどうやって？って言うHow toは意外と語られません。 それは「答えが無い」ってのもありますが、プレイヤー目線とマネージャ目線（経営者も含む）で大きくアプローチが違うからっていうのが僕の最近の所感です。 プレイヤー、マネージャを両方経験した結果、プレイヤー側は文化から変える方が早いと思うし、マネージャ側は文化を形成するための組織や制度から手を付けるほうが早いと思います。

その視点の違いは重要で、プレイヤー側から組織を変えるのは大変だし、マネージャがいきなり文化を決めるために○○をしましょう！と言っても現場が付いてこなければなかなかうまく行きません。 そのへんを僕がオミカレでCTOになってからの半年でずっと試行錯誤していて、その話が上記のスライドになります。

実際のHowの話

スライドの中には明記されてませんが、マネージャ側が用意する方針として大きく次の4つが大事だなと思っています。

  • チャレンジするための仕組み、つまり評価制度
    • 責任を現場に押し付けない責任の明確化
  • 適切な問題を設定するマネージメント
    • 適切なタスクの委譲
    • 各人、チームに合わせた問題設定
  • 新しい問題、大きな問題を生み出すビジョンを作る
    • これは経営者の仕事とも言えるかもしれません
  • チームメイトを信頼すること

成長してもらうためのチャレンジと評価について考えたことは参考URLのエントリにまとめています。

適切な問題を設定することはとても難しいし、その為にXPだったりスクラムだったり色んな手法があるわけですが、ここは正直僕も試行錯誤中だし答えはありません。 だからこそ1on1をやったり、Backlogの粒度を調整したりするわけで、全ては適切な問題を設定出来るか、って言葉に尽きると感じています。 適切な問題については任天堂の岩田さんの記事がめちゃめちゃ参考になります。

あとはもう設定したらチームメイトを信じる。例えば「チームメイトが辛い」と言えばそれは辛い。「俺ならそれくらい平気だけど？」ってなってもそれは自分の話であってメンバーは言い難いことを伝えてくれてるわけなので一方的にまず信じる。見積もりがズレたら「なんで出来なかった？」ではなく「どうやったら次の見積もりが正確になるか？」って話をする。そういうことがチームメイトを信じるってことだと思っています。 大事なのは丸投げすることと、信じることは違うと言うことです。 適切にフォローしながらタスクを任せる。そのタスク粒度を適切な問題のサイズにする。そういうことを出来る仕組みはなにか？ってことを考えて導入するのがマネージャの仕事だなと思います。

プレイヤー目線の話

PHPカンファレンス仙台で id:ikkitang1211 がプレイヤー目線で話をしてくれます。 プレイヤー側からもプロダクトやチームを良くしていける話、めちゃめちゃいい話なのでご期待ください。

phpcon-sendai.net

まとめ

Webサービスを成長させるためには組織やチームの成長が必要で、そのために文化を育んでいく必要があります。 それは時間がかかる事なのだけどとてもとても大切なことで、僕はそれを引き続き頑張っていきます。 そーだいさんの次回作にご期待下さい！

FAQ

当日あった質問を記載します。

適切な問題の判断基準ってどうやって決めますか？

記事の中でも出てるけど一番コレが難しいです。 とは言え、やっていかなきゃいけない。だから適切な問題の設定の粒度調整や見積もり調整などの質を上げるために1on1やったり、コミュニケーションをしっかり取ることが大事かなと思っています。 これはプレイヤー側の性質、得意不得意によって適切な問題のサイズや内容が変わるためです。

あとは適切な問題が出来たかどうかを判断するためにはKPTやKPIを設定してしっかり振り返り、次回に活かす、そしてそのサイクルを早くするために1週間スプリントを設定したり、進捗を可視化するためにカンバンを用意したりなどしています。

なので適切な問題を設定するための手法やツールはいろいろあるのでそれらで自分たちにマッチした方法を模索しながらやっていくしかない。と思っています。

今、満足してる人に対しての問題設定をどうやっていくか？

新しいことをすることだけがチャレンジではなく、今出来ていることをよりクオリティを上げていきましょう、という問題を設定するようにしています。 例えば単純な処理だけでも、月1000件を対応しているのであれば1001件を目標にしましょう。などを設定するのが良いと思っています。

それすらも難しいって場合は、プレイヤーの成功体験が足りていません。つまり成功体験が無いのでやる意味が見えていない。なので大切なことは小さい成功体験を繰り返し体験させて上げるのが大事です。

その中でも僕が特に大切にしていることは とにかく褒める ってことは大切にしています。 その延長に評価があると思っています。 勿論、チームにとって不適切な対応が会った場合は叱るなどの厳しいフィードバックを送ることも必要なのだけど、割合で言えば 9.5:0.5 くらいで褒めるようにしてます。

外注の先をどのようにコントロールすればいいですか？

外注先こそ、しっかりコミュニケーションを取るってのがまず大事です。 この時、1時間のMTGを週に1回やるよりも、5分の会話を毎日したほうが圧倒的効果があります。これをザイオンス効果と言って、人は接する回数が多いほど、好印象を持ちます。

あとは思ったとおりのアウトプットが帰ってこないのであれば「渡している問題のサイズが大きすぎる」のだと思います。 その場合は細分化してやればよく、そのための手法として仕様書を書いたり、要件定義をしたりなどがあります。細分化を突き詰める技術やツールについてはSIerの手法がとても参考になります。

問題を発見するのが現場の場合、どうやってタスクを設定するか？

弊社の場合はこれは1週間スプリントと日報と分報(times文化）の3つの時間軸で対応しています。 まず一般的な方法でわかりやすいの1週間スプリントです。現場が問題を見つけたらIssueを作る、そしてマネージャはそれを定期的に棚卸しをして設定する。これの少し粒度が小さいのが日報です。 日報の中に「今日あった問題」って枠があって、それを毎日の開発朝会で共有してます。この時、場合によってはタスクが増えたり、優先順位を変更したり、サポートを用意したりする調整をしています。 それでも1日1回ではスピード感が出ないので分報もやっています。 分報はさきほどのザイオンス効果と問題を早めにアウトプットする、の2つの効果を持っており、大事なのは誰かが発言したら反応する人が居るということです。誰も居ないところでは誰もアウトプットしないので自分が積極的に反応してみんなのアウトプットを促すようにしています。これはマネージャの仕事の一つだと思っていて、勿論僕自身も積極的に分報を使っています。

コレ以外にも「緊急性の高い、突発的な問題」というのもあって、これは例えばサービス障害などに当たります。この場合は裁量をプレイヤーに渡す、そしてマネージャが必要なのはどんな結果になっても責任を取ることが大事です。 裁量を渡す、をもう少し具体的にするとスピード感を持って対応してもらう必要があるので、迷わないようにガイドラインを用意する、エスカレーションフローを明記する、対応手順を事前に準備するなどがあります。

そしてその2つがうまく出来ない時は多分、マネージャが現場をコントロール出来ていない、見えていないのだと思います。つまりチームにとって「問題設定をする人が居ない」のであれば、結論自分がやるしかないと思います。 これは役職、ロールとしてマネージャを持っていなくても、実際にはマネージャのタスクを自分がやるということでプレイングマネージャーをやりましょうってことになります。そして文化を変えていく、この時大事なのは自分以外の人を巻き込むこむ、他の人をマネージメントするということで一人で戦うことは辞めましょう。残念ながら一人で戦うことはとてもとても厳しく、多くの場合に続きません。 仲間が見つからない場合、それはよほどのことがない限り諦めて転職した方が良い。となってしまうと思います。

質問箱に対する回答

参考URL

soudai.hatenablog.com

soudai.hatenablog.com

ほぼ日刊イトイ新聞 - 適切な大きさの問題さえ生まれれば。

employment.en-japan.com

soudai.hatenablog.com

party-calendar.net