📚

ITサービスに貢献する体系化エンジニアリングとは

2022/07/04に公開

AWS

ども、takiponeです。

ITサービスやソフトウェアプロダクトを展開していく10→100のフェーズでは、サービスの機能拡張やドキュメンテーション、導入支援に加えて 体系化エンジニアリング という活動が必要だよ！ということを書いてみます。

要旨

顧客やパートナーに向けた技術習得のための情報発信は、トレーニングや資格試験に留まらずオンラインへ活動の幅が広がっている
オンライン/オフラインを問わない体系的な情報発信をトリガーに、ITサービスへの貢献や社内外の知識・ノウハウ共有を指向するのが体系化エンジニアリング

体系化エンジニアリングとは

SaaSやプラットフォームサービスを顧客が業務に役立てる、パートナーならば彼らのサービスに組み込んだり彼らの顧客に売る。そのための技術支援には様々なアプローチがあります。サービスの初期フェーズであれば、創業者やサービス開発者の知り合いに使ってもらうためにサービス説明のスライド資料やチュートリアルを用意するのがスタートラインでしょうか。顧客が何社かつき営業メンバーが加わる頃には、案件の技術支援を担うソリューションエンジニアや問い合わせチケットに対応するテクニカルサポートが参画し、導入事例紹介やオンラインドキュメントなどドキュメンテーションの整備を進めることでしょう。

体系化エンジニアリングは、その次のフェーズとしてサービスの機能や周辺の要素技術を体系的にまとめユーザーの技術習得を支援する活動です(以下顧客とパートナーをまとめて「ユーザー」と呼称します)。具体的には、社内外を問わない要素技術習得の底上げをはかり、共通の認識や技術用語への理解を醸成します。複数の案件で得たノウハウを汎化したりプラクティスを集約することで、ユーザーへの横展開を促す側面を持たせるのもよいでしょう。ドキュメンテーションと異なるポイントは、サービスの機能説明に重きをおくのではなく、要素技術を機能説明と同等に据えることです。

“体系化”が必要な理由

体系化する理由は以下の2つです。

レベル分け
技術分野の分類

サービスが若いころはアーリーアダプタ層と呼ばれる、技術的にとがっていたり問題に直面してもそれを突破する力のあるユーザーが主体的に新たな事例・ユースケースを切り開いていきます。ある程度技術に明るいであるとか特定の技術分野にはめっぽう詳しいユーザーを相手にするので、足りない技術トピックを補う形で技術支援を行うことになります。そのため支援内容は案件ごとにまちまちで、社内に蓄積されるノウハウや情報も偏ったものになります。

より多くのユーザーにサービス利用の機会を提供するためには、断片的な情報提供だけでは異なるケースや導入が進んでいない業界には適用できません。ユーザーがラガード層で技術のキャッチアップ力があまり高くない、スキルレベルが低いといった場合は、基礎となる情報提供からのスタートになります。情報提供の幅やレベルの広がりに従ってボリュームが増えていくため、アクセスする方が自分で情報を選択できるよう、初級者向け、上級者向けなど習熟度別のレベル分けが必要になり、技術としての体系化が求められるわけです。

また、XXTechと言われるようにサービスと扱う要素技術の掛け合わせ化が進んでいます。業界軸だけでなく技術軸でも、例えばIoT(Internet of Things)分野のようにハードウェアとソフトウェア、デバイスとクラウドというように複数の技術分野を複合的に求められることが増えてきました。技術者は特定の要素技術の習熟度が高い一方で、これまであまり触れてこなかった技術分野にもチャレンジするケースが多くなってきたわけです。技術情報を分類して提供することで、ユーザーは自分にとって必要な要素技術をかいつまんで習得できるようになります。

体系化エンジニアリングの手段

ドキュメンテーションのゴールが『滞りなくサービスを利用するための情報提供』とすると、体系化エンジニアリングは、『サービス利用に必要な要素技術を習得するための情報提供』です。技術分野の体系的な情報は、初学者には習得がどこまで進んでいるかの道標として機能し、経験者には自身の立ち位置や最近の技術動向を知ってもらうために機能します。

体系化の手段として鉄板なのは、トレーニング(研修)や書籍でしょう。ユーザーのまとまった時間をいただいてじっくりと説明することができますし、トレーニングにハンズオン(実機演習)があれば技術およびサービスに触れその場での質疑応答によって確実な理解度向上が図れます。それらに付随する認定資格や確認テストはトレーニングの理由付けとして強力で、知識の定着に大きな効果があります(あと、日本はテストや資格試験が大好きな人が多く、内容に関わらず興味とモチベーションを持つ方が一定数います)。一方、トレーニングや書籍、テストの作成には大きな工数がかかり、そのあとの品質の維持には作成以上のコストがかかります。やっつけで作ってその後の手直しを疎かにしていると、直近の技術動向やサービス仕様との乖離が出てきて混乱を生み、ユーザーが適切な情報にアクセスするための障害になります。一般向けに公開するものであれば、専任担当者およびトレーニングチームを組織して取り組むべきです。組織というとハードルが高いですが、有償トレーニングと資格試験はそれ自体をビジネスにして社内に成果を説明できるという側面があります。

一方のオンラインコンテンツは、以下が挙げられます。

ブログ記事
CMSなどWebページ
動画配信

