Type something to search...
2023を振り返る

2023を振り返る

はじめに


2023は個人的に仕事で学びが多かった年なので、まとめておきます。
今まで行ってきたことの答えが分かり始めた年でもありました。

Q1 : 1月 - 3月


チームの地力を感じる

2022年7月から始まったプロジェクトのサービスのクローズドリリースをしたのがここ。
2週間単位でスプリントを回しながら、毎日チームメンバーでアプリを触ってドッグフーディングをしていました。
リリース前ということもあり、チームのメンバーに残業を打診したところ、皆快く快諾してくれた。
開発も企画も、チーム全員が同じ方向を向いていると確信した。
地道にチームビルディングと向き合ってきたためか、チームの地力のようなものを感じた。

info

もちろん、チームに無理させないスケジューリングをすることが大切です。

Q2 : 4月 - 6月


上記のサービスの運用期間。 運用しつつ、リリースの準備も進める

優先度を下げた技術的負債の解消

チームの方針として、「ユーザーにとっての価値」の検証だったり、最大化を第一優先としていたため、ここで負債を返すこととなった。 幸い、完全に作り直さないと耐えられないような設計や技術選定をしていなかったため、あらゆる箇所のチューニングで対応できた。
技術的な打ち手を考え続けてくれたSREと、その打ち手を素早く正確に実装してくれた開発メンバーの努力もあり、サービスのクオリティをリリースレベルまで持っていくことができた。
「非機能」の部分はエンジニアがしっかり説明して、チームの総意として優先度を決める必要があると感じた。

Q3 : 7月 - 9月


サービスのリリース期間

チームメンバーの入れ替わり

チーム外から強い個性を持ったメンバーが数名入ったこともあり、ガチガチに固めていたチームの文化が揺らいだことを感じた。
また、ブリリアントジャークのサイドエフェクトを肌で痛感した。🦈
参考:https://x.com/fuuuuuta21/status/1581974930609930240?s=20
全く異なる文化の人がチームにジョインする際には、それ相応の準備が必要なのだと学びになった。

あえてウォーターフォールを選択してみる🚿

ここで、期間とやることがfixしていることから、2ヶ月だけウォーターフォールの手法を採用した。チームからハレーションが発生するかとも思ったが、採用する理由を説明したこともあって、皆協力してくれた。
この2ヶ月間はガントチャートで割と細かく進捗を管理した。PdMはニッコニコだった。
とはいえ不確実要素は消しきれなかったので、スケジュールを守るためにバッファを多めに積んだ。
結果、バッファを食いながらもスケジュールは守られた。 ※ スケジュールを守ったという点では評価が高いかもしれないが、この期間のあらゆる「変更」を受け入れることはできなかった。 ※ 日々変化が起こる業界では悪手だと感じた(開発が進んでも、望まれないものを生産する確率が上がるため)

チームのための知識武装⚔️

8月以降はアジャイル開発のスタイルに戻したいと強く感じたので、必死に勉強した。
本を読み漁り、Webを読み漁り、PMOと意見交換をしたり。
この過程で過去記事のアウフヘーゲンと邂逅した。

Q4 : 10月 - 12月


運用フェーズ

進行の実行責任を移譲した

運用する際に、自分が窓口となってエンジニアチームの進行を行っていた。
このやり方に限界を感じていたので、チームメンバーと相談して、
エンジニアが主体となって、ある程度の大きさのタスク進行を分散して行う仕組みを小さく取り入れみた。
こちらの仕組みのことをエピックオーナーと名付けた。
チームメンバーが優秀なこともあり、非常にワークした。
エンジニアの責任範囲は「機能」「システム」だったりするが、チームとして達成しないといけないことは「価値の提供」である仮説から導入したが、仮説は大きく外れていないと感じた。
エンジニアも開発の範囲を一歩踏み出して、進行だったり、ビジネス価値だったりに手を伸ばせると、チームとしての強度はグッと上がると感じた。

アジャイルを肌で体感し始めた

上記の経験から、「アジャイル」が何たるかを若干掴み始めた気がしている。
鍵となるのは、「自律分散」「価値の提供」「ポジションの越境」「担当の委譲 / およびその仕組み」辺りなのだろうと感じている。
本やウェブに書いてある通りといえば書いてある通りなのだが、実践し、体感することで初めて分かってくるところがあると思った。

実績は大事

また、何かを始めるときに「小さく取り入れる」ことと「結果を元に提案」することは大事だと思った。
上記のエピックオーナーがうまくワークしていることから、PdMにタスクが集中している、サービスの機能の仕様作成についても、チームで分散できるとより開発速度が上がるのではないかという提案をしたところ、思った以上にスッと通った。

まとめ


裁量を持ってチームに対してアクションをし、学び続けることができた年だった。
自分のエンジニア人生の中でも、1番学びがあった。 座学やインプットとしての学びもそうだが、実践、アウトプットとしての学びがあり、非常に貴重な経験ができたと考えている。 チームのメンバー全員に感謝の気持ちでいっぱいです。

Related Posts

自分流本の読み方

自分流本の読み方

本、読めてます? エンジニアなら本を読んでインプットをすべきと頭では分かっているが、買うだけ買って積読状態になってませんか? はい、僕はそうなっていますね。 ですがこれから述べることを意

read more
アジャイル リーダーシップ を読んだのでメモ

アジャイル リーダーシップ を読んだのでメモ

どんな本? アジャイルとは「マインドセット」であると定義し、それを組織に対してどう浸透させるか(アジャイル・トランスフォーメーション)、そのためには、いかにアジャイルリーダーシップが大切である

read more
敢えて定義や二項対立を避けた事による学び

敢えて定義や二項対立を避けた事による学び

こんにちは 今回は、「議論をする際に敢えて定義やワードを避けてみる」と、スムーズに話が進み、結論に至った日のことメモします。 その日、自分が所属する開発チームは開発手法について議論していました。 参

read more
開発が企画に寄り添うというコト

開発が企画に寄り添うというコト

ソフトウェア開発の難しいところ モノづくり、特にソフトウェア開発において、技術と企画のバランスは非常に難しい所だと思います。 どちらかが悪いとかいう話ではなく、どちらもプロダクトのことを思っ

read more
今年読んだ本を振り返る

今年読んだ本を振り返る

はじめに 今年は自分にしては本を読めた年だったと思う。 理由は2つあって、1つ目は仕事で実践するために必要だと判断して行動したこと、2つ目は本を読んだ際に、一緒に読んで感想や考えをシェアでき

read more
Clean Architectureは息苦しくない

Clean Architectureは息苦しくない

概要 Clean Architectureでサービスを運用して1年近く経ちました。チームのメンバーからより良くなる提案をしてもらい、アーキテクチャ自体は走りながら一部リアーキされたので個

read more