HOME | イベント | ET2013 設計・検証ツールトラック ソフトウエアプロダクトライン開発:再利用の秘訣

ソフトウエアプロダクトライン開発(SPLE)
再利用の秘訣

 ~ バージョン地獄で苦しんでいませんか? ~

「やっと元バグをつぶしたと思ったらコピー先でバグが進化していた」、「コードを再利用するはずだったのに苦労を再体験してしまった」など、一歩先を行くプログラマーなら誰もが抱えるこの悩み。本質的な解決策はないものか?製品間の差異をバージョンではなくバリエーションと捉えることでバリアント管理という新しいドアが開く。そのための専用ツールの実践的な活用事例を紹介

 
講演には100名以上の申し込みがあり、お陰様で盛況でした。また講演後に多くの方がブースに来られて様々な思いを聞かせていただきました。その中で特に興味深かったのは、独自にバリアント管理を進めていて、良い市販ツールによる改善に興味を持っている方が多かったことです。ここ数年で取り組み始められた方が多くなってきたという実感を感じることができました。
 

再利用が上手くいかない

 
・せっかく苦労して、費用・工数もかけて開発したので上手く再利用したいのに、元になる製品に10%だけ新機能として開発しても80%の開発コストがかかってしまう
・再利用部品の依存関係が複雑で(小変更が多くの場所に影響してしまい)、テスト・検証に多くの時間を費やしてしまう

従来式の派生製品開発の課題

 


 クローン&オウン(既存製品をコピー、あるいは構成管理からブランチング)で複数の製品を継続して開発。開始当初は安上がりに見えるが、最終的にはコピーによる再利用をしない場合と殆ど変わらないか、場合のよっては割高になる。理由の一つは、テストやメンテナンスが軽減できないこと。クローンごと個別に実施する必要があるので。もし異なるバージョン/ブランチからの機能を合成して新製品を作ることになれば、一から開発するよりも工数を要することは明らか。そして再利用失敗の末、一から開発することになる。
 
バージョン地獄は、このようにして複数製品が開発される場合に起こる。

バージョン地獄

 


 体系的な管理を行わずに複数製品が開発される場合、バージョン地獄に陥る。例えば、再利用可能なコンポーネントで構成される幾つかの製品があると、長期間にわたって開発されてきた各製品は、異なったバージョンのコンポーネントで構成されている。製品ごとで、機能追加され、その結果として既存コンポーネントが修正されるなど、個々に進化を始めるので。これら異なったバージョンのコンポーネントで構成され、違う時期にリリースされた、異なる製品群の保守は難しく、修正を他の製品に効率的に反映させることも困難。

バージョンとバリアントの混同

 
非常に大切な、バージョン或いはリビジョンと、バリアントの明確な違いについて。
 
バージョンとは、ある時点におけるオブジェクトのこと。オブジェクトなり、資産が何であるか、どうであるか、と言うことではなく、オブジェクトのある時点を示している。
(例:バージョン1.10 をバグフィックスして バージョン1.11をリリース)
 
バリアントは、互いに異なるオブジェクトのこと。例えば、2つのプロダクトバリアントは、プロダクトラインの共通のベースからなる2つの製品間で、オブジェクトに対する異なったプロパティ(顧客の観点から見た)を持つ。車なら色の違い(あるいはセダン車かワゴン車)が判り易い例。つまりプロパティのインスタンス間の違いをユーザが識別できる。これらプロパティは、プロダクトラインにおけるバライアビリティに相当する。 
 
ここで問題は、一般にバリアントが、バージョンに相当すること。なぜなら、オブジェクトの新たなプロパティを実現すること、例えば、編集機能を追加するには、それを実現するコードをオブジェクトに追加する必要があるので、古いバージョンと新しいバージョンのオブジェトは違うものになるので。
 
また、単一バージョンのオブジェクトから、バリアントが生まれることもある。例えば、コンパイラスイッチやコンフィグレーションファイル等による、オブジェクトの異なった振舞いは、ユーザの観点において異なったプロパティを実現することになる。車の色の場合は、このようにはいかないが、データベースへのアクセスを設定で切り替える等のケースがわかり易い例。
 
バリアントは、単一のバージョンのファンクショナリティ(機能)で定義され、異なったバージョンから生み出され続ける。厄介なのは、単一システムにおいて、バリアントとバージョンの互換性が失われること。各バリアントが、特定のバージョンに帰属してしまうこと。

