技術・開発の閑話-2- vol.11〜20

技術・開発の閑話 -2- ：技術開発コラム

• サウンドコラム/技術開発コラム
• サウンドコラム
• 音響測定編
• ソフト開発
• 技術開発の閑話2

F1とコンピュータ技術 後編

技術・開発の閑話-2-

20

前回に続いてF1チームとコンピュータ技術の話題を続けます。前回はF1車両のレギュレーション(規定)と技術に関してザッと書きました。

(※前回触れていない技術のABSや排気量の変化、タイヤ、燃料の規定など、コンピュータ技術関連以外にもスピードや安全性に関してのレギュレーション変更は行われていることをここで少し補足します。)

F1とIT技術

F1の車体に関わるコンピュータ技術については、時々F1の雑誌などで取り上げられるのですが、CNetの「ITが支えるF1世界最速技術」という記事の後編に掲載されているようなデータベースやデータロガー(テレメトリ)のデータの処理の話題はあまり見かけません。

マクラーレン・メルセデスは、記事にあるようにCA(コンピュータ・アソシエイツ)社をパートナーにしています。ウィリアムズ・BMWチームはHP社、フェラーリはAMDがスポンサー兼テクニカル・パートナーとなっています。

F1とコンピュータ技術 後編
技術・開発の閑話-2-

《 技術開発の閑話2 : F1とコンピュータ技術 後編 》

F1とコンピュータ技術 前編

技術・開発の閑話-2-

19

今回は、興味深い「ITが支えるF1世界最速技術（前編/後編）」という記事があり、F1最終戦(ブラジルGP)が明日(2004年10月掲載時)から開催されるタイミングでもありますので、自動車レースのフォーミュラー１とコンピュータ技術の話題をこのコラムにさせていただきます。

F1とハイテク技術とレギュレーション

自動車レースのレギュレーション(ルール)は、通常かなり細かく決められています。

F1もレギュレーションは細かくなってきていますが、それでも、初期の志の断片からか、技術開発や工夫の余地がない所まで厳密にはなっていません(良い点でも悪い点でもあります)。

これは技術の競争の片鱗を見ることができるという点で、厳密、もしくは、標準化された同じ車両を使うレギュレーションのカテゴリのレースとは異なる楽しみ方ができる点でもあります。

F1とコンピュータ技術 前編
技術・開発の閑話-2-

《 技術開発の閑話2 : F1とコンピュータ技術 前編 》

標準と生産管理

ソフトウェアの標準と部品化 8

18

前回、話題にしましたようなレガシーシステムとされてしまうとシステム維持やレガシーシステムを専門にした技術者の確保も困難になって行きます。

部品化や再利用性そのとコストは開発手法やプラットフォームと密接な関係にあるためプラットフォームや開発言語の動向による影響が多大です。

そこで標準技術を確立し標準技術を利用することが求められます。

標準と生産管理

ソフトウェア技術には、デファクト・スタンダードやANSI規格、ISO,JISなどの規格されている技術要素もありますが、実際に実装を伴う規格品コードのようなレベルではありません。

工業規格の部品のようにJIS規格のネジ、MIL規格の……というような管理が確立された部品を採用するというところまでは産業が成熟していないといえるのでしょう。

かつて、太平洋戦争開戦時の日本海軍の艦船の部品は、規格統一されておらず、一隻の形式の艦ごとに設計された部品で造船されていたそうです。

標準と生産管理
ソフトウェアの標準と部品化 8

《 技術開発の閑話2 : 標準と生産管理 》

遺産と再生産

ソフトウェアの標準と部品化 7

17

前回までは開発手法の話題に回り道をしていた感じでもありますが、部品化や再利用などを検討する時、現在のようにプラットフォームの変化が大きいときに問題となるのは、開発方法と実現手段(コードや言語、プラットフォームやライブラリの選択)です。

プラットフォームは、過去に比較すると集約的になってきているといえるのではないかと思います。

