|
 |
|
|
|
| レベル： |
|
 |
|
| |
|
|
Doug Ishigaki
IBM
（Rational Edgeより）
Ishigaki氏は、IBM Software Development Platformの自動ツールで作成したサンプル・ビューを用いて、自動化された測定プログラムを活用することにより、ソフトウェア・プロジェクトの管理者が、進捗度の査定、リスクの軽減、チームの生産性の向上をいかに達成できるかを示しています。
ソフトウェア開発の管理は、経験の有無を問わず、あらゆるプロジェクト管理者にとって困難なタスクであり、プロジェクトの進捗度を正確に測定することは、常に難題です。通常、プロジェクト管理者がステータス・データの入手をチーム・メンバーに任せきりにしてしまうと、一貫性のない、不正確で、照会しづらい結果しか得られません。さらに、プロジェクト全体を通じて、経営幹部や機能管理者、クライアントらによって、特定なデータに関する様々なフォーマットによるステータス・レポートが求められる場合があります。チームは、ソリューションの開発に費やす時間よりも、ステータス・レポートを準備するのに、より多くの時間を費やしてしまうことになります。
効果的な自動ソフトウェア・プロジェクト測定プログラムを使用すれば、プロジェクト管理者は、これらの難題により良く対処できるようになります。複数のプロジェクト・エリアでの進捗具合を見極め、開発ライフ・サイクルの早い段階で障害を特定すると共に、面倒なレポート・タスクを軽減することにより、チームの生産性を向上させることができます。
本稿では、このような測定プログラムの使用によって得られる利点について説明し、サポートされるベスト・プラクティスとツールを特定します。本稿では、IBM
Software Development Platformの自動ツールで作成した、経営幹部およびプロジェクト管理者向けのサンプル測定ビューを使用します。
測定は効果的な管理ツールです。測定を活用することにより、意思決定者は、企業や組織の目標、幹部レベルとプロジェクト・レベルでの進捗度や品質、および計画に照らし合わせたパフォーマンスなどに関する重要な問題を正確にモニタリングするために必要な情報を得ることができます。管理者は、測定によって入手したデータを基に、正しい質問を提示し、客観的な情報に基づいて、正しい決断を行うことができます。
本稿では、2003年1月のRational Edge記事“Practical Measurement in the Rational Unified Process （PDF/552KB 英語）”に詳述されていた測定の利点に加え、新たに特定した利点を紹介します。管理者は、測定を活用することによって、以下を実現することができます。
- 効果的なコミュニケーションと見通しの向上
測定は、組織のあらゆるレベルでの利害者間のコミュニケーションをサポートします。客観的な測定により、曖昧さを解消することもできます。また、サプライヤーとクライアントの間で、ステータスに関するコミュニケーションを効果的に図ることができます。
- 問題の早期検出と修正
測定により、プロアクティブな管理を促進し、開発ライフ・サイクルの早い段階で問題を特定し、管理することができます。開発が進んだ段階で発見された問題は、管理が困難で、修正コストも高くつきます。測定を活用すれば、管理者は問題が実際に出現する前に、これを予測し、素早く解消できます。
- 主なトレードオフの決断
1つの領域での決断は、しばしば他の領域にも影響を及ぼします。測定基準を活用すれば、客観的に影響を査定できるため、管理者は、十分な情報を基に、プロジェクトの目標に最適なトレードオフ決断を下すことができます。
- 特定のプロジェクト目標の追跡
測定基準を活用すれば、管理者は、「プロジェクトはスケジュールどおりに進捗しているか？」、「品質は改善されているか？」、「システムはリリース可能な段階か？」などの、具体的な質問を提示することができます。実際の測定を計画に照らし合わせて追跡することにより、管理者はプロジェクトの目標と組織的な目標に関する進捗度を見極めることができます。
- リスク管理
リスク管理は、広く認められているベスト・プラクティスであり、プロジェクト・ライフ・サイクルの早期にリスクを特定、分析します。プロジェクトが進んだ段階で発見されたリスクは、管理が困難で、修正コストも高くつきます。高品質で客観的なデータがあれば、管理者は、サインオフ後の要求変更依頼のようなリスク領域への見通しを立てることができます。要求の変動性を測定し、モニタリングすることにより、リスクが軽減されているか否かを判断することができます。
- 決断の弁護と正当化
管理者は、自らの決断を効果的に弁護し、正当化できなければなりません。主観的なデータと客観的なデータに基づくいずれかの選択が可能な場合、大多数が客観的なデータを選択するはずです。測定基準は、履歴と共に客観的なパフォーマンス・データやトレンド・データ、現在のパフォーマンス・データの他、時間、プロジェクト、リリースなどに関する展望も提供するため、意思決定者は、これらの測定結果を解釈することによって、適切な処置を決断することができます。
- 将来的なプロジェクトの計画
プロジェクト計画において、管理者は、現実的な目標とスケジュールを定め、予算を決定する必要があります。過去のプロジェクトのスケジュールと費用を記録しておけば、管理者は、同様のプロジェクトでのスケジュールやコストの見積もりに必要なデータを入手できます。
ソフトウェア開発を成功させた企業やチームは、再現可能で測定可能なプロセスに従っていたということが、多くの事例によって実証されています。さらにIBM
Rationalでは、これらの企業やチームでのプロセスと測定の関係性について、以下のことを解明しました。開発に成功している企業は、以下を実行しています。
- 最初に、基本となるプロセスを確立する。
- 基本プロセスの副産物である測定基準を使用する。
- 基本プロセスに従い、測定を有効にする。
- 自動化を通じてより客観的な結果を得ることにより、測定欠陥の品質を改善する。
- 測定または追跡可能な測定の属性に変換できる、プロセスのインストゥルメンテーション・ポイントを特定する。
私たちは、多くの組織との提携により、測定とプロセスに関する一般的な問題を特定すると共に、管理者によるソリューションの発見をお手伝いしてきました。
- 一部の組織においては、ソフトウェア開発プロセスに柔軟性がないため、測定がこのプロセスの後回しになっている場合があります。新たな測定が必要な場合は、まず、このようなプロセスを更新または変更する必要があります。この問題を解消するには、プロセスをカスタマイズし、プロセスに直接インストゥルメンテーション・ポイントを組み込みます。インストゥルメンテーションを実行する開発ツールを導入すれば、これらのポイントに簡単にアクセスできるようになります（図1を参照）。自動化ツールを使用すれば、可能な操作と測定結果の収集をより簡単に定義できます。
- 実際の作業が測定に反映されていない場合があります。これは、組織において、プロジェクト予算とスケジュールのみが追跡可能な場合（または、これらのみを追跡するよう設定してある場合）に起こる問題です。これは、タスクに費やした経費や時間に、実際に行った作業が反映されていない場合を指します。たとえば、コードの開発にXドルを費やしたことは分かっても、実際に開発されたコード数が判明しない場合などです。タスクのスケジュールと費用のみを追跡したのでは、生産性を測定できません。この場合も、プロセスを変更し、要求やユース・ケース、設計オブジェクト、コード、テスト・ケース、障害のようなプロセス成果物の測定を追加することにより、時間と経費がどのように費やされたかをより正確に把握し、進捗度を測ることができます。
図1のような自動化ツールを使用すれば、測定をソフトウェア・プロセスの主な構成要素として位置づけ、インストゥルメンテーション・ポイントに容易にアクセスできるようになります。
 |
