法令遵守を意識したアジャイル

医療機器メーカーのための現実的アプローチ

IBMとDiagnostic Grifols社の専門家が、厳格に規制を受ける医療機器の領域においてDiagnostic Grifols社がいかにアジャイル・ソフトウェア開発アプローチを活用しているかを説明します。彼らは、「多くの開発組織は、規制を受ける環境においてはウォーターフォール型アプローチを取る必要があると信じているが、なぜそうではないかを示したい」と語っています。

Keith Collyer, PhD, シニア・ソリューション・マネージャー, 電子・医療機器・産業ソリューション, IBM

author photoKeith Collyer博士は、要求およびシステムズ・エンジニアリングの領域エキスパートです。彼は、電子工学技術者としてトレーニングを積み、その後ソフトウェア開発に従事しました。”人”の側面に興味があり、プロジェクト管理、品質保証、プロセスに目を向けるとともに、実際のニーズを満たすシステムの開発という視点も忘れずにやってきました。自身のキャリアのかなりの部分において、大小を含む組織に対して要求管理を定着させるのを支援してきました。そこで大切なことは、顧客が要求管理の必要性と利益を理解すること、そこに含めるべきプロセスを顧客とともに明確にして定義すること、必要な情報や相互関連を取り込んでいくこと、そして、顧客のニーズを最良にサポートすべくIBM Rational DOORSでの実現を設計していくことです。



Jordi Manzano, ソフトウェア品質保証マネージャー兼R&Dディレクター代理, Diagnostic Grifols

Author1 photoJordi Manzanoは、およそ15年にわたるメディカル・セクターでのシステムおよびソフトウェア開発の経験を持っています。これまで、エンジニア、プロジェクト・マネージャーとして従事し、現在は、グローバルなヘルスケア企業である Grifolsのソフトウェア品質保証マネージャー兼R&Dディレクター代理の立場にあります。彼の経験は、免疫血液学における体外診断用検査機器、免疫および止血剤、血管造影装置および臓器灌流装置、調剤機器、などを含んでいます。彼の技術的専門領域は、システムおよびソフトウェア開発、プロジェクト管理、ソフトウェア・ライフサイクル・プロセス開発であり、特に規制を受ける環境におけるベストプラクティスの効果的な実施に重きを置いています。



2013年 9月 13日

はじめに

この記事は、アジャイル開発の実践法が、高度に規制を受ける医療機器の領域で採用されうるかについて述べています。このアプローチは、規制を受ける他の領域においても容易に採用することができます。

医療機器の法規制が固定的なライフサイクル・モデルを強制するということはないものの、(なすべき)活動が逐次的な形で提示されており、ウォーターフォール・プロセスを暗示しているかのようです。その一方、10年か、それ以上にわたり、世のソフトウェア・チームはアジャイル開発手法に有用性を見出しています。幾つかの医療機器メーカーは、開発において規制を遵守しつつアジャイル実践法を採用しています。しかし、両者の折り合いがつかず、アジリティ(機敏さ)か正式な手順を踏むかで何らかの意思決定が必要になることもあります。医療器具開発協会 (Association for the Advancement of Medical Instrumentation, 略して AAMI) では、TIR45という技術情報レポートを新しく発行し、医療機器開発におけるアジャイル実践法の利用のガイドを提供しています(参考文献セクションのリンクを参照)。この「医療機器ソフトウェア - ソフトウェア・ライフサイクル・プロセス」というレポートは、IEC62304の活動をあるアジャイル開発プロセスに対応付けることで、この話題への新しい知見を与えています(参考文献セクションを参照)。

この記事では、以下のことが明らかになります。

  • Diagnostic Grifols社が如何にこのレポートを念頭に彼らの実践法を発展させてきたのか。
  • Diagnostic Grifols社がアジャイルかつ法令に遵守したやり方をした上で、如何に生産性に関して大きな利得を得たのか。
  • 同様な方法が規制のある他の業界で如何に適用可能か。

Diagnostic Grifols社は、最近、重要なアメリカ食品医薬品局(FDA)の監査を受け、特に大きな問題を指摘されることもなく合格しました。この監査は、Diagnostic Grifols社がアジャイル・アプローチにて開発するソフトウェアも対象としていました。


規制における原則, 活動, 成果物