メインフレーム、オフコンやＰＣ、組込みまで視野に入れたとしても、かつてハードウェアメーカーがそれぞれのハード使用、CPU、開発言語を擁するというようなことは無くなり、ローカルな環境はレガシーと呼ばれるほど、種類は収束しているとも言えるのかもしれません……

　　▼レガシーシステム　【legacy system】
　　　　e-words IT用語辞典
http://e-words.jp/w/
E383ACE382ACE382B7E383BCE382B7E382B9E38386E383A0.html

比重の変化

楽器の演奏情報の通信規格にMIDI(Musical Instruments Digital Interface)規格というものがあります。

遺産と再生産
ソフトウェアの標準と部品化 7

《 技術開発の閑話2 : 遺産と再生産 》

重要な課題

ソフトウェアの標準と部品化 6

16

5回に渡って部品化に関連した話題として、あまり相関が強くないようにも見える話題を取り上げててきました(やや散漫ですが)。

• 第１回は、UMLなど設計を資産的に考える方法とコード
• 第２回は、１回に続いて資産的な考えと戦術、戦略的なこと
• 第３回は、ツールの変遷とコードの再生産について
• 第４回は、ホットなアジャイル開発と従来の開発
• 第５回は、XP手法のリファクタリング、イテレーション開発

ソフトウェア開発のサイクルの短期化と、質的、量的要求の上昇によって、開発手法やツール、フレームワーク、言語などあらゆる所で、開発効率の向上と工学的な開発手法に対するアプローチが提言されている中、あえて「標準化と部品化」という低レベルな軸で考えてみました。

これは(アジャイル的手法に少し傾向していますが)新しい開発手法まで見ても、現在のところ、工学的、工業生産、設計的な手法が確立されおらず、標準化のような知的財産の積上げが必ずしも効果的に機能しない場合があることを断片的に見てきているような作業でした。

ここまで、何となくアジャイル開発や手法の標準化にやや否定的に見えるような表現もあったかもしれませんが、そのようなことはありません。

非常に注目をされているアジャイルのような手法でも、現在のソフトウェア開発の抱える重要な課題を解決するためのものではないという視点で見みたに過ぎません。

重要な課題
ソフトウェアの標準と部品化 6

《 技術開発の閑話2 : 重要な課題 》

リファクタリング

ソフトウェアの標準と部品化 5

15

前回は、アジャイル開発の話題で少し部品化や標準化といったこのテーマから外れているかのようになっていますが、アジャイル開発で重視されることの多いリファクタリングの考え方は、部品とまで言わないまでも、部本的なモジュール(やコンポーネント)のインターフェース仕様を変更しないで改良することから、共通性を有しています。

　　▼リファクタリング【refactoring】
　　　　IT用語辞典 e-Words
http://e-words.jp/w/
E383AAE38395E382A1E382AFE382BFE383AAE383B3E382B0.html

ウォーターフォール型の開発方式では、先に製造された部品的なコードは、よほどの不都合がなければ、改版することは避けることにされていることが多いかと思います。

一方、アジャイル的な開発方式では、テストコードによる品質確保に拠って、リファクタリングなどのコード改変を肯定的に考えられていることが多いようです。

もっとも、実際に導入されている開発現場でリファクタリングが行われるかというと、予算的には難しいことが多いのではないかと推測しますが……

XPプログラミングがリファクタリングで説く「動作を変更せずに、効率やコード記述を改善する」という作業は、対象のソフトウェアが要求される性能を確保しているならば、改悪リスクを伴うだけの金のかかる行為と考えられることも珍しくはないでしょう。

リファクタリング
ソフトウェアの標準と部品化 5

《 技術開発の閑話2 : リファクタリング 》

アジャイル開発

ソフトウェアの標準と部品化 4

14

前回につづいて、ソフトウェア開発に関連した話題です。

アジャイル開発

XP手法やアジャイル開発が注目されていることはご存知の通りです。

従来の手法でコードを開発しているだけでは要求にこたえられないと感じている人が多いことが、アジャイル開発の注目度が上がる要員の１つであると思いますが、もう１つには、アジャイル開発を唄って、ノンドキュメント、設計行為なくただコードを作るという方法が取られている場合もあるようです。

