いてづきブログ

情シスでやってみたことの備忘録

経験値の差と成長

少し前から今年度の新卒入社メンバーと同じチームで仕事をしている。

 

彼らはとても勤勉で優秀なんだけど、経験値の差というのは普段の仕事では思ったより大きいのだなと思った。

あと自分の経験値というものが思ったよりちゃんと物を言ってるのには少し驚いてる(仮にも干支が一周するくらいは社会人やってるのでそうでないと困るのはそれはそう…)

 

彼らは最新の技術に対する知識はあるがそれをどう使うかみたいなところで少し迷うところがあるように見える。
自分だったらこれとこれを使ってこんな感じで作れそうだなという半ば手癖のようなものを一個一個丁寧に調べている。

 

とはいえこれは今だけの話で、実際1年も経てばこの差はなくなると思う。

 

一方でそうした手癖を改めて誰かに説明しようとすると自分が何を意識してそうしようとしているかを言語化できてよい。

自分はなるべく単一責任にしたり依存を排除しようとすることに思ったより気をつけていることに気づけた。

 

 

これらを伝えようとすると通常のプルリクレビューだけではダメでペアプロモブプロなどで一緒に作業してどういう思考プロセスでこう考えてるを伝えないといけなさそうというのが最近の気づき。

プルリクのコメントだけではどうしても出てきたものに対してしか伝えられないけどどういう思考で最終的にこんな感じになってほしいからこうする、という思考の流れを伝えないといけない。

 

あとレビューコメントだけだと読んだ側が考えないといけなくてそこから考えるスキルとか相談するスキルとかいろんなものが必要になって時間が無限に溶かせてしまう。
成長のためには考えてもらうことも必要だけどそもそもタスク自体が終わらなくなってしまっては本末転倒なので。

小さいタスクだからといってコメントだけで済まそうとして沼に陥ってしまったのでやっぱり一緒にやるということが大切そう。

 

 

(なんとか毎月1記事くらいは維持したいなぁ)

プランニングを制するものはスクラムを制す

というのを考えた。

 

アジャイルコーチに見てもらいながらスクラムのイベントを一通りやってみて、これまで仕事してきた中でうまくいっていたチームに共通してそうなことを考えてみた。

 

 

その中で一番違いを感じたのがプランニングだった。
うまくいっていたチームはスプリントのタスクの内容を細かく確認していた。

逆にそうでなかったチームはやるタスクを決めたら中身はざっくり確認で終わる、そもそもプランニングに時間を割いていなかったというパターンが多かった。

 

タスクの内容を細かく確認するのはチームが進捗の状態を検査できるようにするため。
例えば何らかのデータを表示する機能を作ろうとするとこんな感じ。

  1. APIのエンドポイントを作る
  2. データを取得できるようAPIの中身を実装する
  3. フロントから呼び出せるようにする
  4. 呼び出した内容で表示を整える

こういう形になっているとデイリーで何番の作業までは終わっていると明確にわかる。

これを作るためには全員がこのタスクについて理解できている必要がある。
そしてそれが出来ていれば作業を分担したり交代したりすることが出来る。

 

これを怠ると既にシステムや技術を理解している人はどんどん進捗が出るけど、新しく入った人や経験の浅い人は進捗が出せなかったり出来ても品質が悪くなったりして結果として悪いものが出来上がるのだと思った。

 

ではなぜプランニングで細かく見ないようになるかを考えると、わかってる人にとっては作業を細かくする作業は無駄に感じられるから。
上記のタスクの1~4はわかってる人にとっては自明でわざわざ分解して書く必要などないしそれで途切れるような作業進捗にはならない。

そういう人はわからない人のために時間を取られて自分の作業効率を下げられていると感じるし、本人単体は成果を出しているから声が大きい人ポジションにいることが多くプランニングを無駄な時間と切り捨てていってた。