規制の監督の仕方には、大きく分けて、「規範的 (prescriptive)」と「記述的 (descriptive)」という二つのアプローチがあります。

  • 規範的アプローチにおいては、規制は「何をしなければならないか」そして多くの場合「それをどのようになすべきか」を明確に示す。
  • 記述的アプローチにおいては、規制は「何を達成しなければならないか」を明確に示し、それをどのように達成すべきかに関してはほとんど規制を受ける組織に任せる。

このこと(後者)は、施行の厳格さが緩められるということを意味しません。実際ほとんどの場合、規制に関する検定は、より探索的に行われます。なぜなら、検定を受ける組織は、単に書類のチェック項目を埋めるのではなく、検査官に対して実際のそのような結果がどのように達成されたものかを正確に説明することを求められます。

規制者側は、最近ますます記述的アプローチに変化をしてきています。このことはFDA品質システム規制 (Quality System Regulation) 21 CFR Part 820 (参考文献参照)にも当てはまります。この規制は、アメリカ合衆国で生産もしくは販売する機器には必須であるため、全世界のほとんどの医療機器メーカーにとって守る必要があります。


ウォーターフォール、アジャイル、そしてVモデルという開発アプローチの差異

これまで、たくさんの異なる開発アプローチが提案されてきています。このセクションでは、最も人気の高いアプローチを三つ説明します。

ウォーターフォール開発

ウォーターフォール・アプローチの基本原則は、開発は段階的に進み、それぞれの段階が完了したとみなされるまでは次の段階へは進まない、というものです。図1が示すように、最初にユーザ要求およびシステム要求から始まり、次に設計、開発、統合と検証、さらに、組込み、妥当性確認と進んでゆきます。このようにして、それぞれの段階の最後の時点では、システムの完全な記述、もしくは、ある程度の記述、あるいは、完全なシステムがそろっていることになります。この特徴により、規制への遵守はより容易であると考えられています。なぜなら、それぞれにおいて完了した記述を前の段階でのものと照らし合わせることが可能だからです。

ウォーターフォール・アプローチは、しはしば単一方向の流れしか許さないプロセスと特徴付けられています。しかしながら、問題が発見されたときには各段階間でフィードバックがなされます。

図1.フィードバックを持つウォーターフォール・プロセス
フィードバックを持つウォーターフォール・プロセス

ウォーターフォール・アプローチは主に二つの利点を持っています。

  • 契約関係のある状況ではうまく機能する。なぜなら、明確に定義された要求に基づいて契約をすることができるからである。
  • 開発者が十分に文脈を理解せずに作業を進めて保守不能なものを作ってしまうとか、他の必要な機能の実装への障害になる事態を引き起こす、といった問題を回避する。

しかしながら、実際上は、開発を始める前に要求を完全に定義できるということは、あったとしても稀であり、たとえなされたとしても、プロジェクトが完了する前には古くて使えないものになってしまうこともしばしば起こります。ウォーターフォール・アプローチでも典型的なのは、各社は、それぞれの領域で「繰返し」をし、次の領域は前の領域が終了する前に開始され、その中で開発は要求を実際に満たしていることを確認できる、というものです。この意味するところは、アジャイル・プロセスとしての厳格さは無いとしても、ある程度アジャイル・スタイルの開発を実際にやっているということです。

アジャイル開発

アジャイル開発は根本的に異なるアプローチです。これは、「提案されるシステムの使われ方への理解が進むにしたがって、要求も変化していく」ということを認めるものになっています。それは、プロセスの中で厳密な成果物を要請することよりも、動作するシステム(典型的にはソフトウェア)に重きを置いたものです。

このアプローチは、注意深く管理をしないと、ウォーターフォールで回避しようとした問題を全て含んでしまうようなプロセスに退化してしまう恐れがあります。そのためにいろいろな対応が取られます。実際、アジャイル・アプローチにおいてはウォーターフォール・メソッドに比べ、より規律が求められます。

アジャイル・プロセスにおける主たる統制機構は、開発をたくさんのスプリントに分割することです。それぞれのスプリントは、必要とされる機能面の明確に定義された一部分を提出すること、もしくは、システム・アーキテクチャの明確に定義された再構造化を遂行すること、を目的とします。後者はアジャイルの言葉ではリファクタリングといいます。