アジャイル開発はドキュメンテーションをなくすということを主張しているものではありません。

　　▼XP(エクストリームプログラミング)
　　　　IT用語辞典 e-Words
　　　　http://e-words.jp/w/XP.html

単に工数を削減するという名目のもとにドキュメントを作成しなかったり、リファクタリングの名のもとに未設計のままコードが作られて、スパイラル開発の名のもとに改版するという行為をアジャイル開発といっている人がいるというに過ぎないのだと思います。

アジャイル開発
ソフトウェアの標準と部品化 4

《 技術開発の閑話2 : アジャイル開発 》

新開発ツールと再生産

ソフトウェアの標準と部品化 3

13

前回につづいて、ソフトウェア開発に関連した標準指向や部品化についての話題です。

技術の二極化

今から１５年ほど前に「今後、ソフトウェアはプラットフォームやライブラリを作るハイエンドの技術者と、それらを使うだけを仕事にする技術者に二極化する」といわれていました。

OS、開発ツールやライブラリが充実したものに拡充されると、それを使って単純なアプリケーションを作成する技術者(?)と、そもそもの高度に専門化したライブラリを設計する技術者に分かれることになるというものでした。

その傾向は、ソフトウェアの標準と部品化の１回目に述べたようにライブラリはデバイスメーカーやOS、開発ツールメーカーに絞られてきている(オープンソースの場合には少し事情が異なりますが)点においては、二極化しているといえます。

実際には、ライブラリのセットが丸ごと入れ替えられたり、主要OSが変遷しているため、ライブラリの充実によって二極化したのではなく、ライブラリを組み合わせて使うだけではアドバンテージが無いため淘汰され、なんらかのアドバンテージを持っていて残っている技術者と初心者が担っているから二極化しているように思います。

新開発ツールと再生産
ソフトウェアの標準と部品化 3

《 技術開発の閑話2 : 新開発ツールと再生産 》

戦術と戦略の誤解

ソフトウェアの標準と部品化 2

12

前回につづいて、ソフトウェア開発に関連した標準指向や部品化についての話題です。今回は、なぜ今さら、部品化と標準化を話題にしようと思ったのかを述べてみたいと思います。

ここ数年で、ソフトウェアの標準化や部品化に関わるムーブメントは、表層的には標準化の動きが大きく、また激しく変化しており、実装を伴う部品化はオープンソースのような形では現れることがあるものの、表面的には沈静しているといえます。

一つに、前回述べましたように、プラットフォームや開発言語などが変化しているため、実装レベルでのソフトウェア部品が即物的には意味をなさないことに起因しているかと思います。

また、それによって、デザインパターンやXP、UMLなどのようにコードの実装ではなく、設計レベルのもう一段抽象化された手法などがその役割を担うものとなり、実装上の共通化については、標準化(もしくはプロジェクトの共通のプラットフォーム)の過程に組込まれれるようにという形にシフトしてきているのだと認識しています。

戦術と戦略の誤解
ソフトウェアの標準と部品化 2

《 技術開発の閑話2 : 戦術と戦略の誤解 》

ソフトウェアの標準と部品化 1

技術・開発の閑話-2-

11

今回はソフトウェア開発に関連した標準指向や部品化についての話題です(専門的な細かい話ではないですが)。

近年は、ソフトウェアのモデル化にUML記法が利用されることが一般化してきているようです。

いくつかの理由がありますがデザインパターンと同様、モデル化、設計の共通の表現としてコミュニケーションやドキュメンテーションを作成するために利用しやすい状況にあるということだろうと思います。

　　▼@IT「5分で絶対に分かるUML」
　　　　(わかる人にしかわかりませんが、平易に簡潔に説明してあります。)
　　　　http://www.atmarkit.co.jp/fjava/devs/01fivemin/fivemin00.html

　　▼IT用語辞典 e-Words : デザインパターン【design pattern】
http://e-words.jp/w/
E38387E382B6E382A4E383B3E38391E382BFE383BCE383B3.html

