瀬宮の球拾いブログ

エンジニアだったはずが、みんなにヘイストかける方がチームに貢献できた男のブログ

リファラル採用が、大企業に向かないよね、と思った話

タイトルが微妙に誇大だと思った。

リファラル採用は、友人からの自分の信頼を賭け金にして、友人を自分の会社に対して紹介する制度、という側面を持つ。

なので自社の募集と友人の内定に対してある程度の成算がないと友人を紹介しづらい。

経験上、もっともエンジニアのリファラル採用が強いのはエンジニア組織の規模が20人以下であるケースである。
20人以下だと、「誰がどの技術を使ってどういう仕事をしているか」がほぼすべての職種に対して説明できる。
シニアクラスなら、マネージャークラスからメンバークラスまで説明できる。
なので暗黙的にジョブディスクリプションを自分で組み立てられるので、内定への成算を計算しやすい。

逆に、エンジニア組織が100人を超えると、自分のチームや部門以外のエンジニアの仕事が説明できなくなる。
説明できない=成算が低いので、「友人からの自分の信頼」を賭け金にするには分が悪くなる。

この対策としては、単純に言えば募集単位でジョブディスクリプションを書けばいい。
ただしこれは難しい。

現実的アプローチとしては、クックパッドの人事部長(当時)だったyoshioriさんのアプローチが観測範囲では最善だった、と何度か熱弁したことがある。
ただしこれが本当にいいかは、自信がない。
詳しく聞きたい人は私に酒を飲ませるとペラペラと喋ると思う。
求むディスカッションできる人。

moduleに skip_before_action を書いたら undefined method 'skip_before_action'

継承元のControllerで宣言されているbefore_actionを、継承先でskipさせたい。
かつ、skipさせたいクラスは複数あるので一つのhelperにまとめることにした。
そのために以下のコードを書いた。

module Api::Concerns::SkipAclHelper
 skip_before_action :has_allowed_acl?
end

include Api::Concerns::SkipAclHelper

したところ undefined method 'skip_before_action'

[原因]
moduleを読み込んだ段階で、Controllerに定義されるべきskip_before_actionクラスメソッドが書いてあったので「そんなん知らんわ」となった。
であるのでActionController::Baseを継承したクラスの中にskip_before_actionは書くべき。
しかしmoduleにActionController::Baseを継承させることはできない。
[対策]
include先では継承されているので、継承先で展開されるように以下のように書いた

module Api::Concerns::SkipAclCheckable
 extend ActiveSupport::Concern

 included do
  skip_before_action :has_allowed_acl?
 end
end

  includedは ActiveSupport::Concern の中で定義されているので ActiveSupport::Concern をextendする。
これで動いた。

なぜスクラムの経験がない人間ほどベロシティに固執するのか?

チームにおいて「スクラムを導入しよう!」という機運が盛り上がることはよくあることだと思います。
またそういう状況において、主導者がスクラムの経験者、特に導入経験者であることがあれば非常に運が良いでしょう。

しかし逆に、主導者が経験がなく、特に本を読むこともなく、熱意先行型であるケースもあると思います。
こういったケースにおいて、往々にしてあるのが「ベロシティ」を「生産性」と捉えてベロシティの前スプリント比xx%アップ!というような、営業チームのような目標を掲げてしまうケースです。

経験豊富な人間に聞くまでもなくアンチパターンど真ん中です。
しかしなぜか繰り返す人間は後を絶ちません。

このケースはなぜ起きるのか?っていう話を友人たちとしました。
議論の結論から言うと、この手の人間は
・「生産性を上げたい」と漠然と思っていて
・それでいて生産性指標を計算したこともなく
・生産性という言葉の意味と効能もあまりよく知らない
タイプが多いです。

彼らは 「ベロシティ」 という生まれて初めて見る「生産性(に見える)」指標に興奮し、そこに固執してしまうのだろう。
知識がないからベロシティを拡大する弊害もわからないし、無意味な指標を「生産性」と呼ぶことを経験者がどれほど忌避するかもわからない。
だから止めることができないのであろう。
という結論でした。

