罪と罰（22） 決戦は金曜日
11月最後の金曜日は、からりと晴れ上がった晴天だった。朝のNHKニュースで気象予報士の女性が、乾燥注意報が発令されていて、今日の平均湿度は50％、日中は25％近くにまで下がると断言した。乾燥肌に悩む私は、普段より念入りに化粧水と保湿クリームを叩き込んだ。
今日は午後から外出の予定が入っていた。＜ハーモニー＞のカスタマイズについて、美和学院大学の荒木准教授と打ち合わせだ。いつもなら朝のメイクは、簡単に眉ペンシルとリップグロスだけですませるのだが、今朝は少し時間をかけて、ファンデーションをはたいた。薄くルージュを引いた後、外出用のグレーのパンツスーツを身につけ、窓を細めに開けて気温を確認する。少し肌寒い程度だったので、薄手のコートを着ていくことにした。
――今日は決戦だなあ。
駅まで歩きながら、ふとそんなことを考えた。もちろん決戦に臨むのは私ではなく武田さんだ。きっと五十嵐さんは、武田さん制作総指揮の仕様書一式に容赦ない指摘を加えるだろう。武田さんもある程度は予想し、応戦の準備はしているだろうが、Webアプリケーションの実装スキルでは太刀打ちしようがない。
問題はその後だ。納期まで日数がなさすぎるから、いくらなんでも設計書の作り直しなどをやっている時間はない。となると、結局、あれだけ苦労して作成された設計書の山はどこかにしまいこみ、第2開発課のメンバーを全投入して、一気に実装を進めていくしかないのではないだろうか。20画面程度であれば、3バカトリオとマサルを投入して、1人あたり5画面。武田さんと久保さんには、主にテストを担当してもらうか......。
そんなことを考えながら出社すると、先に来ていた五十嵐さんが挨拶もそこそこに声をかけてきた。
「今日の午前中にあれ......」と五十嵐さんは机の上の置かれている仕様書一式を肩越しに指した。「...... のレビューをやるんだが、箕輪さんも参加してくれ。美和学院に行くのは午後だったよな」
その向こうで、武田さんと久保さんが緊張した顔でこちらを見ていた。どうやら五十嵐さんが私を巻き込むことを先に伝えたらしい。
「レビューですか。でも、私は要件とかよく分からないんですが、それでもいいんですか？」
「構わんよ」五十嵐さんは面白そうな顔でうなずいた。「君は実装する立場で意見を言ってもらえばいいから」
「分かりました。何時ですか？」
「10時だ。3階のプレミアを予約してある」
プレミアとは正しくは第1会議室のことで、主に役員会議か、来客用に使われる部屋だ。他の会議室のようにパイプ椅子ではなく、肘掛け付きの来客用チェアが置かれているし、役員用の給湯室が廊下の向かい側にあり、ちょっといいお茶を供することもできる。一般社員の使用が制限されているわけではないが、あまり予約する人はいない。私も入ったのは数回ぐらいだ。
「あそこですか」
「そうだ」悪戯っぽい笑みが五十嵐さんの目に浮かんだ。「たまにはいいだろう。じゃあ5分前に集合してくれ。ドキュメントなんかは用意するから手ぶらで構わんよ」
自席に座ってPCを起動したとき、今度は3バカトリオが寄ってきた。
「レビューやるんですよね」守屋が訊いた。
「そうみたいね。あんたたちも呼ばれてるの？」
「いえ」木下が残念そうに言った。「いろいろ言いたいこともあったんですけど」
「だから箕輪先輩にぼくたちの想いを託しておこうかと」足立が続けた。
「あたしはあくまでの公正に技術的な点から意見を言うだけよ」私は冷たく答えた。「間違ってたらそう言うけど、批判のための批判はするつもりないから。さっさと仕事しなさい」
3人が散っていくと、カスミさんがクスクス笑った。
「がんばってね、お母さん」
「正直、あんまり巻き込まれたくないんですけどね」そう言いながら、私は少し首を傾げた。「五十嵐さんの意図がよくわからないです。なんであたしがいるんでしょうね」
「そうねえ。味方を増やすためとか」
「五十嵐さんに？ あの人は味方なんか必要ないでしょう」
単純に技術力という点だけなら、武田さんと久保さんのクローンが100組いたとしても、五十嵐さんは片手であしらってしまうだろう。私と違って、職場の先輩だから、という遠慮などないから、なおさら容赦ない。
「じゃあ仕様書作ったのはあの3人だから、その上長としてってことじゃないの？」
「そんなところでしょうかね」
朝は時間が経過するスピードが速い。メールに返信したり、午後の打ち合わせに持って行くドキュメントをチェックしたりしていると、あっという間に9時50分になっていた。
「箕輪さん」武田さんがやってきた。「先に行ってるから」
「あ、はい」私は慌てて修正中のWordファイルを保存した。「すぐに行きます」
見ると五十嵐さんも久保さんも、すでに席にいなかった。私は4色ボールペンをつかむと、オフィスから出るところの武田さんの後を追いかけた。
1フロア上の第1会議室に着くと、久保さんがプロジェクタの準備をしていた。
「紙でやるんじゃないですか」
そう訊くと、久保さんは肩をすくめた。
「さあねえ。副部長が準備しとけというからさ」
その五十嵐さんは窓際に立ち、スマートフォンに向かって会話をしていた。私たちが入ってきたことに気付くと、二言三言話した後、通話を終えた。
「おつかれさま。座って待っていてくれ」そう言うと、急ぎ足で会議室を出ていってしまった。
私たちは言われた通り適当な場所に座り、五十嵐さんの戻りを待った。
「おつかれじゃないですか」場をつなごうと、私は武田さんに声をかけた。「昨日も遅かったんでしょう？」
「まあな」武田さんの顔には疲労の色が濃かったが、アドレナリンのせいか活力に満ちあふれているようだ。「でも、久しぶりにちゃんと仕事やったって感じだからな」
「結局、画面数はいくつになったんですか？」
「18個だ。まあ、半分ぐらいはコピペで作れると思うけどな」
「18ですか」ということは、実質的には12画面ぐらいになるわけか。「来週から実装に入れますかね」
「それは今からのレビューで決まるんじゃないかな」武田さんは五十嵐さんが出て行ったドアを睨んだ。「あの人がなんくせつけなきゃ......」
ドアが開いたので武田さんは口をつぐんだ。
「お待たせ」五十嵐さんは私たちにそう言うと、首をひねって後ろを見た。「どうぞ」
五十嵐さんに続いて、3人の男性が入室してきた。先頭の男性の顔を見た途端、武田さんの顔が色を失った。
「池田さん......」
「ああ、どうも武田さん」池田と呼ばれた男性は軽く頭を下げた。「今日はよろしくお願いします」
私の隣で久保さんも唖然となっている。とにかくうちの会社の人間ではない。私は慌てて立ち上がった。
「こちらは第2開発課の箕輪です」五十嵐さんが私を紹介した。「こちらは、KSR電機のシステム管理部の方々だ」
状況を把握できたわけではなかったが、社会人としての習慣で身体が動いた。内ポケットから名刺入れを出した。午後に外出の予定があってよかった。
「Webシステム開発部第2開発課の箕輪です」
「KSR電機システム管理部システムマネジメントチームの池田です」
「同じく北条です」
「システム管理部運用チームの八十田です」
名刺交換が終わると、私たちは向かい合う形で座った。私は小声で久保さんに訊いた。
「KSRさんが来ることになってたんですか？」
「いや......」久保さんは、まだ混乱しているようだった。「......そんな話は......」
「本日はお忙しい中、足をお運びいただきありがとうございました。早速、詳細仕様書のレビューを始めさせていただきます」五十嵐さんはそう宣言すると、床に置いてあった紙袋から、きちんとダブルクリップでまとめた仕様書の束を取り出した。「回していただけますか」
仕様書一式が配布される間に、五十嵐さんはデモ用のノートPCを取り出して武田さんの前に置いた。いくつかキーを叩くと、Wi-Fi経由でExcelの画面がスクリーンに映し出された。仕様書一式の目次ページだ。
「じゃあ、武田くん、始めて」
武田さんはすごい目で五十嵐さんを睨んでいたが、お客さまの前であることを思い出したらしく、かろうじて愛想のいい表情を作り出すことに成功した。
「では始めます。スクリーンをご覧下さい」
最初の15分ほど、武田さんの説明は順調に進んだ。それは説明の内容が、ネットワークやデータベース、バックアップといったシステム設計に属する事柄ばかりだったからだろう。KSR電機の3名は、武田さんの説明を聞きながらしきりにうなずいていたが、それは単にすでに知っていることを確認していたからかもしれない。
私は武田さんの説明を聞き流しながら、いただいた名刺に目を走らせた。池田さん、北条さん、八十田さんの肩書きは、それぞれ、課長、係長、係長となっていた。あいにくKSR電機の職位と、職務の実情についての知識はないから、係長レベルの人がどこまで業務に携わっているのかは分からない。だが、全員の名刺には、JavaとOracleの認定資格のロゴマークが刷り込まれている。八十田さんの名刺にはLPIC2の認定ロゴも並んでいた。単に資格を取るための勉強をしただけ、という可能性もあるが、しっかりプログラミング言語とデータベースの知識を身につけているプレイングマネージャだとすると、武田さんにとって、この説明会は少々つらいものになるかもしれない。
雰囲気が変わってきたのは、各機能の詳細説明に入ってからだった。武田さんの口調は変わらなかったが、KSR電機の3人の表情は次第に戸惑いの色を濃くしていった。
「ああ、ちょっとすみません」池田さんが声を上げた。「この過去データのインポート処理なんですけどね。この仕様によると、パーツ識別キーはインポートするCSVファイルの順番に生成されるようですが」
武田さんが説明していたのは、画面のないバッチ処理だった。過去の取引データなどをCSV形式ファイルからインポートする処理のようだ。
「ええ、そのとおりです」武田さんは笑ってうなずいた。「ヒアリングしたとき識別キーはユニークになるとうかがったので」
「まあそうなんですがね。ただ、これが主キーになっちゃうのはどうかなと思うんですが」
「え、なぜですか？」
「過去データのレコード数は6000万レコードぐらいになるんですけどね」池田さんは困ったような顔で言った。「川崎と港北の2工場にそれぞれサーバがあって、データとしては分離してるんです。でも、識別キーは全社共通にしとかないといかんのです」
武田さんの顔から笑顔が消えた。
「えーと、どういうことでしょうか」
「つまりですね。このインポート処理は2工場でそれぞれ実行することになるんですよ。それぞれで1から連番を取っていくと、重複することになるでしょう」
「あ、そうなんですか」
「運用環境については以前にお話ししましたが」八十田さんが顔を上げた。「各工場サーバで完結する処理ってのは少ないので、2フェイズコミットが基本になります。本社サーバがマスタで」
武田さんは言葉に詰まった。2フェイズコミットという言葉を理解していないのは明らかだったが、何とかそれを隠してうなずいた。
「ああ、なるほど。ええ、分かっていますよ。そうでしたね」武田さんは愛想笑いに近い表情を浮かべた。「どうも仕様書を書いた部下が理解していなかったようです。修正しておきます」
この場に3バカトリオが参加していないことに、私は心から感謝した。
「では次の機能に行きます」と武田さんは何事もなかったかのように続けた。「在庫参照画面ですね。ご覧の通り、画面の上部が検索条件、下部が検索結果になっています。検索条件の各項目の桁数などは全て仕様書に記述してあります」
自慢げな口調だったが、3人のお客様たちはあまり感銘を受けた様子ではなかった。武田さんは少し当て外れという顔になったが、そのまま説明を続行した。
「あ、すみません」画面機能の説明が進んだとき、北条さんが手を挙げた。「この受付所属と担当者を選ぶコンボボックスですけどね。所属を選んだら、担当者コンボの中身が入れ替わるんですよね？ この仕様書によると、changeイベントでリクエストが発生するとなっていますが、できればAjax使って切り替えしてもらえませんか。可能ですよね？」
武田さんの顔に狼狽が浮かんだ。
「ああ、えーと、その......」
「その点については」五十嵐さんが落ち着き払った声で口を挟んだ。「実装の責任者である箕輪から説明させましょう。箕輪くん？」
いきなり話を振らないでほしい。私はざっと仕様書に目を走らせてから答えた。
「はい、可能です」
「ライブラリは何を使うんですか？」と池田さんが訊いた。
「jQueryですね」
「バージョンは？」池田さんは続けて質問してきた。「1系ですか？ 2系ですか？」
「うちで使ってるのは2.1系ですね。逆に何かご希望のバージョンがありますか？」
「いえ、2.1なら大丈夫です。結果はどんな形式で返します？」
「JSONで考えていますが」
「分かりました。ありがとうございます」
池田さんは満足そうにうなずいた。
「じゃ続けますよ」武田さんは主導権を取り戻そうとしてか、必要以上に大きな声を出した。「えーと、どの画面でも共通なんですが、実行ボタンを押すとエラーチェックが走るようになっていて......」
「そのエラーチェックですけどね」池田さんがスクリーンを見ながら遮った。「この仕様だと全部ロジックでやるようになってるみたいですが、基本的なバリデーションチェックぐらいはフレームワークでできませんかね」
全員の視線が武田さんの顔に向けられたが、武田さんは「えーと、その、それについてはですね」などと意味のない言葉で時間を稼ぎつつ、助けを求めるような視線を私に送ってきた。
「あ、えーとですね」私は慌てて仕様書をめくった。「この仕様書にはないんですが、必須チェックと桁数の大小、あと型チェックはデフォルトのバリデータでやる予定です。ただDB絡むような相関チェックは、ロジックになりますが」
そう言いながら私はプリントアウトをせわしくめくり、クライアントの使用前提条件が書かれたページを探しあてていた。IE9以上とある。
「本来なら数値入力は、type="number" でやりたいところなんですが、御社の使用しているのがIE9以上となっているようなので」
「ああ、それですね」八十田さんが頭をかいた。「現場で使ってるのが、どうしてもIEが多いもんでね」
「もう1ついいですか？」北条さんが訊いた。「ここで検索結果の受注番号セルの色をステータスで変えてもらうのは、オーダー通りなんですが、この色の変更はどっち側でやるんですか？」
その質問は武田さんに向けられていたが、武田さんはいぶかしげに訊き返すことしかできなかった。
「どっち側ってどういう意味でしょうか」
「つまりクライアント側でやるのかサーバ側でやるのか、ってことですよ」
「ああ、なるほど、そういう意味ですか。はい、えーと...... そこはですね......」武田さんの言葉は尻すぼみに小さくなっていった。
「箕輪くん、どうだ？」五十嵐さんが私を見た。
「サーバ側で、と考えています」
「というと、何らかのHelperクラスを作って？」
「そうですね。よくやるのは、対象のHTML部分を外部XMLファイルにでも定義しておいて、それをテンプレートとして置き換える感じですかね」
「なるほど」北条さんはうなずいた。「そのXMLファイルのメンテナンス画面とか作れますか？」
その質問が向けられている先は、もはや武田さんではなく、私だった。
「作れますが...... そこまで頻繁に変更することがありますか？」
「うーん。そう言われると」北条さんは苦笑した。「ないでしょうねえ」
「だったら、とりあえず必要な際にはエディタで変更してもらうことにしておいたらどうでしょう。もし今後、修正の頻度が多くなるようでしたら新たにメンテ画面を考慮するということで。そういうことでいいですよね？」
最後の言葉は武田さんに言ったのだが、武田さんは素っ気なく頷いただけだった。
「じゃあそういうことで」五十嵐さんがにこやかに言った。「もちろん、その際には新しく見積取らせていただきますよ」
KSR電機の人たちは笑い崩れた。五十嵐さんと私もその笑いに同調したが、武田さんと久保さんはにこりともしなかった。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
wildcat
暫く静かに経緯を見守っておりましたが、成程こういう展開ですか。
武田大先生の狼狽っぷりが目に浮かびますねえ。目先というか建前にとらわれて本質を考えない（目をそらした）所で実務（というか顧客）には関係ないですし通用しませんからね。個人的にはスッキリする展開ですね。
nanashi
技術的にまともなお客様を相手にするのはいいですね。
ここで成長を志さないようなら技術者・社会人・サラリーマンとして失格ですからね。
ただ、こんなバカをお客様の前に連れて行く度胸は持てませんね。
.
まさかの公開処刑。
acb@co.jp
うｍｍ......
今回の場合は本質うんぬん建前うんぬんというよりは、新しい技術・知識の不勉強、という単純な話のように見えます
orchis
大先生の公開処刑ｗｗｗｗ
>> acb@co.jp
新しい技術・知識の不勉強じゃなくて、エンジニアとしてのあり方を問われているんじゃないかな。
yamada
なるほど・・・
お客さんを連れてきちゃうのが一番早いわな・・・確かに。
anserer
わ、わざわざ不意打ちにする必要はあったのかしら。
いったいいつ武田久保コンビがブチ切れて傷害事件を起こすかひやひやする……。
DR
毎週月曜日を楽しみにさせていただいております。
何だか武田副課長が、前回の城ノ内君とダブりますねぇ。
箕輪さんに主導権を握らせて、仕事もそのまま第2課に移す魂胆でしょうかね？
以前、箕輪さんから引き継いだ案件の回(15回)の最後の一文「最終のチャンスだった。」から、武田副課長を救う可能性は無いかなと思っちゃってます。
sudo
KSR電機さんの案件ではないですが、以前シノハラさんの案件で武田さんが「ユーザは所詮素人」といった驕り高ぶった発言をしていましたね。
箕輪さんがそれに関して注意をしたのですが、武田さんは今回のことで思い知ったでしょう。。。
もっとも誰しも武田さんのようになる可能性はあるわけで、自分がそうなる可能性を考えると怖くなりました。
n
公開レイプかー、この展開は読めなかった。
でも、恥じているだけまだましですよね。
ずれているけど、技術者の誇りみたいなものはあるってことでしょ。
そのずれが問題なんだけどね！
.
これみて自分の使ってるjQueryが古いかと思って確認しちゃったけど、現状2.0.3が最新だった。未来の話？
unkei
毎週楽しみに読ませて頂いてます。
これまでのシリーズも一気に読みました。
一言、「おもしろい」です。
ただ、数年開発の現場から離れていたのですが、技術的なやりとりのところは、
自分もダメな側の人間になっていて、インターネットでちょっと調べても
理解できず、ちょっと鬱な気分です・・・。
muu
しかし、この後具体的にどうなるんだろう
「今回のはレアケースだ！基本的には俺のやり方が正しい」
と開き直られたら、また振り出しに戻るな気がする
none
今週の失言：
「まあ、半分ぐらいはコピペで作れると思うけどな」
lav
うわ、本当にノーチェックでお客様の前に出しやがったw
しかも、これは予想外w
処刑だな、これ。
要求と設計に齟齬がある時点でダメダメ
五十嵐さん、怖いわ。
lav
んー、でも、箕輪さん、ちょっと鈍いなw
プレミアルーム使うってことは来客ありかもってことなんだから、
まさかね、KSRさんがきたりして
とか勘付かなかったのね
フェニックス
副部長が武田に内緒でＫＳＲ電気と連絡取っていたことが気になる。実はＫＳＲ電気の三人はイニシアティブのメンバー？
DumbObj
久々のプチ修羅場で面白かった。
それにしても、システムが想像よりずっと複雑で驚き。生産中止製品のみが対象なのに各工場のサーバでぞれぞれ処理させて、データも分散配置で2フェーズコミットが基本って.....
武田くん、要件定義ちゃんとやったの？
aa
やられた～。
こうなると、武田さんの要件定義の実力も怪しい。
実装は、設計書なしで進めるしかないか～。やれやれ。
ふっちーLove
この連中、いくらなんでもお客を無視すぎる。
開発者の独善に苦しめられた経験があるだけに見ていられない。
五十嵐も武田も利用者視点で見れば五十歩百歩。
たとえ話で言うとすれば、
世間が求めているのは安定した食肉の供給。
ところがIT業界ときたら、旧石器時代のハンターレベル。
槍・弓派のアクション派とトラップタイプの持久派で争っている。
畜産加工業までは行かなくても
せめて遊牧民レベルには達して欲しいのですが。
KSR電機のお歴々も会社が自分たちに何を期待しているか考えてほしい。
独善SIerに狩猟技術で評価されるは大事なことですか？
とある初心者
新しい技術を習得云々関係なくただの無能って位置付けになってしまっている武田さん。
というかお客さんも画面でAjaxでの動作を求めるなら先に言わないのかな。
それとも今の世だとAjaxを使うのがデフォ、の勢いなのかしら。
うちの会社だとBtoCサイトなプロジェクトでしかAjaxな使ってないから解らないや。
アラファイブ
2フェーズロックを知らないとかAJAXを知らないとか以前に、（想像ですが、この武田さんの様な）プログラムとかの詳細を知らず、たたき上げでリーダーになった人は、自身の体得したベストプラクティスとして、同じ組織の上の人間を困らせる様に動くんですよね。
もう当人にもそうしているのが何故か解らないくらい染みついてしまっている振る舞いなのでしょうけど、それが当人が最先任になってしまうと途端に破綻してしまう、自己免疫の病気みたいに、自分を困らせる様に動いてしまう、というのも判を押したように共通なんですよね。
言語化せず体得した、成功を重ねてきたやり口なので、絶対当人は手放さないでしょうし、現行のリーダー養成法の1つの決着だと思います。
匿名
これはひどい。
自分の場合、技術はあってもレビューは上手く行かず苦労することが多いから、
技術すらないない武田さんの苦労は胃に穴が開くレベル。
ふっちーLove
つらつら思うにコンピューターは人よりもずっと優れた計算能力を持つ。
そこに惑わされてシステムを創る（大笑い）SE／PGは何か優れた能力を持っていると勘違いしているのではないでしょうか。
自分たちは才能に恵まれてクリエイティブな仕事をしておると。
IT業界はいまだテイラーの手法の適用すらおぼつかない民芸レベル、
工業とは程遠くこのコラムのフィクションでは
江戸時代の職人レベルのプロ意識を持ってるかも怪しい。
何しろ自分が作る作品そっちのけでお家の諍いに熱中しているわけですから。
日本のSE/PGは工場で油まみれで仕事をしている人よりも
ましな仕事をしているのでしょうか？
うっちー
ふっちーLoveの癖にまともっぽい問題提起が
匿名
Ajax云々の下りは技術的にまとも～というより知りすぎているような
（Ajaxの挙動云々じゃなくてマイナーバージョン含めて挙動を把握しているところとかHelperクラス云々だとか）
ここまで知ってる＆そこまで大規模ではないシステムでパッケージ利用でもないのに設計段階から外注する理由はなんなんだろうか？
一切の内製化をしないというなら逆になんでここまで知ってるかが不思議だ。
DumbObj
食肉にたとえるとか斬新！
釣られてみるけど、自分たちの業務に合うシステムを作ってくれってのは、自分たちの舌に合う肉料理をオーダーメイドで作ってくれっていうのに近いんでは？ 畜産加工業者らが作ってる"手捏ね"ハンバーグでいいなら、わざわざプロの料理人にオーダーメイドで作らせる必要はですよね。材料を買って自分で料理してもいいでしょうし。
レシピレビュー
「ああ、ちょっとすみません、このタマネギのソースなんですけどね、このレシピによるとバターで炒めてから、りんごとはちみつを入れてますが....」
「ええ、そのとおりです。ヒアリングしたときバーモントカレーがお好きだとうかがったので」
「まあそうなんですがね。ただ、これがメインのソースになっちゃうのはどうかなと思うんですが」
「え、なぜですか？」
DumbObj
未だにテイラー主義的な考えに根ざした100年前の経営手法を理想としていることが、使えないシステムやデスマーチを量産している主因だと思うんですけどね。
bottom
2層コミット知らないとか、武田さんはFE(二種)も持ってないのか
ほ
ソフト開発が「製造」ではなく「設計」だということが分からない人がまだいるのか
フッチーLove
成り行きで平日なのに酒飲んでいるから書き込むべきではないとは思うが
（以前も同じミスをやってしまったが）、あえて書きます。
ソフト開発が製造だろうが設計だろうが利用者には関係ない。
かりにソフトの開発が設計だとしても
じゃあ建築や家電製品の設計に問題があったケースがどの程度あるか。
姉歯の耐震偽造マンションのような類が極端な事例であることを指摘するまでもなく、
リコール制度やPL法を引き合いに出せば、
IT業界がいかに製造業として異常であるか理解してもらえると信じる。
普通の製造業であればリコール制度が運用できますが、
IT業界ではリコールなんて認めたら事業が成り立たない。
SE／PG各位はもしかしたら理解していないかもしれませんが、
設計に問題があろうが、製造に問題があろうが、利用者に被害を与えるとね、
製造者は責任を問われるのだよ。
少なくとも20世紀後半以降の製造業では。
SE／PG各位が知らなくても恥ではないです。
IT業界はいまどき珍しい例外ですから。
ITでは世界的な大企業であるマイクロソフトが製造した重要なプロダクトに
脆弱性という名の不備（この不備が設計で混入したか、製造で混入したか当然、利用者には無関係）があってもOK。
パッチを提供してそれで終わり。
分かる？
自動車でいうなら（自動車なんてテイラーっぽい業界と比較されて気分を害したSE／PGには謝罪します）
リコールすべき問題があればパーツは無償で提供するから、
あとは利用者の負担でやれって話よ。
実はこれは世間では異常なんです。
まあSE／PGとしてはそれが何？って感じでしょうが、
そこに違和感を感じる業界の人もいるということは頭の隅に置いておいたほうがいいでしょう。
設計だから何？
＞これみて自分の使ってるjQueryが古いかと思って確認しちゃったけど、現状2.0.3が最新だった。未来の話？
この物語はフィクションです。
jQuery のバージョンは、2013年11月25日現在、2.0.3が最新です。
フッチーLove
テイラー式や自動車のような工業的な手法を無理に適用するからおかしくなる。
ではなくて、IT業界は工業的な手法を適用できるレベルまでに成長しなくてはいけないと思います。
ルネッサンス期のイタリアの工房ですら、
分業制（家内制手工業的な手法）でアートというもっとも属人的なプロダクトを生産した。
現代のいま、求められているアートはまさしく工業です。芸術ではない。
いま求められているのは新聞チラシのデザインです。
美術館に飾るようなアートなソフトを作りたい人は受託システム開発の仕事はするべきではない。
旧石器時代のハンターよろしく、
名人芸なスキルが求められるのはその通りでしょうが、
いまどきのSE／PGはその状態ではニーズにこたえられていないと
恥じてほしいと思います。
最後に捕捉しますと、ふっちーは最高のユーザー企業マネージャーです。
彼の価値がわからないSE／PGはど素人！
通りすがり
＞フッチーLoveさん
以前、酷い目にあったからって問題をすり替えてるだけじゃねぇか。
お前には関係ないかもしれないが、IT業界の連中だって出来が良くなるために苦労してるんだよ。
そのために必死こいてバグがすくなくなる為の方法、顧客の我が儘、不勉強からくる土壇場での仕様変更にも対応しやすい方法、テメェを騙したような似非が入り込む余地が少なくなるような方法を導入する為に苦労してんじゃねぇか。
テメェの不勉強からインチキコンサルみたいな奴に騙されたのかしれんが、IT業界全体やIT業界の効率化（＝バグの低減や設計の高品質化につながる）に思いを馳せている連中にまで、糞味噌一緒にして、と言うよりもむしろ味噌側の連中にやつあたりしてんじゃねぇよ。
ふっちーLove
私をだました人はいません。
すべてのSE/PGが誠実に一生けん命やったと断言してもいい。
だから救われない。分かる？
時代が悪かった。
味噌もくそも大差ない時代なんだよ。今は。
現代人が古代の世界を振り返って誰はくそだの味噌だの評価しても無意味。
他の製造業とIT業界は古代と現代なみの差がある。
よってIT業界は世間の評価を受け付けない。
だから誰もSE/PGを非難していない。
非難の対象になれる存在すらない。
理解できましたか？
通りすがり
これがお客様は神様精神を持ったお客様か･･･。
零知零能により、無敵感が漂ってますなぁ、馬鹿は論破できない。
しかも、過去に学んで自重することもできないとは、救いようがないですな。
客は客で見る目が無さ過ぎるんだよねぇ。
だから、そういう低質なPG/SEを選ぶし蔓延する。
安いからといってそっちばかりを選択する。
そりゃ安かろう悪かろうが蔓延するし、業界はいつまでたっても洗練されませんわ。
ふっちーLove
通りすがりのくせにいいこと言った。
その通り。
客はSE/PGの資質を見る目を持たないといけない。
残念だが会社というブランドではあてにならない。
所詮は人。
だからよ。
ユーザー企業の人間にIT知識が求められるわけ。
総務部の人間が社屋と建てるのに建築士の技量を自力で評価しなくても
大手のゼネコンに出せはまず大丈夫と安心できるのにさ、
情シスは大手のSIerに出しても
それこそふっちーなみに技術に精通していないとヤバいわけよ。
SE/PGは変わろうとしない武田のような人ばかり。
ユーザー企業はSE/PGがど素人という現実を直視しない。
ほんとにIT業界はいつまでたっても洗練されませんなぁ。
通りすがり
凄い斜め上に解釈されて、凄い極論に達してて絶句するｗ
まぁ、おたくは素人のようなSE/PGとしか仕事した事ないんだろうね。
もうちょっとお金だして、ちゃんとしたプロを使うといいよ。
やっぱあんた、今日は黙ってた方がいいぞ、自らの過去に学べ。
ふっちーLove
さすが通りすがりさん
いま、IT業界の人間から得られる最上のアドバイスをいただきました。
仰せのとおり、今日は寝るとします。
非常に有意義な会話ができまして幸甚に存じます。
有難うございました。
ミーミー
ではIT業界の人間からもう一つ
チラシの裏へどうぞ
わるを
次に出てくる時は、たとえ話はやめてほしいな。
他業種のはなしをしたって、枝葉ばかりに議論が逸れて何にもならん。
ほ
ふっちーLoveさんのIT業界に対する「だめだこいつら、早くなんとかしないと」って気持ちはみんな共有してると思うんですよ。
でも、現実を無視した解を出したとところで机上の空論なんじゃない？
この業界ができて半世紀、いろんな先人が四苦八苦してもまだ工業の域に達することができない事実を踏まえれば、その現実を踏まえてやってくしかないと私は思う。
おそらくあと半世紀経っても人間にはその解を得られないと思う。
半世紀後には人間の知性を超える計算機が誕生するだろうから、今のようなIT業界は淘汰されるからそれでいいと私は思う。
あ
珍しく、ふっちーLoveが正論吐いてるな。
DumbObj
製造か設計かは利用者には関係ないだろうけど、オーダーメイドのシステムを発注する人間は単なる利用者ではないんだよね。パッケージ製品やSaaSなどの利用者とは異なる性質の責務があって、それは要求仕様を伝え、理解させ、最終的にその要求が実現されたかどうかを確認すること。これがきちんとできるユーザー企業はそう大きな失敗はしない。
要求仕様を伝えるのに実装知識が必ずしも必要なわけではないが、自分が作って欲しい物がどういうものなのか伝えられるだけの知識やスキルは必要。それができない場合は出来る人を代わりに雇う必要がある。自分でメンテナンスする場合は実装知識も当然必要。
今回の話でいえば、KSR電機側の人間は、要求仕様をきちんと伝えられていないし、伝わったかどうかの確認もできていない。武田さんに問題があるのと同様、KSR電機側にも問題があることになる。
発注者側の責務のうち、3点目の要求が実現されたかどうかの確認、特に内部品質に関わる部分の確認方法が確立されていないのがソフトウェアの難しいところ。でも、第三者機関に検査をさせるとか、Code Climateのような指標を使うとか、方法は多々ある。
DumbObj
ふっちーLoveさんの言う"自動車のような工業的な手法"が何を指しているかはよくわからないですが、他業界から学んでIT業界が改善していくべき点は多々あると思います。ただ、それが工業化という言葉でイメージするものだとは思わないですけど。ソフトウェア産業の工業化を叫んだソフトウェアファクトリーという考え方が見向きもされなくなった理由はそれなりにあるのでは。
あと、利用者に被害を与えるとソフトウェアでも責任を問われますよ。業務システムの場合は、金銭的な被害を与えることはあっても、人的な被害を与えることはないでしょうけど。
釣られてたとえ話を続けるべきじゃないのかもしれないけど、自動車のリコールは、安全上の欠陥がある状態で製品を販売しているわけで、人命に直接関わるかどうかの違いはあっても、ソフトウェアが脆弱性という安全上の欠陥がある状態で販売されているのと同じでは？ それにパッチはパーツを提供しているだけじゃなくて、そのパーツを交換するプログラムとともに提供されいて、配布のための仕組みも維持管理されてます。リコールでいえばパーツと共に修理要員を対象となる車のある場所まで派遣して作業する仕組みを維持管理しているのと同じ。某ベンダーだと、このシステムのために少なくても年数百億はお金をかけてるんじゃないですかね。もちろん、その費用はリコールと同じで製品価格に予め上乗せされてますけどね。
IT業界に未熟な面があるのは否定しないし、大手SIerもいろいろと問題があるでしょうけど、失敗の原因を他責的に考えているうちは問題は本質的に改善されないと思います。自分たちがコントロールできるところで勝負しないと。
(長いコメントですみません）
あ
ソフトウェアファクトリーの考え方が見向きもされなくなったというのは、
DumbObjさんの周辺だけじゃないですかね？
私の周りじゃソフトウェアファクトリーの考え方だらけですよ。
ふっちーLove
工業化されたソフトウェア開発、製造業としてのシステム開発なんて私は見たことがない。
工業的な手法というのは「計測可能で管理可能な再現性のある手法」程度の表現しかできず、
見たことがないものを語る言葉もないので、たとえ話に頼ってしまうのはしかたない。
ただ、そのような方法が存在しているのは確信している。
ユーザー企業が自社ビルを建てるとき、望む仕様のビルを建てている。
おなじユーザー企業がシステムを開発すると成功率3割。
自動車製造のような製造業に従事すると数万点の部品からなる高度な製品を迅速・大量に生産する。
同じ母集団で育った人間がシステム開発をやるとバグばかり。
何かが足りていない。
何かがないと理屈が合わない。
またまた例えると元素の周期表に穴があるなら、惑星の軌道がゆがむなら、
そこに何かがあるはずです。。
そしてもう一つ。
その何かはIT業界の中にあるのではない。
IT業界の外の何かをシステム開発に適用したらうまくいったというような形で実現する。
だってさ、そうでしょ。我々は旧石器時代に生きているのよ。
野生動物が群れをなして季節ごとに移動し、それを狩って食べている。
「新鮮なお肉が毎日欲しい」って言われたら、
「はぁ？何いっているの。お肉がほしければ狩りをするのが当然でしょ。
で、狩りではいつも獲物があるとは限らない。知らないの？」
「お肉がほしいなら、狩りの技術をマスターしたら？」
「シカに毎日一頭ずつ食べられに来るように頼んでみるのもいいね！」
旧石器時代の優秀なハンターが畜産加工業なんて思いつくわけない。
ただ、ひたすら狩りの技術を磨く。
IT業界の中に答えはない。
これが2つ目の確信です。
J
ふっちーLoveさんは人を怒らせようとしてるようにも見えます。
前に炎上?した時のクレームつけてた人のマネしてるところとか。
それから他の人も書いてるようにわかりにくいたとえはやめたほうが
いいのではないでしょうか?
たとえを使うのもいいですが、誤解を招くことも多いですからね。
ここまで書かれるのですが、きっとふっちーLoveさんには何か答えが
あるのではと期待しています。それが前の作品の渕上さんだったら
ちょっとがっかりですけれども。。。
DumbObj
まじですか？ ソフトウェアファクトリーの考え方だらけとは驚きです。皮肉ではなくですよね？ 差し支えない範囲で、例えばどういう分野のシステムに、どんなビジネスモデルで適用しているのか教えていただくことできますか？ 興味あります。
ちなみにソフトウェアファクトリーの考え方の一番の特徴は、製造業における生産ラインのように、特定分野のシステムを量産するためnのプロダクトラインをまず開発し、そのプロダクトラインを使って個々の顧客向けのシステムを要求仕様に沿って生産する（設計・開発・テスト）という点にあると理解しています。
なるほど、ふっちーLoveさんの言う工業的な手法は自動車の生産工程をイメージされているんですね。ソフトウェアファクトリーの考え方のように、ソフトウェア開発における一部工程(特にプログラミング)を、製造業における生産工程になぞらえる考え方もあり、どうやらそれを追求されている方もいるようです。
ただ、それとは違って、製造業における生産工程は、ソフトウェア開発においてはビルド工程だと捉える考え方もあります。ビルド工程では数万行のコードからなる高度なシステムを、迅速に何度でも生産可能ですよね。それもほぼ無料で繰り返し何度でも。この考え方では、ソフトウェア開発の大半は、製造業の生産工程ではなく製品開発工程に近いものとして捉えます。「製造」ではなく「設計」というコメントはこの違いについて述べたものじゃないかと。どちらが正解というものでもないと思いますが、私の周りでは後者の考え方を支持する人が多いです。
真面目な話、ほんとにバグだらけで困ってるんであれば、要求仕様を決める段階で、各要求仕様を満たしたかどうかを判定するテスト内容も決め、それらのテストに常にパスする状態を維持しながら開発するようなベンダーを選べば、バグだらけってことはなくなるかと思いますよ。フッチー式にサードアイの東海林さんばりの人を引っ張ってきては。
肉より魚派。
個人投資家
＞ふっちーは最高のユーザー企業マネージャーです。
＞彼の価値がわからないSE／PGはど素人！
炎上しているプロジェクトを仕切り直して、スタッフを入れ替えて、追加予算を分捕ってきて、新機能を追加して無事リリースにまでこぎ着けた手腕はマネージャとしてとても優れていると思います。
一番ダメなのは主人公でしたね。
個人投資家
今回、内部レビューを通さないで、いきなり顧客レビューをするというのが会社の業務としておかしい。
>識別キーは全社共通にしとかないといかんのです」
ヒアリングの時になぜそういう重要な要件を顧客は要件として伝えていないのだろうか？
＞「各工場サーバで完結する処理ってのは少ないので、2フェイズコミットが基本になります。本社サーバがマスタで」
本社にマスタがあり、スレイブサーバが各工場にあるのなら、
運用形態は2フェーズという問題ではないような。
マスタサーバにあるのは全工場のデータで、スレイブサーバには各工場ではそれぞれの工場で使用するサブセットのデータがある運用形態？
各工場の差分データを本社に送って、マスタを夜間バッチで更新して、スレイブサーバにコピー？
旧システムである AS/400ではどんな運用をしていたの？
各工場にAS/400を置いてたわけ？
リアルタイムでマスタを更新する必要があるの？
製造が終わった旧部品の在庫処理システムだったはずなのに・・・・
＞KSRさんが生産中止にした何種類かの製品の管理だけで、その在庫がなくなったら、このシステムもお役ご免になる
はずだよね。
＞実は、すでにASから移行を完了している基幹システムの方で、在庫管理の登録や検索などの主業務は行っているんです。
だから、マスタに2フェーズコミットでリアルタイムに更新をかける必要はないんじゃないの？
各工場にあるサーバのデータを月末にバッチで反映する月次処理で十分じゃないの？
jQueryで機能をブラウザ側に分割する意味が分からない。
既存のシステムがサーバーサイドでチェックする仕組みなら、その仕様を変更するのはなぜ？
端末としてつかうパソコンはどの程度のものを想定しているんだろう？
旧システムでは、一日の始めに管理者がLOGONして、一日中LOGONしっ放し
で、作業者A,B,Cがそれぞれ端末操作して、就業時に管理者がLOGOFFして帰るとかそういう運用してないの？
タイムアウトでセッションが切れてしまうWEBシステムだと、運用方法を変えないといけない。
自動車部品の下請け工場だと3シフトで動いていて24時間LOGONしっぱなしとかあり得る。
会計監査用に在庫の入出庫指示をログとして保管する機能とか使ってないですか？
jQueryを使うかどうかより、そっちのほうが顧客にとってずっと重要だと思うがKSR電機のシステム開発部の人達はそう言うところには頭が回ってないの?
語り部
皆さんのやり取りを読むと、何故か過去の黒歴史を思い出します。
いまでも業界の体質そのものは全く変わってないんじゃないかなぁ。
役人の発想や一般大衆の認識とかもね。
http://www.miraikeikaku-shimbun.com/article/13198069.html
http://petapeta.tumblr.com/post/23016363806
闘うすべてのSE／PGたちに幸あれ。
普通のプログラマ
工業化が話題の中心になってるようですけど、自動車工業とシステム開発を比較するのは無理があるのでは？
自動車工業は商品の要件・使用と顧客ターゲットを製造側が決められますが、システム開発は要件・仕様は発注側と製造側の双方の合意が必要です。また、商品を買うお客を選べません。
自動車業界と比較するなら、レース車両の開発やオーダー車両の製造なんかと比較するほうが妥当な気がします。
余談ですが、前の作品での斑上マネは技術や姿勢は評価されるべきだと思いますが、タレントマネジメントが
下手過ぎです。どんなに能力があっても案件ごとに退職者や休職者が出てたら会社としてはたまったものじゃないです。
ペダル
↑デカイ釣り針だな。
ペダル
上のは個人投資家氏のコメントについてです。
sudo
個人投資家さん
人として好きになれるかどうかは置いておいて、ホライゾンシステムさんの自社製フレームワークが使われそうになるのを阻止したり、厳しい要求を飲ませたり(脅迫に近いですが)と有能な人なのは確かですね。
ただ、渕上さんのやり方は何か一つでもミスをしたら崩壊するので危ないと思いますが。
sudo
個人投資家さん
人として好きになれるかどうかは置いておいて、ホライゾンシステムさんの自社製フレームワークが使われそうになるのを阻止したり、厳しい要求を飲ませたり(脅迫に近いですが)と交渉面では非常に有能な人なのは確かですね。
しかし、あの恐怖政治のようなやり方はマズイと思います。部下や協力会社さんと良好な関係を築くのも仕事ですからね。
実際亀山さんにテロ行為をされてしまったわけですし。
(もちろんこのテロに関して亀山さんに一番問題があるのは分かっています。)
sudo
個人投資家さん
人として好きになれるかどうかは置いておいて、ホライゾンシステムさんの自社製フレームワークが使われそうになるのを阻止したり、厳しい要求を飲ませたり(脅迫に近いですが)と交渉面では非常に有能な人なのは確かですね。
しかし、あの恐怖政治のようなやり方はマズイと思います。部下や協力会社さんと良好な関係を築くのも仕事ですからね。
それに亀山さんのテロ行為を防げなかった渕上さんを最高のマネージャーというのは買い被りすぎかなぁと。(もちろんこのテロに関して亀山さんに一番問題があるのは分かっています。)
rezz
例え話は比喩による具体的な説明方法ってことが判ってない人多いよね。
nagi
適切ではない例え話を持ちだして、やれ石器時代だ
あれやこれや言って自己陶酔してる人って大体わかってない人だよね。
説明下手なんだろうね。
大体その場合は、説明することに慣れてないので
人と接する機会がないかコミュ障なんだよね。
また、フィクションの小説に対して流れも読めず
どうでもいい細かい考察してるのって可笑しいよね。
どこにも渕上PMの話なんて本文どこにも書かれていないのに
いきなり持ち出してきてどうこう言ってるのって笑っちゃうよね。
ついでに渕上はPMの実務としてはまともだったかもでも
コミュ障の頭でっかちで自己中の時点で詰んでるよね。
人と接する仕事で３つも欠点があるのはいくら仕事ができてもダメな人って感じ。
個人投資家
＞また、フィクションの小説に対して流れも読めず
＞どうでもいい細かい考察してるのって可笑しいよね。
コンピュータを題材にした映画があったとしましょう。
そこで画面に流れるソースコードがN88-BASICのソースコードだったら、リアリティ（本物らしさ）が感じられませんよね。
ましてそのプログラムがストーリーの根幹に関わるものだったら、 「あ、この映画の製作者、コンピュータのことが全然判ってない」ってげんなりするでしょう。
フィクションであっても、物語が成立するためには本物らしさが必要です。
わたしが挙げた指摘点は、どうでも良いことではなく、実際に自動車業界の部品の下請け会社で、複数の工場にある小型メインフレームをオープン化するプロジェクトに携わったときにお客様からの要件として挙げられたことです。
プログラマはコードの書き方ばかりに注意が向きますが、お客様の重視していることはこれまでの業務プロセスを変えないで済むかで、2フェーズコミットやjQueryのほうが些末などうでも良いことだったりするのです。
nagi
個人投資家さんへ。
例え話をいきなりN88-BASICに例えるのは極端すぎませんか？
これだから、適切でない（以下略
本筋をよく読まれたほうが良いかと思います。
そもそも論、小学生レベルの書き手の何が言いたいのでしょう？というレベルの
読書感想文提出レベルかと。
「本筋として何を作者は伝えたいか」の部分をごっそり無視して
細かい描写にも出ていないレベルの突っ込みしても一般の読み手にはどーでもいいんですよ。
個人投資家
＞「本筋として何を作者は伝えたいか」の部分をごっそり無視して
ドキュメントよりもコードを書く奴が一番偉い
最新のプログラム技術を知らない奴はダメ
てことでしょ。プログラマ至上主義ですよ。
わたしも嘗てはそうだったけど。
でも、それを主張したいのであれば、小型メインフレームからのオープン移行案件を題材にするは不適切です。
現在の描写では五十嵐やKSR電機のシステム開発部の連中のほうがピント外れな間抜けに見えてしまいます。
それはつまり、書き手がこの種の案件についての知識が無いことを示しています。
一昔前のハリウッド映画に良く出てきた「ふっふっふ、冥土の土産に教えてやろう、実は我々の目的は・・」って主人公に悪の組織の企みを懇切丁寧に解説するお間抜けな悪のボスみたいなものです。
主人公を勝たせるためにことさら敵方を間抜けに描くと、主人公のほうが馬鹿に見えてきます。
「ダイハード」」（第1作目）がすごく面白い良くできた映画であるのは、敵のボスが頭が良くて、主人公や警察・FBIの動きを予測して先手、先手を打ってくるからです。
＞細かい描写にも出ていないレベルの突っ込みしても一般の読み手にはどーでもいいんですよ。
読者のレベルを低く見てはいけません。
nagi
＞ドキュメントよりもコードを書く奴が一番偉い
＞最新のプログラム技術を知らない奴はダメ
＞てことでしょ。プログラマ至上主義ですよ。
＞わたしも嘗てはそうだったけど。
そんなこと書いてないと思いますよ？
なのでそれ以下の内容は当てはまらないのでスルーしますね。
変わろうとしないエンジニアというかITだけじゃないですが
学習し、変化を恐れて自分の経験()だけで突っ走ってる人は淘汰されますよ。
ってだけかと。
傲慢と偏見でも同じこと書いてますよね。
＞読者のレベルを低く見てはいけません。
あなたのレベルを低く見ているんです。
dotJ
＞個人投資家さん
＞わたしが挙げた指摘点は、どうでも良いことではなく、実際に自動車業界の部品の下請け会社で、複数の工場にある小型メインフレームをオープン化するプロジェクトに携わったときにお客様からの要件として挙げられたことです。
それはつまり、あなたの経験の範囲でしか物を言ってないってことではないですか？
武田さんと同じじゃないですか。
DumbObj
著者が何を言いたいのかについては、読み手によって違う受け取り方があってもいいと思いますよ。
本編を読んだり、コメント欄を見たりして、自分が知らなかったことや自分とは異なる考え方を知り、何かしら学びがあるといいんでは？
他人を卑下しても、自分が賢くなるわけでも成長するわけでもないと思うので、ほどほどに〜。
自分も含めてだけど。
個人投資家
＞それはつまり、あなたの経験の範囲でしか物を言ってないってことではないですか？
＞武田さんと同じじゃないですか。
IT企業を舞台にした小説を書くとしましょう。
取り扱う案件は、製造業の中小企業の小型メインフレーム上の在庫管理プログラムをオープン系へ移行です。。
作品中では技術的なすったもんだがあって、それがストーリーの展開上、キャラの行動上必要だとします。
書き手の経験が
（１）WEBのフロントエンド系の開発経験しかない
（２）実際に同種のオープン化移行案件を手がけたことがある
のどっちのほうが、本物っぽい（あるある）話を書けるでしょうか？
書き手に必要な知識が不足していたためにズッコケた小説には、SF作家山本弘の「神は沈黙せず」があります。
加古沢という抜け目なく立ち回る頭の良い(筈の)悪役が登場するのですが、彼は作中で日本政府を倒そうとネットで呼びかけます。
＞「具体的に言えば、あなたは今年度の税の納入を拒否すればよい。税収がなくなれば、旧政府は存在できなくなる。」
加古沢はこれを「一年かけて下調べを行い、多くの専門家の意見を聞き、スタッフとの間で激論を繰り返して得た結論」
として力説するわけですが、「神は沈黙せず」刊行直後から読者に
「源泉徴収を知らないのか、こいつは？」という嘲笑を浴びました。
自サイトの掲示板で指摘された山本弘は
> 源泉徴収については……いや、おっしゃる通りですね。すみません。
とポカを認めています。
日本政府が倒れ、革命政権が成立するという作品の根幹の部分がひっくり返ってしまったわけです。
このポカによって、作中では抜け目なく立ち回る頭の良い(筈の)加古沢という作家は、作者の意図に反して「ただの間抜け」になってしまいました。
今回の場合、五十嵐とKSR電機のシステム開発部の連中が加古沢に相当しますよね。
個人投資家
＞変わろうとしないエンジニアというかITだけじゃないですが
・製造業の小型メインフレーム系の在庫管理プログラムのオープン化移行案件において、jqueryは、どの程度重要だと思いますか？
・レビューで指摘しなければならない観点の上位に来ると思いますか？
・この案件においてjqueryの使用は必須だと思いますか？
・nagiさんがレビューアだったとして、オープン化移行案件のレビューはどこに力点を置いてレビューしますか？
nagi
引用部分と質問内容の関連性が皆無すぎて困るんですがｗ
誤読なのか天然なのかはたまたなんなのか分からないので何が言いたいのでしょうｗ
引用された内容について補足するなら
「どんな職務においても」という意味で
勉強もしない自ら研鑽しない人間はどのみち淘汰されますよね
という意味を込めて書いたのですがそれが分からなかったのならすみませんｗ
で、質問内容ですが。
＞・製造業の小型メインフレーム系の在庫管理プログラムのオープン化移行案件において、jqueryは、どの程度重要だと思いますか？
顧客の要望・実現させたいによります。よって要件定義の段階のレベルです。
＞・レビューで指摘しなければならない観点の上位に来ると思いますか？
背景的に社内である程度回せれるけど何らかの理由で外注したというストーリーですので
「後々メンテができるよう」こうしてほしいという要望のレベルの類です。
ぶっちゃけ、どーでもいいです。
＞・この案件においてjqueryの使用は必須だと思いますか？
上記と一緒
＞・nagiさんがレビューアだったとして、オープン化移行案件のレビューはどこに力点を置いてレビューしますか？
概略的にこーしますよ。以上。
要件定義の段階である程度知識のある顧客に、
１～１０まで説明するのはありません。
高校生に足し算から説明するレベルですから。
で、質問の意図はなんなのでしょうかね。
まさか無駄な質問とかあなたの知識を～とか試したとか言われたらどーしましょうねぇ。
それこそ、低レベルすぎて話にならない人間の烙印ですかね。
nagi
書き忘れてたので。
＞著者が何を言いたいのかについては、読み手によって違う受け取り方があってもいいと思いますよ。
まぁ分かりますけど。
別に十人十色あってもいいと思うんです。
ただ、自分の感想が圧倒的に正しい（キリッ）
とか恥ずかしい人だなーという印象からつい。
ひまひま
>>個人投資家
この小説って、会社が変化を求めてたんだろ。
そんで、課長が五十嵐を連れてきたんだろ。
人事以外の権限まで与えたんだろ。
武田が逆らっている時点で、武田が馬鹿なだけ。
技術ウンスン関係ない。
勝てるわけない。逆らえるわけない。
だって敵は五十嵐じゃなくて会社なんだから。
人事権なくても、リストラの様な嫌がらせうけるだけ。
武田が頑張っているけど無駄な努力。
部署移動願いでも出せばいいし、他のことで評価されるように動けばよいだけ。
関わってはいけない相手に関わっただけ。
えびふりゃあ
＞個人投資家さん
＞オープン化移行案件のレビュー
なんかずれまくってませんかね。
今進行中の会議は案件のレビューじゃなくて詳細設計レビューでしょ。
つまり画面の機能についてのレビューをしてるわけです。
それであればjQueryとかAjaxが話題になって当然でしょ。
＞自動車部品の下請け工場だと3シフトで動いていて24時間LOGONしっぱなしとかあり得る。
いつの時代？
今どき下請け工場といえども親会社（この場合はK自動車か）から内部統制の要件などを求められるので、そういうセキュリティに甘いことはありえない。
＞だから、マスタに2フェーズコミットでリアルタイムに更新をかける必要はないんじゃないの？
＞各工場にあるサーバのデータを月末にバッチで反映する月次処理で十分じゃないの？
あなた、武田さんと一緒に要件定義会議に出席したんですか？
リアルタイムに更新をかける必要がないとか月次処理で十分だとか、何を根拠に言ってるんですか？
個人投資家さんが以前に体験したオープン化案件ではそうだったかもしれないけど、今回の案件には関わってないでしょ。
文中では明示されてないだけで要件には”社内開発チームが保守しやすいようにAjax等を使用すること”とか書かれてるかもしれないでしょ。
自分の限られた経験だけを絶対視して、他の可能性を受け入れないというのは、三浦マネージャだね。
個人投資家
＞
＞＞・レビューで指摘しなければならない観点の上位に来ると思いますか？
＞背景的に社内である程度回せれるけど何らかの理由で外注したというストーリーですので
＞「後々メンテができるよう」こうしてほしいという要望のレベルの類です。
＞ぶっちゃけ、どーでもいいです。
＞＞・この案件においてjqueryの使用は必須だと思いますか？
＞上記と一緒
jQuery使うかどうかは、どうでも良いって事ですね。
つまり、
「罪と罰（22） 決戦は金曜日」において、レビューでjQueryのバージョンや、InputタグやHelperクラスのぐだぐだした話は、案件にとってはどうでもいいということですね。
どうでもいいことでレビューの時間を消費しているKSR電機のシステム開発部の連中や五十嵐は、ピント外れレビューをしているわけです。
武田氏が業務に必要な知識を身につけていないことを示すには誠に持って不適切な案件を、作者は選択してしまったわけです。
だって、jQueryなんて「ぶっちゃけ、どーでもいい」事項なんですから！
個人投資家
＞文中では明示されてないだけで要件には”社内開発チームが保守しやすいようにAjax等を使用すること”とか書かれてるかもしれないでしょ。
つまり、書くべき事を作者が書いてないって事です。
nagiさんが書かれたように「要件定義」が問題の中心なので、実装コーディングでjQueryを使うかどうかを問題にする今回のエピソードの場面設定が間違っているって事です。
なぜそうなったかというと、
・作者にオープン化移行の要件定義工程の実務経験や知識が無い
・作者の興味は、コーディング技術に集中している
・ドキュメントよりもコード主義
だからです。
＞いつの時代？
ほんの数年前
＞今どき下請け工場といえども親会社（この場合はK自動車か）から内部統制の要件などを求められるので、そういうセキュリティに甘いことはありえない。
あり得ないというのは思い込みです。
実務で直面したら「え」ということはままあります。
ひまひま
>>個人投資家
jqueryについて咄嗟に答えただけでしょ。
【罪と罰（18） 第1開発課の新規案件】で、勝手に武田が引き受けたんだろ。
>自動車部品の下請け工場だと3シフトで動いていて24時間LOGONしっぱなしとかあり得る。
WEB系だと、LOGONしっ放しはセッションタイムアウト(操作しない時間が長いと強制ログアウト)になって落ちるよ。
本当にWEB系に関わったことあるの?
えびふりゃあ
＞個人投資家さん
＞ nagiさんが書かれたように「要件定義」が問題の中心なので、実装コーディングでjQueryを使うかどうかを問題にする今回のエピソードの場面設定が間違っているって事です。
何度も言いますがこの会議は「要件定義」ではなく「詳細設計」のレビューでしょ。
そこのところわざとスルーしていますか？
＞あり得ないというのは思い込みです。
＞実務で直面したら「え」ということはままあります。
そうですね。そのお言葉をご自分にあてはめて考えてみられてはいかがでしょうか。
＞つまり、書くべき事を作者が書いてないって事です。
じゃあたぶん数十ページ以上あるだろう要件定義の全てを詳細に書けと仰る？
そんなもの誰が読みたいかな。
この限られた文章を読んだだけで、
＞作者にオープン化移行の要件定義工程の実務経験や知識が無い
などと断定されるのは、それこそ思い込みでしかないでしょ。
ああ去年の今頃炎上した某大藤氏のことを思い出しますね。
あの人もやたらに断定したり決めつけたりしてましたっけ。
寝よう。
えびふりゃあ
あ、もう一つ。
＞ 「ダイハード」」（第1作目）がすごく面白い良くできた映画であるのは、敵のボスが頭が良くて、主人公や警察・FBIの動きを予測して先手、先手を打ってくるからです。
何が面白いのかまたは面白くないのかということは、それこそ千差万別でしょ。
「ダイハード」にしたって、ある人は主人公と警官が無線を通してはぐくむ友情に感動するかもしれないし、ある人はガンアクションの描写に興奮するかもしれないし、ある人は事件が日本企業のビルで起こったことに国際情勢的な興味をおぼえるかもしれないでしょ。
私の経験からするとよく知りもしないで「○○です」と決めつける人が設計するシステムはだいたいどっかに穴があります。
通りすがり
＞個人投資家さん
毎度奇麗事だけ支持しているけど、
今の現実の現場知らなければ黙っていればいいのに。
現実レベルでのシステム（開発プロセス）での改善点とそのコストと時間を評価
しなくて結果だけで○×言っているだけでの評論家ですむなら、そら楽な世界だよ。
淵上メソッドは本来のコストを現場に押しつけているだけのブラック手法。
コスト倍払ってもそれを支持するなら傾聴に値するけど、リスクは現場、
利益はPMってだけじゃ只の無責任だわな。
nagi
えーっと。寝てる間にひまひまさんとえびふりゃあさんが
大体私が言いたいことを言っていただけたので何も言えないｗ
で、見事にスルーされていますが
＞引用部分と質問内容の関連性が皆無すぎて困るんですがｗ
＞誤読なのか天然なのかはたまたなんなのか分からないので何が言いたいのでしょうｗ
これの個人投資家さんが引用された内容と質問の意図を説明してもらえませんかね？
あ、都合が悪いのであれば、都合が悪いので答えられません！
でもいいですよ？
その場合なんとか自分が優位に立とうとして失敗したただの恥ずかしい人ということで。
個人投資家
＞これの個人投資家さんが引用された内容と質問の意図を説明してもらえませんかね？
本当に判らないんですか？
作劇の方法について実例を引いて説明しているのですよ。
（１）「ダイハード」
主人公をピンチから脱出させるために敵を馬鹿に描くと、主人公も馬鹿に見えてくる。
「ダイハード」はその轍を踏まず、賢い敵を作って、主人公をピンチに追い込み、主人公が上手く脱出することでヒーロー性を獲得させることに成功している例。
（２）「神は沈黙せず」
賢い敵を設定したつもりが、作者に必要な知識がなくて失敗した例。
＞あ、都合が悪いのであれば、都合が悪いので答えられません！
いくらなんでも上記の意味が分からない馬鹿はいないので、nagiさんが判らないフリをしているだけだと思っていました。
個人投資家
えびふりゃあさん
＞何度も言いますがこの会議は「要件定義」ではなく「詳細設計」のレビューでしょ。
＞そこのところわざとスルーしていますか？
nagiさんがすでに書かれているように、詳細設計レビューでjqueryが必要とされるかどうかは要件定義次第です。
では、作者がそこをすっ飛ばして、詳細設計レビューの場面を設定したことは作劇上正しい事だと思いますか？
＞じゃあたぶん数十ページ以上あるだろう要件定義の全てを詳細に書けと仰る？
ポイントだけ書けばいいことでしょう？
これまでも作中で、
「期間は短く、12月末納入検収」
「部品の在庫がなくなったら在庫管理処理も廃棄」
て挙げられていますね。
「期間は短く、12月末納入検収」
JavaやjqueryやHTMLを使って0からコーディングを起こして、既存システムと同じ挙動をすることをテストで確認している時間は無さそうですね。
「部品の在庫がなくなったら在庫管理処理も廃棄」
メインテナンスしやすいようにAjaxという選択肢は無さそうですね。
個人投資家
通りすがりさん
＞今の現実の現場知らなければ黙っていればいいのに。
じゃあ、あなたの体験した「自動車業界の部品製造をする中小企業で、小型メインフレーム上の在庫管理をオープン化した」事例をお話しくださいませんか？
顧客の企業秘密に関わる部分は省いてくださってかまいません。
作者のリーベルGさんに参考にもなると思いますし。
個人投資家
nagiさん
＞WEB系だと、LOGONしっ放しはセッションタイムアウト(操作しない時間が長いと強制ログアウト)になって落ちるよ。
＞本当にWEB系に関わったことあるの?
WEB系に携わっているから、そこ書いたんですよ。
もともとオープン系で仕事しているので。
「WEB系に移行するとセッションがタイムアウトで落ちますので、再ログインが必要になります」
「実は現用システム（小型メインフレーム）は、LOGONしっぱなしで運用してるんですよね。タイムアウトなしでなんとかなんないですかね」
というような会話がお客様とあったのです。
nagi
もーいっかい説明してあげますね？
＞変わろうとしないエンジニアというかITだけじゃないですが
と
jqueryの関連性を説明してください。
全般的にどの職業でも学習しない人は～から
jqueryの質問に発展したあなたの意図を教えて下さいね。
私にjqueryの質問をする意味ですよ？
小説の内容における要件定義の描写が少ない～とか
関係ないですからね？
ピントがずれてるのが分からないのでしょうかね。
nagi
私じゃないと思うんだけどｗ
まぁ突っ込みどころ満載で・・・ｗ
＞「WEB系に移行するとセッションがタイムアウトで落ちますので、再ログインが必要になります」
＞「実は現用システム（小型メインフレーム）は、LOGONしっぱなしで運用してるんですよね。タイムアウトなしでなんとかなんないですかね」
＞というような会話がお客様とあったのです。
あ、うん。あったのね。それで？
あったから何だっていうの？ｗ
もしかして、ログインしっぱなしにできるようにしちゃったの？
まさかねーｗ
まりも
ふっちーLoveさんに反論しようと内容を検討してみたのですが。
言っている主旨は間違っていないんじゃないですかね。
アジャイルだって、製造業の影響は強いわけですし。
ただ、具体的な話をすると、
実際の作業内容の感覚がわかっていないせいか、
現実から離れすぎているので、どうにも反論がしたくなる意見になってしまっている、
というだけなんじゃないでしょうか。
ひまひま
>>個人投資家
>>「WEB系に移行するとセッションがタイムアウトで落ちますので、再ログインが必要になります」
>>「実は現用システム（小型メインフレーム）は、LOGONしっぱなしで運用してるんですよね。タイムアウトなしでなんとかなんないですかね」
そんな仕事よくできたね。
お客はデスクトップのロック機能を使わないの？
利用者が離籍(お手洗いや会議)している間に弄られる可能性があるからセキュリティーは保障できない。
セキュリティー関係で一部欠陥がある契約を交わす?
ありえない。そんな客はいないし、Sierもいない。
現実の設計書なんて訴えられないための【保険】がほとんど。
契約に欠陥があったら、裁判になるだけ。
実際の業務では、一部の処理だけBatch処理で対処する。
個人投資家
>＞変わろうとしないエンジニアというかITだけじゃないですが
と
>jqueryの関連性を説明してください。
すでに、nagiさん自身がわたしの問に回答する形で、回答していますよね
jqueryなんて「ぶっちゃけ、どうでもいい」って。
小型メインフレーム移行案件でjqueryを使うか「どうでもいい」。
つまり、ここで武田氏がjqueryについて何も知らなくても、案件には何ら支障がない。
武田氏にとってマイナス材料にならないので、作者は題材の選択を間違えたってわけです。
逆に「ぶっちゃけ、どうでもいい」jqueryについて細々したことを言っているKSR電気電機のシステム開発部の連中や五十嵐にとってマイナス材料になっているってことです。
nagi
ちゃんと読んだほうがいいですよ？
＞小型メインフレーム移行案件でjqueryを使うか「どうでもいい」。
ここから
＞つまり、ここで武田氏がjqueryについて何も知らなくても、案件には何ら支障がない。
この飛躍ってありえないんですよね。
いつ私が武田さんが知らなくてもいいなんて言いました？
ストーリーと文脈ちゃんと読んだほうがいいですよ？
Ajaxでよろしく→jquery使おうかと→あ、それでいいです。
って流れですよね？
レビューに対する要望はAjaxであってjqueryじゃないんですよ？
Prototypeでもいいかもしれませんよね。
だから、jqueryに拘って質問してきてるあなたの質問自体を
どーでもいいこと何聞いてるんですかって言ってるんです。
で、質問に対する回答はまだですか？
個人投資家
＞お客はデスクトップのロック機能を使わないの？
＞利用者が離籍(お手洗いや会議)している間に弄られる可能性があるからセキュリティーは保障できない。
工場の在庫処理システムで、3シフト。
シフトの頭に主任がログインして、発注処理は担当者(複数)が行う。
シフトの終わりに主任がログオフして、次のシフトに引き継ぐ
という処理でした。
つまりログオン中に他の人が使うことが前提。
セキュリティ上問題あるのは、お客様も承知の上での運用をしていた。
(お客様は小型メインフレーム上のクローズドシステムで、監査用のログも常時採取しているから、不正操作があった場合は履歴が残るし、ということでこれまで運用していた。）
こちらからは当然問題があることは指摘します。
えびふりゃあ
＞個人投資家さん
どうも個人投資家さんは
自動車業界の部品製造をする中小企業で、小型メインフレーム上の在庫管理をオープン化する場合は、Webアプリケーションにするのはおかしい
と決めつけていらっしゃるようです。
実際に私は業界は違いますがACOSからのダウンサイジング案件に携わったことがありますが、ターゲットはWebアプリケーションでした。
2008年頃だったのでAjaxでの画面書き換えは機能要件に普通に含まれていました。
この物語ほど細かいレベルでのレビューが行われたかどうかはしりませんが、仕様書には記述があったので、どこかの時点で決定が行われたのでしょう。
以前に個人投資家さんがされた質問
＞・製造業の小型メインフレーム系の在庫管理プログラムのオープン化移行案件において、jqueryは、どの程度重要だと思いますか？
→ jQueryが重要かどうかなど、ケースバイケースなので、絶対的な答えはないでしょ。たまたまKSR案件のこのレビュー会議では重要だったというだけのことです。何度も言いますが詳細レベルのレビューです。要件定義レベルでは話題に上がらなくても、詳細レベルなら、担当者によっては重要視しても不思議ではないです。
＞・レビューで指摘しなければならない観点の上位に来ると思いますか？
→同上
＞・この案件においてjqueryの使用は必須だと思いますか？
→顧客が必要だと思うなら必要だし、不要だと思うなら不要でしょ。この場合は、顧客が必要だと要望したということです。
＞・nagiさんがレビューアだったとして、オープン化移行案件のレビューはどこに力点を置いてレビューしますか？
→要件定義レベルなら業務フロー中心になるだろうし、詳細レベルなら画面や帳票上の必要項目になるでしょ。今回は後者でしょ。
何度も言いますが、ご自分の経験だけを元に「○○のケースでは、××とするものだ」と決めつけているのは滑稽です。「オブジェクト指向など実業務で何の役にも立たない」と決めつけているのと同じです。
それから、
＞「WEB系に移行するとセッションがタイムアウトで落ちますので、再ログインが必要になります」
＞「実は現用システム（小型メインフレーム）は、LOGONしっぱなしで運用してるんですよね。タイムアウトなしでなんとかなんないですかね」
それじゃあ、LOGONの意味がないでしょ。それなら最初からLOGONしなくてもいいぐらい。
でもそんなことよりも、セッションタイムアウトの話が、今回の話とどう関係してくるのか不明ですが。
「まあそういうお客さんもいるでしょうね。で、それが何か？」としか思わないでしょ。
個人投資家さんが「ずれてる」と思うのはそういうことです。
個人投資家さんが今回の話が「題材の選択を間違えたってわけです」と思っているのは、個人投資家さんの個人的な体験に基づく個人的な意見でしかないのに、あたかも業界全体の総意であるかのように断言しているのはおかしいでしょ。
個人投資家
＞いつ私が武田さんが知らなくてもいいなんて言いました？
レビュー観点についてnagiさんは
jqueryなんて「ぶっちゃけ、どうでもいい」って回答してますよね。
「顧客の要望・実現させたいによります。よって要件定義の段階のレベルです。」
とも回答しています。
要件定義の段階をすっ飛ばして、詳細設計のレビューの場でjqueryだの言うのはおかしいでょ？
要件定義で言っとけよということです。
つまり作者が不適切な題材(要件定義をすっ飛ばして詳細レビューを舞台にする）を選んでしまったって事です。
判りませんか？
判らないフリをしているのかな？
でも要件定義次第だって言っているのだから判っているはずですよね？
nagi
あー判りました＾＾；
失礼を承知でいいますが、
あなたに足りないのは技術力とかそういうのじゃなくて
日本語の読解能力とコミュニケーションスキルですね。
なんていうか、うん。
単語じゃなくて文章を読みましょうよ＾＾；
てっか、これはなんですかね。
えーと私の言ってること判りづらいんですかね。
まず自分が言いたいことが優先順位的に１番なんでしょうかね。
で、他人が言ったことは右から左に流れて咀嚼せずに
真っ向からいや違う！みたいなｗ
流石にここまでなんというか文章読めない人は見たことがないので何を言っていいやらｗ
多少なりとも人の話には耳を傾けましょうね？
我儘駄々っ子みたいに自分の主張で上書きしてヤンヤ言わずに…さ。
恫喝を警戒して匿名
> 要件定義の段階をすっ飛ばして、詳細設計のレビューの場でjqueryだの言うのはおかしいでょ？
> 要件定義で言っとけよということです。
>
> つまり作者が不適切な題材(要件定義をすっ飛ばして詳細レビューを舞台にする）を選んでしまったって事です。
「そういった諸要件を前段階でヒアリングできていない、(顧客軽視な)武田さん」
という描写だと読解していましたが。
実際「要件定義で言っとけよ」なんていうSIerがいたら、即刻契約解除でしょうね。
ひまひま
>>nagi
>>個人投資家
>工場の在庫処理システムで、3シフト。
>シフトの頭に主任がログインして、発注処理は担当者(複数)が行う。
>シフトの終わりに主任がログオフして、次のシフトに引き継ぐ
という処理でした。
>つまりログオン中に他の人が使うことが前提。
これじゃあ、主任と発注担当は別機能だろ。
ログオンの定義を間違っているよ。
システムのログインは個人単位の話。
あなたのログインの説明はシステム単位の話になっている。
>>「WEB系に移行するとセッションがタイムアウトで落ちますので、再ログインが必要になります」
>>「実は現用システム（小型メインフレーム）は、LOGONしっぱなしで運用してるんですよね。タイムアウトなしでなんとかなんないですかね」
上記のシステムなら、セッションタイムアウトを削る必要がない。
なぜなら、個人単位で影響与える制限だから。
DumbObj
おっ、休日も盛り上がってますね〜。(>д<｀) ...
jQueryのバージョン確認などのくだりは、今回の案件において重要だから描いたのではなく、設計レビューの内容にリアリティを持たせるために描いたのでは？
ユーザー企業で、多少実装知識を持った人たちがどういう質問をするのか、どんな回答に満足するのか、すごくリアリティのある描写だと思いますけどね。
バリデーションの実装方式について聞かれてる時に、Input typeの話で返すのとか、開発者同士の会話なら成り立たないけど、ちょっと実装知識のあるユーザー企業担当者と、詳細設計の不備を口でなんとかごまかそうとしているベンター技術者との会話だから成り立つわけで、計算ずくだと思いますけどね。
DumbObj
あらま。バリデーションについてわかってなかったのは、自分のほうだったわ。めんごめんご。あ〜、これが武田さん状態かぁ。
うっちー
渕上信者はコメント欄を荒らすのが趣味だとよくわかる
nagi
ひまひまさん
えーっと、私の名前が引用に入っている理由が分からないっす。
何かを伝えるがために含めたならば、
あ、うん、そっすね。おかしいですね。
文脈から察するに、ただ引用（なぜか私宛になってましたから。）しただけでも
どんな相手でも最低限「さん」つけはしたほーがよいかと。
引用ミスだったらまぁ、わかりますけどー。
ついでに本題？というか疑問
要件定義書で、通常本コラムの状況の中で（Ajaxのくだり）
Ajaxのjqueryを使用して～とかなんとかって書きますかね。
私なら書かないかなー。
精々コンボボックスが変更されたら対応する値の一覧を別コンボボックスに割り当てるとかなんとか書きますね。
上記のような感じで、発生したレビューでの顧客からの質問ならしっくりくるんですが、
通常、そこまで詳しく書くものなのかな。
個人投資家
＞システムのログインは個人単位の話。
そうです。
メインフレームだと、システムとセッションのログインを別々に管理できるから。
でも、WEB系のオープンシステムだと、もともとそんな機能はないので、メインフレーム時代と運用手順を変更することを検討しなければならないんです。
判っている人がいると話が早くて楽です。
カレー
個人投資家さんの話は、正直なところ何が言いたいのかわからないですね。自分に都合の悪い指摘はスルーするか、下手なたとえ話でごまかしてるし。
こういうわかったようなこと言いながら、実は全然わかってない老害さんは、見ていて気の毒になってくる。
ログインの話、結局、個人投資家さんは、どう対応したのか。
それさえはっきりしない。