このような手段や技法、とりわけ標準化が必要となる共通の手法に関しては、ある程度の支持者ができると、宗教的とも言える働きかけを廻りにする人が現れたり、関連した製品などを事業とする企業も勢いづくので、その発言や宣伝では「絶対的」であるかのような表現を用いられることもしばしば見受けられます。

ソフトウェアの標準と部品化 1
技術・開発の閑話-2-

《 技術開発の閑話2 : ソフトウェアの標準と部品化 1 》

• 技術・開発の閑話-2-
  技術開発コラム
• 
• 技術・開発の閑話-2-
  vol.01〜10 技術開発コラム

• サウンドコラム/技術開発コラム
• サウンドコラム
• 音響測定編
• ソフト開発
• 技術開発の閑話2

技術・開発の閑話 -2-

ソフト、ハードウェア 技術関連の雑記

このコラムは無料メールマガジン「アメニティ＆サウンド 音と快適の空間へ」　vol.36〜vol.64(2003年8/21〜2004年11/18)に 音響と開発の関連コラムとして連載していたものを編集掲載したものです。

技術・開発の閑話-2- vol.11〜20 20 F1とコンピュータ技術 後編 技術・開発の閑話-2- 19 F1とコンピュータ技術 前編 技術・開発の閑話-2- 18 ソフトウェアの標準と部品化 8 標準と生産管理 17 ソフトウェアの標準と部品化 7 遺産と再生産 16 ソフトウェアの標準と部品化 6 重要な課題 15 ソフトウェアの標準と部品化 5 リファクタリング 14 ソフトウェアの標準と部品化 4 アジャイル開発 13 ソフトウェアの標準と部品化 3 新開発ツールと再生産 12 ソフトウェアの標準と部品化 2 戦術と戦略の誤解 11 ソフトウェアの標準と部品化 1 技術・開発の閑話-2-

技術・開発の閑話-2- vol.01〜10 10 NHK技研公開 2004 超高精細映像システム 09 Googleローカルファイル検索へ 技術・開発の閑話-2- 08 専門ドメインの基礎範囲 2 高度な統合化による構造変化 07 専門ドメインの基礎範囲 1 技術・開発の閑話-2- 06 Prescottリリース 技術・開発の閑話-2- 05 ＮＤＡと情報公開 技術・開発の閑話-2- 04 エラーとコスト ゼロ除算/ブルースクリーン /XP 03 リアルタイムとベストエフォート 技術・開発の閑話-2- 02 HDD容量の差 天使の分け前(Angels' share) 01 「ありえない」 フェイルセーフと安全機能の連鎖

ソフトウェア開発コラム ： 技術・開発の閑話

ソフトウェア開発と開発ツール関連の雑記

機器組込みのエンベデット・ソフトウェア(ファームウェア)の開発に関連したコラムです。 メールマガジン「アメニティ＆サウンド 音と快適の空間へ」に連載していた技術・開発コラムを編集掲載しています。

技術・開発の閑話 : ソフト開発コラム ファームウェア開発(組込み)の技術 / デバッギング・ミステリー	開発ツールの話 : ソフト開発コラム ソフトウェアの分類 / CPUとDSPのアーキテクチャの違い
プロジェクト初期 ツール評価 : ソフト開発ツールの話 プロジェクト初期のツール評価 / プログラムの動作・ソースの作成 / コード生成　アセンブラ、コンパイラ / 型変換を伴う式評価(コード生成) / 暗黙のライブラリ(コンパイラ生成コード) / 組込みCPUのメモリアクセス / コード生成〜デバッガ	デバッガとICE　ツール評価2 : ソフト開発ツールの話 CPU,DSPの内部の状態モニター / プロセッサ周辺のモニター(メモリ、I/O) / 実行の停止(ブレーク) / シングルステップ実行 / 任意部分の実行 / ヒストリー - 実行トレースとコマンド / 各種ファイルのロード、セーブ / シンボル化

≪ 技術・開発の閑話 ：技術・開発コラム ≫