いてづきブログ

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

なぜプロジェクトは予定通りに終われたのか

2月から関わっていたプロジェクトが無事に終了した。

タイトルでは予定通りと言っているが、実際には自社開発サービスのリプレースなので何かあったらリリース延期とかは出来る状態。
とはいえ、当初目標と定めていた6月末リリースを無事に終えられたので予定通りと言ってもいいと思う。

開発体制

  • エンジニア2人とデザイナー1人の3人チーム
    • デザイナーもReact、TypeScript結構書ける
    • エンジニアはcss書けない
  • RailsアプリからフロントエンドをNext.jsにリプレース
    • TypeScriptとGraphQL
    • NxRelay(この記事では触れない)

目標を達成できたのはなぜか?

小さいチーム

  • 人数が少なかったので意志決定と情報の共有のコストが少なかった

メンバー全員ある程度のスキルが揃っていた

  • 全員がReact,TypeScriptおよび周辺の開発知識は一通りあった
  • ただ、cssはデザイナーしか書けなかったためそこが少しネックになった

フィードバックループ

  • 毎日夕会を行いその日に起こった困りごとはその日に潰せていた
  • 自分以外の2人は毎日出社していたため密なコミュニケーションを取っていた模様(自分は週1出社)*1

フェーズごとの設計

  • 段階的にリリースを行うことになっていたため、フェーズごとにおおまかな設計を行った
    • 一つ前の開発で問題だったことをフィードバックして予め設計時に決めるなどの改善も行った
  • ここで決めたことと今動いてるシステムを迷いなく作業ができる
    • 自分だけリモートでコミュニケーションが少なくなっても進められる状態だった

社内システムである

  • 既存システムがあるのでそれを見ればよかった
  • 再現が厳しいものはビジネス側と交渉して落とし所を探ることが出来る
    • 社内だからというだけでなくお互いの要求を並べて尊重できる組織文化があったこと

個人の感想

ある程度スキルと経験の揃った人がきちんと予定通りに終わらせるためにどうすればいいか考えて動いた結果、というのが正直なところ。

あとは社内システムなので融通を効かせられるのも大きい。
実際に納期延ばしてとかこれやめにしてとかは言ってないけどいざとなったら相談できるのと、無理な仕様が来ても難しいと言える関係は安心感がある。

自分としては「React,TypeScript,Next.jsわかるよね?」ということで招聘されたので無事に役目を果たせてホッとしているところ。

*1:今は出社は任意だが2人は家の事情等で出社を選択していたらしい

スクラムのMTG時間を削れと言われた

1週間のスプリントで毎週1時間ずつレトロスペクティブとプランニングをやっている。

 

スクラム1ヶ月ほどやってみてメンバーはそこそこいい感じの手応えを感じていたっぽいところ、上司からこの取組についてフィードバックがあり「メンバーのやりやすいようにやってくれて構わない」と言ってくれつつも遠回しにMTGを削って効率化しろという指摘をされた。

 

自分としてはまたいつものかと思いつつも「予定としてのMTG時間だけ削ってもその分だけ見えないところに分散するだけですよ」みたいなことを言って一応この時間の確保は続けさせてもらうよう話をしていた。

 

しかしその週のレトロスペクティブで時間を減らそうという話が出てしまった。
その週、レビューが爆発してリリース出来ないタスクが発生していて今後どうするという話をしていて当事者たちは「プランニングで厚目に見たい」という意見だったが他の人は「時間が増えてしまうので関係者だけでやればいいのでは」という意見だった。
まるで自分たちは関係者じゃないみたいな物言いでショックだった。同じチームなのに。

 

それとMTG時間を減らすことが目的になっていたのと、何よりそうなった原因が上司からの命令だったというのが情けない。
始めるときに1時間って長いって言われがちだけど〜みたいな話をして納得してもらったはずなのになー。まぁ1ヶ月経てば忘れるか。。。

 

ちなみに、自分は毎回1時間全部使い切れとは思ってない。
早く終われて作業にかかれるならそれに越したことはない。
ただ、現実問題が起こっている状況でコミュニケーションを削るのはありえないというのが自分の考え。

 

試してみればよかったのだろうか。

MTG30分削れば儲かるのか?を率直に聞いてみればよかったのだろうか。

 

ここまで書いてみて、実はMTG時間短縮云々じゃなくてメンバーに対して疑念が出来てしまったところがしんどいのかなと思った。

ここまでやってきたときに協力的っぽい感じがしたのは自分に関係があるところだったからなのか、目に見えやすかったからなのか等々考え始めてしまってしんどい。

 

混乱期に突入したのかなと思えばまぁ前進してる感じはするのでいいけど、このままだと形骸化して崩壊しそうなのでなにか手を考える。
すぐに悪くなるものへの対策はしやすいけど長期間に渡って効いてくるものは納得してもらうのがなかなか難しいね。

 

とりあえずモヤモヤを溜め込んでしまったのでここで吐き出しておく。

 

人事異動の時期

期の変わり目でそこそこ大きめの人事異動が発生している。

 

