こんなプロジェクトでよく進められるなという話

昨今は働き方改革やコロナの影響で生産性や個人の負荷軽減対策をしているとは思います。
しかし、その状態でもあまりよくないプロジェクト進行をしているところもあります。

「このプロジェクトやばくないですか?」

「こんな現場あるのか」と目を覆いたくなるレベルですが、あります。
僕の働いている会社では以下の状況でプロジェクトが進んでいます。

  • 設計書のメンテナンス工数がない or 設計書を書く工数が確保できないスケジュールに設定される
  • 上流工程が遅れているのに、終了時期が変わらない。
  • 本来のPMがマネジメントしないで、リーダーがほぼマネジメントをしている状態。それでいてスケジュール決定の権限はPMの方にある模様。
  • 手動テスト、エビデンスExcelに貼り付ける。
  • プログラム設計・開発自体の工数も短い。
  • 口頭での仕様変更・追加が多い。
  • 開発者が見積・詳しい仕様を聞いていない状態でスケジュールが引かれてしまう。
  • コーディング規約がない。
  • レビューなにそれおいしいの?
  • テーブル定義書?ER図?なにそれおいしいの?
  • 課題管理なにそれおいしい(ry
  • 振り返り、PDCAサイクルなにそれお(ry
  • 自動テストなにそ(ry。

他のプロジェクトでは以下の状況も入ってくるらしく、僕のプロジェクトはまだマシな模様だと最近知りました。
正気かよ。

  • 定時後に開発者に連絡され対応させられる。開発者に対する定時という概念がないような連絡をされる
  • 上司のパワハラ
  • 新人・新規参画者にまともに教育しないで「進捗どうするの?リカバリー策考えろよ」というだけの上司が存在する。

自分の作業状況とプロジェクトについて

仕事の経緯を振り返ると、入社して3か月は本社で研修を受けていました。
そこから東京の別会社に常駐することになり、自社の社員であるPMと仕事することになりました。
新人として配属されてから半年程度で、なぜか開発のリーダーにさせられ3年間過ごしてきました。
配属されてから1年半くらいはパワハラまがいのことを受けつつ、PMに振られた仕事をこなしていきました。
正直、PMから今までまともなフィードバックをもらったことはなく、その状態で3年間仕事してきましたね。

リーダーをやっていたときは、ほかの会社の方やフリーランスの人もいたみたいですが
その人達からのPMへの評価は「無能」とか「大きな赤ちゃん」とか散々な評価でした。
当時はよくわかりませんでしたが、今だと自分もそう評価する確信があります

最近の仕事

最近、リーダーの仕事は「こんなにあるのが普通なのか?」と疑問を感じてきました。
評価や資料を聞く限り、私は「サブリーダー」の扱いなのがわかりましたが
サブリーダーってこんなに作業あるもんなんですかね。

  • スケジュール・担当者・作業割り振り(WBS作成・管理)
  • 開発・テスト・詳細設計書(過去形)
  • 試験
  • 業務マニュアル作成
  • Git/slackなどのソース運用
  • 仕様変更管理
  • 定例・会議などの議事録作成・司会
  • 進捗管理(PMのも含む)
  • メンバーの業務知識・技術サポート(Sierなので技術といってもたかが知れていますが)
  • 勤怠管理
  • 正社員的な雑務・資料作成

最近は知らないうちにPMの方で期限が引かれていて、その期限を守ってくださいと言われるようになった。
それがどういう工数見積ったらこんな期限になるんだ?と思うくらいに短い。

必ず資料を送る際に、スケジュール部分と見積金額を省いて送ってくる。(何かやましいことでもあるのか)
どういう見積を出したのか?そもそも全体のスケジュールがどうなっているのか聞かないと教えてくれない。
聞いてもたまに教えてくれないときがある。

正直どう考えてもおかしなプロジェクト・環境だと思っている。

プロジェクトの状況をなんとかしたかった

1年ほど前から、この状況は自分の負荷がどんどん増えていくと思ったので
いろいろ対策は立てました。

詳細設計書は書かない

最初WBSを作ったときに、詳細設計書を作る工程を入れられました。
が、調べたところ開発者がほとんど使うことがないことが分かりました。

それもそのはずで
仕様が受入試験や定例で変わるのに、詳細設計書をFIXする工数確保できない期限になってる。
そして詳細設計書の書き方も統一されていなければ、レビューもしない。(そんな工数もない)

更に深く僕より長く働いている人に、詳細設計書を提出したことがあると確認したら
「ない」と言われた。
裏付ける根拠として、PMが一人で作って修正した内容も詳細設計書は作っていなかった。
つまり、提出物ですらなかった(PM曰く提出物らしいが、出してなくてもリリースできている以上、発注者も確認していないし重要視もしていない)。

したがって、僕の行っているプロジェクトのスケジュールは詳細設計書をほぼ入れないことにした。
入れてもテスト完了後に入れて、バッファとして使うことにした。

何回か送っているWBSでほとんど指摘されたことがないので、中身ほとんど確認してないんじゃないかな

口頭で変わった仕様は議事録を残す

多少効果はあると思うが、私の負荷が大きく増えてしまった。

「当たり前じゃねーの?」と思うかもしれないが、僕がやる前はやっていなかった。
なので頻繁に「この話なんだっけ?」→「覚えてないので調べます」という現象が起きた。
しかも、その情報はほかの人はちゃんと聞けていなかったということもあった。

あまつさえは、PM自体が発言した内容、自分らメンバーが報告した内容を忘れているのだ。
お前それでよくPM名乗れるなと思うが、まぁ業務が死ぬほど忙しいんだろうと考えておくことにする。

口頭での仕様変更伝達を避ける

あまり成功していない。

そもそも今まで議事録を残していなかった以上、口頭伝達による仕様変更は避けるべきだ。
文章で伝えられる非同期コミュニケーションツールが「メール」しかないので、それで仕様確認を行うようにしてみた。

いくつかは解答がもらえるが、体感半分程度は解答をもらえない。
聞いてみるとメールを見てない、間違って捨てたなど衝撃の回答をもらえる。
「何回も同じ間違い指摘させるな」と昔言われた記憶があったが、同じ言葉を私も返したい。

メンバーに連絡するときはslackや資料を用いての説明等を行っていた。
口頭で説明した際も、内容や依頼事項等を文章で再送付した。
メンバーのレスポンスは良いので、非常に助かっている。

でもメンバーからPMに確認する際は相変わらず口頭確認になってしまっている。
そういう時は「覚えていない、残していない本人が悪い」と逃げたいところだが
確認をする際に大体はリーダーと担当者に聞くことが多いので、僕も被害を被る。
だから放っておけないのですね

定例での進捗確認をしないようにしてみた

これは賛否両論あるかと思います。
当時はそれぞれのメンバーの進捗報告を定例でやっていました。
しかし、内容としてはほとんど意味のないものでした。

まず、PMは仮に進捗が悪いと「どうするの?」「なんとかしろ」「リカバリー策立てろ」くらいしか言わず、特別フォローをしてくれるわけでもなかった。
正直実際のリカバリーやフォローはPMではなく、教育担当者や当時のリーダー、もしくは本人からの残業カバーになっていた。
また、キレることも多かったので、メンバーは恐怖して本当の進捗を言うことがなかった。(しっかり言ってる人もたまにはいたが、ほかの人にも影響するので大変ではあった)
進捗管理しているように端から見えるが、実態は嘘言ってるだけなので無駄でしかないと気付いた。

なので、リーダーになってから定例でそれぞれの進捗報告はやめて、質問や報告したい人だけ報告するようにした。
PMに聞かなくてはいけない内容だと、よほどの内容だからだ。

最近では内容を把握したいのか、日報を送るように連絡がきた。
聞く限り、新しく就任した部長がちゃんと進捗管理しろと提言・指示したらしい。
まぁそれ自体は妥当だと思うが、このままいくと過去の悲劇と同じ轍を踏む気しかしない。

PMの進捗確認

「うっそだろ」と思うかもしれないが、今まで3年仕事をしてきてPMの仕事っぷりに不安しかなくなったので
さりげなく進捗や状況を確認してみることにした。

今までのPMが起こした不思議な現象をまとめてみる。

PMから言い出した作業が行われず、本番リリース直前で作業した

前にあったことをそのまま書くと、
PM自身から「作成する」と言っていたSQLの処理があった。
それはいわゆる物件の初期データを作成する処理であり
データがちゃんと入らない場合、システム上の処理が正常に動くかは検証していない状態だった。
また、ちゃんと作ってくれるかも今までの仕事っぷりから正直心配だったので、早く作ってほしかった。

欲しい初期データも開発途中で連携し、メールで必要な条件と内容をくださいと来たのでそれも送付した。
しかし、一向に作られる気配がなかったので期間を開けて3回(3回以降は覚えてない)以上確認した。
ユーザー試験が終わったと連絡を受けた後、ふと気になって処理が作られているか確認したら
まだ作られていなかった。
その時点でリリースの2週間程度前だったことを覚えている。

ちょうど1週間前の際に確認した時も作成されていなかったので、もう一度「作らなくて大丈夫か」確認した。
その時に「当日までに作られない」ことが発覚した。
まぁ作られないのなら、初期データをつくって後で処理追加かと考えていた。

その後リリースの前日に、この初期データ作成処理これでいいか確認が来た。
その時は「当日用の初期データ作成かな」と思ったので、当日だけのデータのINSERT文ならこれで大丈夫っすよと回答した。
その後、SQLの処理で「移行パッケージコンパイルして初期データ作成するようにした」と連絡が来た。
「話が違くないか」と思ったが、ちゃんとできるか確認しないとリリースが長引く原因になるので、パッケージ処理を確認した。

案の定ちゃんと作れていなかった。そりゃそうだ。
そのパッケージ処理、開発側で作ったDBカラム追加を入れないと、ちゃんとデータ移行できないものね。
というか、テストしたのかこの人。
前にDB追加したという資料も渡したし、メールも送ったんだけど「この人ちゃんと見てないんだなー」と感じながら
こっちの追加カラム入ってないので、今のままじゃ動きませんと連絡したら、カラム追加してパッケージ追記してとのたまう。

そんな開発環境にも作らずに本番環境に直接デプロイさせられても、やってるわけないだろ
と思いながら、パッケージを修正しました。

これ普通にメンバーとして見ていたら、間違いなく叱るか注意するレベルの内容だと思うんですよね。

バックアップも残さずに、本番のリソースを置き換えた。

これはリリース参加していたメンバー全員があきれていました。
そのシステムのリリース作業は、リリース資材を適応して、warファイルを置き換えるだけの作業ですが
モジュールが足りない、もしくは間違えた場合の対策として、適応前のwarファイルをバックアップとして残す習慣がありました。

そのため、最悪間違えてしまったとしてもバックアップを戻せばよい。
そうなっていました。

しかしPMはあろうことか、バックアップもとらずに適応しました。
そして適応するファイルを間違えました。

その後「どうやって戻せばいい?」と開発メンバーに確認してきました。
僕含め開発メンバーがひどく困惑していたのを覚えています。
一人が「おかしいだろ…」と言っていましたが、その際に僕も「この人本当に大丈夫なのか」と不信感にさいなまれました。

1時間くらいかけて戻すことはできましたが、はっきり言って無駄な時間でした。
というより、業務経験が一番豊富なPMが犯すミスとは思えない内容でした😂

送った資料・メール、定例の内容・報告した内容を忘れている

どうなんだPMとして。
あなたはPMではないのか?ただのメンバーなのか??
と、10くらい年齢差があるが言いたくなるレベルである。

正直年齢による記憶の差だとしても、何らかの対策くらい立ててほしいものである。
ってか社会人なら立ててください。

4回も同じメールを送ったことがあるのを僕は忘れない。
私が報告した内容が忘れられ、なぜか苦言を示されたことも忘れない。

とどのつまり不満があるのはどこだろうか

プロジェクトに関しては以下のようなところ。
正直なところ、これ以外に不満は特にない。(人が悪いわけじゃないからね)

  • 作業場所的には別よりはマシみたいだが、上長が無能な件

最近分かったが、現場移動の可能性が出てきているので
この会社にいるべきかいないべきかの決断が迫られている気がする。

さて、どうしたものか…。