バージョンとバリアントを区別する

 


 プロダクトライン開発のシナリオでは、個々の製品機能は、使用するプロダクトラインのバージョンから得られる。そして簡単なプロパティの選択で、顧客毎に特定のソリューションを提供出来るようになる。
顧客が必要としなければ、バリアントが無いこともある。そして改めて必要になったときには、いつでも追加できる。あくまでもビジネスとしての選択肢であり、技術論は問われることが無く、このような仕組みが実現される。
 
解決策は経時変化(バージョン・進化)と、機能合成による製品化(バリアント)を区別すること。新製品のためにプラットフォームが変更されても、そのプラットフォームバージョンの資産を用いて既存製品を作ることができる柔軟な環境を継続的に管理・維持すること。これは個々の製品を構成するために使用されている異なるバージョンの資産間で修正をマージすることに比べて、ずっとシンプル。
 
もちろんバリアントによっては無関係になることもあり、その場合は配慮の対象外になっていく。

こんな症状でお悩みでは?

 

  • 並行して開発されているブランチ数が増えつつある
  • 並行して開発されているブランチのコード量が増えつつある
  • 同じバグを修正したり、同じ改善を複数回実施している
  • 単一ブランチに実施されるバグ改修や改善策が他のブランチに反映されない
  • コンポーネント間の依存関係が不明確。このコンポーネントがこのように組み込まれなければならない理由を説明できない。
  • 失敗した統合が増えている。なぜこれらが失敗するのか説明できない
  • メンテナンスコストが増加の一方
  • 顧客から直近のリリースではなく、以前のリリースの新しいバージョンを求められる
  • 顧客から、以前のリリースにそれ以降のリリースからの機能をバックポートするように求められる

 
また経験的に以下のような徴候が見られることもある:

  • 構成管理やビルドプロセスがどんどん複雑になったり、保守が難しくなってきている。製品のビルドは熟練者にしかできない。
  • 既にいくつかの製品バリアントがあるが、それらに共通するプラットフォームは無く、それらは無計画に進化している。
  • すでにいくつかの製品バリアントがあるが、製品の差別化要求が高まっている – さらなるバリアントの追加、あるいはバリアント間の違い

 
原因:構成管理ツールでバリアントを管理してしまっている
 


“典型的なバージョンコントロールシステムから派生されるブランチング/マージのログ(左からの時系列)。7つの製品(P1~P7)が 良くあるブランチ&マージ の手順で実装され、それは既存システムのクローンを作って各々独自にメンテナンスされる。全てのブランチされたインスタンスに変更をきちんと同期させ続けることは全く厄介であることは明らか。マージするために必要な作業量から、多くの場合2つの製品間のみでマージが取られることになる(いくつかのパーツを別の製品から取ってくるだけ) システマチック(体系的)な再利用とは言えそうに無い”



“V1~V4(製品バリアント)が共通のベースから生産されている状況。共有されるベースからのバリアントの実際の導出は、コンフィグレーションあるいはpure::variants のような適正なバリアント・バライアビリティ管理ツールによって、独立した活動として実施される。この派生導出/インスタンス化の活動はバージョン管理される成果物の上で取り計らわれる。そこでバージョンコントロールシステムはインスタンスの記録に使われはするが、バリエーションポイントの仕組みは提供しない”
 
参照: プロダクトライン開発に於ける構成管理(バージョン管理)について

バリアント管理できるツールが無かった

 


 ソフトウエアプロダクトライン開発のバリアント管理には、専用に開発されたツールが必要。 
 その理由を pure::variants と Excel の比較、各種開発支援ツールとの比較表にて紹介。
 

再利用が高くつく理由・課題

 
 ・ソフトウエア部品の依存関係が高い
 ・機能追加で依存関係、複雑性、バライアビリティが指数関数的に増える
 ・既存ツールでバリアント管理はサポートされない
 ・製品開発ライフサイクルを通してバリアント管理が必要

ソフトウエアプロダクトライン開発の鍵はバリアント管理

 
バージョンとバリアントを区別して、開発ライフサイクルを通して製品間のバリエーションポイントが、バリアント管理の鍵となる

