冷たい方程式（10） 誰がためにマネジメントはある
やはりというか、当然というか、10月1日までにすべての仕様書は完成しなかった。正確には、ホライゾンシステムさんの必死の努力によって、仕様書自体は送られてきていたのだが、渕上マネージャが、片っ端から「不備を指摘」して差し戻したため、「完成」にならなかっただけだ。
それでも、10月1日から実装開始、というスケジュールは動かせなかったので、仕様書の仕上げはホライゾンシステム内の別のエンジニアが引き継ぎ、ムツミさんは予定通り、ITマネジメント課で常駐を開始した。
「今日からお世話になります。よろしくお願いします」
ずらりと居並ぶITマネジメント課の社員たちの前で、ムツミさんは緊張の面持ちで短く挨拶し、全員の拍手を受けて、頬を紅潮させた。
初日は、社内施設の案内や、臨時入館証の登録、開発環境の構築や、実装の進め方の打ち合わせといった事務的な些事で、慌ただしく過ぎていった。Eclipseのプロジェクトは、あたしが作成済みだし、テーブル設計に合わせたentityクラスも亀井くんが作成してある。テンプレートのHTMLは、管理系については、一応すべて作成済みだった。細かい部分は、ムツミさんに実装しながら、手を加えていってもらうことになる。
常駐2日め、ムツミさんの常駐は本格的にスタートした。これまでの打ち合わせなどを通して、ムツミさんが自分から積極的にコミュニケーションを取る人ではないと分かってきていた。エンジニアの中には、他人と協調することで数倍の力を発揮する人もいるが、ムツミさんは明らかにそのようなタイプではないようだ。それでも、不明点を自分で勝手に消化したりせずに、きちんと質問してくるので心配はしていなかった。
午前中、ムツミさんはEclipseの環境を自分好みに変更した後、職位マスタメンテナンス画面の実装を開始した。さすがに最初はいくつか質問をしてきたものの、すぐに早いペースで実装を進め出した。Teedaの経験はないと言っていたけど、今日までに訓練してきたらしく、見た限りでは実装方法で戸惑っている様子はない。
あたしはひとまず安心し、自分の仕事を進めた。最近になって現場から上がってきた機能追加要望を、すでに設計済みの機能に組み込めないか検討していたのだ。亀井くんは、まだ少し残っているテーブル設計を片付けていた。渕上マネージャは何をしているのか分からないが、しきりに何かを入力していて、ムツミさんの作業に口を出そうとはしなかった。
正午少し前に、あたしとムツミさんは作業の手を止めた。今日はムツミさんと食堂をランチを取ることにしていたので、混み合う前に席を確保しようと思ったのだ。それを見て、亀井くんも慌てて立ち上がった。
「ご一緒します」
いつもは同期の連中と外に食べに行く亀井くんも、今日は同行した。放っておけば、毎日でも同行しそうな顔だ。
あたしたちは、テーブルの1つに陣取り、ゆっくりランチを楽しんだ。亀井くんは、しきりにムツミさんに話しかけ、ムツミさんも口数は少ないものの、それなりに楽しんでいるようだった。
「ここの食堂は安くておいしいですね」パスタセットを選んだムツミさんは、うれしそうに言った。「うらやましいです」
「じゃあ、いっそ、このままうちの社員になったらどう？」亀井くんが馬鹿なことを言い、ムツミさんは困ったように笑った。
それでも、ムツミさんの緊張も多少は解けたようで、ITマネジメント課に戻ってきたときには、口元に笑みが浮かんでいた。それを見た亀井くんもうれしそうな顔だった。
あたしたちが席に着こうとした途端、渕上マネージャの鋭い声と重量感のある視線が、ムツミさんの笑みを消し去った。
「君が午前中にコーディングしたソースはどこにある？」
あたしたちは顔を見合わせた。ムツミさんは、首を傾げながらも素直に答えた。
「PCのディスクの中にあります」
「なぜソース管理システムにコミットしないのか」
「はい、あの……」ムツミさんが口ごもったのは、質問の意図が読めなかったからだろう。「……まだコーディングの途中ですので……」
「食事に行く前に、きちんとコミットしたまえ。常識だろう、そんなことは」
――どこの世界の常識だ？
困った顔で立ち尽くしているムツミさんを見て、あたしは助け船を出した。
「すみません。まだ使い方を伝えていないんです」
「君は何を考えている。なぜ真っ先に教えない？」渕上マネージャの矛先はあたしに向けられた。「プロジェクト・マネジメントというものが、まったく分かっていない」
あたしは小さく深呼吸して心を落ち着かせた。
「あの、帰り際でいいかと思っていたのですが」
渕上マネージャの目が光った。
「今まで、そうやってきたのか」
「ええ、まあ」
あたしは素知らぬ顔でうなずいたが、正確ではなかった。コンパイルエラーが残っていたり、コーディングの途中で切り上げるときなどは、不完全なソースをコミットしないことの方が多い。また、帰り際にバタバタしていて、コメント入れてコミットしている余裕がない日などは、そのまま帰宅してしまったりする。これは亀井くんも同じだ。
「では、それをこれから改める」渕上マネージャは宣言した。「本日より、昼の休憩前、15時、退社前に、各自、そのときのソースをコミットすること」
あたしたちは再び顔を見合わせた。
「途中でもですか？」亀井くんが訊いた。
「例外はない」反論の余地なし、という冷徹な口調だ。「亀井くんに、タイムキーパーを任せる。時間になったら、全員にコミットを促したまえ」
亀井くんは、ちょっとイヤそうな顔をしたが、取りあえず従順にうなずいた。
「分かりました」
まあ、確かに、夕方にいきなりHDDが壊れて、1日分の実装結果が泡のように消えてしまう、という悪夢のような事態も考えられなくはない。あたしたちが使ってるPCには、RAIDなどというぜいたくな機能はついていないのだから。亀井くんには気の毒だが、安全性が高まったと思えばいい。
と、あたしは好意的に解釈したのだけど、次の渕上マネージャの言葉で、その評価を考え直した。
「その際、誰が何のソースをコミットしたのか、台帳に記録しておくこと。記録したら、私に提出したまえ」
――そんなことして、どんな利点があるんだか……
「あの、管理メニューで、変更履歴の一覧がダウンロードできますけど」
そう言ったのは、ひょっとして、ソース管理システムの管理方法をよく知らないのかもしれない、と思ったからだったが、渕上マネージャの目的は違っていた。
「これは君たちに作業の区切りを意識させるためだ。その時間には、可能な限りキリのいい状態でコミットしてもらう。もちろん、コンパイルが通っていることは最低限の前提条件だ」
この人の言っていることがまったく理解できないのは、あたしの頭が悪いからなのか？ あたしはそっと亀井くんとムツミさんを観察してみたが、どちらの顔にも、「理解不能」の文字が張り付いていた。それどころか、2人ともあたしに何かを期待するような視線を注いでいる。
あまり気は進まなかったけれど、聞いてみることにした。
「すみません、渕上さん。それは何が目的なんでしょうか」
「私が君たちの作業の進捗状態をチェックするためだ」
「……よく分からないのですが」
「君たちが理解する必要はない。これは高度なマネジメントの手法だ」
――マネジメントときたか
そういえば……あたしは渕上マネージャがやってきて数日後のことを思い出した。
渕上マネージャの机の上には、本がずらりと並んでいるが、あたしの席からは背表紙が見えない。その日、たまたま渕上マネージャが先に退社したので、あたしは好奇心に駆られて、どんな本を愛読しているのかと題名を確認してみた。プログラミング関係の書籍かと思いきや、ほとんどに「マネジメント」という単語が入っていた。その前後に「徹底解説！」とか「実践手法」とか「効率的」などの踊り文句が付いている。
「プロジェクトというものは」渕上マネージャは、わざわざ解説してくれた。「プログラマの自由裁量に任せていると、必ず失敗する。強力なリーダーが的確な指揮を執って、はじめて高品質なシステムが完成するのだ。経験の浅い君たちには、まだ分からないかもしれないが」
そのとき、磯貝課長がのんきな顔で、ランチから戻ってきた。缶コーヒーと雑誌を手にしている。そのまま自分の席に向かおうとしたところで、あたしたちと渕上マネージャの間に漂う緊張感に気付いたようだ。関わり合いになるのはごめんとばかりに、そのまま回れ右して出て行きかけたが、渕上マネージャの低い声に呼び止められた。
「磯貝課長」
やむなく足を止めた課長は、顔をしかめて振り返った。自分に予知能力がないことを悔やんででもいるんだろう。
「はい、なんでしょう」
「今まで、開発グループはどうやって開発や保守を進めてきたのかね」
何を目的とした質問なのか分からない課長は、深く考えることもなく答えた。
「どうやってと言われても……空いている人に、適当に業務を振っているだけですが」
「仕様書のチェックは？」
「仕様書ですか」磯貝課長はわざとらしく笑った。「やってませんよ。いやいや、そもそも仕様書なぞ、ろくに作ってませんでしたからねえ」
「では、コードレビューは？」
「やってませんね」
「進捗管理は？」
「毎週のグループミーティングで報告してもらってますよ」
「つまり、週に1度しか確認していないということか」
「たまに忘れますけどね」
磯貝課長はまた笑ったが、誰も同調しなかった。
「では、スケジュールに遅れが発生した場合、どのような対応を取ってきたのかね」
「対応もなにも」課長は肩をすくめた。「遅れてしまったものは仕方がないです。インフラグループの手伝いとかもありますし、突発的なトラブルもありますから。たぶん、グループ内でやりくりして進めているんじゃないですかね」
「つまり、プロジェクトマネジメントらしいことは、何1つやっていないわけだな」
「マネジメントですか」磯貝課長は首を傾げた。「いや、こんな少人数のチームで、そんなことをする必要はないですよ。各自に任せた方が結局、早いですからね」
渕上マネージャはゆっくりうなずいた。
「それは怠慢というものだな」そう言うと、あたしたちの顔をにらみつけた。「これまでは、君たちも大したシステムを作ってきたわけではないから、それで問題がなかったのかもしれない。しかし、この勤怠管理システムはとても重要なシステムだ。これまで通りの、いい加減なやり方では、失敗するのが目に見えている。やはりしっかりしたマネジメントが必要なようだ」
渕上マネージャは、ゆっくりと立ち上がった。
「システム開発の8割は失敗だと言われている。これまで私はそんなはずはないと思っていたが、今、考えを改めた。いい加減なマネジメントしかできていないか、まったくマネジメントをしていないから失敗してきたのだ」
とうとう演説モードに入ってしまったようだ。背が高いから、演台に乗る必要がないのは便利だ。
「考えてみれば、君たちは不幸だった。今まで、まともなマネジメントをしてくれる管理者がいなかったのだろう。それで、独自色が強く、統一感がなく、計画性もない貧乏たらしい開発のやり方が染みついてしまったのだ」
――貧乏たらしい？
「だが、心配はいらない。私は本社でERPパッケージの導入の責任者として、多くの担当者と業者を統括する立場にいた。これまでの導入はすべて計画通りに完了しており、各部門の部門長や、担当役員の方々から、絶大なる信頼を得ている。それがなぜだか君たちに分かるかね？」
分かるもんか。あたしは心の中でつぶやいた。もちろん渕上マネージャは、あたしたちに答えを求めてなどいない。
「それは私が確固たるプロジェクト・マネジメントの思想を持って進めてきたからだ。私の言うとおりにやれば、必ず成功することを保証する」
文字にすると熱弁をふるっているかのようだけど、実際には、渕上マネージャの顔は無表情のままで、声も単調だった。眉間にしわが寄っているのが、わずかに見せた感情の片鱗だろうか。
――この人、開発で苦労したことないんだな
渕上マネージャの演説を聞いて、あたしはそう思った。
マネジメントが、システム開発の正否を分ける面があるのは否定できない。指揮官がクズだと、できるシステムはクズ以下になってしまう。
でも、この人、分かってないなあ、と思ってしまうのは、システム開発はマネジメント”だけ”で決まるものではない、と知っているからだ。マネジメントだけで決まるなら、世の中のプロマネさんは、こぞってPMBOKやCMMIを勉強しさえすればいいことになる。
前の会社では、さんざんな目にあったあたしだったが、1つだけ学んだことを上げるとすれば、システム開発はダイエットに似ているということだ。一定以上の規模のシステム開発になると、「～だけでいい」ということはあり得ない。
リーダーシップあふれるマネージャだけでもダメ。
神業プログラマだけ揃えてもダメ。
高価な開発ツールばかり買ってもダメ。
実装能力だけ優れたメンバーばかりでもダメ。
コミュニケーションスキルだけ高いメンバーばかりでもダメ。
オブジェクト指向だけ究めていてもダメ。
SQLばかり得意でもダメ。
男ばっかりでもダメ。
女ばっかりでもダメ。
etc……
とはいえ、渕上マネージャに、そんなことを話してもムダだということも、イヤになるぐらいはっきり分かっていた。そんなのは、取るに足らないあたしの経験でしかないんだから。「参考になった」ぐらいのリップサービスを受けるのがせいぜい、といったところだろう。
渕上マネージャは、あたしが考えている間も、あれこれ話していたが、やがて唐突に言葉を止めた。
「まあいい」そうつぶやくと、腰を下ろした。「とにかく私のマネジメント方法に従ってもらう。まずは、ソースのコミットルールを徹底すること」
もし徹底しなかったらどうなるのか、とは、聞く気にもならなかった。
「次のコミットは15時だ」渕上マネージャの視線が亀井くんを突き刺した。「やることは分かっているだろうな？」
亀井くんは、ガクガクと首を縦に振った。それを合図に、あたしとムツミさんも自席に座った。ランチで醸し出した和やかな雰囲気は跡形もなく消え去っていた。
これを皮切りに、渕上マネージャは、あたしたちの開発作業に本格的に介入し始めた。それはもう、ウンザリするような毎日の始まりでもあった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
wm
コーディングの途中でコミットしちゃったらテスト通らないじゃないか・・・
BEL
渕上さんの理論でいくと、このプロジェクトは渕上さんとホライゾンだけでやった方が
いいんじゃないか？日比野さんと亀井くんの金少しホライゾンに上乗せして。
「オブジェクト指向だけ究めていてもダメ。」「SQLばかり得意でもダメ。」
これらは全くその通りだろう。(後者は某連載を思い出す)
「男ばっかりでもダメ。」「女ばっかりでもダメ。」これ、そうですか？
後者は少ないかもしれないけど前者はこの世界普通にある気がしますが。
「これは高度なマネジメントの手法だ」これ、なんか吹いたｗ
banana
渕上マネージャーが！
技術のわかるマネージャーが！！
おいらのあこがれが！！！
ただのマネジメント馬鹿になっちまったよーーー
。・゜・(/Д`)・゜・。うわぁぁぁぁん
さそうたける
渕上マネージャーってマネジメントやら設計やらプログラミングやら、
知識はたくさんあるようだけれど、
もしかして単に教科書読んで覚えただけの、
頭でっかちな人なんじゃないか。。。
とおりすがり
淵上マネージャーって、たとえば以下のような経歴の人じゃ無いかなあ。
一流大学（特に文系学部）出身 → コンサル会社に新卒入社 → そこでERP導入（のみ）を経験 → コンサル会社をリストラされる → SI会社に転職
一流大学だろうとなんだろうと、文系学部だとプログラミングなんて基礎さえやってない人が大半だろうし、そういう人がコンサル会社に入って「これが一流のマネジメントだ！」「おれたちはマネジメントという高尚なことをやっている。だからプログラミングみたいな低俗なことに関わる必用は無い。そんなことは下々の奴らがやることだ」「マネジメントがプロジェクトの成否を分ける」→ 「マネジメントさえ良ければプロジェクトは成功する」という先入観を植え付けられて、洗脳されてしまった。
そして「お勉強」は良くできたし、就職活動も「成功」したし、その後も高給取りで「えりーと」街道をまっしぐらに来たから、無駄に高いプライドと、自称「豊富な経験」も持っている。ただしプログラミング経験０なもんだから、自分が言ってる自称一流のマネジメント手法や規律とやらが頓珍漢なことにさえ気づかないし、それを理解する能力もない。
大学受験までなら受験参考書の「正解」を覚えることで難関大学も突破できたんだけど、プログラミングやマネジメントには「失敗」や「プラクティス」はあっても「正解」はない。その違いを理解できぬままマネージャという肩書きだけぶら下げてるから、こういう役立たずのバカマネージャも生まれてしまうんだろう。またERP導入は動くお金は大きいし動く人も多いかもしれないけれど、ソフトウエア開発やプログラミングという視点では極めて単純な、中学生の遊び程度のことしかやってないことにも気づいてないだろう。
こういう人が厄介なのは、自分が失敗していることや、失敗の原因が自分であることにさえ気づかないことがあると言う所だな。ホライゾンシステムがあわれだ。
Edosson
淵上マネージャーって、ERPパッケージのマネジメントは
経験豊富とのことですが、「開発の」マネジメントは経験無いんでしょうね。
こういう人が、なんでこんなところに回されてきたんでしょう。
以前の作品では、ホスト系でならした人が、
Web系に乗り込んでこようとして、すっころんだ話でしたが。
しかもこの人、基本的に、自分以外のメンバーを信用してないんですね。
BEL
一度は、淵上さんが下流の実務をちゃんと経験してないんじゃないかという
推測もしましたが、そういう人がクラス図を一目見ただけで
「単一責任原則という言葉を知らないのか」と言ったのが不思議でしたね。
まだこの人の本当の性格やら経歴やらがつかめていません。
前作の方々ほどめちゃくちゃなことは言っていないし。
しかし作者とて、すべての知識や技術を持っているわけではないはずなのに
その制限を感じさせないで読めるリアルさは面白いわ。
nanashi
技術を分かっている人なら
進捗にしても、プログラマーの表情とソース、
そしてテストコードのクリア具合で殆ど分かってしまいますよね。
弊社の一番のPMはそういう人。
またドキュメントの誤字・脱字・フォントの不統一を整える些末な雑事は、
早々にまきとって、学生バイトにやらせてます。
淵上マネージャーのご本には「ピープルウェア」は無いのでしょうね・・・
さて、こんな状況になってしまった以上、
主人公はどうするのでしょう？
どこかで淵上マネージャーとぶつかって、
折り合いをつけていくのでしょうか？
それにしても淵上マネージャーは、
このままでは進捗遅れが取り返し不能になるのでしょうけど、
もうリカバリープランは考えていたりするのでしょうか？
saboten
淵上さんはたくさんの知識を持っている優秀な人材だと思う。
これまで成果を上げてきて、自分の腕に自信があるイメージ。
ただ無駄に臆病というか、1%のリスクでも回避したいって感じかなー。
部下が大丈夫ですというならあえて任せてリスクを取る(根回しもする)
くらいの度量がないとダメかなー。実際反発コメがたくさんあるし。
そういう意味では課長はいい感じだよね。
技術は1流、器は3流って感じかな。
yamada
どんなにダメな相手だとしても名前を間違えるのは失礼だと思うのですけどね。
まぁ架空の人物なのでどうでもいいことかもしれませんが、
一人が間違えてから、あとに続く皆さんが間違い続けるのがなんかちょっと面白いです。
通りすがり
ほんとは部活のマネージャーみたいなのをマネージャーって言うんだよね。
BEL
>どんなにダメな相手だとしても名前を間違えるのは失礼だと思うのですけどね。
まったく気づきませんでした。。ご指摘ありがとうございます。
>一人が間違えてから、あとに続く皆さんが間違い続けるのがなんかちょっと面白いです。
ほんとですねw。。上の人のをコピペしたのでしょうね。少なくとも私はそうです。。
前回の"上級SE"みたいに、さらなる登場人物がいるのかが気になるところです。
としろう
なんだか、
健康な人を過剰に頻繁な検査で本当の病人にしておいて
俺の検査のおかげで病気がこの程度で済んだんだと
本気で信じて言い放つ医者
それと同じような結果を招く嫌な予感
それともエースシステムの回し者か？
へろへろ
結局のところ、明確にプロジェクトを「完了」させ、「手放す」意思を持った人間
がいないという状況なのかもしれない。
成果物の形式（時限式のコミットのような進捗管理も含め）レベルでの品質に
こだわるマネージャーは、できあがったソースコードの動作や可読性に関する
視点がなく、バグ対応や変更要望への対応に要する時間が膨れ上がり、「完了」
することも「手放す」こともできない。
チームリーダーは自分にとってやりやすい方式をとった結果、他者に引継ぎ
しにくくなり、「手放せない」。そして社内での権限の問題上、「完了」させる
こともできない。
スキルの足りない社内SEや立場の弱い下請けはそもそも自分の意見を通せない
から、切られることはあっても「手放す」ことはできない。
早々に頬かむりを決め込んだ中間管理職はいわずもがな。
さて、この状況を動かせるのは誰なのか？
banana
前作の三浦マネージャーといい、
今回の渕上前んージャーといい、
なんだってこんなにマネージャーを嫌うのか不思議。
そんなにリアルではマネージャーとうまくいっていないの？ ＞リーベルGさん
banana
仕様書書きとコーディング以外にもシステム開発以外の世界はあります。
マネージャーはそこでがんばっている。
そりゃ、若い者に気持ちよく仕事させたいよ。
SE・プログラマが生き生き仕事していれば、
良い結果をだすなら、自腹切っても環境整える。
でも、そうじゃない。
部活のマネージャーじゃないのよ。
選手を気持よくゲームに集中させるのが仕事じゃないのよ。
選手に最高のパフォーマンスを発揮させるのが仕事じゃないの。
会社から与えたミッションを成功させるのが第一目標、
第二目標はマネージャーの首根っこを押さえている人を納得させること。
第三目標はマネージャー自身が生き延びること。
あまりマネージャーに期待しないでくれ。
banana
ごめん、間違えた。
誤：仕様書書きとコーディング以外にもシステム開発以外の世界はあります。
正：仕様書書きとコーディング以外にもシステム開発の世界はあります。
ついでですが、暴言と非難されるのを覚悟して言います。
徹夜でコーディングしただけで
システム開発を分かった気になっているSE・プログラマ、
管理馬鹿のマネージャー並みに救えないです。
BEL
>徹夜でコーディングしただけで
>システム開発を分かった気になっているSE・プログラマ、
>管理馬鹿のマネージャー並みに救えないです。
そんなに暴言ですかね。徹夜しなきゃいけない状況になる前から、
徹夜したい・すべきと思ってしてるSE・プログラマはほとんどいないと思います。
すべきでなかったことをしたのに、後からそれを誇らしげに言うのはやはり
間違っていますね。そもそも徹夜が必要になった時点で、たとえ徹夜したとしても
そのプロジェクトは完全な形でうまくいくことはまずないです。
＞そんなにリアルではマネージャーとうまくいっていないの？ ＞リーベルGさん
プログラマにだって、こういうネタになってしまうような方々は沢山いると思います。
でも「マネージャ」という一般的には能力があるとされている人が、実はダメなところが
あるんだよ、ってのが話として面白いってことなんじゃないでしょうかね。
fgnplo
＞そんなにリアルではマネージャーとうまくいっていないの？ ＞リーベルGさん
フィクションにこんなこと言ったって作者は困るでしょうに・・。
読み物は読み物として楽しみましょうよ。
banana
作者さま、ならびに本コラムの読者さまへ
bananaです。
昨夜、酒に酔った勢いでくだらないことを書きこんでしまいました。
「泥酔した会社員が駅員に暴行」という状態です。
年とっていることを自覚しているようなことを書きながら、
行動がともなっていませんでした。
すみませんでした。
削除すべきところですが、
仕組み上できませんのでお許しください。
ハムレット
昔、中国の古典に政治の在り方の上、中、下を説いた本がありました。
上：無為を以って政治を行い、民衆が王の存在を意識しない。
中：仁徳をもって政治を行い、民衆は王の人徳に感謝する。
下：法令をもって政治を行い、民衆は王の権力に畏怖する。
結局、法令を重視すれば、法令が手段から目的に変わり、そこに辻褄を合せようとして、結局国が乱れてしまうとのこと。
プロジェクト管理の世界でも、大きなプロジェクト程、規則や体制が優先されて、結局何を作っているのか、良く分らんって状況がよくありますよね。そう云う意味では磯貝課長のやり方も、それなりに価値はあるように思えます。結局、職制を通じて一度、人の行動をコントロールする事を覚えると、権力の快感というか、中々そこから逃れられないのでしょうね。なまじ理論武装しているから、なおさらって感じですか。
人間の精神的な、本質は、昔も今もそう変わらないのかもしれない。
くくな
初登場したときに、「私は独身だ」と主人公に言ってますね。
プログラマ
＞ そんなにリアルではマネージャーとうまくいっていないの？
日本では、マネージャーとは「マネジメントをする人」では無く、「単に管理をする人」であって、しかも「プログラミングなんてできなくてもいい」と公言されてるんですよ。そしてそれを鵜呑みにして、本当にマネジメントも知らないし、プログラミングもできないし何も知らない無知で馬鹿なマネージャーが多い。すごく多い。
で、これははっきり言って良いんだけど、プログラミングができない人で、良いマネージャは滅多にいない。だから日本のマネージャの9割はダメマネージャと言って良いくらいにヒドイのが現状。これは失敗パターンもできるくらいよく知られている事実で、PRESS ENTERで扱われているような人たちは、そういう典型的失敗マネージャ達なんですよ。
このPRESS ENTERはフィクションだけどとてもリアルと言われるのも、実話に基づいているからでしょうね。
＞徹夜でコーディングしただけで
＞システム開発を分かった気になっているSE・プログラマ、
まあなにせ学歴不問・未経験歓迎でプログラマを雇ってるくらいだからね。ろくにプログラミングを知らないダメプログラマの比率はかなり高いよ。そういうひとたちが「まだ」理解してないってのは本当。だけどそういう人よりも大半のマネージャの方が、さらに何にも全く理解していない。しかも彼らが困ったチャンなのは自分が無知であることに気づいてないか、気づいていてもその事実をひたすら隠そうとするところ。
例えば、
＞「君たちが理解する必要はない。これは高度なマネジメントの手法だ」
ここなどは、実はマネジメント本でもそんなことは全然書いてないし、自分でも全然理解して無いんだけど、部下に痛い所を突かれたので、こういう言い方をして煙に巻こうとしているんです。プログラミング経験1年くらいの初心者ならこれで本当に騙されるかもしれないけど、ある程度以上の知識と経験を持っていると、逆にボロが出ます。
たしかに経験が浅く、無知で未熟なプログラマも多いけど、小学校の頃からパソコンを触り、大学で専門教育を受け、さらに十年以上様々な現場でプログラミングを続けてる人間もいるんだよね。プログラミングで落ちこぼれたからマネージャになった人や、そもそもプログラミングが全くできないくせにマネージャになった人と、開発についてどっちが詳しいか言うまでもないと思うんだがね。
で、そういうマネージャの人たちと話しをすると、恐ろしいほどに全く話がかみ合わない。何しろ何も知らないから。現場経験も無く、勉強したことさえなく、それで分かったフリだけしている「管理職」のなと多いことか。
>一度は、淵上さんが下流の実務をちゃんと経験してないんじゃないかという
>推測もしましたが、そういう人がクラス図を一目見ただけで
>「単一責任原則という言葉を知らないのか」と言ったのが不思議でしたね。
これは不思議じゃ無いですよ。
その気になれば単一責任原則だけなら初心者がチェックリスト片手にUML図を見れば指摘できる程度の、ある意味で最も簡単な部分だからです。これに比べればリスコフの置換原則なんかの方がずっと難しい。単一責任の方はプログラミングを理解してない人でも指摘できる数少ない設計原則なので、彼はこれ「だけ」をチェックしていたのでしょう。見る場所も少ないし、バカの一つ覚えなのでチェックする時間も短くて済むのです。
プログラマ
>「単一責任原則という言葉を知らないのか」と言ったのが不思議でしたね。
さらに捕捉しておくと、渕上マネージャは杓子定規にチェックしただけなので、適切でない場面で単一責任原則をゴリ押ししています。
単一責任原則は確かに「守ったほうが良い原則」ではあるけれどあくまで原則にすぎず、他の原則やプラクティス等と総合的に判断して、必要に応じて破るべきルールの一つでしかありません。
渕上マネージャはプログラミングのことを理解せずにチェック方法を丸暗記しているだけなので、ああいうトンチンカンな指示になっているんでしょう。
大手SIer
形通りのガチガチのマネージメントをしたがる渕上マネージャーと、
「マネージメントって何？」的な磯貝マネージャーと開発メンバー。
個人的にはどっちもどっちだと思いますね。
私の上司が見れば「君たちはマネージメントというのはどういうことか
理解してるのかね？」って切り捨てそうな程度のバランス感覚の悪さ。
あと「開発を知らないマネージャーが多い」とちらほら書かれていますが、
ある程度の規模の会社では基本的に管理職は知らなくてもいいんですよ。
こういった内容はある程度の規模の会社で経営に絡む業務をしたか
管理職の経験でもないと、ピンとこないかもしれませんが、bananaさんも
書かれているように、会社から請け負っているミッションが全く違いますから。
「大手ほど技術力があり、かつ部下に慕われる管理職は部長より先には
昇進できない」というのがこれの最たる象徴ですかね。
最後に渕上マネージャーは意外といいことを言っているんですけど、
目的を理解していないのか、残念ながら説明の流れが結構支離滅裂。
>これは君たちに作業の区切りを意識させるためだ。
を読んだときは「おおっ」って思いましたけど、続いて
>「私が君たちの作業の進捗状態をチェックするためだ」
という説明がついたときは「違うでしょ」って思いました。
まあ、玉石混合だと思えばいいのかもしれませんけどね。
wm
>これは君たちに作業の区切りを意識させるためだ。
これはマネージメント的にもいいと思います
>コーディングの途中でコミット
これはプログラムを全く知らないという所から来ていると思います
結局、自分の無知を受け入れないで相手の言葉を無視するとこうなるんじゃないか？って感じですかね
っつか、としろうさんの医者のように、片端からプロジェクトを潰して「ほら、この程度の被害で済んだでしょ？」という事しかしてないような気がするんだが、ほんとこんなんで成功したプロジェクトあるんでしょうか？
# いや。ここから大成功に持ち直すのが腕の見せ所？
a
玉石混淆と玉石混合はまったく違う。javaとjavascriptくらい違う。
とまあ、いちいち人を食ったふうなこんな態度が皆さん業腹なのでしょうな。
開発メンバーの技術力を信用しないわりに、開発メンバーの忍耐力だけは根拠もなく信頼している。
これでプロジェクトが失敗したら開発に責任かぶせてとんずらするのかな。
畑が違うことは百も承知だろうけど、なんか開き直りすぎじゃないかなあ。
失敗プロジェクトの分析じゃあ、そういう精神的な部分って要因としてあげられないことが多いのかもしれない。でも元を正せばメンバ間の雰囲気が悪くなったことが一番の原因……ってよくありそうだと思うのだけれど。
それすらぶっちぎれる神懸かりなマネージャって期待してもいいんですかね？
saboten
>会社から与えたミッションを成功させるのが第一目標、
>第二目標はマネージャーの首根っこを押さえている人を納得させること。
>第三目標はマネージャー自身が生き延びること。
う～ん。なんというか残念な方向に履き違えてるね。
上に向かってどうどうとそう言えるならたいしたもんだけど。
もうちょっと先(持続性やらなんやら)を見据えた方が良いと思います。
特に3番目ばっかりの人はいらないかな。
>ある程度の規模の会社では基本的に管理職は知らなくてもいいんですよ。
そういう人は開発の現場に出ないんじゃないかな。
banana
確かに、システム開発のマネージメントには問題が多い。
目の前でおかしなことが起きていても、
SE・プログラマに指摘されるまで、
自分では気が付けないマネージャーがほとんどだと思う。
ではどうすればよいか。
マネージャーがITスキルを持てばよい。
ということで、この物語の渕上マネージャーには期待していたのですが。
どうも、「分かっているSE・プログラマ」対「おバカなマネージャー」という構図は崩せないようですね。
banana
>>ある程度の規模の会社では基本的に管理職は知らなくてもいいんですよ。
>そういう人は開発の現場に出ないんじゃないかな。
現場に任せられたらいいんだけどね。
banana
会社では仕事の評価は回りが下します。
たとえばシステム障害が発生して、利用部門から状況説明を求められる。
その時に、何もしていません、これからも何もしませんでは、
誰も納得しません。
レビューを実施したり、進捗管理をしたりなどの
なんらかのアクションを起こさないといけない。
SE・プログラマからしたら物知らずのマネージャーが
そんな事をしても無意味と思うかもしれません。
現場に任せておけと。
しかし、こんな障害が起きたらどうでしょう。
利用部門から問い合わせがありました。
「この帳票の製品コードの番号がおかしい。」
マネージャーはSEに調査を指示します。
半日後、報告がありました。
「帳票を作成するプログラムで、
フラグの値を誤って帳票に出力していました。
データベースのデータの不整合はありません。」
マネージャーは何を言われているのか意味が分かりません。
いくつか質問して分かったのですが、
フラグというのはプログラマがプログラムの動きを確認するために入れていた変数で、
帳票にデータをセットする際に誤ってセットしていたか、
セットしていたのを納品時に消し忘れていたそうです。
データベースのデータの不整合はありませんでしたというのは、
軽微な障害だ、安心しろと言いたかったようです。
テストでどうして発見できなかったのかと聞くと、
年次で補助的な使い方の帳票だからと言います。
重ねて質問して分かったのですが、
頻繁に使う業務的に重要な帳票はしっかりチェックしているから、
大丈夫と言いたかったようです。
マネージャーは仕様書にない処理を書くなとか、
そんなコードを納品時になぜ消さなかったのかとか、
いったい何をレビューしていたんだといいたくなりますが、
そこはぐっとこらえます。
「バグを憎んでプログラマを憎まず」
これが日常です。
マネージャーはSE・プログラマを信頼しつづけることができるでしょうか。
また、このような障害を利用部門はどう受け止めるでしょうか。
ちゃんと作っているのか、品質は大丈夫かと不安になっても無理はないですよね。
マネージャーはどうしたらいいでしょうか。
不安になっている利用部門が、今後の再発防止策はと聞いた時に。
「いや、こんな少人数のチームで、そんなことをする必要はないですよ。
各自に任せた方が結局、早いですからね」的な説明をしたら
火に油を注ぐようなものだという事は分かりますよね。
磯貝課長はSE・プログラマの理想かもしれませんが、
磯貝課長が会社で生き延びるには
SE・プログラマが完璧な仕事をしなくてはいけません。
みなさん、出来る？
私は無理だと思う。
つくづく人間ってやつはシステム開発に向いていないと思う。
名無し
毎回毎回延々と1人で長文はいい加減鬱陶しいです、
そんなにご自分の正当性を主張なさりたいのでしたらブログか何かでやってください。
banana
お叱り、ありがとうございます。
まったく私は誰に対して正当性を主張しているのでしょうね。
これからは書き込みを控えます。
ほ
ディルバートの法則ってやつだね
fgnplo
話は終息しようとしてるみたいなので、とりあえずひとつだけ。
>磯貝課長はSE・プログラマの理想
いやー、それはないでしょうｗ
saboten
>>>ある程度の規模の会社では基本的に管理職は知らなくてもいいんですよ。
>>そういう人は開発の現場に出ないんじゃないかな。
>現場に任せられたらいいんだけどね。
マネージャーとして現場に駆り出されるのは、
「私は技術が分かります」アピールしてるからじゃないの？
現場のSE・PGの話についていけなくなったら潮時だと思うよ。
>私は無理だと思う。
>つくづく人間ってやつはシステム開発に向いていないと思う。
私はこの業界が天職だと思ってるけど、
センスのない人はとことん合わない世界だから、
無理にしがみつく必要もないと思うよ。
やめていった仲間も居酒屋とか自分の才能が生かせる世界で頑張ってるよ。
大手SIer
「理由はよくわからないが融通が利かなくて書籍通りの型にはめたがり」のマネージャーと、
「経験、知識不足だという認識がなく、会社として、組織として本来求められている
アウトプットを認識しておらず、趣味の延長の意識になってる」SE、プログラマ。
どちらも「相手はわかっていないが、自分はわかっている」と思い込んでいて、
みんなで仲良く「無知は罪なり」をまっしぐら。
そもそも会社組織で働いていれば、どうしても避けられない苦手な分野の仕事も
まわってきますから、自身やメンバーの弱みをきちんと把握した上で、状況に応じて
別部署だったり外注などで対応できる要員を確保するのが普通のやり方ですが、
「自分たちがわかっていないのがわからなきゃつける薬はありません」ていう感じですかねえ。
としろう
渕上氏はSE・プログラマの領域に踏み込んでいて判断をゴリ押ししています。
当然結果についての責任も取る必要があります。
十分な反論をしなかったからといって責任を押し付ければなお悪い。
とりあえず、他人の領分まで踏み込むからには、半可通では困ります。
だから、専門分野は任せるべきなのです。疑い過ぎも盲信もいけませんが。
banana氏がどうであれ、例示の対策で、チェックばかり増やすのは反対です。
本当に必要なのは、人金物時間の余裕です。
余裕の無さが大概の端折りとポカミス・チェック漏れの元だから。
マネージャの過剰監視に繋がれば、マネージャと開発者側で囚人のジレンマ的にLoseLose
開発者は自分の作業を増やすようなアラートは上げなくなるし、
最低限の言われた事しかしなくなるでしょう。
管理コスト（人金物時間）を増やす事でより余裕を失う事があれば本末転倒
そのへんのバランスを取るのが良いマネージャではないか？
勿論、駄目な開発者（個人の資質と評価）の問題は別に考える必要が有るが。
時と場合と案件で優先順位と各要素のコストパフォーマンスが異なる
要求がそもそも厳しい物だったならエンドユーザや自社の営業等にも責任がある。
最終的に失敗をした人間に責任を押し付ける事に疑問は無いのか？
>磯貝課長はSE・プログラマの理想
私もそれは無いと思います。
開発者の要望を叶える事も無く、只の事なかれ主義か、楽観主義だからです。
プロジェクトの成功の為の行動でも部下を信頼しているからでもない。
今までの行動からはそのように見えます。
渕上氏との比較であれば、磯貝課長の方がマシ
elseorand
「コーディングの途中でコミット」
「コンパイル出来ていることが前提」
これは強烈。
ソフトウェアソースのバージョン管理システムを進捗管理目的で使うとは・・・
しかもコーディングの途中でコミットでは、
「正しく機能するものの完成」という進捗ではなく、
あくまでソースの「ステップ数」という似非進捗しか分からない。
SE・プログラマー、いや技術者でなかろうと、
商売人として「正しく動くもの」という自身の商品特性すら、
このバカは理解していない。
ソースが商品なのではなく、「保証付きで正しく動く物」こそ、
商品なのだが。
ソースのバージョン管理をこのような目的外に使ってしまっては、
この目的の達成のために多大な被害を与えるな。
組織としてビジネス上の背景だとか何だとか以前の問題だな。
tiu
>>>ある程度の規模の会社では基本的に管理職は知らなくてもいいんですよ。
下請けか部下に責任と一緒にぶん投げるからでしょうか？
>あまりマネージャーに期待しないでくれ。
と、書かれている中で、なぜ、SE・PGは完璧を求められるのでしょうか？
あまりSE・PGに期待しないでくれ。と、言いたくなります。
>毎回毎回延々と1人で長文はいい加減鬱陶しいです、
>そんなにご自分の正当性を主張なさりたいのでしたらブログか何かでやってください。
顧客サイドの見解は貴重だと思いますが？
書かないという選択肢を他人に押し付けるより、ご自分で見ないという選択を選ばれてはいかがでしょうか？
elseorand
もっと端的に
「正しく動くか分からないバージョン（i.e ゴミ)だらけのバージョン管理システム」
渕上マネージャーは理解せずにごり押ししており、
これは即刻プロジェクトから叩き出すべきレベル。
anekdoten
＞大手SIer 2012年3月21日 (水) 06:47
＞「マネージメントって何？」的な磯貝マネージャーと開発メンバー。
磯貝は『こんな少人数のチームで』という前提で述べているのに、なんでこんなミスリードするかな？ ちょっと結論ありきで話を捻じ曲げすぎじゃないの？ まあ、あなたの話は磯貝達はプロマネ知らないという前提でないと成立しないからね。
あと
＞「大手ほど技術力があり、かつ部下に慕われる管理職は部長より先には
昇進できない」というのがこれの最たる象徴ですかね。
読点打つ場所悪すぎ。普段どういうドキュメント書いてるの？
hoge
しかしほんとに本文より皆さんの上からコメントが面白いです。
ひかえたりしないでもっと続けてください。
ブログなんかにかかれるとあちこちに流れてやり取りの減って面白くありません。
大手SIerさんとbananaさんが一緒に参加するプロジェクトとか見てみたいし。
へろへろ
>大手SIerさんとbananaさんが一緒に参加するプロジェクトとか見てみたいし。
（想像してみた）
……これはひどい。
BEL
>その気になれば単一責任原則だけなら初心者がチェックリスト片手にUML図を見れば指摘できる程度の、ある意味で最も簡単な部分だからです。
なるほど、ここまで織り込んでの描写なら逆にリアルですね。
C++しか経験ない人がJavaのプロジェクトのマネージャになるとか
組み込みしかやってこなかった人がWEBのプロジェクトのマネージャやるとか
そいうのはあるでしょうし、中にはいわゆる"技術畑出身"じゃない場合も
あるでしょうが、それ自体は問題はないでしょう。
ただそれと「システム開発(とその管理)のなんたるかを理解しているか」は別。
"知らなくてもいい"というのは、何も知らなくてもいいわけではないですから。
管理能力が同じだと仮定したら、当然
そのプロジェクトで使う技術の経験・知識がある＞左記はないが類似の経験・知識がある＞そもそもそういう類の経験・知識に乏しい
の順に管理効率も悪くなっていきます。まったく差がないということはないでしょう。
その場合は、自分が知らないことはメンバーから吸い上げるなどしながら、
プロジェクト管理を遂行していけばいいわけですが
自分よりメンバーの方が技術や知識があるということを謙虚に認識して
"協力してプロジェクトを進めていっている"という意識が必要です。
メンバーが問題を抱えているとき、何が問題なのか全くわからない、じゃまずいでしょうし。
まさにsabotenさんのおっしゃる
＞現場のSE・PGの話についていけなくなったら潮時だと思うよ。
というやつですね。
マネージャとその他メンバーは役割が違うだけで
「あらゆる面においてその他メンバーより優秀」というわけでもないし、
独裁体制をとればいいわけでもない。
物事の決定の判断材料はマネージャだけが持っているわけではない。
(もちろん権限や責任はマネージャにあるでしょうが)
というあたりを勘違いしないでプロジェクトを進めていく必要がある。
(勘違いしている人は往々にしてコミュニケーション能力に乏しい気がするが。)
toanna
> しかしほんとに本文より皆さんの上からコメントが面白いです。
> ひかえたりしないでもっと続けてください。
> ブログなんかにかかれるとあちこちに流れてやり取りの減って面白くありません。
そうなんですよね。
ブログ（または執筆者）に対応するツリー形式のサブスレッドが欲しいです。＞ 中の人
仕組みの考慮は必要ですけど。
恐らく読者も多いと思うのですが
ファンを取りこぼしちゃ勿体無いですよね ＞ やはり中の人
WhiteBall
反響の大きさが、皆さんの『「マネージャ」への期待度』、『「マネージャ」の定義の不透明さ』を物語っている気がします。
よく建築業と比較されるIT業界ですが、太古の昔から営まれている建築業のように確立された構築手法が無いことが原因なんでしょうか。
例えば、引数を2つ渡して足し算をするプログラムを作って欲しい、といわれても、プログラムの作り方は人それぞれ。
これが厳密に取り決められていれば、もう少しマシなんでしょうか。
けど、西暦以前からある建築業に対して、ここ100年（もないのかな？）くらいのIT業界なんて、成熟していなくて当たり前なんですけどね。
2000年後のIT業界には「一級システム構築士」や「一級プログラム開発者」というような国家資格が無いとシステムが作れないようになっているといいなｗ
（そしたら、プログラムの単体テストをしない、というような悪徳業者がニュースになったりして＾＾；）
banana
お目汚しですが、私に関するコメントの一部について書かせてください。
>最終的に失敗をした人間に責任を押し付ける事に疑問は無いのか？
上流工程やマネージメントの失敗を
SE・プログラマが尻拭いしている現状は問題だと思っています。
あまり慰めにはならないでしょうが、
失敗プロジェクトのマネージャーも責任追及はされます
（ユーザ企業は内情を社外に教えないため知らないと思います）。
>あまりSE・PGに期待しないでくれ。と、言いたくなります。
気持ちはよくわかる。
世間はシステム開発をテクノロジーの世界の属する作業と見ている。
よいプログラムは機械的に大量生産できるようなものではないのに、
SE・プログラマは良いものをより安くという圧力を
もっとも厳しい形で受けている。
また、システム開発とコーディングは別物ですが、
そのあたりが十分認知されていない事によるしわ寄せも
SE・プログラマに来ていると思う。
日本生まれの日本育ちなら大抵、日本語で文章が書ける。
しかし、日本語が書けるというのと売れる文章が書けるというのは全く別物。
SE・プログラマはいわば、プロのライターであることが求められている。
当たり前といえば当たり前ですが、
そこを十分に教えられた人がどれくらいいるか。
> ……これはひどい。
言ってくれる。
よーし、大手SIerさん、高杉上級SEも入れて
今度一緒にプロジェクトやろうぜ。
banana
注意したつもりでしたが、また、長文になってしまいました。
すみません。
# 空白行がいっぱい。ミスった。
しん
bananaさんの帳票の例だと、テストで帳票を出力する時点で出力内容を利用部門に確認してもらえば済む話ではないのかな。
帳票出力テストの際に利用部門にチェックをしてもらうのを怠っていたのであれば、それをしなかったマネージャーの怠慢でマネージャーの仕事ができていなかったと反省すべきだと思う。
他人の愚痴を言う前に、自分のミスについて謙虚に反省しないのか不思議だよ。
また、利用部門が不安になっているのであれば、利用部門に頭を下げて全部の帳票を確認してもらうなどやりようはある。
こういうのも『仕様書書きとコーディング以外のシステム開発の世界』だと思う。
あと、システム開発やプログラミングが分からないマネージャーについての意見があったけど、システムが分からないのであれば、協力会社だろうが後輩だろうがシステム周りに詳しい人に頭を下げてお願いするべきだと思っている。
開発がうまくいくことが大事なのであって、個人のちっぽけなプライドなんて不要だし、言い方は悪いけど頭下げるのなんてタダなんだしね。
そして、後は利用部門や開発部門などがうまく協力できるような態勢づくりに注力すればいい。
上流工程と下流工程は単なる作業の違いだけで、どちらがかけてもうまく仕事が回らないと説明しているのだが、うちの後輩みたいに上流工程しかやったことのない人は平気で下流工程を見下すので困る。
そういうのって、本人にその気がなくても、言葉の端々から出てしまうんだよね。
上流工程とか下流工程って訳がそのの原因のような気がするから、別の呼び方が定着するとうれしいと思っているんだけど、いい言葉は無いかな。
あんまり偉そうには言えないけど、「実るほど頭垂れる稲穂かな」という姿勢に学ぶところは多いと思っている。
banana
この障害は例であって、フィクションであることを確認しておきます。
状況を補足すると、
利用者部門のテストはクリアしていて押印済みのエビデンスもありました。
では利用者がなぜ気がつかなかったかというと、
セキュリティ上の理由から開発・保守作業ではダミーデータを使うことになっており、
テストで出力した帳票の製品コード欄に出力されたフラグの値が
たまたまダミーデータと一致していたため、誰も気がつきませんでした。
>利用部門に頭を下げて全部の帳票を確認してもらうなどやりようはある。
私なら無理。
利用部門に頭を下げたところで、
「まず情シスがバグがないことを確認するのが先じゃないでしょうか」と
すっぱり断られます。
利用部門にとってテストというのは本業以外の雑務です。
> 自分のミスについて謙虚に反省しないのか不思議だよ。
耳が痛い。
確かにそのとおりです。
本番システムのデータを使えなくなったことで、
バグの発見が難しくなることはマネージャーとして
当然予想できるリスクでした。
しかし、私がこの架空の障害の場にいたとしても
何もできなかったでしょう。
セキュリティという理由は強いですから。
で、ダミーデータを使うことによるバグ混入のリスク対策もできず、
SE・プログラマのがんばりに頼りきりになったと思います。
自分の非力さに嫌気がさしている
くたびれたおっさんマネージャーは
結構いると思います。
bananaさんの言っていることは別に間違っていないとは思うのですが。
世の中が全部自分でやれば上手く行くと思うなら、
全員起業でもすればいいのですが。
得意不得意があるから、
社長がいて、マネージャーがいて、技術者がいて、
お互い補いながら仕事をする。
それでいいと思うのですが。
なのですけれど、
実例を聞いていると、どうも素直に賛同しにくい。
いかにも旧態依然っぽいやり方で、
これではセキュリティなどの新しめの要求には答えられないだろうという気がします。
自分がわからないなら誰かに聞けばいいのに。
マネジメントはマネージャーに任せろと言っておきながら、
技術のことを技術者に聞いてないのではないでしょうか。
それとも、技術者の側にも、現状改善の志を持つ人がいないのでしょうかね。
誰も状況を変える気がないのなら、
時代とともに問題は徐々に増えていくことでしょうけれど。
hoge
量のbananaさんに、常に最上の目線からの大手SIerさん（どこなんだよｗ）
いやあ楽しいですなｗ
まさに「お前がそう思うんならそうなんだろう、お前ん中ではな」状態に見えなくもないです。
banana
実例じゃないって・・・
そこはよろしく。
ほんとにどうすればいいのか。
もともと大量のドキュメントを要する重厚長大なプロセスを採用していたところに
ISO、JSOX、内部統制だのが重なって窒息しそう。
海の向こうのManager連中は本当にこんな要求事項に対応できているのか。
なんでみんな悪意はないのにこんなつらい。
こんなとこで愚痴っている自分はほんとに正常なのか。
罪滅ぼしにボルネオで植林でもしたほうがいいんじゃないか。
少なくとも一ヶ月は本当に書き込みやめることにします。
今日は仕事しなくちゃ。
お騒がせしました＞作者さま＆読者さま
noName
コメント欄が酷い・・。
前からわかってたことだけど、こんなのが幅を利かせてるようじゃこの業界に未来はないわ。早めに逃げて正解だった。
まともなスキルのあるプログラマならたいていの国で働けるので、英語を勉強してさっさと海外に逃げ出したほうがいいよ＞all
もちろん他業界に逃げてもいいと思うけど。
海外ではプログラマはきちんと専門職として扱われて、そこそこの給料をもらいつつゆったりした暮らしができますよ。
any
現実的にできないことをやれっていうマネージャーは無能だと判断しています。
「無駄」「面倒くさい」「手間」等のやめよーよ的な事が言える人じゃないとね。