冷たい方程式（15） もしプロジェクトマネージャが手当たり次第にマネジメント本を読んだら
次の朝、出社したあたしは、自分の席の後ろに、昨日まではなかった物体を発見して少し驚いた。
「なんじゃこりゃ？」
それは新品のホワイトボードだった。幅120センチぐらいでキャスター付き。会議室などに置いてあるようなやつだ。なぜかマーカーやイレーザーは付いていない。
「ねえ、これは何？」
ムツミさんに聞いてみたが、首を傾げるだけだった。
「昨日の夕方、サオリさんが研修に行っている間に、搬入されてきたんです」
「ふーん、誰が注文したんだろ」
「渕上さんですよ」亀井くんが答えた。「受領印を押していましたから」
渕上マネージャは、いつもどおり8時59分に出社してきた。あたしが真新しいホワイトボードのことを聞こうと思ったとき、渕上マネージャに機先を制された。
「今日から、タスク管理をより厳密に行うことにした」単なる決定事項を告げるように、渕上マネージャは淡々と話した。「それはタスクボードだ。亀井くん、そこの模造紙を1枚貼ってくれ」
亀井君は不審そうな顔をしながらも、言われたとおりに、足元に丸めて置いてあった模造紙を広げると、ボードの上にメンディングテープで貼り付けた。
模造紙には、すでに文字と線が印刷されていた。こんな大きな紙に印刷できるプリンタは、このフロアにはないから、設計部にある古いプロッタか、MAXARTでも使ったのだろう。
「タスクボードでしょうか？」ムツミさんが、あたしにだけに聞こえるぐらいの小声で聞いた。
あたしはうなずいて同意した。あたしたち3人分のレーンが、それぞれ用意されているということは、ここにタスクカードが貼られるのだろう。
「よろしい」
はたして渕上マネージャは、手に持っていたA4版8面のラベルシールから、長方形のシールをはがしては、ペタペタと貼り付け始めた。
こちらも、すでに何かが印刷されている。あたしは日比野レーンに貼られている1枚に顔を近づけた。
よく見ると、それはシールではなくポストイットだった。エーワンのポストイットラベルシールだ。
「これから君たちには、このタスクに基づいて作業をしてもらうことになる」シールを貼り終えた渕上マネージャが説明した。「1枚が1つのタスクとなる。君たちが、これからやるべき作業、または現在、進行中の作業が印刷してある」
あたしは、自分に割り当てられたタスクをざっと眺めた。渕上マネージャの言うとおり、あたしの担当の作業が、かなり細かく記入されている。
他のレーンを見てみると、あたしと亀井くんに比べて、ムツミさんのタスクの数が圧倒的に多い。これはホライゾンシステム社内で実装しているプログラマさんたちを考慮に入れているのだろう。
「君たちは、自分のレーンのタスクを上からこなしていく。その手順はこうだ」
渕上マネージャは、手元に残してあったシールに何か書き込み、それを模造紙の隅の方に貼った。「テスト」と書いてある。
「亀井くん、そのタスクをはがしてくれ」
亀井くんは、あたしたちと顔を見合わせてから、言われるままにシールをはがした。指にくっつけて、ぶらぶらさせている。
「開始に今日の日時を書く。時間は10分単位だ」
開始日時 10/21 9:20
「次に、完了予定に、そのタスクの完了見込みの日時を書く」
完了予定日時 10/22 13:00
「書いたら、私に渡す」
亀井くんは渕上マネージャに、シールを渡した。渕上マネージャは、ちょっと眺めて、検印欄にデータ印をポンと押した。
「私が承認したら検印を押す。このとき、完了予定が不適当だと判断したら、そこで修正する。検印をもらったら、タスクボードに戻したまえ」
シールが、また模造紙に戻された。
「戻したら作業を行う」渕上マネージャは説明を続けた。「タスクが完了したら、はがして、私に申告に来ること。私が内容をチェックし、完了と判断したら、完了日時と完了印を入れる。それでタスクが完了と見なす。完了したタスクはボードに戻し、次のタスクに移る。後はこの繰り返しだ」
思わずうめきそうになった。
――めんどうだなあ
「片寄さんは、自社のエンジニアに担当される分についても、同じ手順を踏むこと」
「あの、他の人とタスクを交換したりしていいんでしょうか」あたしは聞いた。「あるいは、2人で1つのタスクをやるとか」
渕上マネージャの首が横に振られた。
「ダメだ。相談などは構わないが、タスクの完了責任は、担当者だけが負うものとする。タスクの交換も不可だ。この割り振りは私が決めたものだ。勝手に変更することは許さない」
タスクボードで見える化するのはいいことだと思うけど、これじゃあ単にプロジェクト管理のために余計な手間が増えただけでしかない。
「また、タスクにない作業を行うことも不可だ。もし、新しい作業が発生したら、私に申告したまえ。タスクとして登録する」
「完了見込みに間に合わなかったらどうなるんですか」亀井くんが聞いた。
「理由を聞いた後で、新たに遅延タスクとして追加する」渕上マネージャは告げた。「それもマネジメントの一環だ」
それなら、7日とか10日とか、余裕たっぷりに完了予定を書けばいい、と思ったが、検印をもらうときに修正すると言っていたことを思い出した。どうせ渕上マネージャがギリギリまで絞り込むに決まっている。
「あの、これ、何かの役に立つんでしょうか？」
あたしは思わず聞いてしまった。渕上マネージャは、あたしの無知を哀れむような顔になった。
「正確なマネジメントを行うためだ。君たちは、どうも、行き当たりばったりに、目先の作業をこなしているだけのように見える。タスク管理も何もあったものではない。そんなやり方では、このシステムの品質に影響が出る。必ず出る」
ムツミさんも亀井くんも、あからさまな反感こそ表していないものの、ややムッとした表情で聞いていた。2人の視線が、時折、ちらちらとあたしに向けられている。あたしはテレパシー能力を持っていないけど、「何とかしてください」と言っているのは痛いほどわかった。
もちろん、あたしの気分も爽快さとは対極にあった。
渕上マネージャが無能だったり、単なる威張りたがりだったりしたら、あたしも自分の意見を主張したかもしれない。ところが、渕上マネージャから感じ取れるのは、このプロジェクトを完ぺきに成功させたい、という強い決意だけだ。その根底にある動機らしきものを、はからずも知ってしまった今は、なおさらそう思える。
詳細は噂でしか聞いていないが、現行の勤怠管理システムの開発は、かなり無茶苦茶だったらしい。一括請負契約としてエースシステムに発注したのだが、設計や実装の質については、ほとんどノーチェックだったようだ。進捗報告会議は定期的に開いていたのに、報告書を受け取るだけで、内容を精査しようとしなかった。おそらく「大手SIerだから」という、根拠のない安心感もあったのだろう。結果的に、総合テストでおびただしい数の不具合が発生した上に、人事部門や拠点にいる事務スタッフの意図とはまったく異なる機能が納品されてしまった。修正を要求しても、報告書に承認印をもらっているから、という理由で拒否される。どうしても必要な機能は、追加費用を出さざるを得なくなる。最終的に「失敗」の烙印が押されたシステムの誕生だ。
導入の責任者だった渕上マネージャが、具体的にどのような役割を担っていたのかは分からない。が、その経験から「きちんと管理しないと、プログラマどもは、とんでもないものを作り出す」とでも思い込んでしまったのだろう。だから、マネジメントの本を読みあさり、何カ月も考え抜いたあげく、片っ端から良さそうなマネジメント手法を適用している。
つらいのは、あたし自身が「何が正解なのか」という答えを持ち合わせてないことだ。世の中に何人のエンジニアがいるのか知らないけど、そんな銀の弾丸を持っている人はいないだろう。持っている、と思い込んでいるだけの人は大勢いるかもしれないが。
あたし：あなたのやり方は間違っています
渕上マネージャ：では、正しいやり方は何なのか
あたし：分かりません……
これでは、信念の人、渕上マネージャを納得させることなどできはしない。
だからあたしは何も言わなかった。言えなかった。
「では、始めるように。私はインフラグループと打ち合わせがある」
そう言おうと、渕上マネージャは、ITマネジメント課を出て行ってしまった。残されたあたしたちは、顔を見合わせた。亀井くんとムツミさんの顔には不満と不審が浮かんでいる。きっと、あたしの顔にも浮かんでいただろう。
「本当にこんな面倒なことやるんですかね」亀井くんが納得できないように言った。「手間が増えるだけでしょう」
あたしだって思いは同じだ。だけど、3人で愚痴を言い合っていたところで、コードが勝手に生成されるわけでもない。どうせ避けられないことなら、さっさと済ませてしまうに限る。
「だったら、あんたが代案を出して、渕上さんを説得しなよ」
「そんなこと……」亀井くんは口ごもった。「……無理です」
「タスクボードで管理する方法だって、間違っているとは言えないでしょ」やり過ぎではあるけど。
「でも、こんなやり方、どう考えても……」
「おかしい？」あたしは亀井くんの言葉を先回りした。
「というか……正しくないというか。そう思いませんか？」
「思うよ。でもね」あたしはため息をついた。「社会とか会社とか業界というのはそういうものなの。誰が考えても不条理だとしか思えない方針やルールがほとんどなの。民主主義だからって、必ずしも多数意見で物事が決定するわけじゃないの。むしろトップの少数意見によって、流れが決まっちゃうことの方が多いの。そうじゃなきゃ、デビルマンだってドラゴンボールだって、もうちょっとまともに実写映画化されてるわよ」
「？」
「いいからやるよ」
あたしは、自分のレーンから先頭のタスクをむしり取った。それを見て、ムツミさんが手を伸ばしてタスクを取り、黙って自分のPCに向かった。亀井くんも、渋々ながらそれにならった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
くくな
デビルマンとドラゴンボールの件に激しく同意
BEL
模造紙貼るならホワイトボードいらないし、、
10分単位でタスク遂行できたら苦労しないよなあ、１時間単位でも無理なのに。
＞「大手SIerだから」という、根拠のない安心感
いまだに大手の方が"技術力"が高い、と思い込んでいる人は多いと思う。
(会社自体の)信頼性とか含めた総合力は高いかもしれないが、
それは技術力だけからなっているものではないのだよね。
＞きちんと管理しないと、プログラマどもは、とんでもないものを作り出す
これは、確かにそうだと思う。それが、"とんでもなく気の利いたもの"
かもしれないし、"とんでもなくおせっかいなもの"や
"とんでもなく的外れなもの"かもしれない、ということ。
abs
プロジェクトマネージャー・マネージャーが必要
TAKE
ひとつ大きな殻を破りましたね。
プログラマだから、営業だからというつもりはないですが、世の中の会社員の大半が必ず言うこと。
「これをやって意味があるのか？」「これは正しくない、間違っている」
否定するだけで、「なぜそうやるのか？」という背景までたどり着かない。
だから、相手を納得させられるだけの代替案も出せない。
世の中の決まりごとはそれを決めた人がいる以上、必ず決めた人なりの理由がある。
確かに「なんとなく」という理由もあるけど、それにも本人が気付いてないだけで
何かしらの背景があるもの。
これに気付くことができれば、一気に人間としても成長できるのにな。
saboten
正解かあ。
プログラムでいうならif then だろうけど、
実際はmaybeの連続で、総合的な状況に対して高度な判断が要求されるんじゃないかな。
それは、経験や勘、センスといった現状では体系化されていない領域で、
メソッド等の知識ではなく、経験者が語る何気ない一言に集約されていると思う。
渕上式でどのようにプロジェクトが進み、何を体験するのか、
今後の展開が楽しみです。
うーたん
現場の開発者に振りかかる数多の面倒事から守ってくれるリーダーが欲しいですよね。
mapawata
進捗が見てわかるんだから, 渕上マネージャの検印はいらないんじゃないか?
その進捗を見て, スケジュールを引き直すなどの方策をとるのがマネージャの仕事。
ここまで細かなメンバーのタスク管理はマネージャの仕事ではない。
ホワイトボードとポストイットによるタスク管理はマネージャのためではなく, 一つのモジュールが完成するたびに, ベルを鳴らし, チームでその喜びを共有し, チームの士気を高めるため。
タスクの交換不可も間違い。手の空いたor予定より進んでいるメンバーが残っているタスクをこなし, 互いに助け合えばいい。こうして, より強固なチームになっていく。
ってなんかの本で読んだ気がする。
jo
代替案がないことは、失敗をやらかすことの理由にはならない。
が、それじゃこのマネージャを納得させることはできないでしょうね。
曲がりなりにも理屈がある人なのが唯一の救い？
結論ありきで理由を後付けするような言葉の通じない人とは比べるべくもない。
豚
検印ｗｗｗ
noname
読むべきだった(と思うもの)
アート・オブ・プロジェクトマネジメント
マネジメントby ドラッカー
ほ
> 世の中の決まりごとはそれを決めた人がいる以上、必ず決めた人なりの理由がある。
> 確かに「なんとなく」という理由もあるけど、それにも本人が気付いてないだけで
> 何かしらの背景があるもの。
> これに気付くことができれば、一気に人間としても成長できるのにな。
たしかにそうなんだろうけど、説明を受けないと理解できないできないし納得もできないと思う。
説明するのがめんどくさいからって、ただ一方的に指示するだけでいいのだろうか。
それとも、それに自分で気づくような人間を選別するための試験をしてるのだろうか？
私のような下っ端の人間には上に人の考えはわからんです。
こんなのを思い出した
http://www.geekpage.jp/blog/?id=2007/10/22
TAKE
>たしかにそうなんだろうけど、説明を受けないと理解できないできないし納得もできないと思う。
>説明するのがめんどくさいからって、ただ一方的に指示するだけでいいのだろうか。
いや渕上マネージャのやり方が正しいというわけじゃないです。本当に優れたマネージャなら相手に合わせて、背景を伝えたりあえて伝えなかったりするように調整しますから。今回のケースは伝えるべきケースと思いますし。
ただ、私が言いたいのは優れたマネージャなんてほんの一握りしかいないってこと。あまりよろしくないマネージャについても、ちゃんと結果を出す人って必ずいますよね？
理不尽なことや時代に文句言ったって何もはじまりません。他人を変えることなんてできません。できるのは、自分を変えることだけ。
この主人公は偶然にしろ、渕上マネージャも「プロジェクトの成功」を目指してやっていることを知ったことから「自分を（考えを）変える」という結論に至ったから「殻をやぶった」という表現をしたまでです。
次の段階として、渕上マネージャと対等に「プロジェクトを成功させるために」意見のぶつけ合いを行えるかどうかですね。もちろん、いい意味で。
wm
TAKEさんの言っている事には同意するけど
>次の段階として、渕上マネージャと対等に「プロジェクトを成功させるために」意見のぶつけ合いを行えるかどうかですね。
これは
>渕上マネージャは、あたしの無知を哀れむような顔になった。
こんな態度を取っているから無理じゃないかな。
いや。まぁ、人間だし軽蔑とか出てしまう事はあるだろう。
でも、本で読んだだけの知識でそういう態度が出てしまう人って、何か根本的な所で歪んでいると思う。
普通は、「本で読んだだけ」というのなら、みんなで本を読んで、
「この方法、いいよな」
と同意を取って、みんなで試してみる、という方向に行くと思うのだが。
TAKE
>TAKEさんの言っている事には同意するけど
ありがとうございます。
>>次の段階として、渕上マネージャと対等に「プロジェクトを成功させるために」意見のぶつけ合いを行えるかどうかですね。
>これは
>>渕上マネージャは、あたしの無知を哀れむような顔になった。
>こんな態度を取っているから無理じゃないかな。
すこーし論点がずれてる気がします。皆さんの書き込み見てると渕上マネージャ批判なり肯定なりの意見が多いですが、私はこういった逆境になっても変化していく主人公を見守る立場で話してます。
私はこの変化を成長の過程と思っていますが、そうは思わない方もいるでしょう。
確かに渕上マネージャは完全に見下してるので難しいでしょうね。でも、前の話でもありましたが、理由もなく他人の意見をシャットアウトしてるわけじゃないですよね？何話だったか忘れましたが、主人公と渕上マネージャの２人の管理MTGで主人公の意見が通ったときありましたし。
「無理かもしれない」あくまで、「かもしれない」んです。ということは「成功するかもしれない」ともいえますよね？
「１％の可能性でもあるなら」って根性論で押し通すつもりもないですけど、諦めちゃったらそれまでですし。
主人公からもっと歩み寄ってもいいのかもしれませんね。むしろ自分から「こう管理してもらったらうまくいくはず」とか提案してみるとか。
ほ
渕上マネージャと主人公がどう変わるか興味つきないですね。
変わるにしてもどっちの方向に変わるかってのもありますし。
過去の失敗から学んだ渕上マネージャが今回とりいれたのがこの手法なわけで
今回は何を学ぶかどう変われるか。
筆者がこの物語で描きたいのは渕上マネージャなのでしょうか。
いやー、おもしろいです。次回も楽しみにしてます。
ぽんた
日比野さんもコメしている幾人の方も勘違いされているのが、
代替案なのは渕上マネージャの方です。
現状のやり方に対して改革が必要だとしているならばその立証
責任は渕上マネージャにあります。
その改革案が理解・納得できないものであれば同意する必要は
ありません。
なので本来は以下のやりとりのようになるはずです。
渕上マネージャ：あなた達のやり方は間違っている
あたし：では、どこがどう間違っていて、どういう失敗に
なっているのか
渕上マネージャ：正しいプロジェクト・マネージメントと
いうものは・・・
あたし：それは間違いの指摘ではない。また、そのやり方が
正しいとしてそのやり方で成功した実績があるか？
ない場合成功すると思える根拠は？
渕上マネージャ：実績はない。根拠はマネジメントの書籍等
でもよいとされているし・・
そうなっていないのは、単に渕上マネージャが権力を持っている
からにすぎません。
なので、理解も納得もしないが、保身のために権力に従いました
ってだけなのですが、問題が摩り替えられた記述になっているの
は最終的に不利益を被るユーザーに対しての責任逃れでしょうか。
（正しいやり方をいきなり聞くながれもかなり不自然です。
自分も間違いだと思っていたのですか？）
いずれにしろ、本当にシステムのためにならないと思っているこ
とは譲ってはいけないでしょう。
HOHO
プロジェクトは成功しそうですけど、死傷者が出そうな予感です(ToT)。
ほったて
> 渕上マネージャ：実績はない。根拠はマネジメントの書籍等
> でもよいとされているし・・
「よいとされている」と断言するに１票。
WhiteBall
結局、管理工数が増えて、タスクが間に合わなくなって、ポストイットが山積みになって、デスマーチになって、、、 という展開に見えなくも無いなぁ。
タスク消化しきれなくなる原因が、管理工数が多すぎるのか、スケジュール(工数)に無理があるのか、は分析する必要がありそうですが。
プロジェクトの打ち上げ方がどうなるか、非常に楽しみです。
>現状のやり方に対して改革が必要だとしているならばその立証
責任は渕上マネージャにあります。
んー。
渕上さんをやり込めたいあまり、無茶言ってません？
今回の場合はそういっておくと溜飲が下がるわけですが。
本当にそれを信じて言っているのなら、
たとえば、前作とか前々作では、
主人公側に反対してないといけないはずですよ？
前々作は微妙かもしれませんが。
でも、オブジェクト指向を使わないやりかたのほうが、
「実績」はありますよね？
現代でもオブジェクト指向を使わない開発で成功しているものがある以上、
オブジェクト指向の必要性は「立証」はされてませんよね？
自分が言いたい結論に都合がいい根拠を持ち出してくるというやり方は、
感心しないと思います。
昔のエンジニア
メタ・タスク「ふっちーとタスクについて打ち合わせる」×１０回＝100分／1日
ふっちーは「プロダクト・マネジメント」派だな。
その源流は「テイラー・システム」。
近代国家を作り上げた「流れ作業」を成功に導いた「科学的管理法」というヤツだ。
一定の効果（品質向上と生産性向上）は実証されている。
それと同時に、テイラー・システムの徹底的な導入は、現場労働者に大きなフラストレーションを発生させて、サボタージュ（破壊的な怠業行為）の温床になり、全ラインの停止⇒工場の崩壊に至ったという現実もある。
その実例へのスタディ・ワークから「人間関係管理論」が発展した。
こちらは言い換えれば「ヒューマン・マネジメント」派だ。
判りやすく言うと「仕事に充実したやりがいを与えれば、労働者は自分で艱難辛苦を乗り越えてオーバー・アチーブを達成する」というものかな。
でも「テイラー・システム」は、よほど管理者に魅惑的なのか、形を変え品を変えて再登場するんだな、これが。
で、やりすぎたマネージャーがメンバーの信任を失って、サボタージュからプロダクトが崩壊するという、二の轍・三の轍を踏んで「歴史を繰り返す」。
今では、生産現場は「流れ作業」から「セル生産（一人屋台方式）」に切り替えられつつある。
「流れ作業」を維持しなければいけない場合は、産業ロボットの導入とか、カイゼン運動などで自主性を引き出そうとしている。
ふっちーに感じる危険性は「やりすぎの新米マネージャー」に近い。
最終的な「成果」＝「役に立つシステム」を見失い、マネジメントという手段が目標と化しつつある。
人間の注意力と集中力は「有限なリソース」だ。
それは「リスク管理」の「冷たい現実」だ。
「冷たい方程式」の最終解答はこれだ。
「有能なマネージャーとは、成功したマネージャーだけである」
方法ではなく、結果だけなんだよ。
いつでも。
BEL
＞世の中の決まりごとはそれを決めた人がいる以上、必ず決めた人なりの理由がある。
＞確かに「なんとなく」という理由もあるけど、それにも本人が気付いてないだけで
＞何かしらの背景があるもの。
これはまったくその通りなんですよね。
それでも「でも、こんなやり方、どう考えても……」と直感的に思うなら、
決められたときは正しかったけど"今の状況ではこれこれこうだから正しくない"
とか、"今回のケースでは正しくない"とか、そのやり方が
間違ってる理由を説明できればいいんですよね。「正しいやり方は何なのか」は
わからなくても、間違ってると思うやり方で突き進むよりはいいはずです。
別な話で、もっとよくないのは"渕上さんのやり方は間違ってる(らしい)"
という"理屈を伴わない情報"が浸透してしまうこと。
＞現状のやり方に対して改革が必要だとしているならばその立証
＞責任は渕上マネージャにあります。
これはその通りだと思います。同じようなプロジェクトで実績もあるのに
いきなり違うやり方でやるなら"今まで何がいけなかったのか"を説明すべきですね。
もしくは「今回の開発は今までとは〇〇が違うから現状のやり方ではダメだ」とか
(「何がだめとかじゃないけど実験的に新しいやり方で」とかも立派な理由ですが)
＞現代でもオブジェクト指向を使わない開発で成功しているものがある以上、
＞オブジェクト指向の必要性は「立証」はされてませんよね？
これは開発のタイプというか、向き不向きの問題もあると思います。
オブジェクト指向を使わない方がよいとされているタイプの案件で
いきなり「オブジェクト指向を使おう」というならそれなりの立証は必要でしょうし。
とはいえ、渕上さんも
「バグや仕様漏れがあっても、仕方ないな、と笑って重要視しない。」とか
今までの開発はダメだったという思いを彼なりに持っているようですが。
見習いSE
これまでのシリーズと違い、悪役キャラ(＝渕上さん)が決してただの無能管理者(有能とまでは言わないが・・・)では無いことが、読み手からしても色々と考えさせられる事が多く、非常にためになる。
主人公視点で物語が進むから、渕上さんのやる事なす事がどれも無用なものに見えてしまうが、現行の勤怠管理システムの導入PJが失敗に終わったという背景を考えると、PJ管理者としてはここまで徹底したくなる気持ちも分からんでもない。
ただ、こう言ったPJ管理手法はPJ運営上に何か問題がある事が前提で、それに対する対処として取捨選択/アレンジしていかないと効果は発揮しない事が多いので、何も問題が発生しない内から一方的に徹底させる事に意味は感じない。
そう言った意味で、これまでの物語中での渕上さんの最大のミスは、過去のPJにとらわれ過ぎていると言った点なのかも・・・過去PJの失敗は次に生かさなければならないけども、メンバーも何もかもが一新されているのだから、同じ教訓が今回のPJに生きるとは、必ずしも言えない。
これから、一体どんなひずみが生まれて、渕上さんがそれらにどう対応していくのか・・・見物です(笑)
TAKE
>現状のやり方に対して改革が必要だとしているならばその立証
>責任は渕上マネージャにあります。
>その改革案が理解・納得できないものであれば同意する必要は
>ありません。
「同意する必要はない」とはおっしゃいますが、同意しようがしまいが
時間は経過します。
「私は納得できませんので、納得できる方法が出てくるまで仕事をしません」と
やるほうが正しいということでしょうか？
>そうなっていないのは、単に渕上マネージャが権力を持っている
>からにすぎません。
結局はこの一文に尽きます。「単に権力を持っているから」
じゃあなぜ「私は納得できませんので、納得できる方法が出てくるまで仕事をしません」が権力を持っているのか？少なからず過去の
実績や期待値から上層部から承認されているからでしょう。
それが現実です。主人公は所詮はサラリーマンなんです。（正確にはウーマンですが・・・）
会社に雇われ、給料をもらっている以上、お上の意向には従わざるを得ません。
「私は納得できませんので、納得できる方法が出てくるまで仕事をしません」
これではただの子供のわがままです。私が上司なら「嫌なら辞めろ」と
いうだけです。
とはいえ、確かに渕上マネージャのやり方が極端なのは事実で。
確かにこのままなら失敗する可能性は高いでしょう。
でも、もっと成功の可能性が高い手法は誰も思いついてません。
期限がある以上、「よい手法が出るまで開発を止めましょう」なんて
こと現実にできると思いますか？
「今のやり方ではだめかもしれない」と思っても、とにかく前に
進まないと成功はつかめないのです。
「なぁなぁで進めろ」といいたいのではありません。
>「冷たい方程式」の最終解答はこれだ。
>「有能なマネージャーとは、成功したマネージャーだけである」
>方法ではなく、結果だけなんだよ。
>いつでも。
結局最後はこれになります。
「結果を出したもん勝ち」。
私自身よく陥りますが、よいやり方を思いついたところでそれを
実践しなければ結果はでません。
主人公は「やり方がどうこうよりまずは結果を出すこと」に視点が
シフトしたんだと思いますよ。
さぁこれからどうなっていくことやら・・・。
主人公も渕上マネージャもどう変わっていくか楽しみですね・
TAKE
ここコピペミスです（笑）
>結局はこの一文に尽きます。「単に権力を持っているから」
>じゃあなぜ「私は納得できませんので、納得できる方法が出てくるまで仕事をしま>せん」が権力を持っているのか？少なからず過去の
>実績や期待値から上層部から承認されているからでしょう。
↓
>結局はこの一文に尽きます。「単に権力を持っているから」
>じゃあなぜ渕上マネージャが権力を持っているのか？少なからず過去の
>実績や期待値から上層部から承認されているからでしょう。
saboten
>主人公からもっと歩み寄ってもいいのかもしれませんね。むしろ自分から「こう管理>してもらったらうまくいくはず」とか提案してみるとか。
なんというか日本人的な考えというか、精神論というか
有能なブレインが必要だという周知の事実があっても、
環境は変えないで今ある状態でなんとかしようとするんですよね。
>「テイラー・システム」は、よほど管理者に魅惑的なのか、形を変え品を変えて再登場するんだな、これが。
>で、やりすぎたマネージャーがメンバーの信任を失って、サボタージュからプロ?>ダクトが崩壊するという、二の轍・三の轍を踏んで「歴史を繰り返す」。
今回はやり方がどうだというより、人間性というかそうのが原因じゃないかなあ。
効率の良い手段であると納得させれないから反発しているわけだし。
>「冷たい方程式」の最終解答はこれだ。
>「有能なマネージャーとは、成功したマネージャーだけである」
成功かあ。
たとえ赤字になっても目標が達成できれば成功という人もいるし、
納期守っても評判悪くて敵作る人もいるしなあ。
TAKE
>>主人公からもっと歩み寄ってもいいのかもしれませんね。むしろ自分から「こう管理してもらったらうまくいくはず」とか提案してみるとか。
>なんというか日本人的な考えというか、精神論というか
>有能なブレインが必要だという周知の事実があっても、
>環境は変えないで今ある状態でなんとかしようとするんですよね。
正直、私は日本以外のやり方を知りません。だからこのやり方が必ずしも
正しいとは思ってません。
でも・・・ここは日本で、主人公の勤めている会社は日本企業なわけで。
「郷に入っては郷に従え」という言葉の通り、納得いかないからって
環境を無理に変えようとしても自分がはじかれて終わるだけですよ。
環境を変えることができるのはそれなりの権限者だけ。
その権限者に社内営業かけて環境を変えるという方法もありますし、
そういう手段を私自身とったこともあります。
難しいですよね。こういう討論してても結局最後には精神論に行き着く。
感情のある人間同士の話ですからね。
感情の浮き沈みで仕事の出来がまったく変わってしまうことのように
最終的には精神論になるわけです。
もちろん「それだけ」では駄目です。でも、どんなことにも必ず
付きまとうのが「人の心」です。
渕上マネージャはそれを軽視しすぎているのかと思ってます。
Fuchi
渕上さん、管理本を読むんだったら、エクストリーム・プログラミング(Extreme Programming, XP)も読めば良いのに、色々なプロジェクトがあり、それぞれの開発に適した手法があるのをご存知無いようですね。
まさと
>渕上さん、管理本を読むんだったら、エクストリーム・プログラミング(Extreme Programming, XP)も読めば良いのに、色々なプロジェクトがあり、それぞれの開発に適した手法があるのをご存知無いようですね。
プログラマやメンバがこうした態度をとっていれば、ＰＭを硬化させる面もあるのでは？
渕上さんから見れば、「現場やプログラマにまかせて失敗した」という実体験があるわけですから、実体験を信頼せざるを得ないと思います。
現場へ乗り込んできた当時の印象も、好転させる助けにならなかったでしょうし。
もっとも、過去の失敗がよほどトラウマになっているのでしょうけど、渕上さんは勤怠管理システムの他にプロジェクトの経験がなかったのかな？とも思います。
CIOになろうというキャリアの中でいろいろなプロジェクトに参加していれば、プロジェクトにもいろいろあるというのは経験しているはず。ことごとく、プログラマやメンバが信頼できないプロジェクトだったのでしょうか？
その点で、渕上さんが狭い人物に描かれているな、とも思います。
くくな
ERPの導入の指揮が本業で、前回の勤怠管理システム開発は、スポットだったぽいですね。
ERPというのは、けっこうカスタマイズの嵐になる場合が多いので、スポット業務に時間を割いていられなくて、エースシステムに丸投げしてしまったんでしょう。
あと、ユーザー企業だとITのトップは開発経験なんかなくても、政治的理由でなるということが多いのでは？
渕上さんはERPのことはわかってるわけなので、まだましな方ですね。
いぬ
タスク管理に模造紙を使ってるIT部門……
それが正確で一番良い方法だと思うのならば
勤怠システムも模造紙で実装してみればいいのにｗ
世の中の代替案がないと否定しちゃいけない病をどうにかしてもらいたいと思います。
悪いものをやらないことはそれだけで前進だと思うのですが、
なんで代わりを見つけてからじゃないと否定しちゃいけないのか。
「代替案は？」
「わかりません。これから一緒に探しましょう」
で良いと思うんですが。
へろへろ
ストイット方式を入れましたけど、それより前に日報を書いてましたよね？
もっと細かいメッシュの報告が入るようになったんだから、もちろん日報は
廃止ですよね？
としろう
タイトルで先日コンビニで「もしドリ」というドリンクを見て驚愕したのを、
デビルマンとドラゴンボールに「どうしてこうなった」感を思い出し、
きっとプロジェクト成果も「どうしてこうなった」になるんだろうと感じ。
ツイッターの最初の方でのデビルマンとドラゴンボールへの食いつき笑ってしまった。
自分も「代替案」セットでの反論は「有るに越した事は無い」と思うが
必須という程ではないと思う。
また、論理は正論でも「程度問題」があり、やりすぎで駄目な事もあるし、
そんな中途半端にするならしないほうがマシという事もよくあると思うぞ。
>理不尽なことや時代に文句言ったって何もはじまりません。
>他人を変えることなんてできません。できるのは、自分を変えることだけ。
最後の自分の件は良いですが、
不平不満の表明も説明も、他人を変える努力も全部必要でしょ。
「奴隷たれ」の悪い日本式社蓄であれと言いたい訳ではあるまい。
言って、表現して、怒って、交渉して勝ち取るのがグローバルスタンダード
何もしなければ何も変わらない。
他人の足を引っ張るとか無駄にネガティブではなく、
他人の間違いを正す事も、当人の為にも自分の為にも必要でしょう。
としろう
>タスク管理に模造紙を使ってるIT部門……
これは渕上氏のやり方を自分は評価したい。
変にまたシステムを急遽導入して使うよりは、という意味で。
ただし、タスク交換他は柔軟にすべきかと。
また、予定終了時間なんて所詮「どんぶり勘定」なのでどんぶり許せと
例えば見積精度を上げていき「どんぶり」や不確実さを排除していくと
見積で詳細設計図が出来上がる
それと似たように管理を細かくすると客の欲しい物を作る事に比べての
管理工数が大きくなりすぎて何が目的か見失いそうになるぞ。
問題が起こって初めて動く駄目管理をコメントで例に上げられているが
問題が起こって動くだけマシの場合もあるなあと思う。
良い管理は、問題が無いか暇が有れば観察し、必要以上に開発の足を止めないようにし、
要所のみ押さえ、アラート報告を受けて問題が起こる前に対処の準備をしておく。
そういうものではなかろうか？
結果論だけで見るのではなく、問題が起こらないように調整した結果の成功である。
何も起こらないのが偉いのではなく、起こさせないようにする・したのが偉い。
結果的に残業しないですむようにするのが偉いのと同じ。
後半偉そうな事書いてみたけど、自分でも難しいだろうと思う。只の理想論だ。
PG
マネジメント結構、コストカット大いに結構
でもそのレベルを要求するだけの給料払ってないよね、きっと
「プロフェッショナルなんだから」の言葉で無理難題を押し付け、出来なければ「金を貰って仕事をしてるんだからちゃんとやれ」なんて言われましてもねえ
貰ってる金に見合わない仕事を課されてもそりゃあこなせませんよ
亀井君なんか顕著でしょうね
新人レベルで給料も新人相応だと思われる人間に求めていいレベルといけないレベルの要求があるんですよ
立ち位置的にもこれから育てていこう、くらいの人間にどこまで求めて良いかの判断がおかしくないか？と
何かと「好きでやってるんだろ」だの「プロ意識があればやれるはず」だの言う前に「プロだからこそ報酬と成果は相互関係にある」という事実を認識しないと駄目じゃないですかね
渕上さんに足りないのはコスト（＝人数、時間）をカットするなら成果（＝機能、成果物）を削らざるをえない、妥協せざるをえないという認識でしょうね
理想と現実のギャップを埋めないとどこかで破綻しますよ
TAKE
>不平不満の表明も説明も、他人を変える努力も全部必要でしょ。
>「奴隷たれ」の悪い日本式社蓄であれと言いたい訳ではあるまい。
>言って、表現して、怒って、交渉して勝ち取るのがグローバルスタンダード
>何もしなければ何も変わらない。
>他人の足を引っ張るとか無駄にネガティブではなく、
>他人の間違いを正す事も、当人の為にも自分の為にも必要でしょう。
「変えるための努力は必要」
おっしゃるとおりです。私の言葉不足もありましたね。
>できるのは、自分を変えることだけ
これも、正確には「今すぐにできることは」が頭につきます。
私は「諦めろ」といいたいわけではなく、「受け入れろ」と
言いたいのです。言葉のニュアンスの違いって分かっていただけますかね？
耐え忍び、それまでに理論を固め、変えるための大きなチャンスを待つのです。
それまでの間は、小さな小さなチャンスをひとつひとつ掴み、ものにしていくのです。
そうすればより成功確率も上がります。
今回のケースでいえば、例えば小さなチャンスは日々の「実装の実績」を
あげること。最終的に口出しされるでしょうけど、「実装はお前がやれ」という
小さなチャンスを与えられているわけです。これをまずは着実にこなすこと。
そして、大きなチャンスは本当にこのやり方が間違っている場合、
どこかで大きなメスが上層部から入るでしょう。「進捗はどうなのだ？」と。
そこでどんなアクションを起こせるか、ここにかかっています。
もちろん渕上マネージャしかメスに気付かない可能性もあります。チャンスを
掴み損ねないようネットワークを張るのも現時点で必要です。
「現状を嘆いて不満を言うこと」「現状を諦めること」どっちもすぐにできて
簡単です。
でも、本当に変えなければならないという強い決意があるのであれば、
「現状を受け入れ、少しずつ準備をし、チャンスを掴み、そこで逆転」と
いうシナリオを長い目で思い描き覚悟していくことが必要です。
かくゆう私も偉そうに書いてますが、ほとんど実践できてないですけどね。
こういうところに書くことで自分にも言い聞かせてます（笑）
世の中の成功者はおそらく本当にこれを実践している人なのでしょうね。
Jitta
マネジメント、あるいは管理って、何なんでしょう？
息子が、イナズマイレブンとかいうサッカーアニメを見ているのですが、そこに出てくるマネージャーは、選手を見て、選手の状態を知り、選手にとって必要なケアをしています。決して、選手から報告は受けていません。
渕上マネージャーはどうか。彼は、何を管理しているのだろう？開発者は、それぞれの状態を、渕上さんが望む形式にまとめて報告している。彼は、それで、何を管理しているのだろう？
少なくとも、プロジェクトの進捗について管理をしているのは、開発者じゃなかろうか。
てｓｔ
Jittaさん
> 渕上マネージャーはどうか。彼は、何を管理しているのだろう？
そりゃ決まっているでしょう。彼の満足感、俺はマネージしている！感を管理しているのであろう。
彼は”プロジェクト”をマネージメントしているのではなく”自分の心”をマネージメントしているのだ、そしてそれを他社に強要している。
大手SIer
ポストイットを使ってタスクや進捗や見える化を推進している企業が
多くあるように、渕上マネージャーの目の付け所は悪くないですね。
しかしながら、運用がいまいちということで空回り感は強いかな。
書いていないのでわかりませんが、うちの会社だと、より上層部から
「どうなってるんだ！」てな感じで何か叱責されたんじゃないかなと
思えるような立ち回りですね・・・
また、主人公が現状を把握できた。ここは大きなポイントでしょう。
ただ、自分の能力不足にも原因はあるのに、他のせいにして
不条理だと逃げる姿勢は「うーん」と思います。
また、これまでは取り入れられた意見を除くと、間違っていると
主張するばかりで、なぜ間違っているかを説明できていないのが現状。
これじゃまるで幼稚園児や小学生の主張なわけですが、ここに
なぜ気付かないのかも疑問です。
結局のところ、「間違っている理由を説明できない人は、正解に
辿り着くこともできない。」と言われるように、今のままじゃ対案を
出せる出せない以前の問題じゃないですかね。
>Jittaさん
開発メンバーは指示された内容を報告しているだけで、プロジェクトについては
何も管理してしないでしょう。読む限りは今はタダの作業者ですね。
とは言え、管理手法がころころ変わるところも見ると、渕上さんが
きちんと管理できているかも不明ですが。
あと部活のマネージャと、プロマネを同じ土俵で論じるべきではないかと。
書かれているイナズマイレブンの例は、「何も計画していないので」
支援であってマネージメントではないのでは？
「もしドラの影響を受けて勘違いしている人が多い」と先日あるプロマネも
苦笑していましたが、部活のマネージャーで「ミッション達成のための
計画と推進」というプロマネ的な振る舞いをしている人なんてほとんどいませんよ。
ふっちーLove
大手SIerさんへ
今、ちらしの裏にふっちーへの応援メッセージを書くのに忙しいので、少しだけ。
貴方の意見に全面的に賛成です。
Jittaさんへ
ユーザー企業のマネージャーはSE・プログラマーのために仕事をしているのではありません。
SE・プログラマーの立場から見ただけでは理解しきれないと思います。
ふっちーLove
ふっちーも余裕たっぷりでいろいろ試しているじゃない。
追い込まれてすがれる藁を探してあがいているように見えます。
主人公は評論家から変わろうとしているように見え、好感が持てます。
彼女が状況をいい方向に変えてくれるといいな。
はど
実体験から言わせてもらうと、マイクロマネジメントは百害あって一利無しです。
目的が明確で効果も実証できるものでないと、単に余計な工数を増やしてスタッフのモチベーションを下げるだけ。所詮はマネジメントする側の自己満足なんですよ。
まして少人数なのにこんなやり方しないと現状把握できないなんて、マネージャーとして無能もいいとこでしょう。
業務の進捗管理なんて、web上で共有したエクセルでマトリクス組んで貼付けるだけで充分だよ。いちいち承認なんかいらない。詳細はリンク貼って飛ばせばいい。
特定の人にタスクが集中しそうな時に仕事割り振って調整したり、MTGの設定もそれで他者のスケジュール見ながらできる。PW設定すればセキュリティだって確保できる。
マイクロマネジメントやってた前の職場は、すべてを把握してないと気が済まない社長が居ないと、業務が何も進まない状態になってしまった。他の人がいま何やってるかさっぱり分からんから、連携もなにもあったもんじゃなかったな。結局マネジメントする側がボトルネックになって、業務効率とか生産性が意味をなさない代物になってしまう危険性が大きいのよ。
ハムレット
> 「開始に今日の日時を書く。時間は10分単位だ」
関西人としては、この時期になると思いだしますね。
採算や効率重視で、分単位のスケジュール管理、職制による厳しいチェックとペナルティ。
IT業界とは違うのですが、そんな業務体制、職場の雰囲気の最悪の事例が、死者107名を含む、500名以上の死傷者を出した、あのJR福知山線の脱線事故だったような気がします。
さて、他山の石ではないですが、マイクロマネージメントによって、部分最適化ばかり追求すると、案外と予想もしない理由で、重度のシステムダウンが起こってしまうのかもしれないですね。
さて、この物語、結局勤怠システムのリプレースは上手くいくのかしらん。
Jitta
てｓｔさん：
> 彼の満足感、俺はマネージしている！感を管理しているのであろう。
なるほど！(゜o゜;
大手SIerさん：
> 開発メンバーは指示された内容を報告しているだけで、プロジェクトについては
> 何も管理してしないでしょう。
私は開発者が「プロジェクトを管理している」とは書いていません。
「プロジェクトの進捗について」と書いています。
プロジェクトの進捗を管理するのはプロジェクト管理の一部ですが、全部ではない、と思います。
いや、「プロジェクトの進捗」というのは間違いでした。「個々の作業の進捗状況」ですね。
渕上マネージャについて、こう書いています。
「彼は、何を管理しているのだろう？開発者は、それぞれの状態を、渕上さんが望む形式にまとめて報告している。彼は、それで、何を管理しているのだろう？」
つまり、プロジェクトを管理しているようには思えないのです。
管理対象は、色々あると思います。部活のマネージャが管理するのは、部員の健康（や備品）ではないでしょうか。
「勝ちに至る行程」を管理しているのではなく、「コンディションを良好に保つこと」を管理しているのだと思います。
勝つためにコンディションは必要な要素ですが、それが全てではありません。
他の要素は、監督なりコーチが管理するのではないでしょうか。
# ちなみに、もしドラ関連については一切見たことがありません。
ふっちーLove
PGさんへ
>マネジメント結構、コストカット大いに結構
>でもそのレベルを要求するだけの給料払ってないよね、きっと
大抵のユーザー企業は自社の社員の単価より高い単価で
SE・プログラマーに外注しているのよ。
ユーザー企業だって、元請け、孫受けの途中で
いろいろ抜かれて手取りは？？？ってのは知っているけどさ、
少なくともユーザー企業が払っている時点ではプロにふさわしい報酬だと思う。
それでも期待しちゃ駄目？
ねこ
ふっちーLoveさんって
>今、ちらしの裏にふっちーへの応援メッセージを書くのに忙しいので、少しだけ
こういう書き方するところが最高にイラっと来るんですよ。
またそれがいいんですけどね。
ふっちーLove
>渕上さんに足りないのはコスト（＝人数、時間）をカットするなら成果（＝機能、>成果物）を削らざるをえない、妥協せざるをえないという認識でしょうね
ふっちーだって分かっていると思うよ。
ふっちーは自動車産業出身だけど同時にCIOにもなろうって人だという設定。
「金かけていい物が出来るのは当たり前。プロなら安くて良いものを作る。」
そんな世間の常識はシステム開発に通用しないと知っているはず。
最初の出だしで磯貝課長と八木社長が間違えて、
ふっちーはその枠の中で精一杯がんばっていると思いたい。。。
ふっちーLove
（・∀・）ﾆﾔﾆﾔ
さそうたける
マネージメントって日本語だと「管理」と訳されてますが、
「監視」の意味で捉えられている場合が多い気がします。
元々の意味は「経営」とか「経理」なんですけどね。
つまり、人・モノ・金・時間といった各種リソースを有効活用して、
目的を達成できるよう取り計らうのがマネージャーの役割。
だから、リソースが有効に活用されているかどうか、
活用されてないとしたら原因は何なのか、
それを把握する為の手段としてリソースの監視をするわけであって、
極端な話、放っておいてもリソースが上手く有効活用されているのであれば、
監視なんかしなくてもマネージャーの役割としてはOKなんですよね。
現状、渕上さんは監視に重きを置きすぎているようで、
プロジェクトメンバーのモチベーション低下や、
報告業務にかかる時間的コストの増大など、
リソースの有効活用という本来の役割を見失っているのでは？と危惧します。
まあ、渕上さんが監視に重きを置かざるを得ない理由は2点あるんでしょう。
(1) 過去の開発プロジェクトで監視を怠ったゆえに大失敗を経験した
(2) プロジェクトメンバーの事をよく知らないため、監視せずにどこまで任せて良いのか判らない
今回のプロジェクトは良い意味で失敗して欲しいですね。
渕上さん自身はかなりの勉強家みたいなので、
失敗を経験する事でマネージャーとしてもう一皮剥けると思うのです。
Edosson
ﾆﾔﾆﾔしてる暇があったら、渕上氏応援メッセージを投稿してよ。
忙しいってほど、がんばって書いてるんでしょ。
２６日の午前７時から。
としろう
http://jibun.atmarkit.co.jp/lskill01/rensai/fullscruch/02/01.html
自分の考えではこれに近いかな。ここまで前向きにはなれないけれど。
結局最初に詰められない以上リスクを込んでどんぶりで受けるしかない。
それを詳細出して説明しろと言われれば結果的に嘘の資料（予想でしかない）
を作る分無駄なんじゃないかと思う事はある。
どうせ出る仕様変更相手にするのだと「最小限のドキュメントしか作成しません。」
が現実的な解だと思うのだ。コストと納期と品質のバランス取るならば。
コスト増加を許容し納期にも余裕が有るなら「作っても良い」が。
その意味で「渕上氏」のドキュメント過剰と管理過剰はコスト削減と納期維持と共に、
今回の開発に合わない手法だと思う。
恫喝を警戒して匿名
雑感をつらつらと。
「仏作って魂入れず」でしょうか > 今回の印象。
渕上マネージャは形≒ハードウェアを整えただけで満足しており
なぜ問題解決できるのか・どうやって問題解決していくのかについては
何も考察していない・何もビジョンを持ち合わせていないように見受けられます。
そして安定の「ミッション達成のための計画と推進」感のなさ。
もはやプロジェクトマネージャ、いや部活のマネージャですらありません。
「俺はマネージしている！感を管理している」という揶揄も然りですね。
# 枝葉末節に拘り根幹を蔑ろにするキャラ、としては立ってますね:-)
実作業をする側の者としては「本質を捉えていることが大事」と考えるので
これはダメだろに一票。尤も「手ではなく口を動かすのが仕事」だったり
「仕事 = 社内政争」だったりするスタンスの人にとっては
「形が大事」なのでしょうからまた違った結論になるのでしょうね。
「仕事に疑問を抱くこと」と「代案を提示すること」とは対立するものではありません。
前者を昇華した先に後者があるのだと考えます。委縮せずどんどん疑問を抱きましょう。
ここで疑問を抱くことをやめてしまう・考えるのをやめてしまうのは即ち「社畜化」です。
「代案が出せないならダメ」扱いして双方を対立する概念であるかのように誤解させるのは
言葉足らずか、そうでなければ社畜としての防御反応なのでしょう。
「ユーザー企業のマネージャー」同様、「SE・プログラマー」も
マネージャのために仕事をしているのではありません。
成果物には何ら直接貢献しないくせに人件費は人並以上に高い、という点で
マネージャというものは存在自体が本質的にコストなのです。
故にそのコストに見合うだけの仕事・メリットを、成果物orプロジェクトorチームは
マネージャに対し期待≒(暗黙的に)要求するわけです。
マネージャにできるのはこれまた本質的に「できても間接的な貢献だけ」なのです。
# 「成果物作成しろ」ではなく「仕事のハードルは高いよ」の意です。
貢献があればむしろいいほうで、実際のところは本文同様、コスト増になる方向にしか
仕事できてないマネージャが多いのが現実ではないでしょうか。
「ユーザー企業のマネージャー」諸氏にはマネージャとしての己の仕事が
実質的にペイしているのかどうか、常に自問していただきたいものです。
大手SIer
渕上マネージャーや主人公の評価は別として、みなさんのコメントを見るに、
いまだに部活のマネージャーがでてくるので、一度組織論まで戻った方が議論が
建設的に進みそうですね。
なので少し脱線。
プロマネはプロジェクト、組織のマネージャーは任されている組織で
定められた成果を出すために必要な措置を行うというミッションを
担っています。
そのミッション達成のために、計画、推進をするのがタスクです。
また、計画、推進と言っても、みなさんご存知のように、WBSとスケジュールを
引くだけが仕事というわけではなく、ステークホルダーの調整やコスト、
品質管理、メンバーのモチベーション、健康管理（残業管理とも言いますが）等、
結果を出すために必要なすべてが責任範囲になります。
否定的な意見は多いと思いますが、社内政争だって、結果を出すために
必要ならばマネージャーのタスクですね。
では、部活のマネージャーはどうでしょうか。
たとえば、運動系のクラブで、マネージャーが行うべき役割をすべてこなした上で
選手が想定通りの活躍ができず結果がでなければ、マネージャーはその結果に
対する責任を取るでしょうか？
私は取らないと思います。
確かに、部活の中で役割分担としてのタスクはありますが、部活という組織の中で
マネージャーは選手の結果責任を取る立場ではないからです。
皆さんになじみの深い例として、開発系のプロジェクトに置き換えると、
部活のマネージャーは、フレームワークの開発や開発環境の整備等を行う
支援部門に当たるのでしょうね。
つまり部活のマネージャーは組織の中では、マネージャーではなくメンバーです。
だから部活のマネージャーを持ち出すべきではないと書いているわけですね。
最後に、ダメマネージャーは多いと思いますよ。
うちは役員陣が「匿名で報告できる仕組みを作るから、ダメマネージャーを
報告しろ！」と大号令をかけて、だいぶ駆逐（全力で自己啓発してまともに
なったとか、閑職に左遷）した上で、マネージャーのための教育を継続的に
行っていても、時々「あー、この人ダメだ」ってマネジャーがいるぐらいですから。
恫喝を警戒して匿名
逆説的ですが、ダメマネージャの存在こそが
部活のマネージャ話が蒸し返される原因なのでしょうね。
# ダメマネージャ駆逐への取り組みの話、興味深いです。
としろう
>逆説的ですが、ダメマネージャの存在こそが
>部活のマネージャ話が蒸し返される原因なのでしょうね。
少し違うと思う。
一般含め、マネージャのイメージが部活のマネージャに近いからだと。
駄目マネージャでも、
条件が良かったり、メンバーが挽回してくれれば結果が出て、
マネージに対する問題（ヒヤリハット）が表に出ないのが問題で、
本当に失敗してからでなければ省みられない（責任転嫁で逃れる事もあるだろうが）
という事が駄目マネージャが少なくない原因ではないだろうか？
加納
「部活のマネージャー」論は、「プロジェクト員に対する姿勢」から入って、結果的に、生産性向上させる施策としての
正しい姿として出てきていると思います。
まず、たしかに「部活のマネージャー」は予算管理しないかもしれませんが、
「プロジェクト員」への姿勢は「部活のマネージャー」であるべきというのは間違っていないかと。予算達成した、という前提であれば
「プロジェクト員」をないがしろにするのと、「プロジェクト員」を大事にするのはどちらが正しいか明らかでしょう。
で、最近はアジャイルなどの影響で「会社のマネジャ」は「部活のマネージャー」になることが、
感情的だけではなく、理論的にも正しいことが明らかになってきたと思ってますが、違うのですかね。
社員を部品とみなすのではなく、一緒に成功する仲間(?)のような感じで扱うアジャイル的な考えであれば、
理論的にも「マネジャー」は「部活のマネージャー」になると思います。
社員を部品とみなす、いわゆるテイラー方式の生産性向上はすでに限界ですので
ほとんどのプロジェクトで、実際にはアジャイル的な考えを取り入れてることでしょう。
なので理論上、「部活のマネージャー」になるのが正しいことになります。
タスクカードなんて、まんま、アジャイル的施策ですね、本来は。
とはいえ、実際には、日本にアジャイル的な考えが根付くとは思えませんが。。。