Copilot進化論：助手席のナビゲーターから、自律するパートナーへ

AI キャリア

最近、開発における自身の役割が変化していく中で、これまで当たり前のように使っていた GitHub Copilot を、自分は「なんとなく」しか使いこなせていないのではないか、という疑問を抱きました。Copilotの可能性と、AI時代における開発者との関係性を探求するため、公式ドキュメントを読み込みました。

そこから、Copilotが単なるツールを超え、私たちの役割を変えうるパートナーへと進化していることが見えてきました。

この状況は、アニメーション映画『カーズ 3』の物語を想起させます。主人公のライトニング・マックィーンが、いつの間にか自分が現役のプレイヤーではなく、次世代を育てる「コーチ」の立場になっていることに気づく。これまでの私は、Copilot を助手席のナビゲーターとして使っていました。しかし、Copilot の進化と共に、いつの間にかその主導権は運転席へと移り、私はその隣で、まだ自分自身も「使いこなせている」とは言えないながらも、行き先を指示し、最高のパフォーマンスが出せるよう環境を整える、いわば『コーチ』のような役割を担うようになっていたのです。

この記事では、Copilot の進化の軌跡を振り返りながら、これからの AI 時代における開発者との新しい関係性を探っていきます。

もはや別物？ Copilot進化の軌跡

「Copilot はコード補完ツール」という認識は、今回の調査で改められました。GitHub Copilot は、私が思っていた以上のスピードで機能拡張を続け、その姿を変化させていました。興味深いことに、その進化の方向性は、例えば Anthropic 社の Claude シリーズのような他の AI アシスタントが先行して実装していた機能を取り込むような動きも見られ、業界全体で機能の収斂と競争が見られます。その進化の軌跡を、具体的な登場時期と共に振り返ることで、なぜ私たちが Copilot との関係性を見直す必要があるのか、その理由が理解しやすくなるでしょう。

段階 時期 主な機能・コンセプト 開発者との関係性
黎明期 （登場初期） コード補完 助手席のナビゲーター
対話の時代 - IDE内チャット, @workspace 能動的な対話相手
プロセス改善 - 効果的な指示書, 構造化コンテキスト プロセス改善の推進者
プラットフォーム化 2025年11月〜 Custom Agents, Agent Skills 自律エージェントのプロデューサー/コーチ
↪︎ 自律性の追求 2024年4月〜 Copilot Workspace / Agent -
対話チャネルの拡大 2025年9月〜 GitHub Copilot CLI -

黎明期：助手席のナビゲーター

Copilot の登場は、開発者のコード記述体験に革命をもたらしました。当初は、主に以下の機能で私たちの「助手席」に座り、開発をサポートしてくれていました。 * 入力候補（コードの提案）: 入力中のコードを予測し、提案してくれる中核機能です。

対話の時代と、その「限界」

次に Copilot は「会話」の能力を獲得し、能動的な対話相手へと変化しました。 * IDE内チャット機能: IDE 内でコードについて質問したり、テストコードの生成を依頼できるようになりました。 * コンテキスト提供機能: @workspaceコマンドなどが登場し、コードベースを横断して関連性の高い情報を自動的に検索・抽出するようになり、それらを文脈として利用する技術が導入されました。加えて、明示的な指示書ファイル（例: .github/copilot-instructions.md）を用いた、より細やかな挙動の制御も可能になり、Copilot への文脈提供は多層的なものとなっていきました。

しかし、このチャット機能にも「限界」が見え始めました。@workspaceによるコードベースの検索は非常に強力ですが、その検索ステップは「賢い推測」であり、常に完璧ではありません。大規模なリファクタリングに必要な全ての依存関係を完全に把握しきれなかったり、意図しないファイルが参照されてしまったりするケースがありました。結果として、一度の指示で期待通りの結果を得ることは容易ではなく、開発者が対話を通じて答えを誘導したり、何度も修正を指示したりする必要があったのです。

対話の限界を超える「プロセス改善」

対話の限界が見えてきたとき、技術的進歩を待つだけでなく、私たち開発者側でも工夫が始まりました。それは、Copilot にいかにして「より良いコンテキスト」を与えるか、というプロセスの改善です。

  • 効果的な指示書の作成: copilot-instructions.md のようなファイルに、プロジェクトの規約や応答スタイルの期待値を記述することで、Copilot の振る舞いをより明示的に制御するようになりました。
  • 構造化されたコンテキストの提供: タスクの実行に必要な仕様書、API 定義（OpenAPI など）、関連ドキュメントを体系的にまとめてコンテキストとして渡すアプローチもその 1 つです。github/spec-kitのような、仕様駆動開発（Spec Driven Development）を支援するツールキットは、この構造化されたコンテキスト提供を促進するために登場しました。