出来る人はそれでも困らないけど新しく入ってきた人や新卒や若手はタスクが終わらず疲弊したり、それだけならまだしもレビューで大幅な変更が入って無駄が発生したりする(レビュー工数がかさむというのは出来る人にとっても無駄だしそれを削減できるだけでも効果は十分あると個人的には思う)

 

結果としてどれだけスクラムをやろうとしてもうまくいかないし、出来る人にとってはむしろ自分の生産性を落とすものとして嫌悪する方向に向くだろうというのが自分の考え。

 

上記を含めてスクラムのメリットを享受するためには結局のところ、成果を出す主体が「個人」ではなく「チーム」だということを理解するのが必要なことだと改めて感じた。

 

 

そういえばこの記事が出た日からRSGTやってますね。
毎年何かしらの都合が合わなくて行けてないので、来年こそは行けたらいいなぁ。

 

 

退職します(2年8ヶ月ぶり4回目)

退職します。
本日最終出社日でした。

 

なぜ辞めるのか

まず今の会社に転職した理由が会社の風土とかそういうの以前に名古屋に引越すからだったというのがあります。*1
しかし実際のところ転職直後にコロナ禍に入りリモート勤務になりました。(もちろん転職活動当時にはコロナのコの字もなかった)

 

当初こそ新生活やリモートに慣れないといけないこともあって様子を見ていたものの流石に2年もリモートしてるともう元の働き方に戻ることはないことはわかってきます。
それと仕事がしんどい時期が重なり、積極的ではなくてもいいところがあれば移ろうくらいの気持ちで活動し始めたら内定をもらったため辞めることにしました。

 

どうやって転職したの?(宣伝含む)

お肉とかアマゾンギフト券目当てで登録したLAPRASとかFindy経由で来るスカウトメールで良さそうなところがあったらカジュアル面談したりしてましたが、最終的には転職ドラフトで決まりました。*2

 

転職ドラフト使ったのはレジュメの審査があることで実際に転職するとなったときにまたレジュメ作るのめんどくさいなと思ってせっかくなら人に見てもらった方が書くだろうと思ったくらいの気持ちです。
実際自分が書いたレジュメに対して「こういう事も書いてください」とか「こういうことは書けませんか?」といろいろ指摘をもらえたことで書けたというのはあります。

 

そしてそこまでして書いたのだから1回くらいは出してみるかと思って指名待ちしたところ最終的に12社ほどから指名をもらいました。
その時の提示額が12社全て現職より高かったので受けてみるかという気持ちになりました。(とはいえ指名理由とか業務内容で自分には無理そうと思ったのはお断りしました)

いいところがあれば~くらいで思ってましたがこれが転職する決め手になった感じはあります。

 

というわけで転職ドラフトの宣伝です。

もし転職ドラフトを使うときは友達紹介コード「WIRN」をお使いください。

 

よかったところ

以前から名前は知っていて名古屋にもどってくるときにここで働けたらいいなと思っていた会社であり実際ここで働けたのは良かったです。

 

名古屋でこういう会社は数が少なくまた規模も大きいことからエンジニアに限らず各職種で優秀な人がたくさんいます。
事業会社ということもあって各種数字の考え方・測り方などは学ばせてもらったなと思っています。

 

エンジニアとしては主にフロントエンドを色々やらせてもらいました。
TypeScriptとかReactとか経験してきたり個人的に勉強してきたけどそれがきちんと通用するレベルにあることを実業務を通じてようやく認識することができました。(同時にまだまだ上がいるなと思ったのも事実です)
そういう認識を出来るだけのレベルのエンジニアと一緒に仕事をすることができたのが大きな収穫です。

 

テナントビルが駅直結でアクセスもよく社食があるので昼に困ることもない抜群のオフィス環境でしたがリモートになり恩恵をあまり受けられなかったのは残念です。

あと、会社のことではないですがテナントビルで当時かなり早い段階でワクチン接種1回目をできたのはよかったかもしれません。

 