過去に見たベロシティ中毒の患者たちは、確かに上記の条件を満たしていたように思います。

タスクをReadyにしないとなにがまずい?

タスクをReadyにしないとなにがまずいか?

たまに聞かれる質問です。

簡単に言うと
・見積精度の向上
・タスク失敗率(炎上ないし未完成での撤退)の大幅な削減
・プロジェクトのリスクの削減
の3つです。

タスクが予想より大幅に時間がかかるケースにおいて調査したことがあります。
実態としてはReadyになってからDoneになるまでのリードタイムは予想通りだったのですが、Readyになるまでの時間が大幅にかかっていました。
またReadyになった段階で作業量がほぼ確定します。
ですのでReadyになっていない=作業量が確定していません。
この段階で「3日で終わります」というのは非常にあやふやな見積りです。見積りというより勘による占いです。

そしてこの勘がはずれて、炎上し、最悪撤退する。
それらが積み重なってプロジェクトのリスクになる、というわけです。

以上の理由から私のチームにおいてはReadyにないタスクを着手することを認めていません。
確実性のない計画表は、予定というよりは願望に過ぎないと考えているからです。

リードタイム短縮のために、Readyになるまでの時間短縮の試み

スクラムコーチをしているようなマスタークラスの人と話すとよく話題になるのが下の話です。
未熟なスクラムチームはベロシティを「生産性」と勘違いしてとにかくその数字を伸ばそうとする
(実際には使われない機能が大量に作られるだけで意味がない)
熟練したスクラムチームはリードタイムを重視してとにかくその時間を短縮しようとする。
思い当たる節はないでしょうか?

さて、我がチームにおいてもリードタイム短縮は目下の急務でした。
生産性、というよりは機動性の高さに直結するからです。
リードタイムを妨げているのはタスクを ready に持って行くまでの「事前作業タスク」と当時呼称されていたタスクでした。
当時の計測で全体の9.7%の工数を食いつぶしていました。
機能追加に費やしていた工数が54%程度だったことを考えると20%弱あったことになります。
いったんreadyにさえすれば、高速でタスクは消化されていきます。
それはここまでで達成されていました。
問題はreadyにするまでのタスクの消化です。
そこで3スプリント使って「なぜreadyにならないか」「なぜこのタスクができたか」「回避方法はあるか」「どうすれば次のタスクからはこの作業をせずに済むか「どうすればこのタスクを生まずに済むか」を調べながら優先して消化することにしました。
当然のごとく当初は「事前作業タスク」の消化スピードが半減しましたし全体の消化スピードも低下しましたが、もはややむをえない、と判断していました。

3スプリント後には以下の効能が得られました。
・在庫だった「事前準備タスク」の87%減
・「事前準備タスク」の再生産ペースの54%減
・「事前準備タスク」所要工数の72%減
おそるべくして減っています。

なぜ俺たちは作業スピードを落とすこいつらを生んでしまったか?を意識したところ、「じゃあ生まないように作業しよう」という意識が浸透しました。
やはりメンバーの意識に染み込ませ、ボトムアップで進めた方が効果があるようです。
一部再生産やむなし、せめて消化スピードをあげようという方向で対応した部分もあるのですが、それはやむえないところです。
収穫逓減の法則に従っているので「撲滅」「根絶」に拘る意味がありません。

リードタイムそのものには6%程度の貢献と判断されましたが、開発ストレスが減ったことでそこは良しとされました。
また副産物として、事前準備タスクの根源は「歴史的経緯」「過去の負債」「惰性の不合理」にあったため、それらが除去されたことで一気に機動性は上がりました。
「生産性」や「スピード感」に拘ると積み上がっていく代物だったので、このタイミングで棚卸し&処分できたので良しとしています。

株式会社はてなに入社しました。

株式会社はてなに入社しました。

エンジニア採用するときに、地元ではスケールに限界があるので地方支社をつくろう、そこでエンジニアを採用しよう、という会社は多いです。
しかし大阪に支社を作る会社はセンスがないと思います。
なぜなら関西というのは、Bizの中心地が大阪であり、エンジニアの活動の中心は京都という珍しい地域です。つまり職種によって中心地のズレがあります。
きっと経営の意思決定をする方がネクタイを締めたBiz職で固められているとそうなるのでしょうね。
エンジニアのもつ現場感、とても大事です。

