いてづきブログ

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

退職します(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:「そうですか」って一言だけつけて返信しようとも考えた

認定スクラムマスター研修を受けた

1/24〜26の3日間で認定スクラムマスター研修を受けてきました

 

なぜ受けたのか

前々から受けたいとは思っていたけど仕事での経験や知見を積んでから…と思ってました。
でもどこかのタイミングで「きっといつまで経っても十分と思えるときは来ないんだろうな」と漠然と思うようになりました。
それならさっさと受けて自身の学びと発揮価値を増やしたほうがいいと考えて次に開催されるタイミングで受けようと決めていました。

 

それで11月の頭に1月の研修の開催が告知されたのでそれに申し込んで受けました。

研修の雰囲気

研修は講義とワークショップの形式で行われました。
講義も質疑応答でも語り口は穏やかだけど言葉の節々から様々な経験を経ていることが感じられました。

また研修用のslackでは講師が常に研修でわからないところや実務での困りごとまで様々な質問に答えてくれてとても学びになりました。

 

学んだこと

事前課題としてスクラムガイド2020を読んでおくというのがあり、一通り目を通したし普段の実務でもある程度はやってるし、経験や手札の数はともかく知識面は大丈夫だろうと思っていたけど全然そんなことはなかったです

 

古い知識のままであったこと、知ってはいたけど背景を理解できていなかったこと、読んだはずなのに自分で勝手に補完して勘違いしていたことなどなどいろいろありました。
ちゃんと時間を取って人から聞くの大事。

 

2020からはゴール志向になったことをスクラムガイドから読み取れていなかったなというのが結構大きい学びです。

 

ワークショップはタイムボックスが厳格に適用されるのでタイムボックスを守ることの大切さを身を以て学ぶことができます。
あと練習は大事というのも自分にとっては大きな学びでした。

 

所管

教えてもらえばもらうほどワークショップで経験すればするほどスクラムマスターやばいな…という気持ちでした。
自分ができるだけでなくそれを周囲にいい感じに適用させていくことの難しさに加えて自身も日々学びながら変わっていくことの大変さよ…。

 

研修したらいろいろ勉強できたり身についている状態になっているといいなと思っていたけど、学んだことの数倍さらに学ぶことが見えてきて山の高さに絶望しているみたいな…。

ただそうなるくらい学べたということで本当に有意義な研修でありました。

 

認定試験

研修最終日の夜に受けました。

他の方の研修の記事とか読むと受けられるタイミングが何日か遅れるみたいなのを多く見かけましたが、自分が今回受けた研修では研修終わりの頃にはメールが届きすぐに受けられる状態になっていました

 

ちゃんと準備してから受けようか迷ったものの、どうせ2回までは受けられるしテストもよくわからないままやっても仕方ないなと思いさっさと受けました

一応、手元にスクラムガイドとアジャイルソフトウェア開発宣言を準備して臨みました。

いくつか不安な問題はあったものの基本的には苦労せず答えられたと思います。

 

無事合格できました。

 

f:id:iteduki:20220128225125p:plain

 

前述の通り、これ取ったからと言ってなにか大きく変わったとは思えない(むしろ絶望が増した)けどひとつの学びの証という意味ではちゃんと取れてよかったです。

 

これで「研修とかを受けてない」という自分自身の言い訳もひとつ消したわけだし、改めて日々頑張っていこうと思いました。

 

 

 

 

2021ふりかえり

仕事納めました@29日

 

今年は2度目の異動を経ての今の部署となりましたが、現在のところ次の異動はなさそうです。

 

今年頭に「お前のフロントエンド力が必要だ*1」と言われて異動してきて、前半はガッツリとNext.jsでのフロントエンド開発に携わっておりました。

 

TypeScript,Next.jsといったデファクトスタンダードとなりつつある環境での開発はめちゃくちゃ体験がよかった。
また、自分を引き抜いてくれためっちゃできる上長とガッツリ組んで開発したことでこれまで自分が点で理解してきた知識が実践を経て繋がる経験を出来たのはとてもよかった。

 

 

しかし後半に入ってその上長がさらなる上の組織に引き抜かれてしまう。
まぁめっちゃ優秀だったし仕方ないよね…と思いつつ、既存のサイトの保守やってたチームと合流してこちらも同じくアテにされていたチームビルディングとかをやっていく。

 

ちょくちょくブログに書いていたけどなかなか苦労しつつという感じだった上に上長が抜けたこと*2で技術的に難し目(特にフロントエンド)のタスクが自分に集中するようになってしまった。
それで根を詰めることになったせいか、仕事終わるとヘロヘロになるような状態になってしまったのがここ最近。

ふりかえりとかにパワーを割けなくなってしまったがそれをカバーすることも出来ず(それもまた問題だけど)というのが現状でなかなかしんどい状態。

冬休みで体調整えて巻き返したい。

 

 

今年後半通じて少なくとも自分の開発力やフロントエンド側の知識は自分の関係するところで相対的に見て低くはないらしいということがわかった。
もちろん自信持って高いとか言える人はそういないとは思いつつも必要以上に卑屈になってはいけない位置ということは理解した。

 

ただ、かといって自分が重たいものばかり投げ込まれると普通にしんどいしチーム全体としての限界がここになってしまうので対策しないといけない。

「目の前の成果」を重視した結果だと思うので今のままでいいのかを改めて問うて全体としてのレベルアップを目指す。
一部、自分は困ってないから、自分はできているから(関係ない)というメンバーからも知識を引き出していけるようにする。これは直近の課題。

 

あとは自分がこれらの熱量を維持できる状態を作らないといけない。
体力とかもっとなんとかしないといけないかも。

 

技術側に寄せればいいと思うかもだけど、上記と矛盾するかもだけど自分が技術全振りではやっていくのは無理だと思ってるので上手くバランス取ってやるしかない。

2022年、しんどくなりそうだけどがんばっていく。

*1:超意訳

*2:代わりに来た新しい上長はガッツリマネジメント寄りの人

コードレビューをボトルネック化させないタスクの進め方

普段開発を行っているときコードレビューをすると思います。

 

しかしコードレビューの指摘と修正が繰り返されいつまで経ってもマージできないということが往々にして発生します。
レビューに何を求めるかはチームや組織によってまちまちですが、少なくともレビューの遅延が原因でマージやリリースが遅れるような状況は健全ではありません。

 

自分が入ったチームで行って効果的だったのは、実際に手を動かす前にタスクを全員で見る時間を作ることです。
もう少し具体的には開発の方針を決めてしまうことです。設計と言ってもいいかもしれません。

 

チームで開発をしていると言ってる割にこれをやっていないチームは意外と多い印象です。
各エンジニアがそれぞれ領域を持っているけどレビューはやらないといけないのでレビューだけ他のエンジニアにしてもらう…とか。

 

 

設計をどのくらいまでやるかはチーム内のレベル感に寄ると思います。
新しく入った人がいたりルーキーみたいな人がいるときはスケルトン作るくらいまでやってもいいかもしれません。

というかレビューが爆発してるパターンのときは大抵の場合、よくわからないけどそれらしいものを作ってレビューに出してそこで初めて設計レベルの指摘をされてほぼ全作り直し…というようなパターンが多いので、チーム内でその領域に詳しい人と一緒に全部作るくらいのことを最初はやってもらうくらいでもいいと思っています。

 

年数とか関係なくその部分のことをがわからないならわかるようにして、全員の前提知識を増やしてあげることが大切です。