＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「動けば良い」では駄目なことを"SE"に分かってもらうには？
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2006-05-12 17:12
「動けば良い」と言う考えも有りかと思う
に対する反論スレを立てました。 私もこの件で大変苦労してきました（いや、いまもしている）。 ここでは 「動けば良い」では駄目なことをお客様に分かってもらうには？ ではなく 「動けば良い」では駄目なことをSEに分かってもらうには？ です。 こういうのは、チームを方向付ける力になるのでしょうか・・・？ 情けないようですが、このIT業界、システム開発に詳しくないSEもいます。 分からなくて手を出さないのはまだいいのですが・・・そうもいきません。 テストを金額にするといくら？ などの記事（この場合はテストの重要性ですが）をヒントに 効果を出し、説得できればと思っていますが、まだ説得できません。 意見を交換し合いませんか？ | ||||
|
投稿日時: 2006-05-12 17:34
その前に、まず「動けば良い」ってのはどういったことを指すのか定義しておかないと、あちらのスレみたいになりますよ？
# のぞきに来られないうちにあちらがずいぶん伸びてて、何書こうか思案中。 | ||||
|
投稿日時: 2006-05-12 17:46
まず、こういうものがあることを理解してもらう。
http://www.cam.hi-ho.ne.jp/adamosute/software-quality/iso9126.htm 私はもともと機械設計の人間でした。１０年ほど前にソフトエンジニアに転身しました。 いまは日々、自力でソフトウェア工学やプログラミングを勉強して身に着けています。 しかし、ソフトウェア業界には、ソフトウェア工学を理解していない人間が多すぎる。 機械設計で言えば、機械工学や制御工学の基本的なことも理解せずに設計・開発して おり、知っているのはCADの使い方だけ。 製図はできるけど設計はできないのと同じ。 それがさも当たり前かのような状態で、出来損ないを納品してお金を頂いてる状態 です。さらにシステムの不具合をまずOSやハードの限界のせいにする。 工学的な考え方、枯れた技術には見向きもせず、新しいハードや言語、OSには飛び ついて、さも知っていることをアピールするが、それを使って設計する能力はない。 それで、Javaできます！ASP.NETできます！Oracleできます！ そんな人や会社をよく見かけます。 さらに、中途半端にやり逃げ。仕様が悪い。聞いていない。OSが悪い。SEが悪い。 PGが悪い。 そしてスキルある人間に負荷が偏り、ボランティア精神でなんとかやり遂げる。 この業界は変な業界です。 この業界でプロジェクトXに出てくるようなエンジニアに出会いたい。 [ メッセージ編集済み 編集者: maru 編集日時 2006-05-12 17:59 ] | ||||
|
投稿日時: 2006-05-12 17:58
馬鹿の自己紹介スレになりそうな悪寒 | ||||
|
投稿日時: 2006-05-12 18:09
ワタクシ的な「動けばよい」を見逃すことができる
条件を書いておきますね。 ・仕様及びテスト事項については、システム完成以前に確定する。 ・完成時点において、用意されたテスト事項について、要求される結果を返す。 ・完成後は、仕様にもプログラムにも、一切の変更を加えない。 ・システムがDBを含んでいる場合、 もちろん、DBについても、データの編集や新規登録は禁止。 ついでに、以下を念押ししておきます。 ・運用開始後、バグが表面化した場合、すなわちテスト事項を追加する必要が 発生した場合、システムは廃棄。新規作成する。 とりあえず、こんなところ。 データ整形とか、オレ様用プチ・プログラムくらいにしか適用できなさそう。 [ メッセージ編集済み 編集者: Edosson 編集日時 2006-05-12 18:12 ] | ||||
|
投稿日時: 2006-05-12 18:11
私が直面した問題とそのときの対処を書きます。
仕様変更について、 [SEの主張] ・IF文を一行書けば済む話だから簡単。（←常套句・・・） [PG（私）の主張] ・条件の組み合わせ（状態遷移）があり一行で済む話ではない。ｎ×ｎ通りの処理 ・条件が不成立な場合の処理も考慮しなくてはならない。 ・ありえない条件の組み合わせの場合のエラー処理が必要。 ・ハードコーディングよりもテーブルを設計し条件判定したほうが 整合性も確保でき、保守もしやすい＝品質も上がる。 ・状態遷移に対応しやすい設計が必要（ジャンプテーブルやStateパターンなど） ※SEに説明するために作った資料 ひとつひとつの機能追加は小さいが、数が多くなると 関連する機能との影響を考慮する必要があり 組み合わせはこれだけになるという状態遷移表。 その場、その場でお客様の要望を受け入れると 処理の組み合わせに規則性がなく、直感的に理解しにくいということを説明した。 しかし、SEの説得にはいたりませんでした。 「それを何とかするのがPGの仕事ではないのか」・・・と切り替えされました。 何が足りないのでしょうか・・・？ | ||||
|
投稿日時: 2006-05-12 18:19
ISOについては、以前説明したことがあります。 また、CMM、CMMIについても同様です。 導入は大変難しいですが、 こういう指標があるということだけ理解してもらうようにしました。 システムの信頼性の指標など情報処理をやってれば出てくるようなものですが・・・ | ||||
|
投稿日時: 2006-05-12 18:33
こんなところでしょうか？
「動けば良い」の定義 ・システム障害対処のためのスクリプトなど緊急を要するプログラム ・運用後のシステム障害発生時の暫定対策時（もちろん恒久対策も行います） | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.