冷たい方程式（16） ブルックスの法則
11月1日木曜日、雨の午後。
雨って――とても平和な音がする、とか何とかほざいたのは、カポーティの短編の登場人物だったか。あたしは、応接室の窓からぼんやり外を眺めながら、そんなどうでもいいことを考えていた。午前中から降り出した雨は叩きつけるような激しさを増すばかりで、平和な音どころか暴力的なまでの騒音となっている。
応接室にいるのは、渕上マネージャとあたし、それにムツミさんの3人。無言で、ホライゾンシステムの八木社長を待っているところだった。
渕上マネージャは、いつものように無表情でシステム手帳を眺めている。あたしは窓の外の雨を観察している。不安そうなムツミさんは、渕上マネージャとあたしの顔を交互に見ていた。
ムツミさんが不安そうなのは、自社の社長が遅れていることに対する肩身の狭さもあるだろうが、それ以上に、これから何があるのか知らされていないことが大きいのだろう。知っていたら教えてあげたのだが、あいにく渕上マネージャは、あたしに知らせる必要はないと判断したらしく、何も言ってくれなかった。
さらに待つこと数分後、ようやく八木社長が現れた。雨の中を走ってきたらしく、スーツの肩口やズボンの裾がぐしょ濡れだ。正門から屋根のある場所を通ってくると時間がかかるので、濡れるのを承知で最短距離を突っ切ったのだろう。
「どうもすみませんでした。雨で電車が遅れまして」
八木社長はそう謝りながら、ハンカチで顔を拭いつつ、ムツミさんの隣に座った。
「さて、本日は、どのようなご用件でしょうか」
渕上マネージャは、無言で1枚のA3のプリントアウトをテーブルの上に広げた。10月から3カ月分のスケジュール表だった。
「スケジュールの件です」
「はい」
「遅れています」
「はい、そうですね」八木社長はひとまず肯定した。「でも、それは……」
進捗報告や作業日報、その他もろもろ、実装作業以外で時間を費やしているせいだ、と続けたかったのだろうが、渕上マネージャは片手を上げて制した。
「とにかく遅れています。この際、理由はどうでもいい。どうやってこの遅れを取り戻すのか、それだけが重要です」
あたしとムツミさんは、顔を見合わせた。きっと思いは同じだったに違いない。遅れを取り戻すなんて実に簡単。賢者の知恵も必要としない。今現在やってる、下らないマイクロマネジメントを即時中止して、実装に集中させればいい。
そんなあたしたちの心の叫びに気付くはずもなく、渕上マネージャは言葉を続けた。
「今、御社では、何人をこのプロジェクトにアサインされていますか？」
「現在は、片寄以外に3名です」八木社長は答えた。「状況に応じて、あと1名ぐらいはヘルプさせることもありますが……」
「その3名の人たちは専任ですか」
八木社長は、答える前に2秒ほどの沈黙を先行させた。
「……もちろんです」
ムツミさんが動揺したように、メガネの奥で目をキョロキョロさせて、八木社長を、次いであたしを見て、最後にスケジュール表に視線を固定させた。
八木社長が真実を語っていないことを、あたしは知っている。以前のランチのときの世間話で、ホライゾンシステムで実装を行っている3人が、別の業務も掛け持ちしていることを、ムツミさんから聞いたことがあるからだ。
「3名というのは少ないですな」渕上マネージャは厳しい口調で続けた。「もう少し増員していただきたい」
八木社長は乾いた笑い声を上げた。
「いやあ、それはちょっと無理ですわ。うちもそんなに人がいるわけではありませんので」
「それは御社の都合であって、弊社は関係ありません」
――前にも聞いたぞ、そのフレーズ。
「いや、しかし無理ですよ、実際」八木社長は困惑している。「今から増員というのは」
「何とかなりませんか」
「ええ」
「そうですか。それではそれは諦めます」
やけにもの分かりよく引き下がったな、と思っていたら、渕上マネージャは別の要求を突きつけた。
「その代わり、先ほどおっしゃった3名を、弊社に常駐させていただきたい」
八木社長の顔が青ざめた。
おそらく、渕上マネージャは、くだんの3人が専任でないことぐらい、とっくに気付いていたのだと思う。そこでスケジュール遅延を口実に、自分が直接監視できるように常駐を求めたのだ。
「いや、あの、それはちょっと……」
「何か問題でも？」急に滑舌が悪くなった八木社長に、渕上マネージャは冷たい視線を向けた。「現在でも専任でやっているなら、場所が変わるだけ。むしろタイムラグやコミュニケーションラグがなくなり効率も上がると思われますが」
八木社長は沈黙した。気の毒になったあたしは、時間稼ぎのつもりで質問した。
「あの、場所はどうするんですか？」今のところ、ITマネジメント課に、空きデスクはない。
「1月いっぱいまで、ミーティングルームBの占有使用許可を取った。インフラグループには連絡済みだ。現在、PCとLANの設置を行っている。本日中には完了するはずだ」
インフラグループのGLさんと、長時間打ち合わせをしていたと思ったら、このためだったのか。そういう根回しは得意中の得意らしい。
「でも、そうなると」あたしは驚いているムツミさんを見た。「ムツ……片寄さんの負荷が高くなりませんか？」
ホライゾンシステムとの契約は、派遣契約ではないので、追加で常駐する3人のプログラマに、直接指示は――形式上は――できないはずだ。指示はホライゾン側の常駐者を通すことになる。つまりムツミさんは、自分の実装に加えて、指揮下にある3人の面倒も見なくてはいけなくなる。
「やることは今と変わらない。今でも、片寄さんは同じことをやっている。むしろ、コミュニケーションロスがなくなり、時間の短縮になるはずだ」
あたしは八木社長を見た。顔をしかめて、手帳を睨んでいる。渕上マネージャは辛抱強く待っていた。数秒後、八木社長は唸るような声で答えた。
「……やはり、難しいですね」
「難しい理由が分かりませんな。先ほど御社は……」
しばらく渕上マネージャと八木社長の応酬が続いた。八木社長は必死でさまざまな理由を口にしたが、それらに対する渕上マネージャの返答は、「それは御社の都合」という一言に集約できた。
あたしは無益な応酬に聴覚を無駄遣いするのをやめて、それとなくムツミさんを見ていた。気の毒に、やがて自分に降りかかってくる作業内容を考えて、絶望的な気分で話を聞いているのだろう。
やがて、八木社長は俎上に載せるネタがなくなったのか、とうとうこう言った。
「……すぐには決められないので、一度、持ち帰ってよろしいでしょうか」
持ち帰る、というのは、交渉術上の最後のはかない抵抗に過ぎなかったのだろう。渕上マネージャの要請――実質的に要求――を飲まざるを得ないことは、ここにいる全員が承知していたようなものだ。
「構いません」渕上マネージャはあっさり了承した「ただし、回答は今日中にいただきたい。御社にできないのなら、別の協力会社さんと追加契約し、御社にお願いしている機能の一部を肩代わりさせることも考えなければなりませんので」
ただでさえ、安い単価で受注しているというのに、数を減らされては完全に足が出てしまうだろう。八木社長は胃痛の症状に苦しんでいるような表情を浮かべながらうなずいた。
「早急にお返事します」
急ぎ足で帰って行く八木社長を、ムツミさんは暗い顔で見送っていた。
11月5日月曜日。
ホライゾンシステムから、新たな開発要員3名が送り込まれてきた。全員が男性で、年齢はおおよそ20代前半。なかには、ほとんど高校生のような顔の人もいた。スーツに慣れていないらしく、しきりにネクタイの位置を直しているのがほほえましいというか、頼りないというか。ムツミさんが憂うつそうに語ったところによると、全員、自社以外の常駐は、これが初体験だとのこと。あたしは、彼らの若さと、初体験に関する卑猥なジョークを思いついたが、口に出すのはやめておいた。
彼らが初めての常駐作業に、心躍らせていたとしても、渕上マネージャと対面した途端に、そんなものは霧散してしまったにちがいない。
「私は君たちの人間性や学歴や経験などに興味はない」渕上マネージャは冷たく言い放った。「興味があるのは、いかにタスクを予定通りに消化できるのか、その一点だけだ。片寄さんの負担を減らせるように、給料分の仕事をしてもらいたい」
彼らは毒気を抜かれたような顔で、臨時の開発部屋となったミーティングルームへ、ムツミさんの先導によって消えていった。それを見ながら、亀井くんが囁いた。
「なんか、頼りない奴らですね」
――あんたが言うか？
1時間ほど、バージョン管理システムや共有フォルダーなどの説明を受けた後、3名の新メンバーは無事に実装作業を開始したようだ。すでに自社で、実装を行っていたので、イニシャルの教育コストがかからないのは助かる。この点では、渕上マネージャは正しかったわけだ。
戻ってきたムツミさんは、小さくため息をついた。
「どう？」あたしは訊いた。「大丈夫そう？」
「何事もなく続くといいんですけど」
「なになに」あたしは笑った。「そんなに使えない人ばかり連れてきたわけじゃないんでしょう？」
「スキルの問題というか、なんというか……」
ムツミさんは、斜め前の席をちらりと見た。渕上マネージャはたまたま席を外している。それを確認した視線が、タスクボードに向けられた。
「彼ら、こういうやり方で開発したことがないんですよ。まあ、私もそうなんですけど。いつもは、仕様書があればそれを渡して、やっといてね、で済んでしまいます。仕様書がなければ、概要を説明して、分からない部分は聞いてね、で」
「まあ、確かに、この規模の開発で、ここまでのタスク管理は普通やらないよね」
ムツミさんは、またため息をついて、メガネを外すと、クロスで丁寧に拭いた。相変わらず慢性的な睡眠不足らしく、目の下に隈を欠かしたことがないし、日中もカフェインを含む食べ物や飲み物を口にしていることが多い。
「新人くんの場合や、スケジュールがすごくタイトな場合は、タスク管理することもありますけど、ここまで細かい管理は、さすがに……」
ムツミさんは頭を振ってメガネをかけ直すと、モニタに向き直ってソースを開いた。
そのとき、ホライゾンチームの1人で最年少のメンバーが現れると、おそるおそるムツミさんに声をかけた。
「あの、すみません。ちょっといいですか？」
「ああ、はい」
ムツミさんは立ち上がり、臨時開発部屋に行ってしまった。
「大変そうですねえ」亀井くんが同情あふれる声で言った。
ムツミさんは5分ほどで戻ってきたが、入れ替わりに別のメンバーが呼びに来て、席を温める暇もなく立ち上がる羽目になった。
「あれじゃあ、ムツミさん、自分の仕事をやってる時間がなくなっちゃうねえ」
小声でつぶやいたつもりだったが、ちょうど席に戻ってきた渕上マネージャの耳は、その意見を鋭敏にキャッチしたようだ。
「他に方法があるなら聞こう」平板な声だった。「スケジュールの遅延を取り戻すには、人的リソースを投入するしかないのだ」
あたしは思わず首をすくめたが、心の中では舌打ちしていた。
――あれだけマネジメントの本を読んだくせに、人月の神話だけは読み忘れたのか
とはいえ、信念の元に行われているマネジメントを、何十年も前に提唱された言葉1つで覆せるとは思えない。何より時間がもったいない。
あたしは黙って頭を下げると、自分の設計作業に戻った。亀井君も憎々しげに渕上マネージャを睨むと、無言でキーボードに向かった。
ムツミさんは、なかなか戻ってこなかった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
常駐〇貞
常駐童〇ｗ ・・・というか、私もそれに当てはまるわ。
開発者は一応実在したか。でも100％アサインじゃなかったと。
八木社長は「彼らは社内でしか開発しない契約になってる」とか言えばよかったのに。
今回のプロジェクトで彼らをモリシタに常駐させる契約にはなってないだろうから断れたのに。
(まぁ肩代わりをちらつかされてそうせざるを得なかった感じではあるが)
豚
人月の神話キタ━(゜∀゜)━!!
Edosson
読んでて腹が立ってきますねえ。
人的リソースが無尽蔵に投入できるのなら、
そりゃ、マネジメントなんぞ、端から必要ありませんよ。ｗ
ほまらら
この業界の不幸なところは、上位者と上級者がイコールでない事ですね。
渕上先生も、一度でも開発者側でやってたらこんなマネジメントはしないでしょうに。
elseorand
人月の神話やピープルウェアなどの普遍的な名著の古典は、
実際読まれなくなりました。
それどころか存在すら伝わらなくなってしまいました。
40代、50代のマネージャークラスの若い頃からの不勉強が原因ですね。
過去、そういった本に行き着いた出来る人は独立してしまったんですよね。
（会社OBということで臨時でPMを頼む際、許可が下り易いのですが、
実際できるんですよね～）
私は何故か義務教育時代に推薦されて読んだという幸運に恵まれましたが、
こういった古典は大学生には、分からなくても一読させるべき本ですね。
というより40代、50代でこの古典の求めるところを知らない人間は、
消えてもらいたいものです。
通りすがり
MPは仕事を減らすことに腐心して欲しいよね。
読者A
遅れた原因をしっかり見極めて、その結果が人が足りないのであれば
正しいのですが、そうでない場合は人を増やしてもその効率＆コストに
見合わなくなるのは、PM経験があろうとなかろうと誰でも考えればわかる
ことなのですが。そもそも机上ですが人増やしてもその後の進捗が
多少良くなるだけであって、「遅れを取り戻せる」わけないですよね・・・
にもかかわらず現実にはよくあることになっていますね。
ただ一度だけ、PMより上の位置にいる人が非常に優れた方で、
よくあるドキュメント精査・比較をバイトを短期集中で雇って片付ける、
山場の納品日には提出・クローズできたチームはもうその時点で上がって良い等
メンバーのコア業務集中・モチベ向上を苦心なさっていました。
もっとも、その方がくるまではダウンした人間は数知れず、
救急車まで現場に来る始末でしたが・・・
WhiteBall
> 「他に方法があるなら聞こう」
> 「スケジュールの遅延を取り戻すには、人的リソースを投入するしかないのだ」
自分のやり方に一切の非が無いという自信はすごいなぁ。
「人的リソースを投入する『しか』ない」ですからね。
逆に言えば、全ての責任は自分が負うっていう風にも見えるので、ある意味、渕上△！
でも実際、片寄さん配下のメンバーって他案件との並行開発って現実的に可能なんですかね。
1日12時間くらいとして、6時間ずつ違う案件の開発とかしてるんでしょうか。
個人的には複数案件の掛け持ちってできないと思ってるんですが・・・
私の能力が低いだけか・・・
くくな
>>複数案件の掛け持ち
1日は24時間あるので、8時間づつ別の案件をやっても、8時間はプライベートな時間が取れる。
睡眠時間と通勤時間を削れば、さらに2時間づつぐらいは捻出できる。
泥のように働くというのは、そういうことだ。
なんてね。
読者A
曜日分けしてたんじゃないですかね？
もしそうだとすると、そう言っておけば当該曜日だけ常駐するという
話もできたとは思います。
読者Ｂ
ＸＸをやめること以外で、今この時点でＰＭがとるべき行動はなんだろう？
ふっちーLove
もっと会話することだと思う。
プロジェクトに関する思い、目指すゴール、そこまでの見通し、
開発メンバーが知らない社内事情とか。
リラックスできるような馬鹿話ならなおいい。
同業のよしみで欠点には目をつぶって応援するというのが私の立ち位置ですが、
先週の主人公が感じ良かっただけに、
ふっちーも、もう少しやりようがあるだろうって思う。
Edosson
たとえば、１００メートルを走る。
簡単なことです。
しかし、それを３秒でやれ、と
いわれては、話は別です。
そして、３秒でやらなければならない理由は、
渕上氏がリソースを馬鹿食いしているから。
>WhiteBall氏
>逆に言えば、全ての責任は自分が負うっていう風にも見えるので、ある意味、渕上△！
お言葉ですが、渕上氏に、そんな気概があるとは思えません。
自分のマネジメントは完璧、無能な部下が悪い、と主張するとしか
思えないんですが。
>Love氏
とりあえず、私の中では、
Love氏は、キャラ作ってあおってるだけだと認定することにします。
そうすりゃ、腹も立たないし。
PG
＞「給料分の仕事をしてもらいたい」
うん、多分給料分以上の仕事を求めてますよあなた。
発注側から見えるコストとしては安く済ませてる（その手段もなかなかにえげつないですが）みたいですが、それ相応の労働力しか提供されてないのにどこまで求めるんでしょうね。
ちょっとどうかとは思う形ではありますがコストを削った以上どこかでそれに応じたしわ寄せが来る事は考慮しないといけないはずなんですけどね…。
最悪の場合にはそのしわ寄せを全部ホライゾンシステムに押し付ける未来しか見えないなあ。
それでもプロジェクトが破綻しなければ一応成功と言い張れるんでしょうけどね…。
ふっちーLove
>この業界の不幸なところは、上位者と上級者がイコールでない事ですね。
この業界の不幸なところは、上位者と上級者がイコールであることを必要とする点にあると思います。
社用車を購入するとき、ユーザ企業が考えることは資金の手当て、
契約書類の作成、利用ルールの制定、あとは納税や車検の対応など。
車の製造の知識なんて不要だし、まして上級者であることを求められたりしない。
ユーザ企業だって自動車メーカーがどんな手法で工場を管理しているか気にしない。
ところがシステム開発ときたら社用車を導入する責任者が、
工場のラインに乗り込んで仕切りだし、
工場の技術者も負けじと車を買うお客さんに
自動車製造のプロであることを求める。
本来、別々の世界で生きているはずの人たちが
開発プロジェクトという地獄の一つ鍋でいっしょくたに煮られる羽目になるのは、
この業界が製造業としてあまりに未熟だから。
私はそう思っています。
ふっちーLove
>うん、多分給料分以上の仕事を求めてますよあなた。
どの程度が給料分の仕事なのか、ユーザー企業側からは判断できないのよ。
SE・プログラマって、会社どころか人によって全然違う。
ある人ならすぐに出来る仕事でも、別な人にとっては難関。
SE・プログラマの報酬額も知らないし、バランスの取りようがない。
そもそも、こちらにはSE・プログラマーに給料分働いてもらうという発想がない。
払った対価に見合った成果をSIerに納品してもらうという発想。
組織対組織という感覚で、個人レベルの話は
それこそ御社の都合ってもんです。
その辺はSIer側のPMが管理してもらいたいところです。
素人考え
こんなムチャぶりばっかりさせるんだったらホライゾンさんが手を引いちゃえばいいと思う 途中で手を惹かれて困るのは依頼者だろうに
omanuke
関係無いが下にある関連リンクがひどいwww
WhiteBall
>Edossonさん
いえいえ、私は皮肉のつもりだったので＾＾；
徹底的にプロジェクト管理すると、失敗した時に上層部への言い訳が難しくなりそうで、結局、渕上さんのせいにされるのになー、という思いです。
tui
「給料分の仕事」･･･
企業同士の金額って、作業員の給料の２倍～３倍くらい払われてると思ってます。
８＊（２～３）時間働けとおっしゃいますか･･･
>上位者と上級者がイコールであることを必要
職務上必要となったのなら、諦めて努力して下さい。
コミュニケーションが問われる業種で「御社の都合」って（ニュアンスの）言葉が
平然と使われる業界って、終わってる気がします。
BEL
必ずしも、役職上の上位者が技術的に上級である必要はないとは思う。
特に、具体的なプログラミング手法などの細かい点とか最先端の知識とかは。
でも"技術的総合力"とか"技術的判断力"とかそういうスキルは上位である必要があろう。
この業界の不幸なところは
・上流工程にいくほど高級な仕事だと思い込んでる人がいること(上流という言葉がよくない)
・必要なスキルを持たずして、上流工程にいる人がいること
下流は問題ないのかっていうとそうでもないけど、失敗リスクが高いのは依然上流だろうし。
＞関係無いが下にある関連リンクがひどいwww
これは。。ｗｗｗ
PG
＞ふっちーLoveさん
＞そもそも、こちらにはSE・プログラマーに給料分働いてもらうという発想がない。
＞払った対価に見合った成果をSIerに納品してもらうという発想。
それは間違ってないと思いますが、このケースでは払った対価と求められてる成果にかなりの齟齬があるように見受けられますよ。
品質管理も進捗管理も大いに結構ではありますが、完璧を求めたいならそれに応じたコストを支払わなければ人的リソースも時間的リソースも使えませんよ。
ミスを無くして完璧な成果をあげたいというのは誰しもが共通して考えてはいますが、コストが使える人月に比例する以上、どこかで折り合いをつける必要があるでしょう。
「完璧な成果を出す」ことを目的とする以上なかなか文句を言いづらいですが、「現実を見ろ」と言いたくなりますね。
どうもこの人は必要十分「以上」の成果を残させようとしてるように見えますし…。特にドキュメントの類なんかはそうでしょう。
コストは削る、だが成果は削らない（※ただしその負荷は実働部隊に負わせる）ではうまくいくわけがないでしょう。
どこかで不要な部分を削る事を考えなければならないだろうに余計な仕事まで作ってるようにしか見えませんね。
最終的には失敗しても「私は完璧に管理した。スキルや経験が足りない実働部隊が悪い」と言い出すんでしょうけどね。
ソフトウェア開発はモノ作りではない
ふっちーLove氏
> ところがシステム開発ときたら社用車を導入する責任者が、
> 工場のラインに乗り込んで仕切りだし、
> 工場の技術者も負けじと車を買うお客さんに
> 自動車製造のプロであることを求める。
これは、システム開発を自動車製造と同列に考えるというよくある勘違いですね。
ふっちーLove氏には、以下の記事を読んで理解することをお勧めしたいと思います。
ソフトウェア開発はモノ作りではない
http://www.gcd.org/blog/2006/07/91/
ぽんた
まぁ、ソフトウェアの開発プロセスに一般製造業の
手法を取り入れるのも、科学として捉えるのも方法
のバリエーションのひとつであって、どれか、だけ
が正しいわけではないと思います。
まだ産業的に若い分野なので、手法についてはそれ
ぞれの良いとこを組みあわせてこれから洗練されて
いくかと思います。（いや、そう思いたい）
パッケージ製品を導入して業務の方を製品にあわせ
ればワンオフで作らなくてもよい例はいくらでもあ
ると思いますが、（それはそれでSIが困ってしまう
わけですが）
それをしない（できない）のでワンオフになってし
まうのですね。オーダーメイドあれば、少なくても
要求についてはしっかりと伝える必要があると思い
ます。
（その際にハードの動作原理やソフトウェアの用語
を知っているにこしたことはないでしょうが）
また、地獄の一つ鍋でいっしょくたに煮られる羽目
（笑）になるのは、単純に丸投げでは失敗するから
ですね。リスクマネジメント的にもユーザー企業側
のプロジェクトマネージャの方が分が悪いでしょう。
（訴訟になった際に発注側の協力義務違反の責任も
問われるようになった理由もあると思います）
さて、昨今はプロジェクトにはマネジメントのみに
あらず、ファシリテーションも必要だと言われてい
ます。（渕上Ｍも読んでね！）
ぜひ今後の連載ではプロジェクトファシリテーショ
ンも加えたお話を期待します。
最後に、渕上Ｍのあいさつに対しての答えはこうで
しょう。
渕上マネージャ：「片寄さんの負担を減らせるように、
給料分の仕事をしてもらいたい」
3人のプログラマ：「お前もな」
としろう
益々偽装派遣ぶりが酷くなりましたね。
メンバーの通勤含めた条件が酷く、コストも上がるのでと拒否すればいいのに。
そちらの都合と返されるなら、常駐の必要性も拒否できるはず。
人数投入しても無理なのは判っているし、常駐では殆ど残業できない前提なら
自社内のみで、ある程度残業前提に切り替えた方が遥かにマシ。
自分の責任を棚に上げているのだから、一部機能を他社に任せるようにすれば良い。
価格と期間から飛びつく所はまず無いだろう。
最早ダメージが小さいうちにマネージャには失敗して勉強して貰えれば良いと諦めよう。
マネージャの本心はどうであれ、行動がプロジェクトの成功を求めていないので
最大のボトルネックが解消されなければ他の最適化は無駄である。
さて、社用車購入の例のような場合は、既に物があるので
比較するなら既存のパッケージソフトの購入である。
間違った例えを出す程度に論理が出来なければ舵取りは任せられない。
ふっちーLove
まとめてコメントさせてください。
>８＊（２～３）時間働けとおっしゃいますか･･･
言わない。ユーザ企業が求めるのは良くも悪くも求めるのは成果なんです。
>職務上必要となったのなら、諦めて努力して下さい。
その点、ふっちーの努力は素晴らしいと思いませんか？
>どこかで不要な部分を削る事を考えなければならないだろうに余計な仕事まで作ってるようにしか見えませんね。
会社がシステム開発という投資を行う上では
コーディングに直結しないドキュメントも大量に必要になる。
ふっちーが経営陣や利用者部門とやり取りしている様子が分からないと、
過剰かどうか判断が難しいと思う。
>システム開発を自動車製造と同列に考えるというよくある勘違いですね。
言いたかったのはシステム開発において、専門家と素人の垣根が低いということ。たとえが悪かった。
すみませんが、自社ビル建設、建設事務所、設計士、ビル設計といったキーワードで読み替えてください。
>まだ産業的に若い分野なので、手法についてはそれ
>ぞれの良いとこを組みあわせてこれから洗練されて
>いくかと思います。（いや、そう思いたい）
まったく同感です。
>メンバーの通勤含めた条件が酷く、コストも上がるのでと拒否すればいいのに。
ここもまったく同感です。
ホライゾンが拒否すれば契約の見直しなり、
別のSIerを入れるなり次のアクションが取れる。
八木社長も何を期待して待ちに徹しているのやら。
ふっちーLove
ちなみにソフトウェア開発は物作りであれば設計にあたるという話。
私も10年以上前に社内説明に使った気がしますが、
2006年なんて最近のネタでしたっけ。
どんどんボケが進むな。。。
さらに蛇足ですが、私の会社ではみんな「へー」というのですが納得はしてくれませんでした。
高いものは高いということのようです。
としろう
>すみませんが、自社ビル建設、建設事務所、設計士、ビル設計といったキーワード
>で読み替えてください。
私は、自宅を建てるのに値切りまくり、工期も早くしろと大工さんにまくし立てるような行為を
システム開発では平気でしているという事が不思議である。
値切りのせいで、計算結果だけ立派だったり、見た目は問題ないが耐久性に問題があったり、
使い勝手が悪かったり、士気が下がって判りにくい手抜きが発生
という事が無い紙の上だけのような理想状態を信じられる事が信じられない。
ねこ
ホライゾンってSIerというよりソフトハウスでしょう。
ふっちー氏がまとめてレスという技をおぼえたのは残念。
だらだらと何度も思い出したようにレスするのが彼の面白いところだったのに。
ところで何か他のものにたとえようというのはムリなんじゃないかと思いますね。
でもマネージャーというか上に行くほどそうやってモノづくりだから同じとかって
主張をしたがるような気はします。
Edosson
>WhiteBall氏
これは失礼しました。
むむ、もっとロコツにわかりやすい方がありがたい、と要望していいのでしょうか。
私も精進します。
それにしても、手を引けって、簡単に言う人が多いですね。
それができるのなら、下請けいじめなんて、あり得ないでしょう。
これまでのつぎ込んだ経費を丸ごと負担するのと比べたら、
何とかやりきってとるモノをとった方が、
ほかの事業や銀行の融資で埋めなきゃならない穴の大きさも違うと思います。
>アオリの人
>会社がシステム開発という投資を行う上では
>コーディングに直結しないドキュメントも大量に必要になる。
いつからドキュメントだけになったんですか？
渕上氏個人を満足させるためだけの雑事が膨大なリソースを食いつぶし、
開発の進行を現実に妨げている。
この時点で、マネージャーとしては失格です。
渕上氏にとって、プロジェクトの成功は、
あくまでも自分の点数稼ぎのためのダシに過ぎませんからな。
そもそも、そのためにしゃしゃり出てきたんだし。
大手SIer
渕上マネージャーは（法的なところも含めて）色々アレだし、ダメですけど、
今回の失敗をきちんと自覚して対応すれば、まだやり直すチャンスはある気がします。
対して、主人公は発注元のＳＥとしては、自分の行動が根本原因だと気が付かない
「きちんと考えない他責型のＳＥやプロマネ」の典型で、どこかで気が付かないと
「仕事を任せられないＳＥとして扱われる」危険な状態ですねえ。
まともに仕事しない磯貝課長から権限を委譲させられたとはいえ、
１）「人事系のシステムの開発プロジェクトで考慮すべき要件とは何か？」を実行に
移す前にきちんと把握しなかった。
２）プロジェクトオーナーである経営陣や関係部署の意向を確認するチャンスも
「苦手だから」と逃げた。
３）オーナーサイドから求められている管理内容も成果も把握できていないのに、
単に過剰だとか、間違っているとしかいわない。
これでは渕上マネージャーと同じ土俵に立つことは無理ですね。
しかも発注側（加害者）としての、これまでの対応も自分の棚に上げて
「マイクロマネジメントが原因」だと他責に逃げている。
完全に思考停止に陥っていて、さすがにこのままじゃ救う余地ゼロでしょう。
最後に「御社の都合」が飛び交う業界は私も終わっていると思います。
発注元と発注先とは提供する成果を持って契約しているのに、後から金額の多寡を
言い訳に使う様なビジネスを甘く見ている素人がプロを詐称している業界ですからね。
システムの開発ビジネスも、仕事を受けるということがビジネスにおいて
どれだけ重要性を持つかをもっと真剣に見直さないとダメだと思いますよ。
過去に、顧客から「御社の都合」と突き放された案件でプロマネやＳＥの尻拭いで、
先方と本音ベースでの会話をさせてもらった時に「今回ご説明いただいた内容を、
最初からお伝えいただきたかったです。やはり、今までご対応されていた○○さんは、
我々がどうやって皆さんにお支払している費用を稼いでいるかご存じないのでしょうね。
我々はシステムを開発しているわけではありませんが、お客様に製品やサービスを
提供する際に、「あの時は」や「想定外」を口にしない様、真剣にお客様と向き合って
仕事をしている認識です。」とのような内容をほぼ確実に言われ続けてきましたよ。
AC
大手SIer氏
＞「マイクロマネジメントが原因」だと他責に逃げている。
いや他責もなにも事実それが原因だし。責任は責任者にあるものだし。
しかしうわすげえ。
SIerだとこれが原因じゃないと言えば、責任者は責任逃れができるんですか？
この人の会社は、さぞや中身が腐ってるんだろうなあ。
＞今回の失敗をきちんと自覚して対応すれば、まだやり直すチャンスはある気がします。
いやこれはハッキリいって無理だと思う。
あまりに無能すぎるから。
何をどうしていいか自分で判断する能力が、この御仁には全く無いのです。問題集を暗記するだけの「お勉強」はできるけど、答のない問題に対する「問題解決」ができないタイプの人。ルーチンワークではそこそこ有能かもしれないけれど、時代や顧客の要望、技術の変化に対して臨機応変な対応を求められる技術系のマネージャーとしては極めて無能なのです。
＞これでは渕上マネージャーと同じ土俵に立つことは無理ですね。
誰もそんなものを希望しないんじゃない？
あんな無能な御仁と同じ土俵に立つなんて、そこまで自分を貶められる人ってよっぽどのマゾだとしか。
渕上マネージャーはプログラマでもなければ開発者でもない。
もちろんマネージャーでもないし、顧客でもない。
何にもなれないし、なろうともしてない。
＞先方と本音ベースでの会話をさせてもらった時に
ハッキリ言わせてもらうけど、あんたみたいな人間相手に、仕事では絶対に本音はしゃべらないよ。ホントのことを言ったが最後、逆ギレされるのが目に見えてるからね。「本音ベースで会話します」というのはあくまで建前。
Edosson
１）シフト管理機能(No.12)のことなら、把握はしていたでしょう。
だいたい、システムを丸ごと一新するような案件の場合、
開発負荷の高いパートは後回しにするのに、不思議はありません。
しかも、置換ならともかく、新規開発。
おまけに、インフラそのものすら、現時点で影も形もない。
だいたいインフラの整備なんて、全社的事業として取り組むべき課題ですよ。
２）勤怠管理システムは、労働契約を忠実になぞることに
過ぎないんですから、それの仕様なんて、上意下達で十分でしょう。
３）これって、オーナーサイドというよりも、渕上氏個人でしょ。ｗ
他人の手でリプレースされては、自分の汚名が確定するってんで、
しゃしゃり出てきただけだし。
渕上氏さえいなければ、相応のモノができていたでしょう。
SIer氏の投稿を見て、改めて思いましたが、、
渕上氏擁護派の方々は、ストーリーに書いてもいないことを持ち出して、
渕上氏擁護と開発者批判をしています。
これでは、話はかみ合わないでしょう。
だいたい、渕上氏批判派の人たちにしたって、
渕上氏が指摘していることを、正面から間違っている、
といっている人は、一人もいません。
問題は最初から、渕上氏が、
個人的な満足を満たすための雑事に、
開発を圧迫するほど、リソースを食いつぶしていることです。
この件については、何人もの人たちが、
繰り返し繰り返し指摘していますが、
まともな反論はひとつもありません。
へろへろ
渕上氏に対して「次があれば～」という意見があるけれど、
1)もともと役員になる予定だったから、固有の部署や部下はない。
2)会社業務の大きなレベルでITを専門にしていることにはなっているけれど、
システムレベルまでブレイクダウンしていくとERPと勤怠しかない。
3)この状態で今回の勤怠システムのリプレースに失敗すると、残りはERPしか
ないのだが、保守・運用中のシステムに必要な人材ではない。
という有様。これは、もっと上の人でも「次」を考えるのに頭を抱えるのでは
ないだろうか。
失敗による損害状況にもよるだろうけど、
・都合よく転がっていた大型案件に滑り込み、今度こそ実力を発揮する。
・部長ぐらいの扱いで地方の別部署に飛ばされる。
・新天地を求め、再度転職。
・社内政治の結果、情シス部門に居座ることに。
という感じか。どれがHappy EndでどれがBad Endなのかはわからないけど。
ここまでで、素朴な疑問があるんだけど・・・
主人公たちは、サービス残業しているじゃないですか。
これって、マネージ側の人達からみるとー
「勝手にやってることで迷惑」であり、「無能だからそんなことになる」ってな感じですかね？
いや、渕上マネージャは知らないことでしょうから、彼は置いておいてー
これ読んでるマネージ側の人達はどう考えてるのかなと。
プログラマ側の人達からみると、「無茶なスケジュール」ってな意見が多そうですね。
実際、コメントでもそんな感じですし。
個人的には、サービス残業が発生している時点でマネージメントは失敗だと思うんですよねぇ。
それとも、「経費節減で、すばらしいマネージメント」という成功なんですかね？
お互いが信頼し合える間にならない限り、うまくいくわけないですねぇ。
渕上マネージャは自分の指示にしたがう駒が欲しいわけで、その駒があればスケジュール通りに
完成するはずだと信じているわけですよね。
まぁ、現状だと、その駒は渕上マネージャが期待している能力を持っていないということでしょうが。
そう判断したから、人を増やして対応している、すばらしい！
理詰めで、八木社長と交渉できていて、すばらしい！
・・・下請けは辛いですねぇ。
まぁ、マネージャーがいるってことは、納期遅れの責任は全てマネージャーが被るんですかね？
プログラマがヘッポコだとしても、そのヘッポコをつかってどうやりくりするかがマネージメントでしょうし。
ヘッポコ過ぎて駄目なら駄目という決断を下せなかった時点でアウト・・・かな？
としろう
大手SIerさんはどうしてそこまで渕上マネージャーの方の肩を持つのだろう。
主人公などの残念な所はあるが、それを直そうとされていない状態で駄目出し。
向き不向きや個人の特性を考えて適材適所で仕事を回すのが会社の人事・課長の仕事。
主人公が出来るSEになれないまでも、出来るPGにでもなれればよい。
兎に角、出来る事をやらせ、能力にあった給料を払うだけの事。
全員が出来るSEである必要も無いし、それはそれで単価が高くなるだけ。
主人公の仕事で大きなダメージは出ない。
会社としてダメージがでかいのは渕上マネージャーの方。
プロジェクトだけでなく、他社を巻き込み、偽装派遣で会社本体にも迷惑をかけかねない。
また、下からの聞く耳を持たないブレーキの無い暴走車
大手SIerさんの望む形にしていくには
・磯貝課長の更迭
・主人公を雇う事にした人事に真意を問い、場合によって人事も更迭
・主人公の変わりにリーダーとして出来るSEを雇う
・主人公を出来るSEの下に付ける
とすればいいのではないか？
主人公より課長や人事を責めるべきかと。
みゃな
非IT系で、いわゆるエンドユーザな立場しか経験ないですが…
話が進むにつれて、だんだんと近視眼的な進め方になっているように思います。
「納期に間に合わない→とにかく人員を増やさなきゃ」というあたりが特に顕著。
これだと、とにかく期限に間に合わせることだけが目標になりがちで、本来優先すべき顧客（ユーザ）の求める機能の質とか使い勝手など、もっとも重要な部分がおざなりにされてしまいそうな懸念を覚えます。
いったい何のためのマネジメントなんだったっけ？ な状態。
「そんなもんわかってるよ！」な意見の方々には申し訳ありません。
でも、ITに明るくないユーザ側の見方としては、ドキュメントが詳細なことよりも、マネジメントの巧拙よりも、実際に納品されたシステムがきちんと自分たちの要望した通りに動いてくれているかの方が重要事項なのです。
※ドキュメント作成やマネジメントそのものが無意味という意味ではありません。
今回のケースはほかの方々も書かれているように、ドキュメントやマネジメントが細かすぎて、肝心の開発に時間を取れていないのが最大の問題だと思います。
各リソースのバランスが悪すぎる。
そして、そういう目で見ると、この勤怠管理システムが、果たしてユーザの望む通りの質で完成するのか、（ユーザ側から見ると）非常に不安です。
一応自分も技術系の分野に属していますが、渕上氏のように、現場のモチベーションをへし折りつつ肝心の実作業の妨害をする人が上に立つと嫌われます。
大手SIer
まとめてコメントします。
１）渕上氏と主人公に対する評価
渕上氏を擁護はしていません。
過去に渕上氏はビジネス（マネージメント含む）においてダメだと切り捨てており、
現時点でもその評価は変わっていません。
主人公は、仕事への取り組み方というヒューマンスキルの欠如という点で、ダメの
程度が違うと書いているだけです。
私もマイクロマネジメントには否定ですけど、今回のコラムの主人公の様に
「マイクロマネジメントが遅延のすべてである」ような発想には正直ついていけません。
自分がまいた種もあるでしょうに、いつまでも当事者意識に欠けたままですから、
渕上氏がプロマネとして、責任があるかということとは別の問題。
なお、渕上氏は読む限り発注先の選定以外は責任を取る必要があると思いますよ。
手駒の能力に不足があったり、ＱＣＤが崩壊していれば、プロジェクトオーナーと
折衝して、最終的なゴールを含めて落とし所を決めるのがプロマネの仕事ですけど、
それをやっているように見えませんからね。
２）コラムの記載内容について
私はコラムに書いていないことは書いていません。
コラム自体が支離滅裂なところもありますが、書いていないことが書いてあるように
見えるのは、プロジェクトオーナーと接してきたか等の経験の差ではないですか。
例えば、プロジェクトオーナーの意向の話だと、成果物などプロジェクトオーナーの
意向がキーとなる状態で、それを持っている可能性のある上役と戦うに際して、手ぶらで
戦おうとしているから、「同じ土俵に立てていない」と評しています。
渕上氏が知っているとは書いてませんし、一般に社内的に優位な立場にある上役を
制するには、情報が不足している。また、そのためのチャンスを自ら逸していると書いて
あるだけです。
３）顧客との関係
本音を引き出すのもプロマネの仕事でしょう。正直、キレるとかありえませんね。
むしろ、私は仕事をきっかけに、プライベートでも顧客と付き合いがあるため、
「結果的に色々助かっているのでプライベートには口を出さないけど、業務中は
一応公私の区別を付けるように」と指導を受けるぐらいですよ。
ふっちーLove
> 私は、自宅を建てるのに値切りまくり、工期も早くしろと大工さんにまくし立てるような行為を
> システム開発では平気でしているという事が不思議である。
不幸にしてユーザー企業はSE・プログラマの腕を信じられなくなっているのよ。
システム開発の成功率が3割程度という話はユーザー企業に流布しているし、正直な話、私も自社システムの障害報告書を見ていると素人と大差ないと思うことがしばしば。システム開発は投資か投機かというレベルなら、まるっと専門家にお任せとはいかない。
また、モチベーションの話もユーザー企業側では論外。
気分で仕事の出来が変わるなんて、それでもプロかって話。
少し話がずれますが、ウォール街の都合で情報システムの監査が厳しくなり、システム障害で社長の首が飛ぶような時代になりました。
いやおうなしに経営層の不安は増大する。つまり、ますます現場に対する徹底した管理が求められる。
現場のマネージャーの考えとは無関係の世の流れってやつです。
>主人公より課長や人事を責めるべきかと。
同感です。
いままでの流れからすると私が言うのは変ですが、
主人公はSE・プログラマの気持ちが分かるマネージャーになりうる人材。
それが現状はデスマ育ちのお局さま。磯貝課長の罪は重い。
ふっちーLove
なぜ、SE・プログラマの一部の人がふっちーばかり非難するか不思議です。
SE・プログラマならホライゾンの八木社長にこそ腹が立ちませんか？
SIerは普通ならユーザー企業の事情を聴き、自社の事情は話さないものです。
ホライゾン八木社長ならふっちーに対し
「御社からいただきました今回の案件の進め方について、
渕上マネージャーのご存念をお聞かせください。」と投げかけて、
あとはふっちーが何を言っても仰せ御尤もでメモを取ります。自社の事情は話さない。
ふっちーが現状に対し抱く苛立ちが何であれ、それは正当なものだと認めてあげて、苛立ちを解消するプランを提案する。
ふっちーはコストカッターと異名をとるが必要な投資は行うと言って、わずか1週間で本当に予算を取ってくる政治力の持ち主。
そして、どうしてもこの開発を成功させたい理由があるらしい。
はっきりいってふっちーはカモです。そのカモ一羽しとめればいい。最初の契約でダンピングした分なんか、すぐに取り返せるでしょう。
それが八木社長ときたら「それは御社の都合」の一言ですごすご帰ってくる。
ユーザー企業のマネージャーが責任を負うのは自分の会社に対してのみ。
そんな相手にSIer側の事情を並べても相手にされないのが当然です。
この業界にある程度長くいるくせに、そんなことすら知らないらしい。
ホライゾンは本来なら孫請け、曾孫請けのソフトハウスというか人材派遣業。
それが幸運にも元請けに納まった(なんと大手のエースシステムエンジニアリングと同等のポジション！）。
なら大手並みの金を取りに行かないでどうする。せっかくの幸運を生かせず、社員のがんばりも売り上げ増という結果に結びつけることが出来ない。
SE・プログラマの人ならムツミさんの雇用主である八木社長に対し腹が立ちませんか？
ふっちーLove
「もう少し増員していただきたい。」
「分かりました。追加契約の草案と見積書を作成しますので、詳細をお聞かせください。」
これが普通だろ。
Edosson
・・・。
いったい、何を読んでいるんでしょうね。
そこで終わっちゃ意味ないでしょう。
八木社長が丁々発止のやりとりを展開して、
渕上氏から、がっぽりカネをふんだくるまで、きっちり書いてくださいよ。
正しくはこうですな。
「もう少し増員していただきたい。」
「御社の都合で必要なら、当然やるべきでしょう。ご自由にどうぞ。
コスト？ これ以上かかるというのなら、他社に依頼するまでのことです」
「・・・」
>なぜ、SE・プログラマの一部の人がふっちーばかり非難するか不思議です。
渕上氏みたいな穀潰しの肩を持つことができる方が、不思議で仕方が無いですよ。
あおるの、うまいですねえ・・・。
私、とてもとてもLove氏には歯が立ちません。orz
Edosson
ひとつ書き忘れた。
いくら予算を取ってきたって、渕上氏が食い散らかしますから、
その分を割り引かなきゃなりません。
その時点で、リソース不足に陥ることが確定するのです。
さそうたける
自分もシステム開発社の端くれとして、渕上さんのやり方はマネージャーとしておかしいと考えている一人ですが、
この連載を見ててふと疑問に思ったのが、
「この連載はSE・プログラマー vs マネージャーの話になっているが、システム利用者であるエンドユーザーは、果たしてどちらを評価するのだろう？」
という事。
エンドユーザーが評価する際のポイントは、
「どちらの方が、よりユーザーの要望を実現するよう動いてくれたか？」
という点なのですが、この評価をする上で最も参考になるエピソードが「冷たい方程式（14） 過去の影」における「希望シフトのエントリ機能」の件です。
希望シフトのエントリ機能の実装について、主人公は解決すべき課題の多さに開発を断念しているのに対して、
渕上さんは解決すべき課題をクリアして実現への道筋を立てています。
果たしてエンドユーザーはどちらを支持するだろう？と考えると、
恐らくは渕上さんを選ぶのではないかと。
確かに主人公には渕上さんほどの権限が無いので、主人公が断念した事情も理解できますが、
「必須機能ではない」
という主人公の発言は正直残念でなりません。
これは、ユーザー側に負担を強いる結果に繋がる事を良しとする、という発言であり、
エンドユーザーの目線に立てていない事を意味します。
また、機能削減によるユーザー側の負担増加は往々にして運用コスト増加に繋がるわけで、
トータルコストの点でも看過できないかと。
自分は「システムはエンドユーザーのためにある」と思っています。
エンドユーザーのためとは、エンドユーザーの業務が楽になることであり、コストが削減されて利益を多くできることでもあります。
渕上さんは「システムはエンドユーザーのためにある」を理解している人だと見受けられます。
過去の連載に登場した、時代錯誤で不勉強な老害技術者や、
口先だけの上級SEのようなエンドユーザーの事を考えない輩と違い、
渕上さんはシステム開発に携わる者として、尊敬に値する人物だと考えます。
それ故に、渕上さんのマネージメントにおける間違った数々のやり方は残念であり、
さらなる経験と研鑽を積んでいただきたいと思うわけです。
へろへろ
みゃなさんの
>実際に納品されたシステムがきちんと自分たちの要望した通りに動いてくれているかの方が重要事項なのです。
と、さそうたけるさんの
>「どちらの方が、よりユーザーの要望を実現するよう動いてくれたか？」
どちらが本当のエンドユーザーの見方なんでしょう？
確かに、ユーザーの希望に対して「はい、やります」といった上で予算を確保したとき、渕上氏は「親切な専門家」に見えるでしょう。
ですが、実際開発を行うにあたっては、増やした仕事分のリソースを確保してないだけでなく、スケジュールも動かしていない。
第16回の顛末からすれば、シフト管理機能どころか、リプレース部分も稼動が怪しくなってきました。
そして、システムがユーザーの望む形で最終的に稼動しなかった場合、さそうさんタイプの
ユーザーが「まあ、しょうがないよね」で済ませてくれるのであればよいのですが、
実際はみゃなさんタイプのユーザーが厳しく追求してくることが多いのではないでしょうか。
そして、そのときの渕上氏は「親切な専門家」ではなく、「安請け合いをした詐欺師」と見られるのではないでしょうか。
へろへろ
（書きもれた）
結局、「ユーザーのために」（そうでない可能性が濃厚ですが）働いていたとしても、最終的にはユーザーを害する働きしかしないのであれば、
どれほど努力していてもその人物は尊敬に値しないと思うのです。
miww
渕上さんのダメなところは、後出しジャンケン多すぎってこと。
「当然このくらいはやる想定だよな」の一言でなんとかなると思ってるんだね。
ならねーよ。
ほまらら
>また、モチベーションの話もユーザー企業側では論外。
>気分で仕事の出来が変わるなんて、それでもプロかって話。
変わるに決まってるでしょうが。
最低限の品質を満たすかどうかは気分では変わりませんが、
最高の品質まで高められるかどうかは、メンバー一人一人の気分が不可欠な領域なんですよ。
従業員を粗末に扱う旅館で、最高のおもてなしが期待できると思います？
メンバーのメンタルがボロボロでも最高の仕事ができるなんて思ってるなら管理職なんてやめちまえって話です。
ねこ
>メンバーのメンタルがボロボロでも最高の仕事ができるなんて思ってる
そう思ってる管理職って多いと思います。
「プロ」なら当たり前だろうって。
恫喝を警戒して匿名
「『要件定義での失敗』を挽回する責任は誰に帰属するのか?」
この問いに対する回答の違いが、各位の認識違いを生む原因だと考えています。
# 「失敗の責任」ではなく「挽回する責任」である点がミソです。
主人公 = 要件定義を失敗した張本人、にあると考える方々は主人公を叩き
渕上マネージャにあると考える方々は渕上マネージャを叩く。
私は後者です。
「真に的確な要件定義を行うことなんて、そう簡単にできるものではない。」
この前提故に、組織としてフォローするための仕組みとして
プロジェクトマネージャの存在意義がある、と私は考えています。
今回要件定義を失敗した主人公は、「三人の石工byドラッカー」で言うところの
1or2人目であることは承知しています。ですがそれを本人に気付かせ
3人目に押し上げることこそ、世のプロジェクトマネージャに私が期待していることなのです。
主人公を良い方向に導けない点も含めて、渕上マネージャの権限・責任の範疇と考えます。
# とうとうドラッカーネタを使ってしまった…
「そんなの作業者の甘え。自力で気付けない奴は切るだけ。」という考え方も
あるでしょう。ですがそれでは組織で動く必然性が感じられません。
第一その反論は「真に的確な要件定義を行える人材」を「それに見合う報酬」で
雇っている場合にしか成立しません。そうでないなら企業が社員に対し
「元々できるわけでもないこと」を「ノーギャラで」「勝手に期待or強要」
しているだけのことに過ぎません。
「それが出来る人→すごい社員」は真ですが、
「それが出来ない人→ダメ社員」は成立しないのです。
まして強要するようでは、一体どこのブラック企業・社畜論理かと。
# 渕上マネージャは機能追加盛りこんでフォローしたじゃないか、との
# ご指摘あるかもですが、本人が解決したのは予算問題だけで
# スケジュールに関しては主人公らに丸投げですからねぇ。
# ある意味自身の得意分野だけしか責任を果たしてないかと。
としろう
色々返答です
>「マイクロマネジメントが遅延のすべてである」ような発想には正直ついていけません。
個人的には渕上氏が来なければ、「希望シフトのエントリ機能」は別にして
ほぼ遅延無く完成したであろうと思っています。
課長のマネージメントで渕上氏とは別の意味で問題発生の可能性がありますが。
>私も自社システムの障害報告書を見ていると素人と大差ないと思うことがしばしば。
・「お客様は神様」をかざし無茶な要求や後出し追加ばかりする顧客
・空洞化し、偽マネジメントする大手SI企業
・人月で稼ぐ下請け
・使い捨て扱いされる兵隊の為、士気と能力低下の開発者
などのように実際の開発者が幸せになれない構造を作ってきた事の結果。
顧客企業にも大きな責任が有るのです。
それを主人公レベルの開発者に責任を求めるなどオカシイ。
営業や開発者を雇い育成し、仕事割り振る人間にそれ以上の責任がある。
>渕上さんは解決すべき課題をクリアして実現への道筋を立てています。
エンドユーザには判り難いかもしれないが
大本営がたてたインパール作戦のような、机上の空論の道筋では意味が無い。
主人公も作らないとは言わず、後回しで良いと考えていた。
理想ではユーザに確認すべきなのは確かだが訊けば深く考えずに「直ぐやって」と言うだろう。
お願いする事や希望を述べる事は幾らでも出来るからね。
オプションのナビの遅延のせいで納車が1ヶ月遅れますとか良いの？
ナビなしで納車して後で付けても良いでしょう。
車なら車の品質はまず変わらず納期遅れで済むけれど。
開発の場合は、車で言えば品質や性能まで影響を受けるのに。
こういう現実をユーザは理解しないで無理を言うだけで無駄な時間浪費と関係悪化。
よって「やぶへび」を避ける為、訊くタイミングも戦略的に重要だ。
>「必須機能ではない」
>という主人公の発言は正直残念でなりません。
大多数の方が使う必須機能の品質と性能が、
「一部の人が使うあったら便利機能」の同時開発で悪影響が心配される場合などは
「誠実な開発者」と見る事も出来ますが。
ふっちーLove
だからふっちーに期待しすぎだって。
ふっちーはインフラグループと打ち合わせて、彼らに動いてもらおうとしているでしょ。つまり開発プロジェクトの範囲内にしか彼の権限は及ばないのよ。
マネージャーといってもただの中間管理職。自分の裁量で動かせるのはわずか。
与えられた立ち位置で、周りからかせられた条件の中で、
自分に出来ることを精一杯やっているという点で、
マネージャーはSE・プログラマと何にも変わらない。
>も、最終的にはユーザーを害する働きしかしないのであれば、
>どれほど努力していてもその人物は尊敬に値しないと思うのです。
私はその人物が仕事に誠実に取り組んでいたら、それだけで十分尊敬できると思う。だってさ、プログラムがバクっててユーザーに迷惑をかけたら、そのプログラマがそこまで積み上げてきた努力に敬意を払わないということじゃない。この業界でこの基準は厳しすぎる。
それに、この物語は自分中心の半径１０ｍの範囲しか見ていない主人公の視点で書かれていますから、エンドユーザーを持ち出したら永遠にふっちー式管理の評価ができない恐れが。。。
ふっちーLove
まあ、あえてエンドユーザ視点でいうなら、
現行システムと同等の機能は出来ていて当たり前。
追加機能がないんならわざわざ再構築する必要なし。
利用者部門期待の機能を後回しで開発するということを、しっかり利用者部門と調整していないのであれば、後々大問題になるのは確実。
で、プロジェクトの責任者であるふっちーは知らなかったようですから、当然、正式な組織間の合意には至っていなかったのでしょう。
利用者部門としては開発プロジェクトに不信感を持たざるを得ない。
ここであえて利用者部門を説得しろ！というのがSE・プログラマの意見かもしれないけど、まず無理。出来ない理由の説明をガンガン求められてさらに窮地に追い込まれる。
もう、ふっちーに出来るのは「やります。ただし、、」という条件闘争ぐらい。そう、頼りにならない外注さんとお局さまを抱えて、みなさんが言うように現行並みの機能の実装も危うい状況で。
主人公が「あれは今回の開発では中止にしました」としれっと言ったときにブチ切れなかったふっちーの精神力には感心する。
傍観者1
私はふっちーLove氏の打たれづよさのほうに感心するよ。
書くのをやめるといってすぐにもどってきたり、書くな！と書かれてチラシの裏に・・・って一度書いてまた復活したり。
これだけ精神的にずぶとければ、どんな修羅場もだいじょうぶなんじゃないかと。
Edosson
>だからふっちーに期待しすぎだって。
渕上ネズミに、そんな立派な仕事、誰も期待してませんよ。
余計なことすんな、おとなしく黙ってろ、つってんですよ。
クラウゼヴィッツのいう、「無能な勤勉者」というやつですね。
>ここであえて利用者部門を説得しろ！というのがSE・プログラマの意見かもしれないけど、まず無理。出来ない理由の説明をガンガン求められてさらに窮地に追い込まれる。
下請け社長さんに、そのくらいやれ、って発破かけた内容そのままじゃないんですか？
渕上ネズミには免除？
ずいぶんなダブルスタンダードですね。
>現行システムと同等の機能は出来ていて当たり前。
>追加機能がないんならわざわざ再構築する必要なし。
社員全員が、月イチで使わなければならないのに、使い勝手が悪い、
ってんですから、再構築だけでも、十分に必要性はありますよ。
再構築そのものが現場からの要請だということをお忘れ無く。
>それに、この物語は自分中心の半径１０ｍの範囲しか見ていない＊＊＊の視点で書かれていますから
渕上ネズミのことを、この上なく的確に表現しています。
さすがはLove氏！
通りすがお
>私はその人物が仕事に誠実に取り組んでいたら、それだけで十分尊敬できると思う。
尊敬するのは個人の自由ですが、評価はしないでくださいね。
>永遠にふっちー式管理の評価ができない恐れが。。。
頑張ったんだから失敗してもいいじゃないか、という考えは学生で卒業してください。
>利用者部門期待の機能を後回しで開発するということを、しっかり利用者部門と
>調整していないのであれば、後々大問題になるのは確実。
このような描写がこれまでありましたか？
>で、プロジェクトの責任者であるふっちーは知らなかったようですから、
>当然、正式な組織間の合意には至っていなかったのでしょう。
これは完全にふっちーLove氏の想像（というか妄想）ですよね？
渕上氏は旧システム構築時の責任者だったから旧システムには詳しいという
設定ですが、新システム構築には後から参加したので、新システムの内容や
そこに至った経緯に関しては主人公達以上に詳しいとは思えません。
だからこそ、何故機能を削ったのか主人公に確認したのですよね。
つまり、渕上氏が知らなかったから正式な合意に至っていなかった
と結論付けるのは無理があると思います。
むしろ渕上氏は知らない方が自然、とすら言っていいかもしれません。
私は物語を下記のように読みましたがどうでしょうか？（私の妄想も入っていますが）
・希望シフトのエントリ機能は要件定義の段階で機能から外した。
・それもかなり早い段階で外したところを見ると、ユーザに対しても
（当面は）実現不可能なことを伝え、機能から外すことに合意していた。
・だからこそ渕上氏は機能一覧にないエントリ機能のことを知らなかった。
・ユーザが「あの機能があったらよかったのにな～」と世間話をしていた。
・それを聞いた渕上氏が自分の功名心のために無理矢理機能を復活させた。
つまり
>ここであえて利用者部門を説得しろ！
ということを頑張って主人公達がやったのに、渕上氏が全てご破算にしてしまった
というわけですね。渕上氏が「やれ」としれっと言ったときにブチ切れなかった
主人公の精神力には感心します。
蛇足ですが、「功名心」と書いていますが、あまり悪い意味では書いていません。
それまでマネジメント理論を振りかざす頑固なだけのマネージャだった渕上氏が
「功名心」を見せたことによって人間くさいキャラになった・・・というのが
「冷たい方程式（14） 過去の影」の話しであり、渕上氏の魅力となる要素だと
思うのです。（あくまでキャラとしての魅力、ですが・・・）
みゃな
「ユーザがシステムに求めているのは何か」という話になりつつあるので、ユーザ視点で書いてみます。
ユーザが新システムに期待するのは、大きく分けて
・今までのシステムの使い勝手や不具合を修正して、使いやすいものであること
・ユーザが要望した、新しい機能が盛り込まれていること
があると思います。
もちろんこれら全てが揃っているのが望ましいのですが、敢えて優先順位を付けるならば、「使い勝手＞新機能」になると思います。
新しい機能はユーザがまだ見ていない（実際に使ってみないと評価出来ない）のに対し、使いにくいシステムは毎日接するものであるが故に、シビアに見られがちです。
ユーザの期待というのは、追加機能の要望だけではなくて、普段使っていて「メニュー画面見づらい…」「ここ直してほしいのに…」というものの修正も含まれます。というかむしろこちらの方が多かったりします。
そもそも現システムが、
>経理課長がヒステリー性の発作を起こしかけたほどの開発費用をかけたわりに、納品されたのは、使いづらく、遅く、拡張性に乏しいという三重苦のシステムだったそうだ。
という話なので、尚更使い勝手の向上を期待するでしょう。
でも、今回の話の中で、渕上マネージャが気にかけているのは、シフト管理機能などの新機能ばかりで、
・現システムの問題点は何で、どこを修正すべきか
・使い勝手をよくするにはどのようにすべきか
の話が全くと言っていいほど出ていないのが気になりました。
誤解を恐れずに言うなら、目玉コンテンツ（新機能）の実装にばかり目が向いていて、ユーザが使いやすいかどうか、といった基本部分は軽視されているのではという危惧を覚えます。
ここまでの話を端的に言うと、
「システムそのものがきちんと問題なく動いているという前提で、新機能の意味がある（評価されやすい）」
のだと思います。
大元がおろそかになっていると、幾ら「新しい機能便利でしょ？」と言ってみたところで、「ふぅん、でもこれ（≠新機能）使いにくいの。直して」になってしまいます。
ましてや、現状では開発そのものが予定通り進んでいないのですから、まずは大元のシステムをきちんと作る方が先だと思います。
追加機能の搭載は後からでもいいでしょう。
ふっちーLove
>私はふっちーLove氏の打たれづよさのほうに感心するよ。
ありがとうございます。
私もこの仕事をしていてだいぶ面の皮が厚くなった気がします。
それじゃ最近覚えた新技、まとめてコメントで。
>むしろ渕上氏は知らない方が自然、とすら言っていいかもしれません。
着任時にドキュメントの確認を一通りしていますので、着任前に決まっていたのであればその時点で了解したはず。もしプロジェクトスコープに関する部分がドキュメント化されていなければ問いただしたはずでやはり、着任時に認識したでしょう。
あのタイミングで聞いたということは当初のドキュメントと現状にずれが生じていたからと読みました。
議事録なり基本計画書なりのドキュメントで確認できなければただの口約束で、組織間の合意と見るには不十分というのは合意いただけますよね。
主人公へのフォローを試みるなら、この辺の実装以外の「雑用」は磯貝課長の担当で、彼がしっかりすべきだったという事になるでしょうか。
>みゃなさんへ
合理的でかつ関係者への配慮が行き届いた素晴らしい意見だと思います。
たぶん、主人公も貴方のように話の分かる利用者部門の担当者と話して見送りを決めたのでしょう。惜しいのはその後の偉い人への説明とかスタンプラリーの必要性に気が付かなかったことです。
みゃなさんがシステム開発に関わるようになれば実感すると思いますが、利用者部門にとってもシステム開発というのは大変なものなんです。
まずシステムが必要であることを上に説明して開発実施の了解を取り付けないといけない。新しい仕事のためならともかく、すでにあるシステムならなお大変です。何とか説得したら、自社の売り上げとにらめっこして費用が出せるタイミングを計る。それでようやく開発に着手しても情シスまかせとはいかない。要件定義やらテストやらで時間をとられます。本業もおろそかにできません。利用部門の負担はとても大きいものです。
利用者部門の担当者の気持ちは早く終わって！となりますが、
組織としての意思は、こんなに苦労したんだからもっと見返りを！となります。
つまりね、組織間の合意形成ってのは一筋縄でいくものではないという話です。
まあ、うちの会社の話ですがね。
くくな
このコラムと同じ日に、日経ビジネスオンラインで、
「システムが止まる日 仕事がうまくいかない理由の一考察」という
タイトルで、同じような問題の記事がアップされている。
http://business.nikkeibp.co.jp/article/report/20120427/231470/?P=1
偶然？
それとも、作者と何か関係あるとか？
傍観者1
「無能な勤勉者」ってゼークトですよね（実際には彼が言ったのではないようですけど・・・）。軍隊とシステム作りはちょっと違うかもしれませんが、他を巻き込む「無能な勤勉者」は確かにすごい迷惑な存在だと思います。
ふっちー氏は都度オールレスつけてこそふっちー氏だと思います。
まとめてなんてつまんないですよ。
（普通ここまで書くなら自分のブログでトラックバックしてとかやりますよね）
なんとなく
ふっちーLoveさんの会社ってなんだか居心地悪そうに思うのは私だけ？
> 議事録なり基本計画書なりのドキュメントで確認できなければただの口約束で、組織間の合意と見るには不十分というのは合意いただけますよね。
社内案件でこんなことしなきゃならないってのは、
常に責任の擦り付け合いが行われてる企業文化にちなんでるとしか思えないんだが・・・
”信頼関係があれば”口約束で十分だと私は思いますよ
社外であろうと社内であろうとね
なんとなく
ふっちーLoveさんへ
> だからふっちーに期待しすぎだって。
ちがうのよ。期待したいのが庶民なのよ。
忠臣蔵で家老がなにもかも投げ打って主君の仇を討って最後自害するから庶民は喝采するのよ。
元々千石取りの裕福な家なんだから、のんびり隠居暮らしするなり別の主君探して仕えるなりした方が本人も家族も幸せかもしれないよ。
でもそれじゃ、人としての魅力が落ちちゃうのよね。
私含め庶民は身勝手なものなんです。
話それたけど
大所高所の観点で行動しようとするふっちーはそれはそれで悪くないと思うんだけど
組織の運営能力はからっきしだからなぁ
でも関係部署との交渉力・調整力は馬鹿にできない。（周りにとばっちりを撒き散らしてるわけだがｗ
ちょっと癖が強くて上層部からしても使い所の難しい人じゃないかな
なんにしろＣＩＯには向かないと思う
ふっちーLove
なんとなくさんへ
言った言わないの無用なトラブルを防ぎ、約束に重みをつけるためにドキュメント化は必要です。
口約束で仕事していたら、それこそ信頼関係を壊してしまいます。
私の居心地が悪いのは会社の文化ではなくて、情シスとして結果を出せていないのが原因です。
システム開発が効率的に出来るようになったことも、障害件数が減ったこともない。言い訳ぐらいはうまくなったかと思うと、あんまりいい気分じゃない。
ITマネジメント課のように「エースシステムエンジニアリングが悪い」で開き直れば、気分は良くなるかもしれませんが、それじゃ社内の信頼は得られないですし。
ふっちーには欠点はありますが、それ以上に美点があります。
SE・プログラマとさしで話が出来るほどIT技術に詳しい。会社組織の動かし方を心得ている。手間をいとわない勤勉さ。自分に足りないと思ったら人目も気にせず学ぶ誠実さ。
ふっちーがCIOなら中小の実力あるソフトハウスや個人を発掘して活用できると思います。SE・プログラマにとっても良いことだと思います。
大体、私、リアルでふっちー以上のユーザー企業のマネージャーって見たことないんですが、みなさんの周りには普通にいるんですか？
としろう
>情シスとして結果を出せていないのが原因です。
良くある事ですねえ。
情シスってちゃんと志持って運営しないと
・自部門で開発・改修・保守できなくなる
・社内の取りまとめして外部SI企業に出すのさえ怪しくなる
（SI企業へ顔合わせさせるだけになる）
・根拠が怪しい只の値切り交渉をするだけになる
こうなってきて、システム開発に対する購買部に成り下がる
見積から安く買い叩いた分を成果と勘違いする。
これでは情シスは只のコスト部門。
システムを作らない事も含め、ビジネス目的に併せて必要な投資として
必要なら相応の初期投資として考えねばならないのにね。
>ふっちーには欠点はありますが、それ以上に美点があります。
いいえ、美点を汚点（独り善がり）が全て台無しにしています。
自分の学んだ事に過剰な信仰を持っていて、まるで宗教戦争の当事者のように
他者にたいしてキキワケがありません。銀の弾丸だと信じているのです。
彼がCIOなら軍隊式使い捨て会社になり、今の日本の悪い状況と大差ないでしょう。
ふっちーLove
としろうさんへ
>これでは情シスは只のコスト部門。
まったくそのとおり。
開発失敗のたび、障害のたび、監査のたびにどんどん増えるドキュメントのとりまとめをしているだけの存在という気がする。
契約手続きなら購買部門のほうがよっぽど上手。
>必要なら相応の初期投資として考えねばならないのにね。
さて、相応の初期投資の説明が難しい。いったいいくらなら妥当なのだろう？
世間様のデファクトスタンダードはユニクロであり、トヨタであり、キヤノンである。良いものをよりやすく、期間工が世界最高水準の製品を作る世界。対して我らがシステム開発はさむらい業なみの単価を投じて集めた優秀なSE・プログラマを使って、出てくる台詞は「品質とコストはトレードオフです」「SE・プログラマを大切にしないんだから良いシステムできるわけないじゃん」
エンドユーザは思うわけよ。Googleのサービス見てみろ、あんな高機能なのがただだぜ、それに比べてうちのシステムは、、、何で俺らのボーナス削ってあんなシステム作ったのかね。ちゅーか、あの連中いらなくね？
>他者にたいしてキキワケがありません。銀の弾丸だと信じているのです。
キキワケがないじゃない。
聞くに値することを誰も言っていないだけ。
ふっちーLove
>いいえ、美点を汚点（独り善がり）が全て台無しにしています。
独りよがりだったらどうだって言うのよ。
欠点ひとつで、フィクションの人物とは言え、
がんばっている人を否定するほどえらいのか、あんた。
平凡な人間が集まって、すごいものを作りだせるのが成熟した産業。
我々は不幸なことにシステム開発が産業として成熟した時代に生まれ合わせなかった。
それだけの話だろうが。
Edosson
>言った言わないの無用なトラブルを防ぎ、約束に重みをつけるためにドキュメント化は必要です。
>口約束で仕事していたら、それこそ信頼関係を壊してしまいます。
それを否定している人は、一人もいません。
皆さんが言っているのは、モノには限度がある、ということです。
>ふっちーがCIOなら中小の実力あるソフトハウスや個人を発掘して活用できると思います。SE・プログラマにとっても良いことだと思います。
普通の下請け社長だったら、渕上ネズミが絡んでいる時点で、
尻尾を巻いて逃げ出すと思いますよ。
仕事を請け負ったって、膨大な管理コストでリソースを食い荒らされるんです。
その分を、最初から割り引いておかないと。
「にらみ預金」そのものの話ですね。
さて、日付が変わってしまいました。
次のエピソードの主人公は、ムツミさんかな。
過労で倒れるのか、
ボトルネックと化したムツミさんに、渕上ネズミがぶちキレるのか。
公社だったとしても、元凶は渕上ネズミであって、
ムツミさんは被害者ですけどね。
次回じゃなくても、そういうエピソードがあるんでしょうね。
初体験
>>あたしは、彼らの若さと、初体験に関する卑猥なジョークを思いついたが、口に出すのはやめておいた。
「そっか、まだ経験なかったんだ。じゃあ、おねぇさんが教えてア・ゲ・ル♪」
とか?(w