Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

使いやすさの定義・業務システムは簡単か?

前回のエントリーが尾を引いているのですが. ここ
何事も10人10色で、全員が納得する仕組みや使い勝手は存在しません。国や制度なら尚更です。
システム作りも政治も、その面では同じです。20%が不満でも80%が満足するか、90%の人が少しの不満をもつか、どちらが良いかなどは、判断できるものではありません。人の価値観で異なるし、時代背景にもよるでしょう。
幸福度の高い人を多く作るか、適度な不幸を皆で共有するかも、意見の分かれるところです。
私は、どちらの世界も有って良いと思いますし、住民が自分の意思で選択か引っ越しができる仕組みがあれば良いなと考えるのです。
 システムも、経営者にとっての使い勝手と、実務担当者にとっての使い勝手とは違います。
実務担当者にとっての必要項目も、経営的には不要な項目もあります。近視眼的に必要と思われている項目も実は不要だったということも多くあります。その判断は、システム屋が出来るものでは有りません。上意下達なら、直訴できるだろうし、相手担当者に実権があるときは、従うしかないでしょう。
 使い勝手は、使う人の慣れ具合も左右されるので、相手の経験にも依存されまます。
正論な論理だけでは構築できないのが業務システムの難しさです。OSやコンパイラは、実装技術的には高度なスキルを要しますが、理論がはっきりしていて、作る仕組みが固定化されるので、その面ではスッキリして、作り易いとも言えます。(作り易い/難しいの比較は無意味なんですが)
 一言で言ってしまえば、業務システムは、入力データの集計仕事に集約されてしまうので、答えが確定するだけに簡単そうに見えますが、多システムとの複合した仕組みだと、トランザクション管理すら自由になりません。 MS系で、Active_DirectoryとRDBを同期をとって動作させるのも、難しいものがあります。ましてや、他のOSと連携させるとなると尚更です。
他の仕組みとの連携保証を高めると、使い勝手が犠牲になりがちです。トレードオフになります。
経理システムとの連動は、金と物との流れと矛盾が付きもので、落とし処を見付けるのを要求されても困るだけです。
新人や知識不足の技術者だけて作れるものではありませんし、作れるとは誰も言わないでしょう。経験を積む必要があるので、自然と淘汰されます。
個々のプログラム開発は護送船団方式であっても、システム開発は押さえるところは押さえている筈です。
ただ、予算と期間という壁があるので、100%満足できるモノは作れないので、どこかで納得の上で妥協する必要が有ります。PMやリーダーの腕の見せ所です。
#ダメPMによる火災も起こりますけどね.www

投稿日時 : 2008年12月1日 1:34

Feedback

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 8:05 ネタ好き未記入

>個々のプログラム開発は護送船団方式であっても、システム開発は押さえるところは押さえている筈です。

ここが根拠無いんですよね。
護送されていた人が新しい人を護送する時、適切に護送できるという理論が成り立たないと思います。


全体として、プロ意識が無い人が多いですね。
お客様の満足度は実装段階で関係ないとかw
プロとは思えない発言ですw
私は「お客様は分かっていない」は言い訳とだしか思えません。
そんな事は他の業種でも同じです。
ITだけ特別だということはありません。
それに、統合開発環境で技術者の腕が落ちているのに、それをさらに進める護送船団方式は正気の沙汰ではありません。
あと、本当に業務システムって簡単ですか?
何度も言いますが、皆様はクレーム0件なのですか?
これは基本的なことですが、品質を最終的に判断するのは我々ではなくてお客様です。
技術者が100点をつけようと、お金を払う人が0点と思えば0点なのです。
みんな全体として甘いですね・・・

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 8:10 ネタ好き未記入

あと、あちらで皆が言っていることを総合すると「コーダーの発言」だと感じてしまいますね。
言われたことだけ実装していれば責任ないって言っているように聞こえます。
実装能力を重視する私は、プログラマの価値を下げる発言は聞き捨てなりませんねぇ。
本来プログラマとは、設計も出来て当たり前だと思うのですが・・・
全体像が分からないでコーディングされると怖すぎますw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 8:25 ネタ好き三記入

