「動けば良い」と言う考えも有りかと思う

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

投稿者

投稿内容

加納正和: ぬし; 会議室デビュー日: 2004/01/28; 投稿数: 332; お住まい・勤務地: 首都圏

投稿日時: 2006-05-09 21:14

引用:
takuさんの書き込み (2006-05-09 09:01) より: 中身はかなり無茶苦茶な実装が行われています。

ええ。「技術」なんて言葉を丸ごと捨て去ってるのは時たま見ますね。
例えば、UNIXでプロセスを一時停止するのに
while(1) {
}
とか。「動けばいい」んですよね。確かに動いてるよ。。CPUが。。(苦笑)

「技術」を単に「お客様の問題を解決するツール」ぐらいにしか思っていない
元記事の人の場合、そもそも「無茶苦茶な実装」かどうか判断できないと
思ってたりしますが。

「要求仕様策定時」ではなく、「最後」まで関わろうとした時、
ソフトウェア開発というお仕事で「技術」なしでどうやって関わるのだろう(不思議)

コンピュータシステムって「言うだけ」ならとても簡単なのは「コンサル」見れば
分かりきってるのに。「技術」だけが重要なんてのはともかくとして。

なちゃ: ぬし; 会議室デビュー日: 2003/06/11; 投稿数: 872

投稿日時: 2006-05-10 00:22

うーん、どうもね、

引用:
未記入さんの書き込み (2006-05-06 13:35) より: 「動けば良い」と言う考えも有りかと思います。

これと

引用:
大前提として、システムを開発するのが目的ではないということです。お客様の問題をソリュートしていくのが使命です。なんでお客様の問題を技術に転嫁し対応可否を判断するのでしょうか？最近の技術者はそこを履き違えているように思えます。

これがつながらないんですよね。
「技術に転嫁し対応可否を判断」がいまいちはっきりつかめないんですが、
動かすためには技術が必要だと思うんですけどね。

目的は技術ではない、これは当たり前の話ですし、
技術ばかり見ていてお客さんを見てないなんてのは問題なのは当然ですが、
イコール技術を軽視していい、無視していいかというともちろん違いますよね。
というか、そもそもこれは話としてつながらない。

スレ主はこれをなぜかつなげてるように思えるんですよね。
はっきりいうと、
「技術がいらない」を正当化するための理由に、
普通はその理由にはならないような理由を無理やりもってきている。
ように思えるんですよね。

お客さんのことがどうでもいいなんていっている人はいないと思うんですけどね。

taku: ぬし; 会議室デビュー日: 2002/11/12; 投稿数: 918; お住まい・勤務地: 墨田区→中野区

投稿日時: 2006-05-10 09:02

　私は前職から社内ＳＥになったのですが、
前職も現在も技術的な知識・経験を期待されて、転職しています。
ユーザー部門に接していてもそれを感じています。
技術的な事柄がわかる方いないので、困っていたとよく言われますよ。
情報システム部の私がそうなのに、開発側が技術無視というのは、
？？？ってな感じですね。

業務知識においては、現場が良く知っているのですから、
技術が解らないでは、何を売りにビジネスをやっていらっしゃるのか、
かなり疑問を感じます・・・。

べる: ぬし; 会議室デビュー日: 2003/09/20; 投稿数: 1093

投稿日時: 2006-05-10 12:18

引用:

なちゃさんの書き込み (2006-05-10 00:22) より:
引用:
未記入さんの書き込み (2006-05-06 13:35) より:
「動けば良い」と言う考えも有りかと思います。
これと
引用:
大前提として、システムを開発するのが目的ではないということです。
お客様の問題をソリュートしていくのが使命です。
なんでお客様の問題を技術に転嫁し対応可否を判断するのでしょうか？
最近の技術者はそこを履き違えているように思えます。
これがつながらないんですよね。
「技術に転嫁し対応可否を判断」がいまいちはっきりつかめないんですが、
動かすためには技術が必要だと思うんですけどね。

