gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

「炎上案件」を思い返しつつ分析してみる

別に「つるし上げ」が目的ではないので、最低限「当事者以外には」対象がわからん程度にぼかします。
で、「おいちゃんにしかわからん」程度の隠語を交えつつ、とはいえ読者の皆々様に「参考になる」程度に。
…って思ったのですが思った以上にしゃれにならん内容なので、結果だけ(苦笑


関わってきて「炎上してたなぁ」って案件を思い出しつつ要素をリストアップすると、こんな感じになりますた。
括弧の中の数字は「1案件あたりこの要素が当てはまったら+1」でカウントした数字です。
「プロジェクトの規模とかみんな違う」から、まぁ、参考程度に。

PM能力不足

(8)そもそも、マネジメントしていない
(5)プロジェクトスコープを管理していない
(3)「仕様変更」を野放しにしすぎている
(1)コミュニケーションデザインが出来ていない
(1)「管理のための管理」をしてしまってる
(1)当初から無理なスケジュール(見積もり(時のヒアリング/想定)不足)

設計不足

(5)設計が不足している事をそもそも認識できていない
(1)「設計は出来ていないけどとりあえず作る」など、設計をおざなりにしている

技術不足

(6)「メンテナンサブル」「サステナビリティ」なコードが書けていない(クラス設計がむごい / そもそもクラスがない)
(3)セキュリティの知識が皆無
(2)そもそも、Web(アプリケーション)の知識が皆無


ざっくり見ると
(8)そもそも、マネジメントしていない
(6)「メンテナンサブル」「サステナビリティ」なコードが書けていない(クラス設計がむごい / そもそもクラスがない)
(5)プロジェクトスコープを管理していない
(5)設計が不足している事をそもそも認識できていない
この辺。
じゃぁどう鎮火してきたかを思い返してみると………


(8)そもそも、マネジメントしていない
「現職マネージャを締め上げて」からstart。
中途半端な口を開いたら「どんな目にあうか」を、体でご理解いただく。
降格はさせなくてもいいんだけど「現場には介入できない」ようにしておく。


(6)「メンテナンサブル」「サステナビリティ」なコードが書けていない(クラス設計がむごい / そもそもクラスがない)
「なぜンなコードを書いてしまったのか」という状況にもよるのですが。
丁寧にいくのであれば
・まずい理由の説明
・教育しつつリファクタ計画&リファクタ
別の角度から丁重にいくのであれば
・まずい理由を説明してのつるし上げ
・締め上げきった後、コーディング規約の制定とリファクタ。場合によっては「有能なメンツ」に首をすげ替えてからのリファクタ


(5)プロジェクトスコープを管理していない
契約形態にもよるんですよねぇこれの場合。
請負なら完全アウトだけど(「変更するなら金をくれ」)、準委任でも「とはいえ締め切り日が確定してましてね」って時はやはりアウト。
まず「可能な範囲ってぇもんがある」事を骨の髄までご理解いただいた後で、機能要望の取捨選択をしていただきます。
ただ、お客様が変な学習してて「後追加、出来ないんでしょ?」って思ってるケースがあるので「それは下手くそが設計してコード書いた場合。綺麗に書けば、ちゃんと後で修正も追加もできるから、そこは安心してくださいませ」って話を落ち着いて説明して、安心していただきます。


(5)設計が不足している事をそもそも認識できていない
質問攻めをかけて、理解していただく。


(3)「仕様変更」を野放しにしすぎている
「プロジェクトスコープを管理していない」と大体一緒。


(3)セキュリティの知識が皆無
「「メンテナンサブル」「サステナビリティ」なコードが書けていない(クラス設計がむごい / そもそもクラスがない)」と大体一緒。


(2)そもそも、Web(アプリケーション)の知識が皆無
状況にもよるが…「教育コストをかけてよい」状況であれば教育。
でなきゃ、このレベルだと流石に「切る」を視野に。


(1)コミュニケーションデザインが出来ていない
面倒なんでこっちでデザインする。
ただ、ほぼ確実に「そもそも、マネジメントしていない」がセット販売されていると考えられるので、以降は大体一緒。


(1)「管理のための管理」をしてしまってる
まずは「何のために管理をしているのか」とその背景を確認する。
「恐怖からくる管理」であれば、対話と説得で方向性を見出す。

コストの話をして「最適なところ」への落としどころを対話する。


(1)当初から無理なスケジュール(見積もり(時のヒアリング/想定)不足)
「なぜ」そうなったのか次第。
どこを調整するか? については「プロジェクト:4つの変数 http://d.hatena.ne.jp/gallu/20091123/p1 」参照。


(1)「設計は出来ていないけどとりあえず作る」など、設計をおざなりにしている
実例が出るまでは説得しても理解してくれないんですよねぇ…
やってませんが、恐らく「実際に無駄が発生してから"ほら無駄だよねぇ"ってところで締め上げる」ってあたりでしょうか?


さて。
とりあえず「第一陣の考察」完了。
ちょいと、もう少し色々、考察を深めたり分解したり融合したりしながら、炎上案件ネタ、ちょいと筆を進めていきたいかなぁ、と思ってます。