- - PR -
「プロジェクト成功のキーポイント」投稿室
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2001-09-26 12:47
今回の記事が面白かったので、ふと会議室を覗いてみたら、濃い話題が・・。お邪魔します。
私の周りでは、まだ繰り返し型の開発を行っているところを見たことがありません。 逆に、「設計書はあとでいいからとりあえずコーディングだけ進めて」という要求はかなりよくあります。笑 これ、どう考えてもおかしいですよね・・・。 「クラス図は後から作ればいいから」とか、言ってる意味わかってるのかなぁ、とか思ってしまいます。 結局、プログラマー側で分析レベルからやりなおし、自分でこつこつとクラス図から起こして、足りない日数は土日や深夜を使ってコーディングをする、という悲惨な状況です。 しかも、コーディングもだいたい終った頃に「これを使ってください」と、オブジェクト指向のカケラもない自称「共通ライブラリ」を渡されて、どうにもソースに組み込めずに死にそうになる、とか・・・。 と、まあ、それはともかくとして、今回の記事の「モデリングの大切さ」はとても共感できました。 先日、私の同僚が元請けの会社へ出かけて、今回のプロジェクトの「シーケンス図」を渡されたそうなのですが、そのシーケンス図がかなり酷いものだったそうです。 まだ分析段階なはずなのに、「画面生成クラス」というものが登場し、「○○処理」というクラスと通信していました。クラス図を見せてください、とお願いしたら、「まだ出来ていません」だそうで・・。 で、それを同僚が突っ込んだら、「あなたはオージス総研のＵＭＬシルバーとか持ってらっしゃいますか？」と言われ、持ってなかった同僚は話を聞いてもらえなかったらしいです。笑 ちなみに彼らはブロンズレベルを全員持っていたそうです。 私はシルバーをこないだ取得したのですが、確かにブロンズレベルは単なる「記述方法」のレベルなので、モデリングという観点からはあまり役に立たないのかもしれません。 その後、友人はブロンズレベルをソッコーで取得していました。笑 （残念ながらシルバーは落ちたようです） | ||||
|
投稿日時: 2001-09-27 17:01
第3回、な〜んかちょっと違うような気も。
「仕様とJavaコードを直結して考えるのは危険」かな。 モデルをがっちり決めてしまうことは諸刃の剣で、実装段階に入っているのに、そのモデルを理解していない顧客がモデルを崩してしまうような仕様変更を要求してくることはままある気がします。そしてモデルのなかに「例外」が発生し、コーディングは泥沼の様相を… なんてことにならないために、モデルを考える時点で - 要求仕様 - 潜在要求仕様(顧客が仕様変更する可能性がある要求。口先は信用できない:b) - 実装言語の特性に応じたものであること - 潜在要求仕様が出てきても対応できるようにすること を考えておかないといけないのでは。おそらくこれが「上手なモデリング」であって、これをできるためには、顧客の業務要件全般に造詣が深いだけでなく、実装言語の特性を知っており、抽象的なモデルの考え方ができるといった能力が必要になるでしょう。 うまい職人的プログラマは、この後半部分を無意識に行なっています。事実上、仕様をみながら、クラス階層図(まぁUMLと同等と思ってもいいかも)を思い浮かべ、具体的な実装ではなくAPIから作っていくでしょう。 Javaで作るっていってんのにC/S系COBOL実装みたいなモデルっぽいものが出てきて、なんだよこれっていうことはまぁよくあることで。 # 余談ですが、「定跡」ではなくて「定石」では？ # 例で挙げられている図がほぼ単なるERDになっているような気がするのは私だけ? | ||||
|
投稿日時: 2001-09-27 22:37
単純に言えば”設計をすること”と、それを”表記すること”の違いですよね すごく単純な例えは Javaの構文を知ってるだけでプログラムは作れない人と プログラムの基礎はきちんと押さえて、Javaの構文は知らない人 の違いって感じですか・・・ご愁傷様です。 | ||||
|
投稿日時: 2001-09-28 12:07
しょむさん、こんにちは。宮下です。 まず、「定跡」ですが、将棋の場合は「定跡」、囲碁の場合は「定石」と 使い分けるようですよ。 さて、漆原さんの記事に関するフォローです。 まず、この記事でいいたいことのポイントは２点あると思っています。 １点目は、ユーザーとのコミュニケーションを円滑にするためには共通語が必要。 そのためにモデリングをするんだということ。 ２点目は、設計のアウトプットがJavaコードに確実にマッピングされる スタイルを確立していれば（ここの部分、大昔SEをやっていた私としては 夢のような話なんですが）、ユーザーから仕様変更の要求が来た際に、 毎回モデリングからやり直したほうが早い。という点だと思います。 （ウルさんでは、RUPを使ってこれを実現しているようです） ただ、たとえばありとあらゆる案件でUMLが使えるかといったら そうでもないと思うので（漆原さんに怒られちゃうかな）、 いろいろな議論が出てきて良いと思っています。 ここから皆さんへ： お出しいただける範囲で、できるだけ具体的な事例を前提に議論が展開できると、 よりこのスレッドが面白くなってくるのではと思っています。 皆さん、どんどん意見を出してみてください。 [ メッセージ編集済み 編集者: tom 編集日時 2001-09-28 17:35 ] [ メッセージ編集済み 編集者: tom 編集日時 2001-09-28 22:17 ] | ||||
|
投稿日時: 2001-09-28 13:25
漆原です。
いつのまにやらBBSで議論が・・・ありがとうございます。 ようやくBBSにデビューする間がとれました。 この連載「プロジェクト成功のキーポイント」では「敢えて刺激的な」 お話をさせていただき、読者の皆様のフィードバックを喚起したい と思ってます。 J2EEやUMLやXMLなどの個別技術はもちろんですが、最近の技術者に 求められる資質はどんどん広く深くなってきています。単なる個別技術に 詳しいエンジニアではなく、その先を求める方々の議論の場となれば 光栄です。 今回の「Javaコードで物を考えない大切さ」では、プログラミング時に 何も考えなくていい、と言っているわけではありません。すばらしい プログラミングはもちろん存在するわけであり、しょむさんのおっしゃる 通り職人的プログラマは本能的（？）に無意識にいろいろなモデリングを 頭の中で実践しているわけです。それをどうやったらシステマティックに できるか、という問いかけをしたかったわけです。 ご意見、文句等お待ちしております。 | ||||
|
投稿日時: 2001-09-28 17:48
漆原さん、宮下です。
お忙しい中ありがとうございます。 ご登場をお待ちしておりました！ またお時間のございますときに、 コメントをいただけますと幸いです。 | ||||
|
投稿日時: 2001-09-28 20:58
こんにちは。＠ITラーニングデスクを担当しています小林です。
ここでちょっと、ご案内をm(__)m ＠ITラーニングデスクに、新しく日本ラショナルソフトウェアさんのコースが加わりました。 これらは同社のツールの使い方セミナではなく、オブジェクト指向による開発（要求管理、 プロジェクト管理も含む）を学べるものです。 コース概要では、講師にもインタビューをしたのですが、興味深いものでした。 コースで使うテキストの目次をご覧いただけると、みなさんだったらおおよそコースの 内容がつかめるかと思います。 どうぞご一読を。 （＠ITトップページの左サイドメニューで「ラーニング」をクリックください） --- 小林＠atmarkIT | ||||
|
投稿日時: 2001-10-03 08:57
漆原です。
そうそう、XPをやっているヒト（弊社にもたくさんいますが）って どこまでコードだけで全体仕様を考えてるんですか？ ほらそこでXPしているヒト（笑）、教えてください。 やはりまず右脳で考えたい・・・！？ | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。