2022年1月にマネージャーの役を仰せ仕ってはや半年が経過しました。
右も左もわからないが、理想はあった状態でのスタート。
方法論は日々色々なところでキャッチアップしたが、組織はナマモノ。
構成メンバーによってBest Practiceは変わる。
そんな感じで、よりよくするために結構色々やってきました。（つもり）
うまくいった（と思っている）もの、全然だめだった（やめた）もの、迷走中のもの色々とあります。
ちょうど評価の時期でもあるので、外部公開できるレベルのものは全部書いてしまおうと思います。
なお１か月経過した頃に書いた記事は以下。
継続したこと、辞めたこと、新しく始めたことなど、状況が変わっているものもあります。
改めてやったこと、成果、今後やりたいことあたりをバババババーーーーああっと書いてみます。
この半年でやったことと結果
機能強化案件２ProjectをManage＆Play
１つ目は某ユーザーのコミット案件。
パッケージとは言え、顧客要望を吸収し成長していくものなので、ポジティブな案件。
他との差は稼働時期までに要件を満たし切っていること。
なので、スケジュールが重要。
Project自体は私がマネージャーになる以前からスタートし、別チームから引き継いだ状態。
物理的にきついスケジュールだったので、マネージャーとして顧客担当部門と改めてMTGをセットし、
スコープを縮め、デッドラインをもばすことに成功。
おそらくスコープは３０％減、デッドラインは１.５か月延長に成功。
実質２０営業日しかないところから３０営業日の猶予を追加でゲット。
これによって。技術的負債を生まないような実装をペアプロで実施でき、
レガシーコードを改善しながら進めることに成功。
２つ目は新機能開発。
不具合修正しか経験がないメンバーを主担当としてアサイン。
機能強化案件の進め方、WBSの作成方法、タスク分解の考え方、設計手法など、
半年ではやりきれないくらいの知識、技術を投下。
当初の予定スコープは見たせなかったもののミニマム出荷に漕ぎ着けた。
マネージャーとしては、いかに小さく進めて、高速にループを回して、アジャイルに進めていくかと言うところを念頭に、主にタスク分解、スプリントバックログ、WBSの作り方、目的、考え方などを毎日主担当メンバーにFB。
マネジメント側（私の上長、プロダクトマネージャー含め）何を可視化してほしいのかなども共有しつつ、進めたつもり。
うまくやれたかはわからないが、学びの場を提供することはできただろうと思う。
ペアワーク＆ペアプロ
チームメンバー全員とペアプロを実施した。
コーディング力の強化が主な目的だったが、併せて自分が担当しているものを使ってマネージャーはどうやるのか？を実践の中で伝えることをやりたかったのでその点についてはおそらくできた。
読みやすい保守しやすいコードを生み出す過程は一人っで学ぶのはなかなかきつい。先人のやり方を見て学び、自分で実践すると言うプロセスが必要。あったほうがいい。
そう言う意味で、先人のやり方をを学ぶ機会提供はできた。
コーディングにとどまらず、タスク分解、アジャイル開発っぽい進め方などもドキュメントに頼りきらず、マンツーマンで実施。
いろんな記事から影響を受けて実践した。基本的にはtrelloでSplint Backlogを作って進めた。
弊社の開発部門は問い合わせ対応も重要な役割として存在している。
ここについては半年間原則毎日シャッフルペアで開発に上がってくる問い合わせ対応をした。
モブワーク＆モブプロ
ペアアーク＆モブワークのモブ版。
３人以上でやったものもあるし、私が有給の時はメンバーだけでモブプロ進めてくれたものもある。
人のコードをReviewするなんて経験がなかった人たちなので大進歩でしょう。
それぞれのメンバーに観点を伝えてきた成果だと思っています。
また週次で時間を抑えたものについては継続しており、社外秘もあるが、可能な範囲でまとめて別の記事にしようと思う。
色々ハンズオン
- サブシステム勉強会を実際の評価環境などを利用して実施。
- Junitハンズオンを３回実施
- テスト駆動開発を２回実施（Junitと重複あり）
- レガシーコード改善を１回実施（Junitと重複あり）
チームであつ読み
２回やりました。
あつ読みは以下の記事を参照してください。
対外向け情報開示
開発が問い合わせ対応するのだるいのでQ＆Aやマニュアル整備を進めました。
フロント部門がやれることはやってもらわないと開発なんてやってられないくらい整備されてないというか、まあそういう領域をマネジメントすることになったので。。。道半ば。。。
レガシーコード改善
私含め４人中２人がJunit書いたことないという状況から、２人ともがJunitを複数のMR（PR）でmasterブランチにマージしました。
また１人については、モノにしたようであまり指摘をせずとも勝手に入ってくるし、それに合わせてレガシーコードを順調に減らしてくれています。
「何それ美味しいいの」状態からメンバーのコードにコメントしたりアドバイスするレベルになったので急成長じゃないですか？
マインド教育
説明難しいですけどスクラム、アジャイルで進めることのメリットをひたすらしゃべって伝えると。
また問題解決の常套手段である仮説思考の話も結構OneOnOneとかでしたと思います。
参考にした記事とか、本とかはたくさんあるので貼ってみます。
ひとまず仮説思考の話は以下のような話です。
※他は後ではる
今後継続したいこと、始めたいこと、やりたいこと
道半ばのもの、継続したいこと、たくさんありますが下半期に向けてざっくり洗い出します。
また年末に振り返れればいいかな。
スクラム（的な）開発
要するに、純粋なスクラム開発は今の弊社の開発部門では結構難しいので、個人プレーではなくチームプレイで、チームとしての成果を重視しそこに各自が貢献することをイメージしてやりたいです。
アジャイル（的な）開発
小さく作って早く出すと言うアジャイルな観点を開発に英題に盛り込んで行きたいと思っています。
理由は単純で問題は小さいほうが簡単になるから。つまり高難易度案件も細かくできれば難易度が下がる。
そうやって進めていけるように、各メンバーのウォータフォール的な「完成してからマインド」をアジャイル的な「細かく進めて早くReviewしてもらおうマインド」変えていけるように色々やりたい。
組織的に問題解決できるようなチームビルディング
仕組みですね。Daily ScrumやSplintプランニング、レトロスペクティブとかのやり方をより良くして、フォロー体制をもっとうまくやれるような状態を目指して日々カイゼン！！
チームジャーニー
はい、できれば輪読会やりたい。
主体性、自律性の醸成
オーナーシップというやつです。
無理な人は無理なのでしょうけど、そんなこともないかなと思う。
程度の問題はあるかもしれないが、自分の明日の飯は自分で調達しなければならない。
そのためには主体的に動けなければ、生活は現状維持だし、給料も現状維持（つまり衰退）。
現状維持は衰退。つまり成長しなければ現状維持は不可能。その源泉は主体性にあると考えている。
多くのメンバーが主体性を持って自らの役割を果たせるようにアクションしていきたい。
具体的なアクションプランはむずいな。なんだろ。説教じみたのばっかもいやなんだよな。
基本的にはちょっとレベル高いもので多少追い込んでいくことでやっていくしかないのかな。
最後に
参考資料とかは後ほど貼ります（多いですがいい記事多いと思いますので気長にお待ちを）