それにしても・・・みんな、SEには実装能力を求めるのに、プログラマには設計能力は要らないとw
うーんやっぱり怠慢とかおもえないやw
自らそうやって出来ないことを増やしていく時点でプロとして如何なものでしょうか?
プログラミング言語の機能は全ては使わないw
お客様の満足度は追及しないw
優秀な先人を見習うよりも、未熟な自身に合わしてくれというw
これを甘えといわずに何と言う!

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 10:30 みきぬ

> これは基本的なことですが、品質を最終的に判断するのは我々ではなくてお客様です。
> 技術者が100点をつけようと、お金を払う人が0点と思えば0点なのです。

いくら立派な実装技術があっても、歪んだ読解力と崩れた表現力しか持ち合わせていない人が作ったシステムは 0点になるというお話ですね。よくわかりますよー。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 11:20 choir

>自然と淘汰されます。
悪貨は良貨を駆逐するのですね、わかりますw
・・・と、要らん茶々を入れてみる。

>システム開発は押さえるところは押さえている筈です。
護送船団が十全に機能している限りは、ですよね。
船団指令がアレだと、全体にマイナスが及んで非常にマズイ事態になるような。
#指令の選定・評価はどうすれば?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 11:59 Ognac

整理してみましょう。
護送船団方式は、コーダーの労働力を集約するための形態です。善悪でなく、工業製品としてのシステムの開発手法です。
開発者として不満ばかりの形態であっても、ビジネスの話です。

プログラマと表現しないで、コーダーと開発者と表現して考えて見ましょう。
開発者がコーダーなることも逆もあり得ますが、資質や向き不向きもあるので、互換性は有りません。センスの無いコーダーが開発者になるのは不幸てす。同様にセンスのない人が設計者になるのも不幸てず。
その人の持ち分を発揮できる、仕事を配分するのはマネージャの仕事です。

>護送されていた人が新しい人を護送する時、適切に護送できるという理論が成り立たないと思います。
 そう考えると、護送船団で守られた開発者が、「護送船団を指示する側」に回ることはないことは少ないと思います。

>本来プログラマとは、設計も出来て当たり前だと思うのですが・・・
コーダーの中にはセンスの無い人がいるのも事実です。皮肉なことてすが、護送船団がフィルターの役割を果たしている面があるかも知れません。


>「お客様は分かっていない」は言い訳とだしか思えません。
誰も、そのようには言ってません。「解ったほうが楽しいが、解る必要がない」と言っています。
テレビを見るとき、内部回路の実装具合を理解したいですか。
車に乗るとき、EGIの燃料制御のブログラム実装の品質を気にしますか。
携帯電話を使う時、JAVAアプリの実装が気になりますか。

>全体像が分からないでコーディングされると怖すぎます
設計段階と、実装段階の役割差の認識が大事です。設計が終わってから、製造に入るケースが多い現実では、製造段階で、仕様変更は不可としないと、収集が付かなくなります。トータルコストと品質はトレードオフです。局面だけの満足度では、ビジネスにはなりません。

技術面だけでなく、ビジネス面で考えて見ればどうでしょうか。

>あと、本当に業務システムって簡単ですか?
これも、誤解されているようですか、誰も「簡単だ」とは言ってません。 「OSや言語に比べたら簡単」というように、ネタ好きさんが言っているように聞こえたのです。見直されたら如何でしょうか。


>護送船団が十全に機能している限りは、ですよね。
もちろん、純粋に、ビジネス面限定で話しています。 www
#技術面では矛盾が生じやすいのは承知しているのですが...orz


 前述したように、センスのない開発者(VBerに多いとされますが、昨今はJaverにも見受けられると聞きますが)の問題と