このような人間側のプロセス改善の試みが、Copilot のさらなる技術的進化を促し、そしてその進化を最大限に活用するための土台となっていきました。

さらなる進化：プラットフォーム化、自律性の追求、そして対話チャネルの拡大

この「人間側のプロセス改善」の流れを受けて、Copilot はさらなる技術的進化を遂げます。

1. プラットフォーム化：開発者による能力の拡張

まず、私たちが手動で行っていた「コンテキストの最適化」を、より洗練された形で自動化する拡張可能なプラットフォームへの進化が、段階的に起こりました。

  • GitHub Copilot Custom Agentsの登場 (2025年11月〜): 最初に、特定の目的に特化した「カスタムエージェント」を作成する機能がパブリックプレビューとして提供されました。これにより、開発者はチーム独自のワークフローに合わせた AI アシスタントを定義できるようになり、プラットフォーム化への第一歩が踏み出されました。

  • Agent Skillsによる能力拡張 (2025年12月〜): 次に、それらのエージェントに再利用可能な「SKILL（能力）」を教える、より新しい仕組みがプレビュー版として導入されました。巨大なライブラリのコード全体をコンテキストとして含める代わりに、SKILL として機能をカプセル化します。エージェントは SKILL の仕様（使い方）だけを理解すればよいため、プロンプトのコンテキストサイズを劇的に節約し、より複雑なタスクの実行を可能にします。

この「エージェント」と「SKILL」の組み合わせこそが、Copilot を単なるツールから、開発者が育て、拡張できるプラットフォーム化を推進する重要な要素です。

2. 自律性の追求 (Copilot Workspace / Agent - 2024年4月〜)

このプラットフォームの能力を最大限に活用する形で、「人間が対話で修正を繰り返すのではなく、ゴールだけを与えて、具体的な計画立案から実行までを Copilot 自身に任せてしまおう」という、エージェント化のアプローチが本格化しました。

  • Copilot Workspace (テクニカルプレビュー) が、このエージェント化アプローチの先駆けとなりました。これは、当時話題となっていた自律型 AI ソフトウェアエンジニア「Devin」のように、Issue の番号を渡すだけで Copilot が仕様を読み解き、利用可能な SKILL を駆使して、コーディングからテストまでを自律的に実行しようと試みる、といった機能がその代表例です。

3. 対話チャネルの拡大 (GitHub Copilot CLI - 2025年9月〜)

そして、この強力なエージェント機能を、IDE の外でも利用可能にするための新しいインタフェースとして、GitHub Copilot CLI が提供されました。

  • copilot コマンドでインタラクティブなセッションを開始し、「Issue #123 を解決する」といった抽象的なゴールを伝えることで、ターミナルから直接エージェントを起動し、ファイルの編集やコマンドの実行といった一連のコーディングタスクを自律的に実行させることができます。

あなたはどの段階？ 2つの関係性の間で揺れ動く私たち

Copilot の進化を見てくると、私たち開発者と Copilot との関係性には、大きく分けて 2 つのモードが見えてきます。しかし、これは明確にどちらか一方に分類されるものではなく、多くの人がこの 2 つのモードを状況に応じて使い分けたり、その間で自分なりの最適なバランスを探したりしているのではないでしょうか。私自身も、まさにその探求の最中にいます。

観点 モード1：助手席のCopilot（受動的パートナーシップ） モード2：運転席のCopilot（プロデューサーとしてのパートナーシップ）
関係性の比喩 開発者が運転手で、Copilotは助手席のナビゲーター Copilotが運転手で、開発者はコーチ/プロデューサー
主な利用機能 コード補完、簡単な質問応答 チャット機能（@workspace）、エージェント機能
タスクにおける役割 手作業の効率化をサポート 設計に基づき、タスク実行を主導
メリット 手軽に導入でき、すぐに生産性を実感できる 圧倒的な生産性向上。より複雑なタスクに挑戦できる
求められるスキル （特別なスキルは不要） 課題の分析・設計スキル、生成物のレビュー能力

モード1：助手席のCopilot（受動的パートナーシップ）

  • 特徴: コード補完や簡単な質問応答が中心。Typo の修正や、よく使うコードスニペットの自動生成など、手元の作業を効率化する目的で利用します。
  • メリット: 手軽に導入でき、すぐに生産性向上を実感できます。
  • デメリット: Copilot の持つ真のポテンシャル、特に自律性や高度な推論能力を十分に活かしきれていない可能性があります。まるで高性能なスポーツカーを、街乗りにしか使っていないようなものです。

