「ソフトウエア科学・工学」と「断片化」

投稿者

投稿内容

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2006-04-11 18:13

objectです。
#スレの内容に対して、妥当な会議室が思い付かなかったので、取り合えずここにしました。

「次世代開発基盤技術“Software Factories”詳解」
(http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory01/softfactory01_01.html)
の冒頭で、「萩原正義氏」は次のように述べておられます。

引用:

「代表的な開発手法としては、プロトタイプ開発、ドメインクラス開発、プロダクトライン開発が存在し、開発アプローチとしては特にユースケース駆動のプロセス中心アプローチ（POA）とデータ中心アプローチ（DOA）が存在する。
また、開発方法論、開発プロセスとしては、UP（Unified Process）、アジャイル、Catalysis、そのほかとしてSOA、パターン指向設計、マルチパラダイム設計などが存在する。
ソフトウェア開発の意思決定戦略として、要件や課題を判断して、開発手法、開発アプローチ、開発方法論、開発プロセスなどの多次元な選択肢を決定する。
これに基づきソフトウェア開発を実践する。
　しかし、技術の適用限界と最適な条件を理解してこれらの多様な選択肢を多次元に組み合わせることは容易ではない。
本来、ソフトウェア開発の複雑さや生産性の改善を目指して発展してきたソフトウェア工学の成果が皮肉にもかえって複雑化を招いている。
ここが本質的な問題と考える。
アーキテクトは難しい先進的な技術の成果をいち早く啓蒙するのが主ではなく、実情に合わせて技術を整理し、単純化して適正な適用方法を示すことで技術の普及に努めるのが役割と考える。」

「萩原氏」は
「アーキテクトの役割が、実情に合わせて技術を整理し、単純化して適正な適用方法を示すこと」
また
「現在のソフトウエア工学に於ける複雑化の悪循環」
を嘆いておられる様です。
しかし、問題点を含む、その為の対策には言及せず、結果的に、
「"Software Factories"によって、さらなる「複雑化」を招いている」
様に、私には見えてしまいます。

このままでは、ソフトウエア科学・工学はひたすら発散し、
結果的に
「プログラマ等への負担がただただ巨大化していくだけ」
だと私は考えています。

皆さんは、どう思われますか？

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

投稿日時: 2006-04-11 22:33

引用:

objectさんの書き込み (2006-04-11 18:13) より:
「次世代開発基盤技術“Software Factories”詳解」
(http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory01/softfactory01_01.html)
このままでは、ソフトウエア科学・工学はひたすら発散し、
結果的に
「プログラマ等への負担がただただ巨大化していくだけ」
だと私は考えています。

皆さんは、どう思われますか？

この手のやつを見ると、いつも思うのですが。今は「技術」の問題ではない。
という事実、です。そもそもだぁれも開発手法なんて気にしてはいません。

目の前の仕事をこなすので「いっぱいいっぱい」です。

この状況は「えせ経営者」が、何の責任も取らずに仕事を下に回すのが
下で蓄積して疲労しているのが問題の根幹ですので、どんなに「よい」
開発手法なり製造手法なりを導入しても「プログラマ」は忙しく、
かつ給料が下がっていく状況は変わりません。

ここらの「ソフトウェア工場」(あえてこう書く)発想の人は、
ここらへんの「えせ経営者」の事情を完全に無視しているようです。

私から言わせれば、製造技術選択肢そのものが問題ではない。

現在、システム開発は「ウォータフォール」とも「スパイラル」ともなんとでも
呼べてしまう状況ですでに行っている。しかも、別にそう選択したのではなく、
結果的に、そうなってしまっただけだ。

この状況で選択肢を一つ増やしただけなんて何の意味もない。その選択肢が「よい」
ものであろうが「わるい」ものであろうが、結局役に立たない。状況に適合できないから。

その「選択」をちゃんとできる環境のほうが重要だと思うのですがね。

あまり関係ないか。

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2006-04-12 12:35

objectです。

「加納正和」さん、レス有難う御座います。
>この手のやつを見ると、いつも思うのですが。今は「技術」の問題ではない。
>という事実、です。そもそもだぁれも開発手法なんて気にしてはいません。
>
>目の前の仕事をこなすので「いっぱいいっぱい」です。
ええ、一言では言い尽くせませんが、
実際的に、
「いっぱいいっぱい」
ですよね。
その上に問題なのが、
「メーカーの利益追求」
の影響による、
「高額開発ツールの差別化」
で、見える部分と見えない部分が交錯して
「身動きさえ取れない」
という状況になっている事ですね。

>この状況は「えせ経営者」が、何の責任も取らずに仕事を下に回すのが
>下で蓄積して疲労しているのが問題の根幹ですので、どんなに「よい」
>開発手法なり製造手法なりを導入しても「プログラマ」は忙しく、
>かつ給料が下がっていく状況は変わりません。
この辺りは、私も少し経験があります。
仕事の進め方(開発プロセス)が全く異なる会社から、協力を求められて
全く閉口した事があります。