製品を品質を保ちながら納期通りに仕上げる管理技術と、個人レベルの技術への追求精神は、別次元の話です。
それが干渉し合って、社会が成り立ってます。自己の言い分だけ主張したのでは、中途半端に誤解が生じてしまいます。
建設的な議論は、誤解の解消も大事な手順です。行き違いのままでは、気まずさだけが残ります。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 12:57 aetos

> テレビを見るとき、内部回路の実装具合を理解したいですか。
> 車に乗るとき、EGIの燃料制御のブログラム実装の品質を気にしますか。
> 携帯電話を使う時、JAVAアプリの実装が気になりますか。

全部 Yes って言いそうで怖い。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 14:03 通行人

ネタ好きさんの例えを借りるならば、
ネタ好きさんはたとえお店で出された料理が美味しくても新人が作ったものであれば文句を言いたくなる、のに対し、
ネタ好きさんに反論する人たちは料理そのものが美味しければ作った人のことなどほとんど気にしない、のだと思います。

どこまで引っ張っても相入れないと思いますけど。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 14:13 Chuki

ネタ好き未記入さんと他の方の前提で2つ違うところがすごく気になったです。

>護送されていた人が新しい人を護送する時、適切に護送できるという理論が成り立たないと思います。
ある程度大きなシステムだと、そもそも各局面で会社も違えば人も違うため、ある程度役割分担を行います。そのプロジェクト内での役割が決まれば完全な縦割りは困りますが協力関係のもとに各自の役割の利害に基づき行動する必要があります。護送船団もその一つだと認識しています。
#運ばれる側が幸せかどうかは議論の外。

護送船団の中の人がシステムやIT知識に詳しいことは望ましいですが、それ以上に安い賃金で最低限動いてくれる方を発注側は望みます。(安くて知識があればなお良し。このあたりの最低限をどのレベルに置くかは各PMによって全然違いますが)
#船団の中から意見を具申してくれるのはうれしいが、度が過ぎると会議時間を延ばすだけのコストが高い奴を思われる可能性高し(このあたりもPMの資質如何ですが...)。チーム内での役割を変えてもらった方がきっとみんな幸せになれる。

ということで、チーム内での役割という前提が違っているように思います。(ある程度の規模の案件でプログラマって書いていれば、ほぼコーダーのことかも^^;)
プログラマのプロフェッショナルとして設計ができることは重要ですが、それとプロジェクトに設計の役割として入ることとは同義ではありません。全てのメンバがプロジェクトの全体を把握していることが理想ですが、まず無理なので役割分担するのだと思っています。なので、どの役割でプロジェクトに参画するかで辛さ楽しさは全然違って当然ですし、求められる能力も変わってきます。
#全部を一人か数人で回せる規模の案件だと、当然一人で何役も担うため、担う役割については党外の能力が必要であることは言うまでもありません。

>あと、本当に業務システムって簡単ですか?
私が知っている限りOgnacさんは業務系アプリの難しい部分を熟知されている方だと認識しています。氏が業務アプリを簡単だなんて言うところを私は想像できません。
#Ognacさんの本職ってなんだろ。業務アプリ屋としてすごいのは知っていますが、本職を何だと自認されているのかは存じ上げません^^;

>aetos さん
おんなじこと考えた^^;
#私も気になるw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 15:03 Ognac


>全部 Yes って言いそうで怖い。
>おんなじこと考えた^^;
>#私も気になるw

(ボソ)ここで、火に油を注いでほしくなかったなぁ。
開発者視点では、気になる処ですが、ユーザー視点と開発者視点では別の価値観というのを認識してほしいです。>ネタ好きさん

>どこまで引っ張っても相入れないと思いますけど。
うーん。