バリエーションポイントについて

 


 バリエーションポイントは、プロダクトライン開発における本質的な要素。プロダクトラインを構成するものの、異なる全ての場所のこと。これは問題空間と解決空間の両方にある。なぜなら、バリエーションは問題空間で選択可能な選択肢として表され、その影響が解決空間に及ぶので。
 
バリエーションポイントはプロダクトラインの個々の製品を特徴付ける全ての箇所。単一のバリエーションポイントによって、その時点で取り得る全てのインスタンスが表現できる。一般にバリエーションポイントを表現する習慣的なものや、特定の形式的な方法がある。
 
一つのバリエーションポイントはコンストレインツ(制約)によって、それのインスタンスと他のバリエーションポイント間の依存関係を表現できる。それらはコンパイル時、リンク時、ランタイムなどのバインディング・タイムをとり、バリエーションポイントのインスタンスが選択される(決定が実施される)
 
問題空間の自然言語によるシンプルな例は、“自動車は2あるいは4つのドアを有する”
解決空間では、C/C++ の #ifdef/#else/#endif などのようなコード片を包含させるコンセプト
 
そして何よりも重要なことは、これら双方異なる空間のバリエーションポイントは互いに関係しあうということ。

プロダクトラインの戦略(全体像)

 


 この図はプロダクトラインのバリアント管理のエッセンスを表している。ドメインエンジニアリングを通じて再利用資産を見出し、アプリケーションエンジニアリングにてそれらを活用(再利用)する。
 
分離された問題空間(顧客の観点からのバリエーションとしてフィーチャ群、そして利用可能なフィーチャからの個々の選択)と、解決空間(コード、モデル、ドキュメントなど顧客観点のフィーチャを実装するためのもの)。
問題空間以上に解決空間はバリエーションポイントを持つ。一般的には問題空間の一つのバリエーションは4~10の解決空間のバリエーションポイントにマップされる。
 
チャレンジは、絶え間なく進化し、それゆえ意思疎通と決定が欠かせないということ。

バリアント管理ツール pure::variants

 
上手な再利用の鍵はバリアント管理。しかしながら従来のソフトウエア開発ツールは、単一システムの開発にしかフォーカスしない。
 
pure::variants は製品開発ライフサイクルのバリアント管理フレームワークとして各種ツールと連携して、それらツールがバリアントを効率的に扱えるように増強する。オープンインターフェイスを提供し、バリアントの情報は要求エンジニアリング、システムデザイン、実装、テストに渡って一貫して提供される。そして全てのコンポーネントとそれらの用法に対する制限や条件ごとモデル化して管理することで、あらゆる開発成果物がフィーチャの選択で自動構成・生成できるようになる。
 
pure::variants は開発環境を変更する事無く、既存の開発成果物を使い続けられるのでプロセスへの統合が容易。C、C++、JAVA などあらゆる言語に対応し、HW の管理にも活用されている。
 
バリアントモデルは、フィーチャ間のルールや制約で形式的にモデル化され、検証することもできる。また自動的にリソースを活用してバリアントを作成(構成)できる。例えば、バージョン管理ツールからソースコードを取り出して、バリアントコード生成する等、ソースコードのパッケージ化が可能。各種モデル、ドキュメント、部品表の作成もできる。
 

構成管理ツール、変更管理ツールについて

 
プロダクトライン開発だからといって、構成管理に大きな違いは無い。バリアント管理に使ってしまうことさえしなければ良いということ。そして基本的に従来の構成管理ツールが使える。正直、どれでも一緒であって特別なものは必要ない。
 

 
変更管理となると様子は変わる。大抵のツールはSPLには適さない。ただしpure::variants があればSPLを上手くサポートして、製品間のトレーサビリティが取れるようになる。
 

SPLEへの移行

 


 ここまでソフトウエアプロダクトラインとバリアント管理について紹介した。以下、既存製品・ソフトウエアからバリエーションポイントを抽出する方法を紹介する。一からプロダクトラインを作るより、既存システムから行うほうが実践的であり、緩やかに適応できる。
 
一から始めるのと違う点は、既存の資産には、モデルを作成する為の殆どの情報が入っている(隠れているだけ)。ただし、プロセスや生成物の変更は簡単ではない。例えば、一旦開始した、既に製品を開発した、プロセスを変更することは、非常に難しい。しかしながら、適切なプロセスや生成物を始めから用意すること(製品が無い所から、プロダクトライン開発を始める)は、もっと難しい。
 