モード2：運転席のCopilot（プロデューサーとしてのパートナーシップ）

  • 特徴: Copilot にタスクの大部分を委ねるために、私たちはまず課題を分析・設計し、的確なコンテキスト（指示、情報）を与えます。そして、その結果を評価し、必要に応じて軌道修正を行います。チャット機能やエージェント機能の活用が中心となります。
  • メリット: 圧倒的な生産性向上。より複雑で大規模なタスクに挑戦できる可能性が広がります。また、Copilot との協働を通じて、自身の設計能力や問題解決能力も磨かれます。
  • デメリット: Copilot の能力を最大限に引き出すための「分析・設計スキル」や、生成されたコードや提案を正確に評価する「レビュー能力」が求められます。まさに、優秀な AI という素材を活かす「設計者」としての力量が試されるのです。

まとめ：プロデューサーとして、新たな旅へ

Copilot の進化は、私たち開発者にとって、仕事のやり方だけでなく、自身のキャリアパスやスキルセットを見直す転換点をもたらしています。AI に仕事を「奪われる」という受動的な懸念ではなく、AI を最大限に活かし、「共創する」という能動的な姿勢が求められる時代です。

私たちは、Copilot を単なるツールとして使うだけでなく、その能力を最大限に引き出すための「設計者」として、新しいパートナーシップを築いていく視点が、今後重要性を増すでしょう。それは、プレイヤーから「コーチ」へ、そしてさらに、課題解決の全体像を描く「設計者」へと、私たちの役割がシフトしていくでしょう。

もちろん、誰もがすぐに完璧な「プロデューサー」になれるわけではありません。ここで言う「プロデュース」とは、AI の能力を最大限に引き出すための、タスクの分解やコンテキストのプロデュースといった、AI との対話におけるプロデュース（以降、「対話プロデュース」と呼びます）を指します。この「対話設計」のスキルについては、経験豊富なエンジニアであっても、新たな学習領域と言えます。

そして、この「対話設計」スキルが未熟であるからこそ、セーフティネットの構築が重要です。私たちは、AI の提案を安易に受け入れるべきではありません。最終的なコードの品質と安全性に責任を持つのは、人間が責任を負うべきです。そのために必要な、ソフトウェアの構造を見通す、従来からの深い技術的洞察に基づいた「レビュー能力」や「アーキテクチャ設計能力」は、その価値は一層高まるでしょう。

では、この新しい「プロデューサー」としての役割を全うするために、私たちに求められるスキルとは何でしょうか？　それは、単に Copilot への「聞き方」を工夫するプロンプトエンジニアリングに留まりません。その前段階として、解決すべき課題を分析し、Copilot に渡すべき情報と役割を的確に判断する「分析・プロデューススキル」は、これからのエンジニアにとって重要なスキルとなると考えます。

参考資料

この記事は、以下の公式ドキュメントおよびリソースを基に、筆者の考察を加えて構成しました。

AWS API GatewayとSpring BootのCORS競合に直面して考えたこと

クラウド システム設計

はじめに

ある時、私は AWS API Gateway と ECS 上の Spring Boot を組み合わせた API 連携で、予期せぬ挙動に直面しました。curlコマンドで検証してみると、シンプルな GET リクエストは成功するものの、Origin ヘッダーを付与すると途端に失敗するという現象が確認されたのです。一見するとシンプルな問題に見えましたが、その裏には CORS（Cross-Origin Resource Sharing）の複雑な挙動が潜んでいることに気づきました。

正直なところ、CORS はこれまで基本的な知識で乗り切れてきた領域でした。しかし、今回の調査を通じて、API Gateway と Spring Boot の二重の設定が引き起こす問題の複雑さに直面し、CORS の挙動の正確な仕様を十分に理解しきれていなかった自分に気づかされました。これは技術者として少しもどかしい経験でしたが、同時に、この領域を深く掘り下げ、体系的な理解を得る絶好の機会だと捉え直しました。

今回は、この時の調査内容と、そこから導き出した解決策、そして得られた学びを共有します。この経験が、同様の課題に直面している開発者やチームにとって、より堅牢なシステム設計の一助となれば幸いです。

1. CORSの基本とOriginの挙動を再確認する

まず、CORS とは何か、そして「Origin」ヘッダーがどのように機能するのかを、今回の問題の背景として整理しておきましょう。

CORS（Cross-Origin Resource Sharing）とは？

CORS は、ブラウザが、現在表示している Web ページとは異なるドメイン（オリジン）にあるリソースへアクセスする際に適用されるセキュリティメカニズムです。ブラウザは、異なるオリジンへのリクエストに対して、サーバーがそのアクセスを明示的に許可しているかを確認します。この確認プロセスは、特に複雑なリクエスト（例：POST、PUT、DELETE や、特定のカスタムヘッダーを含むリクエスト）の場合、本リクエストの前に「このリクエストを送っても安全ですか？」とサーバーに事前確認する「プリフライトリクエスト」（OPTIONS メソッド）を送信することで行われます。