いずれにも一長一短があるので、目的に応じて使い分けたり併用するのが現実的です。コンテンツの作成は社外に委託しがちですが、今回の目的からはあまりお勧めしません。企画者と執筆者がイコールである必要はありませんが、企画者が社内の各チームに執筆協力をお願いしつつコンテンツの内容について主体的にレビューし、コンテンツ間の整合性やレベルを調整する振る舞いが必要だと考えます。情報処理技術者試験など既に広く普及している技術分野や入門レベルのものは、市販の書籍やYoutube動画など既存のものを紹介してまかなうのも良いですが、自社サービス特有の部分などの整合性は最低限意識しましょう。オンラインコンテンツはあとからの更新のハードルが低いのと一覧やリスト化がしやすいことから、トレーニングや書籍と比べて技術分野の細分化や複数コンテンツの組み合わせがやりやすいと言えます。

“エンジニアリング”として指向するもの

ここまでの内容だと「ひたすらコンテンツを作りましょう！」になってしまうので、“エンジニアリング”というワードには仕組みづくりという意味を込めています。学校など教育機関のイメージからトレーニングであれば履修、認定資格であれば合格がゴールであり、それらを何人が達成したかが主な指標ででした。体系化エンジニアリングは、ユーザーが知識を習得した結果としてなんらか 「次のアクション」に繋げる ことを指向します。例えば、技術の理解からのサービス利用、サービスへのフィードバック促進、ユーザー組織内への技術知識の伝承などがあげられます。

AWSには、それらに繋がる取り組みが多く見られます。クラウドを利用したシステムのインフラ構築・運用のベストプラクティスをまとめたAWS Well-Architected Frameworkは、これをよりどころとして彼らのパートナーにプラクティス適用のチェックを促すパートナープログラムやチェックツールの提供が行われ、AWSクラウドの利用レベルの底上げにつなげています。AWS自身が開発を通して得た、大規模でモダンなシステム開発に必要なプラクティスをまとめたThe Amazon Builders' Libraryもあります。ベンダーサイドではなく、ユーザーコミュニティ主導でクラウドのアーキテクチャをパターン別にまとめたCloud Design Patternも参考になるでしょう。いずれもAWSの広範なサービスを網羅するボリュームのあるものなのでそっくり真似できるようなITサービスはそうそうないと思いますが、位置づけや活動の広がりは手本にできる部分があると思っています。ユーザー組織内への伝承は、ユーザー自身が組織内向けに勉強会などを行うための支援として、コンテンツの二次利用のガイドラインやコンテンツによる指導ガイドなどの整備が挙げられます。

仕組みにはそれを評価するための指標が必要なわけですが、これ自身がまだ体系的な手法として確立されていないため、正直手探りです。まずはサービスへの貢献の数をカウントするところからのスタートになりますが、ゆくゆくはエンジニアリング手法の先輩方であるCRE(Customer Reliability Engineering)やSRE(Site Reliability Engineering)のように、SLOといった新たな計測軸を編み出せるといいのかなと思います。目下研究したいテーマなので、こんなことしてるよ！取り組みを知ってるよ！という方はSNSなどで教えてください！

誰が担うべきか

適任なのは、トレーニングマテリアル(テキストなど教材のこと)の作成経験が豊富なテクニカルトレーナーでしょう。IT技術の一般的なトレーニングでは、受講者満足度や資格の合格率を追求することが多いと思いますので、ITサービスやプロダクトにどう貢献していくのか挑戦しがいがあるのではと思います。デベロッパーアドボケイトやエバンジェリストといったロールもそれぞれのミッションとの親和性がありそうです。

なお、前述の通り指標作りが手探りになると思うので、社内のプロダクト開発チームやセールス、サポートなどなるべく多くのメンバーと接点を持ち、支持を得ながら活動を進めるのが良いでしょう。彼らはITサービスに関するそれぞれの数字を主眼に活動するがゆえに、普段の業務では手が届きずらい部分が少なからずあると思うので、そこを補うようなフォーメーションが組めると信頼が得やすいのかなと思っています。セミナーやトレーニングであれば、アンケートから個別の意見を拾い上げ、プロダクト開発チームやセールスチームへのフィードバックラインとして機能させるのが有効です。フィードバックを出しやすい項目設定やアンケート取得の頻度など工夫するポイントがあると考えています。

まとめ

顧客やパートナーの知識習得、底上げのための情報発信として体系化エンジニアリングの活動をご紹介しました。体系化エンジニアリングには、ITサービスへのフィードバックなど知識習得だけでなく次のアクションにつながる施策を盛り込むことでサービス貢献という新しい形が作れる可能性があると考えています。

あとがき

ちなみに筆者はソリューションアーキテクト(技術支援)職の過去の取り組みを顧みて、自分がやってきたことは一般的な技術支援とは少し違う部分もあるなぁとぼんやり思うことがあり、研修講師の経験も踏まえ体系化エンジニアリングというラベルを付けて文章にまとめてみたのでした。近い取り組みを必要としている組織作りや採用に役立てていただければ嬉しいです。

なお、バックオフィスや一般消費者向けのSaaSやアプリサービスの場合顧客やパートナーは利用にあたり技術要素があまり絡まないので、体系化エンジニアリングはビルディングブロックと呼ばれる特定の機能を持ったテクノロジーサービスやプロダクト、例えば決済やメールやアプリ通知などのITサービスに向いていると思います。まだ浸透していない新しい分野であれば、興味をもってコンテンツを見てもらえそうすし、レガシーな分野でも扱いづらかったり特有の知識が必要な分野であれば検索での流入が見込めそうです。コンテンツのタイトル付けやキーワードを意識するのもよいかもしれません。