ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。

高慢と偏見(9) 誰がスケジュール遅らせた? それはあなたとプロマネは言った

»

 その日の午後、三浦マネージャは何かの会議から険しい顔で戻ってくるなり、全開発メンバーを招集した。たまたま平良さんは私用のため、午後になってから出勤することになっていた。

 「知ってのとおり、スケジュールの遅れがかなりひどいことになっているね」三浦マネージャは私たちをにらみつけた。「正直なところ、私は君たちに失望したよ。この程度のプロジェクトもまともに進められないほどスキルが低いとはね。もう少し高い単価に見合った仕事をしてほしいものだね。オブジェクト指向なんかにこだわってるからこういうことになるんだ」

 室温が一気に急降下したみたいだった。相変わらず人の神経を逆なでするのが天才的にうまい人だ。

 どうせ上の人からスケジュール遅延を責められて、その責任を私たちに転嫁しようとしているに決まっている。

 ――誰のせいで遅れてると思ってるんだ。

 メンバー全員の敵意に気付いているのかいないのか、ひとしきりスケジュール遅延について文句を言ったあと、三浦マネージャはこう続けた。

 「そこで、この遅れを取り戻すために、今日からスケジューリングの方法を見直すことにしたので、これに従うようにね」

 全員にA4用紙が配布された。そこには新しいスケジューリング方法の概要が載っていた。

 まとめるとこうなる。

 1. 実装担当者は、機能単位の実装を開始する前に、実装工数の見積もりを出す。

 2. 三浦マネージャがその見積もりをチェックし、承認したら実装作業に入る。

 3. 毎日、昼と退社時の2回、見積もりに対しての実績工数を記入する。

 4. 見積もり工数を実績工数が超えてしまったら、その原因を報告する。

 そして、

 5. 見積もりを超えてしまった時間数は、勤務実績時間とは認めない。

 ――なんじゃこりゃ?

 私は、穴が空くほどスケジューリング概要を見つめた。

 いま使っているスケジュール進捗管理は、予定実装期間として線を引き、その下に進捗の割合に応じて実績の線を引いていく、というありふれたものだ。ただ、何日も進捗率75%で足踏み、ということがよくあるので、大まかな目安以上のものではなかった。

 確かに新しいスケジューリング方法は、その欠点を克服している。進捗度合いがより明確になるし、実装者が予定を決めるので精度も上がるかもしれない。

 でも……

 5. 見積を超えてしまった時間数は、勤務実績時間とは認めない。

 これはいくらなんでもむちゃくちゃだ。

 そもそも、これを導入したからといって、スケジュール遅延が解消するわけではない、ということに三浦マネージャは気付いていないんだろうか? 全員が同じ疑問を抱いているらしく、室内がざわめいた。

 「ちょっといいでしょうか」アツコさんが手を挙げた。「勤務実績時間とは認めないってどういうことでしょう?」

 三浦マネージャはアツコさんをじろりとねめつけた。

 「読んで字のごとくだよ」

 「実績時間として記録するな、ということですか?」

 「それ以外に意味はないだろうね」三浦マネージャは見下すように答えた。

 「契約的に不当ではないですか?」アツコさんの口調はだんだんきつくなってきている。

 厳密に言えば契約的に不当ではないはずだ。私たちの常駐単価は月単位で決まっているのだから。月の最低労働時間は守る必要があるけど、それは普通に 10時から17時まで勤務していれば達成できる。それでも毎日の勤務時間を細かく記録しているのは、K自動車側から厳しく言われているからだ。労働基準法に関することらしいが、詳しいことはよく知らない。

 私たちにとって、というより、私たちの会社にとって重要なのは、その勤務実績を次の常駐の際に交渉材料として使用できることらしい。これは営業の黒野が言っていたことだが。

 「スケジュールが遅れるということはシステムの完成が遅れるということだ。その場合、不利益を被るのは誰かな? 君たちじゃないだろう。うちの会社なんだよ。なのに、君たちのスキルが未熟なせいで伸びた時間まで実績として認めろというのかね? それこそ不当だと思わないのかね」

 ――あんたが余計な口を挟まなきゃ、今ごろオンスケで進んでたんだってば。

 普段はクールなアツコさんも、さすがに忍耐というキャッシュがあふれてしまったらしく、険悪な口調で言い返した。

 「お言葉を返すようですが、あなたがプロマネになるまでは、ここまで遅れていませんでしたよ」

 「はあ? どういう意味だね?」

 「スケジュール遅延の原因があたしたちばかりにあるような言い方をされていますが、もっと根本的な原因があるのじゃないですか、と言いたいんです」

 何人かが、同意するように頷いた。私も思わず頷いていた。

 「根本的な原因とは何だね?」

 「わざわざ効率が悪いコーディングを強制したことです」もはやアツコさんにためらいはなかった。「不要な設計書やバグ表の作成を追加したことです。新たに共通クラスを作成することを禁止したことです」

 「私はそうは思わないね」まだ上から目線で話す余裕は見せたものの、三浦マネージャの口調も険しくなっている。「私が正しい方向に軌道修正したからこそ、遅れがこれぐらいで済んでいるんだよ。そうでなければ、今ごろ、もっとひどいことになっていただろうね」

 ――なんで? なんでそうなる?

 「そうおっしゃる根拠がまったく分かりませんが」

 「ああ、君にはまだ分からないだろうね」明確な嘲笑だった。「経験が足らないんだから仕方がないがね。オブジェクト指向なんてうさんくさいものに関わるとろくなことがないんだよ。これは私の20年の経験から言うんだから間違いない」

 ――出たよ、20年の経験。っていうか、あなたに「経験が足らない」なんて、死んでも言われたくないよ。

 確かに社会人としての経験、エンジニアとしての経験は、ここにいる誰よりも三浦マネージャの方が圧倒的に上だろう。だけど、この人は自分が理解できないものを「使えないもの」と決めつけ、あまつさえそれを強制しようとしている。実装効率や、メンバーのモチベーションや、今後のメンテナンスなどお構いなし。自分が理解できない世界を、理解しようと努力するわけではなく、世界の方を自分のレベルまで引きずり下ろそうとしているだけだ。

 自分のスキルを高める努力を怠るのは勝手だと思う。しかし自分の立場を利用して、自分の狭隘な世界観を他人に押しつけ、うまくいかないとなると他人のスキルが低いせいにする。これはもう、エンジニア能力以前に、社会人として、人として尊敬に値する要素が1ビットすら見つからない。

 私の斜め前に座っているメンバーが手を挙げた。最初のコードレビューでボロボロにされた富永さんだ。

 「よろしいでしょうか?」

 富永さんの顔は怒りのためか紅潮している。

 「なんだね」

 「ぼくも星野さんの意見に賛成です」富永さんも覚悟を決めたようにはっきり発言した。「われわれが力を発揮できていないとしたら、あまりにもムダなコーディングやドキュメント作成が多すぎるからです。これを変えない限り、スケジューリング方法をいくら変えたところで意味はないと思います」

 今度は、ほぼ全員が頷いた。頷いていないのは、後から投入された「新人くんチーム」の6人だけだった。

 「まったく」三浦マネージャは、わざとらしく嘆息した。「ああしてたらよかった、こうしてたらうまくいってた、なんて仮定の話をしても仕方がないだろう。私には負け惜しみにしか聞こえないな。私のやり方を君たちが気に入らないのは分かるがね。君たちのやり方に任せていたら、もっとひどいことになっていただろうね」

 ――だから、なんでそうなる?

 「繰り返しますが、まったく根拠が分かりません」とアツコさん。「三浦さんがいらっしゃる前は、スケジュール遅延はこれほどではありませんでした。そのやり方がダメだという根拠を聞かせていただかないと納得できません」

 「なんで君を納得させる必要があるのかね?」三浦マネージャは鼻で笑った。「別に君が納得しようとしまいとどうでもいいんだよ」

 「な……!」

 「だいたい業者の分際で、客の私に意見するとは、何様のつもりだね、君は?」

 マンガならアツコさんの頭の中で、プツンと何かが切れた擬音が浮かんだだろう。

 室内は静まりかえり、次の瞬間、抑えられない怒りの声が一斉に沸き起こった。5月からずっと、かろうじて心のどこかに待避させてきて、しかし決して消えることのなかったさまざまな感情が、とうとう臨界点に達し、一気に噴出しようとしていた。

 もはや全員が三浦マネージャに対する怒りと侮蔑を隠そうとしなかった。私だって同じだ。もう我慢の限界を超えた。今、自分の顔を鏡で見たら、子供には決して見せたくない表情が映っていただろう。

 何人かの男性メンバーが腰を浮かせている。何かのキッカケで三浦マネージャに物理的な暴力をふるってもおかしくない。私は、離婚した元夫がキレやすい性格だったこともあって、この手の「カッとなった」暴力を心から嫌悪していたが、このときばかりはやめてほしいとは思わなかった。それどころか、三浦マネージャが暴力の被害にあうことを望んでさえいたかもしれない。

 さすがの三浦マネージャも顔色を変えた。それでも「私は客だ。偉いんだぞ」という態度を崩そうとはしなかった。

 激昂したアツコさんが何か言いかけたとき、

 「遅くなりました」

 穏やかな声とともに平良さんが入ってきた。

 まるで外で様子をうかがっていたんじゃないかと疑ってしまったぐらい、実に絶妙なタイミングだ。三浦マネージャもアツコさんも、気勢をそがれたように口を閉じた。一触即発だった室内の空気も、平良さんの登場で、ひとまず緩和するのが分かった。

 平良さんはゆっくりと空いている席に座ると、隣に座っていたメンバーから手短に経過を聞いていたが、やがてうなずくと挙手して発言を求めた。

 「1つ提案があります」

 「ああ、言ってみたまえ」まだ尊大さが残っているものの、人を見下すような口調は消えている。

 「三浦マネージャが決められた一連のルールをAとします」平良さんはゆっくりと話し始めた。「それ以前に私たちが採用していたプロセスをBとします。どちらも相手の方法に納得していないのが現状だと思います。そういう認識で合っているでしょうか」

 「ああ、まあ、そういうことだろうね。ただ、どちらが優れているかということは証明できないと思うね。それなら、私は自分の経験に基づいて、自分が信じる方を選ぶだけだね」

 「そこです。その証明を試してみませんか?」

 「どういうことだね」

 「もうすぐS系部品納入時チェック機能の仕様がまとまり、実装を始めることになります。それを2チームで同時に作成するというのはどうでしょうか。もちろん、コーディングルールなどに一切の制約を課さないという条件で」

 「同じ機能を2つ作るというのかね?」三浦マネージャは疑わしそうに言った。「それで何か分かるかね? どちらかが早くできたからといって、それが証明になるとは思えないがね」

 三浦マネージャに同意するのは悔しかったが、私も同じ疑問を抱いていた。

 「それでもやってみる価値はあると思います」平良さんは譲らなかった。「お互いにある程度は納得することができるでしょうし、何よりも、ここまでモチベーションが下がってしまっては、プロジェクトの完成に影響を及ぼすのではないでしょうか」

 平良さんは脅迫めいた言葉をさりげなく口にした。

 ――いやいやいや、三浦マネージャが納得するとは思えませんけどねえ。

 三浦マネージャは少し考えた。

 「その証明とやらは、具体的にどうやるのかね」

 「Aチーム、Bチーム、それぞれ5人ずつのメンバーで同時に開始するというのはどうでしょう? それぞれに新人さんを3名ずつ含めます」これを聞いた新人くんチームの6人は不安そうに顔を見合わせた。

 「残りの2人は?」

 「Aチームは三浦さんが選んでください。Bチームは私が選びます」

 「どうやって勝敗を決めるのかな?」

 「作成期間と機能そのものの出来具合でどうでしょう」

 ――また曖昧な……いっそジャンケンで決めればいいのに。

 「ふーむ。これが何かを証明するとは思えないがねえ」

 三浦マネージャは沈思黙考したが長い時間ではなかった。ここで無下に平良さんの提案を却下したら、敵意の集中砲火が再開するのが分かっていたのだろう。

 「まあ、いいだろう。そこまで言うならやってみようかね」

 「ありがとうございます」

 「じゃあ私がまずチームを選ぶが、いいかね?」

 「どうぞ」

 三浦マネージャは、まず新人のうち3名を選んだ。それから外注メンバーを見回した。

 私が選ばれませんように、と心の中で祈ったが、たぶんその可能性は低かったのだと思う。三浦マネージャ以前/以後のコードを書いた私だから、「こいつもオブジェクト指向かぶれか」とでも思われているに違いない。多少なりとも自分に従順なメンバーを選ぶだろうから、アツコさんと富永さんを選ぶはずがないことは言うまでもない。

 結局、三浦マネージャは、私があまり話したことがないメンバー2人を選んだ。少しでも年上の方がいいとでも思ったのか、2人とも40代の男性だった。

 平良さんが最初に選んだのは、若槻さんという男性メンバーだった。三浦マネージャ以前に、数々の共通ロジックをきれいに作り上げていた人だ。無口な人だが頼りになる。

 そして、次に選ばれたのは、

 「え、私ですか?」

 なぜか私だった。

 「そう。頼めますか?」

 ――うう、正直いえばあまりやりたくはないんだけど。

 「はい、分かりました」

 とても辞退できる空気ではなく、その理由も見当たらなかった。

 「お願いします」平良さんはいつもの穏やかな笑みを浮かべた。

 ――てっきりアツコさんか富永さんを選ぶと思っていたのになあ。

 そのアツコさんは、親指を立ててサインを送ってくれた。「がんばれ!」とでも言っているに違いない。私は曖昧に笑い返しておいたが、頭の中は混乱していた。

 (続く)

 この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。

