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