瀬宮の球拾いブログ

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

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

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

しかし逆に、主導者が経験がなく、特に本を読むこともなく、熱意先行型であるケースもあると思います。
こういったケースにおいて、往々にしてあるのが「ベロシティ」を「生産性」と捉えてベロシティの前スプリント比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バグが潜んでいたわけです。
この事実をもって実際のプレイに即したテストの重要さを思い知りました。

また退職しました(3年ぶりくらい)

代々木にあるpクシブ株式会社を退職していました。
なぜか12月にかけて会社の会議室をイベントの会場として使用したいという旨の相談が急増していたので私はもう代々木の会社にはいないよ、ということをここに明言しておきます。
社員の方、連絡がある場合は2つだか3つだかあるという元社員グループのどれかからご連絡ください。

在職中はBOOTHというクリエイター向けECサービスや、自社配信の広告管理システムなどを作っておりました。
またpixivのUIリニューアルにも関わっていました。

今はB2B系のサービスに関わっています。
トレンドの移り変わりで、億単位の月間PVや100万単位のユーザーを確保できないと収益的に辛い2Cサービスよりも、2Bサービスの方が今後は伸びると思っています。
もうアガってしまったサービスを作るより、これから伸びるサービスを作る方が楽しかろうということで成長期の会社に入りました。
実際楽しいです。

転職のきっかけとなったのは、ECサービスのBOOTHを作った時に、「ユーザーの気にいるサービス」を作るために、ユーザー側のマインドを理解しようと思ったことです。
自分でサービスを作り、ゼロからプロダクトを作りました。
今でも年収分に相当するくらいの売上間で成長させたのですが、プロダクトを作る過程でプロダクトマネジメントやグロースハックを学べたのは大変大きな収穫でした。 InspiredHookedが当時のバイブルでした。
作る過程で当時はサーバサイドエンジニアだった私は、フロントやAWSの知識、あるいは各フレームワークの選定から習熟にかけてのスキルがつき、ユーザーサポートや品質保証、SEOマーケティング、広告の運用やOKRとKPIの設定など多種多様のスキルがつきました。
今振り返ればここで大きく人生が変わったのだと思います。
しかし会社にいても、私のスキルはサーバサイドエンジニアのスキルの分しか会社に買い取ってもらえずおちんぎんも少ないままでした。だってフロントやSEOやサポートはそれぞれ専門の職種の人がいましたし、分業した方がスピードも速く品質も高いですからね。
私は新規でサービスを立ち上げるなら、分業しない方が最終的に低コストと高スピードが成り立つと思っていました。つまり一人で高速にプロダクトを立ち上げ成長させられる自分のスキルが活かせる環境を求めて転職を考えたわけです。
私自身のスキルの成長が、会社とのアンマッチを生み出したというわけです。

最終的に拾われたのは立ち上げフェーズではなく、成長期でサービスの幅を広げるにわたり各職種の橋渡し役になれるエンジニアを求めていた会社でした。それはそれで自分に合っていると思います。 また幅広いスキルを評価してくれて割とおちんぎんは多めに出してくれました。

転職したいなーと思ったきっかけは もともとピクシブはエンジニアも「サービスをよりよくするための意見を出すことができる」というのが私が入社した頃のアピールポイントだったのですが、ある時期から何を言っても「そんなことをしている余裕はない」と却下されることが相次ぎ始めた時期でした。

そうなったきっかけは
・ 「何が正解かわからない」「だからとにかく、思いつく限りよいサービスを作ってみよう」
・ 「小さく作るとインパクトが不足するから、新規サービスは十分な規模のサービスで作ろう」
という方針のもと「とにかく大技を撃ちまくれば一発は当たるだろう」という方針になってからです。

大きなプロダクトを高速で生産するために「生産性」が重視されました。そのために ・ディレクター、デザイナー、エンジニアでそれぞれ分業制が組まれ
・考える人と手を動かす人を徹底的に分業し
・エンジニアは会議の時間を減らし、席に座る時間を1分でも長くする
政策が実行に移されました。

その結果、 ・「そもそもなぜこの機能を実装しないといけないの?」という疑問が解消されないままとにかく深夜まで実装作業を続けたり
・意思決定があるのはわかったが、どういう意図でこのような意思決定があったかわからない変更があったり
・ エンジニアが機能について口出しすることが嫌われたり
・「デザイナーが作ったSketchのデザインをもとに、この画面からディレクターやデザイナーは何をしたかったんだろう?」を忖度しながらSketchからコードにリバースエンジニアリングを続ける
そんな作業が増えました。

