頑張る前
今月の頭に今の会社に転職をしたのだけどもまあ愚痴の絶えない和気藹々とした職場体験をさせてもらっている。
それはおいておくとしてアサインした業務のマネジメントが完全に崩壊、というか実質機能していなかったので さすがのぼくも「これはヤバい、主にぼくが働く上でつらすぎる」と考え今まで頑なに拒否ってたマネジメント…のようなことを行い2週間ほど経過したのでその経過報告を書いておく。 (お前のやってることはマネジメントじゃない！とかいうマサカリがあるかもしれない。マネジメントとかよくわかってないのでご容赦願いたい。)
一応プロジェクトリーダー(以下PL)という名前の有名無実化した役職は存在するが タスク登録マシンと思いついたらとりあえず指示出しマシンになっているので実質いないものとして考えて欲しい。
状況説明
- PLのタスクに登録する情報量少なすぎ問題
- ○○を実装してください
- 何故？どういう実装がしたいの？それによって期待する内容はなに？？？となってしまっている
- 技術的に自信のないメンバーが多いため言われたままに作業してしまっている
- 不具合報告もURL貼って「デザイン崩れてるので直してください」一言で終わっておりいちいち作業者が確認にいかないといけない
- URLがステージング環境のもので自分の開発環境だとそもそも再現しない…みたいなことが多々ある。
- タスク登録≒マネジメントだと思っているフシがある
- いつまでにどういう機能が実装されていないといけないのか？が明確でない
- 開発チーム全員の共通認識としてこの実装は優先されるものなのか？それよりはこっちを優先したほうがいいのでは？という意見がほうぼうから寄せられている
- 明確なプロダクトの方向性がわからない
- 開発チームとPLの温度差の乖離
- 開発チーム:バギーなシステムで本来1時間で済むような修正に対して上記したような他の不具合のせいで1日作業になったりする
- PL:とりあえずコンバージョンがあがらないのでSEOをあげて対応、分析しよう！そのためには今のデザインだといけないのでこう変えて欲しい！
開発チームで行ったこと
さすがにこれではまずかろうということで何故か入社2週目にしてメイン担当者になってしまったので仕組みを変えないとぼくが死ぬ。 精神的に死ぬし、このままいったら精神病みそう…と思ったので以下の改善を行ってみた。
- KPTによるふりかえりを実行
- 毎週15分~30分ほど行うようにする
- アルバイト社員が多いため、なかなか全員での参加が難しいためTrelloを使用。
- プルリクエスト(PR)導入
- 今までは直接masterブランチに書き込んでいたらしい。ヤバすぎるのでとりあえずやめさせた。
- 開発チームでgitに関する知識を確認したら概ね基礎的な知識はあるようだったので実行に踏み切った。
- 外部のデザイナーさんだけがわからないということだったのでぼくがサポートすることで対応。結構たいへん。
- 過半数がわからなかったら全員まとめて講習会を行う予定だったがそれはしなくて良くなったのでこれは助かった。
- コードレビュー導入
- 必ずブランチ切ってPR作成させるようにした
- マージを実行するのはコードレビューが通ったもののみ。レビュー通ったら作成してもらったPRをマージ。
- 今はまだぼくが権威的になってしまっている。ぼくのコードに対するレビューがついていない状態なので今後はこれを改善したい。
- タスクのスケジュールと担当者を設定
- ぼくからすると驚くべきことにスケジュールや優先度、担当者を決めずに作業を割り振っていたらしい、Backlog上でやりとりを行っているのに！
- とりあえず担当者とスケジュールを決めてから割り振るようにPLに指示
- 開発チームのリーダーを設定
- 今までは誰に聞けばいいかわからない中で指示された内容をただこなしていたらしい。
- 一応名目上は社長が開発チームのリーダーだったそうだが社内にいなかったり、ほぼマネジメントしてなかったりで事実上放置されていた
- 後述する1on1でかなりの開発チームメンバーがこの点に関して強い不快感と不安感を抱いていることが判明した。
- 1on1ミーティング
- ぼく以外に正社員で担当している人がいないため全員アルバイトだが一緒に働くチームメンバーなのでどう考えているか？どう感じているかを知る必要があった。
- 正社員も入れ替わりが激しいがアルバイトも同じくらい激しいのでそれを緩和しないと前に進めない状態になっていた。
- エンジニアリングに関する考え方や今後の人生の方向性、どういうことを楽しいと感じているのか？などなど割りとざっくりと知ることが出来たのは良かった。
- 一方、前述したような仕事上の問題点や不満点がかなり溜まっていることも露見した。
- 基本は1ヶ月に1度の頻度で行うが言いたいことがある場合は呼び出してOK。人事評価とは別枠であることを明言。
- ぼく以外に正社員で担当している人がいないため全員アルバイトだが一緒に働くチームメンバーなのでどう考えているか？どう感じているかを知る必要があった。
KPTで振り返ってみた結果
大まかにはタスク関連の不満が噴出した、という印象が強かった。 ぼく個人の感覚としてもこの点に関しては異論がなかったので「あーやっぱりみんあそう思ってたのか…」という感じ。
Problem
- git/github運用に関する学習コストが高い
- タスクの内容がわからない
- 全体のスケジュールが不明
- 優先順位度が不明
- まともに動かないバギーなシステムなのにSEO強化するほうが本当に優先度高いの？とかそういうの。
- 仕様に関する理解度が低い
- 仕様を完全に把握している人間がいない&資料がない。デザイン用のサンプルページがあるだけ。
- 確認しました！報告があがるが実質、確認されていない
- 機能が丸々動かない、エラーページに移動するレベルの触ればわかる問題が放置されている、誰もそれを報告していない。
- DBの値が信用できない
- 開発DBの中でデータ不整合が発生している
- 各個人ごとに開発環境は与えられてるがDBが共通している可能性がある。
- 本番DBの中にテストデータが紛れている、それも結構な数のデータが…。
Try
- ショート会議をこまめに行うことで情報共有の粒度を下げる
- 会議をしたら必ず議事録作る
- 参加していない人もなにが決定して、なにが保留になって、どういう問題があがっているのかがわかるようにする
- チャットツールを統一する
- github運用の方針をWikiに残す
- 会議にはアジェンダ必須を徹底する
- 暗黙の了解を見える化
Keep
- ふりかえる機会があるのは継続したい
- コードレビュー/PRが自身の勉強にもなる&相談しやすくなる
- 全体的にマネジメントがよくなったので以前よりやりやすくなった
- 会議のスプリットが短くなったので共有事項がわかりやすくなった
今後の課題
- タスクの明確化
- 優先順位設定の基準を明確化
- 全体のスケジュール共有
- Laravelのマイグレーション機能を使ってDB管理を行う
- テストコードを書く
- 特にModelクラスのあるメソッドが便利だからといろいろなところから呼び出されており、そのたびにチェックするパラメータが増えている
- モデルの1メソッド内の行がざっくりと500行くらいある。そのモデル全体の行数が1000未満なので大半がこのメソッド。
- 本筋とは関係ないがKPTやコードレビュー、PR開発に対して開発トップから横やりが入る
- 「うちのやりかたでない」「開発効率が落ちる」「今はそのフェイズではない」、「うちの開発力では教育コスト/学習コストがかかりすぎる」などなど。
- その割にはgithubなどの運用に関する知識が薄かったり、メンバーの知識に対する把握がお粗末な印象が拭えない。
今後どうしていきたいか
- 試用期間中に辞めたい
- 2月入社で3ヶ月試用期間なので5月までに転職したい
- ぼくが辞めても取り組んだいくつかの仕組みが残るようにしておきたいとは考えてる。
- タスク関連の問題は今後残り続けると疲弊し続けるだけなので対処するために全体で情報を共有する
- どうにもPLはこの問題を軽く考えすぎているきらいがある。
- 開発トップによる横槍が入らないようにPLに依頼……したら翌日欠勤した。
- 見える化の促進
- 意見の言い合える空気感の生成
- 問題の抽出と共有
- PLや社長がこの点を軽視というかきちんと把握していないように感じることが多々ある。
- KPTを行っているがまだ本音が出てきているように感じないので本当に感じている不満を言える空気を作りたい
- 一緒に頑張ってくれている開発チームメンバーは未経験の大学生なのだけどもやる気があったり向上心がある人間ばかりなのでぼくで教えられる内容範囲であればきちんと技術を吸い取って自分の力量に反映してもらいたいと考えている。
- 今の会社にいることでプログラミングの楽しさを感じられず苦手意識を持っている優秀な学生さんが1人いてこのメンバーに「プログラミングは楽しいんだよ！」ってぼくが辞める前に思ってもらいたいと考えている。
まとめ
マネジメント？というのかどうかわからないけどもそれっぽいことをやって2週間ほどなのだけどめっちゃ大変。 マネジメントいらない！とかいう話題が先日Twitter上でバズってたけどもぼく個人はあまり賛同できなかった。 少なくともチームメンバーに大きく依存する問題だと思う。
TeamGeekでいうところのHRT、謙虚、尊敬、信頼がないチームだと誰かが旗振り役をしないとチーム自体が崩壊するのだと実感した。 それと同時に今までぼくが気持ちよく開発に専念できたのはそういったマネジメントを行ってくれた上司や同僚の努力の賜物だということを強く実感出来たのでその点は良かったように思う。 どこかの会社が週一でマネジメントの役割の一部を一般社員に移譲してマネジメントを経験させて育てていく…みたいなことをやってるという記事を読んだことがあったが得心がいった。 これは経験することで大変さや相手が求めているものがなにか？がわかるようになってくる気がする。
KPTやコードレビューに対してチームメンバーが割りと好意的な意見を返してくれて非常に嬉しく思っているが あまりこれを正面から捉えすぎないように注意しようと思っている。
重要なのは開発チームにとっての最善を目指すことであって、ぼくが実現したい開発環境でないのだという戒めを強く思い続けておかないと ぼくは暴走してしまう可能性が非常に高い。 都度、ふりかえりなどを行ってメンバーの意見をすりあわせてベストな状況に持っていけるように頑張りたい。
さいごに雑談
これは本題とは関係ないのだけども先日開発トップに呼び出されて以下のようなことを言われた。
「アイディアをあげてくれるのはいいけど小銭稼ぎがしたいの？そういう印象しかないんだけど？」と。
うちの会社は良いアイディアがあがった際に少額ながらインセンティブが与えられる。 ぼく個人としてはコードレビューやPRやってなかったのでこういう手法を知らないだけなのかな？と思って提案したり こういう面白い取り組みしている会社の制度がありますよ！っていう紹介のつもりだったのだけども どうもその投稿数が社内で多かった。他の人が月に数件しか投稿しないところにぼくが10件以上あげたのでその点は明らかだったと思う。
ぼく個人としてはもらえるならもらうけど別にお金のためにやってるわけではなかったのでさすがにこれには不機嫌を隠せなかった。 この発言を受けて元々転職先を探していたけどもさっさと辞めないとぼく個人が潰されるなと感じることになった。
この件は社長以下、上層部にも伝わってしまい、その日のうち開発トップが注意を受けていた。 （元々週のうち大半を休んでいるんだけども、案の定翌日休んでた。）
という経緯があってかなり本気で転職先を探しているので以下のどちらかの条件を満たしている会社さんがあればTwitterでもFacebookでもWantedlyでも連絡をくれると嬉しいです。
- 関西圏外だけどリモートワークが可能
- 関西圏内で自社サービスを展開している
- 京都だと個人的にめっちゃ嬉しい。
なおぼく自身はPHPer歴10年選手でLaravel1年生、基本的なMVCは理解出来ているって感じ。好きな言語はGolangとPHP。
リモートワークが条件に入っているのは将来的に語学留学がしたいと考えていてただその間も働いていたいって考えてる、主に金銭面や精神的な安定性などの面で本質的でないことに邪魔されたくないと思ってるからなんだけども。 あと仕事が楽しい場合辞めてしまうのが惜しいというのもある)という理由になります。
これらの条件があるのでこの条件を受け入れてくれる企業さんだとめちゃくちゃ嬉しいです。 自社サービスとリモートワーク、どっちが重要なの？と言われたらリモートワークがちょっとだけ上位に来てます。 元々受託よりも自社サービスなどを成長させていくことに楽しさや喜びを感じるタイプの人間なので受託だとやらされてる…みたいなことを感じるのがあまり好きじゃないです。 安定して稼げるのは間違いないし、それでお金稼いでるのも理解はしているつもりなんですが。
もういっそフリーランスにでもなってやろうか！みたいに最近考えることが多くなってきて大変。 やらないのはマネタイズや経理なんかの管理、精神的に追い詰められそう…という面で自分には向いていないんじゃないかと考えているからだ。
以上。 転職の斡旋などあれば是非ともよろしくおなしゃす！！！