1:既存製品の相関パターンを知り、移行のシナリオを定める
 
 現状の開発アプローチから、ソフトウエアプロダクトライン開発(SPLE)への興味をお持ちでしたら、その移行に際して、そして移行中に対する多くの考察がありますが、シンプルな確認で、現状を理解し移行方法を知ることができます。この資料では、製品間の関連パターンと、それによるプロダクトライン開発(SPLE)への移行策の関わりについて紹介します。
 

 
 
2:バライアビリティの解析
 


 先ずは、プロダクトのバリエーションポイントを特定・抽出。同時に、それらバリエーションポイント間の関係(制約等)も抽出する。
 
これには、幾つかの見るべき場所がある。ソースコードがその1つで、その構造、アルゴリズム、テクノロジー等から、バリエーションポイントが見つかる。ユーザーマニュアルやマーケティング用資料、コードのコメント等のドキュメント類も重要な情報源になる。
プロダクトが違うバージョンや違う機能で構成されている場合には、バージョン管理ツールやコンフィグレーション方法からも有用な情報が得られる。
 
得られたバリエーションポイントの情報から、問題空間と解決空間に対して、バリエーションポイント、及びこれらの制約の最初の手掛かりを定義する。ここで、最初の手掛かりと表現しているのは、プロダクトラインを進めていく上で、これらバリエーションポイントの情報が変化し続けるので。また、これらバリエーションポイントを定義する事で、プロダクトラインの範囲の特定、プロブレムスペースの定義、コア資産の特定、製品計画の作成を行うときの入力を準備できる。
 
バリエーションポイントは以下で定義される
 
 ・有効な選択肢(フィーチャー)
 ・バリエーションの制約(requires/conflicts)
 ・帰属する空間(問題空間/解決空間)
 ・プロダクトラインのバライアビリティに関する関連性/重要性 
 ・解決されるタイミング
   -製品構成時、コンパイル時、リンク時、インストール時、ユーザによる構成時、実行時
 ・解決方法
   -スタティック ダイナミック
 ・使用するバライアビリティのパターン
 
3:解析の方向について
 
フォワード:問題空間のバライアビリティから
ユーザマニュアルや製品仕様が、既存製品間のバライアビリティについて良い情報源となる場合に良い。プロダクトフォレスト型に向いている。既存ソフトウエア資産を見ないでも(詳細に)、プロダクトラインのスコーピング(適用範囲の調査・物色)ができる
 
バックワード:解決空間のバライアビリティから
ソフトウエアデザインやアーキテクチャが問題空間をしっかりと反映しているなら良い。プロダクトブッシュ、プロダクトギャング型に向いている。プロダクトラインのスコーピングを開始する前に問題空間のバライアビリティを洗いだしておく必要がある
 
Danfoss社では最初にプロブレムスペースからの方法を試み、1ヶ月かけても成果が上がらなかったため、ソリューションスペースからの方法に切り替えることで、2週間で成果を上げることができた。
 
マーケティングや営業などのユーザに近い人たちはフォワードを、技術者はバックワードを好む傾向にある。
 
 
4:問題空間のバリエーションポイント抽出
 
典型的な入力
 
 ・ユーザドキュメント
  -インストール/ユーザマニュアル
  -ホワイトペーパー
 
 ・開発ドキュメント
  -要求仕様、ユースケース
  -アーキテクチャー設計ドキュメント
  -バージョン管理システムのログ(特にプロダクトブッシュ)
  -コンフィグレーションファイル(特にプロダクトギャング)
  -顧客とのコミュニケーション(機能要求等)
 
プロブレムスペースのバリエーションポイントは、インストールマニュアル、ユーザマニュアル、ホワイトペーパー等のユーザドキュメントが典型的な入力。また、要求仕様、ユースケース等の開発ドキュメントを参照することもある。
 
顧客とのコミュニケーションもプロダクトラインでは重要な項目。なぜなら、顧客が必要としている機能を盛り込む事は、製品にとって重要なので。
 