はてなは京都にあり、京都においてはこの規模だと大手、ブランド感というカンバンのパワーが大きいです。
私も今後ははてなerとして実力を発揮していこうと思います。

hitode909の日記

実際のプレイに即したQAを入れてわかった意外な事実。

私は趣味でゲームを作っています。
お仕事でもシステムを作っているのですが、色々と社外秘の多い業界ですのでWebで語るのは趣味にとどめます。

前回までのあらすじ:
開発に必要なエンジニアの工数が逼迫してきたため、QA作業をデザイナーの方にお任せしました。
ただ任せるだけではモチベーションが続かないので、開発版を使った実況プレイ、という形でファンに新作の機能のアピールをしつつバグ報告をしてもらうことにしました。
YouTuber気分で宣伝とQA、あとスタッフのモチベーションアップができるので大変良い!と思いました。

結果:
最初の頃は思ったより実況が盛り上がりませんでした。
理由としては、たとえば「勇者チームが土壇場で救出に失敗したのはわかった、なぜこの結果になったか?」という部分が実況者に不明で全盛期の古舘伊知郎風の実況がつけづらかったからです。

そこで開発側タスクに「その結果をもたらした数字を出すこと」というタスクが積まれました。
Before
結果:失敗!
After
成功率10%
技能スキルで+20%!
タリスマン装備の効果で+5%!
「才能:ピンチに強い」で+10%!
合計成功率45%!
結果:失敗!
というような表示を出すことで実況がしやすくなりました。

ユーザーの調査の結果以下のことがわかりました。
副産物その1: ユーザーは結果だけを求めていない(ジョジョ5部のアバッキオの先輩の画像は略)

ユーザーは結果だけを求めていません。「親友キャラ、城之内が死んだ」という結果だけを渡されても、それが大事なことだと十分に強調されていないために、若干戸惑います。

しかし実際にはこのような表示の方が「タメ」がある分、ユーザーは満足しやすいということがわかりました。
お願い、死なないで城之内!あんたが今ここで倒れたら、舞さんや遊戯との約束はどうなっちゃうの? ライフはまだ残ってる。ここを耐えれば、マリクに勝てるんだから!

次回、「城之内死す」。デュエルスタンバイ!

いやこれを見たとき「えっ、そうなの?長い分ダラダラしていやなのかと・・・」と思いましたが、計測結果=現実の方を優先すべきと考え以降は「タメ」を重視した演出を入れるようにしました。

副産物その2:
意外なバグが見つかる。
当時の新作は本命キャラ以外に操作不能なサブキャラとしてNPCキャラが多数登場するゲームでした。
上のように数字を出していたことで意外な事実がわかりました。
例を上げると以下の通りです。
天馬騎士フュリーは敵に敗北した!
逃走成功ポイント:20
レベルによるボーナス:42
スキルによるボーナス:30
クラスによるボーナス:25
合計:117
捕獲判定:
敵捕獲能力4 * 敵兵数27 = 108
117 > 108
フュリーは逃走に成功した!

こう書くとたいしたことないんですよ。
逃走成功点を捕獲点で割った数が捕獲成功率になる、結果が1を超えたら100%逃走成功。
これは仕様です。

でもね。
開発側はこのときまで気づいていなかったんです。
「レベルが高すぎると、捕獲イベントが発生しない」という事実に
これに気付かず一生懸命捕獲イベントを作っていたわけです。
「彼氏キャラが助けに来たら絶対面白いって!」とか言いながら。

レベルが高いキャラ=プレイヤーの愛着が強いキャラなのでイベントが起きた方がユーザーの満足度も興奮も高いはずなんですが、実際にはイベントは起きないようになっていたんです。

そこそこ満遍なく強くしたテストデータやテストプレイでは気付かないUXバグが潜んでいたわけです。
この事実をもって実際のプレイに即したテストの重要さを思い知りました。