冷たい方程式（8） 細部に宿るのは神か悪魔か
9月の最後の週。来週から下期だというのに、秋が近づいてくる気配すらない。同じように設計フェーズの終わりも見えてこなかった。
スケジュール通りであれば、すでに詳細仕様書は全て完成していて、渕上マネージャの最終チェックの後、実装に入っているはずだった。もちろん、そんな無茶苦茶なスケジュールを遵守できるわけがなく、10月1日時点で完成している仕様書は、わずかに8画面分だけだった。
遅れている理由は、渕上マネージャの要求水準が、あたしたち関係者全員の予想をはるかに超えて厳しかったからだ。
9月中旬、ホライゾンシステムが作成した最初の画面の仕様書一式がメールで届いたので、あたしは簡単に中身を確認した後、プリントアウトを渕上マネージャに渡した。
「チェックお願いします。職位マスタメンテナンス画面の仕様書です」
渕上マネージャは、無言でプリントアウトを受け取ると、ちらりと見ただけで突き返してきた。
「作り直しだ」
「え、何か変ですか？」
「表紙がついていない」渕上マネージャは、あたしの顔を見ようともしなかった。「タイトルと作成日、バージョン番号、作成者を明記させたまえ。常識だろう」
細かいな、と思いながらも、あたしはムツミさんに電話して、渕上マネージャの要求を伝えた。
10分後、表紙のExcelファイルが送られてきた。あたしは急いで印刷すると、さきほどのプリントアウトの上に載せて、渕上マネージャに渡した。
渕上マネージャはページを数枚めくっただけだった。
「やり直しだ」
「……何がまずかったですか？」
「目次がない」
「……」
たかだか20ページあまりの仕様書に、果たして目次が必要でしょうか、と訊くのは時間のムダだからやめた。あたしはまたもやムツミさんに電話して、目次を作ってくれるように頼んだ。あたしが自分で作って、あとでムツミさんに送っておけば早いけど、そういう行為は渕上マネージャによって禁止されている。
15分後、今度は、一式まとめて送られてきた。目次を作るということは、各ページにページ番号を振る必要があるからだ。
そのまま渕上マネージャに転送すれば印刷する手間が省けるのだけど、仕様書類は全て印刷するように厳命されている。仕方なく、全ページを印刷し直して、渕上マネージャに渡した。
「お願いします」
その仕様書が渕上マネージャの手元にあったのは、45秒ぐらいでしかなかった。
「却下だ」
「今度は何ですか？」さすがにうんざりしてきた。
「ページ番号がずれている」
取り戻した仕様書をめくってみると、確かに、6ページが抜けている。でも……
「あの、多少の記述ミスは置いておいて、内容の方をチェックしていただけないでしょうか？」あたしは提案してみた。「時間の節約になります」
渕上マネージャは、ようやくあたしの顔を見た。
「君は品質確保ということを、どう考えている？」
「品質……ですか？」
「そうだ。品質の確保だ」
「さあ……」少なくともページ数の抜けを、嬉々として指摘することじゃないのは確かだ。「……よくわかりませんが」
「こういう細かい部分に気を配れない人間に、高品質な設計などできるはずがない」
――ちょっとズレてないか？
「ちょっとしたケアレスミスだと思いますけど」あたしは反論した。「誰にでもあるミスです」
「その些細なミスが、休憩時間の計算ロジックや、労働時間の計算ロジックで起きたらどうなるのだ？」渕上マネージャはあくまでも冷静すぎるほど冷静だった。「結果として、社員に支払われる給与額に違いが生まれる。それでも、君は、誰にでもあるミスだと言うのか？」
「書類の作成ミスと、プログラムのバグでは、次元が全然違うと思いますけど！」
いかん。つい、熱くなってしまった。フロアのあちこちで、何人かが何事かとこちらを見ている。
「君の意見はよくわかった」渕上マネージャは、しかし、すでに興味を失ってしまったようだった。「とにかく内容以前の問題だ。やり直し」
そんな調子で、渕上マネージャは、ムツミさんが送ってくる仕様書の内容にダメ出しを続けた。
曰く、「ロバストネス図の矢印の太さがバラバラ」
曰く、「クラス図のクラスボックスの大きさがまちまち」
曰く、「機能説明の主語が明確ではない」
曰く、「文の終わりの句点とピリオドが混在にしている」
曰く、「アルファベットの全角と半角が混在している」
どーでもいいことばかりだ。だいたいロバストネス図なんて、分析のために裏紙にでも走り書きする程度のもので、こんなにきれいな永久保存版を作る必要などないだろうに。
ただし、公平な目で見るなら、渕上マネージャは悪意があってアラ探しをしているわけではないようだった。完璧主義というか、お役所的というか、とにかく細部がきちんと整っていないと我慢ができないらしい。
それだけなら、あたしもムツミさんも、何とかやりすごせたかもしれない。表面的には唯々諾々と指摘された箇所を訂正して、「技術のわからない管理者だから、そういうところにこだわるのよねえ」とか陰口を叩くとかして。
何度めになるのか数えるのも面倒になった修正版を見せたとき、さすがにアラ探しのネタが尽きたのか、ようやく渕上マネージャは処理の内容に目を通し始めた。やれやれ、これで少し先に進むか、と思ったとたん、またもや仕様書が差し戻された。
「やり直しだ」
またですか、と言いたいのをぐっとこらえた。
「どこでしょう？」
「社員種類によって必要な権限が決まるだろう」
「はい」
「その処理の定義がない」
「は？」あたしは意味をつかみかねて、渕上マネージャの顔を見た。
職位マスタには、社員種類という列があり、種類の指定によって操作できる画面の項目などが変わってくる。そのことを言っているのだろうか。
「そういう処理は、だいたいupdateメソッドの中に定義されるはずですが」
「そうではない。種類によってstrategyクラスを定義するべきではないかね」
「ああ、そういう意味ですか」つまり、Strategyパターンを使用しろ、と言っているらしい。「でも、2、3種類ですから、わざわざStrategyパターンを使うほどでは……」
渕上マネージャは侮蔑の視線を投げつけた。
「君はそれでもプロなのか」
「一応、そのつもりですが」
「プロなら、if文やswitch文を安易に使うことを恥だと思いたまえ」
――はあ？
「やり直しだ。strategyを定義するよう伝えたまえ」
そんな大げさなロジックでもないんだけどな、と思いつつ、あたしはムツミさんに連絡した。
「すみません。また仕様書のことなんですが……」
ムツミさんは、さすがにうんざりしたような声になりながらも従順に了承したが、その後で、八木社長が電話を替わった。
『この仕様書だけで、もう2日以上かけているんですよ』八木社長も困り果てた声だ。『何とかなりませんか？もともと、どこまで書くかという取り決めもなかったのに、これでは……』
八木社長が省略した残りの言葉は、あたしにもよく理解できた。2日という工数だけ決められて、仕様書の内容に後から文句をつけるのは、普通に考えればアンフェアそのものだ。最初に、必要な仕様書のサンプルを提示し、その見積を求めるのがフェアだろうに。材料費300円で牛丼を作れと命令しておいて、できあがってから「九州産の黒毛和牛と北海道産のタマネギを使ってないのはおかしい」と文句を言うようなものだ。
とはいえ、コストカッター渕上からすれば、これが正しいやり方なんだろうけど。
「あたしも何とかしたいんですけどね」向かいの席の渕上マネージャは席を外していたが、あたしは声を小さくした。「うちのためにも」
開発グループで作成する分については、あたしか、亀井くんが仕様書を作る必要がある。そのとき、ここまで細かい仕様書を作成する自信は全くない。
「でも何ともしようがないんですよね」
『それでは、今日か明日にでも、一度レビューの時間を設定していただいて、まとめて指摘してしてもらうというのはどうでしょう？』
「そうですね」少なくとも時間の節約にはなる。「一応、話してみます。またご連絡します」
渕上マネージャが戻ってくるのを待って、八木社長の提案を話してみた。案に相違して、渕上マネージャはあっさり了承した。
「では、今日の夕方でもよろしいですか？」
「ああ、任せる」
「30分の残業時間を超えてしまうかもしれませんが……」
「やむを得ないだろう」渕上マネージャはあたしを見た。「そのかわり、オーバーした分は、明日以降で調整したまえ」
あたしは早速、八木社長に連絡し、時間を決めた。18時30分からという、いつもなら渕上マネージャが退社している時間を選んだのは、ちょっとした嫌がらせのつもりだった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
omodai
リーベルGさんはじめまして。
いつも楽しく読ませていただいています。
文章の間違いを見つけたので一応お知らせいたします。
> 秋が近づいてくるの気配すらない。
「の」が余計ですよね？
・・・しょうもないことですみません。
これからもがんばってください！！
BEL
「細かい部分に気を配れない人間に、高品質な設計などできるはずがない」
とか、言ってることは結構正論だったりはするんだけどね。
でもコストと品質がトレードオフだってことを無視してるわな。
コストカットすれば往々にして品質が低下する。
その犠牲を実装にもってくかドキュメントにもってくか。
にしても仕様書は文句言うなら最初にテンプレあげればいのに。
全部見てから一括で指摘すればいいのに。日比野さんの時間だってコストだろうに。
それにしてもこういうタイプの人ってstrategyクラス云々とか言わない
場合が多い気がするけどね(理解してないから)。
たまに理解してるつもりになって言ってる人はいるけど、
この人もあとからソレ系だったことが露呈するパターンかな。
詳細な設計に文句つけるなら規約として渡しとくべきだな。
そのうち「ここはDecoratorパターンだろ」とかいうのかな。
実は全部を見通したうえで自社の(あるいは自分の)責任にならないように
してるとしたらずるがしこいというかなんというか。
それにしても渕上マネージャのキャラはツボだ。
elseorand
段々、渕上マネージャーのバカ完璧主義者なキャラが出てきましたね。
「現実に対応できない理想論吐きすぎ」のエビデンスをどんどん押さえていかないと。
渕上マネージャーの言葉は、言葉としては一見正論だが、
Strategyパターン採用の理由が、
「プロなら、if文やswitch文を安易に使うことを恥だと思いたまえ」
だと「分かっていない人」になるな～
「社員種類は非常に膨らみやすい割には、処理は共通が多い」
とかの実装・業務上の理由からなら、大いにありだけど。
天才でもない限り、
いくらプログラミングを勉強したところで、
経験無しではやっぱりプロジェクトを壊しますね～
sa
> 材料費300円で牛丼を作れと命令しておいて、
> できあがってから「九州産の黒毛和牛と北海道産のタマネギを
> 使ってないのはおかしい」
その通りです。ウマイ！！！
mistolteen
>omodai さん
渕上マネージャーお疲れ様です！
…と書かずにはいられなかったｗ
通りすがり
前職の上司みたいな細かさだ…。
当時はそんなどうでもいことを…頭おかしいんじゃないかと
かなりムカついたりもしたけど、
離れてみると意外と勉強になってるな
ということに気が付いた自分がいた。
としろう
一番肝心な内容を見ずに、本質に関係ない部分ばかり先に指摘するのは
非生産的で嫌がらせ以外の何ものでもないと思います。
その時点でコスト増大に寄与しているとしか思えない。
色々後出しでハードル上げた（明示的に無い契約詳細に関して）上にこの仕打ち。
無駄に恨みを買うだけ損だと思うのですが。
プロジェクト失敗させて損害賠償でも請求するつもりですかね。
TK
細部もクソも…、コストカッターと関係ないよね？
渕上氏を問題者にしたい作者の意図が暴走した感じだな。
コストカット方法に関して肯定的ツッコミが多かったから、
本人の人格問題にすり替えたのかね？
まる
コスト重視している人がひとつずつのチェックで付き返すの？しかもその度に印刷させなおしているし、色々と無駄なコストを発生させるの気づかない分けないよなあ。
> 材料費300円で牛丼を作れと命令しておいて、
> できあがってから「九州産の黒毛和牛と北海道産のタマネギを
> 使ってないのはおかしい」
⇒そこは概要設計で記載する部分ではないですか？
あれだけの成果物を依頼するならば概要設計もえらいことになると思うんですが、なぜか全く触れられないですよね。
あと、一番気になるのは、全部外注に出して、管理・チェックは渕上マネージャがやる。
主人公ってこのＰＪでなにするの？
banana
細部に細かいこと自体は悪いことではない。
コスト削減のプランを立て、実行できる。
IT技術に詳しく、ドキュメントのテンプレートを作れる。
自分がやることと部下がやることをわきまえ
部下にさせる事とさせてはいけないことを意識している。
自身はおそらく自分が要求するレベルの作業ができる人間。
自社のコストは限りなく低く、
作るもの品質は可能な限り高く
それが会社から求められていることで、
渕上マネージャーは忠実に自分のミッションを遂行している。
渕上マネージャーはユーザ企業側の人間としては
最優秀の部類だと思う。
フィクションの登場人物ですが、
あんまり一面的に見るのはかわいそうに思いましたので。。。
ちけんち
一般的な話ですが、開発者ってドキュメント作成の技術(というよりWordの利用技術かな?)を身につけていない人が多いように感じます。Excel方眼紙の多用も気になります。
少しWordの使い方を勉強すれば、体裁の整ったドキュメントがけっこう簡単に作れるようになるのに、なぜかそのあたりの勉強って嫌がる人が多いんですよね。
Wordを使えば目次だって自動でできるし、フォントの統一も簡単だし、Excel方眼紙より使い勝手がいいんですけどね。Wordの段落の設定を知らない人は、「Excelのほうが文字の頭が揃えやすいんだ！」なんて言っちゃったり(笑)。
みんなもっとWordを使おう！！！
へぼPM
＞渕上マネージャーは忠実に自分のミッションを遂行している。
じゃあ、「システムを遅滞なく完成させる」っていうのは誰のミッションなんだろう？
QCDのDの部分。
そもそもこのプロジェクトって、QCDのどれが一番優先なの？
ぱっとみD＞Q＞Cだと思うんだが。
優先度がつけられないマネージャーとか、ゴミクズ以下。
ほまらら
はるか昔から、こういう人はいたんですよね。
だから「角を矯めて牛を殺す」という諺が今に残る。
責任が誰にあるのかハッキリさせるために言質を取るだけ取って、
あとは牛が死んでいくのを生暖かく見守るしかないですね。
こんなのが音頭取ってるプロジェクトに関わってしまった時は、
納期守るより健康守る方が第一プライオリティになります。
・・・5年前のあのプロジェクトどうなったかな・・・
レビューのたびに前回言ってなかった細かい部分に修正要求出してきて、
終いにはプロジェクトリーダーが失踪したあのプロジェクトは・・・
banana
この物語のこの段階で納期遅延を心配するのはまだ早い。
プロジェクトの最初の段階ではQもCもDも求めるというところでしょうか。
・・・品質は後から作り込めないというし。
私はドキュメントの誤字脱字、定義不明な文言の使用に寛容なほうだと思う。
しかし、その方が品質にプラスだからという理由ではない。
指摘する方も指摘される方も精神的にもたないから。
実際のところ、人間という生き物は
システム開発に向いていないんじゃないかと思う。
としろう
>渕上マネージャーはユーザ企業側の人間としては
>最優秀の部類だと思う。
こういう考えの人が発注側に居る事が「動かないコンピュータ」を生むのでは。
「角を矯めて牛を殺す」ではないですが。
本当にユーザの為とはとても思えませんね。
何か、迷走ぶりは8つくらいの木にブランコをかける絵の例えを思い出す。
そして結論は「安物買いの銭失い」
誰も幸せにならない。
もんきー
過去にこんな人がいる仕事やったことありました。フォントが違う文字が一部あるというだけで資料見るのやめる人がお客さんの仕事。最後には社内レビュー＝誤字脱字探しになって誰も資料の中身見なくなりました。もちろんプロジェクトは大失敗。
今回の話見ると開発が成功する可能性が全く想像できないし、最終的にコストが抑えられるとも思わないんだけど、どうなるんでしょ？
大手SIer
改めて1話から読み返して気が付いた点として、今回のストーリが「現場一辺倒の人たちに
SEとしてもっと企業経営という観点にも視野を広げるべき」という意図で書いているのならば、
１）稟議という経営陣の意向(QC)をきちんと確認せずに人事部の要求する納期(D)を承認した。
２）QCDを実現する手段として、能力的に不十分な外注先を選定した。
磯貝課長を筆頭とする開発メンバーの大失態を、進め方は褒められたものではありませんが、
渕上マネージャーがフォローしている状況にも読めますね。
この見方が正しいとすると、稟議を承認したユーザ企業の「経営層」やユーザ部門の「人事部」の
観点からすれば
>渕上マネージャーはユーザ企業側の人間としては最優秀の部類だと思う。
は正しいです。
渕上マネージャーは地震の役割である「稟議で約束した経営陣の意向(QC)と、安易に合意して
しまった人事部の要求(D)達成」を守らせようとしているわけですからね。
厳しい見方ですが、外注先とは何も合意していないから、立場上考慮する必要はないですよ。
渕上マネージャーの進め方が余りに濃すぎてわかりにくいですが、開発メンバーが自分たちで
稟議も切って、経営陣の意向も踏まえた行動ができていれば「現場の能力不足、失態を経営側が
フォローしてくれているという事実」や、「会社から求められているQCDを踏まえた行動が
できていないことを指摘されている事実」にも気が付くはず。
逆に上記の意図で書かれていないなら、渕上マネージャーはバランス感覚が悪くて、進め方が
ド下手なダメコストカッターですかね。
おたま
すでに基幹系システムが稼働中のサーバやDBMSがあっても、わざわざ勤怠システムのためだけに異なるサーバを用意して、さらに異なるDBMSでシステム構築なんてちょっと想像しづらいなあ。
Oracleは費用が発生するからPostgreSQLにしろなんてコストカット指示出すくらいなら、既存のサーバに相乗りさせるんじゃないの?
banana
５S運動ってあるじゃないですか。
整理・整頓・清掃・清潔・躾。
ドキュメントの細かい指摘というのはIT版の５S運動。
俺が工具の位置をわかればいいとか、
茶髪だろうが作業服のボタンを外していようが俺の自由、
歩留まりに関係ないという職人さんがいたら、
彼が作る製品を信用する気になるでしょうか？
ドキュメントのページを飛ばすSEが
ちゃんと必要なパターンを網羅したテストをしたと、
図表の見た目に無頓着な人が、
使う人のことを考えて画面をデザインしたと
信じる気になるでしょうか？
整理整頓をやかましく言う人こそコストだから
ここからカットしようという主張が
一定の説得力をもつのがシステム開発という世界です。
IT業界以外の人（経営者はだいたいそう）から
自分達がどうみえるか、ときどき考えてしまいます。
banana
一般にユーザ企業の情シスはIT技術を知りません。
だからドキュメントで判断します。
といっても日本語が読めると理解できるはまったく別物。
じゃあ、どうするかというと顔色をみて判断します。
営業が余裕ありげな顔をしていたらもっと値切れる、
プログラマがぴりぴりしていたらまずそうだ。
私の狭い世界でみるかぎり、
渕上マネージャーほど技術的な根拠をもって判断できる人材は貴重です。
ちなみにユーザ企業の情シスにとって
一番好ましいのは頼ったり頼られたりする関係が作れるSE・プログラマ。
困るのは感情表現がちょい平均からずれていて
情シスとの接触をさけるSE・プログラマです。
SEのくせして工程管理やプログラミングより
ゴルフ・カラオケのほうがうまい人が出世するのは
そうゆう事情だと思っています。
渕上マネージャーのような人がユーザー企業側に増えれば
かえって実力あるSEや中小SIerにとってチャンスが増えるかもしれません。
現場の人にとって不合理きわまりない人も
果たすべき役割があるから存在していると思っています。
m*k*is
「完璧で沢山のドキュメント、バグゼロ、予測通りのバグ件数とステップ数」が高品質だと考えている人がいて、しかも往々にして力が強い。
「品質＝顧客満足」のはずなのに、その部分の品質評価（つまり顧客ニーズに合っているか）をきちんとやっているところは少ないんじゃないでしょうか？
何十年も前の品質保証手法を引きずっていては、めまぐるしく変わるビジネス要求にはついていけないはず、、、なのに、今だに無くならないのはなぜだろう、、
大手SIer
私は多少ならば止まってもいい社内での会議室予約システムから、何かあれば
即新聞沙汰になるミッションクリティカルなシステムまで扱った経験がありますが、
>モリシタ精機は、K自動車の100％出資で設立された自動車関連部品
>メーカーで、ブレーキやシャシー関連製品、電子制御部品を製造・販売
している。
なので求められているQは極めて高い（親会社が上場企業として修正報告が
必要となる様なバグ、ミスなど許されない）のでしょうね。
とすると、渕上マネージャーの行動原理である「品質担保」は極めて妥当でしょう。
ドキュメントだからその程度の品質でいいと考えている渕上マネージャー以外の
メンバーがダメSEかな。
自分たちが作っているシステムが社会でどういった役割を担っているのか、
問題が発生した時のどのような社会的影響が発生するのかまで認識できて
いない人は往々にして、本当の上流工程（自分たちが社会に何を
コミットメントしているのか）の認識が薄い。
何年か前にSEも経営を勉強するべきってかなり騒がれたから、作者が改めて
こういった意図もこの文章に含めていたとしたら、「Bravo」って言いたくなるかも。
fgnplo
うーん・・
淵上さんの言う事は至極真っ当ですが
それ以前にDeliveryそのままでCost締め上げたんだからその分Quality落ちるの当たり前なのに・・
その矛盾による軋轢を「それは御社の都合」と責任なすりつけてる時点で、品質担保が出来ているとは言えないような・・
banana
品質が良ければ歩留まりがよく、利益率があがる。
使い勝手がよく、長持ちしてお客も幸せ。
世間の全てと言いませんが、確実にそんな世界がある。
品質とコストはトレードオフというのは
世間の常識とまでは言えません。
せいぜい、「完璧で沢山のドキュメント、バグゼロ、
予測通りのバグ件数とステップ数」よりましな指標を提案できず、
プログラマのセンスやPMの力量といった属人的な要素に
品質を左右されるIT業界の常識といったところでしょう。
banana
渕上マネージャーの立場からは次のように言うこともできます。
「なぜ、私がホライゾンのSEにドキュメントの書き方を指導しないといけないのだ。
かりにも金をとるならドキュメントの作成ぐらいできるようになってからこい。
客の時間を浪費して恥ずかしいと思わないのか。
まったくIT以前の問題で発生したコストをなぜ当社が考慮する必要がある。
教育費を請求したいぐらいだ。」
・・・渕上マネージャーのキャラでは
こんな感情剥き出しの愚痴は言いそうもないですが。
これでは納期が守れないとホライゾンが思うのであれば、
見積額が他社より3割低い理由を丁寧に説明して「低品質」を受け入れてもらうか、
渕上マネージャーの手法以外で品質を確保していることを説明して
理解してもらうと言った対応が必要です。
渕上マネージャーの立場では
ホライゾンが何も言わないのに
勝手に苦境を察して品質レベルを下げるなんて難しいでしょう。
このまま堪え忍んで、納期オーバー、赤字になっても
ホライゾンの自業自得とすら言えるかもしれません。
banana
・・・読み返して思ったのですが、
この数日、渕上マネージャーに肩入れしすぎましたね。
すみませんが、私の投稿は半分割り引いて読んでください。
よろしくお願いします。
としろう
大手SIerさんの渕上マネージャー擁護に反論
開発メンバーの意識改革や育成を言うなら、
コストケチる意味での外注依存率を上げる事は相反する
今までの行動から擁護できる好意的見解通りだとすると色々不自然だ
値段重視で選んでおいて、後からハードルを上げるえげつなさ。
他所がそれなりの値段であった事から、ホライゾンにそこまで要求すると
失敗プロジェクトになる可能性大でそれこそ銭の無駄。
ここに来て思う最悪のオチ
実は社内SE部門を切り捨てる為の演出でした。
大義名分作りの失敗プロジェクト
これぞ最大のコストカットだ
banana
横から失礼します。
>実は社内SE部門を切り捨てる為の演出でした。
>大義名分作りの失敗プロジェクト
>これぞ最大のコストカットだ
リアルの世界なら十分ある。
前回の勤怠管理システムの開発に失敗したが
エースシステムエンジニアリングの責任にして
みずからの部署の失敗として受け止めていない。
しかも、社内の信頼を失って仕事をほされ
ろくな仕事をしていない（社員の定期券・・・）上に
グループリーダ（管理職）を削られ、
経営陣からあからさまに低評価をくだされているのに危機感がない。
社内が残業を削ってコスト低減に勤めているなか、
もともと残業がなくて、社内の顰蹙をかっているくせに
開発に取り組むとなると正社員が残業する前提。
くさった林檎と見られても無理はない。
大手SIer
偶然見たら環脚向けにコメントが付いていたのでちょっとだけ。
このストーリーは毎回読み返してってみるとに一貫性がないので、
事実以外は話ごとに変わっている可能性ありと見ています。
それを踏まえてのコメントです。
>開発メンバーの意識改革や育成
意識改革はまだしも、IT系企業でもなきゃ社内SEの育成にまで結構手は
回りませんよ。
自分で業務外に自主的に勉強してもらうの流れが多いと、色々な会社の
関係者からは聞いていますし、会社によっては「育成に○○○万円位/人ほど
金かけてます」ってアピールになるぐらい。
だからSIerにとって、そういう社内SE部門はのビジネスの種になります。
>値段重視で選んでおいて、後からハードルを上げるえげつなさ。
選んだのは渕上マネージャーではありません。
ホライゾンで会社の求めるQCDを満たせると説明して承認を得たのは、
磯貝課長＆開発メンバーだから、そもそもハードルの高さを
読み間違っただけでは？
私は数年前に大手SIer各社ででよくあったQCDのバランスを読み間違って
QD>>Cになった失敗プロジェクトの規模を小さくしただけに見えて
仕方ないです。
まる
としろうさんのコメントについて、気になりました。
＞値段重視で選んでおいて、後からハードルを上げるえげつなさ。
＞他所がそれなりの値段であった事から、ホライゾンにそこまで要求すると
＞失敗プロジェクトになる可能性大でそれこそ銭の無駄。
⇒契約要件を出して、ホライゾン側から他社3割減でやれますと
見積提示したから要求度合いは値段で選択したことと関連はないのでは？
そもそも「金額」の実態が見えないのでホライゾンがここまでこの仕事に固執する理由があるんでしょうか。
「工数」相談ばっかりで作業が増えても「金額」が増えてないように見える・・
XYLITOL
＞そもそも「金額」の実態が見えないのでホライゾンがここまでこの仕事に固執する理由があるんでしょうか。
小さなベンチャーSIerだと、いったん受注した仕事を、金額的に見合わないからといって投げ出すことは、ほぼないと言っていいんじゃないでしょうかね。
なぜならそんなことしたら、次の仕事が回ってこないから。
そういうときは、たとえ赤になったとしても完遂して、貸しを作る。
営業的ないいぶんですがね。
エンジニアからすれば、「本当に次があるのか」と言いたいこともしばしば。
hoge
アニメヲタクが製作者にからんでるようなそんな感じのコメントですね。
本文より面白いやｗ
大手SIer
流れからするにホライゾンは初めての取引なんでしょう。
発注する側の観点で想定すると「逃げるようなら次の仕事どころか、
発注先のグループ企業全ての案件でチャンスがなくなる」ということを
言われなくてもそれを感じ取っているんでしょうね。
あと貸し借りの話ですが、継続して取引関係がある会社なら貸しの場合も
ありますが、そうでなければ貸しだと思っているのは受注側だけ。
発注側は貸しだと思っていないので、次も頼みたいと思える結果を
出していなければ、問い合わせがあってものらりくらりとかわすか、
絶対受注できない要件で見積もり出すだけですね。
SIerとしては、顧客から当然の要求として上記の対応をされるので、
同じことを発注先にやってるだけ。
そういった経験のない社内案件専門のSEは、往々にして
「使い勝手の悪い不評なシステム」を平気で作ったりするものですがね・・
へぼPM
＞bananaさん
＞この物語のこの段階で納期遅延を心配するのはまだ早い。
すみません。「まだ」の意味がよくわからないです。
現段階で遅延が発生しているのならば、それをどう挽回するかを
考える必要があると思うのですが。。。
それとも、このマネージャには、Qも落とさずCも上げずに
Dを守る「冴えたやり方」があるんでしょうか？
個人投資家
＞「なぜ、私がホライゾンのSEにドキュメントの書き方を指導しないといけないのだ。
＞かりにも金をとるならドキュメントの作成ぐらいできるようになってからこい。
＞客の時間を浪費して恥ずかしいと思わないのか。
＞まったくIT以前の問題で発生したコストをなぜ当社が考慮する必要がある。
教育費を請求したいぐらいだ。」
全くその通りだと思う。
ホライゾンの出してくるドキュメントがダメダメ過ぎる。
主人公はドキュメントのサンプルを作成して、
「我が社ではこれが共通規格なので、これを使ってください」
という事も出来てない。
上流工程で品質が悪かったら、後工程でリカバリーするのが大変なのに。
2cbから
何度も印刷するコストはカットしないんですか渕上さん(笑)
三浦や高杉と比べるといろいろ真っ当だっただけにこの描写は残念