>氏が業務アプリを簡単だなんて言うところを私は想像できません。
何も出ませんよ。
(確認) 私は、「簡単だ」とは言ってませんし、思ってません。誤解されるような記述になったのは、未熟でした。..orz;
繰り返しますが、業務系システムの難しさは、意思決定の手順や他システムとの同期なと、運用手順という人的要素が入ってくるからです。それ故に、下手なソースでも確実に動作するほうが望まれたりします。
OSやコンパイラは、その世界の難しさがありますし、 OOPの実装技術は違う要素が入ってきます。
比較すること自体、無意味な事です。

世の中には、「知らない事の幸せ」「知らぬが仏」というのがあります。.....と言い出すと、火に油になるので、又の機会に。


>本職を何だと自認されているのかは存じ上げません^^;
え! 只のプログラマに過ぎませんが.....

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 21:40 通りすがり

いつも楽しみに読ませてもらってます。
直接エントリとは関係はないのですが、Ognac氏のこのシリーズのエントリを読むたびに思い出すのが
東証のシステム障害(2008年)と国税電子申告・納税システム(e-Tax)の利用率についてです。
様々なITの問題がこれらにあぶりだされている気がするので。。。
いつかこれらに触れて頂きたい気もします。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 23:05 Pasie.

 なんとなく全体的に、たとえば30人31脚をしようとしてて、足の速い奴が、「俺様の足を引っ張るな!おまえらもっと速く走れよ」と言う話をしているように感じます。
 そんなことなのだとしたら、護送船団方式のほうが美しいし信頼できますね。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/01 23:44 Ognac

>いつかこれらに触れて頂きたい気もします。
うーん。難しい宿題をいただきました...www.可能ならいずれ..ww

>護送船団方式のほうが美しいし信頼できますね
適切な比喩ですね。感服してしまいました。
マイナス評価のモノでも、それ以上のマイナスがあれば、よく見えます。価値評価は相対的なものですものね。
#あ、肯定しているのではありませんよ。...いままで以上に言葉に気を遣うようになったのは、なぜだろう

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 7:21 ネタ好き未記入

みんなが言っている事が本当ならば、コーダーはジェネレーターと変換可能なので必要ないと思います。
知っていて作業をするのと、知らないで作業をするのは違いするぎるってことです。
護送船団方式を問題といっているのは実地訓練をする事がなくなるからです。
何時護送する人を鍛えるのですか?
実装を知らない設計者を育てるつもりですか?
プロであるべき人々をジェネレータに変換可能にしているのでは?

> なんとなく全体的に、たとえば30人31脚をしようとしてて、足の速い奴が、「俺様の足を引っ張るな!おまえらもっと速く走れよ」と言う話をしているように感じます。
そうです。常にべべに合わしてれば、皆が走れなくなります。
お金を貰うって事を甘く見すぎていませんか?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 7:34 ネタ好き未記入

皆様はソフトウェア工学の勉強していますか?
故障率を上げているのはソフトウェアバグなのですよ。
ハードウェア技術者の方はとっくの昔に故障率を劇的に下げるのに成功しております。
その一方で、ソフトウェア技術者のバグは一向に減りません。
いえ、正確に言うと、減っているけどもそれとともに増加しております。
さてここで問題です。
システムの故障率を減らすために一番有効な手段はなんでしょう?

1、プログラミングを自動生成する
2、護送船団方式でみんなで技術力を下げつつ仲良しごっこをする
3、中国などにアウトソーシングする

さて、経営者はどれを選ぶでしょうか?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 9:07 ネタ好き未記入

>あと、本当に業務システムって簡単ですか?

ここ誤解されているようなので訂正しておきます。
レベルの低い人に合わしている余裕がありますか?ッてことです。
全力失踪でも作れないものを、一番遅い人に永遠と合わし続けて走るのはKY過ぎます。
それよりも一番遅い人を実地訓練する効率的な開発プロセスを考えた方が経済的ですし経営効果もあります。
ビジネス面を考えているからこそ、技術者の価値、お客様の価値観、経営戦術を考えていっているのですが・・・

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 9:13 ネタ好き未記入