それでいて次々繰り出されるプロダクトはmarkezinなどには記事になるのですが収益につながりませんでした。
エンジニアも「結果にコミット」ということで、関わるプロダクトのビジネス的な数字の部分まで目標設定に組み込まれていたため、数字があがらないと給与も上がりませんでした。

・毎晩遅くまで働かされる割に、利益が出ない。ユーザーも増えない。当然給与も増えない。
・機能リリース前の最終段階で、社員の中にいるクリエイター業をしている(見込みユーザーど真ん中の)人に触らせると苦笑いをして「まあいいんじゃないですか?」と言われる。 ・これは明らかに変えたほうがいいですよ、といっても「リリース日が近い。今更変更している時間はない」と却下される。
そんな日々に疲れ果てて友人に相談したところ「まるでインパール作戦みたいだね」と言われました。

ああ、牟田口司令官の下で山ほど日本人が死んだインパール作戦。たしかに近いかもね。
そう思ったら自然と転職を考えるようになりました。

私はエンジニアの中ではビジネス志向、サービス志向が強く「テクニカル志向にあらねばエンジニアではない」という風潮が強まり始めたピクシブはもう居心地の良い場所ではありませんでした。

プロダクトオーナー祭りにおいて、プロダクトマネジメントについての発表をしようとしたところ前日に「それはテッキーな内容ではないから」と自粛を強く求められたこと、そして「業務外の活動」を理由に登壇しベストスピーカー賞をいただいたことで
「自分の志向を認めてくれる会社もこの業界には存在するが、社内ではない」と判断し転職活動を本格化させました。

いろいろあって今の会社に拾っていただき、ビジネス志向、プロダクト志向を生かした仕事ができています。
給与も倍近く上がり、満足しています。

自分の志向と会社の求めるものを擦り合わせることはきっと重要なことなのだと思います。
皆様も良い転職を。

30歳Webエンジニアのおちんぎん

30歳当時は某pクシブ社に雇用されていました。 今は雇用関係にありません。 もう2年以上経っているので、今は評価制度なども違うそうなので、時効だと考えています。 会社も給与体系もなんか昔と変わっているそうなので、今あの会社に入りたい人には参考にならないと思います。

雇用当初の説明では27万円 * 12ヶ月 + 夏冬賞与が1ヶ月分 + 住宅補助5万円 * 12ヶ月分、残業代なし裁量労働制438万円という説明でした。 なのでその額をもらっていたことになります。

そこから昇給が一切なく、時々賞与が少なかったり出なかったり、あと電車遅延とか関係なく月3回、朝10時に遅刻したら減給(精勤手当とかいうのがあってそれがなくなる。他社でもそういう制度があると聞いたのでよくあるのでしょう。社会は厳しい)で、その年は電車遅延が多く、上記の減給があり満額は出なかったですね。

裁量労働制だったので残業代はありませんでした。

昇給はマネージャーに昇格するとマネージャーのお手当が増えるので給与がもっと欲しい場合はマネージャーを目指せと上司との面談で説明されました。記録もしてます。

今求人票( ピクシブ株式会社への転職・求人情報 )を見たら「【賞与】年1回(6月)※業績により支給」とあったので今も私が働き続けていたら、もっとおちんぎんは低いのかもしれません。

また参考までに「※定額深夜手当(80時間分/26,000円以上)を職種手当として支給します。 」とあります。 26,000円 / 80h = 325円 なのでベースは時給1300円で計算していると思われます。時間外割増25%と深夜割増25%含めているかは不明です。 これも私の頃はなかった気がします。 だいぶ制度が変わったのでしょう。

あと住宅補助5万円/月、というと大きいように見えますが、代々木の会社オフィスから半径800m以内という縛りがありました。 代々木は家賃が高くいまの部屋の条件(RCワンルーム10平米強Not古い)で探すと高級住宅地の豊洲より家賃が5万円高く、実はそんなに美味しくなかったです。

[今の生活について]

マネージャーへの昇格なしでもおちんぎんアップありの会社で働いています。今年はおちんぎんがあがりました。 始業が遅いのに帰りも人間的な時間に帰れるのでベン・トー(スーパーでの半額惣菜争奪戦)競技という趣味ができました。 労基法についても割と守られていて、非常に不思議な感じがします。 私はサービス志向なので今の職場の方がフィットしていた気がします。

向いている会社で働いたほうが、世界は変えられるしおちんぎんも上がるしストレスも少ないのでよいと思います。 幸いにしてWebは流動性が高い業界なので、勇気を持ってジョブチェンジするのもよいのではないでしょうか。