f:id:iteduki:20221021084208j:image

会社のトイレから見える景色。

 

辛かったところ

事業会社でよかったことの裏返しというか事業会社あるあるだと思いますが、数字が重視されシステムの保守や開発の継続性は軽視される傾向にありました。

チームのベロシティからこれ以上開発要求を追加するのは難しいですよといえば消極的とみなされ、一人がワンマンで作り上げてリリースし保守は丸投げした方が評価される文化は丸投げされる側としてはしんどかったです。*3

 

評価の高い人は自分のやりたい開発が事業にどうプラスなのかをいい感じの言葉にして伝えるのがうまく、政治力とまではいかなくてもこのような説明をする力というのは必要なのだと思いました。(そして自分はそれが苦手であることも認識しました)

 

SIer時代、客先都合でなかなか思うような開発ができず苦い思いをしたのが自社開発ならうまくやれるだろうと思っていましたが現実は厳しい。(考えが甘いとも言える)

 

今後について

上記の通り内定は既にもらっているので次の会社にいきます。

結果として次も名古屋に事業所のある会社になったので今と変わらず週1出社で働くことになりました。

 

やりたいことや読みたい本も溜まっているので11月の間は無職をして12月から入社することにしました。
ここに書けないような話とか詳しく聞きたい人がいたらこっそり聞いてください。

 

そして無職することになったのはいいのですが年末調整のことを完全に忘れていたため今年度は自分で確定申告をすることになってしまいました。*4

皆様転職するときはお気をつけください。

 

例のリスト

www.amazon.co.jp

 

 

*1:そもそも名古屋は選択肢が少ない

*2:このご時世には珍しく焼肉奢ってもらった社もありました

*3:そしてその人は他でも成果を上げてほしいと言われて別部署に引き抜かれていなくなる

*4:無職期間の間に次の会社での年末調整の受付が終了してしまう

vsゴリラ

スクラムチームでのゴリラの具体的な活用方法を考えたい。

 

その前にまずスクラムアンチパターンにおけるゴリラについて軽く説明する*1

 

 

ゴリラとは

チーム内にいる声の大きいメンバーのこと。
大抵の場合、技術的やプロジェクトの経験、ドメイン知識的に一番強い人間がこうなりがち。

ゴリラがチームに居るとチームはゴリラの意見や意向を伺うようになる。
自己組織化出来ないばかりかゴリラへの依存が高まりゴリラなしでは仕事が立ち行かなくなる。

 

 

一般的な対処法

  • ペアプロなので知識をうまく使わせてもらう。
  • チームの外に置いてアドバイザ的に使う。

一般的にゴリラの技術力・ドメイン知識についてはメンバーも認めていることが多い。
なのでその知識は活かしつつ他のメンバーにも少しずつそれを移していくアプローチ。

 

  • どんな問題でも最後に発言するようゴリラに依頼する。
  • ゴリラには発言するよりも質問するようにお願いする。

自立を妨げるゴリラを黙らせることで他のメンバーに強制的に自立を促す方針。

実際にゴリラと遭遇した

実際にチームにゴリラが出現したときの失敗談をここに残しておく。
なお今思うとゴリラは実は2頭いたのでそれぞれについて書く。

 

1頭目のゴリラ

組織図上の開発部門の部長で現在のプロダクト開発の大半を手動してきたわかりやすすぎるゴリラ。
スクラムチームにおけるゴリラと言っているが、実際には始める頃くらいに技術研究的な部署に異動になったのでチームの外に置くことには(勝手に)成功している。

 

しかしながらプロダクトの一部において未だにゴリラのレビュー承認を得ないとリリースできない状態になっている。
曰くチームだけに任せられる状態ではないとの判断とのこと。。。

 

ペアプロとかして徐々に知識を移していくのがよかったのかもしれないけど、

  1. 部署が変わったのでそもそも指揮系統が違う
  2. ゴリラ自身の性格の問題