ずっとスレを読んでいましたが、ふと最初を見ると、私もやっぱりこれが引っかかりました。
結局明確な回答が得られていませんが「技術に転嫁し対応可否を判断」というのは
技術者が「うーん、これは技術的に無理ですねぇ。。。」のようなことを言うのを
指してるのでしょうかね。だとすると
「動けばいいんだから、どんな方法を使ってでも作りなさいよ」という主張でしょうかね。

どんな観点から無理なのか、時間的に難しいのか、持ち合わせている技術が足りないのか、
そもそも論理的に不可能なのか、代替案はどんなものがあるか、といったことを
技術者から聞き出すべきでしょうね。つまりコミュニケーションをもっと取るべきなのかなと。
これは「役割はプロジェクトリーダーです」の人の仕事に当然含まれるでしょう。
このようなコミュニケーションを通じて技術者からも学べることが沢山あるはずです。

＃まぁ技術者の側も、難しい注文がきたときに、ただ無理という回答をするのではなく
＃上記のようなことを回答に含めるべきでしょうけど。自然にそういうコミュニケーションが
＃生まれる雰囲気/環境を作るのも、求めすぎですがリーダーの仕事かもしれません。

あと

引用:
お客様の関心はいち早く動くことです。

これは、ちゃんと動くのは当然として、早いほうがいいな、ということでしょう。
何でもいいから早く動かせ、とは思っていないでしょう。でも仮に早さが重要だとしても、
だからこそ「その場その場で開発工程を定義する」んです。どのくらい人が必要でどのくらい
時間がかかるか、わからないまま進めるべきではないでしょう。

「お客様の視点にたって仕事を」するのはもちろんいいですが、プロジェクトリーダーとして
技術者の視点を無視してはいけないです。

maru: ぬし; 会議室デビュー日: 2003/01/27; 投稿数: 412

投稿日時: 2006-05-10 19:14

このスレ読んで、オレンジジューステストを思い出した。

プロジェクトリーダならご存知だとは思いますが・・・。

「お客様が望むもの」に「売側・開発側としての提案（技術者としてのノウハウや腕の見せ所の部分、将来を見越してこうしたほうがよいなど）」からコストを算出して、きちんとコストの妥当性を説明した上で、お客さんの予算と納期に見合った部分に落ち着くように調整していき、お互い納得いくように仕様を決定していき、当初予定したスケジュールにあうように、みんなでがんばるだけの話ではないでしょうか？

納期やコストの妥当性をお客さんに説明できず、流行の技術に振り回され、調整できないままお客さんに言いなりの営業マンやPMが最もたち悪い。

出来損ない技術者なら、まだフォローや補強が利くことが多いけど、出来損ない営業
マンやPMは、プロジェクトそのものが崩壊して、結果お客様や開発側が大きな負担を
抱えることが多いように思う。

「動けば良い」システムの考えられる問題点や将来像をお客さんに説明した上で、
お客さんが納得すれば「動けば良い」システムでもいいのではないでしょうか？

結局、スレ主さんのところのエンジニアは妥当性や問題点、コストをきちんと説明
できてないか、スレ主さんが聞く耳持たないかのような気がしますが・・・。

[ メッセージ編集済み編集者: maru 編集日時 2006-05-10 19:49 ]

ぶさいくろう: ぬし; 会議室デビュー日: 2005/11/22; 投稿数: 1232; お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）

投稿日時: 2006-05-10 19:39

やれやれ。スレ主は立て逃げか。
真面目に返すのもバカバカしいな。

さいくろう: 大ベテラン; 会議室デビュー日: 2005/11/19; 投稿数: 170; お住まい・勤務地: 川崎市

投稿日時: 2006-05-10 21:34

まあまあ。
これまで何度もあったことだし、これで最後というわけでもありますまい。