以下この記事では、Diagnostic Grifols社が、如何に成功裏にアジャイル・メソッドを適用させたかのアプローチを記述しています。さらに彼らは、しばしばアジャイル開発実践法と組合せで用いられるスクラム (US) ・プロジェクト管理手法を自分たちの開発に組み入れました。スクラムというのは、ラグビーで、チーム全体で押し合う"scrimmage"に由来します。図2はこのアプローチのアウトラインを示しています。

図2.スクラム・プロジェクト管理ライフサイクルの概要
スクラム・プロジェクト管理ライフサイクルの概要

V-モデル・プロセス

ここでは、更にV-モデルについて言及すべきであると考えます。それは、しばしば見方を変えたウォーターフォール・アプローチと捉えられています。ウォーターフォール・メソッドとの主な差異は、開発のそれぞれのレベルにおける活動(Vの左側)が、対応するシステムの検証、妥当性確認といった活動(Vの右側)に対応付けられているということです。これはもともとウォーターフォールの拡張とみなされていたのですが、最近の解釈によればV-モデルは一連の段階を表したものというよりも、活動の間の関係性を表したものです。その各要素を、アセットを生み出す活動とみるか、アセットそのものと見るかは、大して問題ではありません。

図3.V-モデル・プロセス
V-モデル・プロセス

V-モデルを、関係性を表したものとする立場に立てば、これはウォーターフォールにもアジャイル開発にも同じように適用できるものであることは明らかです。違いがあるとすれば、アジャイル開発においてはある活動(アセットも含め)を完了しないと次の活動が始められないということはない、ということです。実際、それらのアセットは中身を作ることさえしなくてよく、開発の中で中身を埋めていく入れ物と考えればよいのです。


規制を受ける環境でのアジャイルとは

このようなアジャイル開発の成功を踏まえて、医療や規制を受ける他の業界に身をおく会社にとって当然の疑問は、「自分たちの環境でアジャイル・アプローチが採用できるだろうか」ということです。このセクションでは、Diagnostic Grifolsという会社がどうやってそれを行ったのか、という点について述べます。

アジャイルと規制、それぞれの原則が一見不一致のようでも相互を増強するような場面

既に述べたように、規制は、最近では主に記述的アプローチを取っています。このことは、規制者側が、メーカー自身が自分たちのプロセスを確立して文書化し、そのプロセスが安全で効果的な製品を作るために十分頑強なものであると証明することを期待していることを意味します。ガイド文書や標準規格は、これらのプロセスにおいてあるべき一連の活動を定めており、一方、その活動をどのように組織化して進めるかについては、メーカーにかなりの裁量を与えています。

この、頑強なプロセスを確立することによる品質保証の原則は、アジャイル宣言 (US)にある「我々はプロセスやツールよりも個人や対話に価値を置く」という主張とは相容れないように思われます。実際のところ、このアジャイル原則にしたがってスキルのある人を集め、彼らが快適に作業できる環境を提供すれば、まさに頑強なプロセスはより頑強になります。なぜなら、それによりチームは、継続的にどのように作業をしてゆくべきか、改善の必要はあるか、ということを継続的に自問するようになるからです。このことは、まさに規制者側が明示的にメーカーに要請していることなのです。

規制の検定では、検定を受ける製品の開発が、確立されたプロセスに沿って実施されているかどうかが評価されます。規制の観点からは、プロセスに沿っているという事実は、客観的な証拠によってのみ妥当性が確認されます。それは、ある種の文書化を指しており、アジャイルでいう「包括的な文書化よりも動作するソフトウェア」という価値観と一致しないように思われます。アジャイルも規制の原則も、動作するソフトウェアと安全で効果的なソフトウェアとを同じものと見なせば、実は同じ目的にかなったものであるといえます。文書化はそれだけで終わりではありません。それは、その製品が頑強なプロセスに沿って開発されているゆえ安全な形で使用目的を実現する、ということを示すための、単に一つの手段に過ぎないということです。アジャイルの原則は、「この文書化において本当に価値のある資料のみが作成され、無駄は排除されるべき」ということを認識する上で助けになります。