| 図1: 測定に役立つIBM Software Development Platformのツール |
|
|
私たちの元には、「プロセスをどのように変更し、何を測定すべきか？」というような質問が多く寄せられます。これに対し、私たちは、常々「場合によって異なります」とお答えしています。まず、ソフトウェア開発ライフ・サイクルのどのフェーズで測定を行うかによって異なります。反復開発を行っている場合、推敲フェーズと作成フェーズでは、測定する対象が異なります。また、組織内での役職によっても異なります。事業部長が必要とする情報は、プロジェクト管理者が必要とする情報とは異なります。事業部長なら生産性の向上に関心があるでしょうし、プロジェクト管理者ならスケジュールを達成し、製品の障害数を削減することに関心があるでしょう。
常に、どのような情報が必要であるかを見極めた上で、測定を計画することが重要です。必要な情報は、組織、プロジェクト、チームの目標、課題、リスクによって異なります。さらに、測定結果を利用するユーザーが理解しやすいように、測定を分類することも重要です。本稿では、図1のIBM Software Development Platformに基づいた、管理測定の例を取り上げます。
|
包括的なツール群、実証済みのベスト・プラクティス、プロフェッショナルなサービスを誇るIBM
Software Development Platformを使用すれば、チームは、ソフトウェアやソフトウェア・ベースのシステムの構築、統合、拡張、最新化、導入を容易に達成することができます。IBM
Software Development Platformは、IBM Rational Unified ProcessRまたはRUPRを土台に、反復開発アプローチによるソフトウェア開発ライフ・サイクルを自動化し、統合します。本プラットフォームのツールを活用すれば、アーキテクチャに専念し、継続した品質を確保しながら、変更や資産を管理できるため、企業のソフトウェア開発能力を向上させることができます。
IBM Software Development Platformは、ソフトウェア開発のあらゆる領域で活用できます。
- プロセスおよびプロジェクト管理
管理者は、あらゆるプロジェクトの測定を計画、実装し、企業全体で一貫したプロセスを実現できます。
- 要求および分析
自動ツールを活用すれば、管理者は、ソフトウェア開発ライフ・サイクルを通じて、ビジネスやソフトウェア要件の移り変わりを把握し、管理できるため、リスクを軽減できます。
- 設計および構築
チームは、ビジネス・アプリケーションやソフトウェア製品、システムの構築において、最大限の生産性を達成できます。
- ソフトウェア品質
開発ライフ・サイクルの早期に障害を発見することにより、チームの予測性と品質が向上します。障害を早期発見することにより、より容易に安価な方法で修正できます。
- ソフトウェア構成管理
本プラットフォームには、開発ライフ・サイクルを通じて、ソフトウェア変更や資産を追跡し、確実に管理するためのツールが搭載されています。
IBM Software Development Platformで実装可能な、これらの領域での管理測定の例を見てみましょう。以下の例は、IBM
Rational Team Unifying Platform（IBM Software Development Platformのコンポーネント）に同梱のIBM
Rational® ProjectConsoleを用いて作成したものです。
Rational ProjectConsoleは、プロジェクト・ステータスのレポートを自動化し、様々な自動収集エージェント、カスタマイズ可能なレポート、グラフィカル・ダッシュボードを提供します。測定ビューをカスタマイズし、ドリルダウン方式で根本原因を分析できます。
優秀な測定システムには、組織での情報の必要性を満たす柔軟性が備わっていなければなりません。測定の要件は、Cレベル（CTO、CIO、CEOなど）の経営幹部または業務部長レベルの高度なビューから、プロジェクト管理者レベルの詳細なビューまで、様々です。
通常、経営幹部は高度な情報を必要とします。たとえば、様々なプロジェクトや製品を担当している業務部長は、各プロジェクトのステータスと、主要な進捗度の測定を素早く判断する必要があります。緑、黄色、赤で視覚的に示されるステータス表示が、この高度な情報を明瞭に表します。図2のサンプル表示は、Rational
ProjectConsoleで、各プロジェクトの情報を一覧表示したものです。以下の情報が表示されます。
- Status
計算された値に基づき、特定のしきい値と比較したプロジェクト全体のステータス。実際の計算は、組織またはプロジェクトによって異なります。
- Open High-Priority Change Requests
優先度の高い変更要求の内、現時点で未解決の要求数。本例では、この測定が必要な情報として識別されています。
- Glidepath
検証済みの障害数に対する、検証予定の障害数。リリース計画において、当該プロジェクトでは、本リリースでチームがn個の障害を修復予定であると識別しています。この測定は、目標に対する進捗度の指標となります。
- Test Coverage
テスト済みのコードの割合
- Change Requests to Verify
残りの作業量
図2: エグゼクティブ・ビューによるプロジェクトの一覧表示
図3のエグゼクティブ・ビューは、プロジェクトの健康度を視覚的な（緑、黄色、赤）ステータス表示で表したものです。経営幹部は、プロジェクト名を掘り下げ、各プロジェクトのステータス情報（図4）をさらに詳しく表示することもできます。
図3: 各部署のステータス・レポートのエグゼクティブ・ビュー
通常、プロジェクト・レベルでは、以下の領域が全体的なステータス・レポートに表示されます。
- Project management
コスト、スケジュール、リスク、スタッフの配備など
- Process
適格性、適合性、生産性に関する目標など
- Requirements and analysis
要求、変動性、ユース・ケース開発の進捗度
- Design and construction
ビジネス、設計およびデータベース・モデル、コード開発の完成度や変更
- Software quality
ユニット・テストの進捗度、システム・テストの進捗度、テスト・カバレッジ
- Software configuration management
障害および変更要求の追跡、ベースラインの進捗度、アクティビティー管理
- Engineering support
ツール開発、ソフトウェア開発環境のサポート
- Operations
ハードウェアの可用性
図4に、プロジェクト管理者ビューの例を示します。
図4: 全領域の高度なステータス・レポート（プロジェクト管理者向け）
管理者は、図5に示すような領域まで掘り下げ、プロジェクト管理における以下のカテゴリーのステータス情報を入手することもできます。
- Highlights and issues
アクションアイテムや課題の特定、分析および追跡
- Planning and schedules
プロジェクト計画やスケジュールをモニタリングし、計画に対する進捗度（これまでに完了した作業）を追跡します。有用なスケジュール表示として、図6のスケジュール・パフォーマンス指標（SPI）があります。SPIは、計算によって算出される指標です。SPIが1を上回っている場合は、プロジェクトが予定より進んでいることを示しており、1を下回っている場合は、予定より遅れていることを示しています。
- Cost and earned value
プロジェクトのライフ・サイクルを通じて、経費管理を行います。有用なコスト表示として、図6のコスト・パフォーマンス指標（CPI）があります。SPIと同様、CPIは計算による指標です。CPIが1を上回っている場合は、プロジェクトが予算を超過していることを示し、1を下回っている場合は、予算以内であることを示しています。
- Staffing
プロジェクトの推進力や士気の指標として、プロジェクト・メンバーの追加や削減をモニタリングします。メンバー数が急激に増加した場合は、新しいメンバーに今の状況を把握させる必要があるため、プロジェクトの進捗度が低下する場合があります。優秀なチーム・メンバーの削減率が低い場合は、プロジェクトの成功の兆候とみなせます。交代数が多い場合、士気や意欲面での問題を示している場合があり、プロジェクト管理者にとっては、要注意の兆しと言えます。
- Risk
プロジェクトの成功を脅かすようなリスクを、継続して特定、分析および追跡します。プロアクティブなリスク管理により、プロジェクトが成功する確率が上がります。
- Compliance
標準やプロセスの改善目標に対する適格性を追跡します。
- Customer satisfaction
顧客のニーズが満たされていることを確認します。
プロジェクト管理者は、このリストから、モニタリング対象のカテゴリーを選択することができます。
図5: プロジェクト管理ステータス・レポート
図6: コスト・パフォーマンス指標（CPI）とスケジュール・パフォーマンス指標（SPI）
図7は、計画に対する進捗度を示したものです。自動プロジェクト計画により、タスクを特定し、スケジュールの完了日付を割り当てることができます。IBM
Rational ProjectConsoleを使用すれば、完成に向かって作業を進めながら、プロジェクト計画におけるタスクの進捗度を追跡できます。
図7: タスクの進捗度 - 予定のタスクと完了済みのタスクの比較
プロセス・エリアで、プロジェクト管理者は、以下に関する詳細なステータス情報を入手できます。
- Highlights and issues
アクションアイテムや課題の特定、分析および追跡
- Planning and schedules
プロセスのロールアウトに向けたプロジェクト計画やスケジュールのモニタリング
- Cost and earned value
経費と成果の追跡
- Staffing
プロジェクト・メンバーの追加や削減の追跡
- Risk
リスクおよびリスクの軽減に向けた取り組みの特定、分析および追跡
- Compliance
標準やプロセスの進捗目標に対する適格性の判断
- Defects contained
特定期間または特定リリースで検出、修正された障害をモニタリングします。この測定は、テスト有効性の指標となります。
- Defects escaping
リリース後に発覚した障害の測定。この測定は、ソフトウェア開発プロセスでの問題の指標となります。
- Scrap and rework
ソフトウェア・ベースラインへの変更量のモニタリング。健全なプロジェクトでは、変更量が下向きまたは横ばいになります。作業のやり直しが増えているということは、保守の必要性とコストが増加するという予兆でもあります。図9は、破棄されたコード行を示したものです。ただし、不用品ややり直しは、コードだけにとどまりません。これらは設計の変更に起因している場合もあり、設計モデルでこのような傾向が伺える場合があります。
- Productivity
基本プロセスの生産性が向上しているか否かを判断
図8は、プロセスの高度なステータス・レポートを緑、黄色、赤で視覚的に示したものです。
図8: プロセス・エリアのステータス・レポート
図9: 廃棄率 - 削除されたコード行による測定
要求および分析には、プロジェクトのライフ・サイクルを通じた、問題空間の把握、移り変わる要求の捕捉と管理、ユーザー・インタラクションのモデリング、利害関係者からのフィードバックの反映が伴います。優秀な要求と分析の慣行によって、プロジェクト・リスクを軽減させることができます。
要求および分析では、以下の領域をモンタリング、測定します。
- Highlights and issues
要求および分析におけるアクションアイテムとリスクの軽減
- Planning and schedules
計画と実際の要求の対比、またはスケジュールに対する開発済みのユース・ケース
- Cost and earned value
要求および分析における予算の追跡
- Requirement reviews
要求の進捗度と、利害関係者によるレビュー
- Use-case reviews
ユース・ケースの進捗度と、利害関係者によるレビュー
- Inspections
要求の検証
- Requirements volatility
要求の変更は、スケジュールとコストに影響を及ぼします。この測定の詳細については、図13を参照してください。
プロジェクト管理者向けの高度なビューでは、各領域を緑、黄色、赤でステータス表示できます（図10を参照）。
図10: 要求および分析の高度なスタータス・ビュー
図11の要求サマリーや、図12のユース・ケース・サマリー（いずれもIBM Rational RequisiteProから引用）を活用すれば、要求および分析開発の進捗度をさらに詳しく把握することができます。
図11: Requirements summaryビュー
図12: Use-case summaryビュー
図13: Requirements churn（変動性） - リビジョン数による測定
設計および構築には、設計の図案やモデリング、モデル駆動型開発、ソフトウェア・コーディング、障害の修正や拡張要求への対応、コンポーネント・テストが伴います。
設計および構築では、以下の領域をモニタリングします。
- Highlights and issues
アクションアイテムおよびリスクの軽減
- Planning and schedules
予定の設計要素やソース・コードと実際の成果物の対比、およびスケジュールに対する対比
- Staffing
開発スタッフの追加や削減。大規模なプロジェクトにおいては、この測定が重要です。
- Cost and earned value
経費と予算の追跡
- Design model completeness
アーキテクチャや設計モデルの完成度、または設計モデルの進捗度（トレンド）。図15を参照してください。予定値と対比（表示なし）できるのが理想です。
- Size at complete
進捗度を示すコード開発のトレンド（図16を参照）。開発済みの実際のコードと予定値の対比（表示なし）により、残りの作業量を判断できるのが理想です。
- Software inspections
品質やパフォーマンスに影響を及ぼす恐れのある製品の障害や不整合、不安定な箇所を発見するために行う、ピア・レビューによる検証
- Requirements volatility
リリース・スケジュールに影響を及ぼしたり、ソフトウェアのやり直しやコストの増加につながるような変更要求
- Open problems and originating dates
未解決の問題レポートの数と経過期間。スタッフの配備が適切か否かを判断する指標となります。
図14は、プロジェクト管理者向けの設計および構築の高度なステータス・ビューを、緑、黄色、赤で視覚的に示したものです。
図14: 設計および構築の高度なステータス・ビュー
図15: 設計モデルの完成度（開発済みのクラスによる測定）
図16: 開発済みコードのソース・ライン（SLOC）合計のトレンド
ソフトウェア品質の確保には、機能、信頼性、パフォーマンスのテストが伴います。また、あらゆるテストの実施を追跡し、リリース予定のアプリケーションに求められるすべての機能がテスト済みであることを確認します。
ソフトウェア品質では、以下の領域をモニタリングします。
- Highlights and issues
アクションアイテム、課題、およびリスクの軽減
- Planning and schedules
予定のテスト・ケースと実際の成果物の対比、およびスケジュールに対する対比
- Staffing
テスト・チームでの追加や削減
- Cost and earned value
予算の追跡
- Unit testing
予定されているテスト数、実施されたテスト数、合格したテスト数、進捗度を判断できなかったテスト数
- System testing
予定されているテスト数、実施されたテスト数、合格したテスト数、失敗したテスト数（図18および19を参照）
- Performance testing
スループットまたは応答時間
- Defects
顧客によって報告された障害（図20）またはすべての障害（図21）の追跡
ソフトウェア品質では、プロジェクト管理者は、緑、黄色、赤の視覚表示による高度なステータス・レポート（図17を参照）を表示できます。
図17: ソフトウェア品質の高度なステータス・ビュー
図18: テスト・ステータス（トレンド・チャート）
図19: 反復別のテスト・ステータス
図20: 障害追跡 - 顧客によって報告された障害
図21: 重大度別の障害追跡
ソフトウェア構成管理には、ソフトウェアの変更や資産の捕捉、制御および管理を伴います。また、障害および変更の追跡や、ソフトウェア資産の管理が含まれます。
ソフトウェア構成管理では、以下の領域をモニタリングします。
- Highlights and issues
アクションアイテムおよびリスクの軽減。通常、プロジェクトのあらゆる領域で必要です。
- Planning and schedules
開発予定のソース・コードと実際の成果物との対比、およびスケジュールに対する対比
- Staffing
構成管理スタッフの追加や削減
- Cost and earned value
予算の追跡
- Defect status
目標とする障害ステータス
- Enhancement status
開発中の機能のステータス
- Build status
ビルドの完成度
- Code churn
構成済みまたはベースライン済みのソフトウェアに追加、変更、削除された行数（図23）。この測定は、ビルドやリリースの完成度を示します。このような追加・変更・削除行の増加は、リリース「準備が整っていない」ことを示しています。
図22は、これらのソフトウェア構成領域のステータスを示す、高度なプロジェクト管理者向けのビューです。
図22: ソフトウェア構成管理ステータスの高度なビュー
図23: 構成済みソフトウェアのコード・チャーン
管理者は、測定を利用することによって、進捗度を査定し、進行するプロジェクトの品質を見極めながら、客観的な意思決定のためのデータを入手することができます。測定によって、プロジェクトの成功が確約されるわけではありませんが、測定を活用することにより、意思決定者は、プロアクティブなアプローチによって、ソフトウェア・プロジェクト特有の重大な課題を管理することができるようになります。
本稿では様々な測定ビューを紹介しましたが、成功へのカギは、本稿で紹介したすべての測定を実装することではありません。むしろ、プロジェクトと組織を評価し、利害者のニーズを特定することにより、このようなニーズを満たすための測定と指標を特定し、重要な管理上の決断に必要な客観情報が得られるような、煩わしくない程度の自動測定プログラムを実装することが重要です。
IBM Software Development Platformの詳細については、IBM Webサイトをご覧ください。
IBM Rational ProjectConsoleの詳細については、IBM Team Unifying Platformページをご覧ください。
参考文献
Doug Ishigaki and Cheryl Jones, "Practical Measurement in the Rational
Unified Process." The Rational Edge, January 2003.
John McGarry, David Card, Cheryl Jones, Beth Layman, Elizabeth Clark, Joseph
Dean, and Fred Hall, Practical Software Measurement: Objective Information
for Decision Makers. Addison-Wesley, 2002.
Philippe Kruchten, The Rational Unified Process: An Introduction, Second
Edition. Addison-Wesley, 2000.
IBM Rational Unified Process 2003.06.12. IBM, 2004.
Practical Software and Systems Measurement Web site （includes the PSM
Insight tool）: http://www.psmsc.com.
ISO/IEC 15939 Software Measurement Process. International Organization
for Standardization, 2002.
Software Engineering Institute, "Capability Maturity ModelR Integrated
（CMMI（sm）） for Systems Engineering, Software Engineering, Integrated
Product and Process Development, and Supplier Sourcing, Version 1.1 Staged
Representation." Carnegie Mellon University, March 2002.
Walker Royce, Software Project Management: A Unified Framework. Addison-Wesley,
1998.
著者について
Doug Ishigaki氏は、1996年にRational Softwareに参加して以来、主にRational
ProjectConsoleの研究と開発に取り組んでいます。Ishigaki氏は、上級テクニカル・マーケティング・エンジニアとして、IBM
Rational ProjectConsoleの理解と導入に関する顧客支援を行っています。氏は、Rationalに参加する以前、TRW,
Incにおいて、大規模なリアルタイム分散型システムや市販ミドルウェア製品のあらゆる開発フェーズに携わっていました。カリフォルニア大学ロスアンゼルス校で言語学/コンピュータ・サイエンスの学位を取得しています。
|
|
|
|
|
