こんにちは。アーキテクトの小林です。
この言葉をご存じでしょうか。旺文社のブランドスローガンです。
「学ぶ人は、変えていく人だ。」
とてもインパクトのある言葉で、素晴らしいメッセージだなと思っています。
この言葉に出会う以前は「システムエンジニアにとって学びは大事」という漠然とした必要性を感じているに過ぎませんでしたが、この言葉に出会ってからは「ＩＴの力で世界を変えたいからシステムエンジニアになった」「世界を変えられるようになるためにこれからも学びつづけたい」という、前向きな信念に切り替えることができました。
この世の中には、時間をひたすら消費するのに、社会にはあまり役に立たないような誘惑が満ち溢れています。そんな中で、この信念を持つことで、すべての誘惑に負け続けることなく、自分の知らないことを学ぶための時間を確保することができるようになってきました。
もし、このような信念をエンジニアリング組織の全体に行き渡らせることができたならば、本当に世界を変えることができる。そんな動機もありまして、広木大地氏の著書「エンジニアリング組織論への招待」やピーター・センゲ氏の著書「学習する組織」を読んで勉強して、エンジニアリング組織における学習する組織とはどのようなものかのイメージを膨らませ、製品開発部門の学びの仕組み作りには積極的に関わるようにしてきました。
今回は、そんなエンジニアリング組織の学びにつながる部門の取り組みの一部を紹介させていただきます。
スキルマップ
学びに可視化は不可欠です。もし、学びの可視化ができていないと以下のような問題が起きてしまいます。
- 現在の自分の立ち位置がわからない
- これから進むべき方向がわからない
- 目標を立てられない
- 振り返ることができない
このような状態では、学びは好奇心の向く方法に進むだけになります。各々が好き勝手な方向に進みますので、組織として学びをマネジメントできていない状態になります。
スキルマップは、各チームで業務を遂行するうえで必要なスキルを洗い出したものです。
さらに、各個人がどのスキルを習得できているか一覧・可視化できるようにしています。
スキルマップ作成において工夫したポイントは以下の通りです。
- 各スキルの習得状況を数値化する（以下は数値化の一例です）
- 無印・・0点：未経験、まったく知らない。
- ▲・・・0点：学び中。チュートリアルをこなした。
- △・・・1点：概要を理解している。独力で扱える。
- 〇・・・1.5点：全体像を理解している。初心者には指導できる。
- ◎・・・2点：マスターしている。だいたいの問題をすみやかに解決できる。
- 全員がほぼ習得しているスキルは新卒や中途入社の社員の注力スキルとする
- 今後戦略的に伸ばしたい注力スキルも明確にする
スキルマップを作成するときに注意すべき点もありました。
それはスキルマップは直接的に人の評価につかうものではないと伝えることです。
スキルマップはあくまでも現在地を知るためのものです。この方式は、広く浅くスキルを学んでいる人の数値が高く、特定スキルに秀でている深堀り型の人は数値が低く見えてしまいます。人の評価はアウトプットした成果や生み出した利益、組織やチームへの貢献など、さまざまな要素で多角的に行われるべきだと思います。
スキルマップは、学びの羅針盤となりますので、定期的にブラッシュアップするようにしています。
たしなみ時間
ソフトウェアや開発プロセスの技術は日進月歩です。しかしながら多くのシステムエンジニアは、目の前の業務に追われています。放っておけば「木こりのジレンマ」状態に陥ってしまいます。
仕事中は目の前の業務に追われる状態であるとすると、学びの時間はプライベートの時間を使うことになってしまいます。
しかし、プライベートの時間は基本的に自由な時間ですし、家事や子育て、介護など自由な時間が全くない人もいます。
このような事情から、プライベートで学びの時間をつくれる人とつくれない人の差はどんどん広がっていきます。
さまざまな価値観やライフステージがある中で、プライベートの時間を使って学ぶことが強制される組織には持続性がないと思っています。
ピーター・センゲ氏が著書で言っているように、一部の人が学習すれば十分という時代ではないのです。
そこで、仕事に必要なスキルを身に付けるために本を読んだり、何かをつくったり、つくったものを発表するための時間を一定時間確保するようにしています。
たとえば、1日の作業時間が8時間あるとして週にすると40時間。そのうちの一定の割合（10％程度）を学びの時間にあてましょうという活動です。
これを「たしなみ時間」と呼んでいます。たしなみ時間で何を学ぶかはスキルマップから選びます。スキルマップは業務を遂行するうえで必要なスキルのリストですので、学んだことはほぼ間違いなく成果につながる役に立つスキルになります。
まだ業務に使われていない新技術を学びたいというニーズもあると思います。新技術はまずは触ってみないとわからないものです。触ってみた結果、実際どうだったのかをライトニングトークやSlack等で共有すれば、組織の知識になります。このようにアウトプットの内容をあらかじめ上長と合意してあれば、スキルマップに無いスキルも取り組みOKにしています。
たしなみ会
「たしなみ会」はたしなみ時間をつかって複数人で集まって何かをつくる会の呼称です。
プログラミング関連の学びは、チュートリアルをこなしても身につきませんので、実際に何かをつくるのが早道です。そして、何かをつくるときは一人より数人集まった方が効率が良い場合があります。
たしなみ会では何をつくりたいのかのテーマはあらかじめ定義しておきます。「ちょっとした事務作業をすばやくこなすための便利ツール」であったり「コニュミケーションや情報の可視化ツール」といったものづくりテーマを日頃から集めておいて、学びたい技術をあえて使ってつくるのです。
この取り組みはまだ始まったばかりですが、うまくいけば学びと業務改善の一石二鳥です。 これからどのように発展していくかは非常に楽しみです。
読書ポイント
読書の可視化です。業務に役立つ本を読んだら、読書履歴のシステム（Excel管理からスタートして社内で有志によってWebアプリケーション化されました！）に登録するようにしています。本のページ数がそのままポイントとして加算され可視化されます。
本を読むことは、物事を体系的に学ぶときに非常に効率が良いツールです。先人たちが何年もかけて研究し、まとめあげた知識をたった数日で獲得できるのですから、もはやチートツールと言っても過言ではありません。そのため、本を読むことの奨励は積極的に行っています。
「でも本を読む習慣がなくって...」という人もたくさんいます。そこで、まず本を読むことの素晴らしさを知ってもらおうということで、読書のモチベーションやスキルアップにつながる齋藤孝氏の著書「究極 読書の全技術」の輪読会も企画・実行しています。ここでは強制的に読書のすばらしさを知ってもらおうという荒業です。
半期ごとに読書ポイントの獲得上位者には表彰しています。といっても何か金銭的な報酬が提供されるのではなく、みんなからの賞賛があるだけです。
読書ポイントは、みんなが本を読んで学んでいる、学び続けていることが可視化されます。このような可視化は組織にとって大事だと思っています。
人が増えれば増えるほど、組織の読書ポイントの累積は増えていきます。 これは組織の知識の成長度合いになりますので、知的資産の可視化とも言えるのではないでしょうか。
新人育成カリキュラム
今年度の製品開発部門に配属される新人から設けた取り組みがあります。それは新人育成カリキュラムです。
もともと会社全体では部署への配属前に新人研修が行われています。
この新人研修では、社会人としての基本的な教育や、当社の技術者としての基礎知識の教育を行うものです。
新人研修のあとは配属後のOJTです。ただ、製品開発部門内にもさまざまなプロダクト・サービスが存在していますので、所属チームによって新人の知識のばらつきが懸念される状況でした。例えば、ecbeingのパッケージ開発をしているチームと、ecbeingの周辺サービスをスクラムで開発しているチームでは、教えないといけないこと、考えないといけないことが違ってくるのです。
そこで、基本はOJTで進めつつ、どのチームに所属しても最低限知っていてほしい知識をリストアップすることにしました。 このリストアップ作業は、入社３年目の先輩を中心にまとめてもらいました。長年いるベテランは新人の当時の気持ちに立ち返ることはなかなかできませんので、新人の少し先輩にあたる人が「これを最初から知っておきたかった」というものを中心に洗い出しました。
新人育成カリキュラムはチェックリスト方式になっていて、その説明と理解できているかの確認のチェックを行うのがピアメンターです。ピアメンターは、言わば新人のお世話役です。新人にとって最も身近な存在であって、業務上で困ったときに一番最初に相談相手になる人です。新人はそもそも何も知らないことが前提ですし、ピアメンターは教える役目なので「こんなことも知らないのか」なんて叱られてしまう心配はありません。
ピアメンターには「心得」も定義してあります。心得の内容は以下の通りです。
＜よりよい関係性を築く＞
- 縦の関係(命令、高圧的、一方的)ではなく、横の関係(相談者、アドバイス、共に考える)を築く
- 相手の行動や意見、失敗を頭ごなしに否定せず、まずは受けとめる。そのうえで出来たこと、正すべきこと、課題を明確に伝える
- 相手にレッテル(思い込み)を張らず、あらゆる可能性を信じて指導する
- 雑談を積極的にする
＜機会をつくる＞
- 日次で業務状況や困っていること、気持ちについて直接会話する時間を作る
- 課題や悩みはピアメンターと新人の間ですべて解決しようとせず、必要に応じて上長にエスカレーションする
- 学びや他メンバーとのコミュニケーション機会を積極的に創出する
＜透明性を保つ＞
- チェックリストは随時更新し、状況の透明性に努める
- 定期的に上長へ状況を共有する機会を設け、フィードバックをもらう
＜ふりかえりと改善を徹底する＞
- 定期的に学んだこと、教育方針をふりかえり、知識の定着と指導方針の改善に努める
- 組織ナレッジとして他メンバーや来年度以降活用できるよう、チェックリスト改善や指導内容のドキュメント化を怠らない
その他
製品開発部門には他にもたくさんの学びにつながる仕組みが存在します。 過去にブログ記事で紹介していますので、その以下から確認いただけます。
今回は製品開発部門の学びの仕組みの一部をご紹介いたしました。
「学習する組織」で紹介されている理想的な状態にはまだまだ遠い状況ではありますが、それでも着実に正しい方向に進めている気がしています。
今後も、業務に負荷のかからないやり方を工夫して、組織の成果を上げながらも個人とチームの学びにつながる取り組みを増やしていければと思っています。
ecbeing では、ずっと学びつづけたい探究心旺盛な人を募集しています!
careers.ecbeing.tech
