ソフトウェア開発工程の国内標準規格制定へ 116
ストーリー by wakatono
本当に標準になるか？ 部門より
本当に標準になるか？ 部門より
DB-researcher曰く、"日本経済新聞の記事【経産省、ソフトの開発工程を標準化】（直接リンク禁止だそうなので、タイトルで検索してください）より。 ソフトウェアの品質向上を目指し、経済産業省はソフトウェアの開発工程の標準モデルを作るための専門機関を設立することを決めた。経済産業省周りでは２年程前から開発工程には注目していたようだが、このたび専門機関の設立へ向けて動き出すとの事らしい。富士通、ＮＥＣ、日立製作所、日本ＩＢＭ、トヨタ自動車、東京大学が参加することが決まっている模様。"
当該記事は IT BUSINESS & NEWS に掲載されている。いったいどんなもんになるのだろう…？トヨタが入っているのは「カンバン方式」の立役者だからかな？
現場では (スコア:4, すばらしい洞察)
Re:現場では (スコア:2, 参考になる)
私はXPのプロセスは積極的に取り入れるべきと思いますが、それをできるかできないかは人にかかっているわけです。できない人の組織だったら既存のままやってりゃいいんじゃないかと。
策定するにしても、とにかく柔軟性を確保しなきゃいけない。そんなもの作れるわけないし、なら策定する意味もあまりない。いくつかの方法論があってそれらが競争するっていう流れがあと十数年は続くと思われます。
（ソースコード管理ツール、オブジェクト指向言語を利用することを推奨、とはいろんな方面から言って欲しい気はますが。）
--
ところで、これを見て「アジャイルアライアンス」でググッてみると、
http://www.agileprocess.jp/
> トヨタの大野耐一氏によって実践されたかんばん生産方式は
> アジャイルプロセスの知識面および実用面の源となっています
ここでトヨタの名がちらり。
システムの統合も容易？ (スコア:2, すばらしい洞察)
>2004年度に産業界と共同で専門研究機関を新設し、ミスが起こりにくく効率の良い開発工程を確立し、標準モデルとする。モデルができればシステムの統合も容易になる。
という下りがあるんですが、どうしても「開発工程の標準化」と
「システムの統合が容易」とがつながりません。
誰か、分かりやすく説明してもらえるとありがたいです。
大本の経産省の発表か何かを見れば分かるのかもしれませんが...
大本の経産省の発表 (スコア:2, おもしろおかしい)
「大本営発表」に見えてしまったのは寝不足のせい?
個人的には (スコア:1)
＃専門職の方すいません
それよりも、個人的には巷でささやかれているデスマーチ [geocities.co.jp]が
減るのかということに興味が(ぉ
＃＃関連企業ではないですがあの状況はあまりにもかわいそうだと思うのでID
-----
スケーター12号〜(┌ ┌ ┌ ´Д｀)┘
問題無い。 (スコア:2, おもしろおかしい)
他の職種の方にも正確に説明できるようになります。
もしかしたらスケジュールに明記されるようになるかも知れません。
ってヲイ！
Re:個人的には (スコア:1, 参考になる)
開発工程の良し悪しには関係ありません
まさに気づくとデスマーチという表現が正しいでしょう
ちなみに目端の利く（大抵できる）ヤツは、とっくに
脱出成功している為、状態は急激に悪化します
ちょっとだけデスマーチなどが存在しないのはこのせいです
Re:個人的には (スコア:1)
いえ、デスマーチが標準化されます (-_-;;;
直接リンク禁止 (スコア:1)
とりあえず (スコア:2, すばらしい洞察)
＃リンクはお断りされたり、お願いしたりする物じゃ無いと信じているのでIDで、、、
Re:とりあえず (スコア:1)
もともとそういうつくりだったはずなので直リンクできないみたいですね。仕様変更すると莫大なコストがかかりそうですが...
ソフトウエア・エンジニアリング・センター (スコア:4, 参考になる)
経産省、ソフトの開発工程を標準化――設計図や用語を統一 [nikkei.co.jp]
でしょう。
それからIT PROの：
政府がソフト工学の研究機関を設立へ [nikkeibp.co.jp]
も参考になると思います。
30億・・・。 (スコア:3, すばらしい洞察)
>富士通、ＮＥＣ、日立製作所、日本ＩＢＭ、トヨタ自動車、東京大学
って一番ノウハウ持ってそうな独立系ソフトハウスとかまったく入ってませんね・・・。（汗
しかもなんでトヨタが。（汗
＃唯一期待できそうなのはIBMぐらいか？
それより
>来年度予算の概算要求に新機関設立の経費、30億円程度を盛り込む。
って・・・標準化ってだけでなんで30億も？いらねーだろ。
新たに天下り先を作ろーっていう官僚の匂いがプンプンするんですが・・・。
Re:30億・・・。 (スコア:2, すばらしい洞察)
仕事を投げる先で共通化定型化を推進するという、ごくあたりまえの話
Re:ソフトウエア・エンジニアリング・センター (スコア:1)
つっこみ＆フォローありがとうございますm(_ _)m
＃やられたぁ
実は普段から組み込み系のユーザ企業として無理難題をふっかけ、開発工程をぐちゃぐちゃにさせている（と心配しています、本当です）張本人なので、この手の話はとっても気になる＆参考になります。
今や有りとあらゆる物がソフトウェアを介して動いている、といっても過言ではないのでこの辺をきちんと系統立てて整理しておくのは大事ですね。自分は、ばりばり機械工学系のものの開発に携わっていますが制御は完全にコンピュータになってはや幾とせ、、、
＃先週もバグ取りはあとで良いからとりあえず納入しろ！＃なんて事があったけどIDで、、、
Re:とりあえず (スコア:1)
何でこういうケチなことするんだろうねえ。
ケチ (スコア:1)
同じ日経でも日経BP社のBizTech [nikkeibp.co.jp]は、 「連絡してちょーだい」とは言うものの基本的にOK。 [nikkeibp.co.jp]
この違いって、どこから来るんだろう？
BP社は印刷物メインの出版社だけど、 ネット経由のニュース提供も売りにしてる（そこから本や雑誌の購入に結びつけてる）のに対して、 そういう発想がない?昔からの新聞社って、やっぱりご多分に漏れず、 頭が固くて古くて高飛車でケチな体質（これじゃ最悪）なんだなって思うのは偏見かな？
# ナニヲイマサラ。だから?新聞を買わなくなってもう幾年月。
fujitsu (スコア:1, すばらしい洞察)
を何とかしろよ＞富士通&日立
NECさんはわりとしっかりしてて、受注する方も安心なので
ノウハウの放出は歓迎。
あんまり具体的会社名は書かないで欲しい (スコア:1, すばらしい洞察)
# もうね、AC以外でこんなこと書けません
Re:あんまり具体的会社名は書かないで欲しい (スコア:1)
だって、自分とスラドとの間を断ち切ったって、残りの世界中の人々とスラドとの間を切れる訳じゃないんだから、
単に自分の耳をふさいだだけ。
＃だからっつーてスラドの口封じに出られるのも困るが。G7としては。
Re:あんまり具体的会社名は書かないで欲しい (スコア:1)
Re:あんまり具体的会社名は書かないで欲しい (スコア:1)
Re:fujitsu (スコア:1)
U=UNISYS
ここは特に独自用語のオンパレード。
印書とか言うか？普通
Re:fujitsu (スコア:1)
Re:fujitsu (スコア:1)
written by こうふう
Re:fujitsu (スコア:1, おもしろおかしい)
Re:fujitsu (スコア:1)
三菱なら MELCOM とかで M では?
Re:fujitsu (スコア:1)
Mだとモトローラになってしまうんですね。
# 元M206使いだったのでID
----tm-hal-----
我々はM$だ
お前達の知識と技術を吸収し、お前達の企業を買収する
抵抗は無意味だ
Re:fujitsu (スコア:1)
コメントアウトの反応、すいません。
私も昔、富士通のプロジェクトでSDEMなるドキュメントフォーマットを使ったことがあります。と言っても、私が担当したサブシステムはパッケージを使っての構築だったのですが、SDEMで定義さているフォーマットに適当なドキュメントが一つもありませんでした。
だから、私の参加していたサブシステムは「ヘッダーだけSDEM」の独自フォーマットで設計書を書いていました。
初めは富士通に「作って」といっていたけれど、一向の出てこないので痺れを切らして自前で作ることになりました。
こういうことしても、はたして「SDEMに則った」といえるのかな。
これって日本版CMMの話? (スコア:1)
いま話題のCMMとは何か? [atmarkit.co.jp] ("いま" と言っても "当時" だが...)
いちだいこっかぷろじぇくと (スコア:1)
＃30億なんて、はした金？
架空戦記的発想？ (スコア:1)
おそらく直接の契機になったと思われる金融機関の統合によるシステム障害などのケースなどでは、開発工程に入る以前での問題が相当に大きかったような気がするのですが。
よく言われることですが戦略の失敗を戦術で挽回することはできません。今回のプロジェクトはあくまで『戦術レベル』での改良であって、状況は多少はマシになるかもしれませんが、結局それ以前の戦略レベルでのドクトリンの見直しと意識改革が行われない限り、大きく好転はしないでしょうね。
関係者がこれでほんとにどうにかなる、と思っているのだったらそれは『戦艦大和がミサイルを積んでいればアメリカに勝てた』というのと同レベルでしょう。
#まず最初に人月以外のコスト算定方法を開発すべきでは。
Re:架空戦記的発想？ (スコア:1)
前提が違いますよ。
SDEM準拠のドキュメントを書かされた人が居るように、
参加各社は既にプロセス標準を持っています。
ですので、使えない標準プロセスが出来ても、
使わないか、使う前からヘンテコリンだったかのどちらかになると思います。
「カンバン」じゃなくて (スコア:1)
「かんばん」が正しい表記です。
田舎のLinux野郎
結局 (スコア:1)
SPI活動 (スコア:1, 参考になる)
結局のところ，CMMがある程度そうであるように柔軟性を持ったものじゃないといけないわけで，XPにしてもCMMにしてもがちがちになっていないのはそういうわけだと思います．
で，SECでやろうと考えていることはまずSPI活動が必要であるという認識を植え付けることとそのための技術移転，テーラリング手法やある程度共通化されたプロセス基準なんじゃないかなと．
件の検討委員会の資料を目にする機会があったのですが，標準化されたプロセスを作って終わりというわけでなく，柔軟性を持ったプロセスの策定，プロセステーラリングガイドならびに各企業，あるいは各プロジェクトでの適用方法の研究開発，およびソフトウェア開発者の教育と各レベルに関して産官学連携で進めていくことが目的のようです．
まぁそんなにうまく行くかどうかは別として，./の中でもSECの意義に関して位は前向きな理解が進めばなぁとAcademicな立場としては思います．
SPI活動は絶対に必要なものだという意識自体が現状ではなさすぎますよね・・（ここのコメントでもそんな意見がちらほら・・）．
工業製品の開発工程は？ (スコア:1)
工業製品の場合、厳密に決まってるのは「開発工程」じゃなくて
「量産工程」のほうのような気がします。
で、開発工程の標準があるのかな、と疑問が。
工業製品の場合、新製品を開発した後、それを一定品質で量産する
体制が重要なわけですが、ソフトウェアの場合は、量産するのは
コピーで済むのでそこが無い。
工業製品その他にしても、品質を維持できる量産工程は
厳密であっても、新製品の開発の際にはやっぱり試行錯誤
して時にはデスマーチに近い波を経験したりしてんじゃないかな、
とか勝手に想像してしまいました。
--------------------
/* SHADOWFIRE */
Re:工業製品の開発工程は？ (スコア:1)
いわゆる"トヨタシステム"は、自動車の新製品開発サイクルの
マネジメント手法です。
開発工程を可視化・定量化して、新製品の市場投入の迅速化や
品質向上やコスト削減に大きな成果をあげています。
（一方、かんばん方式のほうは生産工程の話）
私は、ソフトウェア業界でこのような高度なマネジメントを行っている例は
あまり聞いたことはありません。
ただ、製造業の分野でも、いくら定量化出来ると言っても、
全く別次元の新技術に取り組む開発の場合には、ご指摘の通り、
試行錯誤やデスマーチに近い波を体験しているようです。
（例えば、燃料電池車開発とかでしょうか）
そのため、自動車業界では、このような次世代用の新製品開発は
時間を掛けてじっくり整えてゆきます。基本的に。
一方、ソフトウェア業界では、技術革新が速すぎるからなのか、
車で言うと、ガソリン車->燃料電池車の置き換え並のリスクプロジェクト
（例えば、他社構築の汎用機のシステムを、Linux+Javaに置き換えとか）
を平気で短期・少人数で、組織体制や情報が整わぬまま請け負って、
死の行進を始めてしまっているような印象。
Lean Development (スコア:1)
>あまり聞いたことはありません。
日本では有名でないようですが、アメリカには
Bob Charetteさんが提唱するLean Developmentで
かんばん方式をソフトウェア開発に適用しようとしているようです。
解月手法 (スコア:1)
XPやリファクタリング等の言葉(内容はまぁ、深く追求しないで)が
ちまたにあふれ出しているのは今までの企業のウォーターフォール
開発形式が実際には全然動きが悪すぎる証明でしょう。
キーパンチャーが多すぎてプログラマーが少ないのは
上記開発手法の弊害ともいえなくはない。
…ちなみにNECもひどいとおもいまふ(^^;;;;
kusanagi shin
Re:昔、某社の場合 (スコア:1)
結局、フィードバックというか戻りというかの存在を認めないと、
ソフト開発って、どうにもならないよねー。
仕様書を自分の頭で考える段階で、CPUなみにバグ出しを出来るほどに
高速かつ「愚直(気を利かせて「正しい」処理をやってしまっては無意味なので)」な思考形態を
持っている人が居るならば話は別なんでしょうけど、
少なくとも俺はそんな地球人を見たことがないです。
たぶん本当に居ないんでしょうね。
Re:トヨタ (スコア:1, 参考になる)
出さないようにするためです。
ただトヨタが他と異なる所は、リリース後のバグ修正の費用が予算とし
て組まれている所です。他なら瑕疵責任で無料で修正せにゃならん所で
すが、トヨタの場合お金が出ます。
しかし、そのお金が孫受けや曾孫受けまで下りてくる事は稀です。
Re:トヨタ (スコア:1)
叩き台をタダで作らせないで欲しいって程度じゃ甘いモンです。
Re:３０億かけて… (スコア:2, すばらしい洞察)
関係省庁も、いまどき流行りのアレゲな言葉を並べられれば、面目も立つってモンですよ。
さて、メーカーが集まって何を相談するか。
金にならないから今まで手をつけなかった、ドキュメンテーションの作成を
社内失業者にやらせる方法について、あたりなんじゃないだろうか。
Re:プロトタイピング技法って (スコア:1, 参考になる)
たとえ客がこれで十分だと言っても
納品したら後でエラいことになりそう。
Re:プロトタイピング技法って (スコア:1)
出来たものはそれなりに使いものになる…
という状況を実現することが(だけではないが)目的である処のモノを、人はライブラリと呼びます。
というわけで、仕事の合間を縫って(^^;、ライブラリをしこしこ作り置きしとくわけです。
＃「究極のライブラリは、言語(が必要ならば作ってしまうこと)である」という意見はそれなりに真理だと思うので、G7
＃まあ流石に言語仕様から作るのはシンドイし、既存の優良言語を流用すればそれで済むことが大半なので、rubyなりなんなりのbindingを作るくらいのもんだけど。
RADを実現するには、足回りを慎重にキッチリ作っておかないとならない(使い物にならない)んだよね。
＃そういうものを作る暇すらないプロジェクトがデスマである可能性は高いと思うので、G7
Re:すごいなぁ(^^; (スコア:1)
所詮、厳密な(仕様書の)デバッグ能力を持つわけでもない人間という生き物が押すハンコなんて、
技術的な裏付けに欠けたものなんです。
ハンコを貰えた仕様書だからって、それを実装して旨く行くかどうかなんて、誰も保証できない。
で、「ハンコ貰った後なんだけど、やっぱ不味いって判ったので、直してください」と言うと、
「ハンコ貰ってんだぞ？今更直せると思ってんのか？」としばしば返事される、
という点が問題なんだと思います。
技術的裏付けよりもハンコのほうが大事にされとるわけです。
こんなんで「良いもの」が作れるわけないのは、子供でも直感的に理解できるんではないかと。
＃こんな親を見て子が育ってしまったら不幸だろうなのG7
ついでに言えば。
それまでずっと計算機の中のデータだったのに、ハンコを押すためだけに数百ページのその仕様書を
プリントアウトさせる、って制度は勘弁してください。
どうせ、OKなら永遠に仕舞いこむだけだし、駄目ならすぐにシュレッダーにかけるだけなんだからさ…
Re:すごいなぁ(^^; (スコア:1)
>ハンコを押すためだけに数百ページのその仕様書を
>プリントアウトさせる、って制度は勘弁してください。
ハンコが押してある事が最重要なら,
CD-Rなどのライトワンスの媒体に記録して,
媒体にハンコを押してもらうようにするとか...
間違っても記録面にハンコを押さないように(^^)
Re:すごいなぁ(^^; (スコア:1)
いやいや、うまくやれば味方にできます。
検査成績書に判子を押させれば勝ちです（笑）
後で問題が出ても「判子戴いてますから」で済みます。
十数年前に関西方面の某電力会社から仕事（プログラムではないけど）を定期的に貰ってたことがありますが、突然検査成績書に判子ではなくサインをするようになりました。
原因はどこかので納品後のトラブルに対する処理を判子を理由に揉めたかららしい。
サインだったら「日本人だから責任はない」そうで (-_-#
Re:すごいなぁ(^^; (スコア:1)
あるいは、筆跡鑑定でもめないように、金釘流でサインするとか、脅迫状ばりに新聞の切抜き文字でサイン(?)するとか..。