Comment(15)

コメント

EI

読み物として楽しんでいる者です。

なんか主人公の性格設定が支離滅裂になってきた気が。
「後先考えず、手加減なしで営業の顔面を殴りつけたこと」があり
あまつさえ「そのことをネタにまた殴るぞと脅しつける」ような人間が
「この手の「カッとなった」暴力を心から嫌悪している」んですか?

何回読んでも良くわからなかったんで幾つか理由を考えてみましたよ。

1.お前(読み手)の日本語読解能力に問題があるだけ。良く読めば何の矛盾も無いことがわかる。
2.一見して一人称視点で書かれているが、「私」の中の人が入れ替わることによる重大などんでん返しがある。今は深く突っ込むな。
3.結局この業界にはイカレた人間しかいないじゃん。お前ら面白がって読んでるようだけど我が身を顧みろよという事が言いたい。
4.建前はあっても結局その瞬間の感情が全てという、ある意味弱い人間にありがちな属性なので何の問題も無い。
5.アダルトチルドレンの如く、暴力を嫌っていてもその影響下から逃れられない主人公の苦悩を鋭く描き出している。(つまり1か?)
6.年末年始で間があいたので忘れてた。現実は平凡である。
7.フィクションの名を借りてオブジェクト指向を否定する哀れなカスを血祭りにあげたいだけなので細かいことはどうでもいいです。