そもそも指揮系統が違うのでこっちのプロダクトのために工数を割いてもらうことが出来ない(じゃあなんでレビューはやってんだって話ではあるんだけど)
性格についてはゴリラにありがちなやつ。聞いたことには答えてくれるけどキツイ文言で返ってきたりするアレ。

 

ゴリラがレビューフローに入っていることで計画が立てづらい。
ゴリラは計画に参加していないので設計レベルのレビュー打ち返しがしばしば発生するがゴリラの返しを恐れてゴリラの指摘通りの修正を行ったりしていた。
特に以前からのメンバーはゴリラと上司と部下という関係が長かった分、そういう行動を取ってしまいがちだったと思う。

 

きちんと説明すれば聞いてくれる方ではあり、メンバーにもまずは自分たちの意見として伝えるべきとしていたが上記の理由もあって全員がそれを出来たわけではない。

 

一方でチーム内のレビューでは見落としたがゴリラの技術力によって問題や不具合が事前に発見されることがあるのも事実。

 

タスクのフローがゴリラに依存せずかつゴリラの力を借りられる体制を作れればいいがどうすればいいんだろう?

 

ゴリラに聞かないとってわかるようなところならそもそも問題は発生しない。自分たちにはわからないけどゴリラが見たらわかるようなものをどうやって見てもらうか、が難しそうと感じている。

 

2頭目のゴリラ

1頭目のゴリラの次にプロダクト歴が一番長く、1頭目のゴリラが別部署になったことでプロダクトに関する質問や決定をしていく立場になり徐々にゴリラ化していった。

 

当初こそドメイン知識を少しずつ周りに移してく動きをしていたものの、徐々に普段の業務に追われて形だけになっていってしまった感じがある。

こちらのゴリラは「正しいやり方をすれば正しい結果になる」という考え方をする人で、結果として知識の伝達がうまくいっていないが理屈上は正しいことを言っているので周りは反論が出来ずという悪循環になってしまった。

 

理屈ではなく結果で判断しなかったこと、そして悪意があって行われているのではないからと行動を見逃してしまったことが大きなミスだったと思う。

(余談だがこの頃自分のタスクが重くとてもチームの状況に気を配れる状態ではなかった。やはり兼務はアンチパターンなのだと身を以て知った出来事でもある。)

 

そして何よりの問題は1頭目のゴリラに気を取られてチーム内に別のゴリラが出現しつつあることを察知出来ていなかったこと。いつからゴリラが1頭だけだと錯覚していた…?

 

ゴリラとの対戦を経て

ゴリラは実際強いのでその人を何かしら向きを変えるのはやはりパワーと諦めない強い意志が必要だなと感じた。
目の前の課題に追われがちでなし崩し的にゴリラの台頭を許してしまったのは大きなミス。

 

あと人は誰でもゴリラになりうるんだなという気持ちでいないといけないなと思った。
ゴリラへの警戒心がやばいなw

 

 

*1:しかしなんでゴリラって言うんだろう

保守タスクから思うPBIと開発チーム

今のチームには通常の機能実装とは別に保守というタスクが積んであるリストがある。

 

保守タスクは開発チームにしかわからないという理由から通常のリストとは別になっていて、毎週のプランニングでスプリントの20%に入る分だけのストーリーポイントのものを入れても良いということになっている。

 

しかし一見良さそうに見えたこのルールも実際に運用すると全然保守タスクは消化されない。

機能実装が優先という名目なので20%残せないことも多いし、タスクの見積もりの精度にもばらつきがあって保守タスクを積んでも消化されず、次スプリントでは時間が足りないから戻されてそのまま。なんなら途中まで手を付けてしまったせいでその人の手が空くまでほったらかしにされるまである。

PBIが一つになっていないと明確な順位は付けられずこうして腐っていくんだなと痛感した。

 

 