>ここらの「ソフトウェア工場」(あえてこう書く)発想の人は、
>ここらへんの「えせ経営者」の事情を完全に無視しているようです。
私が理解している限りでは、「ソフトウェア工場」を組織的に追求した一人は
「I.ヤコブソン」だと思いますが、
問題は、
「えせ経営者」が「ソフトウェア工場」に関して、全く無知である事
の様な気がします。

>私から言わせれば、製造技術選択肢そのものが問題ではない。
「プログラマー等」にとって
「製造技術選択肢」は「本来影響の大きいもの」
だと思います。
しかし、
「加納正和」さんが仰られる事に納得が行く「現在の状況」の方が問題
なんでしょうね。

>現在、システム開発は「ウォータフォール」とも「スパイラル」ともなんとでも
>呼べてしまう状況ですでに行っている。しかも、別にそう選択したのではなく、
>結果的に、そうなってしまっただけだ。
そうですね。
「ウォータフォール」と呼ばれた当時でも、
「プログラマ」レベルで「イテレーション」は実際に行われていましたからね。
その上、
「スパイラル」モデルの有効性は
「分析モデル・設計モデル」
を前提としますから、
「実際的な現場でどれ程効果があるのか…」
ですね。

>この状況で選択肢を一つ増やしただけなんて何の意味もない。その選択肢が「よい」
>ものであろうが「わるい」ものであろうが、結局役に立たない。状況に適合できないから。
>
>その「選択」をちゃんとできる環境のほうが重要だと思うのですがね。
>あまり関係ないか。
これに関しても、
「実際的にそう考えざるを得ない状況」
ですよね。
問題の一つは、
「ソフトウエアベンダ」が
「開発者」では無く
結果として
「経営者＝金」
しか見てないのと同じ状況になっている事は問題だと思いますね。

自分達が困った(新しい環境を理解している開発者が皆無等の)時は、
「ツールを無料にしたり、情報を押し付ける」
のですが、
それを乗り越えると、直ぐに
「開発者に対して金銭をベースに情報の差別化」
を行う。
#情報(ツール含)の差別化は、開発者を混乱させ、結果として、
#「いつの日か自分達(ベンダ)の首を絞める事になる」と私は思います。

それから、今の状況を「象徴的に述べる」なら、
「言葉と概念による混乱」
があると思います。
極端に言えば、
「ソフトウエア」では言葉に関して、
「自由＝何でも良い」
と考えているかの如き印象さえ受けます。

「ソフトウエア開発＝創造的プロセス」に係わっている者としては、
「How to」だけに囚われず、
「What」
そして、
それを深める為の「スキル」をシッカリと持ち
「見る目」
を持つ事は重要だと私は思います。

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2006-06-03 13:47

objectです。

「ソフトウエア業界の問題」が、実体験として「種々の場」で提起されています。
直接的な問題は、殆ど全ての事が
「業者主導で利益追求という観点をメインに進歩(単なる変化)している」
という事に尽きる様に思われます。
#また、技術変化のスピードが速いのも、我々が結果として、表面的な事を追求している事の証？

しかし、本当の問題は
「情報概念」
が殆ど理解出来ていない(明確になっていない)事にあるのではないでしょうか？
#熱・エネルギーに関しては、19～20世紀に実在概念として一応形が出来ました。
#しかし、情報に関しては、今現在でも「実在概念」ではない。

また、これは
「情報は、それに対する科学が無い以上、工学としては存在していない」
という事であり、
現在、現実に行われているのは、
「業者が技能レベルで勝手に理屈をこね、利益追求製品を作っている」
と極論出来る状況にさえあると私は思います。

このスレは現在、少し細かい部分での流れと内容になってしいました。
従って、
「これ以降どの様な展開をすれば、皆さんに分かっていただけるか」
と暫く考えていました。

そして、矢張り、その重要性に於いて強調したいのは、
「量子力学に於ける観測問題」
です。

これは、所謂
「物質と観測者の意志の問題」
でありましたが、
別の表現をすれば
「世界は物質だけで構成されていない」
という事でもあると思います。

それでは、
「物質以外に何が実在するのか？」
と言うと、それは
「情報」
ではないでしょうか？

つまり、
「情報は実在する」
それも
「物質・エネルギーとは独立に情報は実在する」
という事です。
現在、「情報処理に対する作業見積」もエネルギー的に行っています。
#社会・経済活動自体が、「エネルギー・物質の象徴である金」をベースである。

私達は、
「情報に係わる者」
として、
「自分達が拠ってたつ観点」
に対してもう少し自覚的である必要は無いでしょうか？

unibon: ぬし; 会議室デビュー日: 2002/08/22; 投稿数: 1532; お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)

投稿日時: 2006-06-03 14:13

引用:
objectさんの書き込み (2006-06-03 13:47) より: 現在、「情報処理に対する作業見積」もエネルギー的に行っています。 #社会・経済活動自体が、「エネルギー・物質の象徴である金」をベースである。

