|
Latest Entries
スポンサーサイト
上記の広告は１ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
新しい記事を書く事で広告が消せます。
開発マネージメントについての議論が高まっている
■デバッグについての話題を多く見かけた
バンダイナムコの『カルドセプト』、セガの『ファンタシースターユニバース』と『ぷよぷよDS』、任天堂の『ポケモン』など、ゲームソフトの不具合が相次いでいます。そのせいか、昨年末から年頭にかけて、ゲーム開発者のブログや掲示板で、デバッグについての話題をいくつか見かけました。
ユーザーレベルの議論としては、重大なバグを出した会社を吊るし上げて集中砲火で叩く意見が圧倒的に多いものの、一方で制作サイドとしては、対岸の火事として安穏と眺めてもいられない気分なのでしょう。騒がれ、目立った事例だけが問題ではなく、たまたま騒がれなかった事例もあるはずで、リスクが高まっているという認識が、ゲーム制作者の間で共有され始めています。
単に、重大なバグを出した会社の問題という視点ではなく、ネットの普及にともない、不具合についての情報、それに対する企業の対応がまたたく間にネットを駆け巡って、炎上する時代だというリスク認識です。
同業他社の人と飲んだり、あるいはメール、チャット、その他で色々な雑談をしていても、不具合に関する話題はやはり出てきました。こういうブログをやっていると、開発スタジオの現場の方からタレコミ的、オフレコ的なメールをいただく事もあります。議論の深さはまちまちなものの、問題がそう単純ではないという認識に至ります。
わかりやすい理由に帰結できるかというと、意外と根深いものに突き当たったりします。個々の事例にフォーカスを当てすぎると、表層的な理由が目について、かえって深層の要因を見失う可能性もあります。包括的に見ていけるよう、事例の収集を淡々と行い、精神論や表面的な解決に陥らないことが必要でしょう。
■要因を探る
比較的、表層レベルの要因を箇条書きにしてみます。
少なくない企業で、品質に対してのモチベーションが低下しがちのようです。短納期化は明らかに、この傾向に拍車をかけています。何故なら、期間内で開発を終えることは評価されやすいのですが、不具合を起こさないことは評価されないからです。起きたら責任を問われますが、起きなければ何の評価もされない性質のため、相対的に優先度が下がってしまうのです。失敗を防ぐ仕事は、失敗が起こらないがゆえに評価されないというジレンマを抱えています。
また失敗事例は、企業内においてタブー視されがちです。誰だって、成功はみんなから誉められたいし、失敗は誰からも言及されたくないからです。失敗を失敗と言うと、当事者や関係者から無用の恨みを買ったり、組織内に亀裂を入れることになりかねません。そして失敗はろくに要因分析されず、腫れ物にさわるような扱いになり、結果として同じような失敗を繰り返します。
これは別にゲーム会社に限らず、一般的によく起きていることで、その反省から例えば「失敗学」などが注目を高めているわけです。企業経営において、いかに感情をこじらせずに失敗データベースを蓄積し、未然のミスを防ぐかは、優先度の高い課題になりつつあります。
■「知」の継承
また開発のノウハウ、基本知識の継承がうまくいってない事例も耳にします。と書くと、ゲーム開発者でない人間がまたぞろ「ゲームデザイン学が……」などと言い出しかねませんが、従来感性でやっていた部分を合理化しようという話ではなく、それ以前の問題なのです。
事はもっと単純かつ深刻で、「誰がやってもあんまり変わらない部分」がきちんと伝達されていないケースが多いようです。
学問的な志としては、ゲーム開発において感性や才能に依存した部分を解体し、汎用化し、プロセス化（マニュアル化）したいという欲望があるのかもしれませんが、じつは現場に最も不足しているのは、「誰がやってもあんまり変わらない部分」のプロセス化と共有化なんじゃないかと思います。
つまり学問的には、ドキュメント化しにくい部分をドキュメント化しやすくするために、理論と用語を整備しましょう、というのが第一歩になりがちなのですが、現場的に必要性が高いのは、ドキュメント化できる／しやすい部分をまずはきちんとドキュメント化しましょうよ、という事です。
■開発戦略とモチベーションの維持
ゲーム会社の存在意義
モチベーションの維持は非常に重要な課題で、ゲームのマボロシのあれれさんの記事は、ゲーム会社のマネージャー向けの、興味深い問題提起です。ゲーム業界は他業種に比べて、ユーザーの声が大きく、伝統的にユーザー志向の強い産業ですが、制作者の「作りたいもの」とユーザーの「欲しいもの」が乖離している、という指摘は説得力があります。
経営側は開発側よりも先に市場に反応しますから、開発側に「作りたくないもの」を押しつける事があり、去年表出した「脳トレクローンなんて作りたくないけど、会社が作れって言うんだよ」問題が思い出されます。開発側からは「ブームなんてすぐに終わる」「脳トレクローンなんて売れないよ」という抵抗が出てくることもありましたが、50万本出荷した『漢検DS』を筆頭にサードパーティの実用ソフトの売れ行きが堅調なため、任天堂の実用ゲームしか売れないという主張は瓦解し、経営サイドが自信を深める材料がむしろ揃いつつあります。
ややバブリーに展開してきているので、さほど長くは持たないかもしれませんが、弾けるまでの儲けられる間に儲けたいのが経営サイドの欲望でしょう。1、2年の間は、この路線の案件は増えるでしょう。
開発技術のキャッチアップにしても、「キャハ。キバっちゃっても、どうせショボグラはショボグラだろ。スクウェア以外ほしくねーよ、ぶははは」という辺りが、ユーザーサイドからの残酷な本音でしょう。開発サイドの強迫観念に報いるほどのリターンはどこにも無いのが実情でしょう。無論、スクウェアやカプコンなどは高い開発力を維持する努力に、リターンが得られます。ユーザーの使える時間が減っているなか、全体として「選別」が進んでいます。いまだに筋の悪い路線に、多大な労力が無駄に突っ込まれている感はあります。
■日本のゲーム業界は復調しているはずだが……
2006年の国内ゲーム市場は97年の記録を追い抜き、史上最高の規模に成長しました。E3縮小を受け、ゲームショウも4日間に増え、日本のゲーム業界は衰退どころか再び絶頂期を迎えつつあります。
任天堂のひとり勝ちと言われつつも、スクウェアエニックスは大幅に利益拡大し、カプコンも北米市場で大成功をおさめています。ハドソン、イマジニアなど、小回り重視で儲けている会社もあり、各社の業績は上向いていて、悪い材料は少ないです。据置ゲーム市場の縮小のあおりで、ロスが生じている企業はあるものの、来期には路線転換の効果が現れてくるはず。2003年頃の停滞期に比べれば、明るい材料が多いです。
しかしモチベーションに関連して、最近「うつ」の話を耳にする事が増えました。ボク自身はあまり縁のない（少なくとも実感のない）ものなので、身近な所でどれぐらい深刻なのかはじつは把握できてはいないのですが、ここ数ヶ月、同業他社の人たちから「うつ」についての話が出てくる事があり、なんとなく頭に残った状態で本屋に行くと、割と目立つところに「うつ」本が置かれているのを見ると、流行ってるのかなあ……などと思うのですが、サンプリング数が少なすぎて、全体の傾向としてどうなのかはちょっとわかりません。
今年一年の様子を見てみないと、何とも言えませんが。
とはいえ、好景気のほうが仕事の量は増えるから、労働負荷という点では、じつは増加傾向にあるのです。また市場の変化が急激なため、多くのゲーム開発者に考え方の転換が求められていて、大きな負荷になっている可能性はあります。数字を達成するために各企業でストレスが生じているのでしょうかね？
ある種の有能さが従来の路線への最適化によるものだとするなら、有能な人物に限って、変化への対応が遅れ、心理的なストレスも抱えこむという、嫌な事態を招いているのでしょうか？
してみると、昨年末あたりからネット上において、マネージメントについての議論、論考が増えつつあるのも、潜在的なニーズが高まっているからかもしれません。
以上、まとまりの無いトピックを飛び飛びに書きましたが、今後ぽつぽつと関連する話題を書いていこうかなと思っています。
（センシティブな話題なので、コメントの際に「管理者にだけ表示を許可する」を使っていただいても結構です。これをチェックして投稿すると、管理人のボクにしか読めませんし、ボクでも公開は不可能です。オフレコ専用機能ですね。）
バンダイナムコの『カルドセプト』、セガの『ファンタシースターユニバース』と『ぷよぷよDS』、任天堂の『ポケモン』など、ゲームソフトの不具合が相次いでいます。そのせいか、昨年末から年頭にかけて、ゲーム開発者のブログや掲示板で、デバッグについての話題をいくつか見かけました。
ユーザーレベルの議論としては、重大なバグを出した会社を吊るし上げて集中砲火で叩く意見が圧倒的に多いものの、一方で制作サイドとしては、対岸の火事として安穏と眺めてもいられない気分なのでしょう。騒がれ、目立った事例だけが問題ではなく、たまたま騒がれなかった事例もあるはずで、リスクが高まっているという認識が、ゲーム制作者の間で共有され始めています。
単に、重大なバグを出した会社の問題という視点ではなく、ネットの普及にともない、不具合についての情報、それに対する企業の対応がまたたく間にネットを駆け巡って、炎上する時代だというリスク認識です。
同業他社の人と飲んだり、あるいはメール、チャット、その他で色々な雑談をしていても、不具合に関する話題はやはり出てきました。こういうブログをやっていると、開発スタジオの現場の方からタレコミ的、オフレコ的なメールをいただく事もあります。議論の深さはまちまちなものの、問題がそう単純ではないという認識に至ります。
わかりやすい理由に帰結できるかというと、意外と根深いものに突き当たったりします。個々の事例にフォーカスを当てすぎると、表層的な理由が目について、かえって深層の要因を見失う可能性もあります。包括的に見ていけるよう、事例の収集を淡々と行い、精神論や表面的な解決に陥らないことが必要でしょう。
■要因を探る
比較的、表層レベルの要因を箇条書きにしてみます。
- 短期開発の案件が増えて、デバッグ期間も短くなった。
- 国内市場の拡大や、欧米の次世代機市場の好調を受け、仕事の発注が増えていて、管理が甘くなっている。
- 次世代機の開発において、十分な開発期間が得られなかったり、技術的についていけない部分があり、チームの人数が肥大化したことで、不具合発生の確率が上昇した。
- デバッグチームの外注化が進み、デバッグ専門の会社の仕事のクオリティにばらつきがある。
- 海外拠点の活用をふくめて、開発の分業化が進んだため。
少なくない企業で、品質に対してのモチベーションが低下しがちのようです。短納期化は明らかに、この傾向に拍車をかけています。何故なら、期間内で開発を終えることは評価されやすいのですが、不具合を起こさないことは評価されないからです。起きたら責任を問われますが、起きなければ何の評価もされない性質のため、相対的に優先度が下がってしまうのです。失敗を防ぐ仕事は、失敗が起こらないがゆえに評価されないというジレンマを抱えています。
また失敗事例は、企業内においてタブー視されがちです。誰だって、成功はみんなから誉められたいし、失敗は誰からも言及されたくないからです。失敗を失敗と言うと、当事者や関係者から無用の恨みを買ったり、組織内に亀裂を入れることになりかねません。そして失敗はろくに要因分析されず、腫れ物にさわるような扱いになり、結果として同じような失敗を繰り返します。
これは別にゲーム会社に限らず、一般的によく起きていることで、その反省から例えば「失敗学」などが注目を高めているわけです。企業経営において、いかに感情をこじらせずに失敗データベースを蓄積し、未然のミスを防ぐかは、優先度の高い課題になりつつあります。
技術の伝え方（畑村洋太郎） amazon bk1 | 失敗学のすすめ amazon |
■「知」の継承
また開発のノウハウ、基本知識の継承がうまくいってない事例も耳にします。と書くと、ゲーム開発者でない人間がまたぞろ「ゲームデザイン学が……」などと言い出しかねませんが、従来感性でやっていた部分を合理化しようという話ではなく、それ以前の問題なのです。
事はもっと単純かつ深刻で、「誰がやってもあんまり変わらない部分」がきちんと伝達されていないケースが多いようです。
- 各チームで使用するCGツールの種類がバラバラ。
- 効率的な作業法やデータの管理の方法が異なる。
- 開発用語の微妙な方言。
- プログラミングにおける注意事項や、リスク回避のコーディングが浸透していない。
- 技術情報がまるで共有化されないし、ドキュメントも無い。
- ビルド周りの環境に落差がある。
- 処理速度やメモリの最適化のノウハウがシェアできてない。
- プロジェクトのホームページおよびドキュメント管理、デバッグ管理に差がある。
- 事後反省がなされない。やっても愚痴と批判の応酬になったり、蓄積されなかったりする。
- ：
- ：
学問的な志としては、ゲーム開発において感性や才能に依存した部分を解体し、汎用化し、プロセス化（マニュアル化）したいという欲望があるのかもしれませんが、じつは現場に最も不足しているのは、「誰がやってもあんまり変わらない部分」のプロセス化と共有化なんじゃないかと思います。
つまり学問的には、ドキュメント化しにくい部分をドキュメント化しやすくするために、理論と用語を整備しましょう、というのが第一歩になりがちなのですが、現場的に必要性が高いのは、ドキュメント化できる／しやすい部分をまずはきちんとドキュメント化しましょうよ、という事です。
■開発戦略とモチベーションの維持
ゲーム会社の存在意義
モチベーションの維持は非常に重要な課題で、ゲームのマボロシのあれれさんの記事は、ゲーム会社のマネージャー向けの、興味深い問題提起です。ゲーム業界は他業種に比べて、ユーザーの声が大きく、伝統的にユーザー志向の強い産業ですが、制作者の「作りたいもの」とユーザーの「欲しいもの」が乖離している、という指摘は説得力があります。
経営側は開発側よりも先に市場に反応しますから、開発側に「作りたくないもの」を押しつける事があり、去年表出した「脳トレクローンなんて作りたくないけど、会社が作れって言うんだよ」問題が思い出されます。開発側からは「ブームなんてすぐに終わる」「脳トレクローンなんて売れないよ」という抵抗が出てくることもありましたが、50万本出荷した『漢検DS』を筆頭にサードパーティの実用ソフトの売れ行きが堅調なため、任天堂の実用ゲームしか売れないという主張は瓦解し、経営サイドが自信を深める材料がむしろ揃いつつあります。
ややバブリーに展開してきているので、さほど長くは持たないかもしれませんが、弾けるまでの儲けられる間に儲けたいのが経営サイドの欲望でしょう。1、2年の間は、この路線の案件は増えるでしょう。
開発技術のキャッチアップにしても、「キャハ。キバっちゃっても、どうせショボグラはショボグラだろ。スクウェア以外ほしくねーよ、ぶははは」という辺りが、ユーザーサイドからの残酷な本音でしょう。開発サイドの強迫観念に報いるほどのリターンはどこにも無いのが実情でしょう。無論、スクウェアやカプコンなどは高い開発力を維持する努力に、リターンが得られます。ユーザーの使える時間が減っているなか、全体として「選別」が進んでいます。いまだに筋の悪い路線に、多大な労力が無駄に突っ込まれている感はあります。
■日本のゲーム業界は復調しているはずだが……
2006年の国内ゲーム市場は97年の記録を追い抜き、史上最高の規模に成長しました。E3縮小を受け、ゲームショウも4日間に増え、日本のゲーム業界は衰退どころか再び絶頂期を迎えつつあります。
任天堂のひとり勝ちと言われつつも、スクウェアエニックスは大幅に利益拡大し、カプコンも北米市場で大成功をおさめています。ハドソン、イマジニアなど、小回り重視で儲けている会社もあり、各社の業績は上向いていて、悪い材料は少ないです。据置ゲーム市場の縮小のあおりで、ロスが生じている企業はあるものの、来期には路線転換の効果が現れてくるはず。2003年頃の停滞期に比べれば、明るい材料が多いです。
しかしモチベーションに関連して、最近「うつ」の話を耳にする事が増えました。ボク自身はあまり縁のない（少なくとも実感のない）ものなので、身近な所でどれぐらい深刻なのかはじつは把握できてはいないのですが、ここ数ヶ月、同業他社の人たちから「うつ」についての話が出てくる事があり、なんとなく頭に残った状態で本屋に行くと、割と目立つところに「うつ」本が置かれているのを見ると、流行ってるのかなあ……などと思うのですが、サンプリング数が少なすぎて、全体の傾向としてどうなのかはちょっとわかりません。
今年一年の様子を見てみないと、何とも言えませんが。
とはいえ、好景気のほうが仕事の量は増えるから、労働負荷という点では、じつは増加傾向にあるのです。また市場の変化が急激なため、多くのゲーム開発者に考え方の転換が求められていて、大きな負荷になっている可能性はあります。数字を達成するために各企業でストレスが生じているのでしょうかね？
ある種の有能さが従来の路線への最適化によるものだとするなら、有能な人物に限って、変化への対応が遅れ、心理的なストレスも抱えこむという、嫌な事態を招いているのでしょうか？
してみると、昨年末あたりからネット上において、マネージメントについての議論、論考が増えつつあるのも、潜在的なニーズが高まっているからかもしれません。
以上、まとまりの無いトピックを飛び飛びに書きましたが、今後ぽつぽつと関連する話題を書いていこうかなと思っています。
（センシティブな話題なので、コメントの際に「管理者にだけ表示を許可する」を使っていただいても結構です。これをチェックして投稿すると、管理人のボクにしか読めませんし、ボクでも公開は不可能です。オフレコ専用機能ですね。）
スポンサーサイト
コメント
問題はマネジメントにあらず
他業種の方のご意見、参考になります。
うーん……ただ、おそらくIT業界の中でご苦労をされているせいか、ちょっとその視点で物を見すぎているような気がしました。少し落ち着かれては。ネットを見ると、IT業界の方は、色々と不満を抱えている方が多いようですね。ただ、失礼ながら、少し熱くなりやすく、視野もちょっと狭まる傾向があるように感じています。
さて、今回のエントリーは現場の人間どうしの話の中で、「こういうことは必要だよね」として出てきたものをボクなりにまとめ上げたものです。あのにますさんがおっしゃる「技術力」を成長させるための手段でもあります。教育や士気の問題にふれているのも、そのせいです。また、プログラマーに限定した話ではなく、デザイナー、サウンド、ディレクター全てをひっくるめています。
阪神淡路大震災の例はわかりやすいのですが、えーっと、どうも話がずれているようです。マネージメントという言葉に惑わされず、中身をもう一度読んでみていただけると、より良い議論ができると思います。別に役立たずのマネージャーを増やそうという話をしているわけではありませんよ。
> それだったら数機のヘリコプターと消防車の100台も増援で送り、自衛隊員を出動させた方が遙かに効果的でしょう。
そういう判断も、またマネージメントだと思います。あのにますさんがイメージされている、IT業界独特の「まねじめんと」にこだわらず、広い意味で捉えていただければ幸いです。
うーん……ただ、おそらくIT業界の中でご苦労をされているせいか、ちょっとその視点で物を見すぎているような気がしました。少し落ち着かれては。ネットを見ると、IT業界の方は、色々と不満を抱えている方が多いようですね。ただ、失礼ながら、少し熱くなりやすく、視野もちょっと狭まる傾向があるように感じています。
さて、今回のエントリーは現場の人間どうしの話の中で、「こういうことは必要だよね」として出てきたものをボクなりにまとめ上げたものです。あのにますさんがおっしゃる「技術力」を成長させるための手段でもあります。教育や士気の問題にふれているのも、そのせいです。また、プログラマーに限定した話ではなく、デザイナー、サウンド、ディレクター全てをひっくるめています。
阪神淡路大震災の例はわかりやすいのですが、えーっと、どうも話がずれているようです。マネージメントという言葉に惑わされず、中身をもう一度読んでみていただけると、より良い議論ができると思います。別に役立たずのマネージャーを増やそうという話をしているわけではありませんよ。
> それだったら数機のヘリコプターと消防車の100台も増援で送り、自衛隊員を出動させた方が遙かに効果的でしょう。
そういう判断も、またマネージメントだと思います。あのにますさんがイメージされている、IT業界独特の「まねじめんと」にこだわらず、広い意味で捉えていただければ幸いです。
かなり同感
かなり同感できるエントリで考えさせられました。
ただし、次世代機云々というよりも、ボリュームの増大や仕様の複雑化が原因の一つであると、個人的には感じています。ちょっと頭の中でまとまってないので、詳細は述べられませんが(機会があれば自分のblogででも)
> あのにますさん
そうですかね？あなたがダメな上司に振り回されているのは分かりますが……。
阪神大震災の例はむしろ反例だと思います。あの震災であれだけ被害が拡大したのは、指揮系統が悪かったからです。自衛隊は災害発生からすぐに出動準備を整えていましたが、総理大臣からの出動命令が無いために待機させられて悔しい思いをしたそうです。いくらヘリコプターやり消防車があっても、あの状況はさほど変わらなかったでしょう。
もし災害時に運営方法がしっかり定められていたなら(被災地の要請や、総理大臣の命令が無くても出動できるとか)、多くの人命が救われていたのは間違いありません。
技術力はもちろん重要ですが、開発者の人員が増えている以上、全ての人員の技術レベルを高く維持するのは不可能です。上層部の無能(マネジメントのまずさ)を現場の技術力でカバーするのは、よく見られる光景とはいえ、根本的な解決ではないと思います。
ただし、次世代機云々というよりも、ボリュームの増大や仕様の複雑化が原因の一つであると、個人的には感じています。ちょっと頭の中でまとまってないので、詳細は述べられませんが(機会があれば自分のblogででも)
> あのにますさん
そうですかね？あなたがダメな上司に振り回されているのは分かりますが……。
阪神大震災の例はむしろ反例だと思います。あの震災であれだけ被害が拡大したのは、指揮系統が悪かったからです。自衛隊は災害発生からすぐに出動準備を整えていましたが、総理大臣からの出動命令が無いために待機させられて悔しい思いをしたそうです。いくらヘリコプターやり消防車があっても、あの状況はさほど変わらなかったでしょう。
もし災害時に運営方法がしっかり定められていたなら(被災地の要請や、総理大臣の命令が無くても出動できるとか)、多くの人命が救われていたのは間違いありません。
技術力はもちろん重要ですが、開発者の人員が増えている以上、全ての人員の技術レベルを高く維持するのは不可能です。上層部の無能(マネジメントのまずさ)を現場の技術力でカバーするのは、よく見られる光景とはいえ、根本的な解決ではないと思います。
あほらし
>あの震災であれだけ被害が拡大したのは、指揮系統が悪かったからです。
というのが管理職の発想の限界。
たしかに当時の総理大臣が大馬鹿物で無能以外の何物でもなかったのも事実ですけどね。あそこまで馬鹿じゃなければ、あの日の朝7時には出動命令を出せたでしょう。でもそれだけでは不十分。
>開発者の人員が増えている以上、全ての人員の技術レベルを高く維持するのは不可能です。
うん。これも良く聞く言い訳ですね。
全員のレベルを高く維持するのは難しい。「平均値」が下がるのは仕方ないかもしれない。でも問題なのは平均値ではなく、質、量ともに低すぎるということなんですよ。
>広い意味で捉えていただければ幸いです。
だったら最初から「まねじめんと」などという言葉で逃げないように。こういう言い訳をする管理職は多いけど。
いくらでも拡大解釈が許されるというのなら、最後は「現場の独断で動くのもマネジメントなんだ」で誤魔化すおつもりか？
というのが管理職の発想の限界。
たしかに当時の総理大臣が大馬鹿物で無能以外の何物でもなかったのも事実ですけどね。あそこまで馬鹿じゃなければ、あの日の朝7時には出動命令を出せたでしょう。でもそれだけでは不十分。
>開発者の人員が増えている以上、全ての人員の技術レベルを高く維持するのは不可能です。
うん。これも良く聞く言い訳ですね。
全員のレベルを高く維持するのは難しい。「平均値」が下がるのは仕方ないかもしれない。でも問題なのは平均値ではなく、質、量ともに低すぎるということなんですよ。
>広い意味で捉えていただければ幸いです。
だったら最初から「まねじめんと」などという言葉で逃げないように。こういう言い訳をする管理職は多いけど。
いくらでも拡大解釈が許されるというのなら、最後は「現場の独断で動くのもマネジメントなんだ」で誤魔化すおつもりか？
＞あのにますさん
率直にいって今あなたがやっているのは、自分のストレスや上司への不満を、形を変えてぶつけているだけではないでしょうか？ 繰り返しますが、もう一度だけ書きます。冷静に議論を読み返してください。ここはIT業界愚痴掲示板ではありません。チラシの裏でもありません（苦笑
> 最初から「まねじめんと」などという言葉で逃げないように。こういう言い訳をする管理職は多いけど。
あなたの言う「マネージメント」とボクのかいている「マネージメント」の意味がずれています、という事を指摘しただけなのですが。
それと、ボクはあなたの管理職でも何でもありません（苦笑
挑みかかるような調子で、コメント投稿する態度は、いかがなものでしょうか。正直ストレスのはけ口にされたくはありません。
あなたが自分の怒りをぶつけられる対象を「マネージメント」と名づけていることは理解できましたが、ボクやtablogさんが述べているマネージメントがそういう意味合いではないことは、文脈から読み取れるのではないでしょうか？
「マネージメント」＝マネージャーの数や予算や権限を増やす事だとは思いませんし、仮にIT業界であなたが常日頃接しているマネージメントがそういうものだとしても、ボクやtablogさんが論じているものはまったく別物です。
再度書きますが、
>さて、今回のエントリーは現場の人間どうしの話の中で、「こういうことは必要だよね」として出てきたものをボクなりにまとめ上げたものです。
あなたの仮想敵か何かであるところの「管理職」の作った、訳のわからないプランの話をしているのではありません。
以後、あなたがIT業界の愚痴を叩きつけるような態度で、投稿を続けられるなら、掲載不許可をふくめた対応をとらせていただきます。
（まあ、このような、「自分は決して悪くないし、マネージメントも知ったことじゃない、無能ばっかりだ」というような、環境に当り散らす事でしか自分を保てない人は、残念ながらどこの世界にもいるんですよね。こういう人物の扱いをどうするか、というのは、なかなか難しい問題です。ずっと不満を抱えて、何年も経つと、人間は寂しい見方に囚われてしまいがちです。こうなる前に不満を見つけてあげて、対処していこうとするのがベターでしょう。まあ、それで完全に防げるわけでもないのですが。図らずも、そういう良い実例になっていただけた、と思います。）
率直にいって今あなたがやっているのは、自分のストレスや上司への不満を、形を変えてぶつけているだけではないでしょうか？ 繰り返しますが、もう一度だけ書きます。冷静に議論を読み返してください。ここはIT業界愚痴掲示板ではありません。チラシの裏でもありません（苦笑
> 最初から「まねじめんと」などという言葉で逃げないように。こういう言い訳をする管理職は多いけど。
あなたの言う「マネージメント」とボクのかいている「マネージメント」の意味がずれています、という事を指摘しただけなのですが。
それと、ボクはあなたの管理職でも何でもありません（苦笑
挑みかかるような調子で、コメント投稿する態度は、いかがなものでしょうか。正直ストレスのはけ口にされたくはありません。
あなたが自分の怒りをぶつけられる対象を「マネージメント」と名づけていることは理解できましたが、ボクやtablogさんが述べているマネージメントがそういう意味合いではないことは、文脈から読み取れるのではないでしょうか？
「マネージメント」＝マネージャーの数や予算や権限を増やす事だとは思いませんし、仮にIT業界であなたが常日頃接しているマネージメントがそういうものだとしても、ボクやtablogさんが論じているものはまったく別物です。
再度書きますが、
>さて、今回のエントリーは現場の人間どうしの話の中で、「こういうことは必要だよね」として出てきたものをボクなりにまとめ上げたものです。
あなたの仮想敵か何かであるところの「管理職」の作った、訳のわからないプランの話をしているのではありません。
以後、あなたがIT業界の愚痴を叩きつけるような態度で、投稿を続けられるなら、掲載不許可をふくめた対応をとらせていただきます。
（まあ、このような、「自分は決して悪くないし、マネージメントも知ったことじゃない、無能ばっかりだ」というような、環境に当り散らす事でしか自分を保てない人は、残念ながらどこの世界にもいるんですよね。こういう人物の扱いをどうするか、というのは、なかなか難しい問題です。ずっと不満を抱えて、何年も経つと、人間は寂しい見方に囚われてしまいがちです。こうなる前に不満を見つけてあげて、対処していこうとするのがベターでしょう。まあ、それで完全に防げるわけでもないのですが。図らずも、そういう良い実例になっていただけた、と思います。）
あそこでも管理職は「まねじめんと」でなんとかしたいと考えていました。彼らの手にはそれしか残されていないからです。「まねじめんと」でなんとかできない限り、彼らは自分たちが役立たずの金食い虫であることを認めることになります。だから彼らは「まねじめんと」に拘り続けるのです。しかし、それは貴重な時間と資金を浪費し、現場はさらに疲弊しました。
阪神淡路大震災では多くの人命が失われました。同時多発的に発生した火災で、生きたまま焼かれた人もいます。さて彼らを救うために「官邸に災害対策本部を迅速に設置し、総理大臣を中心に閣僚を大勢配置すべきだ」という人がいるでしょうか。「閣僚が100人じゃ不足だ。300人に増員しよう」などというでしょうか。それだったら数機のヘリコプターと消防車の100台も増援で送り、自衛隊員を出動させた方が遙かに効果的でしょう。
管理職のとなえる「マネジメント」など、現場技術者からすると虚しく響くだけです。