罪と罰（45） ずっとお城で暮らしてる
どんな業界にも独特の用語というものがある。IT業界で使われるエビデンスやアサイン、ミッションクリティカルなどの単語は、業界外の人が耳にしても、すぐには意味がわからない言葉ではないだろうか。私自身、友人たちと旅行の相談をしている時に「そのスケジュールじゃバッファなさすぎじゃない？」と発言して、一斉にきょとんとされた経験がある。
もちろん自動車業界にも業界用語は存在している。IT業界より歴史が長い分、数も種類も豊富かもしれない。東雲工業は自動車部品メーカーなので、社内で交わされる会話や文書、メールに、それらの業界用語があたりまえのように使われていた。初めて「号口」という単語をメールの中に発見したとき、てっきり誤変換か誤入力だと思ったものの、では正しい単語は何なのか想像もできなかった。
某大手自動車メーカーで「量産開始」を意味するこの言葉は、ITシステムを導入する際にもよく使われる。スケジュール表の一番最後のマイルストーンが「号口」と記述されているのだ。うちの業界用語に置換するならカットオーバーだ。
9月5日、木曜日。並行運用開始から9営業日め。トモコ御前こと、三吉さんは怒り狂っていた。さっきからその発言の中に「号口」が10回以上は出現している。
「号口まで今日を入れて26日しかないんですよ！」三吉さんはライオンのような咆吼を、飛田に浴びせかけた。「なんでこんな問題が今の今までわからなかったんですか！本当におたくの会社でちゃんとテストしたんですか」
首をすくめたのは私とカスミさんで、矢面に立っているはずの飛田ときたら、口うるさい近所のおばさんが燃えないゴミの収集日を間違えたことで文句をがなり立ててる、とでもいうような顔で立っている。
「この号口は絶対にずらせないってことだけは、何度も何度も口が酸っぱくなるぐらい申し上げましたわね。おたくはそれをちゃんと認識されてるの？」
「もちろんです」おそらく相当うんざりしているのだろうが、さすがにそれをあからさまに表に見せることはなかった。「これまでのところ、予定通りに進んでいると思いますよ」
「予定通りじゃないじゃありませんか。ここに来てこんな問題が発覚するなんて」
「何度も申し上げましたが、私はその問題を聞いていませんでしたのでね。私の記憶が確かなら、これまでのどの仕様検討の席でも、そんなケースは議題に出ていなかったはずですが」
「当然、わかっていると思っていましたからね。進藤さんならわかっていたはずですよ」三吉さんはカスミさんを見た。「そうですよね？」
「ええ、まあ」カスミさんは短く答えた。
「ほらね」三吉さんは満足そうな顔になった。「飛田さんがしっかり進藤さんから聞き取りをしておけば、こんなことにはならなかったんじゃありませんか？」
俎上に載っているのは、アルバイトを含む契約社員の契約更新処理の件だった。東雲工業で働く約900人ほどの契約社員は、定期的に契約内容を見直し、等級や職位が更新される。遅刻や早退、欠勤などから算出される勤怠ポイントを元に、ユニットリーダーが面談を行い、勤務態度などを数値化して入力する。中には契約満了と同時に退職する人もいるし、翌月から配属されてくる人もいるので、何回かにわけて仮の更新処理を走らせた後、月末の10営業日前を目標に最終更新処理が実行され、翌月からの新しい時給、または年俸が決定となる。ラインの配置計画も決めなければならないし、人件費の算出と部門長承認、雇用契約書と労働条件通知書の印刷発注と、社印の押印処理などを考慮すると、10営業日前でもギリギリらしい。
2時間前、三吉さんからの連絡が入った直後、飛田と木下が激しい口論を始めた。私が見とがめて話を聞いたところ、問題になっていたのは、東雲工業の全従業員1200人中、現時点で6名しかいない定年後再雇用契約社員だった。高年齢者雇用安定法が改正されたときに、間に合わせで実装した仕組みで動いている。厄介なのは、これが個人毎に別のロジックになっていることだった。
「たとえば」私の質問にカスミさんは説明してくれた。「Aさんという対象社員は年俸制で10:00から16:00勤務、Bさんの場合は3ヵ月契約で勤務時間は未定、月間労働時間だけ決まってる、とか」
「そんなの勤怠関係のロジックにありましたか？」怪訝そうな顔で飛田が訊いた。
「ないわね。対象者は勤怠締め後に、庶務の人が手修正してるから。契約更新とは扱いが別なの」
「どこにそんなテーブルがあるんですか？」
「だからないんだってば。個人別のロジックになってるから」
「え、じゃあ」私は確認した。「基本給とか能力給とかが、ハードコーディングされてるってことですか？」
「そうなの。職位キーと雇用契約キーは、普通の期間契約社員Cタイプと同じなんだけど、同じ計算ができないから」
「で、こいつが」飛田は木下を憎々しげな目で見た。「それを私に伝えてなかったわけです。契約更新処理関連の仕様の洗い出しは、こいつに任せてあったのに」
木下は反抗的な目つきで見返した。
「別にわざと言わなかったわけじゃねえよ。単に忘れただけだ。いろいろ忙しかったんでな」
「本当にそうか？別の意図があったんじゃないのか？」
「あ？どういう意味だ」
2人が剣呑な表情で睨み合ったので、私はうんざりしながら介入した。木下が意図的に情報を隠蔽したのではないか、と飛田が疑っているのはよくわかったが、そんなことは全てが片付いてからゆっくり対処すればいい。
「そういうのは他所でやってくれるかな。なんで今までわからなかったの？契約更新処理は、前月分の対象者全員でテストしたはずでしょ？」
「定年後再雇用契約社員は本社工場にはいないのよ」カスミさんが答えた。「根岸と川崎の工場にいるの。テストしたのって、本社工場だけだったでしょ」
東雲工業株式会社の本社工場は、第三京浜港北インターから、緑産業道路を西に2キロほど進んだ工場地帯の一角にあり、従業員の7割はここに集中している。他に、根岸、川崎、鶴見にも5つの工場と3つの営業所があるが、新人事・勤怠システムの並行運用は、9月5日までは本社工場だけで行うことになっていた。本社工場以外は、庶務担当者の数が少なく、勤怠締めに向けての入力と修正が集中する月末と月初は、並行運用を行う余裕がないからだ。
「なるほど。今日から各工場でテストが始まって、発覚したわけですか」私はうなずいて、飛田に視線を移した。「で、三吉さんは何だって？」
「すぐ来い、と言ってましたね」
「それを早く言え」
かくして、私とカスミさん、飛田の3人は、東雲工業に急行し、案内された会議室に入った途端、グレート三吉の非難が雪崩のように襲いかかったのだった。カスミさんを連れてきたのは、緩和作用を期待してのことだったが、あまり効果はなかったようだ。
「まあ、今は責任を追及しても意味がないでしょう」嶺井課長が言った。「定年後再雇用契約社員の計算ロジック、組み込むことはできるんですか」
絶え間なく続く三吉さんの罵声の奔流に、無言で耐えていた飛田は、さすがにホッとした顔になった。
「もちろんできます。ただ、すぐというわけにはいきませんが」
「なぜですか？」
「勤怠系で多くの修正が発生していますので」飛田は三吉さんの方をちらりと見た。「そちらの対応が終わり次第ということになりますね」
並行運用を開始した最初の3日間で、1000を超える数の問題報告や改善依頼が上がってきていた。トラブルについては三吉さんがフィルタリングしてくれるはずだったし、改善要望については、よほど些細な要望以外は、基本的に応じない取り決めにしてあったが、ほぼノーチェックでうちに転送されていたのだ。事態に気付いた嶺井課長が、報告の一次受付窓口を自分にしてくれたことによって数は激減していたが、うちとしては正式なバグレポートとして上がってきているものは対応せざるを得ない。突き返すにしても、根拠を提示する必要があり、対応に時間がかかっていた。
「号口までに間に合うんですか？」嶺井課長は訊いた。
「お約束はできませんね」飛田は素っ気なく答え、それが一度は収まりかけた三吉さんの憤激を呼び覚ますことになった。
「それでは困るじゃないですか！10月末で期間満了になる再雇用の人が2人いるんですよ。10月始めにもう処理をしないといけないのに。そこは何としても入れてもらわないと。進藤さんなら、こういうとき何とかしてくれたものですけどねえ」
「数字が変わるたびにロジックを修正したり、対象者が追加されるたびにプログラムを追加したりしてたってことですね」飛田は三吉さんを見つめ返した。「むしろ、そういうことがないように、きちんと機能として盛り込むことを提案します。別の給与テーブルを作成して、専用の処理画面を作ることで実現できるでしょう」
それを聞いて三吉さんが言い返そうとしたが、嶺井課長が何か考えるような顔で制した。
「でも号口までに実装するのは難しい、ということですか」嶺井課長は確認した。「どんな作業が必要になるんですか？」
「まず、今の定年後再雇用契約社員の契約更新パターンを全部ピックアップする作業が必要ですね。それから、今後、発生しうるパターンの予測も。加えて言うなら、今、手修正している勤怠の方も、同じようにロジックとして組み込むことも提案したいですね。庶務の方の工数削減になるのではないですか？」
「なるほど」嶺井課長は頷いた。「それは確かですね」
「あの入力はコツがあるんです」三吉さんが反論した。「長年の経験が必要なんです。そう簡単にパターン化できるとは思えませんよ。それに10月分はどうするんですか？」
「パターン化ができないとは思えないですね」飛田が薄笑いを浮かべた。「現状だって庶務担当者が当てずっぽうに入力しているわけじゃないんですよね？だったらルール化できないはずがないですね。三吉さんが理解していることなら、うちにだって理解できます。10月分については、手入力したらいいんじゃないですか？」
「......」
「この問題が、本番運用開始――号口ですか――の前に発覚してよかったですね」飛田は続けた。「こうして対処する時間が取れるわけですから」
次の瞬間、三吉さんがいきなりテーブルを両手でバン、と叩いたので、私は飛び上がるほど驚いた。
「ふざけないでください！」鬼のような形相で三吉さんは怒号した。「今の仕組みは、私たちが何年もかけて作り上げてきたものなのよ。それを半年前に初めて触った人に読み解けるわけないでしょう！人をバカにするのもいい加減にしてください。そもそも、今は、定年後再雇用契約社員の勤怠処理の話なんかしていないじゃありませんか。契約更新の話をしているんですよ！これが考慮されていなかったのは、明らかに飛田さんの手落ちじゃないんですか？その責任の話をしているんですよ！話をすり替えないでちょうだい！」
「すり替えてはいません。もちろん責任は弊社にあります。そこを否定してはいません。その上で提案をしているんです」
「その提案が手入力なの？」三吉さんは嘲笑した。「まず目の前の問題に対して、有効な解決策を提示したらどうなんですか」
「ちょっと待ってください」嶺井課長が言った。「私は飛田さんのご意見にも聞くべき点があると思います。むしろ、これまでその部分に対して場当たり的な対応しか取ってこなかったことの方が問題ではないのですか」
「嶺井さん！」三吉さんは嶺井課長を睨み付けた。「あなたどっちの味方なのよ」
「味方も何も」嶺井課長は肩をすくめた。「東雲にとって最善と思われるシステム環境を整備するのが、私の仕事ですよ」
「それには私の提案が最善です」飛田は不遜な態度で断言した。「ここで小手先の対応でごまかすよりも、抜本的な解決を行ってしまった方が、長期的に見て御社にとっての利益となりますよ」
「長期的なんて私には関係ありません！私は私の仕事をちゃんと進めたいだけのことです」
すると今度は飛田がテーブルを叩いた。ただしその勢いは三吉さんのそれに比べれば、かなり小さなものだった。
「どうしてわかってもらえないんでしょうかね」飛田は苛立ちを隠そうともしなかった。「どうして目先のことばかりにこだわるんですか。もっとシステムを有効活用しようとしないんですか。三吉さんの言っていることは、業務の属人化を維持してくれということですよ。そういうのを既得権益というんじゃないですかね。そんなにご自分の城を守りたいんですか」
私が飛田を制止できなかったのは、間にカスミさんが座っていたからに過ぎない。そうでなければ、足でも踏みつけていたのだが。まさか、カスミさん越しにペンを投げつけるわけにもいかない。それでも私は何とか飛田の注意を惹こうと身を乗り出したが、飛田は構わず自分の意見を披露し続けた。
「三吉さんは、進藤だったらやってくれた、進藤だったら聞いてくれた、と言い続けていますが、もし進藤が入院するとか転職するなどの事態になったらどうするおつもりだったんですか。三吉さんだって、いつどうなるかわからないですよね。それはどの庶務担当者についても言えるじゃないですか。そのときのために、バカでも処理できるようにしておこうと提案しているんじゃないですか。なぜ、その利点がわからないんですか」
三吉さんの顔が青くなり、続いて赤くなった。もう限界だ。私は強引にでも飛田を止めようと腰を浮かしかけたが、それより先にカスミさんが口を開いていた。
「飛田さん」静かだが有無を言わせない声が、カスミさんの口から発せられた。「いい加減にしてくれないかな。三吉さんが、直近の契約更新処理に対応して欲しいと仰っているのなら、そうしましょう。これまでもそうしてきたんだから」
「はあ？」飛田は呆気に取られたようにカスミさんの顔をまじまじと見た。「だからそんな短期的な視点じゃあダメだって......」
「そんなことは、うちの考えることじゃないでしょう。自分たちが作りたいものを作るんじゃなくて、お客様が求めているものを作るのが、私たちの仕事でしょう。飛田さんが言っていることは、単なる技術の押し売りでしかないわよ」
「いや、あの......」
飛田がスムーズに返答できないシーンを初めて目撃した気がする。私や三吉さんからの反撃は予想していたかもしれないが、カスミさんからのそれは全くの想定外だったのだろう。自分より技術レベルが数段劣っているはずの人間から説教されるなど、飛田にとってあり得ないことだったに違いない。
「そりゃあ確かに」カスミさんは少しだけ表情と声を和らげた。「定年後再雇用契約社員の勤怠処理や契約更新を、とりあえずの方法で逃げてきたのは問題かもしれないけど、今、考えることじゃない。そうですよね、箕輪課長」
反射的に私は頷いていた。頷かされたといってもいいぐらいだ。
「すいません、三吉さん」カスミさんは三吉さんに向かって、テーブルに額がつきそうなぐらい深々と頭を下げた。「飛田の暴言については後でしっかり言い聞かせておきますので、ここは私に免じて許してやってもらえないでしょうか」
私も慌てて頭を下げた。
「ああ、その......」勢いを失った三吉さんの声が、私たちの頭上を通過していった。「......進藤さんがそう言うなら、ええ、そうですね」
私は安堵のため息をついて顔を上げた。三吉さんは感情的になったことを恥じているような決まり悪そうな表情を浮かべている。カスミさんが、ちらりと私の方を見た。
「10月分の契約更新処理については、滞りなくできるように、弊社で対応させていただきます」私の言葉に、飛田が驚いたようにこちらを見たのがわかったが無視した。「具体的な方法については、明日にでも改めて打ち合わせの場を設定させていただきたいと思うのですが、それでいかがでしょうか」
「ええ」三吉さんは小さく頷いた。「それで大丈夫です」
「できればですね」嶺井課長が言った。「さっき飛田さんが言ったように、定年後再雇用の対象者が増えたらプログラムを追加するというような現状の仕様も、何とかしてもらいたいんですがね」
「はい。それは11月まででよろしければ、何とかなると思います。ただ、今回の開発対象からは外れますので、追加で工数を算出させていただくことになりますが」
「もちろんです」嶺井課長は三吉さんを見た。「それでいいですね？予算管理表の方は、私が経理と調整しておきます」
「わかりました」三吉さんはため息をついた。「こちらでも、できるだけパターンを洗い出してみます」
その後、打ち合わせの内容は、今後の予定や、並行運用で発生している問題の対処などに切り替わり、終始なごやかな雰囲気で終わることができた。ただ1人、飛田だけは無言のままだったのだが。
打ち合わせが終わり、私たちが席を立ったとき、嶺井課長が呼びかけてきた。
「箕輪さん。少しだけお時間いいですか？」
「はい。なんでしょう？」
「お話があって。5分ぐらいですみますので」
「わかりました」
カスミさんと飛田に先に帰社しているように言おうとして、私は考え直した。先ほどの騒動の後に、2人きりにするのも酷だろう。
「外で待っていてください。すぐ行きますから」
三吉さんに続き、カスミさんと飛田が微妙な距離を保って、会議室を出て行くのを待って、私は再び腰を下ろし、嶺井課長と向かい合った。
「さてと」嶺井課長は思い出し笑いをした。「相変わらず強烈な人ですね、飛田さんは」
「すみません」私は顔から火が出る思いで頭を下げた。「飛田はある種の理想主義者みたいなもので」
「私個人としては、あんな風にこだわりを持って仕事をする人は嫌いじゃないんですよ」嶺井課長はそう言うと表情を改めた。「ただ、お話したかったのは飛田さんのことじゃないんです」
「といいますと？」
ある潜水艦のクルーによれば、航海中に一番聞きたくない言葉は「これは演習ではない」だそうだ。私が今、一番聞きたくない言葉は「御社への発注はこれが最後になる」だ。長い付き合いの会社からの受注がなくなるのはダメージだし、何よりカスミさんの居場所が消失することになるのだから。
私の緊張が伝わったらしく、嶺井さんは苦笑した。
「いやいや、別に御社との付き合いをこれっきりにしてくれとか、そういう話ではないので安心してください。むしろ、今後も末永くお付き合いをお願いしたいと思っていますから」
「ありがとうございます」私は心からお礼を言った。
「そのためにも1つお願いがあるんですよ」
「何でしょうか」
「進藤さんを外していただけないでしょうか」嶺井課長は真剣な顔で言った。「号口後、新システムの担当者から」
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
経済犯罪特捜部
こういう状況が発生すると、普通は「飛田外してカスミさんに戻してくれ」だと思うがなあ。
カスミさんを東雲工業側で再雇用して、内製に切り替えるとかだったら分かるが、
ななしーん
嶺井課長イニシアティブ説はほぼ確定かな。
DEADBEEF
そりゃまあ「新藤さんなら気づいただろうから言わなかった」
「新藤さんならやってくれる」なんて言いまくられたら
カスミさんかトモコさん、どっちか外すしかありませんわな。
言わなかったことが、費用追加につながったんならなおさら。
二次開発は、飛田くんの好きにやればいいんじゃないの。
jeid
これまでの嶺井課長のスタンスだとカスミさんに戻してくれって発言はしないでしょ
というかやっぱカスミさん―三吉さんラインのほうがガンじゃねーのコレ
飛田さんの物言いはともかくとして
むむむ
東雲としても三吉みたいな能無しは閑職に送りたいんだろうな。
そういう意味では、飛田案のような属人化しないシステムにしないといけないし、カスミさんみたいに客の言った事なんでもやる担当者は邪魔だろうな。
まぁ、なんというかこのタイミングで出る問題かとも思うし、通常は手入力や別計算で機能追加後データインポートで終了だよな。
この手のお局は自分の無能さ提示されると最後は泣くからな、あとは管理職に告げ口。
hrt
ダメな発注側とダメな開発側とのダメな関係が見事に引き起こした問題だよなあ。
意地でもそれを認めたくない長文が出てくるだろうけど。
wwJww
間接部門には、三吉みたいな自分のテリトリー守りたがる人がかなり多い。
それしか自分が抜きに出れるものがない技能職だからですかねぇ。
ま、技術職であるITでもたまにいますけど、ね。
へっぽこERPエンジニア
・バカでも処理できるように
・自分の城・・・
・の前に発覚して良かったですね
とか、ここまで出入り禁止ワードを並び立てられる飛田君はすげえなあ。
正直、この回の単語だけ拾って読むと、どっちが感情的かっていったら飛田君側でしょう。
短期的利益だけ追い求めてきた過去の体制もアレだろうけど、この場においてはは戦略よりも戦術を優先しないと、会社滅びてシステム有りになっちゃいますね。
ケインズ先生の言葉を借りれれば、我々は皆長期的には死んでいるんだから、両側面から話が出来んと・・・。
相手が『アレ』であれ、『コレ』を連れてく箕輪課長も管理職として大丈夫なんか？まだ、木下くんでも連れて行きゃいいのにね。あと、技術力で勝負じゃ！っていうんであれば、既存のソースコードなりデータなりを洗い出すくらいすりゃいいのに。
誤植
場工場
えれこぜ
まだ先は長そうですね。
イニシアティブ大勝利だと、題名の「罪と罰」にならない。
五十嵐さんが犯した罪を、五十嵐さん(及び飛田さん)が贖うと言う話だと思うんだけど、そのまんま過ぎるか。
TKFM
これいきなり会社間でぶつける話では無いでしょう……
今月分は滞りなくできるように対応するっていう対応の定義が作中で明かされていないので言及できませんが、
少なくともシステム側で対応するのはリスクが大きく、その点は飛田さんが正しいでしょうし。
逃げ道として既存システムの結果をインポートするような機能が生まれる程度なら誤魔化せそうですが。
ii
>えれこぜさん
確かに、五十嵐の任期満了でこのストーリーはエンディングかと思ったら、
これでまた着地点が見えなくなってきましたね。
そもそも何で箕輪たちの会社側の改革期間が終了したところで、
エンディングに向かわなかったのか……？
いつぞやの続きで超展開な予想をしてみますが、
実はカスミはすでにエヌ氏たちアンチ・イニシアティブと内通していて、
（もしくはアンチ・イニシアティブにひそかに所属していて）
今も飛田がアンチ・イニシアティブが突っつけそうなボロを出すのを待ちつつ、
イニシアティブに排斥される犠牲者を装っておきながら、
その実あれこれ嗅ぎ回っている最中……とか？
もしイニシアティブVSアンチ・イニシアティブ編が「罪と罰」第二幕のお題なら、
五十嵐が会社を去った時点でエンディングに行かなかった理由は、
一応腑には落ちるんですが……。
BEL
要件もれ、網羅テスト漏れだな。
てか実データだけでテストしたのかよw
やはり飛田の言動は作者の内心を表したものではないと思う。
ドキュメントと技術が相当しっかりしてたとしても、それだけでは仕事はできないよ。
いくらＩＴ業界自体が新しい産業だといっても、経験則的にそんなことはそろそろわかっているはず。
木下は飛田にタメ口きいてる。
よびすてされてて、下の立場になっちゃったのかと思ってたらそうではなかったようだね。
木下、策略だとしたらあまいなあ、洗い出しは自分の仕事だったんだから。
やるなら飛田マターでのミスがでるようにしないと。
嶺井が箕輪に話があるって言ったとき、さすがに今回は飛田はわってはいらなかったな。
ファーストコンタクトで飛田みたいのが出て来たら受注できないよな普通。
あるいみ進藤たちが作ってきた貯金を食いつぶしてる状態だな。
属人化を避けろとは言うが、技術的に高度なことをやりすぎた場合も、ある意味属人化なんだよな。
常にその技術と同等以上の技術力をもった人材を確保しなきゃいけないんだから。
なび
この件で一番救いようがないのは間違いなく木下だろう。
DBと連携してシステムで管理しようとしているのに
ハードコーディングしてある特殊なパターンを伝え忘れるだなんて
策略とするなら超悪質にして陰湿、ミスだとしても超ド級の大馬鹿野郎だ。
知らなかった、ならまだしも、（知ってるうえで）伝え忘れてた、なんて言ってるんだから。
しかも自分が洗い出しを受け持っている範疇のことなのに、全く反省せず悪態をつく始末。
切るなら進藤より木下だろうね、こいつは無能と言われても仕方がないくらいだ。
プーマ
トモエ御前は、名悪役ね。
典型的な「変化を嫌がる」「近視眼的な考え方しかできない」「年寄が」「既得権益にしがみつくための」「ただのわがまま」を体現してる。
Enterの件も「そういう１事例」を出したにすぎないんでしょう。
ただ、トモエ御前の「主張以外のところ」での恣意的な悪役性格設定は、もう少し上手に処理してほしかったかな。
どうも、「Enter事例」のような主張をする人は、’漏れなくすべて’「変化を嫌がる」「近視眼的な考え方しかできない」「年寄が」「既得権益にしがみつくための」「ただのわがまま」である、というようなミスリードがされちゃってる気がするのよね。
潜在的に、前述のような「先入観」を既にがっちり持ってる人や「実は顧客は大抵バカである」という傲慢な思い込みに気付けてない人が、それみたことか、と愚かさに拍車をかけそうな気がするよ。実際は、ケース・バイ・ケースでしかないけど。
もしミスリードが意図的なものだったしたら、愚者の軍団を量産しかねないので辞めてくんないかな、と思うけど、まぁ、考えすぎだよね。
考えすぎってことでいいよな、うん。
サルーン
今回は飛田の手落ちではないかなあ。
木下の物言いは今すぐ帰れって言いたくなりますが、口論の場に途中から着て判断下すのもどうかと思いますし。
強いて言えば、相変わらずビジネスの場には出せない会話能力。
言葉遣いもそうですが、暫定対応の目処が付く前に恒久対応なんて言い出すのは
客の怒りに油を注ぐ行為。
ましてや、そもそも論なんて始めた日には、「オレハワルクナイ」と言ってるようにしか受け取ってもらえないですよ。
営業がアラートあげる迄一人で行かせてた箕輪は何を考えいたんでしょうか。
サルーン
にしても1200人中6人てのは本当に絶妙ですねw
ロジック共通化にしてもサンプルが少ないと、新しいパターンが後から出てきますし。
本当に著者は意見が割れる分水嶺が分かってると思います。
(煽り上手とも言いますねw)
行き倒れ
五十嵐が改革した結果、もしくはイニシアティブの理想の、
「罪」と「罰」が現在進行形でこれから明らかになっていくってことだな。
「内部崩壊」の詳細も現在進行形かも。
五十嵐が去るまでのくだりは壮大な前振りだわw
これは一年(=52週)超えるか?
2週休んだから、期間の一年なら50週だな。
三吉さん、うちの会社にも予備軍がいるわ^^;
小保方銃蔵
案外、カスミさんは飛田のこと嫌っていなさそう。
ななし
進藤があまりにも癌過ぎますね本当に…。
自分の無能さが根本の原因で発生している問題なのに、この期に及んで「お客様」に媚び売る事には全力とは。
その後談として、「顧客の手前、事を収める為に泥をかぶって貰うような事をして申し訳ありませんでした」とでも言えばまだ弁解の余地は有るのでしょうが、多分そんな事も無いのでしょう。
この手のタイプは、顧客の言うことを聞く事が至上でそれ以外は些事、と本気で考えているのでしょうから。
この手合は現実世界にも結構な割合で存在していて、多くの問題を引き起こしていますが、その尻ぬぐいをするのは殆どの場合で本人以外の誰かです。
本人はといえば、「謝ればいい。自分は相手との間に謝って済むような関係を作っている」なんて感覚でいますが、そもそも謝罪しなくてはならないような状況を生み出した自分の瑕疵にはどこまでも無頓着というか、全くもって重要な問題だと認識していません。
自社にとっても顧客にとっても、その無能はゼロですらなく害悪そのものですね。
ななし
飛田のトーク力がアレなのは演出上の都合としても、対比として進藤を位置づけるなら、そもそもご自慢のコミュ力で何故問題があると解っていて伝達しなかったのかと。
木下は意図的にやっていたならば社会人として不的確、即懲戒とすべきでしょうし、主張通りに漏れだったのなら、それはそれで無能という事になるのでしょうね。
どちらにしても、普通はお咎め無しで済む立場では無いでしょう。
24
システムの事を真摯に考えているのは飛田の方だと思うけど・・・
本気だからケンカするんですよ
お客のいいなりがお客のためになるなら
営業が仕事すればいいと思う。
わるを
嶺井と飛田が、それぞれ自社のお局を放逐しようとしているだけでは？
でも多分、カスミは罠に気がつきつつも仕方なしに引っかかってやった感じかな、と。
どん
飛田のトーク力がアレなのは演出上の都合で片付けるのに、進藤の行動は演出の都合で片付けないのか……
プーマ
自分は、「そこそこ若くて」「まだ既得権益はもってない」「割とユーザーとの接点で仕事する機会が多い」立場だけど、顧客重視は意識してる。
顧客重視と技術品質の高いものは両立できると思ってるし。
リアルな世界だと、三吉さんと飛田さんのような人が直接交わるケースは、ほとんど経験したことないな。どっちも居がちな人ではあるけれど、大抵は自分の正義と都合しか目に入ってなくて、お互いをバカだと思いあってるから、交わる場には誰もつれてきたがらない。どっちにも一理はあるけど、一理しかない。
飛田さんはエンジニアとしては良い結果を残せる人だと思う。ただ、要求分析には向いてない人だと思うので、誰か上手に使いこなしてあげてほしいよねぇ、とは思う。
うちの場合は、要求分析で「技術的に無理です。」は言わない、「実装のイメージを持たせてしまう用語は使わない」。が鉄則になってる。
相手側から、「WEBシステムでやりたい」、というような要求を最初から出される事もあるけど、「それは専用のクライアントソフトを作らないようにする、という要望でいいですか？」のように開くようにしてる。WEBって決め打ちだと、結局、一部の機能が実装できなくて、Excelのマクロを作って、所定の場所において連携、とか、妙な荒業を使わないとダメな事になったりするから。
そうなっちゃうくらいなら、顧客も最終的にリッチクライアントの方がマシって判断になるから、概要設計まで、極力、実装の制限が入り込まないように注意してる。駆け出しの頃はこれが出来なくてよく叱られた。PGあがりには、最初はすごいストレス。でも、今は相手の要求を引き出す一番のコツはこれかな、と思ってる。対話力なんかよりよっぽど重要で、相手の要望を「開く」時に、相手が本当に欲しいものは大概出てくると思うようになった。
Jairo
うーん、テスト項目のチェックにカスミさんはタッチしてなかったのかなぁ。
あと、受け入れテスト仕様書は無いのかな？そこそこの規模のシステム移行だから、あっても良さそうなんだけど。
Zzz
前回飛田の「自分がちゃんとしてれば大丈夫ｷﾘｯ」とは何だったのか
結局人のせいとは嗤かしてくれますわ
どうせ他にも漏れあるだろうと思ったら案の定で草不可避
要件定義に参加してたのなら飛田の責任は逃れ得ないし、
ただの実装屋の立場なら明白に越権行為
と言うか移植と設計変更同時進行とか自殺したいの?
しかもテストフェーズ入ってる今頃に?
SQL発行ループ外出しとかのレベルじゃないよねこれ?
属人化の解消()とか錦の御旗掲げてる気になってるようだけど、
それ最初っからそんな話になってんの?
ただの移植作業分しかコスト見積りしてないんじゃないの?
東雲は既存機能を全て移植する前提で金だしてるんじゃないの?
新機能でもないものに追加費用が発生しますとか今頃言ってﾆｺﾆｺ頷いてくれるとでも思ってんの?
まあリアルでも普通にいますけどね? この手の輩
しかし神の見えざる手で守られているファンタジーは、さすがに見たことありませんな
普通は首すげ替えですわ 持ってプロジェクト終了までの命です
結局
ちゃんとヒアリングして、内部レビューして、東雲にもレビューしたんかね？
結局技術力偏重で人間力育てない悪い例にしか見えない。
WEBサービスとかなら上手くいくだろうけど、これじゃ受託開発はとても無理だわ・・・
サルーン
これは流石に要件定義書に書かれていない事に気がつかなかった東雲側のミスです。
前回の依頼したけど握り潰されたとは違いますからね。
確かに
>前回飛田の「自分がちゃんとしてれば大丈夫ｷﾘｯ」とは何だったのか
>結局人のせいとは嗤かしてくれますわ
とは思いますが。
らいてふ
>あの入力はコツがあるんです
>長年の経験が必要なんです。
>そう簡単にパターン化できるとは思えませんよ。
>パターン化ができないとは思えないですね
このやりとりだけじゃまだ何とも言えないが、
飛田くんがここまで自信満々である根拠が全くわからない。
ここでの事例は「従来のどのパターンにも該当しないパターン」
が次々と新しく湧いて出てくる、というパターンじゃないのか？
三吉トモコ嬢をお払い箱にできるよなシステムぐらい組んだるわ！
とは・・・自らハードル上げるの好きやな～男前すぎるわ。
ななし
>飛田のトーク力がアレなのは演出上の都合で片付けるのに、進藤の行動は演出の都合で片付けないのか……
それなりに多くの人と関わって来ましたが、飛田レベルの物言い（例えば、「バカでも使える」と言うような。言っている事は同じでも、普通は「誰でも使える」という表現にするでしょう）をする人を現実世界では少なくとも見たことがありません。
ですが、進藤のタイプをより悪化させた例は多く見てきました。
前者は実際には存在しない、文字通り「フィクションのキャラクター」ですが、後者はリアルのそれそのものどころか、むしろまだマシな部類です。
774
顧客と喧嘩するのは、営業の役目なんだけどね。
なんかここの米欄にいる一部の人って、本気で飛田が真っ当だと思ってそうで怖い(笑)
顧客の言う事を聞くのは当たり前なんですよ。
聞いた上で対案を出すなら兎も角、聞きもせずに技術の押し売りをする奴はエンジニア云々以前に問題外。
ななし
>>Zzzさん
>ただの移植作業分しかコスト見積りしてないんじゃないの?
>東雲は既存機能を全て移植する前提で金だしてるんじゃないの?
単純移植な訳が無いとは思いませんか？
既にあるシステムと全く同じ物を作る理由など、普通はどこにも無いと思いますが。
まともなプロジェクトなら、既存システムの問題点を解消した上で、ブラッシュアップを兼ねて行うと思いますよ。
>普通は首すげ替えですわ 持ってプロジェクト終了までの命です
もしうちの会社だったら、首を切られるのは確実に進藤です。
というか私が切ります。
さすがに、このお話通りであれば飛田を表に出さないようにはするなり、オブラートに包んで会話するようにするなり教育は施すでしょうが。
属人化した会社間の関係は、担当者が変わるという何処にでも有る当たり前の現象で容易に消し飛びます。
そして、結びつきが人間だけで技術的な裏打ちが無く、むしろ他と比べて劣っていたなら容易に仕事も切られます。
現実にこれは起こっている話で、ある意味世代間の話でもあるように思います。
ある一定以上の年齢層に、そうした属人的な関係を重視する向きが有るように経験上思いますが、もっと下の世代になるとそうした人間関係重視的な雰囲気は極端に薄くなります。
実際それで何度か大口の顧客を失った経験もあります。
ななし
「顧客」至上主義の方々は、「顧客」がいったい何を指しているか考えてみた事はありますか？
顧客の担当者はあくまでもその一部であって、その全てではありません。
利益を得るのは「顧客」であって「担当者」ではありません。
本当に誠実なシステム屋であるなら、「顧客」にとって最大限の利益となるシステムの提案をすべきです。
最終的な権限を持った方がそれを否定するならば、それ以上はお門違いですから従うべきですが。
このお話の流れ自体も、「担当者」が自身の利益を優先して顧客企業全体の利益を損ねるような例、のモチーフそのものに見えます。
サルーン
>「顧客」至上主義の方々は、「顧客」がいったい何を指しているか考えてみた事はありますか？
先週までに散々既出なんで今更ドヤられても…
しかも普通に提案すれば良いものを、受け入れフェーズで言い出すのは馬鹿としか思えませんよ。
ｺﾞｩ
鍵かっこおーいなー
ところで嶺井ってなんて読むの？
ななし
>先週までに散々既出なんで今更ドヤられても…
先週どころか、システム開発というジャンルの歴史上、散々既出の事で「顧客の要望こそが〜」というようなご主張でドヤっている方が多くいらっしゃいましたので、コメ欄の流儀に倣った次第です。
>しかも普通に提案すれば良いものを、受け入れフェーズで言い出すのは馬鹿としか思えませんよ。
タイムマシンがあれば、もっと前に言い出せたのではないでしょうか。
現実的な解として、初月のみ別計算での手入力で対処しつつ、飛田の主張するように根本的な解決となる方法で実装、とするのが妥当ではありませんか？
自社の落ち度として、それらの工数をかぶる事になるか、それとも多少なり負担して貰えるかは営業の能力次第といったところでしょう。
その責任が誰にあるかは、問題が解決後に自社内で判断すれば良い事で、少なくともクソ実装を新システムに引き継ぐ事の正当な理由にはならないと思います。
774
>>ななしさん
ななしさんの言われる「顧客」至上主義の方々ってどういう人なのかわかりませんが、その辺を全て考えるから「顧客」至上主義なんじゃないんですか？
顧客企業の短期メリット、中長期メリット、様々なコストと期日…色々な利害が絡む中で、なるべくベストに近い提案をし、後は顧客の判断に任せる。
それは、けして飛田のやり方ではない。勿論、新藤のやり方でもない。
そして理想を言うなら、それを行うのは技術者ではなく営業の仕事です。
技術者は技術的な側面でベストプラクティスを追うのが仕事ですが、営業の仕事は顧客との折衝とSE/PGからの恨みを買う事です(笑)
あかと
＞プーマさん
＞「実装のイメージを持たせてしまう用語は使わない」
これって、今回の例でいうと、退職者の計算ロジックをどう実装するか、極力言質を取られないように表現して、フリーハンドを残しておくってことでしょうか？
通り
以前のレスに返信もせずに書き込む無礼、お許しいただきたく。
カスミさん外す下りをもって、東雲のシステム課長さんがイニシアチブとかの発想は
陰謀論に過ぎるでしょう。
課長さんとしては社内で我が儘を言いまくってシステム更改の邪魔をする（多分、
それ以外の面でも色々と問題を起している筈です）超お局様の三吉さんを外したいのに、
その我が儘を受け入れてしまうカスミさんが邪魔というのが一番の理由じゃないですかね。
ここらへんは、多分、サブタイトル通りなんじゃないですかね。
あとは、個人個人の特例処理を一々組み込まれては東雲側としてもたまらんというのも
理由でしょうけれど、それは飛田が担当になった以上関係ない事ですし。
サルーン
>ななしさん
>初月のみ別計算での手入力で対処しつつ、飛田の主張するように根本的な解決となる方法で実装、とするのが妥当ではありませんか？
へえ、手入力で対応出来るか把握してないのに「手入力でもしたらいいんじゃないですか？」なんて言うのが「顧客の事を考え抜いた結果」なんですね。
勉強になるなあ。
通り
あと、エンターキーかタブキーかの議論ですけど、これ「標準だから」って
だけでタブを支持するのは、「既存だから」と言う理由でエンターを欲しがる
のと同じ程度でしかないので注意した方が。
実はこれ、Windowsに載せかえる時に何処でも揉めた内容のテーマの一つで、
この時は「Windows標準」に従ったところが結構酷い事になっています。
理由はフォーカス移動ではなく、「OK」ボタンと「キャンセル」ボタンの
キーバインドなんですが、標準仕様だから必ずしも優れているわけではないし、
日本語環境と親和性が良いとは限らない。
無批判に受け入れる事は三吉御前の発想とコインの裏表ってことです。
サルーン
>通りさん
嶺井のイニシアティブ疑惑は過去に主人公が触れているので、
伏線が有るともいえますよ。
あからさまな伏線なので、逆になさそうと思いますが。
ななし
>>774さん
あくまで私感ですが、お客様お客様と口にする方々は、往々にして顧客企業というよりも顧客企業の実際の担当者をそれと同一視している事が殆どに感じられてなりません（このお話のコメ欄も含めて）。
確かに、企業間の取引とはいえ最終的には人間相手なので、当然、最低限のヒューマンスキルは必要です。
そういう意味では飛田は不適格だと勿論思いますが、対比となっている進藤と比較して、どちらが根本の考え方としてより理想に近いかと言えば、飛田の方だと私は思います。
自分は技術畑上がりの経営者ですが、たまに営業でもあります。
稀にエンジニア的な事もしていますが、あくまで知識の更新が目的です。
実際やってみて774さんの書かれている理想にわりと近い事ができていると思いますが、これができるのは自身が技術畑だからこそだと思っています。
（幸い表立って恨まれるような事は無く日々を過ごせているようです(笑）
>>サルーンさん
>へえ、手入力で対応出来るか把握してないのに「手入力でもしたらいいんじゃないですか？」なんて言うのが「顧客の事を考え抜いた結果」なんですね。
>勉強になるなあ。
他の計算ロジックは当然飛田は把握しているのでしょうから、その処理結果がどのようなフォーマットになるのかは言うまでもなく把握しているでしょう。
最終的な結果さえ入力できればいいのですから、ごく現実的な解かと。
少なくとも、各個人毎にハードコード入りの例外処理用のロジックを作って不毛な三重作業を発生させるより余程建設的でしょう。
揚げ足取りにもなっていませんよ？
余談ですが…
このお話で問題にされている例が、表層のUIだったり力技で対処してしまっても表立って問題にはならないような事だから「お客様」優先といった意見が出るのだと思いますが、もしこれがセキュリティ的な点で明確な穴になるような要望だったとしたら、それを「顧客の要望だから」として許容するのでしょうか。
ちなみに、私の会社でそうした話が出たとしたら、説明を尽くしてもそうしろと言われたなら最終的にはその要望を呑む事になるでしょう。
エンドユーザーが顧客の中だけでなく、広く一般人が対象のシステムでもそうした事例はありますが、自分の会社はそれを理由に案件を蹴るほどストイックでは残念ながらありません。
サルーン
>ななしさん
>他の計算ロジックは当然飛田は把握しているのでしょうから、その処理結果がどのようなフォーマットになるのかは言うまでもなく把握しているでしょう。
「でしょう」^2ということですね。
とてもわかりやすい回答ありがとうございます。
しかし飛田も強かですよね。
話の流れに寄っては共通ロジックは見積り内でやれ、となりかねないところを
うまく三吉を激昂させる事で見積り外にできました。
プーマ
>あかと
言葉が不十分でした。「実装技術」ね。
>「実装のイメージを持たせてしまう用語は使わない」
ここも言葉が足りなかった。客先より、むしろ、内部に対して「実装イメージを持たせる言葉」を排除する。例えば「CSVでデータを吐き出す」とか、超要注意。
「現在利用中のXXシステムにデータを取り込めるようにする」などとしておいて、インターフェイスの調査は後でする。取り込み側が、なんちゃってCSVで、日本語のコーテションのあるなしが後で問題になったりすることがある。
意外と「CSVで」みたいな一言で片づけちゃうのは、顧客側の情シスだったりする事も多い。
ななし
>「でしょう」^2ということですね。
>とてもわかりやすい回答ありがとうございます。
いえいえ、どういたしまして。
言葉遊びしか出来ない方の様なので、サルーンさんへの以降のレスは控えますね。
プーマ
実装イメージというとまた誤解を受けるかもしれないので、付け足しておくと「技術者的観点での先入観を排除しようとする」の方が、より、ねらいに近いです。
Zzz
>ななし氏
昔はともかく今時は段階踏むんですよ
そうやって一気にやろうとして死屍累々だった反省です
無論ベタ移植ではなく、モジュール単位に改修は行いますが
呼び出し側から見た場合には互換を保つのが普通です
今回の提案()とやらには明白に互換がありません
>サルーン氏
東雲側も無能であることは何ら否定しません
嶺井なんか何の仕事してんのこいつ? と思いますし
但し、飛田が「聞いてなかった」なんざ通りませんわ
プロジェクトリーダーだと言うのなら、本案件におけるH&G社の代表なんです
東雲は業務知識の共有がなされている前提の下に発注しています
当然、前任者の進藤にも引き継ぎ不備の責任があります
木下? 普通は「明日から来なくていい」ですよ?
ま、リアルなら『まぁまぁお互い悪かったことですし』と上の方で手打ちにしますがね
どうやらそういう発想すらない主人公()が一番の無能である、という意見には全力で賛同します
サルーン
>Zzzさん
だいたい、同意です。
その辺を踏まえて責任は50:50くらいかと考えてます。
実対応的には、瑕疵にはしないけど予算は変更なし ということで。
そういった意味では箕輪は珍しく良い仕事しました。
共通化ロジックを追加修正扱いにして予算獲得しましたからね。
ななし
>>Zzzさん
どうも認識している世界が少しずれているようです。
9桁以上の案件だとそうした事はあるのかもしれませんが、残念ながらそうした案件の経験はそう多く無いので、常識がどうなのかは何とも言えません。
そもそも、こと内部的な仕様に限っては旧システムのそれを引き継ぐ、という案件は一部の例外を除いてほとんど見たことがありません。
むしろこの話の様に、UIを元に似せろ（バックエンドはどうでもいい）という要望は多く経験しましたが…。
客層的なものもあるのかもしれませんね。
L
一連のやり取りだけで「顧客が何を求めているか」判断する術はないと思うけどなあ。
予測することは簡単だろうが。
Zzz
>サルーン氏
一瞬ん? と思いましたが
よくよく見ると、それ箕輪の発言だったんですね
失敬失敬
あ
客とけんかするのは技術者だよ。
それを丸く収めるのが営業だったり、上席の技術者。
プーマ
余談だけど、顧客の情シ部門が、ことさら全体最適を強調してる時って、案外、要注意だと思うんだ。（こっちは非常に楽ができるんだけど）
アドオン審議会の名目で、バッサバッサ却下した案件が、１年後に課題検討表で、そのうち1/3くらい復活してて、すごく困った事がある。
テーブル弄る大物の改修が紛れ込んでて、それの対応するのに、他の機能も弄らなきゃいけなくなって、工数がおかしな具合に膨れあがった。
見積もり提示時に正直に話したら、要望してる機能以外の改修費も取るなんておかしいだろ、と言われて、硬直状態。交渉に出てきたのは、当時のプロマネなんで、費用が膨れるのはどうしても認められなかったみたい。（これは感想なんで真偽は定かではないけど）
で、先方の部長が、直接交渉に出張ってきたので、タイミングを見て、両会社の部長だけで話をする場をセッティングして（これが一番大変だった！）事情を話してもらった。
結果、プロマネ交代で、費用も見積もりから、少しの値引きで妥協点を見つけて改修した。
全社最適も現場最適も、結局は使い分けで、バランスが重要なんだけど、どちらか一方を正義にしてしまうと危うい。
更迭されたプロマネは切れ者に感じたし、実際、無能ではなかったと思うんだけど（却下したアドオンの2/3は良い判断だったわけだし、導入時のコストは抑えた。総合評価では優秀に感じる）それでも問題が起きる時は起きる。
こっちは費用の折り合いをつける事だけを望んでいて、更迭は望んでいなかったんだけど、なんらかの業務影響も起きていて、そういう判断になったのか、と想像すると、口出しする余地ないし、結構複雑な思いをした。
ちなみに後釜に座った人は、なんかボヤッとした人でピンとこなかったけど、しばらくして経営企画室に異動になった。実は超優秀でひっこ抜かれたんだと聞いて、つくづくわかんないもんだよなぁ、と思った。
あ
顧客の情報システム部門が全体最適で最大公約数的システム作れってんで作ったことあるけど、
しばらくしてから分社化されてそれを他所に売り出したことがあったな。
社員も引き抜かれて今でもそのまま売り続けているようですが。
Zzz
>ななし氏
まあ客層といいますか業種といいますか
本件のように金銭扱うシステムは、何よりも信頼性を重視します
最終出力は変わらないことがほとんどで、故にテスト仕様書も修正のみで使い回されます
テストデータもまたしかり
前と変わらない入力で、前と変わらない結果が得られればよし
無論テスト修正見落としは普通に起こりえますが、それは新規作成でも同じです
むしろテストケース自体の漏れが少なくなる分、ミスが減る傾向にあるようです
こと会計系においては、1から作ったほうが早いなんてのは幻想です
それはテスト工数を軽視、あるいは無視しているだけです
業務そのものに変更がある場合も、システムが変わるならまず単純な載せ替えを最初に行います
これは今回のようなアンドキュメンテッド(多分)な仕様の洗い出しも兼ねています
なんもかんも手っ取り早く一気にやろうとしても、実質コストはほとんど変わらず
無駄にリスクが増大するだけなのです
プーマ
>あ
それって著作権とか著作者人格権とか問題になりませんでした？
社員引き抜かれたって、それって踏んだり蹴ったりじゃ…
メネメン
前半の武田さん、後半の飛田さん。
また面白くなってきた。
自分語り成分とマウンティング成分ちょい多めなのが、武田さん派の特徴？
メネメン
>プーマさん、
>「それは専用のクライアントソフトを作らないようにする、という要望でいいですか？」のように開くようにしてる。
この「開く」という言葉は、どういう意味で使っている用語なんですか？
Jairo
まあ少なくとも今回発覚した特殊処理が網羅された、旧システムのテスト仕様書はなかったみたいですね。あればさすがに気づいたでしょうから。
ビジネスロジック部分も全部VB6だったのかなぁ。ひょっとすると、テストコードもテストデータもなかったりして・・・。
?
何かをするのに必要なものはお金と権限なのかもしれない
決定権がなければ良いことでも必要無しとして却下される
全権を持つ人間が率先してやるのがベストだろうけど
日本の企業はほぼ成長を止めていて現状維持を目指しているから合理化をはかる必要はないんだと（日本の企業の大多数は中小企業でかつ赤字企業、節税目的でやるところもあるらしく企業の”利益”には無頓着）
本作の五十嵐某が副部長という権限を得て事に当たったのは正解だったのかなとあらためて思った
（作文ですみません）
育野
>>Jairoさん
>まあ少なくとも今回発覚した特殊処理が網羅された、旧システムのテスト仕様書はなかったみたいですね。あればさすがに気づいたでしょうから。
・元々旧システムの要求仕様にもなかった
・三吉－進藤ラインの「その都度対応」により山ほど追加発注が発生
→この機会に一掃/システム化しよう(By嶺井)
ということじゃないかと想像します．
だと「進藤外し」も説明つくような．
ところで．
素人でよくわからないのですが，
システム更新の場合，旧版のソースって参考にしないものなのでしょうか．
こういう例外/特殊な処理の部分だけでも確認しないのかな？
教えて，エラい人!
Jairo
> 育野さん
もちろん、既存コードのチェックはするでしょうが、分業したようなので自分以外の部分に抜けがあるかどうかは知りようがありません。
普通どうするかというと、現行コードど同等の要件定義書を起こし、もし居れば社内の現行仕様に詳しい人にレビューをお願いします。契約内容によりますが、この段階で顧客レビューをしてもらい検収という手順を踏む場合もあります。まあその場合も仕様漏れがあることは往々にしてあるんですが。
新規にコードを書く時も、もちろん既存コードを参考にするでしょうし、可能なら今回使う言語にトランスレートすると思います。
へろへろ
東雲の嶺井課長が新藤外しに動いたのは、別にイニシアティブだからじゃなくて、その立場･役職からすれば当然の気もしますね。
課長すなわち管理職ですから、ギャラはその業績から判断される裁量制です。
そしてまだまだコストセンターである情シスの人間ですから、
・システム導入によって、業務コストを下げられたか。
・同様に、収益は上がったか。
・上記がシステムのライフサイクルを通してもたらされるか。
などが評価項目になるはずです。
オフィスから紙を減らせば上記すべてが達成できた時代ならともかく、電子化（古いな）がふた周りぐらいした今となってはそうもいきません。
それに、業務効率化の手法としての属人化の排除や標準化の推進なんてのは非IT系の雑誌にすら書いてますから、査定のときには必ずツッコまれるわけですよ。
そんなときに特に言葉を選ばず「担当者の言いなりでこんな機能を実装しました」といっちゃったらどうなるやら……。
ずばり「「現場の無駄」に直言できるIT部門であれ」といわれる経営者も現実におられますし、納得できない展開ではないと思いますね。
まりも
>お客様が求めているものを作るのが、私たちの仕事でしょう。
というと一見正しいように見えるが、
それは、顧客側の位置担当者がわがまま言ってわめているのに対して、
わかりましたと言うことなのか？
コメント欄を見てもその違いがわかっていない人が一定の割合でいるようなのだが。
わかってないということは、つまり普段からそういう仕事の仕方をしている？
日本のIT業界って長くないんじゃないか？
まあわかっている人もいるようなので多少は安心もしましたが。
nr
>まりも
>それは、顧客側の位置担当者がわがまま言ってわめているのに対して、わかりましたと言うことなのか？
自分には、みなさん、そこは解ってるように思えます。
・どうせただのわがままに決まってる or オレ様はそんなの簡単に見分けつく。オレが正しいからオレに判断させろ
と言ってる人と
・いやいや、そんな単純じゃないぞ or そこは受注側が勝手に判断しちゃだめだろ
の主張の違いじゃないかと思ってる。単なるわがままであることが間違いないなら、そりゃ聞く必要ないだろうと思ってるよきっと。わがまま認定する基準は多少バラけてるような気はする。多少じゃないか。結構バラけてるか。
育野
>>Jairoさん
お返事ありがとうございます．
そうですよね，特段の理由がない限り既存コードは積極的に利用しますよね．
#その辺のレビュー体制とか描写なかったような．
lav
さすがに、属人的処理をハードコーディングするというパターンは思い浮かばんかったわ。斜め上すぎる。
普通、何何法改正によるシステム変更要件が入ってくるとなったら、
それに伴う影響範囲、変更パターンを洗い出すでしょうよ。
屑二号
「進藤に返す言葉を失う飛田」の絵が面白かったです。
あまりの価値観の差に愕然としたんでしょうね。
普段「それじゃダメなんだ」を体現した言動をしてきていた筈なのに、全然わかってない&今それを言うか、的な。
冷たい方程式でもこんな場面があったような。
主義主張の内容はともかく、こういう場面に出くわすことが稀にあるんですが、ついニヤニヤしちゃいますね。
DEADBEEF
そりゃ、稼働早々業務が回るか回らないか心配してる人に
長期的視点を求めたって、そりゃ無理ってもんですよ。
どうしてわかってもらえないのかって、
そりゃわかるように説明してないんですから、当然です。
屑二号
紙から電子化、のみならず、手書きからワープロへ、とか、社内に初めてPC導入、みたいな時代にもこういう「理想主義者と守旧派のチャンバラ」は陰に陽に行われていたのでしょうね。
私その時代を知りませんが。
彼等がチャンバラを繰り返してくれることで日本社会は漸進していくわけで、全くありがたいものだ、と思わざるを得ません。
この話を読んで「内製にしたほうが良いんじゃないか」的な感想がたまに出て来ますが、ITがアウトソーシング中心になったのはまさに作中の三好のような担当者、進藤のような開発者が引き起こしたことなので、恐らく同じことを繰り返すだけのことになりますね。
匿名
>ITがアウトソーシング中心になったのはまさに作中の三好のような担当者、進藤のような開発者が引き起こしたことなので
違うよ。安かったから。今も安い。
ユーザーは俺らの倍給料もらってる。外に出した方が安いに決まってる。
単価が上がってほしいと思うが、そうなると、多分、仕事がなくなる。
H＆Gは自社でハーモニーっていうサービスプロダクトを立ち上げたけど、良い判断だと思う。
プロダクト持ってないと生き残れない、っていう危機感を俺は持ってる。
屑二号
＞違うよ。安かったから。今も安い。
＞ユーザーは俺らの倍給料もらってる。外に出した方が安いに決まってる。
何故安いのかって、内製やってた連中が要求してくる予算が青天井だったからです。
大企業のシステム部門が子会社化された、その目的の一つはコストカットです。
単なる罰ゲーム。
で、ついでに、IT市場の殆どはその親会社→子会社という受注形態に収まってるわけで、「お互いに大損こくわけにはいかない」という事情もありますので、日本はまだ「内製」から脱し切れていないとも言えます。
らいてふ
今回の新藤カスミは良い仕事したよね、機転を利かせて場の雰囲気を一変させた。
彼女のエンジニア人生はもうじき終わりを迎えそうだけど、この存在感があればどこでもやっていけそうだ。
無言だった飛田が何を語るのか、次回の関心事はそこかな。
774
言い争っている人達が、同じ物を別方向から見て「これは三角だ！」「これは丸だ！」って言い合っているようにしか見えない…
答え：三角錐
774
>>あさん
いえ、客と喧嘩するのも本来は営業の仕事ですよ。
だからこそ、営業は「会社の顔」足りえるのです。
とは言え、現実として「技術に精通した営業が殆ど存在しない」＆「ちまちまと細かい所の共有までする時間が無い」ので、技術者が営業の真似事をしているだけです。
ですが、多くの場合は真似事に終わっているのが現状です。
まあこの辺は色々なコラムなんかも昔見た覚えがあるので、興味があったらググって読んでみてください。
Jairo
まじでどうでもいいわ。
なななし
三角錐ってどっから見たら丸にみえるんですかん？
はいはい、揚げ足取り揚げ足取り
DEADBEEF
超高速に回転している三角錐を、底面から見れば
円形に見えるじゃないですか。
そういう事を言ってるんですよ。
どうしてわからないんですか。
lav
ぶっちゃけると、飛田さんって、
冷たい方程式の渕上さんだったり、傭兵達の挽歌の杉野さんだったりと、
大差ないんだろうなー。
理想主義者ってか、
ぼくのかんがえたさいきょうのぷろじぇくとまねじめんと、
ぼくのかんがえたさいきょうのしすてむかいはつ
的なノリで。
理想は大事だが、現実との折り合わせってのも大事。
バランスなんですよね。何事も。
今回の飛田さんのミスは2つ。
1.相手を無駄に怒らせて、事態の収拾に時間を要したこと。
2.適切な暫定対処と本格対処を、カスミさん、箕輪課長の手助けなしに提示できなかった。
今回のカスミさんのミスってか、ハードコーディングなんて最悪。
それと、どうせ、過去の改修案件管理表とか退行テスト仕様書とかソフトウェア変更仕様書とか作ってなかったんだろうね。
ってか、大元の元凶だよね。
ぶっちゃけ、木下くん、本当にうっかり見落としてたんじゃない？
ドキュメントにすらないだろうから。
まりも
>自分には、みなさん、そこは解ってるように思えます。
わかっている人も多いのは確かですけどね。
全員ではないように見えてならない。
しかし。
>・どうせただのわがままに決まってる or オレ様はそんなの簡単に見分けつく。オレが正しいからオレに判断させろ
>・いやいや、そんな単純じゃないぞ or そこは受注側が勝手に判断しちゃだめだろ
飛田さんのように、事実が大事で言い方なんかどうでもいい、といっている人の言葉ならともかく。
言い方が大事だといっている人がこれってのは、言動一致がなさすぎるんじゃないですか？
lav
そっか、箕輪課長の問題はそこだ！
そもそも、今の問題の元凶がカスミさんにもあることを認識してない。
認識してないから、カスミさんの立場を守ることしか頭にない。
今回の仕様もれ問題の責任の大きさはカスミさん＞飛田さん≧箕輪課長>木下くんだと思う。
私が嶺井さんでも、カスミさんは切る。
あと、自分が箕輪さんなら、飛田さんには必ず営業を同行させ、話す内容は営業に任せる。飛田さんはあくまでも営業が詰まった時の助言役。
jairo
システムのことも技術もわからない営業に来られても、お客さんは困るだけじゃないの？
lav
jaitoさん
まあ、本当はそうなんですよ。本当は。
でも、飛田さんだけでは、客先厳しいですよ。
メネメン
>ITがアウトソーシング中心になったのはまさに...
本編とはあんまり関係ない話題かもしれませんが、
日本のITが外注中心になったのは、なぜなのか結構気になります。
なんでなんでしょうね？
アメリカは、外注・内製・市販品の購入がそれぞれ３分の1程度（内製が一番多い）で、
日本は、2000年頃の情報で、７割・２割・１割くらいらしい。(※ただし、ソースは日経)
外注率の高さと、多重下請け構造と、エンジニアの部品扱いと、
どれも根っこはつながってる気がするけど、その根っこが何なのかよくわからないです。
「俺も昔はCOBOL書いてたよ」っていうユーザー企業の人、かなりいますけど、
汎用機全盛時代は、内製率高かったんですかね？
n
パッケージに業務をあわせるか、あわせないかの違いじゃない？
日本は帳票１つとってもややこしいのが多い
あとは昔と違って求められる技術、知識が多くなったのも大きい
屑二号
＞日本のITが外注中心になったのは、なぜなのか結構気になります。
＞なんでなんでしょうね？
まず第一に、内製のコストが高くなりすぎたから。
IT業界、こと業務システム関連の業界(以下、IT業界)の成り立ちをかいつまんで言えば
・大企業が必要にかられてシステムを導入する
・電算室だとか、それらを作る/保守する部門が立ち上がる
・そこに本業では微妙だった人達が寄せ集められる
・コストが膨れ上がる
・コストカットの為にシステム部門を子会社化
親会社「別会社に発注する形になったからこれが『アウトソーシング』か」
子会社「自社社員で実作業できるような予算貰えなくなったお！実作業は下請けにやらせざるを得ないお！」
こんな感じですかね。
ユーザ企業のIT業界へのヘイト値が高いのは、普段直接関わるのは子会社の面々であり、彼等に一度発注したものは、どんなにクソなものが出来ようとも苦虫噛み潰した顔で検収せざるを得ないから。
子会社であるがために最低限、彼等が生きていくだけの金は払ってやらなければならない、と。
まあ「元々本業で微妙だった人達がぬるま湯浸かってる」ようなイメージしか湧かないんでしょうな。
日本のIT業界の不幸は、その成り立ちの時点で「微妙な面々」がそこに集められてしまったことで、日本のIT業界の「性格」的なものはそこで決まっちゃってます。
微妙な人がシステム部門に流され、「俺は流された」という自覚を持ったときにそれを自身の中でどう処理するかって、「俺はお前らの為にこんなことをやってやってるんだ」と思い込むことでどうにかプライドを保とうとするんです。
これが普通の人間の心理。
コストが膨れ上がらないわけがない。
774
>>なななし
ごめん、円錐の間違いorz
サルーン
日本のITが外注中心なのは、簡単には正社員の首が切れないからですよ。
開発するネタが年中ある企業なんて、そうそうありませんからね。
SZSR
システム開発ってそんな経緯があったのか・・・。
世代的に内製が盛んだったころってよく知らない。
おじさん
ずっと書き込みを遠慮していたおじさんが歴史の体験者として書きます。
長いですが、これくらいしか役にたてないんで、やっておきます。本筋の議論は若い方にお任せします。
私は電算室の子会社化に、当事者として関わったので、他社動向もかなり調べました。これがすべての真実ではありませんが、まずまず客観的な見方はできていると思います。
まず、歴史的な出発点が大企業の電算室の子会社化というところは、概ね正しいと思います。
出発は、グループ経営内で、各子会社内に電算室が立ち上がるような事態が起き始めたので、シェアードサービス化するために独立子会社化し、全体の面倒を見る体制にしたのが発端だと思います。子会社化すると自立採算を求められるので、情報子会社は他社の受託も始めるようになりました。まぁ。ここらが原型だと思います。電算室予算の青天井が理由だったというのは聞いたことがないので、それが伝聞であれば、特定の産業での話ではないかと思います。
電算室が、本業が微妙な人の集まり、という発言がありましたが、ある意味正解ですが、ちょっと補足がいると思います。
本業で微妙はそのとおりなんですが、大抵の場合、コンピューターが好きで、研究所などで、自前でIT化を初めてしまったような人を集めて作られたケースが多いと思います。今はほとんど見なくなりましたが、5年前くらいまでは、メーカーより技術に詳しいような、オタクおじいさんみたいな人がチラホラいたと思いますが、そういう人です。根っからコンピューター好き。
今では考えられませんが、一昔前は、千人以上規模のユーザー企業であれば、WANの設計が出来るような人が大抵１人はいました。LANを敷くにも、何メートルおきにリピーターをかませる、というような事を考慮しなければならない時代からやってきた人達なので、現物にも強い。
本業よりITが面白くなってしまった人なんで、微妙、という表現はなかなか適切だと思います。ただ、無能、というニュアンスで使ってるなら、ちょっと違うと思います。電算室創成時の部長さんなどは、微妙どころか、やり手で若い人がアサインされてたんじゃないでしょうか。全く新しい仕事を立ち上げてたわけですから。私が知る、ユーザー会などでお目にかかった古株部長さん達は、システム化をすすめる為に、現場や経営と戦ってきた人たちです。昔は、IT化を一番と毛嫌いしていたのは現場です。
長くなったので一旦切ります。創成期はこんな感じです。
おじさん
続きです。
さて、所謂、外注開発のスキームが出来る頃には、各社IT化を進めようとする機運が高まった頃と丁度重なっていたこともあって、IT要員の需要は高まっていました。ここでバブル崩壊というキーワードが絡んできます。
企業側はコスト削減のためIT化は進めたいという希望を持っていました。もちろん、バブルで飛んでしまったような会社ではなく、景気が悪くなりつつあり、何か手を打たなくては、という状況にある企業です。また同時期に、就職氷河期が到来しました。企業が一斉に新卒採用を絞ったからです。これが追い風になり、新規の小さなIT企業が立ち上がってきました。就職にあふれた新卒はネコも杓子もIT企業に、という流れが起きていたのはこの時期です。新興のITは、何しろ賃金の安い若い者をあつめ、また、ITの原価と言えば、ほぼ人件費なので、低価格勝負が可能でしたた。ITの外注費が低価格の相場を形成してしまったのはこの時期だと思います。
このころ独立採算を果たした、所謂子会社から出発したITの会社は、資本を引き揚げられ、グループから切り離さる事も起きていたはずです。親会社からコストの面で乗り換えられてしまうという現象です。屑さんが、親会社がITにヘイト意識がある、とおっしゃってましたが、こういう歴史をたどった企業では、むしろ、子会社の方が明らかな憎悪をもっていたんではないかと思います。（まぁ、実体験だと思ってください。）ある意味、裏切りが起きたわけですから。
親会社から子会社へのヘイトがあるとすれば、独立採算になった途端に、親会社の案件を優先しなくなった事、内製時代は情シ部門から積極的なシステム化提案があったのが、子会社化するとともに、言われた事しかしなくなった事、というような事があると思います。これは良く聞きましたし、今でもこういう事は起きているようです。更に付け加えるなら実体験です。
おじさん
更に続き
このような流れで、外注が安くつく、という状況ができました。業種にもよりますが、どの企業にとってもITは本業ではないので、外注を検討するようになったと思います。また、この頃には、基幹システムにパッケージを採用し、パッケージに業務をフィットさせる、という流れもメインストリーム化しました。基幹システムという企業の最重要システムをパッケージ化することで、業務に精通した社内人員でなくともITを任せる事は可能、という考え方が根付いていったと思います。外注化とパッケージの積極採用は、関連していたと考える方が、自然ではないかと思います。
今も昔も、すごい人と、ダメな人は両方いたと思います。技術的な素養の面ではそう変わりないと思います。昔はフレームワークのような便利なものもなかったし、スピードチューニングのためにコンパイラの仕組みまで知る必要がありました。今はそれらが不要な代わりに、多様は環境や言語に対応する必要があると思うので、学習コストは同じくらいではないかと思います。若い方には意外に思われるかもしれませんが、ひとつ、今のIT企業の方が、勝っていると感じるのは、プロジェクト管理技法や開発技法が洗練されているということです。ロートルには、オブジェクト指向の理解などより、よっぽど身に付きにくい技術だと思いますし、ビジネスにおいて、とても有用だと思いますので、若い方は、どんどん磨いて武器にしていただきたいと思います。
おじさん
最後です。
ここまで書いた事は一つの観測結果にすぎません。
ここにいらっしゃる方は若い方のように感じますので、おじさんの歴史体験のようなものを置いてみました。ただ、それだけです。
議論にひっぱり出されると、どうしても、老人臭い、保守的な意見になってしまいますので、これで引っ込みます。
n
おじさんの実体験と考察は面白いですね。
こういうのは滅多に聞けるものではないから勉強になります。
らいてふ
昔はITなんて言葉すらなくて、ひたすら「電算化」だったなぁ。
確かに現場の連中の抵抗は凄まじかった。
現場労組が組織したの交渉窓口の名称が「反合理化闘争委員会」だったものw
隔世の感がありますね。
ちなみにロジック部分のメインは当時組んだCOBOLのまま。
今でも現役バリバリだよ。
屑二号
＞おじさん
大変興味深いお話ありがとうございました。
＞本業よりITが面白くなってしまった人なんで、微妙、という表現はなかなか適切だと思います。ただ、無能、というニュアンスで使ってるなら、ちょっと違うと思います。
「本業のほうでトップクラス未満だった人」という意味で「微妙」としています。
無能、も含みますが、勿論それが全てという意味ではありません。
uglyfrog
コメントされているみなさん、個人的悪感情というか憎しみというか、凄いなあ。みなさん実はイニシアティブ所属とかなのかなあ。
>>ななしさん
業界の通例としてわがまま担当に振り回されたご験を御多分にお持ちのようで痛み入ります。
少し疑問なのですが、「顧客」とはステークホルダーという意味合いでしょうか？そもそも顧客担当様も実務者様も決済される役員様も全員を含めて「顧客」なのではないでしょうか？そのバランスを取る事がはたして一介のPLに可能かとすればそれは随分と難しいことでしょうけれども、本当に意味のある「顧客企業の利益の最大化」は、ただ効率化を推し進める所には無いかと思います。
yellow
「自分（エンジニア）の仕事は誰にでもできる仕事ではないが、
他人（総務）の仕事はバカでもできるようにすべき」
という飛田さんの
属人化を排除すべき基準って何でしょうかね？
「並行運用を開始した最初の3日間で、
1000を超える数の問題報告や改善依頼が上がってきていた。」
というのは、平行稼働であっても
運用に耐えられるレベルではなさそうな気がします。
「激減した」後の数がわかりませんが、
「機能的な欠点が３日間で1000」というのは、
ちょっとヤバいプロジェクトと比較しても桁が２つ違うような…
前回のEnterにしても今回の契約更新処理への提案にしても、
基本姿勢から後方互換性を軽視しているのが
問題の根本原因と考えます。
個人的には三吉さんの発言は、
「後方互換性を保ってくれ」という当たり前の主張に思います。
不必要な発言もありますが、
箕輪さんがまともな提案をした際には受け入れていますし…
また、「仕様を見落としたのはハードコーディングのせい」
のようなコメントがありますが、
本社工場以外も実データでテストすれば良かっただけだと思います。
（ハードコーディングでも良いと言っているのではありません。）
メネメン
>屑二号さん、
システム部門の子会社化が、日本が外注中心になった一因ではないかというのは理解しました。
ただ、数千人規模の比較的大きな会社で、システム子会社を持たないようなところでも、
外注が中心が多いと思っているのですが、そこはどうお考えですか？
>nさん、
>パッケージに業務をあわせるか、あわせないかの違いじゃない？
>日本は帳票１つとってもややこしいのが多い
汎用機時代は、ほぼスクラッチからのカスタム開発だったんじゃないかと思うので、
もし、その時代は日本でも内製率が高かったんだとしたら、
カスタム度の高さ以外に大きな要因が、ありそうな気もするんですがどうでしょう？
>あとは昔と違って求められる技術、知識が多くなったのも大きい
これは、かなり影響してそうですよね。
COBOLの技術者は育成・維持できてたけど、汎用機からオープン化のタイミングで、
対応した技術者を育成・維持できなくなったというような会社の話は、
実際に聞いたことがあります。
>サルーンさん、
>日本のITが外注中心なのは、簡単には正社員の首が切れないからですよ。
>開発するネタが年中ある企業なんて、そうそうありませんからね。
企業規模にもよるのかもしれませんが、千人規模以上くらいの企業なら、
開発するネタは年中あるように思っているのですが。そうでもないですか？
首を切れるかどうかと同じ意味かもしれませんが、
人事制度や人材の流動性の低さは、外注中心になっていった大きな要因かもしれませんね。
子会社化の話も、システム部門には他とは異なる人事体系を適用したり、
外から人材獲得ができやすい環境であれば、違う流れもありえたように思いますので。
>おじさん、
貴重なお話ありがとうございます。
電算室や子会社化が起きたときには業界にいなかったので、大変参考になります。
個人的には、外注が安くつくという認識が広まったのは、
ここ10~15年くらいのことなんじゃないかと思ったりしてます。
自分の経験上、2000年頃は外注すると高いので、
内製できるようにしたいという要望が結構ありましたので。
もし、そうだとすると、外注中心となった理由は、
コスト面以外の要因のほうが強いではないかと思ったりしています。
kawa
外注するのはローテーションで情報システム部門にいる人々が
自分でリスクを負いたくないからというのも理由の一つじゃ
ないかと思うのです。
IBMがSIerってやり方を確立したとか日経BPの読物には書いて
ましたが、それで政府もSIerを奨励してみんな外注にいった
のかもしれません。
jairo
再雇用の人たちのロジックについては、庶務担当者の手入力が必要みたいなので、実データが仮にあったとしても期待値を用意できるかどうか微妙なとこだと思います。
そもそもこのご時世に、本社分の実データを事前に手に入れられたことに驚いてるんですが、この手のシステムではそれが普通なんでしょうか。
red
yellowさん＞
＞「並行運用を開始した最初の3日間で、
＞ 1000を超える数の問題報告や改善依頼が上がってきていた。」
＞というのは、平行稼働であっても
＞運用に耐えられるレベルではなさそうな気がします。
VB6 → WEBへの移行、人事・勤怠システムということから考えると
1000というのはそれほど大げさなものでもないと思いますよ。
ひどいのだと、桁が１つ違う場合があります。
そういうのはだいたい元請け→下請け→孫請けと伝わっていく間に情報が消えたり変わってしまったりすることが原因で
しかも元請けも下請けも仕様を理解してないからいい加減な仕様で通してしまってユーザ受け入れテストの段階で発覚するということも多くて。
メネメン
>>プーマさん、
>>「それは専用のクライアントソフトを作らないようにする、という要望でいいですか？」のように開くようにしてる。
>この「開く」という言葉は、どういう意味で使っている用語なんですか？
これ、タイポじゃないと思って聞いたんですが、もし、タイポだったらすみません。
折りたたまれた状態の表面的な要望を、解きほぐして広げていく(英語だとunfoldとか)、
みたいなニュアンスだと思いながら読みました。
メネメン
>外注するのはローテーションで情報システム部門にいる人々が
>自分でリスクを負いたくないからというのも理由の一つじゃ
>ないかと思うのです。
ジョブ・ローテーションですよね。それは、ありそうですよね。
特に、通信・金融・官公庁とかは、数年単位のローテーションがあったりしますので。
yellow
>jairoさん
実データを手に入れるのが「普通」ではないと思います。
私は工場等が顧客のことが多いのですが…
ライバル企業に売れそうな機密データでも
稼働前には実データをいただいてテストしたりしています。
お客様も背に腹は代えられないということなのでしょう。
対象者に対して契約更新処理を行えば、
新旧で結果が違うと考えたのですが、
確かにそう簡単なテストでは検出できなそうですね。
入力が必要となると、全員分テストしないかもしれないし、
たまたま同じ結果になってしまうかもしれませんね。
仕様を把握してアタリをつけてテストに盛り込むしか
なかったということになってしまうのかな…
>redさん
そうなんですか？
知らない世界があるものですね。
自分のモノサシがいかに頼りないかを実感します。
らいてふ
1995年以降、インターネットの普及に伴って、Webが急速にコモディティ化した。安い理由はそれだと思います。
ユーザのリテラシーが昔とは比べ物にならないくらいに向上した今、どんなに優れた革新的なシステムを提供しても、誰も「感動」しないのです。そして、感動のないところに高い金が払われることはない。
それが、現代のIT業界が直面する課題の本質ではないでしょうか。
ビジネスという面では、昔の牧歌的な時代は良かった。
一人のコンピュータ好きとしては、何でも安価に手に入る今の時代が最高に楽しいけれども。
屑二号
＞>屑二号さん、
＞システム部門の子会社化が、日本が外注中心になった一因ではないかというのは理解しました。
＞ただ、数千人規模の比較的大きな会社で、システム子会社を持たないようなところでも、
＞外注が中心が多いと思っているのですが、そこはどうお考えですか？
それはそれぞれ何かしらの事情があったんじゃないかなぁ、と思います。
日本では、エンドユーザーがIT業界に金を入れる、それを金額ベースで見た場合、圧倒的に多いのは子会社への発注だったと記憶しています。
金額が多ければ当然その下、その流れの中に組み込まれる技術者の数も膨大になるので、「日本のIT業界はほぼそんな感じ」と言えると思います。
件数ベースだとそうではないのかもしれませんけども、金額ベースで見た場合には誤差の範囲なんじゃないかと。
SZSR
>おじさん
興味深い話をありがとうございました。エッセイを読んでる気分になりました。
もう少し時代が進めば、ITの移り変わりが歴史として研究されたりするかもですね。
ITという単語がそもそも新しい言葉なのかも知れませんが。
私はバブル崩壊もIT革命も体験していない世代だからか、今のIT業界の慣例？に疑問を抱くことがあるのですが、おじさんのおっしゃるような時代背景の先端と考えればたしかに得心行くことが多々あります。
・なぜ外注主体なのか。
・特定企業の発注しか受けない会社があるのは何故か。
・なぜ本来は技術職であるプログラマが低い社会地位に分類されているのか。
自分でも少し調べてみようと思います。
屑二号
補足:
「何かしらの事情」の殆どは、大企業の「子会社化して子会社に発注」を見て、それを「成功事例」と受け止めた各企業が
・「内製」はイケてない
・「外注」にして費用を抑える
というトレンドに乗っかっただけなんじゃないかと。
匿名
らていふさんって
労協が機能するくらい、大き目で、まっとうなユーザー企業で
恐らくは四十後半より上の年齢で
システム部門で
多分、課長職くらい
ってことかぁ
顧客の意見として拝聴したほうがよさそうだ
たかたかハリコフ
私はユーザー企業の社内SEなのですが、外注が安いという話が出ていますが、今一つしっくりきません。
私の勤め先で10年近く前に基幹システムをホストからＷＥＢに作り直した（外注です）のですが、本稼働後の追加開発を依頼すると異様に高い見積もりを持ってくるので内製で対応しています。
外注しているのは自社に技術者がいない、人手が足りない、最新の技術動向に触れたいとか、金銭以外の理由があると思っていたんですが、コメントを見ているとそうでもないみたいですね。
プーマ
>メネメンさん
返事がすっかり遅くなってしまってすいませんでした。ちょっと忙しくて、ここを見る時間がなかったもので…
>この「開く」という言葉は、どういう意味で使っている用語なんですか？
またまた申し訳ない。つい、通用しにくい言葉をつかってしまいました。
趣味で文章作法の学校に通っていた事があって、その時に良く講師に言われてた言葉です。
ニュアンスは、メネメンさんの解釈で問題ございません。
一文二意（一つの文で複数の内容を表現する）や複文を直したり、慣用的な表現（わかったような気になってしまうが、実は真意が伝わらない表現）を直す時に、「開きなさい」という表現をされてました。私の提出する課題は、特に、この「開け」という赤ペン添削が多かった…今でも、悪文は直ってないけど。
外注化の経緯で色々意見が出てるみたいですが、面白いですね。
現在だけ見てると分りにくい状態が、一連の事象でできた結果の状態であると分ると、得心がいくところが多々あります。
おじさん氏が、当事者ならではの視点で端的にまとめてくれていますが、事情は複雑だったと思うので、他の方々の考察も、全部含めて要因となっているのでしょうね。
今、ここに身を置いて働くものとしては、外注するのは、プロに任せた方が、より業務に資するシステムが出来上がるからだ、と言われるような状況を目指したいですね。こつこつと良い結果を積み上げていけば、業界の地位もあがるはず。と思いたい。
プーマ
>たかたかハリコフ
社内に開発が出来る人間を維持しておくのに比べたら、外注するほうが安いって事だと思いますよ。
会社が負担する１人あたり諸件費は、大抵、給料の倍くらいでしょうから、ユーザー企業なら１人あたり、15百万から高めで20百万くらい行くでしょう。
SEの外注単価は１人/1日あたり、平均7万としましょうか（少し高めに設定したつもり）。稼働は仮に150日/年くらいだとすると、年間1050万。
ざっくりこんな比較ができますね。
受注側の実入りとしては、SEはフルタイムで働くでしょうから、稼働は200日/年くらいだとすると、1400万程度稼いでくる事になるんですかね。
うーん、つまり、SEの薄給で成り立ってるってことか。つらいな。
ponde
＞嶺井課長イニシアティブ説はほぼ確定かな。
妙に納得できるわ
らいてふ
ビジネスにおいて最も儲けが出やすいのは「小さいもの」でかつ「大量に売れる」もの。「大きいもの」で「少量しか売れない」ものでは、なかなか利益を出しにくい。また、構造的な変化への対応が困難になる等のリスクも抱え込みやすい。
だから例えば、自社向けのシステムで一定規模以上のものは今ではすべて外注。内製ではペイしないし、将来性もないから。ただし、会社の利益の源泉に直結する部分だけは「例外」といったところでしょうか。
「技術」とは「付加価値」にくるまないと売れないものだと思います。
技術が「コード」なら、付加価値とは言わば「ポエム」のようなもの。
何かフワフワしたイメージで包み込まないと、技術というのは売りにくいものです。
ポエムの価値に気付かずにコード一辺倒で押すだけでは、稼ぐのは厳しいでしょうね。
たかたかハリコフ
>プーマさん
あー、そういう計算式ならペイしますね。
残念ながら給料×2で15百万に遥かに届かないので外注の方が高く感じるのかもしれないです。
>らいてふさん
確かに規模の小さい案件だと高いですね。それで完結して次も無いので、値引き交渉も難しいですし。
内製に将来性がないというのも身を持って感じている所です。システムを構築するために必要な技術の難易度が高くなり、仮に必死に身に着けても10年もすれば使い物にならなくなるという現状では自社で技術を持ち続けるのは現実的ではないと思います。
ポエムの例えは面白いですね。何が出来るのかが重要であって、それをどのように実現しているか（コード）を気にする人はいないでしょうし。
メネメン
>1995年以降、インターネットの普及に伴って、Webが急速にコモディティ化した。安い理由はそれだと思います。
確かに、インターネットの普及によって、一部のベンダーしか持っていなかったような、
知識やノウハウの多くが、誰にでも手に入れやすくなったというのは、大きいですね。
逆に考えると、それまではボッタクってたとも言えるかもしれませんが。
>日本では、エンドユーザーがIT業界に金を入れる、それを金額ベースで見た場合、圧倒的に多いのは子会社への発注だったと記憶しています。
なるほど、そうなんですね。
私の経験した範囲での感覚とは少し違うので、
時間をみつけて、そういった統計も少し調べてみたいと思います。
子会社化の流れなんかを含めて、日本の情報システム産業の変遷について書いてるような記事を探していくつか読んでみたのですが、中でも以下の2つが興味深かったです。
"情報システム部門は自部門の地位を低下させる努力をしてきた"
http://www.kogures.com/hitoshi/opinion/bumon-it-hige/index.html
"ITを体系的に理解する：ITの歴史は「伝票・台帳・帳票の進化」"
http://japan.zdnet.com/cio/sp_gartnerconsulting2011/35021268/
メネメン
>プーマさん、
説明ありがとうございます。
文章作法の講師の方の言葉だったんですか。
プーマさんの会社の慣用句かなと想像してました。
「開く」という短い言葉に、大事な概念が凝縮されているのが、いいですね。
?
日本で内製が少ないのは歴史的背景だと思います
国策として国産コンピュータメーカを優遇した結果です
コンピュータを売って利益が出たとしても一時的でそれ以降はお金が発生しないので仕様を秘匿して開発をメーカだけが行える様にしてきたのだと
コンピュータメーカを守るために輸入規制を行ったため、メーカ以外にソフトウェア開発を行える企業が無かったのだと
自由化後日本企業が負けた結果としてハード保護だけ考えていたのでソフトウェア面では無策
すっぱいブドウだからソフトウェアなんて日本には必要ないんだと思いこんで大負けを食らったのだと
経済犯罪特捜部
>日本で内製が少ないのは歴史的背景だと思います
>国策として国産コンピュータメーカを優遇した結果です
>コンピュータを売って利益が出たとしても一時的でそれ以降はお金が発生しないので仕様を秘匿して開発をメーカだけが行える様にしてきたのだと
それはたぶん当たっていないです。
（１）日本のメインフレームはＩＢＭ互換機路線なので、独自拡張部分を除けば共通点が多い。
→日本のメインフレームメーカは安いＩＢＭ互換機をアメリカで売りまくったので、ＩＢＭが警戒してＩＢＭ－日立スパイ事件が起きました。これはＩＢＭの次世代機種への互換性を確保するために情報収集をしていた日立社員がＦＢＩのおとり捜査に引っかかったためです。
（２）さらに日本は、既存のメインフレームをスーパーコンピュータ化してアメリカに売り込んだ結果Cray社が経営難に陥り、日米経済構造協議でアメリカへの輸出を数年間ストップさせています。
（３）日本のメインフレームの売り上げは、保守契約から出ています。
ソフトウエアの開発費用は、メインフレームのレンタル契約額や保守契約額に含まれています。ソフトウエア製造部門はメインフレーム製造部門からかなり補助をもらっていました。ここ最近はどんどん削られていますが。
日本の企業が内製では無いのは、「おじさん」がすでに述べたように、日本の企業形態が「企業団」だったからでしょう。企業団なら、グループ各社で情報システム部門を持つよりも、子会社化してグループで共有している方が合理的です。
アメリカで内製がほとんどだというのは、
（１）アメリカの企業形態では巨大企業はコングロマリット形態だから、超巨大な本社が情報システム部門を丸抱えできる財政基盤がある。
（アメリカではある企業が州境を越えて他州で店舗を構えることを禁じる法律があったので、州ごとに子会社を作って、持ち株会社の役員が子会社の社長になるコングロマリット形態で法律の壁をくぐり抜けた）
（２）メインフレームは1強のＩＢＭしか選択肢が無く、ＩＢＭのメインフレームはを買えない中小企業は、ミニコンしか買うしか無かった。ソフトも自分で作るしか無かった。
＞ハード保護だけ考えていたのでソフトウェア面では無策
＞すっぱいブドウだからソフトウェアなんて日本には必要ないんだと思いこんで大負けを食らったのだと
日本政府はコンピュータ産業自体を保護する考えは無いと思います。
メインフレームの開発も当時の通産大臣だった田中角栄ぐらいしか理解が無くて、競輪業界の利益をＩＴ業界に回したのは有名な話です。
日米構造協議、半導体協議でもあっさり譲ってますし。
ソフトウエア製作技法については一時期は日本のほうがシステム化されていたと思いますよ。プロセスを定義して、品質を確保するとか。共通化、ルール化など。武田氏はこのときの教育を受けたのでしょう。
その後、アメリカは日本の製造業などを視察して日本の品質確保の技法を取り入れて、ＣＭＭＩや６σを作ったのですから。
日本の技法はボトムアップですが、アメリカではトップダウンになるように修正されています。
経済犯罪特捜部
訂正
コングロマリットでは無く、コンツェルンです。
コンツェルン化の契機となったのは反トラスト法です。
屑二号
＞日本の企業が内製では無いのは、「おじさん」がすでに述べたように、日本の企業形態が「企業団」だったからでしょう。
＞企業団なら、グループ各社で情報システム部門を持つよりも、子会社化してグループで共有している方が合理的です。
そちらが主目的だとすると、子会社化されたシステム部門の福利厚生、設備投資、給与テーブル等々は親会社と同等であってもおかしくないんですよね。
彼(おじさん)の話で面白かったことのうちの一つは、その辺りのことには一切触れていないというところです。
エンドユーザーである親会社の感覚って、所謂「内製」の頃と大して変わってないんじゃないかと思いますよ。
システム部門の子会社化は、親会社にとっては「内製にかかるコストの削減」の結果でしかないし、投資額こそ下げたものの、彼等は未だ「内製」を手放していない。
一方で、子会社化以下が外注に走るのは、自分達だけで作る予算が取れなくなったから。
こっちは単純に「安いから外注に走った」で済ましちゃって良い気がします。
経済犯罪特捜部
＞そちらが主目的だとすると、子会社化されたシステム部門の福利厚生、設備投資、給与テーブル等々は親会社と同等であってもおかしくないんですよね。
遅レスで申し訳ないが、別会社にすると言うことは、福利厚生や給与が親会社とは別になるということなので、同等には決してならない。
なんといっても組合が別になるから。
日本の企業は、会社ごとに組合を組織するので、アメリカのように企業を横断して同じ業種の労働者が企業と待遇面で同一業種同一賃金のような条件闘争は出来ない仕組みになっている。
＞一方で、子会社化以下が外注に走るのは、自分達だけで作る予算が取れなくなったから。
＞こっちは単純に「安いから外注に走った」で済ましちゃって良い気がします。
それは景気の下降局面での話。
屑二号
＞遅レスで申し訳ないが、別会社にすると言うことは、福利厚生や給与が親会社とは別になるということなので、同等には決してならない。
だから、少なくとも「大企業によるシステム部門の子会社化」はそっちを主目的として行われて来てるよね、という話です。
その他出てくる子会社化の「意義」なんてのは、ほとんど後付け。
経済犯罪特捜部
＞だから、少なくとも「大企業によるシステム部門の子会社化」はそっちを主目的として行われて来てるよね、という話です。
それは違うよ。
ということを何人も説明しているじゃないですか。
福利厚生や給与が親会社とは別と言うことは、親会社よりも下がることを意味していないことは分かりますよね。
バブル期には親会社よりも待遇のいいIT企業があったんですよ。
IT技術者が高学歴、高収入の花形産業であった時代があったんです。
屑二号
＞それは違うよ。
＞ということを何人も説明しているじゃないですか。
何人も？
全然わかんないんですが、例えばどなたですか？
＞福利厚生や給与が親会社とは別と言うことは、親会社よりも下がることを意味していないことは分かりますよね。
ああ「上がるのが一般的だった」って話がしたいんですか？
そういうソース、私は持ち合わせてないので良かったら教えていただけませんかね？
＞バブル期には親会社よりも待遇のいいIT企業があったんですよ。
＞IT技術者が高学歴、高収入の花形産業であった時代があったんです。
社内システム部門由来の子会社にそんなとこあるわけないでしょう。
経済犯罪特捜部
屑二号さんは入社年度は何年かな？
屑二号
＞屑二号さんは入社年度は何年かな？
答えられないならそう言ってくれても別に構わないんですけども。