一言で言うと、
お客様たちが「ITって品質悪いよねー」って言っている最中に・・・
技術者たちが「どうせあいつらには品質はわからん。一番レベルの低い人に合わせて、教育をサボろう!」
っていっているように聞こえるわけです。
あの~一言言ってもいいですか?
お客様はもうコードの品質が悪いってこと気付いていますよ?
気付いていないのはIT産業側だけですよw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 9:49 みきぬ

> 2008/12/02 9:13 ネタ好き未記入
>
なんで「ネタ好き四記入」にしなかったの! がっかりだ!

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 10:16 ネタ好き誤記入

>なんで「ネタ好き四記入」にしなかったの! がっかりだ!

しまったぁ!ごめんw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 10:51 ごんごん

ネタ好きさん、なんでひとつのレスにまとめられんの?
見てるとイラっとしてくるんだが・・・。

いろんなことをしっかり考えてるなら、読む人が読みやすいかどうかも
考えてレス送信のボタンを押してよ。

それも考えられない人がぎゃーぎゃー言ったって
ほかの人の主張を変えるに至らんって。
理解や同意もされんって。


Ognac様、このような文面をレスすることをお許しください。
あまりにもひどいと感じましたので・・・。
乱文雑文失礼致しました。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 11:15 通りすがり

「あ、もしもし、○○ですが。あの件について...が...して...なんです。はい、そうですね。ではよろしくお願いします。」

3分後

「もしもし、○○です。あとですね、...については...でしょうか?はい、わかりました。では失礼します。」

さらに3分後

「もしもし、○○です。それでですね、...に関しては...ですのでよろしくお願いします。」

(ノ゚Д゚)ノ 彡┻━━┻ 一回にしろー!

Ognac様すみません、つい...(汗)

> それよりも一番遅い人を実地訓練する効率的な開発プロセスを考えた方が経済的ですし経営効果もあります。
いや...だから...ずいぶん前に一番下にあわせるんじゃなくラインを決めましょうよって言ったジャン...orz
それをできる人がいるとは思えないってぶった切ったのネタ好き様ジャン...しくしくしく

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 11:33 ふるふる

>そうです。常にべべに合わしてれば、皆が走れなくなります。
その代わり歩くことはできますね。足が速い人が走ろうとしても、転んで前に進めません。
ゴールしないチームより、ゴールできるチームにお金を払うと思いますよ。
あなたは独りよがりで、ゴールに進めなくさせている張本人ではないですか?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 11:39 吊られてみた

>みんなが言っている事が本当ならば、コーダーはジェネレーターと変換可能なので必要ないと思います。
そりゃもう、コードジェネレータで済むようにならないかと日や研究に励んでおりますとも。中途半端にコーダーが必要な状況はとても無駄。
#本当にコーダーが要らなくなったら、ソフトウェアハウスの多くがつぶれることになりますが、そうならないことからも分かる通り、机上の空論ですな。でも実現に向けて頑張ってます^^。

>レベルの低い人に合わしている余裕がありますか?ッてことです。
ない。だから箱(フレームワーク)作ってコーダさんが最低限の仕事で済むようにしています。箱がうまく作れたら、ベトナムやタイなどの安いところに作ってもらいます。無理そうなら日本の協力会社さんへ、先進的でみにつけたい技術なら自社のエースをつけます。(我ながらぶっちゃけ杉)

>それよりも一番遅い人を実地訓練する効率的な開発プロセスを考えた方が経済的ですし経営効果もあります。
実地訓練って誰が指導するの?出来ない奴のために出来る人の邪魔させるの?もったいなすぎるじゃん。できないのは誰でもできる仕事させてればいいじゃん(と思ってる経営者・PMは多いかと。)

