[教育編] 社内の育成に先駆けて【起】
『 まず隗より始めよ！ 』
年始早々なんで、なんとなく書き初めに故事の格言を取り上げてみました。
この先も、「へぇ～、そうなんだ」っていう軽い気持ちで読んでいただけると嬉しいです。
『大きな目標を達成するためには、まず手近な事から始めると良い』
という教えでなのですが。
実は、いまわたしが社内で携わっている取り組みにも、壮大な目標があります。😅 なんと
“今後3年間で150名以上のSOAエンジニアを社内で育成する”
というものです。
※今後というのは宣言した昨年の4月からのことで、今年は早くもその1年目を向かえようとしています……。
このコラムでは、この1年を通じて苦労して培った何らかのエッセンスを綴っていければと思ってます。
手始めに、最初に弊社代表が宣言した『150名以上のSOAエンジニア』を考えた場合、単純に弊社社員数（2009年10月現在）が285名であることを考えても、その半数以上が育成の対象となるわけですね😫 。
わたしはインストラクターでもない一介の業務SEに過ぎないのですが、想像しただけでも冷や汗出ます～。
つまり、その過半数がSOAエンジニアとしての定義をクリアするような目標をうまく主催者側と受講者側とが折衷し、お互いが価値を認められるような共通の目的を掲げていくことが現実解となってきそうです。
弊社のSEは、自身の技術スキルを伸ばすという面において、皆独自の学習方法（リズム）を持っているようですが、
実は、その多くが“上流工程”の何たるかを案外知らなかったり、あるいは理解していなかったりする現状があります。
これは、これまで大手SIerの下で二次請負の仕事をしていたときの御用聞き的な体質や考え方が蔓延していたことなどが原因としても想定されます。
それ以外にも、人材の流動化が進み、以前に比べ先輩が後輩に教え導くような“徒弟制度”が廃れつつあるのではないかと感じます。
そこで、プライムでPJを動かす従来の開発のフェイズになぞったコース体系を考えてみました😋 。これは全3体系あります。
まず、最初の受講者間口を広げるための“入門編”にはじまり、さらに一般的な知識ベースを練成するための“基礎編”を設け、そこから先は自身のキャリアにあわせ任意にコース体系が選択できる“応用編”（上流/設計/開発）を設置しました。
そうすることで、足りないとされる上流工程から首尾一貫した知識体系をOJTに近い形式で学ぶことができます。
弊社の考えるSOAエンジニアの定義には、一般的なSOAの知識ベースの上でソフトウェアアーキテクチャと実装を前提にしつつ、ビジネスプロセスやルールの可視化から適切な粒度の「サービスを識別できるひと」という（技術は後からでも追随できるので）、実装に根差した上流から設計よりの概念を軸としたユーザー指向を重要視していきます。
ちょっと、弊社SOAソリューションの告知です😃。
ここでいうユーザー指向とは、企業側が自立してSOAを管理していけるような“ユーザー主導型のSOA”を指しています。
実際の講義では、徒弟制度のような場を形成し、一般的な文献や書籍では語られないコンテンツを用意することで、受講者の参加意欲を引き立て、自身のキャリアアップにも役立ててもらおうと考えてます。
具体的には
（1）超上流～要件定義：なぜこの仕組みを構築する必要があるのか？を掘り下げる など
（2）設計(アーキテクチャ)：数あるフレームワークから適切なものを選定する基準 など
（3）開発～実装：つくらない開発を目指しOSSのようなベースをうまく活用する など
上記3つの体系を、事前に策定してある社内のガイドラインをもとに、さらに2～3単元に分けて各々のコンテンツの粒度を揃えます。
※だいたい１時間半程度で説明や演習ができる内容となってます。
大枠として目指すところは、小手先のテクニックではなく、あくまで抽象度の高いSOAに対する概念の本質を理解し、現実のPJへ適用する力を養うところにあります。結果的にそれは、自社の底上げも兼ねた全社員への啓蒙活動を余儀なくされることになるでしょう。
まぁ、これ自体は会社が変わろうとする取り組みに向き合えるので面白いのですが、実施に先駆けて大変なのは、万人の理解を得られるような中身の伴った教材(以降：コンテンツ)を作ることにあります。
その対象には技術者以外にも現場でデリバリする営業さんや、入社間もない新人もおり、経験の浅いひとにもそれなりに腑に落ちるものとなっていなければなりません。
どうするんだ、おいっ……😅 。
それには、過去の既知から共感を引き出し、自身の体験とオーバーラップさせ個々の経験に訴えかける事が結構手法として手堅かったりします。
そこで考えたコンテンツのネタには、「誰もが知っている身近なものや事象を分析する」ことや、抽象的な概念を説明したら理解度を深めるための具体例をあわせ見せるようなイメージを定着させる「右脳を活性化させる」的な試みをとっています。
例）人間ドック・健康診断のプロセスや、自動改札機の仕組み など
まずは、“隗より”はじめるつもりで、上記のような手近なところでイメージを共有していき、プロセスやルールの可視化を手掛けていきます。
ただビジネスルールの可視化手法は、あまり公なリファレンスもないので、海外の文献をもとに手探りで体系をつくりあげています。
そのうち、【結】編でそのさわりを見てほしいと思いますが……。
でも、先は長いなぁ
😔。
皆さんは“SOAエンジニア”の定義をどう考えますか？
次回「[教育編] の【承】」で、コンテンツの1部を紹介していきます。来月までお待ちください。