ほとんどのソフトウェア開発チームは、アジャイルマニフェストで記述された「WHAT」の部分を理解しています。しかし、ソフトウェアアーキテクトにとって、課題は「HOW」でアジャイルであることです。これは、開発者が同じ目標をどのように達成するかが異なるためです。それに加えて、一部のアジャイルチームは、ソフトウェアアーキテクトの役割を不要、あいまい、あるいはアジャイルソフトウェア開発の原則に反して動いているとさえ思っている場合があります。
一部のアジャイルフレームワークは、ソフトウェアアーキテクトの役割に関する紙に書いた定義を作成しようとしており、これによってそのガイダンスに従う人たちが出てくるでしょう。しかし、それは期待するよりも、本来のアジャイルでなかったり、実用的ではないものになる可能性があります。優れたアーキテクトは、特定のフレームワークや方法論に偏らないように行動を継続的に調整し、プロセスとの関連性を保ち、チームに必要なガイダンスとビジョンを提供する必要があります。適切なメンタルモデルの習得が、暗黙的にアジャイルマニフェストの価値観の自然な採用につながります。これは、すべてのアジャイルソフトウェア開発方法論の柱です。
アジャイルの価値：包括的なドキュメントよりも機能するソフトウェア
過去、特にウォーターフォールの時代には、「宇宙飛行士のアーキテクト」や「象牙の塔のアーキテクト」などの用語は、地上のチームから遠く離れた人を定義するために造られました。彼らはソフトウェア自体に真の価値を追加せず、図や仕様の形で包括的なドキュメントを作成することに重点を置いていますが、機能するソフトウェアを作成することはありません。残念ながら、ソフトウェアの開発方法が大幅に変わったにもかかわらず、この誤解は今でも続いています。
「動くソフトウェア」を好むということは、文書を無視してもよいという意味ではありません。これらの2つのファセットは矛盾しておらず、互いに排除すべきではありません。代わりに、最終製品で一緒にラップする必要があります。ソフトウェアアーキテクトは、アジャイルマニフェストの最後の声明を覚えておく必要があります。「右側の項目には価値がありますが、左側の項目にはもっと価値があります。」
包括的なドキュメントはトラップになるかもしれない
アーキテクチャに影響を与える仕様（新しいユーザストーリーの形式）は、アーキテクトが追跡し、経験豊富な開発者、テストエンジニア、devopsを含む開発チーム全体で実用的なアプローチで評価する必要があります。アーキテクトがチームのために本格的な技術設計を紙で作成した過去の悪い習慣は、現代のアジャイル環境には適合しません。このモデルには複数の欠陥がありますが、私も日々の基本的な作業で直面しました。
まず、最も重要なのは、アーキテクトが間違っている可能性があるということです。これは、私が詳細な事前技術設計を作成し、Sprintを改良中に開発チームに提示した後に起こりました。私が考えていなかったケースや考慮に入れなかったケースに関連する質問がありました。ほとんどのケースで、初期設計は不完全または非実用的であり、追加の作業が必要であることが判明しました。
大きな事前設計により、チームメンバーの創造性と自律性が制限されます。これは、チームメンバーが既に付与されているレシピに従う必要があるためです。心理学的な観点からは、著者でさえも、後になってそれを変更する方向に傾いたり、変更に消極的になるかもしれません。その欠陥を認めるのではなく、正しいことを証明しようとするかもしれません。
アーキテクトは、正確な詳細設計を事前に提供するのに苦労するため、チームのボトルネックにもなります。常に事前設計を提供するアーキテクトに完全に依存するチームは、どれだけスケーラブルで自律的でしょうか。経験豊富な開発者は、システムの設計に関与し、貢献することを好むため、このような指示するスタイルは適合しません。 「前もってソリューションを提供するのではなく、ビジネス要件を教えてください。そして、（アーキテクトと一緒に）適切な設計を考えさせてください。」と言うかもしれません。もちろん、これはチームが望むことを何でもできるという意味ではありません。アーキテクトとチームメンバーの間には、すべてのメンバーが理解して従わなければならないアーキテクチャの基本原則や設計ガイドラインなどに関して、相互の合意が必要です。
ソフトウェア開発のイネーブラーとしての十分なドキュメント
アーキテクトは依然として全体像を考慮し、インテグレーションポイントに注意しながらシステムの技術的整合性を維持し続ける必要があります。現在のアーキテクチャに関する潜在的なリスクを評価し、すべての利害関係者に対して透明性を持たせるために、アーキテクトが今後のビジネス仕様を評価するために事前の分析を実行する必要がある場合があります。これは、新しい外部システムと統合する場合、またはアーキテクチャに影響を与える内部機能に対して重要です。どちらの場合でも、アーキテクトがチームのためにいくつかの高レベルの設計スクラッチを準備すると容易になります。大まかなコンポーネント図やいくつかの機能的なユースケースは、さらなる議論のベースとなり、チームが関連するすべてのコンポーネントを総合的に理解するのに役立ちます。
それでも、詳細な技術設計に関しては、チームに参加し、ブレインストーミングを行い、一緒に同意することをお勧めします。このコラボレーションは、開発プロセスの早い段階でも遅い段階でも発生しません。たとえば、通常のスプリントの場合、アーキテクトとチームは、スプリントの開始前に、リファインメントミーティング中にコンセンサスに達する可能性があります。その技術的なソリューションに関連するすべての実装の詳細（たとえば、コンポーネント内通信用の内部API、マルチスレッドモデル、データベースエンティティモデルなど）は、タスク自体の一部として、スプリントの開始時にさらに議論されます。
技術文書の作成と更新は、同じタスク（同じスプリント）の下で、継続的な開発プロセスの一部として、またチームメンバー全員の責任を共有して取り組む必要があります。それでも、アーキテクトはこのプロセスを監督し、スムーズに実行し、チームカルチャーの一部になるようにし、技術的な深掘りを避け、ドキュメントを最新に保つ必要があります。
ドキュメントが重要な場合
ドキュメントが重要な役割を果たす特定のケースがいくつかあり、アーキテクトがそれを慎重に検討する必要があります。
- 特定のビジネスドメイン内で新しい問題、あるいは再発する可能性のある問題が発生した場合、アーキテクトとシニアエンジニアは協力して、関連図を含むリファレンス実装を作成する必要があります。これにより、チームは、アーキテクチャのアプローチや横断的な懸念を心配することなく、解決しなければならないビジネス上の問題に集中することができます。
- 外部システムと統合する必要がある場合、エンドツーエンドのインテグレーションフロー（たとえば、API呼び出しの詳細なシーケンス）をチームへのガイドライン実装として提供する必要があります。
- プロジェクトを別のチームに引き渡す必要がある場合、文書化により移行プロセスがスピードアップされ、より効率的な立ち上げが促進されます。
- 共有ライブラリまたはフレームワークの場合、フォーラムやチュートリアルを含む利用可能なドキュメントの品質と量は、コミュニティでの採用を促進する基本的な柱です。
- 重要なアーキテクチャ設計の決定とトレードオフをキャプチャします。
以前に、アーキテクチャに関するドキュメントに対する多くの懸念について議論しました。それは、なぜドキュメントが本当に必要で、そのくらい必要か、どのように実際の受益者を特定するか、どのように適切に構造化するか、そのようにそれを維持するかなどを含みます。
アジャイルの価値：プロセスとツールを介した個人と相互作用
アジャイルフレームワーク（例：スクラム、SAFe）の皮肉は、プロセスを定義するために開発されたが、人々はプロセスを体系化するためにツールを使用し始めました（つまり、スクラム/SAFeプロセスに続くアジャイルソフトウェア管理ツール：製品計画、リリース計画、スプリント計画、スプリント追跡、スプリントレビューなど）。これはアジャイルマニフェストの原則に真っ向から矛盾するように聞こえるかもしれませんが、実際には、組織、製品、チームなどに依存するミックスが常に存在します。重要なのは、単に「する」のではなくどのように「アジャイル」するかを覚えることです。コミュニケーション、継続的なコラボレーション、お互いをよりよく知ること、信頼と絆を育むこと、相手の意見を聞くことを大切にします。官僚的なプロセスと不適切なツールは摩擦を増やし、チームのスピードを低下させます。
アーキテクトが個人や相互作用を好む方法の例は、おそらく実際のケーススタディを使用してよく説明されています。
アーキテクトはコードを書いてレビューしなければならない
チーム内で優れたコラボレーションを実現および維持し、開発プロセスに常に関与するためには、アーキテクトはアジャイルチームの一員でなければなりません。これは、コードを積極的に記述およびレビューし、新機能のリクエストを処理し、エンドツーエンドのデリバリプロセスを監視することを意味します。
アーキテクトは開発者に比べてコーディングアクティビティに費やす時間が少ないかもしれませんが、可能な限りコードを書き続けることが非常に重要です。たとえば、平均して、可用性の少なくとも30～40％をコードの記述（場合によっては1日でも）に費やし、残りは会議やその他の技術活動（例えば、技術設計や将来のビジネス仕様の評価）に費やしています。開発タスクの性質は異なる場合があります。アーキテクトは、アプリケーションの重要な部分またはアーキテクチャ上重要な部分のコードを書くことに主に焦点を合わせなければなりません。あるいは、チーム環境によっては、彼らは、他の上級開発者がそうするように、入ってくるどんなタスクでも拾います。
コーディングに加えて、アーキテクトは他のコードのレビューにも積極的に関与する必要があります。これにより、さまざまなモジュールにわたってコードベースの認識と知識が向上します。主な関心事は、パフォーマンス、セキュリティ、その他の品質属性の基礎となるアプリケーションコードをレビューすることです。アーキテクチャに関するコードのレビューでは、システムの境界（例えば、API、通信タイプ、メッセージ）、アーキテクチャのコア原則、設計ガイドラインに違反していないことも確認する必要があります。これにより、アーキテクトは紙のデザインと実際の実装の間で一貫性と整合性を確保できます。
実際の課題について理解を深め、意味のある技術的ソリューションを提供する唯一の方法は「自分の手を動かす」ことです。コードを記述およびレビューすることにより、アーキテクトは開発者に近づき、実際の問題やニーズをよりよく理解し、製品に関する深い知識を育みます。
アーキテクトは常にチームのコンセンサスを促進し、官僚的なプロセスを排除する必要があります
組織はプロセスが大好きであり、経営陣はチームの「ルール」を作成することに熱心です。組織が大きくなればなるほど、そのようなプロセスはより網羅的で官僚的になります。会社の官僚機構をすばやく把握するには、あなたの上の管理層の数を数えます。ほとんどの場合、それらの関係は直接比例します。ソフトウェア開発に関しては、チームに対する即時および長期の両面で影響を与える2つの特定のプロセスについてお話したいと思います。それは、コードレビューとコード品質ゲート（コードカバレッジなど）です。
アーキテクトとチームは、製品がビジネス目標を達成し、利害関係者のニーズを満たすために本当に必要なものの評価に積極的に関与する必要があります。チームのコンセンサスに達したら、文書化して、ボトムアップ方式で関係者に伝えます。逆ではありません。チームが決定の一部である場合、彼らはこれが正しいアプローチであると確信し、それを支持します。チームがコードレビューガイドラインに同意することで、貴重な時間を節約し、コードレビュー中に議論が過熱しすぎることや、難易度が高すぎることに取り組むことを防ぎます。それに加えて、開発者は同様のレビューパターンと実装ガイドラインに従うため、一貫したソースコードにつながります。
コード品質ゲート（コードカバレッジを含む）は、製品の内部品質を扱うものです。内部品質を改善すると、外部品質が向上し、顧客と製品の受益者に見えるようになります。製品の優れた内部品質を維持することは、誰もが受け入れる文化であるチーム文化の一部であるべきです。逆に、任意のコードカバレッジのしきい値または任意の種類の品質ゲートをチームに課すと、人為的で非効率的なアクティビティにつながります。開発者は、これらの指標を満たすためだけにコードの調整（総合的なテストケースの開発を含む）に苦労します。さらに悪いことに、彼らは真の利点について確信していないので、それを真剣に受け取らないかもしれません。
開発プロセスにすぐに影響を与えるプロセスは、チームが推進、所有し、絶えずレビューする必要があります。トップダウンルールを課すのではなく、振り返りを使用して、コードレビューガイドラインと内部品質ゲートがソフトウェアの品質を改善する方法を議論します。アーキテクトは、それらが外部的に定義され、チームに課される状況を本当に防ぐ必要があります。
アーキテクトは開発者の近くに留まり、奉仕者であると同時に保護者でなければならない
ワークステーションを開発者の隣に置き、他のチームメンバーのように会話に積極的に参加します。これにより、コラボレーションと人間関係が改善され、より強いつながりが生まれ、チームの精神が向上します。個人と対話は、正式なプロセスよりも効率的です。チームメンバー（特に開発者）にサポートが必要かどうかを常に尋ね、必要な場合には、サポートするためにできることを考えてください。同僚はあなたのアプローチを高く評価し、あなたを本当のチームプレーヤーとして認識します。彼らが問題を抱えているとき、あなたがサポートしてくれることを知っているので、あなたのアドバイスを求めることをためらいません。彼らはあなたを別の帽子を持つマネージャーではなくリーダーとして見るでしょう。自分にアーキテクトのラベルを付けないでください。代わりに、他の人にあなたの貢献に感謝し、アーキテクトとしてのあなたの役割を評価してもらってください。ボスではなく、ファシリテーターおよびチームの奉仕者になってください。
アーキテクトは、クライアント、製品所有者、ビジネスアナリスト、スクラムマスターのプレッシャーからもチームを保護する必要があります。SCRUMやSAFeのような方法論は、この責任をスクラムマスターに明示的に委任していると主張するかもしれません。しかし、実際には、スクラムマスターでさえ要求が厳しくなり、内部品質を損なう可能性のあるリスクがある状態で先に進めようとする状況に直面しました。また、クライアントは、理想的にはより速く、より低コストで、より多くの機能が提供されることを期待しています。製品の所有者またはビジネスアナリストは、スプリント中にユーザストーリーを追加または修正したい場合があり、これにより開発作業が増加します。これらすべての状況において、アーキテクトは外圧を抑え、そのような悪い習慣を取り除く必要があります。関係者と議論し、人々がやる気を失い、プロジェクトを離れる可能性、製品品質の低下、将来の開発コストへの悪影響など、長期的な結果を認識するようにします。外部の圧力からチームを保護し、安定性、快適性、予測可能性を提供することは、健全なチームを維持するための重要な要素です。
アーキテクトは、環境で人々を快適に保ち、破壊的な活動を避けるべき
正式な技術ミーティングを設定するのではなく、チームメンバーに直接アプローチして問題を話し合うことをお勧めします。オフィス内の彼らのデスクや、カフェに出かけたり、昼食を一緒に食べたりするのです。それは本当の話であり、技術者は会議が好きではありません。したがって、会議の数を減らし、開発者が快適に感じる環境（つまり、コンピューターの前）に近づけるようにしてください。開発者に将来の会議の空き状況を尋ねる代わりに、その場でそれを行います。正式な会議以外で直接友好的な会話をします。
リモートチームの場合、チームメンバーが地理的に分散していると、状況が若干異なる場合があります。これについて考える1つの方法は、開発者を快適な領域にとどめることで、すべての従業員をリモートワーカーとして扱うことです。つまり、会議室には入らず、各自の机でビデオ会議を行うことを好むということです。それはヘッドセットを装着したまま隣同士で座っている人さえもいるということです。
アーキテクトは、煩わしくならないように会議を設定するよう注意する必要があります。あまりにも多くの中断は良くなく、技術者は集中を失い、非効率になるということも時々あります。それに加えて、朝の生産性が高い人もいれば、通常は1日の前半である人もいますが、まったく逆の人もいます。いずれの場合も、アーキテクトは、労働時間を危険にさらさないように、また集中し続けられるように、適切なタイミングと良いバランスを見つけなければなりません。
アーキテクトは、ビジネスの機能と技術ストーリーをミックスする余地を見つけなければならない
ビジネスの機能に加えて、製品の内部品質に関連する技術的なタスクがあります。これは、優先するに値します。いくつかは、顧客に直接見えるビジネス機能の開発ですが、他は即時の具体的な効果を持たないかもしれません。その例は、リファクタリングまたは再構築（コードの可読性の向上、凝集度の向上、結合性の低減）、ライブラリまたはフレームワークのバージョンのアップグレード、ログフォーマットの強化、トレースと監視の追加などに関連する可能性があります。
アーキテクトは、新しい機能の追加と必要な技術タスクの量との間で均衡を保つ必要があります。スプリントごとにスプリントを正当化しようとすると、私の経験では、製品所有者の前でスプリントを優先する必要性はスムーズにいきません。さらに、技術的なことを技術者でない人々に正当であることを説明することは容易ではありません。彼らは手掛かりを持っているかもしれませんが、必要性を適切に理解していません。私がうまくいった解決策（すでにいくつかのプロジェクトで実施している）は技術的なタスク（チームの平均速度の約20％）に対する割り当て量（または技術的なバッファー）について製品所有者と合意することでした。この割り当て量内で、アーキテクトはチームメンバーと一緒に、技術的なタスク全体で合理的な進捗を維持するために、次のスプリントに含める価値があるものを自由に決定できます。この割り当て量は定期的に厳密には守られていない場合があります。たとえば、不要なスプリントがある場合もありますが、必要に応じて製品所有者との合意に達し、このオプションを活用することが重要です。
アーキテクトは、開発者が最新のテクノロジーで最新の状態を維持できるようサポートする必要がある
アーキテクトはプロダクトオーナーおよびスクラムマスターと話し合って、チームが情熱を持っているさまざまなテクノロジーを研究したり、オープンソースプロジェクトに貢献するための時間を確保するようにしてください。人々が最新のテクノロジーとの同期を保ち、他のアイデアに触れると、製品にプラスの影響を与えます。そのような活動が非常に奨励され、人々がそれを当然のことと考えている企業がありますが、他の場所ではビジネス機能を提供する需要が常にあるため、ビジネスの承認を得るのは非常に困難です。SAFeのような方法論は、同様の活動（4つおきに1つのイノベーションスプリント）の余地を明示的に割り当て、これは良い前進ですが、これは方法論に関係なく、すべての製品開発チームの一部でなければなりません。
補完的なアプローチは、一流の技術会議へのアクセスを定期的に提供し、専門のオンラインコースまたはトレーニングプラットフォームへのアクセスを促進することです。予算のオーナーとこれらの利点を交渉してみてください。チームメンバーは高く評価され、報われると感じ、プロジェクトに長くとどまります。知識のある人がチームに残っていると、製品の品質が向上します。
関心のある人々が定期的に会議や技術的なテーマについて議論している、内部の実践コミュニティを含むさまざまなトピックに関するプレゼンテーションは、知識とベストプラクティスを広め、人間の相互作用と優れたコラボレーションを際立たせる良い方法です。
アジャイルの価値：計画に従って変更に対応する
チームのメンバーは、内部品質を低下させ、技術的な負債を増やすリスクがあるため、「すぐに機能させる。後でもっときれいにする」ことを好む場合があります。同様のガイダンスに、「現時点では適切なソリューションを見つけるための時間を割り当てない」または「既知の将来のユースケースを除外し、現在のスプリント要件のみに焦点を当てる」があります。これらはすべてアジャイルの観点から理にかなっていますが、優れたアーキテクチャの観点と矛盾する可能性があります。技術的な理由であっても経済的な理由であっても、過小評価され、無視され、間違った設計決定が後からロールバックすることが難しくなったり、不可能になる場合があります。適切なビジョンと現実的な予測がなく、効率的な計画なしでソフトウェアを構築すると、失敗しやすくなります。コードの作成はコストがかかり、開発者は安くありません。コードの一部を捨てて絶えず書き換えると、より多くのトラブルと遅延が生じます。優れたアーキテクトは、結果がビジネスによって理解され承認されない限り、内部品質を意図的に低下させる妥協をしてはなりません。
私の観点から、アーキテクトは技術設計に制約を追加する可能性があるため、常にクリティカルパス上にある将来のユースケースを考慮する必要があります。アジャイルチームは小さなスプリントで作業するかもしれませんが、アーキテクトは、より大きな目標に向けて進歩を確実にするために先を見越す必要がある立場にいます。アーキテクトはより正確なアーキテクチャ上の決定を下し、その時点で不必要または不明確なものを遅らせることができるため、ビジネス機能と明確な目標に対するより良い予測があれば物事は簡単になります。将来のビジネス仕様の評価、現在のアーキテクチャへの影響の測定、利害関係者へのリスクの伝達は、製品の成功のために重要であり、アーキテクトの重要な責任の1つです。
たとえば、私はチームが今後のスプリントで取り組む予定の事前のビジネス仕様（たとえば、最大6つのスプリント、ゆえに合計で最大3か月）のレビューに取り組み、アーキテクチャに影響を与える仕様に注意を払います。このアプローチは、高い開発需要と一貫したバックログがある製品に適合しますが、主にメンテナンスまたはサポートフェーズにある製品では、物事が非常に不規則に飛び交う可能性があるため、適切な予測を立てることはほとんど不可能です。
それでも、変化に対応するということは、計画をまったく持たない、あるいは常にシステムを再設計する立場にあるという意味ではありません。ある時点で、特に古い製品では、アーキテクチャのほとんどの側面がほぼ不変になります。アーキテクトは常に計画を立て、チームにガイダンスとビジョンを提供する必要があります。ただし、アーキテクチャ計画は十分な柔軟性（つまり、変更を受け入れる準備ができている）が必要であり、将来のビジネス要件を促進できる必要があります。
アジャイルの価値：契約交渉よりも顧客とのコラボレーション
アジャイル環境では、契約で交渉されたものよりも顧客のニーズを理解することが重要です。顧客のニーズを満たすソフトウェアを開発するには、開発ライフサイクル全体にわたる定期的なコラボレーションが必要です。実際には、これはフィードバックを受け、優先順位が切り替わる可能性がある各スプリントの終わりにできます。これによって、プロセスの非常に早い段階で最大の開発価値を確保する機会を与えられます。
すべての利害関係者がアーキテクトの顧客になる
アーキテクトは、さまざまな利害関係者（クライアント、開発チーム、製品所有者、スクラムマスターなど）からの外部および内部の両方の要求に対処する必要があります。すべてがシステムの成功に共通の利害関係を持っているにもかかわらず、通常、システムに保証または最適化を望むという、さまざまな懸念があります。これらの利害関係者は、アーキテクトの顧客になります。顧客は常にソフトウェアの代金を支払う人という考えではなく、アーキテクトの顧客はシステムの実現に関心があるすべての人です。この状況下で、アーキテクトはビジネス、テクノロジー、人の間の適切なバランスを実現可能な方法で見つける必要があります。その後、このバランスを顧客および利害関係者に伝え、開発中のシステムの概念的整合性を維持し、モデルから本番システムへの移行を促進します。
アーキテクトは、コミュニケーションと交渉の両方のスキルを習得する必要がある
相互作用のルールを定義するよりも、共に協力することの方がはるかに重要です。アーキテクトにとって、コミュニケーションと交渉のスキルは非常に重要です。ここまでは、他の利害関係者との関係において、アーキテクトにとってコラボレーションが意味するものに焦点を当ててきました。それでも、アーキテクトは常にクライアント、製品所有者、ビジネスアナリスト、スクラムマスター、さらには開発者とさまざまな技術ソリューションについて話し合い、合意に至らせる立場にいるため、交渉も重要な要素です。技術タスクのスプリントクォータの促進、適切な技術ソリューションを見つけるためのチームとの協力、またはコードレビューポリシーまたは内部品質ゲートの定義中のチームコンセンサスの獲得に関して提供されたすべての例は無償で現れるわけではありません。実生活と同様、交渉とトレードオフが常にあります。
最終的な考え
アーキテクトは何らかの方法論（例えば、SCRUM、SAFeなど）を信仰深く信頼したり従ったりするべきではありません。それらはすべて、長所と短所、強みと弱みがあり、実際にはあまり適用されないこともあります。すべての方法論はある程度漏れやすいです。アジャイルアーキテクトは、スキーマや独断的な役割に固執しない人です。アジャイルアーキテクトは、実用的で柔軟性があり、ソフトウェア開発ライフサイクルプロセスに集中的に関与する必要があります。優れたコミュニケーション能力と交渉スキルを持ち、継続的に改善を模索し、チームにガイダンスとビジョンを提供する必要があります。
アジャイルマニフェストの価値はバイナリではありません。 「動くソフトウェア」、「個人と相互作用」、「変化への対応」、「顧客とのコラボレーション」だけでなく、アーキテクトがチーム内の他の役割と協力して、利害関係者の懸念、開発組織、技術環境、彼らの専門知識に応じて、より多くを左に移動するのか、右に移動するのかの優先度付けを調整する必要があります。
著者について
Ionut Balosin氏は、ソフトウェアアーキテクトであり、独立したテクニカルトレーナーです。彼は、世界中のソフトウェア開発会議やミートアップで定期的に講演を行っており、プレゼンテーション、トレーニングコース、ワークショップを行っています。詳細については、彼のウェブサイトをご覧ください。