>ビジネス面を考えているからこそ、技術者の価値、お客様の価値観、経営戦術を考えていっているのですが・・・
ビジネスで考えれば、できん奴は切り捨てて、できる奴を他からひっぱてこれば済むだけのこと。なぜにできない奴を育ててやらんならんのか理解に苦しむ。教育費考えればお金出して引っ張った方が安いこともある。だからことさら社会貢献とか義務なんて言葉をだして安易に流れないように自らを諌める。
経営戦術として、すでに放り込んでしまったのに出来ん奴はしょうがないから育てる、と言うのはあるかもしれないけれど、経営戦略としてはもっと冷酷ですよ?
#あんまり行きすぎると、どっかの球団みたいになるんだろうな

>護送船団方式を問題といっているのは実地訓練をする事がなくなるからです。
>何時護送する人を鍛えるのですか?

これが問題だということについて否定している人はいなかったですよ^^。
発注側の論理として、箱(フレームワーク)は用意するから後は作ってね、というかなぜに金を払って鍛えてあげないかん、という話になりがちです。(自分のところの社員は箱を用意する側に入れて鍛える。)

>お客様はもうコードの品質が悪いってこと気付いていますよ?
ソフトウェア産業のプロジェクト失敗率の高さは昔から大問題。それについて否定する人もいませんでした^^

>気付いていないのはIT産業側だけですよw
だから、気付かなくてむ済むIT産業の人がいるとしたら、かなり幸せな部類に入るんでしょう。

企業の教育やソフトウェア工学について経営者側の視点になって考えてみると、さらに厳しいこと言われると思うんだけれどなぁ。
#つまらん仕事にしか入れてもらえないようなのでしたら、きっと社内の評価がかなり悪いのかもしれないので、とっと移った方が幸せになれるかもしれません。ただ、本人にとってつまらないことでも経営者層にとっては重要で期待されていたからこその仕事かもしれないのでそこは見極めてくださいな。(評価が悪い≠技術力がない。評価が悪い≒いろいろと文句は垂れてくるけれど何言ってるのか分からなくて時間と手間ばかりかかる奴)

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 18:16 ネタ好き未記入心配性

どうも、色々参考になります。
特に気になったことについて返答します。

>ビジネスで考えれば、できん奴は切り捨てて、できる奴を他からひっぱてこれば済むだけのこと。なぜにできない奴を育ててやらんならんのか理解に苦しむ。教育費考えればお金出して引っ張った方が安いこともある。だからことさら社会貢献とか義務なんて言葉をだして安易に流れないように自らを諌める。
>というかなぜに金を払って鍛えてあげないかん、という話になりがちです。

同感です。経営者側や顧客がこう考えそうなので、「護送されている開発者よ大丈夫?」と心配になって投稿したのがきっかけです。
ちなみに製品ジェネレータは成功しており、現在人工知能を適用することを考えておりますので、今のままだと誰かが同じ発明をして、コーダーを失業させるだろうな・・・と予想しております。
これは発明者の直感ですがMSは特に怪しいですね。
MSは製品ジェネレータを目指していると感じます。
それで、製品ジェネレータの弱点は
「人間の経験に関する事はじぇねレート出来ない」なのでぼやぼや護送されていないで、開発者も自身の価値を高めて欲しいなと私は思っています。
私は開発者が好きなのです。
ついつい心配で警告を書きたくなりました。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/02 23:16 Ognac

>ネタ好きさん
あのですね。...口調が変わってしまいますが。

皆さんが言うように「護送船団方式は、遅い人に合わせる」のであって、「できん子に合わせる」のではないのです。
そして、「できん子」の定義は、「経験不足の子」や「新人」が含まれるかも知れませんが、「曲がりなりでもプログラムが出来る子」を指している。只、センスが悪いのか無いのかは知らないが、非効率なソースや不合理なコードを書く子」をさしてます。
 これは、製造者の中間内で評価は低いが、何度もいいますが、業務要件は満たしているのですよ。
といっても、いままでと同じLoopになるので。例を出します。 (無理矢理の例なので、変に突っ込まないでね)