maru: ぬし; 会議室デビュー日: 2003/01/27; 投稿数: 412

投稿日時: 2006-05-11 09:53

スレ主さんは、ハンバーグレストランをたとえに出していますが、
システム開発との決定的な違いは、動く費用が違うのではないでしょうか？

得意先と昼食にハンバーグレストランで食事をすることになりました。
得意先はグルメなので天然高級食材しか食べれません。
そこでコックに、天然高級食材を使うようお願いします。

レシピを気にとらわれず柔軟に対応する料理人：
天然高級食材でうまいこと調整しすぐに成果を出す（しかも旨い）。
→取引先との昼食会が滞りなく行える。新たなビジネスチャンス。

レシピが前提の料理人：
天然高級食材を使うケースはレシピに入っていません。
レシピを新しくつくりなおします（もしくはレシピ的にむりです）
→昼食をとらずに取引先と店をでることとなる。信頼性低下。

レストラン側も、将来的ビジネスチャンスにつながるなら前者もありでしょうが、
コストやビジネスチャンス無視の顧客満足だけを追求したレストランは確実につぶれるでしょうし、マネージャとしては失格でしょう。

＞品質が低いのは、一部の技術力のない技術者の怠慢でしょう。
たしかに、それも大いにあります。が、プロジェクトで開発しているなら、最終的にプロジェクト全体の品質はプロマネが責任を持つのではないでしょうか？
プロマネはプロジェクト遂行のために、その一部の技術力のない技術者を入れ替えたり、教育に行かせてスキルアップさせたりする権限と責任を持っています。
力があるかは別ですが。
品質が低いことを「技術力のない技術者の怠慢」とするのは、「マネージメント能力のないPMの怠慢」でもあるのではないでしょうか？

その昔、こんなことがありました。

お客様：「PCを５台程度ネットワークでつないで、一部のPCが壊れても業務が続けられるよう２４時間３６５日停止しない無人の出荷システムを作ってほしい。ただし予算は少ししかない」
営業マン：「わかりました。コスト削減のため、PCは組み立て、OSはWin95、DBはAccessで、DBが壊れないように５台ともにMDBファイルを持たせて、１書き込み毎にすべてのMDBに書かせるようにします。PCは24時間立ち上げっぱなしでいけるようにします」

　　＜受注決定＞

開発：「それは難しい。動作の保障できない。」
　～あれやこれや技術的な説明をする～
営業マン：「意味がわからない。受注したからあとは何とかなるだろ。つべこべいわずやってくれ」
開発：仕方なくできる限りのことはする。プログラムはぐちゃぐちゃ。当然予算オーバー。

　　＜本稼動＞

稼動初日、いろいろとトラブルはあったが何とか動き始める。
数日後、データが消える、MDBが壊れる、５台のMDBの整合性が取れなくなるなどの問題が多発し始める。
業務に影響が出始める。とどめに、PC起動しっぱなしで47日目(だったか？）にOSがダウンするはめに。

営業マン：「なんでそんなこともできんの？」

結局、開発側がお客さんと調整し、OSはNT系、DBはオラクル、サーバはPCサーバにして普通にC/S型システムに作り直し、サーバが停止しても最低限の業務が行えるようにシステムと業務の運用を見直した。
２４時間３６５日といっても実際業務で使用しているのは５分の１程度の時間で、運用で逃げれることも多いので、運用でカバーしてもらった。

開発費用は、当初予算と＋αは見てもらったが、当然大幅赤字になった。
そのシステムは、あれから大きな問題もなくもう１０年近く動いています。当然、お客さんも満足しています。

[ メッセージ編集済み編集者: maru 編集日時 2006-05-11 10:04 ]

«前のページへ 3|4|5|6|7|8|9|10|11|12|13 次のページへ»

「動けば良い」と言う考えも有りかと思う

スキルアップ／キャリアアップ（JOB@IT）