なるほど。これを読んで思い付いたのですが、ソフトウェアにも、CO2削減等の話題で良く目にする「環境に優しい」という名目があると良いのかもしれません(CO2削減と環境への優しさとの関係が本当にあるのかは知りませんが)。
排出権のようなものをやりとりしたり、開発にかかった排出量を明記しなければいけない決まりにしましょう。これで工数ばかりかかるダメな開発は淘汰されます。とりあえず、人月がそのままCO2の排出量に比例すると考えて良いでしょう。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}

よっしー: 会議室デビュー日: 2006/05/08; 投稿数: 3

投稿日時: 2006-06-05 13:25

私も加納様と同じような意見です。

「開発手法」「開発アプローチ」「開発方法論、開発プロセス」、どれも生産性と品質の向上を目指して編み出されたと思います。説明に出てくるアイテムの幾つかは自分で学んでみました。いずれも魅力的であると思います。

ただ、実際に現場に目を向けてみると、そう簡単に使えるものではありません

それは、現場の人が充分に学ぶ時間を与えられていないからです。私は新しいモノ好き、好奇心が人より強いらしいので、仕事の時間外で自分でどんどん調べます。しかし、他の人も同じであるとは限りません。

加納様がおっしゃられている、「えせ経営者」は「新しい知識・技術は自分で習得するべきで、自助努力の一環」と考えているのか、「人材育成のために充分なお金と時間を割いていない」のではないかと思います

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2006-06-05 15:59

objectです。

引用:

unibonさんの書き込み (2006-06-03 14:13) より:
なるほど。これを読んで思い付いたのですが、ソフトウェアにも、CO2削減等の話題で良く目にする「環境に優しい」という名目があると良

いのかもしれません(CO2削減と環境への優しさとの関係が本当にあるのかは知りませんが)。
排出権のようなものをやりとりしたり、開発にかかった排出量を明記しなければいけない決まりにしましょう。これで工数ばかりかかるダメな

開発は淘汰されます。とりあえず、人月がそのままCO2の排出量に比例すると考えて良いでしょう。
--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}

確かに、意味が無いとは思いませんが、
私が心配しているのは、「開発案件とその名目」では無く、「実開発従事者」の事です。
#今後も「動けば良い」という発注者は益々増えると思いますし、法律では押さえられない？

引用:

よっしーさんの書き込み (2006-06-05 13:25) より:
私も加納様と同じような意見です。

「開発手法」「開発アプローチ」「開発方法論、開発プロセス」、どれも生産性と品質の向上を目指して編み出されたと思います。説明

に出てくるアイテムの幾つかは自分で学んでみました。いずれも魅力的であると思います。

ただ、実際に現場に目を向けてみると、そう簡単に使えるものではありません

それは、現場の人が充分に学ぶ時間を与えられていないからです。私は新しいモノ好き、好奇心が人より強いらしいので、仕事の時間

外で自分でどんどん調べます。しかし、他の人も同じであるとは限りません。

加納様がおっしゃられている、「えせ経営者」は「新しい知識・技術は自分で習得するべきで、自助努力の一環」と考えているのか、「人

材育成のために充分なお金と時間を割いていない」のではないかと思います

仰られておられる事には、私も賛同致します。
確かに、各種「開発手法・開発アプローチ・開発方法論・開発プロセス」は、
「開発自体を少しでも改善しよう」
という各メーカの善意ある目的によって導入されて来たんだと思います。
しかし、ベース(=ソフトウエア科学)が無い状態で、結果として、
最も振り回されているのが
「開発従事者」
という所が問題なんだと思いますね。

実は、私はここで
「UML」を初めとする現在の「モデリング言語(手法)」の問題点は？
というスレをたてました。

目的は、最終的に
「各メーカが開発従事者の為に少しでも動いてくれ」
その結果として、
「Java、DotNet他ソフトウエア上の複雑さがいくらかでも軽減される」
という状態になれば「良いな」という、
言わば「他力本願」的なものでした。

しかし、
「どのメーカも自分の利益に繋がらなければ、開発従事者の為だけでは動かない」
という事だと、現在は諦めています。
#実際、最終的に間違っているかどうかは、殆ど気にしていない様です。

もう一つ、
私は、大学にある程度の期待をしていました。
しかし、現在の大学では、
「実際に現場で作業をしている実開発者の状態」
には余り関心がなくて、
結果として
「殆ど主要なメーカの何処かに組み込まれている」
かの様な印象を受けています。

>加納様がおっしゃられている、「えせ経営者」は「新しい知識・技術は自分で習得するべきで、自助努力の一環」
>と考えているのか、「人材育成のために充分なお金と時間を割いていない」のではないかと思います
確かに、そういう経営者は、自社の「人材=資産」と考えていないのでしょうね。
今の社会に於ける、
「ソフトウエシステムの重要性」
を考えると、
「純粋にソフトウエア開発従事者(知識と心身を含めた)」
の状態を最善にすべく動く組織が、社会的にも必要なのかも知れませんね。
#今は、商品としてのツールに振り回され過ぎています。
#勿論ここでのソフトウエアは、言語・環境を越えたあらゆるソフトウエアです。

「ソフトウエア科学・工学」と「断片化」

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