人員配置の最適化といえば聞こえはいいけど個人的な感想だけ言えば、半年かけて作ってきたチームや文化がリセットされてたまったもんじゃないと思う。

 

 

一般的にチームが機能し始めるようになるには3ヶ月〜半年程度かかると言われている。
んで、自分が今期面倒を見てきたチームも半年経ち今は技術的な相談くらいしか面倒を見ていない。要するに自律的なチームになれている。

 

しかし今回の異動で6人チームから3人が異動になったのとチームの事業的な役割も変わった。
新しい人が入ってきたわけじゃないというのは若干マシだけどまたここが機能するようになるまでの数ヶ月、模索の期間が続くはず(形成期、混乱期)

 

ちなみに自分は今回の異動とは別にひとあし先に異動になっている。
自分の異動の話を打診されたときは、既にチームは機能していたしこのような大きめの人事異動の話は全く出ていなかったので安心して承けたつもりだったんだけど…。*1

 

 

とはいえこれはあくまで会社全体のうちの一部署一組織しか見てない自分の感想なので、全社レベルの視点で見ると正しいのかもしれない。今の自分にはわからないけど。

 

そういえば評価面談をしたとき、現場レベルでのマネジメントは問題ないからもう一段上の視点(?)でのマネジメントを学んでほしいというようなことを言われた気がする。

これはいわゆる「経営者視点を持て」というアレだと思ってるので避けたいんだけど、それとは別に上が何を考えているのかは知っておいたほうがいいのかもしれない。
けどこれって社内政治とかそういうのに繋がりそうという気もしている。

 

求められていることをもう少し明確にしたほうがいいかもしれない。
その中から汎用的なものを探すという道筋が良さそう。

 

 

 

*1:あと、入社当時に上長になるはずだった人のところに行けるということで喜んで承けた

スクラムしてないのにスクラムマスターと呼ばれて

2020年も終わりですね。

 

部署が変わってからの仕事上の役割を決めるときになぜかスクラムマスターという名前の役割を与えられていた。

ただしチームはスクラム開発はしていない*1

 

これには理由があって、

  • もともと配属されるはずのチームでアジャイルスクラム開発の経験をチームに広めてほしいという話があったこと
  • (手を動かす以外に)改善の活動をやりますよということをチーム内外へ明示すること

これらのことを上司が配慮してくれたことによる(と理解している)
とはいえ実際にそういう役割だと認識してくれたのは上司2人だけだったけどw

 

自分としては手を動かして成果物を作る以外の活動をする大義名分を得たと解釈して思う存分やらせてもらいました。

 

具体的なことは過去記事に書いてますが、いろいろ失敗しつつも経験や考えをもとに試したことが奏功したことは自分にとって大きな経験だったと思います。

 

 

来年やることはこれを自分のスキル・知識として明確化することですね。
これをやらないと今回の経験がただのラッキーパンチで終わったり自分がボトルネックになる可能性があるからです。

 

あと、問題・課題はきちんと捉えられているのに解消するための表現が下手くそという指摘もされてるので…。もう少し伝える力を身に着けなければ。

 

激動の2020年お疲れさまでした。

 

 

 

 

 

*1:スクラムしてるとは?という話はあるが少なくともチームはスクラム開発しているという意識はない状態

webpackerのアップデートをした

大変だった。

その一部始終と分かったこと思ったことを残しておく。

 

先に書いておくとアップデートできたからと言ってwebpacker理解できたわけではない。

ただwebpackerを扱うときどのあたりを触ったりどのあたりの記述が関係してるのかのあたりはつけられるようになったし、開発サーバー立ち上げるときに流れるログにもちゃんと意味があってそれがヒントになることがわかるようにはなった。

 

アップデートの手順

  1. おもむろにwebpackerをアップデート
  2. rails webpacker:init
  3. 必要なnpm packageをインストール
  4. 初期化前との差分があれば導入する
  5. 動作チェック

見るべき場所

おもに見るべきは webpacker.yml と config/environment.js 

environment.jsがbabel他のloaderの設定になっている。

 


詳しいことは公式に書いてある。
主にはchunkのやり方が変わったこととerbに埋め込むタグ(javascript_packs_with_chunks_tag)を使うこと、画像などはmediaパスになったこと、webpacker.ymlに  extract_css: true を書くこと、が主な対応だった。

 

webpacker立ち上げるとログにjsやcssのパスが大量に表示されるところがあるけどあれが javascript_packs_with_chunks_tag で読ませるべきパスと実際のファイルの対応になっている。
あれがおかしければ読み込めないし、欲しい形のパスになっていないならenvironment.js内のloaderの設定を見直す、という感じで対応した。

 

 

それにしても、webpackerのググラビリティ低すぎ(勝手にwebpackとして検索される)

webpack自体もだいぶ辛いけどwebpackerはwrapされてるのもあって更に辛い。
世に脱webpacker記事が沢山あるのもうなずける。

 

そんな感じで四苦八苦しつつもなんとかアップデート自体は完了した(3系→5系)
…と思ったらそのプロダクトがサ終することが決まった。

 

この展開、前にも見た気が…。呪われているんだろうか*1

 

 

速習 webpack 第2版 速習シリーズ