要件 : 1~10までの整数の和を求める

どのように製造します?

A:
int s=0;
s = 1 + 2 + 3 + 4 + 5 + 6 + 7 +8 + 9 + 10 ;

B:
int s=0;
for(int i=1; i<=10;i++) s+=i;

C:
int s = (1 + 10) * 10 / 2;


学校のテストで 、上記要件の問題がでたとき、 A,B,Cの回答をした人に得点差を付けることができますか?
要件に「公式を用いて」とか「ループを用いて」という条件がないので、同等に点をつけるでしょう。
製造者なら、拡張性を考えてAはダメで BかCが良いというでしょう。しかし、BとCのどちらが良いかは分かれます。
要件に変更が加わり、「1,3,5,7,9の1つ飛ばしの和」となった時、ソースの変更は,Bが簡単だから Bが良いという人と、
公式が成立するのだから、公式を適用すべきと言う人に分かれます。
 しかし、それは、製造側の内部問題です。業務要求者からみれば、どっちでも良いことです。
解りますよね。「できん子」が作っても、答えが「55」になるプログラムは作れます。顧客要求は満たされるのです。
一般的な顧客は、手続き型やOOP型すら関係無い事が多いです。

「できん子」を「できる子」にするのは別問題です。資質の問題もあって、「できる子」になれない「子」もいます。
所属会社の問題であって、プロジェクトチームではありません。中には、開発者教育を予算計上している奇特なチームもありますが。原則は自助努力でしょう。

何度でも言いますが、「護送船団開発形態」は発注者から見た、経済的、時間的、技術的の近似最適解です。
理論的根拠ではなく、経験則からくる意思決定かもしれません。我々開発者が求めがちな数字的裏付けは乏しいかも知れませんが。

もう一つ気になったのですが、OSを自作したり、コードジェネレートを自作するくらい力があるのに、惜しいと思うのです。誰かのコメントにあったのですが、「コードジェネレータ」は「コーダ」を駆逐すると、本気で思っています?
 1980年代に 4GLブームがありました。http://ja.wikipedia.org/wiki/4GL
「パラメータを与えるだけで、ソースを作ってくれて、後は自動実行してくれる」というものもありました。
各々、特定の環境の下では威力を発揮したようですが、環境外の要素にはお手上げでした。
逆に、業務をそのパターに合わせるという、「会社のルールをパッケージに合わせる」考えが芽生えて、今に至ってます。
 それも一つの在り方でしょう。
しかし、完成された「コードジェネレータ」や「スクリプト言語」がいまだに存在せず、新言語として続々登場するのはなぜか。
昨今の多くの動的言語の登場はなぜか。

# Fortran/Cobolが未だに原型を残して健在なのは、凄いと思う。 Cは原型をのこしているので匹敵するでしょうが、
C#/JAVAは原型が残っていない気がするのは気のせいだろうか

私は(だれか様のコメントにありましたが)基礎となる(画面遷移やDBアクセス)フレームワークを発注者か上流行程者が提供し、開発者は、各イベント内でデータ移送の部分や、項目データチェックの部分だけコーディングすればよい。という姿がもっと普及する予感はしてます。われわれ職人には面白くありませんが、ソフトが工業製品化していくのは不可避なので、しかたないのかなぁ。と思います。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/03 9:55 ネタ好き未記入

>皆さんが言うように「護送船団方式は、遅い人に合わせる」のであって、「できん子に合わせる」のではないのです。

仰ることはよく分かりますが、ベクトルを下に向けるとレベルダウンに限界がないと思うのです。
ベクトルを上に上げるのが職人であり、下に下げるのはゆとり理論だと私は思います。
もちろん、これが杞憂ならばいいのです。
ちなみに、コーダーを駆逐すると私は考えています。
私がシステム構築屋で一システム3ヶ月~6ヶ月で作れるのは何故でしょうか?
このようにジェネレータを職人(私は未熟者ですが)が使えば、コーダーなぞ要らないのです。
ハッカーがジェネレータを使ったとき、我々普通の技術者に仕事が回ってくるでしょうか?
プログラマを作れませんが、コーダーは既に必要ありません。
でも強化学習とカオス理論を使えばどうでしょうか?
私は今それを目指しています。
ジェネレータに人工知能を搭載して、自分で覚えていく時コーダーは要りますか?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/03 11:13 みきぬ

