罪と罰（46） IT統制
驚いたか驚かなかったか、と問われれば、もちろん驚いた。ただ、私が驚いたのは、その内容ではなく対象人物だった。嶺井課長に話があると言われたとき、私はてっきり飛田をもう連れてくるな、と言われるのかと思ったからだ。
「あの、進藤をですか」
「ええ」
「飛田ではなくて？」私は念のために確認した。
「進藤さんです。意外ですか？」
「はい」私はうなずいた。「さっきの飛田の、その、暴走も進藤が収めたようなものですし、御社の担当者からも信頼していただいているようですし......」
「そうですね。先ほどの進藤さんはお見事でした」
「だったらどうしてでしょう？顔の怖さだったら、飛田の方がはるかに上だと思うんですが」
嶺井課長は私の冗談にお義理で笑ってくれた。
「別に進藤さんの人間性や容姿を問題としているわけではないんですよ。理由は、今、箕輪さんが仰ったことです。うちの三吉あたりと付き合いが長すぎるのが問題なんです」
「どういうことでしょうか」
私の質問には直接答えず、嶺井課長は手にしていたAndroidタブレットにタッチした。そして、何か入力しながら逆に訊いてきた。
「最近、Ｋ自動車の方で、IT統制強化が推進されているのをご存じですか？」
「え、ああ、はい。まあ聞いたことはあります」
うちの顧客には、Ｋ自動車の関連会社が多いので、その手の話題は自然と耳に入ってくる。ICT絡みであればなおさらだ。
「去年から、うちみたいな関連会社にも、その波が押し寄せてきましてね」嶺井課長は苦笑した。「発端は県内の......ま、某会社としておきましょうか、そこに納入された発注管理システムがボロボロだったせいらしいです。LAMPのシステムだったそうですが。セキュリティと称してBasic認証かけただけでレンタルサーバに置いていて、危うく取引情報流出につながりかけたようで」
「それはひどいですね」
「そこもシステム部の担当者と、業者......失礼、開発システム会社側の担当者が長い付き合いで、発注ありきで始まったようです。結果として要件も仕様もろくに詰めずに、納期だけ決まった開発となって、それも遅延、遅延、仕様変更、遅延、といった具合に遅れていって。挙げ句にできあがったのはクズだったという次第ですよ」
よくある話といえばよくある話だ。いつか五十嵐さんが「クズが作ったものはやっぱりクズだ」と言ったことがある。
「その話がＫ自動車にも伝わってしまって、その会社と付き合いのあったＧＭさんが怒り狂った、というより、不安になってしまったんですね。で、他の関連企業は大丈夫なのか確かめろ、と鶴の一声ですよ」
嶺井課長はタブレットを私の前に置いた。
「それご存じですか？経産省が出しているシステム管理基準ですが」
私はタブレットを覗き込んだ。1つのPDFファイルがブラウザ上に開かれている。
「読んだことはあります」私は答えた。「ただ正直なところ、抽象的すぎて、基準になってないとしか思えませんでしたが」
「それは見方によるとは思いますよ。書いてあることは真っ当なことばかりですし。まあ、それはともかく、ITシステムの開発は、原則的にこれに基づいてやれ、というお達しが来たんですよ」
嶺井課長は指を伸ばすと、文書をスクロールした。
「このあたりですね」
私はタブレットに目を落とした。
２．分析（８）
(1）開発計画に基づいた要求定義は、ユーザ、開発、運用及び保守の責任者が承認すること。
（2）ユーザニーズの調査は、対象、範囲及び方法を明確にすること。
（3）実務に精通しているユーザ、開発、運用及び保守の担当者が参画して現状分析を行うこと。
（4）ユーザニーズは文書化し、ユーザ部門が確認すること。
（5）情報システムの導入に伴って発生する可能性のあるリスク分析を実施すること。
（6）情報システムの導入によって影響を受ける業務、管理体制、諸規程等は、見直し等の検討を行うこと。
「私が情報処理管理課に異動してくる前のシステムの発注は」と、嶺井課長は少し苦い顔になった。「各部の庶務担当者が欲しいと思った機能や帳票なんかを、三吉に連絡していたようです。三吉が御社の進藤さんと打ち合わせを行い、詳細や工数、納期などを決めて稟議に上げる。稟議といっても形式的なもので、霧島までほぼスルーパス状態で。それで注文書が出るわけです」
「はあ、それはまた」私はいい表現を探すために言葉を切った。「ずいぶんと簡潔でシンプルですね」
「簡潔です」嶺井課長もうなずいた。「おわかりの通り、そこに社内のIT資産を管理する部門である情報処理管理課が関与する余地が全くないんです。ITシステムだって立派な資産だというのに。それで、今年度から稟議のルートを変えたんです。情報処理管理課を通るように」
「そうだったんですか」
「これまで、御社に発注した機能追加や改修には、納品されたはいいけど、あまり使われていなかった、というものもいくつかあるんですよ。いえ、言葉を飾っても仕方がないですね。いくつか、ではなく、実は相当あるんですよ」
「そうみたいですね」
飛田が新システムの設計段階で画面や帳票を大幅にカットしたのに、その件について三吉さんも他の庶務担当者も、ほとんど何も言わなかったので、そんなことではないかと薄々気づいてはいた。
「いくら1つ1つは少額とはいえ、重なれば山ですからね。稟議ルートの変更は、情報処理管理課がチェックすることによって、そんなムダな改修をなくす意図があるんです」
「そうだったんですか。でも」私は首を傾げた。「新システムまでのつなぎで進藤がやってる旧システムの改修は、相変わらず来てましたが」
「そこで、進藤さんを外して欲しい、という話につながるわけなんですがね。上がってきた稟議を、情報処理管理課の人間がチェックしたとしても、内容はよくわからんわけですよ。かといって、三吉に訊くのもはばかられるんです。訊いたところで、そんなこともわからないのにチェックするつもりですか、それで給料もらえるなんて、いいご身分ですこと、なんて言われるのがオチなんで」
私は同情してうなずいたが、一方で三吉さんの言うことにも一理あることを認めないわけにはいかなかった。うちの会社でも、年2回の評価の際、知識のない武田さんたちに評価されることに、第2開発課のメンバーたちはずっと違和感を感じていたのだから。
「それで、うちが御社の進藤さんに連絡をして、内容が妥当かどうかを確認するんですが、もちろん妥当だという返事をいただくわけです。そりゃそうですよね。稟議のルートが変わったからといって、三吉と進藤さんが事前に、言葉は悪いですが共謀することが防げるわけじゃないんですからね」
「つまり、その共謀をやめさせたい、ということですか？」
「そうです」
「それなら、御社の方で三吉さんに事前協議は禁止と言うか、三吉さんと進藤の打ち合わせの場に、情報処理管理課の方が同席するようにするというのはいかがですか？」
私はそう提案してみたが、その程度の対策はすでに考えていたか、試行済みだったらしく、嶺井課長は否定的な反応を示した。
「そう言ったところで、そんなルールは無視されるか、表面上だけ取り繕われるのが目に見えていると思いませんか。打ち合わせに情報処理管理課の人間を同席させたところで、その場で是非の判断などできるわけがないですから。どうせ、事前に電話やメールで内容を詰めてから、打ち合わせに持ち込むに決まっています。まさかメールや電話を監視するわけにもいきませんしね」
「それは、まあ、そうかもしれませんが。ただ、新システムからは、飛田がメイン担当になるので、進藤に相談しても事は進まないと思いますが」
「それはそれで困るんですよ。飛田さんは、あのとおりの人ですから、庶務担当の人間が直接相談するのは難しいと思うんです」
「でしょうね」
「庶務担当が相談するとしたら、まず付き合いの長い進藤さんでしょう。進藤さんも人の良い方ですからね、できる限り相談に乗ろうとされるんじゃないですか？新システムの中身がよくわかっていらっしゃらないのに」
「でしょうね」カスミさんの性格からして、付き合いの長い東雲工業の庶務担当者から相談をもちかけられれば、イヤとは言わないだろう。
「そうではなく、御社への発注は、情報処理管理課を通してのみ行うようにしなければならないんですよ」
「御社の窓口は情報処理管理課のみとしたい、ということですか？」
「ええ」嶺井課長は大きくうなずいた。「弊社のIT統制上、それが正しい形ですから」
「そうすると仕様の詳細などはどうなるんでしょうか？」
「この」と嶺井課長は、タブレットを示した。「システム管理基準の通りです。人事・勤怠システムで言うなら、庶務担当と情報処理管理課とで仕様を詰めて、ドキュメント化した上で、御社に見積を依頼することになりますね」
「うーん」私は思わず唸った。「それで、仕様の詳細部分までピックアップできますか。いえ、情報処理管理課の方たちも、決してプログラムレベルの詳細まで理解しているわけではないですよね。そのあたりで齟齬が発生する可能性があるんじゃないか、ということが少し心配ですが」
「そこは大丈夫ですよ」嶺井課長は笑った。「うちだって、素人の集団というわけじゃないんですから。ちゃんと三吉にも話を聞きますしね。実際にプログラムの経験がなくても、仕様を作るだけなら問題ないでしょう」
この人がイニシアティブのメンバーなんじゃないか、と思ったこともあったが、今、そうではないことがわかった。イニシアティブの思想に共鳴しているなら、こんな技術者軽視の発言は決してしないだろう。
「もちろん進藤さんのことは、御社の人事の問題ですから、うちが指図をするわけにはいきませんがね」嶺井課長は笑顔のまま続けた。「少なくとも、情報処理管理課からは進藤さんに連絡をすることは、今後はないと思ってください。それでも、三吉や他の庶務担当が、直接連絡してしまうかもしれません。そんなときに、もう担当ではないので、と断っていただきたいんですよ」
「飛田はあのとおりの性格なので」私は抵抗を試みた。「御社の仕様に技術的な問題点などがあった場合、遠慮無く指摘すると思うんですが。進藤を緩衝材とした方が、やり取りがスムーズにいくと思いませんか」
「大丈夫です」嶺井課長は自信ありげに繰り返した。「業......システム開発会社さんとの付き合いは御社だけではないので、対応のノウハウはありますから」
その見通しは甘すぎるんじゃないか、と思ったが、ここで飛田の性格を論じていても、カスミさんの待遇を好転させる役に立つわけではないから、私は何も言わなかった。それに、そっちがその気なら、好きにすればいい、という投げやりな気持ちもあったことも否定できない。
「善処されることを期待しています」嶺井課長はタブレットを掴んだが、ふと何かを思い出したように、またタッチした。「そうそう、この話が出たのでついでにお話しておきますが、このあたりの手順も、いずれご相談させていただくことになると思いますので」
私は嶺井課長が指している部分を読んだ。
３．プログラム設計（５）
（1）プログラム設計書は、開発の責任者が承認すること。
（2）システム設計書に基づいて、プログラムを設計すること。
（3）テスト要求事項を定義し、文書化すること。
（4）プログラム設計書及びテスト要求事項をレビューすること。
（5）プログラム設計時に発見したシステム設計の矛盾は、システム設計の再検討を行って解決すること。
４．プログラミング（４）
（1）プログラム設計書に基づいてプログラミングすること。
（2）プログラムコードはコーディング標準に適合していること。
（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
（4）重要プログラムは、プログラム作成者以外の者がテストすること。
「これは御社に限らないんですが、プログラム設計書のようなものが、あまり作成されていないようなので。今後は、設計書の事前レビューや納品も求めることになるかと思います。まあ、今回の新システムでは、それは求めませんが。そのつもりでご検討ください。システムの品質を担保するためにも」
おいおいマジか、と言いそうになった。せっかく五十嵐さんの改革のおかげで、詳細仕様書作成という悪しき習慣が撤廃されたというのに。ここで復活させたくはない。
「プログラム設計書はシステムの品質向上に役立つわけではないですよ」
「でも経産省が出している文章ですよ。根拠がないはずがないでしょう」嶺井課長は時計を見た。「おっと。5分と言っておきながら、かなり時間をオーバーしてしまいました。お引き留めしてしまって申しわけありませんでした。進藤さんの件は、よろしくご検討お願いします」
東雲工業側は、次の開発案件からは別の会社に発注するというカードを、いつでも切ることができる。「ご検討」という口当たりのいい言葉は、裏返せば「検討してもらえなければ......」という強要的な意味を含んでいるわけだ。重い気分のまま、私は今度こそ嶺井課長の前から辞した。
◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇
カスミさんと飛田は、互いとの距離を1メートルほど取って、東雲工業の玄関ロビーで待っていた。何か言葉を交わしていたようだが、どちらもあまり楽しそうな顔はしていない。受付で入館証を返却している私の姿を見ると、カスミさんは少しホッとした顔で駆け寄ってきた。
「何の話だったの？」
「いえ......」私は言葉を濁した。「まあ、帰ってから」
「そう」カスミさんは、何かを考えるような顔になった。「実は、私もちょっと話があるんだけど、少しだけ時間もらっていい？」
「え、なんですか？」
「どこかで話ができる？」
「いいですよ」私は手持ちぶさたに立っている飛田を見た。「ごめん、悪いけど先に帰っていてもらえる？」
「......最初から言ってくださいよ」飛田はそう言うと、ムダにした時間を取り戻すように、ものすごい早足でロビーを出て行った。
「さてと」私は苦笑しながら言った。「じゃ、出たとこにある喫茶店でも行きましょうか」
私たちは正門から出て5、6分の場所にある、喫茶店に入った。コーヒーチェーンではなく、昔ながらの純喫茶だ。暑い日の午後だというのに客がほとんどいないのは、店内が完全禁煙であること以外に、アイスコーヒーがない、という理由が大きいのだろう。私たちはブレンドを2つ頼み、無口な初老の店主が運んでくるまで、他愛のない話で時間をつぶした。
「で」熱いコーヒーを一口飲んだ後、私は切り出した。「何の話ですか？誰かと結婚が決まったとか言わないですよね？」
「だったらいいんだけどね」カスミさんは笑った。「ちょっと決めたことがあって、レイコちゃんに一番最初に話しておこうと思ってね」
「聞きましょう」
「実は前から考えてはいたんだけど、今日のことで決心がついたのよ。10月末で退職することにしたわ」
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
誤植
もちろん妥当だという返事をいただくわけでｓ。
未熟者
進藤さん退職は管理職連中にしたら「渡りに船」ってところでしょうか。
登場人物が淘汰されてきましたね。どういう結末に持っていくんでしょうか？
かなた
誤字
＞もちろん妥当だという返事をいただくわけでｓ。そりゃそうですよね
「でｓ」になっていますね
hoge
こういう流れになるよね・・・
プログラミングとかITリテラシー低いと目の前にある（手に触れて見える）ものを信じたくなるという
o_masa
そして誰もいなくなった
たかたかハリコフ
私も立場が嶺井課長に近いので彼の言う事が分かります。
腹の中では「IT全般統制？無駄無駄無駄無駄！」とか思ってますが、そうしなければシステム監査の指摘事項になるので従うしかないんです。
しかし、プログラム設計書やプログラミングについては一理あると思います。
自社内で何か問題や問い合わせがあった時に仕様書があれば、プログラムが読めない人間でも回答に辿り着ける、少なくともデータの見方は分かるわけですから。
しかし、それはそれとして「実際にプログラムの経験がなくても、仕様を作るだけなら問題ない」は酷いですね。プログラムを書けない人間の作る仕様書を見たときの絶望感と言ったら．．．
Jairo
> たかたかハリコフ
> 「実際にプログラムの経験がなくても、仕様を作るだけなら問題ない」は酷いですね。
これは、ユーザ側から見た要求を定義した結果（アウトプット）なので、私も問題ないと思います。一般的な用語ではないかもしれませんが、このアウトプットは、要求仕様書と呼ばれたりします（非RFP）。
逆に、ユーザがほとんどこれをしないのが問題だと思います。
hrt
ところで顧客第一主義とやらで飛田を非難していた人たちはこの結果をどう見るわけで？
サルーン
>ところで顧客第一主義とやらで飛田を非難していた人たちはこの結果をどう見るわけで？
この程度の伏線も読み取れないんだ…
どう見ても嶺井のベンダー軽視からもう一波乱おきるパターンなのに
通りすがり
まだ武田さんの出番もあるのかな。
匿名
三吉と密談。退職宣言。
まさかの進藤が東雲に転職するフラグきちゃった？
ところで三吉がどうしても「さんきち」に読めてしまって困っています。
所詮、会社員なんて吹けば飛ぶよな将棋の駒ですしおすし。
hrt
> この程度の伏線も読み取れないんだ…
いや…それでは飛田やイニアイチブ叩きに熱弁奮ってた方々が余計に恥ずかしくなるが…。
たかたかハリコフ
>Jairoさん
仕様書と書いているからプログラムレベルに近いものだと思ってました。確かに、要求定義書とかのレベルの話ですね。
>ユーザがほとんどこれをしないのが問題
これは、プロジェクトマネジメントの本に出てきそうな話ですね。
正論とは思うのですが、それが可能なだけの能力を持つ人材を確保することが条件になるわけで、なかなか思うようにいかないのが現実です。
まりも
五十嵐さんが去っても話は終わらず。
完全に腰を据えて続けるようですね。
プログラム設計については、
うまく顧客を説得してほしいところではありますが。
よく考えると、
確か五十嵐さんがいたころもかなり理解の浅いことを言っていたような記憶が。
あれだとどう考えても説得するような展開は無理っぽい。
全部の論拠をしっかり書いていたら小説にならないので、
やむなく手を抜いているのかと思ったら。
伏線だったんですねえ。
ますます目が離せなくなってきた。
どっちに話が転がっていくのだろう。
K
>経産省のシステム管理基準
役に立たないクズ文章の典型ですね。
お役所仕事の極み。
元請けの自称SEが、これに沿った設計をやってると自慢してたっけ。その人の作る仕様書はクズだった。
fuga
業者って言い方失礼なのか
下請けに思いっきり業者さんとか言ってたわｗｗ
Jitta
> （2）システム設計書に基づいて、プログラムを設計すること。
今初めて原本を見たけど、最初に「抽象的すぎて、基準になってないとしか思えません」と言っているとおりだな。
この書き方だと、「どれくらい詳しく」書けと言っているのか、わからない。
いや、詳細の程度を示さない書き方にしたんだろうな。
（４．プログラミング）「（2）プログラムコードはコーディング標準に適合していること。」が満たせるように、自社のコーディング標準を作って、プログラム仕様書の内容は「自社のコーディング標準に沿っていること」でもかまわないかと。
または、javadoc ？でしたっけ？あれを最初に作って（関数の殻だけ作って）出力し、プログラム仕様書としても、この基準に対しては OK！何も武田さんが要求するような細かい設計書を書く必要はない。
何でプログラム仕様書を書いてたかってぇと、CPU の使用時間が高価だったからで、コンパイルして実際に動かしてバグを見つけるのではなく、机上で見つけられるバグは見つけてしまおう、ってことじゃないかなぁ。今は人件費より CPU 時間の方が安価なんだから、なくても良いと思う。いや、ある程度はないと、困るんだけど。
まぁ、今回のような、「何で今頃・・・」は、ある程度減るだろうなぁ。
で、業者…もとい、システム開発会社さんからの問い合わせに答えなければ、実装が進まない。
そしてそれは、工程遅延をもたらす・・・どちらも損するだけだな。
作中の登場人物も、コメント欄で熱くなられている諸兄も「ＡかＢか」を求められているように思います。
でも、現実的な解は、「ＡとＢの中庸」、飛田さんの言うことももっともだし、カスミさんのような人も必要なんじゃないでしょうか。
みんながみんな、カスミさんのようになっても、飛田さん（他、イニシアティブの様な考え方）になっても、社会として成り立たないと思う。
lav
自分だったら、瀬川部長に相談して、東雲さんからの受注を捨てる方向を考えるかな。
他をさがす。
結局、こっちもボランティアでやってるわけではないので、
労働工数に見合った売上、利益が取れなくなるとこからは仕事を受けたくない。
だから、最低限のドキュメントだけ残してケツまくってしまうな。
メネメン
こう来たか。
「武田さん」と「飛田さん」
「KSR」と「東雲工業」
顧客に応じた仕事の進め方があるんだよってことなんだろうか。
でも、スワップしたところで、武田さんでイケるとは考えにくいんだけど。
システム管理基準ww。
システム監査の人たちが、こういうのを頭に入れてたのかと思うと、いろいろ納得。
通りすがり
嶺井「～実際にプログラムの経験がなくても、仕様を作るだけなら問題ないでしょう」
橋本「」ｶﾞﾀｯ
嶺井「～プログラム設計書のようなものが、あまり作成されていないようなので。
今後は、設計書の事前レビューや納品も求めることになるかと思います。」
三浦「」ｶﾞﾀｯ
ななし
>通りすがりさん
ﾜﾛﾀ
わるを
箕輪のチームに設計書作成スキルはない、これからも養成したくないってことなら、武田にヘルプしてもらえば良いじゃん。
eno
＞わるをさん
スキルの有無じゃなくて、設計書作成することで生じする工数の増加、設計書が終わるまで取り掛かれないことによるスケジュールへの悪影響（先行して作成したとしたら手戻り）を心配してるんじゃないかぁ。
設計書という納品物だけの話で済むならいいけど、プロジェクトの進め方や工程に（箕輪視点でマイナスにしかならない）縛りを設けるってことだと、誰が設計書を作成するかって問題にとどまらないので。
適材適所でみんな幸せ、だといいよね。
わるを
ドキュメントを作成する工数は、盛り込まないと駄目だよね。これは箕輪の仕事だと思う。
限り無く、人月勘定にならざるを得ないけど。
ただ、客先が統制を重要視するなら、ビジネスのスピードは絶対に落ちるし、それは覚悟しなきゃ。
その上で、自分のチームとしてのスピードを重視した開発スタイルを堅持したいなら、ドキュメント要員は外部に求めるべきだと思うなあ。
わるを
あ、eno氏の発言に対しては、何も反論はないっす。
往々にして、設計書の問題だけにはとどまらないのは確かだしねえ。
m
ゆとりの法則だったかなぁ、デマルコの本でさ、カスミさんみたいな人を整理した結果、組織がおかしくなりました、みたいな話あったような…。
個人的には、高給取りじゃないって前提であればカスミさんみたいな人って必要だと思うんだよね。
eno
自分も外部メンバーの追加が落としどころのひとつってのは賛成ー。＞わるをさん
統制を重要視する顧客とどう折り合いをつけるか、スピード低下やコストの増加を認識させられるか、箕輪さんのお仕事はもりだくさんってことで。強いて言うなら、こういう交渉（バトル）をするためには技術≒現場を知らないとできないってあたりもイニシアティブの主張の一部かな？
デマルコさんの本はどれ読んでもわりとハズレがない印象。
メネメン
"仕様"とか"仕様書"って言葉が曖昧過ぎるのかな。
箕輪さんが言う"仕様"と、嶺井さんの言う"仕様"は、意味も詳細度も違いそう。
"要求仕様"って言葉も、ユーザーとベンダー間で誤解が生じやすいかも。
ユーザーは、ビジネス要求やユーザー要求を体系的に整理したものを要求仕様と考えがち。
ベンダーは、ソフトウェア要求仕様（SRS)を要求仕様と考えてることが多い。
イメージしている詳細度には雲泥の差がある。
>「プログラム設計書はシステムの品質向上に役立つわけではないですよ」
「見積もりも納期も最低３割増しになりますよ」とか言えばいいのに。
明確にトレードオフを認識させて、判断を迫らないと、どんどん圧がかかるだけ。
要求仕様もプログラム設計も、リスクや品質は文書化の度合いじゃなく、
対話の度合いに依るところのほうが、ずっと大きいと思う。
>ゆとりの法則だったかなぁ、デマルコの本でさ、
"ゆとりの法則"は読んでないのでわからないですが、"デッドライン"に『触媒のような人格というものがある。そのような人はチームがまとまって結束し、なおかつ健全性と生産性を維持できるようにすることでプロジェクトに貢献する。触媒の役割は重要で貴重である』というのがありますね。
デッドラインの触媒にあたる登場人物は、カスミさんとはイメージ違うかな。
組織の潤滑油になってるのは、間違いないと思うけど。
m
>メネメンさん
デットラインでしたか。ありがとうございます。記憶も曖昧になっているので、再読します。
仕様書が書けない発注元とコミュニケーションスキルが皆無に等しい、飛田クンみたいなベンダーが作り出すシステムってなんか怖い。
Zzz
無意味にチキンレースするさまは、端から見てる分には楽しいもんでありますな
嶺井あたりは天国ロード突っ走ってるつもりのようで、それがまた実に滑稽
まあ、自分の業は自分で得てもらいましょ
それと勘違いしてはならないのは、顧客の業績だの体制の効率だのは顧客自身が責任持って判断すべきことで、外野のエンジニアごときが口出しすることじゃない
ご提案()が精々で、飛田みたいにシステムに合わせろなんてのは傲慢でしかない
仕様書も欲しいと言うならくれてやれば良い 当然作成コストは頂く
また、東雲が出してきた仕様書に不備が発覚したなら、その手戻り分の延期も当然させてもらう
粒度がどうこう言い出す前に、合意を得ておく
どうせgdるのが目に見えてるなら自衛に徹するべきでしょう
馴れ合わなくなるということは、責任の在処が明確になるということです
さて、作中人物はこのことに気付いていますかね?
DEADBEEF
>馴れ合わなくなるということは、責任の在処が明確になるということです
>さて、作中人物はこのことに気付いていますかね?
トモコさんは馴れ合う相手が居なくなってしまうし、
嶺井さんは言い出しっぺだし、飛田くんも前に
「馴れ合いとか大嫌い」みたいなこと言ってた気がするし、
むしろドントコイな、皆が待ち望んだ展開でしょう！
みのわさんの認識が甘いような気もするけど、
スーパー飛田くんのがんばりで、みのわさんの出番はないはず。
あ、二次開発が始まる前に、今後の保守のためにも
一次の仕様書作っとかなくちゃ！
それはみんなでがんばろうね！
kawa
アイスコーヒーのない喫茶店
レイコーのない喫茶店
箕輪レイコのいない喫茶店
みたいな、そんな連想をしてしまいましたｗ
elseorand
今の時代ならプログラム設計書 == ソースコード
を目指すべきよね｡
開発から逃げた連中は､ソースコード恐怖症なのが多い気がするね｡
Scalaで英語風に､動くコード書いて見せたけど､
DSLという言葉を知らない不勉強さに驚いた物です｡
Javaですら多少のノイズはあるにせよ､
自然言語に近いコードがかけるのだから､
プログラムは訳の分からん文字列の集まりという前時代的な頭の悪さは､
勘弁願いたいよね｡
あ
そりゃ英語==訳の分からん文字列なんですから無理もない。
TKFM
嶺井課長が言わんとしていることはまぁわかるのです。
欠陥住宅をつかみたくない、みたいなものですし。
お上が出したガイドラインに準じる、という考え方もまぁ仕方ないかなぁ、とも思います。
ダメなシステムを避けるために、深い知識が必須であるならば、外部に開発を依頼なんかできなくなってしまいますし。
なのに、なんかこう、陰鬱な気分になってしまうのは何故なのでしょうね。
774
ああこんなフィクションにまで、お上のバカなIT行政のツケが回ってくるとは…
jairo
まあでも何か手を打たないと、CMMIでいうレベル1の組織が大半(俺予測)な現状は変わらないんじゃないかなぁ。
クリープ
弾幕薄いよ！何やｯてんの？！
自分はどっちかつーと機械屋だけど
ソフト屋さんは大変だねー…
K
jairoさん
経産省のシステム管理基準を守ってれば、現状変わるとは思えへんけど。
BEL
おおお、お役所文書ネタに触れてきたか。
これは結構前の文書だね。
つい去年も妙な文書出したしなあw
http://www.soumu.go.jp/main_content/000265403.pdf
Jairo
> Kさん
> 経産省のシステム管理基準を守ってれば、現状変わるとは思えへんけど。
全てがいいとは思えないけど、全てが駄目とも思えない。
K
jairoさん
たとえばどこらへんが駄目じゃないところ？
Jairo
> Kさん
本文の範囲で言えば、『プログラム設計書』の作成が必須であるように読めるところ以外で駄目なところはありません。
経済犯罪特捜部
＞今の時代ならプログラム設計書 == ソースコードを目指すべきよね｡
＞自然言語に近いコードがかけるのだから､
＞プログラムは訳の分からん文字列の集まりという前時代的な頭の悪さは､
＞勘弁願いたいよね｡
なるほど、COBOL のことを言っているだね。
歴史は繰り返すと言うからなあ。
IT統制を進めるのなら、ソースコード命の飛田は不適格だなあ
H&G社でドキュメント化をすすめるのに最適な人材は武田氏だよ。
少なくともIT統制でがっちがっちにするのなら、飛田は実装するコーダーに専念して、仕様書を作る人間が別に必要になる。
箕輪課長－武田－飛田
｜
カスミ
という配置になる。
へろへろ
＞箕輪課長－武田－飛田
＞ ｜
＞ カスミ
＞という配置になる。
東雲の開発やってるところで触れられてたけど、実装不可能な仕様を武田が量産して
飛田が切れ、「遊びでやってるんじゃないんだよー！！」と頭から突撃していく
未来しか見えないんですが（笑）
kawa
>飛田が切れ、「遊びでやってるんじゃないんだよー！！」と頭から突撃していく
確かに声優さんと名前は同じだがｗ
技術はこのIT世界をささえているものなんだ、とか言いそうですなｗ
しかしコメントのペースが落ちたのはさすがにみんな前回であきたのか。
n
仮想敵を勝手に作ってオナニーしてるコメントなんか誰も欲してないしこのままでいい
banban
情シスと接触のない人は今回のネタは関心がもてないということでしょうね。
ちなみにシステム管理基準にそって発注責任を霧島部長がもつ社内規則だってつくれるわけです。「情報処理管理課を通して発注しなくてはならない」の根拠がシステム管理基準というのは飛躍していると思う。嶺井課長には情シスはこうあるべきという理想像があるのでしょうね。社内でエスカレーションして調整せずに社外に内情を漏らして手を回すのは一種の場外乱闘で、嶺井課長と直属の上司で意見があっていないことを示していると見ました。
K
jairoさん
私にはウォーターフォール推奨、大手sier御用達の文章にしか読めへんかったですがね。
このシステム管理基準を遵守するなら単価は倍にしてもらわんとあきまへんわ。
メネメン
コードで表現できることを、ドキュメント化するのは無駄だと思う。
でも、コードで表現できないことも多々あると思う。
ドキュメントを、
コードを規定するものとして捉えるのか、
コードを補完するものとして捉えるのか、
その考え方の違いが重要だと思う。
「システム管理基準」についても、
プロセスを規定するものとして捉えるのか、
プロセスを補完するものとして捉えるのか、
その違いによって、扱い方が180度変わると思う。
前者はHowを追求し、後者はWhyを追求する。
プロセスが先か、人が先か。
「AかBか」。。。
kumamon
どっちかっていうとカスミさんな私は、会社辞めないといけないかな・・・と。この展開は、ちょっと辛いなあ。
カスミさんと違うのは、私にはまだ、向上心があって、新しいことにワクワクするし、新しいことができるようになりたいと常に思っていること。でも、理解力はどんどん落ちてるのを感じるし、スピード感ないし、気持ちに実態が伴ってなくて、焦るばかり。結果として、勉強しないとか、向上心ないとか、思われているんだろうなあ・・・。
カスミさんには、諦めないで、何らかの貢献ができるストーリーを期待してたんだけど、そういう期待をすることが、甘いのかもしれませんね
経済犯罪特捜部
＞しかしコメントのペースが落ちたのはさすがにみんな前回であきたのか。
IT統制まで話のレベルが上がると、コーディングなどの実装の話は下位要素の一つに過ぎなくなり、話の主眼が事業方針や経営レベルのお話になるからでしょう。
軍隊で言えば、現場の実装の話は二等兵から軍曹か、せいぜい少尉までお話で、IT統制になると師団長とか参謀本部とかの上級士官の「方針」のお話ですから、縁遠すぎてコメントしようがないというところではないかと。
Jairo
おやおや、ここまで自覚症状がなかったのか。
ねこ
>経済犯罪特捜部
軍隊でたとえられてもいったことない人ばっかなんだからわかんなくないすかね？
そういう風にたとえる人は確かによく見ます。
でも私にはさっぱりピンとこないんです。他の方はそうでもないのかな。。。
日本は比較的組織の下のレベルでも上のことを考えて仕事するほうかなと
思います。
いきすぎて経営者目線で考えろとかいう経営者もいますし、実際労働者なのに
経営側の見方してとことん社畜な人も多いですなー。
まりも
>軍隊で言えば、現場の実装の話は二等兵から軍曹か、せいぜい少尉までお話で、IT統制になると師団長とか参謀本部とかの上級士官の「方針」のお話ですから、縁遠すぎてコメントしようがないというところではないかと。
結論をうんぬんする前に、例えが悪すぎる。
二等兵が師団長の作戦についてコメントしないって？
そんなわけがないだろう。