速習 webpack 第2版 速習シリーズ

 

 

*1:一応別のプロダクトにそのまま応用できるわけだから完全に無駄になったわけではない

マネージャーのマネごと

今の部署に来てからマネージャーみたいなことをしている。しかも3プロダクト並行で。実際は役職も権限もないけど。

 

 

入った当時の状況

この3プロダクトは毎週リリースをしないといけない。
しかし自分が入った当時、リリース当日朝にやっとレビューが出たり早くレビューが出ても指摘コメントが数十ついてリリース優先で別タスクに回して強引にリリースしたりとかしていた。

 

この3プロダクトに割り当てられたときに上司から与えられたミッションは「この毎週の定常3リリースがスムーズに回るようにしろ。やり方は問わない」というものだった。

方針

3プロダクトは兼任が多くて単純に人が足りない。 
とはいえ簡単に人が増やせるわけでもないので現状の人間でやっていくしかない。

 

自分がコード書けば早いとは思いつつ、それだと自分が抜けた時にまた元に戻ってしまうのでなるべく自分が手を動かさず今いるメンバーがやり方を変えたり成長することで対応できるようという方針に決めた。

また、自分が抜けてもそのやり方がある程度持続できるようになれば更に良い。

 

やったこと

タスクの共有

この状態になるのにありがちなことだけど、毎週のタスクを決める時に実装の方針や何をテストすべきかが共有されていなかった。

 

なので自分が入ったばかりでプロダクトのことよくわからないから教えてという体で全員いる場で内容と担当者が考える実装方針を説明してもらうことにした。
会話が発生すればそこで質問も発生するので結果として実装方針がより強固になるしテストパターンもある程度明確化される。

そしてそこで話してもらったこともきちんとチケットに書いて残してもらうことにした。

 

これをすることにより、一部のメンバーしか実装できなかった部分を少しずつビギナーにもやってもらえるようになった。

 

1on1の実施

今の会社は1on1MTGを積極的にやっていいみたいな空気があったのでそれを使って各チームで合計5人のメンバーと毎週30分ずつ面談をすることにした。

 

ちょうどこの直前くらいにスクラムフェス大阪で「信頼されるスクラムマスターとはよく相談される人間である」みたいなのを見かけたのでそれを目指そうと思ったのが始まり(スクラムマスターじゃないけど)

speakerdeck.com

 

結果としてこれはかなり効果が大きかった。
大人数で話している会話の輪に入るのがとても苦手な自分が、既にある関係性が出来上がってるチームに途中から入って信頼してもらう(話や相談を持ちかけてもらえる)状態になるのは普通にやってただけではかなり難しかったと思う。

 

気をつけていること

プロダクトの数が多いので型通りのスクラムみたいなやつは早々に諦めた(プロダクトの数×毎週のスクラムイベントをするのは時間的な意味で現実的じゃない)
前の部署で型通りを意識しすぎてプラクティス厨みたいになってしまっていたのを気にしていたのもある。

 

形は気にせず、まずは目の前の問題に確実に対処しようというのは気をつけていた。
出社日ができて近くでタスクに関する雑談や相談が発生してたら必ず首を突っ込むようにもした。

 

タスクについては毎週「チームで当たっていく」ということを念頭に置いて、最初は無理やりMTGをねじ込んででもタスクの内容や各情報を共有させるようにしていた。
完全在宅ワークなこともあって特に新卒や2年目のメンバーは全然キャッチアップができていなかった。ここは通常通りの出社ならもう少しマシだったんだろうなとは思う。

部署に入ったばかりの頃「必要なときは会話しましょ」というのが盛んにチャットに流れていて既に関係性が出来上がってる前提のやり方を続けてしまってるんだなと思ったのを覚えてる。

 

 

基本的に社風として改善を社員同士の仲の良さに依存してる感が強い。
だから既存の社員たちはこれまでのやり方の延長でやろうとするけど完全在宅になり新卒や中途が入ってくるとほころびが出てしまうという感じなんだと思っている。

 

個人的にはそういうコントロールができないものをあてにするのはよくないと思うのでなるべく仕組み化していく方向で進めるつもり。

 

 

 

 

お取り潰し

それは前回の記事を書いた翌営業日のこと

 

上司「この事業は撤退する判断をしました。部署は解散となります」

 

( ゚д゚) ・・・
 
(つд⊂)ゴシゴシ
 
(;゚д゚) ・・・!?

 

というわけで部署が解散になりました。当然、チームも解散です。

本当にこの前日に上記のふりかえりブログ書いたばかりだったのであまりのタイミングに笑えてきてしまって、あとで上司に「なんで笑ってたの…(ドン引き)」という反応をもらいました(実話)

 

というのが3ヶ月前の話。

 

現在3プロダクトでマネージャーのマネごと(権限はない)をしつつ2つくらいのプロダクトでコードを書くみたいなことをしてます。
プロダクト多すぎってレベルじゃねーぞ!!!

 

こっちはこっちでいろいろ大変になってたのでいろいろ直したりしてましたがブログ書こう書こうと思ってたら時間が経ってしまったのでそれは次の記事で。