そしてPBIを一つにするためにはPBIを管理する役割の人(うちであればいわゆる企画チーム)と活動を共にする体制になっていないといけなさそう。
保守タスクはそれ自体では機能追加やユーザーへの価値へ繋がらない事が多いが、かといって決してないがしろにしていいものではない。

 

極端な例えだけどRubyRailsのバージョンアップをしないのは、技術負債に繋がるだけでなくサポート外になったときある日突然デプロイできなくなったり動かなくなったりすることになる。*1
そしてそれは20%の範囲内で各自の自主性に任せてというやり方では到底賄えるものではない。

 

であればチームでいつ頃やるのかというのを判断していかなければならない。
そしてそれをするためには企画チームも同じようにその情報を知って機能追加とどちらを今はやっていくのかという判断をしていけるようにならなければならない、というわけ。

 

 

自分のところも含めて開発チームだけでスクラムアジャイルでのやり方をやっているところは結構いそうだけど、それだと結局タスクや開発の事故を早期に発見出来るということ以上のメリットを享受できないと感じている。
以前やっていたところはSIerだったのでそのメリットで十分だったというのはあるけど、今の自社開発の会社だとそれだけではちょっと開発の成功率が高い社内受託以上にはなれない。

 

この辺が「開発チームは機能横断的である」ということの理由なのだろうなと思った。

 

 

*1:いきなり使えなくなることはそうそうないとは思うけど、そんな判断を下すようなところにエンジニアがずっといてくれるかという別の問題になる気がする

レビューコメントで察してもらおうとするのはやめろ

レビューコメントで具体的な指摘や指示ではなく「ここおかしいです」みたいな突き放すようなコメントを付けて、具体的な対応をレビューイに考えるところから丸投げするのをやめろという話です

 

問題点

無駄を作り込む可能性


言外の内容を読み取らせるということは、相手の読み取り方によっては必ずしもレビュアーが意図した内容が伝わるとは限らないわけです。

修正してもらったとしてもその修正方針が適切かどうか、場合によってはそもそも修正が必要だったのか、出てきてから更に議論をする必要があり無駄なものを作る可能性がありとても非効率です。


無駄なコミュニケーションの発生

レビューイが上記を危惧したなら事前に回避するためにどのような修正にするかを打診すると思います。
が、そもそも指摘する際にどういう風にしてほしいかまで書いてあればこのコミュニケーションは発生させる必要がないもので、レビュアーの怠慢のツケをレビューイに押し付けているだけです。

 

もちろん必ずしも修正方針がわからない場合もあるとは思いますが、それならばそのように書いてレビューイに委ねるなどの手段を取れると思います。

 

心理的安全性の侵害

個人的に一番問題になるのがここだと思っています。

問題だけ指摘するような書き方は得てして高圧的な文体になりがちです。
そこからレビューイが言外に察するのは「なぜこうしないのか?こんなこともわからないのか?」という罵倒や否定の言葉です。

 

本当にそう思ってるかどうかは関係がありません。
かつて自分もそういう人がレビュアーだったときに「言い方がきついことがあったかもしれないが罵倒とかそういう意図はない」と直接言われたことがありますが、思ってないからいいというものでもありません。*1
それをわかっていてもそういうコメントが付けば消化するのにエネルギーを使います。

 

「間違いを指摘しているのだから言葉遣いは関係ない」と言う人もいますが、それは今の仕事の中だけであればそうでしょう。
ですが別に仕事は今の会社とかプロジェクトの中だけではないです、

自己都合か最悪の場合は心を壊して離脱という結果になるかもしれません。

 

なぜ書いたのか

遅れ気味のタスクを自分が巻き取ってその日にリリースできるようにしようって朝会で合意したくせに上記みたいなコメント付けてきてブチギレそうになったので。*2

 

これはちゃんとふりかえりしないといけないなと思って考えをまとめたので載せておきます。

 

 

 

*1:まだ自覚してそう言ってきただけこの人はマシな方

*2:「そうですか」って一言だけつけて返信しようとも考えた