実行環境によるOriginの挙動の違い

私が直面した問題の根源の 1 つは、リクエストがどこから発行されるかによって Origin ヘッダーの挙動が異なる点でした。

実行場所 Originの挙動 fetchのパス指定
クライアント (Reactなどブラウザ) ブラウザが自動でOriginヘッダーを付与 相対パス (/api/...) が使える
サーバー (Next.jsのAPI RoutesなどNode.js環境) Originは存在しない（Node.js環境） 絶対パス (https://...) が必須

今回のケースでは、curlコマンドで Origin ヘッダーを手動で付与したことで、ブラウザからのリクエストと同様の CORS チェックがトリガーされ、問題が顕在化したのだと理解しました。これは、開発者が意図せずブラウザの挙動をシミュレートしてしまい、CORS の複雑な側面が露呈した典型例と言えるでしょう。

2. CORSの責任、どこに持たせるべきだろうか？

このような CORS の複雑な挙動に直面し、私は「AWS API Gateway と Spring Boot のどちらが CORS 設定の責任を持つべきか」という問いにたどり着きました。この根本的な問いへの答えによって、各コンポーネントで「どのような設定を、どれだけ緩めるべきか」というアプローチが大きく変わってくるからです。

アプローチ1：API GatewayでCORSを管理する（推奨）

これは、クラウドネイティブな環境における最も一般的で堅牢な構成だと、私は考えています。

  • API Gateway側の設定: フロントエンドのオリジン（例: https://example.com）や許可するメソッド（GET, POSTなど）を具体的に設定します。ここで CORS ポリシーを厳密に定義します。

  • Spring Boot側の設定: Spring Security などによる意図しない内部ブロックを防ぐための安全策として、CorsConfigurationなどですべてのオリジン (*) を許可するような、最も寛容な設定を推奨します。API Gateway が CORS ヘッダーを最終的に上書きするため、この設定が外部に露出することはありません。

  • メリット:
    • CORS の管理責任が API Gateway に集約され、アーキテクチャがクリーンになります。
    • バックエンドアプリケーションは CORS を意識する必要がなくなり、ビジネスロジックに集中できます。
    • プリフライトリクエストが API Gateway で完結するため、バックエンドの負荷が軽減されます。

アプローチ2：Spring BootでCORSを管理する

ローカル開発環境と本番環境で設定を共通化したい場合など、特定の要件で選択されうる構成です。

  • API Gateway側の設定: API Gateway 側では CORS ヘッダーを生成する設定を行わず、OPTIONS リクエストを含めすべてのリクエストをバックエンドにプロキシさせます。これは、API Gateway が CORS の判定やヘッダー付与を行わない状態を意味します。

  • Spring Boot側の設定: @CrossOriginアノテーションやWebMvcConfigurerを用いて、フロントエンドのオリジン（例: http://localhost:3000）などを具体的に設定します。こちらで CORS ポリシーを厳密に定義します。

  • 主な注意点:

    • すべてのプリフライトリクエスト(OPTIONS)がバックエンドに到達するため、API Gateway で応答する場合に比べてアプリケーションの負荷が増加し、レスポンスタイムに影響を与える可能性があります。

結論として、ほとんどのケースではアプローチ1（API Gatewayで管理） が推奨されると確信しています。今回の私のケースも、最終的にこの構成に落ち着きました。

3. よくあるハマりポイントとチェックリスト

今回の経験を通じて、CORS 関連で特に注意すべき点をいくつか学びました。これらは、同様の問題に直面した際に役立つチェックリストとして、私自身も活用しています。

  • 二重ヘッダーエラーの可能性:
    • 複数のレイヤーで CORS 設定を行うと、ブラウザのコンソールにThe 'Access-Control-Allow-Origin' header contains multiple valuesのようなエラーが表示されることがあります。これは典型的なヘッダー重複のサインです。
    • 今回の記事で扱っているHTTP APIの場合、前述の通り API Gateway 側で CORS を設定すれば、バックエンドからの CORS ヘッダーは無視されるため、この問題は原理的に発生しません。
    • 一方で、より詳細な設定が可能なREST APIを利用している場合は注意が必要です。特にプロキシ統合を利用している場合、API Gateway とバックエンドの両方が CORS ヘッダーを生成し、それらが競合して意図しない挙動や二重ヘッダーエラーを引き起こす可能性があります。もし二重ヘッダーエラーに遭遇した場合は、まず利用している API Gateway のタイプ（HTTP API か REST API か）を確認すると良いでしょう。
  • Spring Securityの壁:
    • Spring Security を利用している場合、API Gateway が OPTIONS メソッドを許可したとしても、その後の POST や GET リクエストで Spring Security が 403 Forbidden を返すと、CORS ヘッダーが消失して CORS エラーに見えることがあります。これは、Spring Security のフィルターチェインが CORS ヘッダーの付与よりも先に認証・認可の判断を行い、リクエストを拒否してしまうために起こります。
    • このプロジェクトでは CSRF 保護を無効にしていたため、この点での直接的な問題は回避できましたが、認証フィルターや認可設定が CORS に影響を与える可能性は常に考慮すべきです。
  • 認証 (Authorization) ヘッダー:
    • Authorizationヘッダーなど、カスタムヘッダーをクライアントから送信する場合は、CORS 設定のAccess-Control-Allow-Headersにそのヘッダー名を明示的に追加する必要があります。今回はまだ利用していませんでしたが、将来的に認証を導入する際には必ず確認すべきポイントです。

4. まとめと今後の展望

今回の CORS 問題を通じて得られた最も重要な学びは、CORS の管理責任をどこに持たせるかを明確にすることでした。様々な検証を経て、私は以下の構成を多くの開発現場でシンプルかつ堅牢に CORS 関連の課題を解決するベストプラクティスであると確信しています。

推奨構成案: 1. API Gateway: CORS の責任をここに集約します。フロントエンドのオリジンや許可するメソッドなどを具体的に設定します。 2. Spring Boot: Spring Security などによる意図しないリクエストブロックを防ぐための安全策として、すべてを許可する最も寛容なCORS設定（allowedOrigins("*")など）を行います。この設定は API Gateway によって上書きされるため、外部には影響しません。

この経験を通じて私が得た最大の気づきは、目の前の現象に囚われず、システム全体のコンポーネント連携を本質的なレベルで見渡すことの重要性でした。この学びが、読者の皆さんの日々の開発業務の一助となれば幸いです。

Pull 型コミュニケーションとイベント駆動アーキテクチャの関係性

システム設計

イベント駆動のアーキテクチャレビューをしていた時に、イベントの送信元が送信先を知っている実装となっていて違和感を感じました。日常的に利用している Pull 型コミュニケーションと考え方は同じだと思っているのですが、それを言語化しておこうと思い、この記事を書きました。イベント駆動アーキテクチャは、システムの柔軟性と拡張性を高めるために重要な設計パターンです。しかし、イベントの送信元が送信先を知っていると、システムの疎結合性が損なわれ、結果として柔軟性が低下します。

この記事では、コミュニケーションの型とイベント駆動アーキテクチャの関係性について説明します。特に、Pull 型コミュニケーションがどのようにイベント駆動アーキテクチャと関連しているかを探ります。

コミュニケーションの型

コミュニケーションの型には、同期型と非同期型があります。同期型はリアルタイムでのやり取りが必要な場合に使用され、非同期型は時間差があっても問題ない場合に使用されます。また、伝えたい対象が明確か不明確かも型を選ぶ条件に含まれます。

型 説明 利点
同期型コミュニケーション 例えば会議や電話など、即時の応答が求められる場面で使用されます。 迅速な意思決定が可能
非同期型コミュニケーション 例えばメールやチャットなど、時間差があっても問題ない場面で使用されます。 各自のペースで情報を処理できる
Push 型コミュニケーション 送信者が情報を一方的に送る形式です。同期型コミュニケーションと非同期型コミュニケーションの両方で使用されます。 情報の受け手が特定されているため、効率的な情報伝達が可能
Pull 型コミュニケーション 受信者が自分のペースで情報を取りに行く形式です。非同期型コミュニケーションの一部として考えられます。 受信者の自主性が求められる

イベント駆動アーキテクチャ

イベント駆動アーキテクチャは、システム内のコンポーネントがイベントを通じて相互作用する設計パターンです。これにより、システムの柔軟性と拡張性が向上します。また、イベント駆動アーキテクチャは Pull 型コミュニケーションと密接に関連しています。

イベント駆動アーキテクチャを使うとき、イベントを発行する側が誰がイベントを受け取るかを知っていると、システムの柔軟性が失われることがあります。イベント駆動アーキテクチャは、受信者が自分のペースで情報を取りに行く形式（Pull 型コミュニケーション）であるべきです。これにより、システム全体の柔軟性が向上し、各コンポーネントが独立して動作できます。

イベントとは

イベントには、システムイベントとビジネスイベントがあります。システムイベントはシステム内部で発生する技術的なイベントであり、ビジネスイベントはビジネスプロセスに関連するイベントです。

イベントハンドリング

イベントハンドリングは、イベントが発生した際にそれに対応する処理を行うことです。イベントを受け取ったコンポーネントは、そのイベントに応じた適切な処理を実行します。これにより、システムは動的な状況の変化へ柔軟に対応できます。

コレオグラフィとオーケストレーション

特徴 コレオグラフィ オーケストレーション
定義 各サービスが独立して動作し、相互にメッセージをやり取りする方式 中央の制御ポイントが存在し、各サービスの動作を制御する方式
利点 高い柔軟性とスケーラビリティ
各サービスが独立して動作可能
中央制御がないため、単一障害点が存在しない 		中央制御による一元管理
プロセスの可視化が容易
各サービスの動作を統一的に制御可能
欠点 各サービス間の調整が複雑
全体のフローを把握しにくい 		中央制御ポイントが単一障害点となる可能性
柔軟性が低下する場合がある

コレオグラフィとオーケストレーションの関係

イベント駆動アーキテクチャでは、コレオグラフィの考え方がよく採用されます。各コンポーネントが独立してイベントを処理し、相互にメッセージをやり取りすることで、システム全体の柔軟性とスケーラビリティが向上します。一方、オーケストレーションは、特定のビジネスプロセスを一元管理する場合に有効です。

Pull 型コミュニケーションも、コレオグラフィの考え方に近いです。受信者が自分のペースで情報を取得し、独立して動作するため、システム全体の柔軟性が高まります。

イベントの配信方式

イベントの配信には、キューを使用した非同期処理が一般的です。キューを介することで、イベントの発行者と購読者を疎結合に保ち、システムの拡張性と信頼性を確保できます。

イベントとキュー、イベント処理の関係

イベント駆動アーキテクチャでは、Pull 型コミュニケーションと同様に受信者が自分のペースでイベントを処理することを期待します。イベントの発行側は受信者を意識しないで済むため、システム全体の柔軟性が向上し、各コンポーネントが独立して動作できます。 具体的には、イベントはキューに追加され、複数のイベント処理が非同期で実行されます。1 つのイベントが複数の処理に対応することで、システムの柔軟性が向上します。この関係性は 1 対多（1:*）であり、1 つのイベントを複数のリスナーで処理することが一般的です。

まとめ

特徴 イベント駆動アーキテクチャ Pull 型コミュニケーション
疎結合 高い柔軟性を提供 送信者と受信者の結びつきが弱い
非同期性 イベント発生から処理まで時間差あり メッセージの送受信に時間差が許容される
スケーラビリティ システムのスケールアウトが容易 負荷分散がしやすい
柔軟性 新しいイベントリスナーの追加が容易 受信者が自分のペースで情報を取得可能
リアクティブ性 イベントに対してリアクティブに動作 必要な情報を取得する際にリアクティブに動作

PMP資格維持のための当面の方針

プロジェクトマネジメント 学習法・資格

PMP 資格維持のための当面の方針

2019 年 6 月末に PMP 資格を取得しましたが、資格維持の仕組みについて理解を深めるため、CCR ハンドブックを精査し、2019 年末に今後の方針を整理することにしました。

PMP 資格維持のためには、CCR プログラムへ参加して 3 年ごとに 60PDU を取得した上で資格の更新が必要となります。

  • 教育分野:テクニカル・スキル、リーダーシップ・スキル、ストラテジック&ビジネスマ ネジメント・スキルを高め、強化するための学習機会
  • 専門職へのギブバック活動分野:専門職の発展と貢献のため、知識とスキルを共有し活用する活動

教育分野

テクニカル・プロジェクトマネジメント、リーダーシップ、ストラテジック&ビジネスマネジメントの各スキルエリアで最低限の PDU を取得する必要があります。

  • テクニカル・プロジェクトマネジメント:プロジェクトマネジ メント、プログラムマネジメント、ポートフォリオマネジメン トの特定ドメインに関連する知識、スキル、行動
  • リーダーシップ:組織がビジネス目標を達成するのに役立つリーダーシップ指向活動や、分野を超えた横断的な活動に特有の知識、スキル、行動
  • ストラテジック&ビジネスマネジメント:パフォーマンスを向上させ、ビジネス成果をよりよく提供する業界や組織に関する知識と専門知識

ギブバック活動分野

知識を共有し、積極的にスキルを適用する活動のことです(専門職実務への適応は最大 8PDU)。

  • ギブバック活動による PDU を取得することは任意（オプション）

CCR プロセス

  1. 試験に合格した日からスタート
  2. 専門能力の開発活動に参加
  3. PDU の記録と報告
  4. CCR 必要条件を満たす
  5. CCR 申請を完了し、更新料を払う
  6. CCR 更新の完了

PDU の取得方法

1 時間あたりの活動が 1PDU に相当します。

取得方法としては以下の方法があります。

  1. PMI や第三者の教育プロバイダーが提供するコースの受講
    1. PMI 支部が支部会員向けに割引価格でコースを提供している
    2. 監査で必要とされる書類
      1. 受講申込書、受講証明書または受講を証明する文書
  2. 専門職に関連したミーティング、アクティビティおよびローカル・イベントへの参加
    1. 監査で必要とされる書類
      1. 参加申込書、参加証明書またはイベント参加を証明するその他の様式の文書
  3. オンラインメディア
    1. ProjectManagement.com
      1. 日本語のメディアも公開されている
    2. ProjectManagement.com のアカウントが資格情報を含む PMI.org アカウントにリンクしている場合、PDU は自動的に報告されるので、監査のための書類は不要
  4. 読書
    1. 監査で必要とされる書類
      1. 読書した内容の概要と日付を記載した学習記録

など(その他は CCR ハンドブックを参照)

私の場合

PMP の維持費のことだけを考えると、毎年年会費を払うのではなく、更新年のみ払う方が効率的です。

PMI 会員ステータス PMI 年会費(更新) CCR 更新料 合計
PMI 会員 29*3 $60 $447
非会員 - 50 50

自分にとっての学習機会として、有効であるかどうかが初年度はわからないので、PMI 日本支部にも入会して、当面の方針は以下の通りで行くことにしました。

  • 定期的に行うこと
    • オンラインメディアによる学習(3 週間に一度)
    • 読書(1 冊 2PDU)
  • PMI 日本支部のコースや、ローカルイベントへの参加

参考

「パワートゥザエッジ」を読んだ

組織・戦略 エンジニアリングマネジメント 読書

「なぜ組織がアジャイルに向かうのか」についての洞察を得るために「パワートゥザエッジ」を読みました。

個人的に興味を持ったところをまとめています。

パワートゥザエッジ: ネットワークコミュニケーション技術による戦略的組織論

パワートゥザエッジ: ネットワークコミュニケーション技術による戦略的組織論

Amazon

指揮統制(C2)

指揮統制(Command and Control:C2)は 6 つの型に分類することが出来る。

  • 周期型
    • 定期的なスケジュールに基づいて中央から詳細な命令を発する
  • 割り込み型
    • 不定期に中央から詳細な命令を発する
    • 周期型より強力な通信能力が求められる
  • 問題解決型
    • 作戦レベルの司令部が軍の各構成要素に対して、目的を規定することに注力する
    • 上級の司令官の付与した制約の範囲内で「革新性と柔軟性」を発揮することができる
  • できる問題提示型
    • 命令は問題解決型同様に目的を中心に組み立てられるが、より少ない指標と制約
    • 任務は部下に対して問題として与えられ、それをどうやって解決すべきかについては極力詳細を提示しない
  • 選択的統制型
    • 非常に有能な部隊を提供して、大まかな任務を与える
    • 基本的には部下が十分に能力を発揮できるようにサポート役に徹する
    • 状況をモニタリングし必要に応じて介入する
  • 無統制型
    • 戦域司令官の主要な役割は軍の支援をすること、すなわち任務達成の可能性を最大化し、勝利のために軍が必要とする情報と軍備を提供する

NCW の理念の採用により、自己同期化された部隊や行動の実現が可能になるが、混乱を避けるためには以下の前提条件を備える必要がある。

  • 明確かつ一貫した指揮意図の理解
  • 高品質の情報および共通の状況認識
  • 部隊の全レベルでの能力
  • 情報、部下、上官、同胞および機器への信頼

工業化時代の組織

工業化時代の組織の特徴としては以下があげられるが、これらの特徴は工業化時代のコミュニケーションの制約に依存していた。

  • 特徴
    • 分業
    • 専門化
    • 階層化組織
    • 最適化
    • 調停
    • 統合計画
    • 相互干渉の回避

コミュニケーション

  • プッシュ型アプローチ
    • 誰がどんな情報を求めているかを配信する側が知っておく必要がある
  • プル型アプローチ
    • どこで情報が得られるかさえ明確であれば、情報を求めている側が自律的に取得しに来る

工業化時代から情報化時代へ

役割の変化

  • 広い分野に存在する潜在的脅威への対応
  • 民間組織や非政府組織(NGO)との連携

    求められる資質

  • 相互運用性：協業がしやすい仕組み(誰が参加するかということに対して柔軟)
    • 非軍事的パートナーとの協業
  • 俊敏性：効率よい学びにより不確実性に柔軟に対応する
    • 状況を理解する能力
    • 状況に対応するための適切な手段の所有
    • 適時的に応答する手段を統合運用する能力

      それを支える技術

  • 通信技術の向上
    • 組織の末端(エッジ)が力を持つことが可能となってきた

パワートゥザエッジ(PTE)

PTE は「エッジの主体に強いパワーを持たせることと、独自の権限を持った組織を増やすことにより、組織やシステムのパワーを増大させることができる」とする考え方。

PTE の考え方を指揮統制およびその情報基盤に適用したとき、軍事組織は工業化時代の欠点を克服し、成功に必要な相互運用性および俊敏性を獲得できる。

PTE が実現された組織の例として、「エッジ型組織」ではすべての構成要素に情報が与えられ、当然の行動を取る自由も与えられる。

階層型組織とエッジ型組織

階層構造が中心にパワーを保持しようとするのに対し、エッジ型組織はエッジにパワーを移動する。

階層型組織は既知の状況と任務行為においては非常に優れているが、未知の場合には非常に制限されることになる。

階層型組織 エッジ型組織
指揮 指示する 状況を整える
リーダーシップ 地位による 能力による
統制 指示による 属性に現れる
意思決定 組織が行う 全員が行う
情報 蓄積する 共有する
主な情報の流れ 垂直、指揮に伴う 水平、指揮からは独立
情報管理 プッシュ 発信して、必要なものを選ぶ
情報源 少人数に集中 取捨選択、市場に適合的
組織プロセス 指示される、線形 動的、並行的
エッジの個人 強制される 権限を与えられる

Windows7環境でDockerを利用して検証環境(Solr、Redis)を手早く準備する方法

コンテナ技術 データストア

新しいミドルウェアをとりあえず触ってみたい場合に、個別にインストールするのは、面倒ですし、環境が汚れてしまう恐れがあります。

そんな時は、Docker を利用すると便利です。

環境

Windows 7

Dockerの導入

Windows 7 環境では DockerToolbox 一択なので、以下の記事を参考に DockerToolbox をインストールします。

Docker Toolboxのインストール：Windows編

VirtualBox 上に default という名前で仮想マシンが作成されます。

付属のターミナルは利用しにくいですが、default の仮想マシンが実行中であれば、お好きなターミナルから接続可能です（デフォルトの ID/PW は docker/tcuser です）。

実際に使ってみる

事前にIPを確認する

仮想ホストの IP を確認しておく。

Docker-machine ls

Solr

Docker Hubで公開されている手順を参考に起動してみます。

  • コアを格納するディレクトリを作成する。
    • D:\var\solr\cores
  • Solr の公式 Image を取得し、起動する。
docker pull solr:5.5.5
docker run --name solr -d -p 8983:8983 -v /d/var/solr/cores:/opt/solr/server/solr/mycores -t solr:5.5.5

Redis

Docker Hubで公開されている手順を参考に起動してみます。

  • コアを格納するディレクトリを作成する。
    • D:\var\Redis\data
  • Solr の公式 Image を取得し、起動する。
# Redisを起動する
docker pull redis:4.0.11
docker run --name redis -d -p 6379:6379 -v /d/var/redis/data:/data redis:4.0.11 redis-server --appendonly yes
  • 動作確認
# 動作確認
# コンテナに接続する
docker exec -it 【CONTAINER ID】 /bin/bash
# Redisに接続
redis-cli
# コマンドラインでset/get/delなどを試すことができる
set test hoge
get test
del test
# Redisから切断
exit
# コンテナから切断
exit

参考

SolrMeterを使ってみた

データストア

Solr の負荷テストツールとして GitHub に公開されているSolrMeterを使ってみました。

準備

buildする

cd C:\Users\XXXXX\Desktop\tmp

git clone https://github.com/lafourchette/solrmeter.git

cd solrmeter

mvn package

起動する

java -jar solrmeter/target/solrmeter-0.3.1-SNAPSHOT-jar-with-dependencies.jar

負荷テスト用のQueryを準備する

Solr のログファイルを SolrMeter の Tools>Extract Queries より解析し、負荷テスト用の Query を作成できます。

実行

設定変更

Edit>Settings より設定を以下のように変更し、Apply→OK で設定を反映します。

※Choose the query mode で「external」を選択しない場合、デフォルトのコアにしかリクエストを送れないようです。

実行・監視

Query Console の実行ボタンより実行すると、下部パネルに結果が出力されます。

なお、Solr サーバのリソース状況は SolrMeter では参照できないので、vmstat などで確認すると良いでしょう。

使ってみて

Solr の autoCommit やキャッシュの設定のチューニング時に有用なツールだと思いました。