/.Jに聞け：経産省のシステム管理基準、使ってる？ 133
ストーリー by hylom
時と場合に応じてか、それとも 部門より
時と場合に応じてか、それとも 部門より
あるAnonymous Coward 曰く、
私はベンチャー企業のエンジニアだ。先月、元請け企業の営業マンからこのように言われた。
顧客のユーザ企業のシステム部門担当者が、御社は当然経産省のシステム管理基準に基づいた開発をやっているんだろうね、と言ってきた。確認しますと答えておいたが、もちろんおたく（うちの会社のことだ）は、経産省のシステム管理基準を遵守してるんだろうね。
そのようなものを見たこともなかったので、早速検索してみて驚いた（経済産業省の情報セキュリティ対策ポータル）。あまりにも曖昧で抽象的な言葉が並んでいたからだ。
４．プログラミング（４）
（1）プログラム設計書に基づいてプログラミングすること。
（2）プログラムコードはコーディング標準に適合していること。
（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
（4）重要プログラムは、プログラム作成者以外の者がテストすること。などだ。いまどきプログラム設計書など作ったことなどないし、納品物として求められたこともない。そもそもプログラム設計書とは何を指すのだろうか。少し大きめの業務システムならクラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ、と言っているのだろうか。
世の中のシステム会社は、本当にこの管理基準に従った開発をやっているのだろうか？
テスト (スコア:3)
建前からいえば、設計書がないと出来上がってきたものが正しいか第三者が客観的に判定できないということで、大手のSIerあたりでは多分今でも、要求仕様書を書いてそこから統合テスト項目を作り、外部(機能)仕様書を書いてそこから結合テスト項目を作り、内部(クラス)仕様書を書いてそこから単体テスト項目を作ってから開発に取り掛かってると思います。そして開発が一応終了したら、それぞれのテストをテスターないし開発者自身が人力で実施してエビデンス(スクリーンキャプチャを格好よく表現した言葉)を収集するか、あるいはテスト項目を実装した自動テストを作って流しているはずです。
このやり方は、品質保証という面で一定の効果はありますが、革新的なソフトウェアを時代に遅れずに迅速に作ろうとしたら効率が悪すぎますので、ベンチャーはこんなことはしないしできないしすべきでないでしょう。大手SIerの開発コストが嵩む理由の一つであり、またそういう企業から面白いソフトが生まれない理由の一つです。
この会社はどうやって開発しているのだろうか (スコア:2)
どうやってソフト開発をしているのか知りたいところですね。
ソフトウェアはモノ作りと違って形がないから、設計図で意思を確認するという分けにはいかないので、
言葉は非常に重要です。
その言葉が何を意味しているのか、共通認識を持たないと誤解が生じます。
そういう意味で共通フレームなどがあるわけですが、設計書なしで打合せや、承認、メンテナンスはどうする
つもりなのでしょうかね。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
文脈からプログラム設計書＝詳細設計書という解釈なのでは？
#システム管理基準内での文脈はまだ見てないので違うかもしれんけど
それなら、詳細設計書Firstというのはないかなあ。テストおよびデバッグにすごくコストがかかる場合に限ってはありだけど。
ふつー、ソースとコメントから自動生成だろ。
>設計図で意思を確認するというわけにはいかない
いやいや、設計図（仕様書）以外に意思（機能の目的）を確認する媒体はないでしょうに。
>設計書なしで打合せや、承認、メンテナンスはどうするつもりなのでしょうかね。
打ち合わせ：すべては口伝で受け継がれる
承認：誰もそんな事はしない。すべてはあるがままに。
メンテナンス：生贄を差し出し、擦り切れるまで使う
でも、まあ通常の知能があれば、設計書とは呼んでなくても設計書のようなものは自然発生すると思うけどなあ。
Re: (スコア:0)
Re:この会社はどうやって開発しているのだろうか (スコア:2)
データ関連図やデータ構造のグラフって, ソフトの設計図じゃないのかな? シーケンス図みたいなので各種の挙動の設計をするってのも多いだろうし.
コード化以前にそうしたレベルでのイメージを整理しておかないと, コーディングの途中で混乱して効率が悪いんで, 自分のために描くようにしてるんですけど.
Re: (スコア:0)
設計図・設計書・仕様書の違いは何だろう。
設計図は図面、設計書は文章の違いだと思ったんだけど。
設計図だと材質とか加工方法とか目的より手段。
仕様書→計算書→組図⇔部品図
かな？
学校でしかやったこと無いので実際は知らないけど。
＃取説とかの仕様の入った図面は設計図から起こした設計図ではない説明図やメンテ図だよね？
Re:この会社はどうやって開発しているのだろうか (スコア:5, 興味深い)
うちのチームでは
システムの仕様書は「何ができるのか」
システムの設計書は「どういうふうに作られているのか」
を書くものだと定義しています。
外部設計書・内部設計書というふうに分けると、微妙にずれるところが出てくるのですが、概ね外部設計書が仕様書、内部設計書が設計書に相当するかなと。
このとき、特に重要な部分については事前にクラス設計とか処理方式程度まで含むドキュメントはつくるので、その基準に合わせるときにはそれに「プログラム設計書」という名前をつけてますね。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
私のイメージではプログラム設計書っていうのは
コード1行と1対1で日本語が書いてあるドキュメントですね。
行間の情報はあまりありません。
じゃぁコード書けよっていう代物です。
# イメージっていうか実際にそういうの見たことも作ったこともあります。
# 日本語でコード書いて、プログラマーという名の翻訳者がコードに書いていき、それが終わるまではプログラムを実行してはいけません。
# ちなみに 詳細設計書とかオブジェクト関連図みたいなものは別でありました。
Re: (スコア:0)
小規模ベンチャーだから大規模・大人数の開発経験が無い。
もしくはプログラム設計書という言葉に対して思い描いてるものがずれているか。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
書類がなんでも仕様書になってる会社ばかりではないことをご理解頂きたく。
－以上－
Re:この会社はどうやって開発しているのだろうか (スコア:2)
Re: (スコア:0)
書類の必要は無い。
メールでもいいから機能要求が書いてあれば仕様書とみなす事が出来ます。
口頭の場合は内容をメールで送って確認するのが一番安全。
Re: (スコア:0)
たとえば、Google Chromeとか、MySQLとか、設計書の存在が怪しいプログラムが世の中の大半だと思うんですが。これらの開発者が全く打ち合わせせずにプログラムを書いているとも思えませんし。
Re:この会社はどうやって開発しているのだろうか (スコア:4, 参考になる)
Google Chrome (Chromium) に関しては Design documents [chromium.org] というのがありますよ。ハイレベルなデザインはやはり文書に仕立ててレビューしてもらうみたいです。
Re:この会社はどうやって開発しているのだろうか (スコア:1)
コードがテストを通ったけど Design Doc が無くてコミットできない、とフォローしている Chromium 開発者が泣いてたっけ。
Design Doc がないとセキュリティレビューに支障があるためらしい。
Re: (スコア:0)
作りながら直して、また作って、ということをした時の
細切れドキュメントを設計書として認定してくれるのであれば
設計書は存在すると思うのですが、
往々にして要求されるものって差分の積み重ねを認めてもらえなかったりするんですなぁ。
元請企業からの要求を記録したものが設計書 (スコア:2, 参考になる)
この場合は、元請企業からの要求を記録したものが設計書にあたります。
記録したものが無い場合は、後からでも記録したものを作成し、元請企業に承認して貰って置いた方が良いです。
元来、顧客企業側は、開発管理を行う部署が基準に基いた管理を行っているかどうかを聞いているのです。
これは、下請企業に確認するものではなく、元請企業内で確認するものです。
このような、元請企業と仕事をする時には必ず、要求内容の記録と承認を忘れない様に注意が必要です。
なお、出来れば、開発管理にまで手を伸ばせば、あなたの会社の立場が逆転する可能性もあります。
（元請側としては頼んでおけば勝手に管理してくれる有難い下請と認識です。）
ISO9000認証企業が元請ならば、こんな事がないのに．．．ぶつぶつ．．．
おいおい (スコア:2)
まさか設計書があったからって設計書通りに作られてるなんて思ってると痛い目をみるよ
# 仕様書とか設計書はあんまし信用してないんだ・・・
そもそも元請けのフォーマットに合わせる (スコア:1)
という場合の方が多いんじゃないの。
であれば「書式を頂ければそれにあわせます」
と答えればOKじゃないだろか。
設計書ねぇ... (スコア:1)
某社の入社試験にプログラムの設計があったんだけど、例見て唖然。
要素がオブジェクトでもステートでもない絵だったよ。
こんなもん何の役にも立たねーだろと思いつつ(ry
そういうのでも設計書になるのかな？
Re: (スコア:0)
開発で飯を食ってるところから言えば、そういう設計書とか仕様書は
客を満足させるためのものであって、それが開発に絶対必要か？と言われればNOですね
最終的に納品して金をもらう時にお客は要求するときもあるし
会社がこういうものを作ったよ、という証とみたいなもので瑕疵かどうかの
線引にも使われるのでそんなものでも設計書になるんです
＃そんな設計書でもそれを出して客に「仕様です」と言えるならそれはそれで必要でしょ？
こういう人がモノ作っちゃダメ (スコア:1)
少し大きめの業務システムならクラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ、と言っているのだろうか。
</blockquote>
知識や経験が足りない点はしょうがない。
しかし、「いちいち～」のくだりは完全にNGだろう。
”面倒くさいから作らない・やらない”といった意識が見え隠れしている。
開発や製造といった業務を担う資質に欠けているとしか言いようがない。
面倒くさいからこそ、いちいち作っていちいち精査して、精度の高いものを作っておく。
小規模開発で手抜きするとこが、それ以上の規模で高精度に開発できるわけがない
と言うだけなら言えるけど、それが実際にどこまで実施できているかという点が問題なんだよね。
Re: (スコア:0)
クラス単位の設計書なんてもう十年以上前からソースから自動生成するもんでしょ。
人の手で作るのは機能単位の設計書までですよ。
仕様書なんて (スコア:1)
仕様書というもの,
Doxygenとかでコメントから生成したことしかないけど,
それは仕様書に基づいて書いてるという事になるのかな?
Re: (スコア:0)
そのコメントをまとめた物が設計書でしょ。
Re: (スコア:0)
じゃあ、先にコメントを全部書いてからコーディングを始めればいいだけですね！
Re:仕様書なんて (スコア:1)
いや、まずテスト書こう。
Re:仕様書なんて (スコア:1)
よし,めんどくさいからプログラムでC言語に変換しよう!
~数カ月後~
日本語プログラミング言語｢さくらこ｣を公開します
Re:仕様書なんて (スコア:1)
その昔、CをCOBOLへ変換してくれるコンパイラがあってだな...
#何処ぞのメインフレームだったと思うが記憶が曖昧
総務省だかどっかの行政法人だったか覚えてないけれど (スコア:0)
プログラミングについての要件をかなり細かく砕いたガイドラインを
去年だか一昨年に発表してなかったっけ？
要約すると (スコア:0)
誰かの頭の中に依存するような開発はしていないか？
かな。
フォーマットを定義しているわけではないから、スケッチでも、それに基づいてプログラムしたなら、ドキュメントとして残しておけばいいだけでしょ。
設計書は必要だが (スコア:0)
こんな2006年に出たっきり何の改訂もされていない時代遅れの基準なんか参考になるもんか。
いまだにウォーターフォールで大規模開発やってるITゼネコン向けだろ。
大きさによる (スコア:0)
> クラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ
うん、この程度のたかの知れた規模のシステムなら
設計書つくらなくても OK だと思うよ。
Re:大きさによる (スコア:1)
> クラス数が1000や2000を超えてしまうだろう。それをいちいち設計書を作成せよ
作ればいいじゃん。自動でな。
馬鹿正直に事前に全て用意する必要もないし。
馬鹿正直に事前に作るとしても、実際は開発途中の修正を容認しないと回らんでしょ。
#存在自体がホラー
Re: (スコア:0)
そのとおり
それなりに参考になる (スコア:0)
(1)はともかく(2)(3)(4)はそれなりに意味があると思います。
少なくともうちはできてません。
この程度の曖昧な基準でさえ守れない会社がたくさんあります。
コンビニのマニュアルと同じで外国人や理解に時間がかかる人でもわかるようでないとだめなのでしょう。
経産省云々の話以前の問題として (スコア:0)
元請けの営業から、下請けのエンジニア直に話が行くの？
自社の営業でもやばいのに、元請けの営業から話が来るとか余裕で死ねそう。
テスト結果 (スコア:0)
（1）プログラム設計書に基づいてプログラミングすること。
→ ありえん。んなもん書くか、今どき。
（2）プログラムコードはコーディング標準に適合していること。
→ まあ、これはある。
（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
→ 評価？コードレビューをしろってことか？で、それを保管するの？そんな暇がどこにある。
（4）重要プログラムは、プログラム作成者以外の者がテストすること。
→ エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
結論
→ 75% ぐらいは非現実的。しょせん、お役人の考える基準なんてこんなもんだ。
Re:テスト結果 (スコア:2)
>（3）プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
> → 評価？コードレビューをしろってことか？で、それを保管するの？そんな暇がどこにある。
最近はコードレビュー支援ツールというのがありまして....。
時間的拘束も場所の制約もなく、自動で記録もされて指摘事項もDB化されるのなら、
それを前提としたスタイルもありなんじゃないかなあと思う。
#存在自体がホラー
Re:テスト結果 (スコア:3, おもしろおかしい)
エクセルに流しこめばいいんじゃね？
まあ、どうしようもないフォーマットってのはあるけど、融通は効く事が多いでしょ。
いや、そうでもないか。表があるなと思ったら、全部テキストボックス貼って作ってあったとか....悪夢だ。
#そこまでひどくないけど、今、それに似たドキュメント触ってるんだよな....
#存在自体がホラー
Re:テスト結果 (スコア:1)
ある程度以上の規模のプロジェクトなら、ソースコードのクロスレビューと結合テスト以降のアジェンダを残すぐらいは普通にやるだろう。
というか、やっとかないと問題が起きたときにテストをしたしないとかで揉めて酷いことになるし。
Re:テスト結果 (スコア:2)
ですよね。
成果物の品質保証を「暇がないから無理」はちょっとどうなんだろう…
Re: (スコア:0)
>（4）重要プログラムは、プログラム作成者以外の者がテストすること。
> → エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
その通り。
弱小ベンチャーは開発請負などをすべきではない。
よくわかってるじゃないか。
Re: (スコア:0, おもしろおかしい)
え、専任のテスターとかいるよね普通。
Re:テスト結果 (スコア:4, 興味深い)
うちは、請負のプロジェクトごとには専任のテスターはおかず、
（システムテストは）複数のプロジェクトに対してテスト専門のチームがテストする体制にしてます。
テストツールとか、エビデンスの作り方とかを共通化・効率化したいので。
たくさんバグがみつかるとテストチームにご褒美、見つからないと開発チームにご褒美ですね。
Re:テスト結果 (スコア:1)
いません。会ったこともありません。
そういう人種を抱えられるのは、大手エスアイヤーだけです。
弊社のような吹けば飛ぶようなソフト会社では、設計からプログラムからテストから保守まで、全部ひとりがやるんだよ。
もちろん経産省のなんたらは見たことないし、遵守しろと言われても無理な話なのは言うまでもない。
理想と現実は違うんだよ。
#さ、自虐モード終了
Re:テスト結果 (スコア:1)
男は一歩外に出ると7人の敵がいる
ソフトウェアは一旦外に出ると千人のテスターがいる
#という気持ちでリリース
Re:釣堀 (スコア:1)
このソースは俺の嫁！！
#離縁したい....
#存在自体がホラー
Re:まず、先の仕様書とか設計書については (スコア:1)
ウォーターフロー開発
設計 ← 試験 → 設計
↑ ↑ ↑
製造 ← 納品 → 製造
↓ ↓ ↓
試験 ← 設計 → 試験
Re:営業トーク (スコア:1)
そちらでXXまでに確認・最終承認していただいての完了となります。
それが遅れると、納期がさらに遅れますので
スケジュールの調整お願いしますね。」