ガイド文書や標準規格が要請している活動の一つは、「設計インプット (design inputs)」を定義することです。この定義は、アーキテクチャ、設計、コーディング、テストといった後続する活動の基礎になります。さらに、規制は、「その製品が設計インプットにて定義されている使用目的を十分実現しているか」に対する最終的な妥当性確認の活動を要請します。これもまた、アジャイルの「契約交渉よりも顧客との協業」という価値観と一致しないように思われますが、実は逆です。なぜなら、開発の全てにおいて顧客を継続的に巻き込むことは、開発者が使用目的やユーザのニーズを完全に理解する上で役に立ちます。このことは、これらのニーズが設計インプットに翻訳され、それがシステムを定義し、他の活動がこのニーズを実現するソフトウェアを生み出すということを意味します。

最後にもう一つ、開発計画作業も、ガイド文書や標準規格が要請する基本的な活動であり、メーカーは、自らが確立しているプロセスを、如何にその対象製品に仕立て直して実装しているかを、それを通して示すことになります。これは、アジャイルの「計画に沿うよりも変化に呼応」という価値観と一致しないように思われますが、実は、アジャイルはいろいろなレベルでの計画作業を大変に重視しているのです。また、規制側も開発が進展する中での計画の更新の必要性を認めているのです。

規制を受ける活動をアジャイル開発プロセスに対応づける

図4は、次のような規制を受ける活動とアジャイル開発プロセスの対応を示しています。

  • 計画策定
  • 要求分析(ソフトウェア要求仕様 - software requirements specification - あるいはSRS)
  • アーキテクチャ設計
  • 詳細設計
  • コーディング
  • 単体、結合、システム、回帰テスト
  • ソフトウェア・リリース
図4.規制を受ける活動のアジャイル開発プロセスへの対応付け
規制を受ける活動のアジャイル開発プロセスへの対応付け

クリックして大きなイメージを見る

図4.規制を受ける活動のアジャイル開発プロセスへの対応付け

規制を受ける活動のアジャイル開発プロセスへの対応付け

これらの活動は、あるアジャイル・サイクルの中に、より具体的には、時間枠をもった(time-boxed)スプリントの系列をもつスクラム・プロセスに対応付けられます。最初のイテレーションは、プロジェクトの範囲を確立し、最初のリリースの大体の計画を定義し、アーキテクチャ的な基礎を置きます。その後で、その製品のライフにわたる一連のリリースが続きます。各リリースは、最初に計画され、その後続く一続きのスプリントから成っています。市場へのソフトウェアのリリースに先立って、規制からの要請を全て満たしていることを保障するための「堅牢化(hardening)」スプリントが行われます。場合に応じてですが、リリースが多くの重要なスプリントを含んでいる場合は、堅牢化スプリントを開発の特定の時点時点に挿入し、そこで規制から要請されている成果物群を合わせて確認するようにします。こうすることで、技術的あるいは規制的な負債を蓄積してしまうことを避けることができます。

以下の図は、ある製品のライフ全体の観点からのスクラム・ライフサイクルを示しています。

図5.製品ライフサイクルにおけるスクラム・ライフサイクル
製品ライフサイクルにおけるスクラム・ライフサイクル

クリックして大きなイメージを見る

図5.製品ライフサイクルにおけるスクラム・ライフサイクル

製品ライフサイクルにおけるスクラム・ライフサイクル

この活動の対応付けは、次セクションで説明するように、うまくお互いの矛盾のトレード・オフを調整することで、両方の世界の良いとこ取りを狙ったものです。

矛盾を解決し妥協点を見出すこと

ソフトウェアの実際的な状況で現れる主な矛盾の一つは、実装すべき要求の詳細度と正式さに関わることです。開発作業を始める上で基礎となる、全ての利害関係者によりレビューされ承認された完全なる要求に関して、異を唱えるのは容易ではありません。残念ながら、現実の状況では、複雑なシステムを完全で欠陥の無い正確な要求に基づいて、全体を予測して記述しつくすことなど不可能です。加えて、カスタマーからのフィードバックなどから変更は起きますし、やり直しにかなりの時間をとられることも珍しくありません。

