第３回：開発効率を飛躍的に向上する - Think IT

第３回：開発効率を飛躍的に向上する - Think IT
(2006/10/24)
http://www.thinkit.co.jp/free/article/0610/5/3/


　オブジェクト指向，サービス指向とソフトウェアの開発手法の中で再利用性を向上させようという試みは長年続けられてきましたが，実現できていないようです．これは「ハードウェアとソフトウェアの本質的な違い」，「マスカスタマイゼーション」が影響しているとおっしゃっています．詳細は記事を見てください．
　「マスカスタマイゼーション」には「可変性に対して徹底的に対処すること」とし，例が載っています．
　最後にソフトウェア開発に関わる普遍的な法則は「イノベーションとコモディティ化」であるとおっしゃっています．(^o^)/

　ソフトウェアは人間や実世界と同じなのだと思います．人間一人一人の"私"も，「イノベーションとコモディティ化」をして成長していきます．色々なことに挑戦して，試行錯誤を経て成果物を構築し(イノベーション)，その成果物は自分の中に知識や経験として蓄えられていきます(コモディティ化)．
　人間全体の"公"も，"私"のイノベーションを組合せにより更なる成果物を生み出し(イノベーション)，その成果物は学問や体験として継承されていきます(コモディティ化)．
　人間や実世界はソフトウェアと同じという所まで来たら，その時が複雑系が解明された時なのではないでしょうか．(^O^)

セル生産方式＋アジャイルという枠組み - ＠IT

セル生産方式＋アジャイルという枠組み - ＠IT

(2006/10/11)
http://www.atmarkit.co.jp/im/carc/serial/thinking08/thinking08.html


コンベア生産は，ソフトウェア開発ではウォーターフォール･プロセスに対応する．セル生産は，オブジェクト指向＋アジャイルではないかとおっしゃっています．

第２回：開発プロセスの本質とモデル駆動開発 - Think IT
(2006/10/10)
http://www.thinkit.co.jp/free/article/0610/5/2/


　開発プロセス＝生産ラインだと考えると，成功したといえるプロジェクトは30%，つまり70%が不良品と言える状態です．(マネジメント要素を含む．何を失敗とするかには複数例があります．)　原因の多くはプロセス(ライン)の設計ミスのようです．

　今回のようにソフトウェアをモノとし，部品(オブジェクト)の塊として考えていくならば，「その目的のモノを造るのにはどの部品が必要なのか」，「部品の依存関係はどうなのか」などを把握できるラインを造ることが必要ではないかと思います．それが分かれば，生産ラインに人間はいらなくなりますが．(^O^)　また，部品に著作権があるかといった問題もでてきます．

第１回：目的指向開発 - Think IT

第１回：目的指向開発 - Think IT
(2006/10/3)
http://www.thinkit.co.jp/free/article/0610/5/1/


　開発方法論がオブジェクト指向，分散オブジェクト技術，コンポーネントベース開発，サービス指向アーキテクチャという変遷をたどって来たことは，High Cohesion(高凝集性)，Low Coupling(疎結合性)という観点からは正しかったが，方法論の"目的"は正しく理解・適用されてこなかったという内容です．
　システム開発は，システムに関わるすべてのステークスホルダの観点で物事を整理することが必要であるとおっしゃっています．
　(例)
　　ユーザ経営者（投資の観点）
　　ビジネスアナリスト（企業活動の観点）
　　システム運用管理者（インフラストラクチャの観点）
　　アーキテクト（アーキテクチャの観点）
　　開発者（開発効率の観点）
　　テスト担当者（品質の観点）
　　リリース後の保守担当者（保守効率の観点）
　このすべての観点での"目的"や利点を明らかにし，アーキテクチャを構築することがシステム開発者の目的でなければならないようです．

【初級】次代を担うSEを育てる　- ITPro

【初級】次代を担うSEを育てる　- ITPro
[前編]
　http://itpro.nikkeibp.co.jp/article/COLUMN/20060921/248594/
[後編]
　http://itpro.nikkeibp.co.jp/article/COLUMN/20060922/248751/

　エンジニアに対する，コーチング・マネジメントの工夫が載っていました．エンジニアに限ったことではないと思います．
　[POINT]
　　1：エンジニアに考える癖を付けさせる．
　　2：エンジニアの力量を見極め過度な負荷を与える．
　　3：エンジニア自身が手掛けた仕事の意義を実感させる
　　4：エンジニア自身が納得する方法を選ばせる
　　5：エンジニアが迷わぬよう陰ながらサポートする