とある案件の開発フェーズでかくかくしかじかがありまして、今年の4月にチーム異動しました。もう半年たつのか〜。案件は無事リリースされて、リリース後のバグも修正し終わっています。今回はかくかくしかじかを書きます。あんまり思い出したくはないけれど、自分が他の人に同じことをしないようにいましめて。
3行まとめ
- デスマーチ案件で病んでしまい案件をおりて異動することになった
- チームビルディングについて勉強するようになった
- マネージャーには感謝していて、これから一緒にがんばりたいと思っている
ことの経緯
案件以前はsmartyテンプレートの文言修正やキャンペーンバナー設置などの案件を担当していました。PHPエンジニアのはずなのにPHPを書いていない状態(?)。もっとロジックとか触りたいなあと思っていたときに、案件がふってきたという感じです。
私がエンジニアとして案件に参加するまでに、仕様MTGとかマイルストーンMTGとかいろいろあったみたいだけど、1年目だからか?呼ばれなかったです。負担を増やさないようにするための先輩の配慮か、居ても役たたずなだけなので呼ばれなかったかは定かではないですが・・・
リリース日が決まっていない状態からのウォーターフォール開発が始まる(すでにデスマーチ臭)。
おりてきた仕様は詰められていないので(ぬけもれあり、だぶりあり、赤入れ形跡なし)カオス状態。それを1つ1つチケット起票して問い合わせる作業、大変でした。仕様書はエクセルの日付バージョン管理で、コメントとかつけられないんですよ。なので、スクショを撮ってチケットに貼りますorz
一応チケットでタスク管理しているので、タスクのストーリーポイントから工数管理、ガントチャート作成できます。ガントチャートはいわゆるWBSですね。で、それを使えばいいのに、GoogleスプレッドシートのWBSが生える、チケットとGoogleスプレッドシートのダブル管理が始まりそうになる・・・
このあたりはまだ元気だったので、「チケットでタスク管理しているので、ガントチャート作れますよね?Googleスプレッドシートいります?」が言えた(えらい)。
「おっしゃるとおりで、今まで作っていたので今回も作りましたが、廃止します」とのことで廃止されました。案件によって「どこまで決めてから着手するのか」「案件規模」「リリースまでの日程的余裕」などいろいろ変わってくるので「今まで作っていたので」という脳死の理由でプロジェクトマネジメントしないでほしい(これはぐち)。
比較的大規模の改修案件だったので、設計ドキュメントを作ろうという話になる。
このあたりで病み始める。まず、設計ドキュメントを作ったことがない先輩エンジニアから指示を受ける。それを見たリーダーがサンプルを適当に送ってくれるものの、「わかりやすいと思う書き方で書いて」という指示がプラスされる。
大規模の改修案件ということで、マネージャーもドキュメントを確認してくれることに。ドキュメントにフローチャートがないので書き足すように指示される。完全に後出し。このころにはもう設計ドキュメントが終わって、実装着手できるはずだった。
大どんでん返しがあったこの頃からコロナの影響でリモートワーク開始。
一人自室でわかりやすいと思う書き方のドキュメントを書く。リモート会議でレビューしてもらい、大量の指摘を受ける。一人自室で天を仰ぐ時間が増える。
夜なかなか寝付けない状態が続く。ストレスで変な汗をかく。
ようやくドキュメント修正おわり(修正できていないところもあった)、実装着手。
HTMLマークアップをテンプレートにする。HTMLマークアップの修正は当然HTMLで届くので、自分で書き直したテンプレートと届いたHTMLで大量の差分を出しながら、修正を取り込む。
dockerの開発環境がなぜか動かなくなる。
開発終了日がなぜか早まる。
だんだん嫌になる。
仕事を休む。
仕事を休むとその分実装が進まないので(当たり前)、もう間に合わなくてもいいなという気持ちになってくる。
仕事を休んだ次の日にリーダーからSlackDMが届き、急遽1on1をすることになった。なんとなく嫌なんですよね〜wみたいなテンションで話すと、もっと具体的に言ってくれないと対処しようがないと突っぱねられる(突っぱねられるは一人称視点です)。リーダーは普通のことを言っているのに気づかなくなる。
リーダーから聞いたであろうマネージャーからSlackDMが届く。リーダーも若いからまあうまくいかないこともあるよ、とのこと。案件おりて仕事やめたい旨を伝える。「まだこの会社で吸収できるものがあると思うから異動しましょう」ということになる。
案件おりて異動することが決定する。同時に引き継ぎタスクが発生する。
実装はだいたい3日くらいオーバーしたけど、特に問題がなかった。(このスケジュールではじめから組んでくれればよかったのに)
テストコードとレビュー対応だけ先輩にお願いして案件をおりて異動した。
敗因:
- ヘルプが出せなかった
- 「なんとなく嫌、やりにくい」の言語化ができなかった
- 人に期待しすぎた
ヘルプが出せなかった
1on1制度とメンター制度とOJT制度があります。が、どれ一つうまく機能していなくて、自分から機能させられていなくてどこにもヘルプ出せれていなかったんですよね。
1on1制度:
直属のリーダーと2週間に1回、30分お話する会。
キャリアパスの話とか、最近勉強した技術の話とかをしています。
優しいリーダーなので悪口言っていいのかわからず、言い出せなかった。
メンター制度:
3〜5年目の先輩エンジニアと2ヶ月に1回、30分お話する会。
コロナの影響で延期になって、開催できなかった。
OJT制度:
同じチームの先輩が半年間、業務のすすめ方を教えてくれる制度。
本人の悪口を面と向かって言えないので、言い出せなかった。
制度として用意されているのは以上なんです。が。もう一つ大きい要素があって、内定者時代からよく面倒みてくれたエンジニア人事の上司が退職されて、話せる人がゼロになったことですね。これが本当につらかったです。
あとは、コロナの影響で出社しないため同期とランチに行く機会もなく、話すタイミングや話し相手がいない環境でした。(今後もフルリモートでの業務が続きそうなので、これは今後も気をつけていきたいところではあります。)
「なんとなく嫌、やりにくい」の言語化ができなかった
これはもう私個人の言語化能力が低いことが一番悪いんですけど・・・
リーダーからも「何が嫌なのか言ってくれないと対処できないです」みたいなことを言われまして。うん、そうだよなあと思いながら、「壁打ち付き合おうか?」とか言ってくれればよかったのになと思いました。
人に期待しすぎた
仕様は固めておろしてくれる、具体的な指示をしてくれる先輩がいる。これらはすべて自分の中で作った幻想、幻想を現実に持ち込むな危険!です。
察して声をかけてくれる人はいません。リモートワークだからということもありますが・・・
異動後
怪我の巧妙ではないですけど、このタイミングからチームビルディングの本とか読み始めました。今はいろんなチームのあり方があるなかで、自分のチームはどうしていったらいいのかを考えています。
少し話はそれますが、わたし自身、中学の部活時代から大学のサークルまで、いろいろなチームに所属し、いろいろな経験をしました。そのころはチームビルディングの知識がないままチームに所属していました。が、今チームビルディングを勉強すると「こうすればよかったんだなあ」とか「意識してなかったけれど、いい雰囲気生んでいたんだ!」という発見があり、今までのチームメンバーに感謝しています。経験はお金では買えないですからね。
IT業界は業界の移り変わりが激しく、それに伴い必要技術スタックも変わってきます。なので、わたしは需要と供給がマッチした職場ではたらけばいいと思っています。だからチーム異動とか転職とか賛成です。
いろいろな価値観があって、それは当然です。OJTの先輩にはあまりこのような考え方に賛同してもらえず、チーム異動のときにかなり悲しませてしまったみたいです。ごめんな。
異動をすすめてくれたマネージャーは、実はこの案件の前からわたしのやりたいことを実現するために異動を考えてくれていました。案件が終わって落ち着いたら異動する予定でいたみたです。理由はアレですが、異動の時期が数ヶ月はやまったということになりました。
いい意味でぶっとんでいる強いマネージャーなので、今は(言葉選ばず)言いたいことが言えている環境です。きれいな日本語を使っていきたいです。
マネジメント業務でカツカツなところ、自分で手を動かしてプロトタイプ作ってみたり、いろいろぐぐってサンプルになりそうなGitHubリポジトリ探してきたり、そういう背中でみせていく姿勢も尊敬しています。わたしがこの会社にいる理由として、このマネージャーと一緒にはたらきたいからというのは大きい割合ですね。
今は「配属されて半年で異動になったこの話」は飲み会のネタにしていますが、当時は本当につらかった。朝になってから、仕事したくないなと思って急遽有休とる迷惑ムーブ、反省しています。あと、彼氏やつあたりしてごめんね。ぐちを聞いてくれた元研究室同期、壁打ちにつきあってくれた元情シス同期、ありがとうございます。
未来の自分へ
・以下わたしがされて嫌だったことをふまえて気をつけるべき点
<要件、仕様>
・エクセルでの日付バージョン管理をしない、している人がいれば移行を促す
・誰も全体像をつかめていない仕様を開発におろさない
・仕様書にやる気を感じられない(抜け漏れだぶり赤入れなし)場合は、一度これでfixなのか確認する
<設計ドキュメント>
・初めて&「あなたがわかりやすいと思う書き方で書いて」という指示での設計書作成なのに本気でレビューを飛ばさない
・「あなたがわかりやすいと思う書き方」みたいな個人の主観による指示をしない
・個人の主観で書いてもらった設計書をけなさない、個人の主観をけなしていることと同じ意味
・サンプルだけ渡してあとは任せる態度をとらない
・一度自分でもぐぐってみる
・設計書がない、運用できないなら、運用できる仕組みに変える(swaggerなど)
・何をどこに書くのか(基本設計と詳細設計の境界)が明確にする、後出ししない
<開発の進め方>
・どうしてこの工数ですすめるのか、タスクブレイクの粒度は適切か、言えるように
・新規案件のときに書く設計書と既存改修での設計書は既存改修のほうが書くのに時間がかかる、それを考慮して設計工数を決める
・スケジュール勝手に変えない