他方、開発チームの外部で規定され決定されるシステム・フィーチャーもあります。それぞれのシステムは、最終的な利用の観点から引き出されるビジネスロジックを持っています。カスタマーや他の利害関係者(例えば、サービス・エンジニアや製造エンジニア)は、彼らによる製品への操作の観点から一連のフィーチャーを求めてくるでしょう。そればかりではありません。製品が発展していくときには、開発の大きな部分は既に存在している機能性の上に作られていきます。したがって、これらのことを全て、自己組織化しているアジャイル・チーム任せにし、これらの全てのニーズを収集する十分な労力を払わずにプロジェクトを開始してしまうのは愚直すぎると言えるでしょう。これらのニーズ(を理解すること)は、うまく対応できれば、その製品の商業的な成功を確実なものにするはずです。

加えて、時間は開発にプレッシャーを与えるので、市場投入への時間を短縮するものとしての作業の並列化は魅力的に映ります。しかし、並列性が持つ暗い部分としては、コミュニケーションの複雑さの増大と、やり直しの影響がより大きくなるということがあります。最初の一連の要求の辺りに戻って考えてみると、開発者が実装に集中する間に、テスト手順を書き始めるというのは意味あることです。規制を受ける環境では、テスト手順を書くのは時間のかかる作業であり、正式なレビューや承認サイクルの対象にもなり、その分利用可能になる時点は遅れます。うまくいけば、実装が済むと、一連のテスト手順が既にそろっているという形にできます。並列性に関する問題は、変更があった場合、それが要求、実装、テスト、に影響を与え、その結果失われる作業が倍増するということです。

最悪のシナリオを考えてみましょう。例えば、要求が集められ、正式にレビューされ、承認され、開発者やテスト担当者に渡され、その結果、実装やテスト手順の作成が並列に始められるとします。もし、開発者が、後に、矛盾する要求、詳細の欠如、あるいは技術的な問題をみつけ、求められる機能性の実現が不可能であるか非現実的であることがわかったとき、作業は中止しなければならず、新しい要求を明確にしなければなりません。初期の要求に対して費やされた多大な労力が失われることになり、もはや古いテストケースは書き直しが必要になるでしょう。

我々のDiagnostic Grifols社での経験では、そしてこのことはTIR45においても明確に指摘されていることですが、次の三通りの選択肢に要約されるような対立軸の間のトレード・オフを判断していく必要があります。

  • 完全な設計インプット、よりも、丁度十分な程度の設計インプット
  • 「完了そして開始」という関係、よりも、「完了と完了」という関係 (すなわち、ウォーターフォールであれば逐次に行われる活動を並行に実行できるということ)
  • 設計インプットと設計アウトプットの同期点(をどこに置くか)

この対応図が示すように、まず正式に承認された最初のハイレベルな要求が存在しています。これは、その範囲においては包括的でなければなりませんが、詳細に関しては完全には成りえません。このようにして、システムが実装するフィーチャーは全ての利害関係者から認識され承認されています。例えば、決定事項に関しては文書に記述されますが、しばしば"未定(TBD)"としておき、詳細は開発が進むにつれて詳細が追加されるようにします。決定事項とは、例えば次のような質問に答えるものです。

  • このシステムは病院のネットワークに接続し中央情報システムとデータ交換をすることができるか。
  • スループットを強化するために幾つかのシステムが連結されるか。
  • このシステムは製造オペレーションの速度向上のため自動自己調整アルゴリズムを含んでいるか。

機能性をシステムに作り込むスプリントの間は、幾つかのフィーチャーが選択され、それらが「十分な程度の明確さ」を持つように、適切な程度に時間が費やされます。つまり、現実的な問題に後からさらされるような詳細にあまり過大な時間を使うことなく、開発がスタートできるということです。加えて、実装が終わった後で行う、非公式で探査的なテストを規定するような幾つかのハイレベルなテストのデザインに、限られた量の時間を費やします。このように、アジャイル・チームの広範なコミュニケーションを生かして、最終的な機能性が「あぶりだされ」てゆき、コードの適切な働きが探査的なテストにより確認されます。

機能性が、「完了」と見なされたとき、同期タスクが実施され、最終的な要求が提出されます。これらの要求は、詳細でありかつシステムの実装と一貫性が取れています。これは、「完了と完了」のアプローチであり規制への提出物を効果的なやり方で収めることができます。