EIさん、どうも。

まあ登場人物も作者も含めて、人間はみな矛盾だらけの生き物である、ということで。

GOGOチアガール

EIさん

 そんな意外なツッコミにへぇ~と思いつつ、同属嫌悪ってヤツじゃないでしょうか?

> 7.フィクションの名を借りてオブジェクト指向を否定する哀れなカスを
> 血祭りにあげたいだけなので細かいことはどうでもいいです。

だとしても面白いからいいじゃないですか。
ちなみに哀れなのはカスではなく振り回される開発者と予算に絡む人と
利用者ですね。

業界的には件の人(三浦マネジャですよ)の例が珍しくもないのがまた。。。


ま、私的にはこのコラムは完成度が高いし面白いので、今後の経過とオチを
楽しみにしています。

EI

>リーベルGさん

了解です。まぁ「信頼できない語り手」手法だったとしても
そんな事言えませんしね。

>GOGOチアガールさん

や、最初に書いたとおり読み物として楽しんでいるので7だったとしても
(物語の完成度的には残念にしても)別に何とも思いません。

まぁ最後の2行に同意しますということで。

AC/DC

例のstaticおじさん、とうとうここに書かなくなったね。
かわりに、自分のとこで、
http://wonderfulsky.web.fc2.com/memo.html
オブジェクト指向についてもっともらしいこと書いてる。
掲示板に批判的なコメント書けばすぐに削除するわ、賛同するコメントだけは残すわ、言ってることは相変わらず知識不足丸出しだわで、もう始末におえない。
情けない人だね。

