なぜ炎上プロジェクトが生まれるのか(仮説と対策案)
- yukio_saitoh
- 6436
- 0
- 1
- 3
カスコードでもクズコードでも、成果物としてアウトプットするのは違いない。アウトプットに対してカスクズボケと批評され成長していく。 アウトプット出来るのだけどやらないと仰る方で、具体的な助言をなさらない方へ。それで後輩や部下を持ったときに、どうするの?(さぁ、コード書こうぜ!
2014-10-13 01:23:31今期 PBL で、あるテーマに自己挑戦している。まだ成果はないので詳しくは書けないが、「ブラック企業の炎上プロジェクトあるある」をどうすれば被害を極小化できるのか、ということ。属人化投入は必要だけども恒常化しないように。失敗することを恐れず、文書化(標準化)を徹底的に活動中。
2014-10-13 01:26:56炎上プロジェクトはブラック企業に限らない、ホワイト企業、超優良企業でも起こり得る。それは何故だろうか?当事者意識がないと片付けるのではなく、仮説として「学習」「知識(使えること)」「管理」「チーム目標」「個人目標」に区別検証。
2014-10-13 01:32:46システム設計を難しいと捉える方がいれば、システム全体ではなく機能ベースに分解してみようよ。複数の機能が集まったものがシステムだから。そこに、機能要求(ソフトを使うもの)、非機能要求(人間がなんとかするもの)に分けて、サービスを提供する以前に、どんなロジックなのか考えよう。
2014-10-13 03:26:16システム開発は料理と同じで、事前に設計がある。闇鍋であっても、適切なプロセスが展開されている。さすがに、ゴム靴を切った奴とかはアカン鍋やけどな。しかし、そのゴム靴を「これは歯ごたえが豚の耳に似ているから」といって出してしまうかも知れないが、それを防ぐのが要件レビュー。
2014-10-13 03:28:15短期間の開発プロジェクトには、必要なものは設計を理解できること。設計には、何をどう実現するのかが記述されている。もしも、モヤっとしていれば、それ設計でも企画でもなく、ただの妄想。妄想から創造へ遷移するには、学習しかない。あるいは一人開発デプロイ。
2014-10-13 03:30:32マーケティング型の企画で、システム開発を推し進めたいならば、分業するしかない。これは、注文型紳士服の仕立と同じ。ただオーダーするだけではなくコストに対して責任を持ってもらう。料理で言えば、オーダー料理。細かく注文すればするほど、コストに跳ね返る。
2014-10-13 03:32:36分業の良いところは、それぞれ餅屋が最大のパフォーマンスを発揮できる。しかし、それには、利害関係調整(折衝)を行えるPMの存在が必要不可欠。PMだけに押し付けるのではなく、メンバーがPMを支え合うこと。健全なプロジェクト活動と発展していくことが、品質、コストにも響いてくる。
2014-10-13 03:33:55指示を出すだけのPMは炎上を招く。これは言わずもがな。また、PM経験が浅くても、それは本質問題ではない。何のための Proj. であるのかを考え、相談し、行動すること。炎上には反発も包含される。コストには金銭のみならず、メンバの健康状態も。結局は「ひと」なんだけど。
2014-10-13 03:38:17学生だから、あるいは新人だから、といって許されるミスと、許されない約束がある。Proj. の場合はミスはPMの責任へ押しつけがちだが、それは違う。メンバ全員が考え行動を変えなければならない。約束(契約)がある場合は、もっと深刻だ。納期と品質は遵守しなければ、信用問題に関わる。
2014-10-13 03:41:16ミスの判断には基準がある。その基準が曖昧なのは最悪。だから炎上する。また是正するための基準を設けることは難しいだろうが、それでも、担当PMは自身の性格やチームの特徴(特性)を発揮できるように、早期に考えたいものだ。既に Proj. が進行している場合は・・・
2014-10-13 03:43:12既にProj. が進行している場合の、活動是正の判断は予実管理を行えていない領域を探す。確実に「ヌケモレ」が包含されていることが多い。気付いていたが、気付かぬフリをしていると、それはトリアージの色を悪化させるのと何ら変わらない。
2014-10-13 03:44:43Proj. メンバーは選べない。これは、当たり前と思って間違いない。だから、やらないという選択肢はそこには用意されていない。やらない=やりたくない、ならば、さようなら。そうならないように、どんな貢献があるのか、理想像でもいい。それをアウトプットしてみよう。
2014-10-13 03:46:03人間だもの、気に喰わない相手がいる。それでもタスクは完了せねばならない。気に喰わない、だから、そこに相手を認めるという行為が必要となる。もしも、気に喰わない相手に押し付けようぜ!あるいは、真面目がダサい!なんて考えがあるなら、今すぐトイレに流して来い!
2014-10-13 03:47:46プライドで飯が喰える、俺は天才だ、俺が言った通りの社会(時代)になっただろという達観視をお持ちの方は、立ち飲み屋でお願いいたします。与太話で Proj. が進んだという事例は耳にしたことはありません。尊敬に値する師からの言葉であれば、与太話ではなくご指導になる不思議はあるw
2014-10-13 03:49:58人間は完全な生き物ではないから、一人では生きていけないから、Proj. はとても有難い活動の場です。一人ではできない、だから相談。相談のあとに報告があるとなお良い。間違っても報告・連絡・相談を誤用(乱用)しなければいい。また、Proj. はチーム活動でもある。
2014-10-13 03:53:01Proj. はチーム活動。これがライブ演奏するものなら、ベース、ドラム、ギターにボーカル。どれか一つでも欠けると演奏を楽しめますか?お客ではなく、演奏する自分たちがです。お客ありきの演奏の前に、まずは自分たちが楽しめるか。嫌なメンバがいても、楽しめる要素はどこかにある。
2014-10-13 03:55:23体調も大きな影響を及ぼすので、悩み事、不安な事があるなら、周囲へ相談すればいい。そのための社会です。たまには休息しましょう。休息のあとにはリカバーしましょう。きっと、できますよ。俺は完璧ではないが、そうやって一つずつ、リアライズしてきた。アホの俺ができるもん。お前らもできるって。
2014-10-13 03:58:04書き漏れたが、PDCA を回すと仰られる方は、PM 経験が乏しいのかと思う。どこで標準化するんだろうって。 PDCA → S( Standarrd) DCA → PDCA ・・・ になっていくのが理想像。
2014-10-13 04:27:57PMBOK はすべてではない。考え方の知識体系としては纏まっている。しかし、そこには謎な バグ対応をどこから着手すればいいのか、書いた本人も読めないほどの内部コールだらけのクズコードを解き明かすクエストには対処できない。
2014-10-13 04:29:56俺の知人で何人かは、コードを書いたことがないが、めっちゃメジャー企業でシステムPMで成功している方々がいる。何故彼らは、対応できるのだろうか。それは経験の前に学習したからであろう。経験者優遇の言葉の背景にあるものはなんだろうか。職業倫理になるが、よく考えてほしい。>誰となく
2014-10-13 04:31:49良い機会だから、ハッキリ書いておく。 togetter のおススメ商品欄を書き換え横取りするクズに対して。漁夫の利、そんなものは不要だ。まったく関係のない商品紹介をすることは、自分自身の行動がクズであることを証明している。今すぐ、そういうアホでクズ行為はトイレへ捨ててこい、クソだ
2014-10-13 17:01:21クズにはクズであることを直面化させないとダメだ。本人は気付いていないからだ。自分は特定されっこないだろうとタカを括るのもアホだ。amazon へアソシエイトコードを通報しといた。丁寧な英語でな。
2014-10-13 17:05:04