5:問題空間のバリエーションポイントをモデリング –フィーチャモデル
 

 フィーチャモデルはバリエーションポイントをフォーマルに記載するために、最も頻繁に用いられる。一つのフィーチャは問題空間の特性であり、当該するバライアビリティを表現するツリー構造になる。フィーチャの選択肢には、 (mandatory 必須) , (optional いくつでも), (alternative どれか一つ) (or 少なくとも1つ) がある。
 
フィーチャはコンストレインツ(必須、排他、推奨、阻止など)を取ることがある(フィーチャ X には Yが必須など)。またフィーチャは値や特性値も持ち得る。
 
コンセプトがわかりやすく、複雑なフィーチャモデルもナビゲートしやすい。たいていの実問題空間を十分に表現できる。ただし大規模になると専用のツールが必要。特に製品ドメイン専用のルール、コンセプトを包括できるツールは多くないので注意。
 

 
6:解決空間のバリエーションポイントの抽出
 
以下の典型的な入力により、フォーマルなモデル化が実現できる。解決空間、パターンを定義するのは、フォーマルであることが望ましい。
 
 -アーキテクチャー設計ドキュメント
 ‐ソースコード
 ‐コンフィグレーションスクリプト
 ‐プロジェクトのビルド定義(例えば、makefile)
 ‐バージョン管理システムの構造と用法
 ‐コンフィグレーションファイルとファイルフォーマット
 
・殆どの場合、少しのコードを良く見ると、使用されているパターンが明確になる(プログラマーは繰り返しパターンを使いがちであるので、小さな範囲内で得られるパターンは限られる)
 
・大抵コード構造が限定された構文に組み込まれるので、解決空間のパターンは、単純なツールを使って、より簡単に検出できる。 
 
・ただし解決空間から得られるバリエーションポイントの数は大抵非常に多くなることが問題
 
解決空間内のパターンは、以上のような特徴を持っている。ユーザドキュメントと比較してフォーマルであるので、自動的に解析するツールを見つけたり、作ったりする事が容易だが、プロブレムスペースのバリエーションポイントに対して10以上のバリエーションポイントを持つなど、数が非常に多くなる。
 
7:解決空間の基本設計
 
 ・参照される基準としてのアーキテクチャー
   -プロダクトから復元できる(プロダクトギャング、プロダクトブッシュ)
   -単一のプロダクト又はスクラッチから構築が必要(プロダクトフォレスト)
 
 ・コア資産の特定
   -コンポーネントにアーキテクチャー特定の重み付け
    将来の製品での使用可能性
    既存製品での使用率
    適用により期待できる効果
 
  全ての既存資産を使う必要は無い!
 
解決空間のモデルは、設計情報やソースコードを基にして行われる。また、モデルを作成する上で、コア資産の特定も行う。コンポーネントに、使用率や将来の使用可能性、効果による重み付けを行い特定。全ての既存資産を使う必要は無く、バリエーションポイントを作成する事で十分な効果が得られる部分を抽出する事が重要。

組織内の役割分担

 
ソフトウエアプロダクトライン開発を進める為の、幾つかの役割がある。
 
ひとつは、プロダクトラインのプロパティと、それらのリレーションシップを抽出し、それらを定義するドメインエキスパート。ここでプロダクトラインのスコープを決定し、外部へのインターフェース(外部からのプロパティの見え方)、プロダクトラインの資産を開発し、その用法を定義して、プロダクトラインアーキテクトや開発者に提供する。ここで定義する内容はテクニカルである必要は無く、製品ユーザの観点で識別できるようにする。
 
プロダクトラインアーキテクトや開発者は、コア資産をテクニカルな観点で解決空間に定義。
 
アプリケーションアナリストは、プロダクトエンジニアリングを満足する特定のアプリケーション(単一のプロダクト、シングルソリューション)を詳しく調査し、個々の顧客の要求を満足する為に必要な機能を考える。
 
そして理想的には、シングルソリューションでは、個々のアプリケーションが開発者にテストされるだけであること。作成されたアプリケーションをテストし、問題があればドメインエンジニアリングにフィードバックされる。
 
プロダクトラインエキスパートは、開発者、アナリスト、ドメインエキスパート、プロダクトラインアーキテクトと上手くコミュニケーションし、プロダクトラインが上手く成立するように管理する役割を担う。この管理は、単一のプロダクトを開発するよりも複雑な工程になる。