ヤス

良い感じに話が進み始めて面白くなってきました。
IT系が土方なのは平良さんの様に上と戦う覚悟がないからではないのか、
と最近考えてきています。
ひでみさんのコラムの話ではないけれど、後になって「こうなるんじゃないかってずっと思っていました」っていう人がこの業界には多いのではないだろうか。
自分自身も考えて実践できるようになりたいものです。
(もちろん、いつか自分が若手に同様の事をされる可能性があるのは覚悟の上で。そうならないように技術には敏感でありたいものです)

AC/DCさん
いちいち書くのもめんどくさいので黙っていたんですが、いい加減に生産性のある話をしてはどうでしょう。
人が間違っていると思うんだったら自分でコラムを書いて間違いを訂正するようなものを書くとか、何なりすれば良いのに。少なくともほかのブログとかでも粘着行為じみた事をだらだらやっているよりは人の為になると思いますが、どうでしょうか?
三浦マネージャに教育された新人みたいな人も良いものを読めば何かが変わるかもしれない。三浦マネージャを罵倒するよりも後進を育てる方がよっぽど有効だと僕は思いますが?
(個人的にはその人の業務で使わない知識を無理して覚える必要はあるのか?という疑問はありますが)
以上です、返信は不要ですが返信する場合はここでやるよりも、(コラムの邪魔にならないように)会議室とかに部屋を作ってもらえれば返答いたします。

