ObjectSquare [2011 年 12 月号]

[技術講座]


IEEE Software July/August 2011 目次と要旨(日本語訳)

翻訳:株式会社オージス総研 アジャイル開発センター 藤井拓

本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。



IEEE Software

私たちの使命: 先導的なソフトウェアの実践者のコミュニティを作るために, IEEE Software誌は迅速な技術の変化についていかなければならない思慮深い開発者やマネージャーに対して先進的なアイデアや専門家の分析,確かなアドバイス,思慮深い洞察を提供します. ソフトウェアの理論を実践へと翻訳するオーソリティです.

July/August 2011 (Vol. 28, No. 4):ソフトウェアビジネス( Software Business)

謹んでIEEE SoftwareJuly/August 2011 (Vol. 28, No. 4)号の目次と要旨をお送りします. 各号では無償の記事(英語)やポッドキャスト(英語)がいくつか提供されており, それらは要旨の下のリンクから入手することができます. 残りの技術的な記事を入手するために, 英語の印刷版[www.computer.org/subscribe/sw-jp] を通常価格の25%引き, またはデジタル版[www.qMags.com/ISW/jp]を US$19.95 で購読することができます.お問い合わせは, 編集長であるDale Strok (dstrok@computer.org)宛てに電子メールでお願い致します.

目次

編集者から (FROM THE EDITOR)
希望的観測からの防御(“Protection from Wishful Thinking” )

Forrest Shull

新たなソフトウェア開発の手法、プラクティス、ツールについていくのは最善の状況でも努力を要するが、今日の厳しい経済状況でそれについていくことがさらに差し迫ったものになっている. 本記事では、時代遅れにならないために役立つと思われたメディアの種類に関してソフトウェア開発者に行った調査を論じ、それらのメディアに対する高いレベルのテーマを記したものである. これらのテーマに基づいて, IEEE Software誌のデジタルコンテンツの重要な変更のいくつかを説明する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.80(無償)

レター (LETTERS)

IEEE Software 誌のMarch/April 2011号に掲載されたDiomidis Spinellisの「 a Tools of the Trade」コラムに対するPhillip G. Armourの返信であり,ソフトウェア開発のコーディングスタイルについて論じている. もう1つのレターでは, March/April 2011号に掲載されたForrest Shull の編集者のコラム"Perfectionists in a World of Finite Resources"に対するStefan Braunの返信であり,ソフトウェア開発の世界における技術的負債の概念について論じている.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.74(無償)


特集:ソフトウェアビジネス(FOCUS: SOFTWARE BUSINESS)

