生涯未熟

生涯未熟

プログラミングをちょこちょこと。

ランサーズ開発ランチにお邪魔してきた!

f:id:syossan:20180711115427j:plain

クラウドソーシングで超有名なランサーズさんが、開発ランチという面白いイベントをやっていたのでカツ丼食べたくてブログ枠として参加してまいりました!!

lancers-engineer.connpass.com

ランサーズ開発ランチ(Lunchers)について

このイベントはランサーズさんが開催している勉強会で、一ヶ月に1~2回というスパンで開かれております。
はてなのa_knowさんやオミカレのそーだいさんなど、著名な方々がゲストで招かれている素晴らしい勉強会です!

engineer.blog.lancers.jp

ブログ枠だと最高に美味しいトンカツが食べれるので皆さん参加しましょう!!!!

f:id:syossan:20180711120000j:plain

kakakakakkuさんによるお話

今回のランサーズ開発ランチのゲストは、

kakakakakku.hatenablog.com

の記事で1000ブクマを超える反響を呼んだkakakakakkuさんによる「プロジェクトの成功を支える ZenHub と モブプログラミング」でした!

僭越ながら、お話を聞いて個人的に「オッ」と思ったところを書き出していきます。

f:id:syossan:20180711120853j:plain

Backlogsにあるタスクにメンバーを割り当てない

手の空いた人が優先順位の高いタスクからサッと着手出来るように、Backlogsのタスクにメンバーは割り当てないようにする。
スキルがミスマッチの場合でも、時間がかかってもいいので着手するようにする。

スキルがミスマッチの場合でも〜、というのが個人的には刺さりました。
マネージャーが機能している場合、プロジェクトを円滑に終わらせるためにも事前にメンバーのスキルセットに合ったタスクの割り振りをやってしまいがちです。
しかし、それではメンバーのスキルセットの質や幅がいつまで経っても向上しないままなので、タスクにかかる時間を多少目を瞑ってもやらせる、ということなのでしょう。

途中、kakakakakkuさんが「サービス自体には興味がない。プロジェクトの達成とメンバーの成長に興味がある。」と仰っていたことを含んで考えると、感慨深いものがあります。

優先度警察

kakakakakkuさんが受け持つプロジェクトでは「優先度」という言葉は禁句らしいです。
というのも、「優先度」ではなく「優先順位」という言葉を使って欲しい、という気持ちから。

優先度だとありきたりな「高・中・低」で分けられてしまいます。
しかし、優先順位だと明確に「1, 2 3」とやるべきことの順番を決めることができます。
例えば、Aさんがタスクを取ろうとBacklogsを見た時に、優先度・高と優先度・高のタスクが同時に存在した場合にどちらを先にやるか悩んでしまいますよね。
そういったことが無いように、優先順位の一番高いものから着手できるよう「優先順位」という考え方を大事にしているとのことです。

質問タイム:前半

  • ZenHubはどこがオススメポイント? → 画面の見やすさ、Githubに紐付いた機能、Epic機能
  • Epicに紐付いた仕様はどう管理しているの? → 仕様書をGoogleドライブで管理してEpicにリンクを貼る
  • 優先順位がビジネスに左右される場合は? → 基本左右されないようにする。Doingに入ったものは変えない。Backlogs内だとバンバン変える。
  • Reviewingからなかなか進まない場合は? → 口頭・対面でレビュー進めるように言う(Doingより優先してやって!など)。WIP制限がReviewingを進めるという効果もある。1~3日の粒度のタスクなのでPRレビューもそんなにかからないはず。
  • ラベルの付け方は? → 全体、仕様、フロント、バック(Ruby etc)、デザイン etc...。スキルマップと照らし合わせて、ラベルを分ける。
  • 今後必要なんだけど今できないみたいなタスクは(技術検証とか)? → Backlogsに積んでおくといい。やるんだったら3日で終わるように調整する。
  • Reviewingの数は制限あるの? → ない。レビューが詰まるようならやる価値はある。

スウォーミングの考え方

タスクとメンバーの関係性を1:1から1:nと考える。
あるタスクに異様に時間がかかっている状況が発生した場合、手が空いたメンバーがそのタスクに関わるようにする。
その考え方の延長線上にあるものが「モブプログラミング」である。
スキルセット関係なく関わるようにすることで、個々のメンバーの強みが他のメンバーの強みとなっていく→強みの伝搬。

モブリリース

今回のお話の中で、この考え方が凄い良いなぁ〜と聞いておりました。
どういうものかというと、属人化しやすいリリース作業をモブプログラミングのように皆の前で行うことで、リリース作業の理解を広めるというもの。
手順書を作り、それを見ながらリリースするという方法もあるのですが、それよりもリリースのプロセスを可視化された状態で見て学んだ方がいいとのこと。
実際に人がやっている手順を見ることで、自分がやる時に安心して出来ますし、その場で「何故それをするのか?」といった質問も出来ますし、良い取り組みですよね。

質問タイム:後半

  • あるタスクが困窮していて、皆で助けにいった際にタスク全体のスケジュールが遅れる場合はどうする? → スケジュールを伸ばす。ビジネス側に文句を言われても無視する。
  • モブプログラミング開催の周期は? → 毎日やってるところもあるが、kakakakakkuさんのところは週1回。教育・息抜きのイベントのような扱い。モブリリースは頻繁にやっている。スキルマップと照らし合わせて、スキル的に難がある人が多い場合は、慣れてきたプロジェクト後半にモブプロを開始する場合もある。

まとめ

プロジェクトマネージャーという職を経験したことのない未熟な私にとっては、非常にタメになるお話の連続でめちゃくちゃ勉強になりました!
今回のお話の中で得た知識を、少しでも現場で活かせることが出来るよう頑張ります・・・!

ランサーズ開発ランチでは今後もドンドン魅力的なゲストを呼んで開催されるとのことなので、界隈の最先端にいる方のお話を聞きたい方は是非チェックしましょう!!