以上失礼しました。

AC/DCさん、ヤスさん、どうも。

AC/DCさんなりに、例の人のことを危惧されているというか、義憤に駆られているのであろうことはわかりますが、放っておくのが一番じゃないでしょうか。普通の感覚を持ったエンジニアさんが読めば、わざわざ相手にする価値はないとわかると思うので。

AC/DC

義憤というよりあまりにも内容が幼稚なので笑えるネタを提供しようかと思っただけなんだけどね。
まあ確かに非生産的ではありますな。
失礼しました。

ONEOUTS

疑問なのは、三浦マネージャーがオブジェクト指向をどうやって学ぼうとしたかということなんですが。独学でしょうかね。大企業のマネージャーなら、外部の研修費用ぐらい出してくれると思うのですが。
ある程度年齢を重ねると、自分より若造の講師なんかに教わるのがいやなんでしょうかね。

もっとも、あの人が言うには、
[quote]オブジェクト指向教育、特にポリモーフィズムに関しては、デザインパターン本や大学の先生の講義まで、ビジネスになってますよね。デザインパターンの話をすれば人から尊敬されると思っているプライドが高いかたもいます。誰も簡単にわかる本とかレクチャーなんてしませんよ。むしろ簡単に説明してしまったら皆さん困るでしょうね。良い本がなく、本当にわかる人なんていないと思ったほうがよろしい。[/quote]
だそうです。出展はあの人のサイトの掲示板です。
よい本はたくさんあるし、よい先輩方もたくさんいらっしゃると思うのですがね。

ONEOUTS

訂正
(誤)出展はあの人のサイトの掲示板です。
(正)出展はあの人の近況で、ヤスさんのコメントに対する意見のようです。

どうでもいいことでしたね。
失礼しました。

ひろし

ココでstaticオジサンをいじってもしょうがないというご指摘もありましたが、別途マイナーなブログ等で書いても書きちらかしで終わってしまうでしょうし、彼もココを見ているようなのでココで書いたほうが効果的だと考えるので、あえてココに書かせて下さい。