取組み方について

 


 プラットフォームセントリックなアプローチ。各プロジェクトチームより、多くの人員(リソース)を得てプロダクトラインチームを組む。そしてプロダクトラインのコア資産をはじめに作成し管理する。一旦プロダクトライン開発環境が構築されると、コア資産は盤石であるが、それまでは各プロジェクトが進まない。各プロジェクトのバス幅が細いことに注目。 



 進化型プラットフォームセントリック。各プロジェクトチームから少数の人員を得て、プロダクトライン開発チームを組む。プロジェクト開発を進めながら、そこで得られた資産をコア資産に登録していく。ゆっくりと時間をかけてプロダクトライン開発チームは大きくなり、コア資産は更に増加し、各プロジェクトは、より少ない人員で開発できるようになっていく。



 プロジェクトセントリック。各プロジェクトチームからの人員は最小限。プロダクトライン開発チームではなく、プロダクトライン開発マネージメントチームを組む。このチームは管理に専念し、各プロジェクトチームとコミュニケーションを図りながら、プロジェクトチームの成果物を資産登録、管理する。


プラットフォームセントリック 進化型プラットフォームセントリック プロジェクトセントリック
+ 長所 + 長所 + 長所
プロジェクトへの影響が最小 限定的なリスク 最小のリスク
レガシーが無くても始められる 徐々に組織を変えて行ける 組織的な変更が少ない


投資回収が早い
- 短所 - 短所 - 短所
組織への影響大 再利用性の向上が遅い目 最善の再利用規則が求められる
開始に時間がかかる
レガシーシステムを再利用する必要がある
リスクが高い


 
顧客事例で紹介するDanfoss社がプロジェクトセントリックの例。進化型プラットフォームセントリックが最もよく利用されるアプローチ。プラットフォームセントリックのアプローチは失敗するケースが多い。

再利用改善活動を開始

 


 再利用改善活動が開始されると、関係者ごとで得られる個別の成果についての情報交換・意思疎通が重要。だれもその取り組みに興味を持たなければ、協調連携が複雑であることから、成果は容易に妨げられる。再利用性の無いコードを開発者が生成したら、それが拡散してしまうことで望ましくない結果が待ち受ける。成功を目指し、意思疎通を図ることが大切。

調整

 


 計画を貫くことは良いことだが、定期的に調整するとより良い結果に導く。全ての障害は予測できないので、耳を傾け、関係者からのフィードバックを集めること。取り得る改善策を協議し、長期的なものと、急ぎの対策の両方を得ることをいつも求めると良い。

わなに注意

 


<開発が外部委託される場合> プロジェクト費用が工数から算出される為、再利用によって開発時間が短くなっても、利益にならない。彼らは再利用から得られる利益について興味が無く、顧客が再利用を推進するように依頼しても、再利用を成功させようとは考えない。
 
<使用されない資産を開発するケース> コア資産開発チームが開発した資産を他のチームが使わないケースがある。これは組織上の問題で、何処でも起こることではない。あるチームが他のチームが開発したコンポーネントや資産を信頼できない為に、使わないというケースがあった。また、コア資産が十分でない為に使われなかった例もあった。
 
<再利用可能な資産を作成・保守しようとするとコストが嵩むケース> 1つは、そのドメインや組織に於いて、技術の再利用が非常に困難な場合。2つ目は、利害関係者に対する再利用の教育が不十分なケース。管理の立場から見て、全利害関係者に、再利用に関する十分な知識を与える為のコストがかかりすぎる。3つ目は、異なるプロジェクトチームが同じような機能を沢山開発しているケース。これらのプロジェクトでは、少しずつ違う機能が、実装されており、これを再利用する場合、プロジェクト間の調整が困難。
 
<管理側が再利用の為の開発体制を十分にサポートできないケース> 非常に重要な問題。なぜなら、高い再利用性を実現するプロジェクトを始めようとすると、単一のプロジェクトを開発するよりコストが嵩み、開発者が低コストで生産することを要求するとトラブルになるので。

事例

 

 

まとめ

 

  • バライアビリティは少ない目に
  • 小さいところから始める
  • 段階的に整備する
  • 短期的な投資対効果を求める
  • 適切なツールを活用すること
  • レガシーソフトウェアをプロダクトラインに転換可能
  • 移行を始める前に念入りなリスク評価が必要
  • 抽出できる知識の量と質
  • 移行チームのスキルと管理者のサポート