背景
アプリケーション開発に注力するための工夫をシェアしよう!
ってのをみて思ったのが・・
同僚が関わってる案件・・明らかに燃えそうだから、なんか助言できないか考えてみるか?
ってことで、思考してみた記録
はじめに
通常なら・・以下のような、開発自体の効率をよくする方向性を考えるべきだけど・・
- 優先順位の明確化:やるべきことをリストアップし、優先順位をつける。
- 時間管理:ポモドーロテクニックやタイムボクシングなどの時間管理方法を活用する。
- ツールの活用:効率的な開発環境を整えるためのツールやプラットフォームを導入する。
- コミュニケーションの効率化:チャットツールやドキュメント管理ツールを活用して、情報共有をスムーズに行う。
- 自動化:CI/CDパイプラインを構築して、手作業を減らす。
今回の案件は、そもそも開発に集中出来るような環境ではないという状況
問題点はなにか?
聞こえてきただけで・・
- 見積もった人が既にいない
- 見積もった内容と既に違っている
- 見積の前提すら違う
- 見積の根拠すら決まってない
- ベースがあるといってたのに無い
- ソースがまともに管理されてない
- 構成管理ツールを使ったことない状態だった?
- 納期が削られた
- 工数も削られた
- ハードが遅れてる(組み込み系ソフト)
- 既に元請けは逃げる体制確立済み
- 元請けは、同じ会社の別部署
- 会社としては逃げられない案件(ハードのせい)
いや、もう救いようないじゃん?という世界
今どきこんな開発有るの?って思ったんですが、あるみたいですよ
ではどうするか?
-
記録をきちんと残す。Teams 会議はすべて録画する。
- プロジェクトの問題点を明確にし、どの部署が責任を持っている、持っていたのかを記録に残し、将来的起こり得る水掛け論を予防する。こうすることで、多くは最初に請けた部署の問題であり、それらの火消しをしたという点で逆に評価されやすくなる・・はず?
-
上位層を巻き込む
- 赤字になること前提で支援に入っていることを評価してもらう必要があることと、他部署との力関係で損害だけ押し付けられることを防ぐことが大切。問題のあるのが部署なのか一部の人なのかを精査して、再発しないように上申することも。
-
可能な限り周りもサポート
- 会社として逃げられない以上、文句言っててもしょうがないので、どうやりきるか?も考える必要はある。やりたくないけど
- 会社として逃げられない以上、文句言っててもしょうがないので、どうやりきるか?も考える必要はある。やりたくないけど
-
内部通報
- 聞くところによると、これが初めてではないし、結構上の人も関わってるらしいので、本社マターにしちゃう。これこそパワハラの見本なんじゃないですかね
PMBOK でのリスク管理、うちでもPM研修とかあって、勉強させてるはずなんですけどね。
- リスクの特定:プロジェクトに潜むリスクを洗い出す。
- リスクの評価:リスクの影響度と発生確率を評価し、優先順位を決める。
- リスク対応計画の策定:リスクを回避、転嫁、軽減、受容するための計画を立てる。
- リスクの監視とコントロール:リスク対応計画を実行し、リスクの状況を継続的に監視する。
結論
システムで防ごうよ!って思うけれど、運用するのは人です。
人は、権力を持ち出すと、ついつい我が儘になりがちです。
セキュリティでも政治でも、権力集中しちゃダメですね。
なぜこれが結論か?
だって、こんな案件請けなければいいじゃんって思うでしょ?でも、ぶっちゃけ上位層の意向ですから、根治療法・・はねぇ!?
記載内容は架空の話であり、必ずしも所属組織の事実を暗示するものではありません。って言えたらいいね