デザインパターンは皆が使うメリットがあるから「パターン」になるわけであって、staticオジサンの言っている例は全くもって頓珍漢(単にレベルの低いオブジェクト指向教科書をなぞっているにすぎない)。あれこそアンチパターンかと。まあリーベルGさんにとってはネタが増えてよかったね、と。

GoFが泣いてるよ...

AC/DC氏ではありませんが、staticオジサンに対しては、義憤というより、本質を理解できてない人に逆ギレされて反論している気分。いちおうソフトウェア関係で教鞭を取っていたりもするので。「良い本がなく、本当にわかる人なんていないと思ったほうがよろしい」なんて、酷すぎ。自分の無理解を棚に上げて、他人のせいにするなんて...。まあ幸にして今のところ素直な学生に恵まれており、直接自分のところに被害は及んでいないのですが、staticオジサンみたいな学生が現れたらどう対応すべきか。まあ正論で対応すればよいわけですが、徒労感が残りそう。あと新人教育してる三浦マネージャーのようにならないように、自戒を込めて、本コラム楽しんでおります。毎週、楽しみにしていますよ。

ひろし

追記です。気に障ったらすみません。

「デザインパターンの話をすれば人から尊敬されると思っているプライドが高いかたもいます。誰も簡単にわかる本とかレクチャーなんてしませんよ。むしろ簡単に説明してしまったら皆さん困るでしょうね。」

教職に携わる者を馬鹿にしてますよ。悲しくなってきた...

ひろしさん、どうも。

私自身は基本的にコメントの内容に制限をかけるつもりはありません。誰かが間違っていると思い、そのメッセージを伝えるのに、このコメント欄が最適だと思えば、何を書いていただいてもかまいません。

最低限、誹謗中傷や暴言のたぐいの発言は控えていただければ。

これは、コラムの最初の1章をサンプルとして送ったときに、@IT編集部の方から言われたことなのですが、あまりに荒れるようならコメント欄閉鎖等の措置を取るとのことです。

今のところ、そういうコメントは皆無なので安心しています。

Gleichgewicht

@ITのメルマガに紹介されていて、先週のお昼休みにすこしずつ読み進めました。
わかりやすく丁寧な文章、ぐいぐいと読み手を引き込むストーリー展開、楽しく読ませていただきました。

三浦マネージャがオブジェクト指向を難解なものと思い込んでしまったり、実業務では役に立たないと断じてしまうのは、世に公開されている数々の素晴らしいコードを見たことがないからではないでしょうか?
適切に設計され、シンプルさを保っているコードは、扱いやすく品質も高いものです。さらに、テストやメンテナンスに要する人数や時間が大幅に短縮されるのですから、マネジメントの観点からしても嬉しい話のはずです。
つまり、三浦マネージャは「素晴らしいオブジェクト指向のコード」に出会ったことがなくて、パラダイムシフトを迎えていないだけでは、と。
それとも、もし眩しい光に目を瞑ってしまって、硬い殻を被って生きることを選んでしまったのなら、とても悲しい話です。

コラムの趣意とは異なるのかも知れませんが、プロジェクトメンバーのスキルを標準化するために、コードレビューは大切と考えています。
ただし、レビュアーのスキルが極端に低いと「自分が理解できない世界を、理解しようと努力するわけではなく、世界の方を自分のレベルまで引きずり下ろそうとしている」だけになってしまいますね。

これからも続きを楽しみにしています。
長文コメント、失礼しました。

Buzzsaw

まぁ自分もstaticマンの立場だったら、「”人間”クラスを継承して”山田さん”クラスを作りましょう」みたいな説明を受けたらその段階で「ハァ?何いってんの!?」ってさじを投げてしまいそう。

こっちとしてはDBまわりや入力チェック、GUIまわりの話がどうなるのかが気になって仕方ないから。

かといって”当時の”書籍や研修が、設計→コーディング→仕様変更→リファクタまでカバーしていたとも思えないし。

って、誰に対してここまで勝手に思ってあげてるのかしら、あたし・・・?
とにかく、反面教師として活用させていただきます。
あぁ、アツコさんのドライカレー食いてぇ~。腹減った。

コメントを投稿する