Red Hat Project Managerの岡田です。
本記事は、OpenShift Advent Calendar 2022 の13日目として、Project Managerの視点でOpenShiftやRed Hatの価値というお題で書き出してみます。
はじめに
ランニングをしていて、ふと気づくことがあります。
「今自分が汗だくで走っている所は
いつも車で息一つ切らすことなく数分でたどり着くところだ。」
そこから過去に思いを巡らせます。
「自分が車で楽に広範囲に動けるのは、先人の知恵と工夫の結果。
車以外にも、洞穴が家になり、電気を通し、冷暖房を効かせてくれたおかげでこの快適な暮らしがある。」
自分の今後についても思いを巡らせます。
「私も後に続く人の暮らしを、一段上のステージに引き上げるための仕事をしたいものだ。」
過去の経験
私が新入社員から育てていただいた会社では、
10年ほどインフラリードSEやプロジェクトリードとして、提案、設計、デリバリー、保守のサイクルを回していました。
システムを導入する仕事には、以下のようにやるべきことが沢山あります。
システム導入についてやるべきこと
-
お客様の新しいサービスを作るために
人的なツテを総動員して、出張の調整をし、業務パッケージをデモして頂き、お客様と機能のFit & GAP比較を行い、追加機能開発をしてサービス開始します。
多くの労力をかけたデモの結果、不採用となることもあります。 -
採用になったら、必要なサーバーの規模を考えて大まかにサーバー台数やラックや工事を見積ります。
-
発注してサーバーが届くまでの間に、機械室の空調の流れを考えてラック配置や電源や配線を整備しつつ、開発チームに最大トランザクションなどの要件をヒアリングしてインフラ設計を行い、開発チーム用の開発環境を準備します。
-
サーバーが届いたらセットアップです。
優秀な人達が驚くようなスピードでセットアップした数十台のサーバーには設定ミスが紛れており、
コマンドを書いたら全台に配布して結果を得るようなスクリプトを書いて全台の設定差分チェックや修正を行います。 -
開発開始前には、開発用のサーバーを大急ぎで立て、端末のセットアップやバックアップの設定を間に合わせます。
-
短時間のデモでは把握しきれなかった課題が導入した後に発覚することもあります。
-
テストのために、他のチームと環境の競合を占有カレンダーと労力をかけた調整の結果、短時間のテスト時間を得ることが可能でした。
予約した短時間でテスト目的を達成するために、事前にテストの手順と読み合わせを行いました。 -
冗長化のテストも実機を遮断して行い、重要な場合は災害対策の切り替えテストなども行いました。
-
商用移行のために、移行のリハーサルを繰り返し、大量の手順の整備を行いました。
サービスイン遅延につながるような大きな問題は回避できていましたが、大量の緻密な計画と、環境に合わせた人的な苦労や精度が必要でした。
OpenShiftのコンセプトに共感
初めてOpenShiftの話を聞いたときに
「色んな人のシステム導入や開発のやり方をステップアップさせられるコンセプトだ」
と感じました。
共感する部分は主に以下のような内容です。
サービスで稼働するノード数を設定しておくことで、個別システムごとに検討していた冗長化や拡張性の仕組みがOpenShift自体に共通で組み込まれている。
テスト環境待ちもコンテナを起動してテストをすればよい。
テスト環境と商用環境の差分に悩まされることも少なくなる。
設定したコンテナを配布するので設定のばらつきも排除できる。
開発環境やリポジトリも事前にセットされたものを払い出すことができる。
ミドルウェアの導入についても、Red Hat Market Placeと Operatorがあるので導入も簡単。
各社のミドルウェア製品などもRed Hat Market Placeに登録ができる。
過去の働き方との差分を表現してみます。
上段の考え方に対して、下段の違いに価値があるかをみてください。
-サービス毎にサーバー群を用意し、冗長化や拡張性のための個別設計・個別実装をする
+サービス毎の起動数を設定でき、OpenShift自体に冗長化や拡張性の仕組みが組み込まれている
-テスト環境は複数準備できないのでチーム間での競合スケジュールを調整する
+テスト環境は自分用にコンテナを起動してテストをすればよい
-テスト環境と商用環境には環境差分がありチェックや影響調査が大変
+テスト環境と商用環境の物理性能は違ってもコンテナ環境は同じイメージを配布する
-たくさんの設定にはバラツキがありチェックや影響調査が大変
+一つのコンテナイメージを配布するため予期せぬ設定のばらつきが排除される
-開発が始まるまでに急いで開発環境やリポジトリを準備する。
+事前にセットされた開発環境を元に素早く環境を払い出すことができる。(Red Hat OpenShift Dev Spaces / 旧: CodeReady Workspaces)
-ミドルウェアの導入イメージを入手し、手順作成・レビューして、インストール。
+Red Hat RegistryとOperatorで簡単インストール。
-ミドルウェアの広告や広く使ってもらうために雑誌に情報提供など。
+各社のミドルウェア製品なども [Red Hat Market Place](https://marketplace.redhat.com/en-us)に登録できる。
今後、
ミドルウェアに限らず、業務パッケージなどのビジネスに直結するナレッジがある方々が、自社のナレッジをRed Hat Market PlaceなどのCatalogに陳列して他の方に試してもらうことができれば
自分の作った業務の仕組みを使ってもらって導入支援やサポートサービスなどのビジネスができるような枠組みができれば
より多くの人が、より多くの人と嬉しいループを回せるプラットフォームになると感じてワクワクしています。
社外の皆さんも含めて幸せになるループができることで、レッドハットのミッションステートメントが体現されていきます。
to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way
昔は随分面倒な事をしていたんだねぇと、後世の人達に笑い飛ばして貰いたい。
是非とも有効に使って皆で育てていきたい仕組みです。
OpenShiftのプロジェクト状況の変化
コンセプトに共感し、2015年頃に出たばかりのOpenShift v3を、なかなか動かないplaybookと格闘していた頃から、随分時間が経ちましたが、近頃の動きには充実感があります。
各社クラウドベンダーではOpenShiftのメニューが載っている。(参考 : a,b,c,d)
OpenShift自体の導入がv4以降IPIで簡単になっている。
OpenShift上のミドルウェアはカタログ化されて導入が簡単になっている。
OpenShift上でのオペレーターにより、操作の自動化が組み込まれている。
OpenShiftを利用するための移行ツールが充実してきている。
コンテナアプリに関する周辺ツールが増えてきている。
お客様のOpenShift採用も進んできており、基盤ナレッジ習得や導入プロジェクトが多かった時期から、アプリケーションの移行や既にご利用頂いているクラウド乗り換えなど、多岐に渡るプロジェクトが増えてきています。
プロジェクトと製品サポートの価値について
多くのプロジェクトにおいて欠かせないのが製品サポートの存在です。
プロジェクトを実施する場合には、自社のビジネス価値の実現を目指してスケジュールと体制を用意しますが、
潤沢な体制になることは少なく、必要最低限のスケジュールとリソースで、多少の余裕を見て計画が進みます。
製品自体の問題が起きた場合に、その解決を独力でするためにチームの力を使うことは、本来ビジネス価値の提供に向けて使うはずのパワーを使ってしまうことを意味します。
その際にサポートがあると、状況の把握の支援、再現、既知の問題の回避策の提示、根本解決までの大量のワークロードを全世界のサポートチームメンバーに支援してもらえます。
解決を早めるためには、いかに適切に情報提供するかがキーとなります。
インフラSEの頃から、サポートと協業するような問題を沢山経験してきましたが、問題の明確化と再現までを急ぎ、サポートチームにワークアラウンドの提示と根本対処を分担頂き、回避しながら、目的を達成することにチームの力を使う。
サポートチームのおかげで、開発を大きく止めることなくプロジェクトを進めることができます。
-自前でオープンソース製品バグの調査改修を行う必要がある
+サポートチームに回避策や根本対応を依頼でき、サービス提供に集中できる
オープンソースの価値について
プロプライエタリ製品やオープンソース製品の開発者との関係を
誤解を恐れず超簡単に図示すると、以下のイメージです。
一部の人に閉じていないため、多くの開発者が関与しイノベーションを起こせます。
-プロプライエタリ・ソフトウェアのイメージ
- 製品 <- 開発者 ユーザー
+オープンソース・ソフトウェアのイメージ
+ 開発者・ユーザー・開発者 -> 製品 <- 開発者・ユーザー・開発者・ユーザー・・・
プロプライエタリ・ソフトウェアと、オープンソース・ソフトウェアの違いについて
プロプライエタリ・ソフトウェアでは、ある１つの会社が自分の優位性を確保する資産として、厳重なセキュリティ基準を元に、社内のお客様と対面するチームにもソースコードを開示しません。
ある障害が起きたときに、全国の現場のチームもお客様も、状況からここが怪しいというログ解析をしながらも、ごく少数の製品チームの調査と修正を、リモートで悶々としながら待つしかないのです。
これに対して、オープンソース・ソフトウェアでは、現場のチーム自体がソースを確認できるだけではなく、お客様も直接確認することができます。
根拠を持って原因の究明に直接貢献でき、最悪独自の回避コードを一時的に組み込んでいち早くビジネス再開できるかも知れません。
実物が共有され、皆が見られることで全世界の人がその発展や改善に貢献することができることが大きな価値となります。
また、オープンソース・コミュニティには、誰が書いたかではなく、どのような価値のあるコードが提案されたかを元に透明性を持ってコードが取り込まれますので、年齢問わず人が学習できるとともに、実力を発揮する土壌があり、人が育つという意味でも社会的価値があります。
オープンソースコミュニティとRed Hat
Red Hatはオープンソースコミュニティをupstreamとして、修正や追加機能・サポートをサブスクリプションとして提供しています。
upstream側と乖離しないよう、コミュニティ版を最初に修正し、新たなマイナーバージョンが発行されますが、既存の影響を抑えるためfixとして修正が必要な場合にはバックポートして提供することがあります。
個人でコミュニティに修正をコミットしつつ自分の環境を維持するのは労力がかかりますが、サブスクリプションを利用することでコミュニティとの調整負荷軽減や、利用中のバージョンをアップグレードする猶予期間が持てるという利点があります。
もちろんサブスクリプションを持っていても、直接upstreamに還元するという選択肢も取れます。
プロジェクトを進める上での考慮点
少し話題を変えて、効率よくプロジェクトを進めて価値を高める方法について考えてみます。
まずは基本として、
複雑なことを口頭だけで説明する光景をよく見かけますが、そのやり方は効率が良くありません。
実環境や、設定や資料などを共有して、それぞれが手元で同じ資料を見られる状態で話すことをお勧めします。
基本的なことですが、意外にそれを気にしない人が多いので触れておきます。
また、事前に資料をメール送付して会話するやり方は、テーマを明確にし、記録を残すことはできますが効率が悪く、少なくとも会議中に更新ができるGitやWiki、共有ドライブなどの共有スペースを準備することが望ましいです。
さらにMiroやGoogleDoc/Spreadsheet/Presentationなどの同時編集ができるツールが共有されていれば、ディスカッションの質が格段に上がります。
PMとしてはそのような効率の良いコミュニケーションができる環境づくりがプロジェクトの最初の仕事になります。
-効率の悪い形態
- 実環境 - お客様 <-質疑-> コンサルタント - 実環境
+効率の良い形態
+ お客様 -> 実環境or設定or資料 <- コンサルタント
-効率の悪い形態
- 資料送付 - 会議 - 修正 - 会議 - 修正 - 会議合意
+効率の良い形態
+ ドラフト作成 - 会議中に意見を反映 - 会議合意
製品の基本を知ること
OpenShiftに限らず、製品の導入をする上で、まずはその製品の基本について知ることが重要です。
コンサルタントに、あれは出来ますか、これは出来ますか、この仕組みはどうなっていますか、うちの制約は乗り越えられますかと基本を飛ばして環境や実際の設定を見せずに質問攻めにするパターンがありますが、これでは中々前に進めませんし、自分の力もつきません。
効率よく学ぶには、一度製品の最小構成、デフォルト構成でのサンプル導入をやってみることです。
百聞は一見にしかずと言いますが、まさに手元に環境があれば、些細な割に時間を消費する質問が減り、効率が上がります。
投資対効果
環境 > 質問
-サンプル導入しないパターンの質問例
- 「この設定はデフォルトで幾つになりますか？」×多数回
- 「パラメーターシートを作ってください」
+サンプル導入したパターンの質問例
+ 「これらの設定を変更してみましたが意図通りに動かないので教えてください」
協業環境を準備し、効率よく協力すること
サンプル導入をやってみる場合には、一人で触れる環境より複数人で触れる環境の方が、より効率的に共通理解が深まり、協力関係が生まれます。
知らない製品について学習し、サポートをもらう時には、まずは基本的な構成を製品側の視点から作ってみること、作ってみてもらう事をオススメします。
どんなに技術力・突進力のある人でも、最初から最後まで独自で茂みを進むより、まずは近い場所まで舗装された道を連れて行ってもらってから、人が多く通っていそうな足場の良いけもの道を通って得たい果実に接近し、必要であれば茂みをかき分けて進む方が良い戦略になることが多いです。
あなたはどの道を選びますか？
何かを作るとき、
既存の環境や自社の制限に合わせて何を作るのがベストか考えるうちに詳細な議論に入りがちですが、
まずは製品のシンプルな使い方を体験してみて、チーム内で共有してから、どの機能拡張が優先度が高いかを見極めていくことで、製品の特性と現状の機能が理解しやすく、意思決定もしやすいということもあります。
OpenShiftでの監視方式の選択について
運用監視の方式に各種選択があります。
- サービスの監視
サービスとしての重要なアプリケーション機能が動いているか止まっているか簡単に確認できれば、致命的な問題かどうかを即時判断できます。 - 業務の問題が起きた時に、一連の業務がどこまで動いて、どこに問題があったか追跡するため、業務のログを失わないように永続ストレージに保管する必要があります。
- インフラの予備を失わないために、サービスは止まっていないが機能停止した部分を交換するための情報を監視します。
- リソースの余裕を見定めるための傾向情報を収集し可視化します。
メトリックを取得し、傾向から危険を予測することが重要です。 - 監査の点から、必要なポリシーに合わせてログを収集します。
- 可観測性・分散トレーシングを実現するために、ServiceMeshを検討することも有効です。
監視全体を別の切り口で見ると、
管理者としてのモニタリングと、開発者としてのモニタリングの観点から機能を選択することになります。
クラウドの監視ツールを使う、OpenShiftの機能を使うなどの選択があります。
OpenShiftの機能を使うと、複数クラウドを使う場合に統一したインターフェースでの運用を目指すことができますが、他に機能が必要な部分はクラウドの監視ツールで補います。
これらも、最初から全てを完璧に導入することを目指すより、必要最低限からまず実装して機能を確認し、テスト期間中から運用のフィードバックループの中で追加改善を回す方針で進めることをオススメします。
デプロイメントパイプラインの重要性
古くからのデプロイのやり方と悪循環
古いデプロイのやり方に話を戻してみましょう。
思い立ったやり方で、動いているアプリケーションに追加機能を入れる人が居ます。
最初のうちはうまく機能しますが、あるタイミングで、追加機能を入れたことでこれまで動いていた機能に問題を起こします。
問題をおこすのが怖いので、責任のある立場の人が再発防止を命じ、手順化や二重チェックという、コストが掛かる割に担当者の依存の強いプロセスが出来上がってしまいがちです。
-昔ながらのデプロイの流れのイメージ
- 開発 - テスト - 調整・レビュー - 組込手順 - 調整・レビュー - 引継 - 組込 - 確認
+OpenShiftでのデプロイの流れのイメージ
+ 開発 - (自動テスト - AllGreen確認 - テスト済みコンテナデプロイ ) - 確認
OpenShiftでのデプロイの考え方と悪循環からの脱出
OpenShiftでの考え方はどうでしょうか。
開発者がコミットしたコードを、開発環境にデプロイし、自動テストで既存の機能含めて検証し、検証済みのイメージを商用に適用する流れが基本となり、パイプラインを作って自動化します。
商用のトランザクションが発生しないと気づかない問題などは残存する可能性がありますが、発生した問題を確認するコードを再発防止として組み込むことで、人に依存しない、確実に実効性のある一歩改善がなされます。
また、担当者の人為的ミスによる商用でのデプロイ問題発生の可能性は大きく減り、組み込みのためだけの有識者レビューなどで大量に時間を取られて行くネガティブループに対し、ブレーキをかけられます。
-悪いループ
- 障害発生 -> レビュー追加 -> 工数増大&スピードダウン&属人品質による再発
+良いループ
+ 障害発生 -> 自動テスト追加 -> 該当障害根絶&スピード維持
都度マニュアル組み込みを行う場合に危惧される人的なミスのリスクが高い状態から、パスワード変更などの定常的な変更対応と同じようにシステム化され、安全性が認識されているプロセスとして、デプロイの敷居を低くしていくことが頻度の高いデプロイへの挑戦です。Blue Green deploymentやCanary releaseなどもリスクを下げることを助けてくれます。
パイプライン上の自動テスト結果の可視化が重要で、OpenShiftコンソールからパイプラインの状況が確認できます。
常にAll Greenであることが確認できれば、問題発生時のみ深堀りすればよいという良いループを回すことができるのです。
コンサルティングサービスの価値
作りたいビジネスやシステムの規模はお客様やその段階によってそれぞれ異なります。
その時の状況に応じた適切なソリューションを一緒に考えて提供するのが、我々テクニカルコンサルティングサービス（プロフェッショナルサービス）です。
お客様がより良いアーキテクチャーを使って競争力を得て頂き、我々の価値を提供でき、価値を感じて頂ければ我々自身の成長にも繋がります。
製品サポートへの問い合わせはサポートケースを通じて行いますが、テキストベースの問題対応のやり取りを会話により加速させたい時にサポートチームのTAM（Technical Account Manager）やコンサルタントの支援が有効です。
製品サポートの面から複数の製品をまたがって会話や解決を加速するTAMに対し、コンサルタントは製品サポートを前提として、アーキテクチャーの考え方やサンプルコードの提供や構成や使い方・考え方を相談することができます。
製品について学ぶ時にはTrainingやLearning subscriptionを利用することも有効です。
| 種類 | 役割 |
|---|---|
| Training | 製品を学ぶための研修を提供する |
| Consultant | 製品サポートを前提として、構成や使い方のアドバイスをする |
| Technical Account Manager | 複数のサポートケースを跨いで対応する |
| Support | 製品の問題についてサポートケースに対して調査回答する |
製品の問題については、コンサルタントに問い合わせをする場合でも、サポートケースに情報提供を行った上でケース番号を共有することで、サポートチームとコンサルタントが連携してより効率的に動くことができ、お客様自身もサポートケースを有効に活用することができます。
コンサルティングサービスのアサインとして、大きくコンサルタントとプロジェクトマネージャーがいます。
OpenShiftについては、インフラからアプリまで、更に開発の方法や製品に応じたパイプラインの持ち方や戦略、文化にまで踏み込んで幅広く支援する可能性があるため、現担当コンサルタントの専門領域以外に発展することも考えてプロジェクトマネージャーが参画することが多くあります。
我々はロックインを目指すのではなく、Openにサンプルコードや考え方の情報提供をし、お客様自身の力でより良い運用を模索できるように支援することを良しとしています。
もちろん、一度は独力で対応可能と感じたが、再度力を借りたいという時にもご支援します。
ビジネスの段階や変化に応じて対応するために
OpenShiftのパイプラインを整備する際にも、業務開発のやり方もAgilityを持った方法が望まれます。
様々な種類の価値の出し方がありますが、大まかに考え方について書き出してみます。
これらのやり方についても、レッドハットコンサルタントやアジャイルコーチがご支援することができます。
スモールスタート・ソフトランディング・MVP・アウトカムデリバリー
最初から複雑すぎる遠いゴール設定をするのではなく、素早く提供することで、最短で価値を享受する考え方です。
やりたいことは何か。今考えていることは本当に必要なのか。と日々問いながら最小限の提供可能なもの（Minimal Viable Product）を探していきます。
MVPを提供し、実際に使ってみると、意外にこの機能はこれで充分だとか、当初考えていなかった要望などが出て来ます。
無駄を省いて価値のあるものだけをリリースし、素早くフィードバックを受け取ることが肝心です。
また、一度のMVPリリースで止めてしまわず、フィードバックループを回すことがとても重要です。
繰り返し開発・カンバンによる優先順位と要件の明確化
上記のフィードバックループを支えるのは繰り返し開発です。
使いたい機能や要件を、優先順を変更しながら認識齟齬無く提供していくにはカンバンが適しています。
カンバンのツールにも多種多様なものがあるので、多く触れて特徴を理解しておくと良いですが、
こちらもまずはシンプルな使い方から始めてみると、慣れ親しむことができます。（Miro,Trello,GitHub,GitLab,Redmine kanban,SmartSheet,Jiraなど）
自動テスト
繰り返し開発をする上で重要なのが自動テストです。
細かい修正に影響されないよう、本来の目的に則したテストを書いて再利用率をあげることを目指します。
単体テスト、結合テスト、E2Eテスト、ユーザー受け入れ、性能テスト、障害テストなどがありますが、できる限り前半の必要なテストを省略せず、早くフィードバックを得ることが大切です。
自動テストを行えるようにしておくと、何度もデプロイできますし、確認の負荷も軽減できるため仕事のやり方が変わります。バージョンアップ時の影響確認や、セキュリティ状況の確認など、他の領域にも自動テストを役立てることもできます。
可観測性・分散トレーシング・ServiceMesh
アプリケーションがどのように使われ、どこが失敗しているかを可視化し、対応ポリシーを決めることもできます。ServiceMeshの利用も価値を高めていく方法の一つです。
MicroService・疎結合・スケールアウトアーキテクチャー
アプリケーションの作りを疎結合にし、スケールアウトできる状態に保つ必要があります。
その状態を維持することで可用性・柔軟性・再利用性が向上します。
Red HatのコンサルティングメニューとしてMicroServiceの考え方を支援するようなワークショップもあります。
システムの横展開・サービス化の価値
OpenShiftを使う上で、お客様にとって価値のあるものは、その上で動くアプリケーションによって実現される業務的価値です。
パイプラインを作り、競争力のあるアプリケーションを作った際には、是非再利用や他者に向けたサービス化をご検討ください。
社内の他部門に向けてでも良いですし、社外に向けてでも良いです。
流用や再利用でも良いですし、他者に向けてのサービスでも良いです。
丸ごと使えなくても、部分的に再利用できる可能性は多くあります。
せっかく作り上げた資産を有効に使うことで、更に価値が高まります。
もし収入源にすることができれば投資を呼び込むことができます。
他者に横展開する際の再現性を高めるために、コンテナが役に立ちます。
Red Hat Market Placeを活用したビジネスの方法なども視野に入れていくと面白いと思います。
アプリケーションを作成したチームにはノウハウが蓄積されています。
最初に作った後、チームを解散してしまうと、ノウハウが離散してしまい、チームのパフォーマンスが落ちてしまいます。
また、立ち上げ時と同規模でチームを抱え続けることは難しいのも事実です。
もし、他のサービスへの横展開ができればチームを維持拡大する力になります。
マネージド・サービスの価値
マネージド・サービスの利用が今後益々増えていくと想定されます。
OpenShiftにおいても、ROSAやAROなど、マネージド・サービスの利用は増えています。
マネージド・サービスを利用する場合の価値は何でしょうか
素早く使い始めることができますし、製品の実装・維持をするための高度なスキルを組織の外で維持することができます。
-非マネージド・サービスの場合
- ハードウェア・保守作業の自前対応の時間・コスト・スキルが必要
- 構成をカスタマイズできる範囲が広い
+マネージド・サービス利用の場合
+ OpenShiftなどのサービスを素早く簡単に使い始めることができる
+ マネージド・サービス提供者が規定している範囲のみカスタマイズ可能
マネージド・サービスを使う場合には、そのサービスの仕様に従った運用をすることが前提となります。
その縛りに従うことで、自企業だけで努力する運用から、他企業まで含めた共通化によりボリュームメリットが生まれます。
制約を受け入れることで効率を得るという考え方です。
マネージド・サービスとの向き合い方
さて、マネージド・サービス利用の際に、アプリケーションと業務価値に集中したいユーザー企業はどこまでマネージド・サービスの内部仕様に踏み込むべきか、スキルリソースを維持すべきかという質問を、ユーザー企業の責任者である友人からされたことがあります。
明確な答えがあるわけではありませんが、マネージド・サービスとOpenShiftの関係で少し触れて見ようと思います。
利用しているマネージド・サービスを深く知ることは重要であると思います。
しかし、例えばOpenShiftを利用するROSAやAROについて、すべての機能や内部実装を知ることは望ましいですが膨大な労力がかかります。
該当マネージド・サービスを再発明するための、設計・実装スキルは省略できると言えるでしょう。
一方で、そのサービスを利用するためのスキルが必要と言えます。
利用するためのスキルとは、機能の利用・接続・評価のためのスキルです。
機能の利用のためには、全体の中での利用を位置付け、外部との境界を把握し、マニュアルを正しく読み、実際に使ってみて、利用側の実装を行うことです。
接続として、確実に必要なのは、ネットワークに関する知識です。
ネットワークの知識と言っても、内部構造まで全てを知るということではなく、まずは外部との接続や境界についての考え方が理解できている状態です。
正常に接続できることと、セキュリティ的に必要な判断をできることは必須です。
評価として、そのマネージド・サービスに大きく相容れない点がないか、どういう要件や構成を前提にするとシンプルになるかを判断する力も必要です。
しかしながら、冗長化や性能について、事前に判断することは比較的難しく、SLAや実測などで評価していく必要があるでしょう。
世の中に溢れている情報の中から、自分の環境で何を必須と考えるか、その選択によりシンプルにも複雑にもなります。
複雑であればあるほど、習得すべき内容も、対応のコストも、抱えるべきスキルリソースも多くなります。
自分の考えに固執しすぎず、そのサービスの基本の考え方に沿って得たい果実を得るしなやかさも必要です。
マルチクラウドの選択と将来
マルチクラウドを念頭に置いた場合には、特定のクラウドサービス固有の機能を使うと移行の障壁になることがあります。
クラウドサービス固有の便利な機能を使うことと、他のクラウドサービスでも使える機能を使うことを天秤にかけながらプロジェクトを進める必要があります。
究極のマルチクラウドサービス利用を冷蔵庫に例えてみます。
冷蔵庫は冷やして保管してある食べ物が価値です。
冷蔵庫の内部配線や内部構造を熟知する必要はありません。
冷蔵庫の故障や変えたい時に、中身を移し替えれば実害はありません。
マルチクラウドで、コンテナアプリケーションを移し替えられるような戦略を取ることが考えられます。（現状データの同期速度など考慮事項があり、冷蔵庫ほど簡単ではありません。）
リアルタイムに近く手軽に切り替えられる状態になれば、マネージド・サービスの細かい部分障害時の影響をそれほど意識せず、正常な状態と、切り替え方法を理解していれば良いことになります。
OpenShiftの価値は、マルチクラウドによるクラウド選択の自由の発達と、コンテナのエコシステムの成熟によって最大化されていくことが想起できますし、期待しています。
社会のステップアップに向けて
プロジェクトマネージャーという役割柄、基本的な内容を広く浅く書き出しましたが、ここまで読んで頂きありがとうございました。
知っていることばかりで退屈された方、すみません。
考え方やモチベーションなどの面から一部でも、一部の方にでも参考になれば幸いです。
今日述べたような基本的な考えを踏まえつつ、
日々学習しながら、今囚われている前提から抜け出し、
これまでのやり方や社会を一段上にすることに視点を置いて、OpenShiftや他の良い仕組みを皆さんと一緒に使って、育てて行きたいと思っています。
実際に使ってみて、サポートケース、製品改善要望、コミュニティへのフィードバック、自らの利用方法発信などを行う事で、より良い製品になり、仲間が増え、より使いやすい状況に近づけることができます。
徒歩から快適な車へ
洞穴から快適なマンションへ
手運用から快適なOpenShift運用へ
一緒にステップアップした将来を描きながら価値を高めていきましょう！