#始めに
私はこの記事を書いている2021年11月現時点で、HR tech業界のリーディングカンパニーを目指す会社で、主に人事系ワークフローと公共向け給与業務機能の開発に従事している。
弊社では良くも悪くも、誰しもが製品知識は**「非同期コミュニケーション」**1 を活用し、評価環境や再現環境、ローカルでデバッグしながら操作することによりキャッチアップする機会が多い。
この手の手法のデメリットは
- 「ドキュメントの質」によって理解度に差が出ること
- 当事者の能力によって理解度に差が生まれる
- やる気がなければやらない
という点が挙げられる。
他社の状況はわからないが弊社では、これが結構普通である。（少なくとも私の周りでは）
かくいう私も入社以来、充分でないのマニュアル片手に、eclipseのtomcatを起動し、マニュアルに従い設定を組み、画面を操作し、製品の動作や仕様をキャッチアップすることが多かった。
最近ではいろいろな勉強会が立ち上がり、開発部門内で閉じるモノだけでも30数ものコミュニティが立ち上がり、皆日々勉強している。（サブシステムやプロダクトに限らず、技術系の勉強会や、輪読会なども含む）
そんな中、私は以下のような課題意識をもって「フロントメンバー2向けサブシステム勉強会」を開催することにした。
- 教わる機会が少ない、もしくは深いところまで学べない
- 最終的に仕様を決めている開発部門からの情報開示量が少ない
- フロントメンバーが育たないと結局問題解決の多くが開発部門に回ってくる
Web系自社開発企業に限らず、プロダクトを持っている企業で働いているプロパー社員は、自分が開発しているプロダクトやサブシステムの最終責任者としての責務があると考えている。
この記事ではその責務を**「サブシステムオーナー」**と定義して記載する。
私が担当する「公務員の児童手当」の機能（サブシステム）についての勉強会をサブシステムオーナーとして開催したことについて記載していく。
※この記事で触れないこと
- サブシステムに利用されているプログラムや技術的な内容
- 弊社で利用している技術的な内容
#児童手当とはなにか、前提情報
エンジニア、プログラムなどには全く関係ないが児童手当について簡単に説明しておく。
詳細は内閣府児童手当制度のご案内を参照していただきたい。
子どもがいるご家庭ならご存じだのことと思うが、いわゆる年に3回中学生以下の子供がいる世帯にお金がもらえるやつだ。
公務員給与業務ではこの児童手当が含まれてくるのだ。
そのため弊社のプロダクトには児童手当サブシステムが存在している。
#勉強会のコンセプト
エンジニアがフロントメンバー向けにサブシステムの勉強会を開催している事例が（私が知る限り）なかったので、まさにパイオニアだった。どうやったらいいか分からないし、何をやったらフロントメンバーに重宝されるかもブラックボックス。
そのため、一般的な勉強会や研修で想像される「講義形式」をベースに、いくつかの仕掛けをすることにした。
仕掛けたこと
徹底的にドメイン解説
児童手当サブシステムの製品側のことを理解するには、まずその業務におけるドメイン知識がないことには始まらない。
ドメインエキスパートとは言えない立場ながら、法定業務なこともあり、内閣府(管轄省庁)のホームページや、e-Gov法令検索などを駆使して、第1回のコンテンツとした。
やはり、知らなかったことについてはもちろんあったが、私自身のキャッチアップにもなった。
結果として、ドメイン知識があれば「これ法律通り動いてなくない？」にも気付けたり、逆に法解釈できてないお客様からの、曖昧な問合せにも対応できる。
そういう状態は、エンジニアのみならず導入担当やサポートセンターのメンバーに対しても提供できたと思う。
ドキュメント化
勉強会でありがちなのがパワーポイントやGoogleスライドのような資料に落とし込むパターン。
しかし個人的にこれで終わらせるのは正直もったいないと思っている。
めんどくさいが、wikiのようなテキストベースのドキュメントに整理し、ストック情報にすると同時に、余裕があればパワポ(フロー情報)、くらいでいいのでは？と思っていた。
そして今回それを実践した。
ドキュメント作成において大きな障害になることは、情報が多すぎて、一朝一夕には作りきれないこと。
それを見越して今回の勉強会は、オブジェクト指向でコンテンツ作成した。
どういうことかというと、
1回1回は完結型にしておき、例えば4回目になると「1回目のここで話したこれは〜、、」みたいな感じで、オブジェクト指向プログラミングのように、呼び出すイメージ。
つまり、完成形はイメージしつつも、1回のコンテンツ分だけを1週間で作り切り、何回かやるうちに気づいたら完成しているという戦法。
将来にも残せる代物が、週を追うごとに出来上がる。しかも準備時間は1日30分〜1時間程度。
アーカイブ化
リモート前提の勉強会なので、web会議システムで開催する。うちはGoogle meetを利用している。
コンサルタントやサポートセンターをメインターゲットにしたので、末端エンジニアとは違い、お客様との会議や、別のミーティングで出席できない可能性があった。
それも全て込み込みで考えていたので、全ての会を動画にし、1時間以内には上の章で述べたところにリンクごとアップするようにした。
これにより「2時間ずれてたら出れたのに〜」みたいな人も即日同じ内容が視聴できるというわけである。
当然ライブ感はないが、某予備校のサテライト授業のようなイメージで受講できる。
予習復習を必須としない
勉強会や研修は座学形式では身につかないという事で、事前課題を設けたり、確認テストを持って出席、みたいなことがよくある(うちでもよくある)。
ただ、正直いちエンジニアの開催してる勉強会でそこまで課すことはできないし、そもそも各自の意思に任せるのも微妙なところである。
そこて、全てを1回の中に詰め込んでまえ！ということで、「エクササイズ」という名で最後の5分〜10分の時間を設けることで、復習を時間内にやれるようにした。
そしてたまに2回くらい前の内容の一部も混ぜ込んだりして、2回目の復習の機会まで含めた。
実は忘れた頃に復習するのが良いということもあってのことである。
※効率のいい学び方については個人ブログに書いたのでそちらも参考にしていただければと思います。↓
双方向型(もうちょいやれた)
上のと被るが、聞くだけの研修や勉強会は記憶に残りにくいし、定着しにくい。
そのため、アイスブレイクでコミュニケーション取ったり、アウトプットの時間を設けることで、できる限り双方向を意識し、参加している感や、取り組んでる感を感じられるように、仕組みとして意図的に用意した。
ただまあもうちょいやれることあったかなーとも思う。
現在のモジュールのロジックにも触れた
結局ここはコード読んだ方が早いのだが、現役のエンジニアではない、普段コードを書いている人だけではなかったので、そこまでは強いることはできない。
そこで、アルゴリズムというか、処理の大まかな流れくらいは知っておくと、どのトランザクションデータが悪さしたか？とかが、トラブった時に仮説として立てられるようになる。
現場の人間にここまでやってもらえないと正直きつい場面も往々にしてあるくらいのリソースでやってるという背景もあり、一部含めた。
そして最終的には将来保守するエンジニアがインデックス（プログラム上、何がどこに書いてあるか探すためのもの）のように使えれば、彼らのためになれば、という思いもあった。
最後に
この勉強会のネタは、弊社の開発部門で開催されてるP2C(Pride & Passion Competition)にエントリーした。
残念ながら本戦に進めなかったのだが(15組中9組が本戦)部長クラスの方々から以下のようなコメントを頂くことができた。
※一部抜粋(と言いつつ98％くらい抜粋).
Hさん
勉強会に参加する人のことを考えて、
負担にならないように、学びやすいように、
気を配ってこだわりつつ、自分の成長にも貪欲に、
機会を生かして成長しようとしている点がすごい。
何かを学ぶ上で、本当に理解するには、得た知識を使う、誰かに教えるのが一番、
という点に非常に共感した。
このマインドは是非これからも広げていって欲しい。
Nさん
とても素晴らしく、PrideもPassionも感じた。
特に「声を大にして言いたいこと」の部分には大きく共感します。(※Hさんの共感ポイントのこと)
自ら率先して行動する、手を挙げる、コミットメントすることは自分のためになる。
@soepyさんはそれをよく理解している。
また先人のナレッジ(developers-dojoのナレッジ)を活用し、
適切な単位でコミュニティを立ち上げ、リモートワーク下で重要な「非同期コミニュケーション」を意識し、
ドキュメントと動画まで用意した点、これらは一緒に働く人のことを考えられており、一緒に働きたいと思えた。
ここまで読んでいただきありがとうございます。
内容が、皆様の勉強会や、学びの場に対する一助となれば幸いです。
また弊社の取り組みとして面白い！興味深い！と思われた方は是非LGTMやコメントください！