コンピュータに業務システムを作れるだけの知能があるんだったらさ、システムを作るなんて回りくどいことしないで、コンピュータに直接業務をやってもらおうよ。そのほうが手っ取り早いじゃん。すげー、俺って天才!

…あれ、人間っていらなくね?

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/03 17:35 Jitta

> …あれ、人間っていらなくね?
こういうことですか?
http://blogs.wankuma.com/jitta/archive/2007/11/29/110975.aspx

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/04 6:09 ネタ好き未記入早起き

みきぬさん、Jittaさん正しくそれです。
2002年に発明した時、始めは便利でいいじゃん!って簡単に考えていましたが、よく考えるとこれバージョンアップを繰り返せば私自身が要らない子になるんですよね・・・・
あー怖い。でも発明は止められないんですよね。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/04 23:31 Pasie.

>> なんとなく全体的に、たとえば30人31脚をしようとしてて、足の速い奴が、「俺様の足を引っ張るな!おまえらもっと速く走れよ」と言う話をしているように感じます。
>そうです。常にべべに合わしてれば、皆が走れなくなります。
 ほほう。
 てことはウサインボルト氏を30人用意してみますか。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/05 8:06 Pasie.

> 要件 : 1~10までの整数の和を求める

なんとなく作ってみた。

int[] a = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
int c = 0;

foreach(int b in a) {
  c += b;
}

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/05 10:33 みきぬ

> 要件 : 1~10までの整数の和を求める

int s = 55;

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/05 12:42 吊^h Chuki

>> 要件 : 1~10までの整数の和を求める
>int s = 55;

保守の時、「55」ってなんだーって叫び声が聞こえてくるパターンですねw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/05 13:17 みきぬ

> 吊^h
ちょw

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/09 1:52 toshi_wp

30人31脚の話が出てましたが、あれって足の遅い子の両隣に足の早い子を置いて全体的にいい記録を出すってのが戦法としてあるんですよね。(その記録は足の遅い子が一人で走ったときより早いタイムだった)
そしてそれが新記録を出していた時期があったはずです。(最近は見てないから他の戦法で記録を出しているかもしれません。)
なので、脚の早い子が自分の全力で走ったときの個人のベストタイムじゃなくて全体のベストタイムを求める方法。
こういうのをOgnacさんは言っているのではないでしょうか?

ネタ好きさんが言っているのは100×4リレーみたいに選ばれた人が、切磋琢磨してより早い記録を目指すような方法に感じました。

IT業界の底上げをするのはOgnacさんの方法も必要だと私は思いました。足の遅い子が早く走ることの喜びに目覚めることもあるでしょうし。

ただ、ネタ好きさんみたいにトップを走り続ける人への憧れや、そこを目指す人への指標も必要だと思います。

そういったところで意見の違いがあるように感じました。

# re: 使いやすさの定義・業務システムは簡単か? 2008/12/09 10:43 ognac

toshi_wp さん、援護射撃ありがとうございます。wwwww
遅い人の底上げは全体の速度に影響するので必須行為だと思います。
誰もがトップランナーになれる訳ではないし、なる必要はないわけで、工業製品としての単純作業工程の速度で良いともいえます。
開発者個人の技術満足度は違う次元の話なので、心理的バランスを考えて仕事の配分をするのは
大事だと思うのです。
あちこちに書いてますが、技術追求と、製造現場との乖離は広がる一方なので、この問題も永遠の課題になりそうな気もします。

タイトル  
名前  
Url
コメント