ここで、規制とアジャイルの世界の間の、もう一方の大きな矛盾点がでてきます。すなわち、監査者は検定が容易になるような正式な文書を期待しますが、我々が今ここで述べたような繰返しによる要求定義と非公式なテスト実施は、それと対極にあるように思われます。ここが正に、堅牢化スプリントが必要になるところです。

  • 全ての同期点の活動を完了し、設計インプット (SRS, アーキテクチャ設計、詳細設計)と、設計アウトプット(コード、テスト手順)とを一貫させる。
  • この情報を文書化し、正式レビュー、承認サイクルを回す。
  • 正式な方法でテスト手順を走らせ、検証記録を残す。

あるリリースが少ない数のスプリントからなる場合(例えば6程度まで)、この堅牢化スプリントは最後に一度きりとなります。全くの新規製品が立ち上げられたり、メジャー・リリースが含まれたりする場合、経験から我々は、6から8の通常のスプリントごとに一度堅牢化スプリントを挿入する必要があると考えます。これにより、技術的および規制の観点からの負債を溜め込んで、開発の最後で解決するのが難しい状況に陥る、というのを避けることができます。


ツールが手助けになる場面

全ての成果物が変化し進化していく「継続的な繰返し」は、開発チームに非常に大きなプレッシャーと、動作するソフトウェアを首尾一貫して作り出す能力へのチャレンジを突きつけます。他のアジャイル実践法の要素、例えば「継続的統合」や「自動化されたテスト」もツールの利用の恩恵を受けるものです。

規制を受ける環境においては、要求、アーキテクチャ、設計、実装、テストを結ぶトレーサビリティ・チェーン、そして、それらへの変更の統制に関する要請は、充足するのが困難なものです。進展や変更がそれぞれの繰返しでのリズムで起こり、監査者の検定時に使える文書を最新に保つのが非常に難しくなるとき、これは気の遠くなるような作業になってしまいます。そのとき、これらの変更をうまく扱い、トレーサビリティ・チェーンを維持するのに使えるツールは、この上なく貴重なものになるでしょう。

これまでのセクションで述べたことからも明らかなように、要求、アーキテクチャ、詳細デザイン、テスト手順は開発を通じて発展して行きますが、静的で正式な文書も監査者の期待を満たすものでなければなりません。これが、正にツールが関係してくるところなのです。

Rational DOORS要求管理ツールを用いた現実例

Diagnostic Grifols社は、システムズおよび先進ITアプリケーションの要求管理ソフトウェアである IBM Rational DOORS を選択し、規制を受ける成果物の生成に役立てています。彼らは、次のような項目をこのツールにて生成・保守しています。

  • ソフトウェア要求
  • アーキテクチャ設計
  • 詳細設計
  • 詳細設計を実現するソースファイルのリスト (ファイルそのものではない。それらは構成管理ツールの中で管理される)
  • システムテスト手順と記録
  • 上記全てのトレーサビリティ情報

DOORSのバージョン管理およびベースライン作成のケーパビリティにより、上記の全ての成果物が進展するにつれ、変更は管理され追跡されるようになっています。規制のための文書を生成するときがくると、DOORSのテンプレートを使ったレポート機能により最新の情報を生成することができます。この情報は、後に正式な文書管理システムに提出されます。


要約とまとめ

この記事では、高度に規制を受ける環境における複数の開発アプローチと、そのソフトウェア開発への適用可能性について、概要を説明しました。更に、進歩的な医療機器メーカーが、その高度に規制を受ける領域で如何にアジャイル開発の実践法を取り入れたかについても説明しました。規制を受ける他の領域で活動する組織でも、これに似たアプローチをとることが可能です。

我々は、アジャイル実践法は、規制産業と矛盾することはないということだけではなく、規制に対する法令遵守を強力にサポートするような形で実行することができることも示しました。Diagnostic Grifols社にとってこのアプローチは、法令遵守とともに生産性においても利益をもたらしています。

出展: 図はScott Ambler, Scott Ambler + Associates の好意に依る

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のKeith Collyerを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。

参考文献

学ぶために

製品や技術を入手するために

  • Rational DOORS Web Accessの無料トライアル版はこちらです。 free trial download (US)
  • 目的に応じてIBMソフトウェアの評価ができます。ダウンロード、オンライン評価、クラウド環境での利用が可能です。Evaluate IBM software (US) 。SOAサンドボックスによりサービス指向アーキテクチャの学習も可能です。 SOA Sandbox (US)

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational, Mobile development
ArticleID=944388
ArticleTitle=法令遵守を意識したアジャイル
publish-date=09132013