ゲスト編集者によるビジネスとしてのソフトウェア入門( “Guest Editors' Introduction: Software as a Business”)

John Favaro, Shari Lawrence Pfleeger

ビジネスのほとんどの側面でソフトウェアはますます重要な役割を担っている. ソフトウェアをサービスとして販売することからオフショアへの開発委託やクラウドでの開発委託に至るまで, ここ10年間においてソフトウェアの比重が高い企業に対する新たなビジネスモデルが多数登場した. 政府や標準化団体も産業界の成長を促進するためにそれらのビジネスモデルに影響を及ぼすように介在してきた. ソフトウェアビジネスには,イノベーションマネジメントのような新分野を生み出すような付随的な効果もあった. ソフトウェアがより多くの製品に組み込まれるにつれて,知的財産権のマネジメントがさらに大きな課題になってきた. ソフトウェアビジネスは他のビジネスと根本的に異なるのかという議論は, ソフトウェアビジネス自身が自分を変え続けるのかという点についても, 続くだろう.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.77(無償)

ソフトウェア産業のビジネスモデル(“Software Industry Business Models”)

Karl Michael Popp

ソフトウェア会社は,成功した企業のビジネスや収益モデルを利用して競争上の優位点を作ることができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.52(印刷版またはデジタル版を有償購読可能)

オープンソースライセンスと対応するビジネスモデル(“Matching Open Source Software Licenses with Corresponding Business Models”)

Juho Lindman, Matti Rossi, Anna Puustell

顧客に対するサービスを向上するために多くのソフトウェア製作会社がオープンソースライセンスへと方向転換した. それらの会社において, 適切なライセンスを選ぶかどうかでビジネスの成功が左右される. 利用可能なオープンソースのスタックやライセンスの選択肢が増えるとともに, ライセンスと外部委託とビジネスゴールの間の関係の理解が必要になる. ライセンス選択のモデルにより, 異なるライセンスの違いが明確になり, オープンソースソフトウェア (OSS) ライセンスを合理的に選択することができる. これは, OSSを採用する毎にその結果として起こりえることを徹底的に調べるためのツールや知識がない小さな企業や起業したばかりの会社にとって大事である.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.50(印刷版またはデジタル版を有償購読可能)

顧客とソースコードを共有する:ハイブリッドなビジネスと開発モデル(“Sharing Source Code with Clients: A Hybrid Business and Development Model”)

Mikko Riepula

オープンなイノベーションと近年の顧客の巻き込みの重視により, ソースコードの限定的な開示と伝統的な価値の割り当てロジックを組み合わせたハイブリッドなソフトウェアライセンスモデルが出現しそうである. 現実的なハイブリッドライセンシングモデルは, 垂直なドメインのビジネス-to-ビジネスソフトウェアベンダーとバラバラの製品もどきを保守しなければならないコンサルタント業の両方のニーズに対応するものである. 中心となるアイデアは, 製品となったプロダクトのベンダーがソースコードを限定された顧客にライセンスし, その顧客も当事者になり,閉じた開発コミュニティを存続させるための参加者になるというものである. ツールやテクニックについてはオープンソース開発のものをそのまま使えるだろうが, 動機や関係のマネジメントは純粋なオープンソースの世界とは異なる動きをする.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.53(印刷版またはデジタル版を有償購読可能)

クラウドビジネスモデルを開発する:クラウドゲームの事例(“Developing Cloud Business Models: A Case Study on Cloud Gaming”)

Arto Ojala, Pasi Tyrvainen

クラウドコンピューティングにより企業がグローバルマーケットでオペレーションをする新たな方法が提供されたことで,小企業でもこれまで多国籍企業が大勢を占めていたマーケットで競合できるようになっている. 事例では, 小さな企業が10年以上の期間に渡り, コンピュータゲーム分野で競争するために有効なビジネスモデルをどのように築いたかを考察する.クラウドコンピューティングにより企業がグローバルマーケットでオペレーションをする新たな方法が提供されたことで,小企業でもこれまで多国籍企業が大勢を占めていたマーケットで競合できるようになっている. 事例では, 小さな企業が10年以上の期間に渡り, コンピュータゲーム分野で競争するために有効なビジネスモデルをどのように築いたかを考察する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.51(印刷版またはデジタル版を有償購読可能)


通常記事

主要記事:アジャイル開発を管理する(FEATURE: MANAGING AGILE DEVELOPMENT)
プロセスよりも人々:アジャイル開発における大きな課題(“People over Process: Key Challenges in Agile Development”)

Kieran Conboy, Sharon Coyle, Xiaofeng Wang, Minna Pikkarainen

アジャイル開発手法への移行の初期に開発者がいくらかの「当初の困難」を経験するかもしれないものの, アジャイル開発手法により開発者がより幸せになり, 熱心になり, 最終的にはより生産的になるという共通認識がある. しかしながら, この信念が正しくない場合もある. アジャイル開発を使い始めて3年以上の17の大きな多国籍組織の事例を通じて「人間系」の深刻な課題が多く認められた. 課題はアジャイル開発の要員の採用からトレーニング, 動機付け, 業績評価にまで及ぶ.これらの調査の過程で判明したベストプラクティスに基づいて, 組織がこれらの課題を克服するための実践可能な推奨内容が研究の結果として得られた.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.132 (印刷版またはデジタル版を有償購読可能)

主要記事:ソフトウェア学位プログラム(FEATURE: SOFTWARE DEGREE PROGRAMS)
ソフトウェア工学のプロフェッショナル教育を進歩させる(“Advancing Software Engineering Professional Education”)

Mark Ardis, Pierre Bourque, Thomas Hilburn, Kahina Lasfer, Scott Lucero, James McDonald, Art Pyster, Mary Shaw

ソフトウェアシステムの重要性と複雑さのため,そのようなシステムを開発し, 保守し, 購買するための適切なスキル, 知識, 経験がソフトウェア開発者にもとめられている. プロフェッショナルソフトウェア工学を進歩させるための鍵は大学院教育である. "Graduate Software Engineering 2009 (GSwE2009): ソフトウェア工学の大学院学位のカリキュラムガイドライン" は修士のプログラムに対する新たなリファレンスカリキュラムである. そのカリキュラムではGSwE2009 のガイディング原則や事前知識, 学生の結果, カリキュラムアーキテクチャ, 中心的な知識体系が特色になっている.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.133(印刷版またはデジタル版を有償購読可能)

主要記事:プロジェクトの見積もり(FEATURE: PROJECT ESTIMATION)
iUCP :拡張されたユースケースポイントでインターラクティブなソフトウェアプロジェクトの規模を見積もる(“iUCP: Estimating Interactive-Software Project Size with Enhanced Use-Case Points”)

Nuno Jardim Nunes, Larry Constantine, Rick Kazman

提案された手法は, ユースケースポイント法(UCP)をインターラクティブなソフトウェアのアジャイル開発に適合させたものである. 開発初期にプロダクトの費用見積もりを作成するためには, 開発者は弛まぬフィードバックや細かい調整とともに, 見積もりを左右する概念に合意し, 過去プロジェクトの膨大なデータを頼りにしなければならない.見積もり者の一貫性を高めるために, インターラクティブUCP (iUCP) は利用中心設計の概念に基づいて抽出される情報を利用する. 本方法は複雑度の係数をアクターとユースケースに割り当ててそれらの係数から要求の複雑度を反映した未調整UCPを算出する. 複雑なアクターは, ユーザロールに基づいて重みづけされる. ユースケースは, ユーザの意図とシステムの責務で表現される本質ユースケースのステップ数と利用中心設計のアーキテクチャから抽出された分析クラスに基づいて重みづけされる. 経験に基づく研究では, iUCP 法に基づく見積もりがUCP法に基づく見積もりよりも一貫性が高いという結果が得られた.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.111(印刷版またはデジタル版を有償購読可能)

主要記事:研究とプラクティス(FEATURE: RESEARCH AND PRACTICE)
アジャイル連携リサーチ:産学連携のアクション原則(“Agile Collaborative Research: Action Principles for Industry-Academia Collaboration”)

Anna Sandberg, Lars Pareto, Thomas Arts

企業も学校も単独では解決できない課題を一緒に解決するための連携を促進している. 連携により単独では不可能なやり方で理解し, 改善する機会が提供されるが, それが成功するのは双方が貢献する場合だけである. 産業界のニーズに明示的に焦点を合わせたリサーチセンターを8年間に渡り, 設立し, 管理した経験に基づいて作り上げた連携モデルは, 研究成果を上げるための5つの成功要因 (ニーズ指向, 企業のゴールとの整合性, 配置のインパクト, 企業のメリット, 革新性)と , 研究活動を可能にする5つの成功要因(上役の関与, ネットワークアクセス, コラボレータの相性, コミュニケーション能力, そして継続性), 企業と学校の連携管理のための10のアクション原則に基づいている.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.49(印刷版またはデジタル版を有償購読可能)


分野別記事(DEPARTMENTS)

アーキテクチャについて(ON ARCHITECTURE)
新ワトソンの精神(“The Soul of a New Watson”)

Grady Booch

システムのアーキテクチャの説明を作成し, 整理し, そして管理することで, そのシステムの意図の理解, 推測, 変換が促進される. このことはレガシーシステムのみならず新システムでも成り立ち, 実験的なシステムでも実用システムでも成り立つ. IBMの推論システムであるWatsonは, 新しくも実験的でもあるということでそのようなシステムである. アーキテクチャを管理することで大きな効能が得られる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.85(印刷版またはデジタル版を有償購読可能;
www.computer.org/portal/web/computingnow/onarchitectureで無償のポッドキャストとして提供)

洞察:リストラクチャリング(INSIGHTS: RESTRUCTURING)
コード拾い上げ棒(“Code Pick-Up Sticks”)

Daniel Brolund, Ola Ellnestam

“ストックホルムの夕食でDanielとOlaの洞察を初めて聞いたとき, 私は大規模レガシーシステムについての多くの経験を思い出しました. 最初は短期間でできるだろうと思い, 徐々に 穴がどんどん深くなり, 最終的には引き返して多くの仕事が無駄になったことを思い出しました.私自身は彼らの解決策に行き当りませんでしたが, その解決策がどれほど強力であるかはすぐに想像できました. あなたもこのスカンジナビアの武勇伝に共感することを祈ります!”−Linda Rising, 洞察の編集者
https://doi.ieeecomputersociety.org/10.1109/MS.2011.73 (印刷版またはデジタル版を有償購読可能)

証拠の声(VOICE OF EVIDENCE)
グローバルソフトウェア開発における証拠のささやき(“A Whisper of Evidence in Global Software Engineering”)

Darja Smite, Claes Wohlin

2000年から2007年までのグローバルソフトウェア開発(GSE)の文献を系統的にレビューした結果, この分野が未成熟であることが分かった. 複数の研究が多くの課題を報告しているものの, 特定のGSEのプラクティスがプロジェクトの直接的な成功や失敗に関係したかどうかに関する証拠は少ない. 距離が問題になるということ, さらにはコスト削減という目的を目指しているのにも関わらず, GSEで費用削減は滅多に達成されていないという証拠はある.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.70(印刷版またはデジタル版を有償購読可能)

インパクト(IMPACT)
短く曲がりくねった道:カーナビゲーションシステムのソフトウェア(“Short and Winding Road: Software in Car Navigation Systems”)

Han Schaminee, Hans Aerts

TomTomは, 自動車業界向けに品質を重視した伝統的なリスク回避で遅いソフトウェア開発プロセスから携帯電話業界で導入されたような高速で革新的なソフトウェア開発プロセスへの移行を支援していた.そのために, TomTomはアジャイル開発アプローチと仕様とスケジュールバッファの明示的な管理との組み合わせを採用することで品質に妥協することなくリードタイムの短縮を達成しようとした.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.83(印刷版またはデジタル版を有償購読可能)

要求(REQUIREMENTS)
今何時だい? エクレス君(“What Time Is It, Eccles?” )

Neil Maiden

要求分析者には, アジャイル開発や利用中心設計のWebの分析, ワイヤーフレーミング, ユーザストーリーのようなテクニックを含む適切な道具とそれらの道具を使うための手引を備えた新たな道具箱が必要になっている. さらに, 創造性に関する文献にも目を留め, 制約の除去, ストリーテリング, その他の世界のようなテクニックを採用することもできる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.86(印刷版またはデジタル版を有償購読可能;
www.computer.org/portal/web/computingnow/software-requirements-talkで無償のポッドキャストとして提供)

ソフトウェア技術(SOFTWARE TECHNOLOGY)
要求工学ツール(“Requirements Engineering Tools”)

Juan M. Carrillo de Gea, Joaquin Nicolas, Jose L. Fernandez Aleman, Ambrosio Toval, Christof Ebert, Aurora Vizcaino

要求工学(RE) のプロセスを容易にし, 要求, 変更管理, 追跡可能性をより系統的できっちりと取り扱うために要求工学ツールの使用が増えている. 要求工学ツールを評価している開発者や企業にとって,どの 要求プロセスがサポートされており, 自分自身の優先度にどのように適合するのかという点を知ることが欠かせない. その回答を得るのは簡単ではない. というのは, 多くの営業担当者は多くの特色を取り上げるものの, それらがどの程度サポートされており, すべての特色に実際に意味があるかどうかについては触れないからである. 現在の要求工学ツールがどの程度要求工学作業に適合しているのかを理解するために,われわれは 要求工学ツールの機能を評価するための新たな枠組みであるISO/IEC TR 24766:2009を網羅する146項目の調査を行った. 主要なツールすべてを網羅する37件の回答を得た.各作業におけるツールの点数に加えて, 具体的な利用シナリオにおける性能も評価した. われわれの調査結果は実践者が要求工学ツールを選ぶ際に役立つだけではなく, 要求工学ツールの開発者に改善点を提供するのにも役立つ.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.81(印刷版またはデジタル版を有償購読可能)

現実的なアーキテクト(THE PRAGMATIC ARCHITECT)
アーキテクチャをガーデニングしよう, パート1:リファクタリング(“Gardening Your Architecture, Part 1: Refactoring”)

Frank Buschmann

リファクタリングには一般的なプラクティスで言われているよりも, もっと正確な定義がある: あるシステムの一部の機能的な振る舞いを変えずに開発上の品質を向上させる変更である. リファクタリングはコードの詳細に留まらず, システムのソフトウェアアーキテクチャというより大きなレベルに至ることもある. それでもリファクタリングは品質の改善に役立つのに留まる.リファクタリングを気ままに, 行き当たりばったりに実践したり, システムに対する, あらゆる形の変更と同義語に使うと, 弊害が利点を上回りかねない.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.76(印刷版またはデジタル版を有償購読可能)

商売道具(TOOLS OF THE TRADE)
アジリティを促進するもの(“Agility Drivers”)

Diomidis Spinellis

複雑なソフトウェアを素早く作り上げるという我々の発展しつつある能力により, 開発の途上で顧客の話を聞いたり, 新たなことを試したり, 間違いを犯したり, 設計を変更することが可能になった. 短く言えばアジャイルになるということだ. 技術的な面でアジリティを促進するものは, パワフルなオペレーティングシステム, 広範な可用性を備えたデータベース管理システム, 幅広い選択肢を提供するライブラリ, 相互運用性の標準, 用途の広いプログラミング言語, 豊富なプロセッシング力, 洗練された開発ツールである. 環境の面でアジリティを促進するものは, 専門的な教育, 形式にとらわれないマネジメント構造, Webアクセス, オープンソースソフトウェア, ユーザの期待の変化, 利用場所を問わないITインフラである. アジリティを促進するものがある場合には, 自分たちの開発プロセスを調整し, ソフトウェア供給者に求めるものを増やし, ユーザや顧客を喜ばせ, 虜にしさえするようなアプリケーションやサービスを系統的に成長させるための自前の能力を開発しなければならない. https://doi.ieeecomputersociety.org/10.1109/MS.2011.72(印刷版またはデジタル版を有償購読可能−近々無償のポッドキャストとして提供)




© 2011 OGIS-RI Co., Ltd.
Index Next
Index Next