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

音響システム、機器開発、受託開発などのサービス:技術開発コラム
音響技術と開発 技術開発コラム
DSPボード/基板設計パターン image 映像と振動信号の製作イメージ 無響室 - 音響実験/測定、音響解析 image アナログ回路とオーディ信号処理 イメージ 音声信号波形とデジタルストレージ image

音響技術とソフトウェア、ハードウェア開発

音響と開発 : Sound & Development
株式会社エーアールアイ / ARI
ARI CO.,LTD.

技術・開発の閑話 -2- :技術開発コラム
技術・開発の閑話 -2- : ソフトやハード、技術関連の雑記

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

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

技術・開発の閑話-2-
20
F1とコンピュータ イメージ

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

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

F1とIT技術

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

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

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

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

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

技術・開発の閑話-2-
19
F1とコンピュータ イメージ

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

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

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

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

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

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

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

標準と生産管理

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

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

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

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

標準と生産管理

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

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

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

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

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

遺産と再生産

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

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

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

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

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

比重の変化

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

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

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

重要な課題

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

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

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

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

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

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

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

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

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

リファクタリング

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

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

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

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

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

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

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

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

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

アジャイル開発

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

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

アジャイル開発

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

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

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

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

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

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

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

新開発ツールと再生産

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

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

技術の二極化

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

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

その傾向は、ソフトウェアの標準と部品化の1回目に述べたようにライブラリはデバイスメーカーや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-

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

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

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

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

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

技術・開発の閑話-2- vol.01〜10

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

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

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

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

技術・開発の閑話 :ソフト開発コラム

技術・開発の閑話 : ソフト開発コラム

ファームウェア開発(組込み)の技術 /
デバッギング・ミステリー

開発ツールの話 : ソフト開発コラム

ソフトウェアの分類 /
CPUとDSPのアーキテクチャの違い

プロジェクト初期 ツール評価 : ソフト開発ツールの話

プロジェクト初期のツール評価 / プログラムの動作・ソースの作成 / コード生成 アセンブラ、コンパイラ / 型変換を伴う式評価(コード生成) / 暗黙のライブラリ(コンパイラ生成コード) / 組込みCPUのメモリアクセス / コード生成〜デバッガ

デバッガとICE ツール評価2 : ソフト開発ツールの話

CPU,DSPの内部の状態モニター / プロセッサ周辺のモニター(メモリ、I/O) / 実行の停止(ブレーク) / シングルステップ実行 / 任意部分の実行 / ヒストリー - 実行トレースとコマンド / 各種ファイルのロード、セーブ / シンボル化

≪ 技術・開発の閑話 :技術・開発コラム ≫
3GPP対応 携帯電話開発用音響測定システム
TS 26.131/ 26.132 V5.0に準拠、ITU-T P.50とP501の試験信号、Windows Vista、Windows XP 3GPP対応 携帯電話開発用オーディオアナライザー MTA-02WB-S

《 技術・開発の閑話-2- vol.11〜20 : 音響技術と開発 - 技術開発コラム 》

株式会社エーアールアイ/ARI CO.,LTD.
東京都八王子市横山町6丁目9番 丸多屋ビル8F
tel:042-656-2771 fax:042-656-2654

ARIはアナログ、デジタル音響機器の ハードウェア開発ソフトウェア開発、 製品、受託開発を行なっています。試作、研究開発や特注機器などのソフト、ハード、システムの設計から製造までご相談いただけます。

エーアールアイ会社情報
製品情報と販売
音響と開発・サービス
音響機器メーカーと代理店

ご利用案内 | 免責事項 | ARI 音響と開発のサイトマップ | 株式会社エーアールアイ | 東京都八王子市横山町6丁目9番 丸多屋ビル8F

Copyright(c) 2001-2015 ARI Co.,Ltd. all rights reserved.