自社の新人向けにワークショップを開催した

概要

自社の新卒に対して、自主的に（勝手に）ワークショップを開催して、どんな感じで仕事をするのか、成長するためにはどうしようか、ということを一緒に考えた。久しぶりのワークショップ開催・ファシリテーターだったので結構戸惑うことが多かった。

対象

自社に新人3名が入ってきた。いずれも未経験ということで自分（3年目）と同じ立場ということで、なにか手伝えることは無いかなーという課題意識を持っていた。

目的

何しろ自分も未経験でプログラミングなんすかそれ状態から始めたので、とても苦労が多かった。そもそもの概要とかどういうふうにシステムができていくのか、システムが作られるにはどういう要素が必要なのか全く分からず、それを一発で説明してくれる本は見つからず（見つけられなかった）、現場に入ってからなんとかかんとかい曖昧ながら理解をしてきた、という泥臭い「ここまで」だった。

新卒に対してそれを経験させたいかというとNOだな、と思った。もっと素早く理解させてあげる方法はいくらでもあると思うし、「現場で経験を積んで一人前になるんだ」という考え方はマッチョイズムな自己責任論だし、それについていけない人を出すのは全体にとって損なことだな、なんとかしたいという問題意識を前々から感じていた。

他の問題意識

おそらく自分と新人は同じ外部研修を同じタイミングで受けることが分かっていた。最初の2ヶ月を他の会社の新人さんたちと過ごしながら、システムとは、アルゴリズムとは、Javaとは、DBとは、開発手法とは…と本当に1から学んでいくカリキュラムだ。

未経験の人たちにとってこれはかなりありがたいものだと思う。1から教えてくれる人は現場には存在しない。上述した通り本を読んでも1から体系だって説明してくるものはなかなか見つからない。

ただ、カリキュラムにはうーん、と思う点も（振り返ると）存在する。例えば、

2019年にJSP サーブレットを学び、演習でもこれを使う
やたら服装にうるさく、スーツにネクタイが苦しい
（今はどうかわからないが）4GBのマシンを使うのでちょっとストレスが溜まる
講師の主観的な意見に新人が左右される

といった点がある。実際の現場は（場所によるのは当然だけど）この通りじゃないので誤解は解いておきたいと思っていた。

あと4点目に関しては、自分が新人のときは（雛鳥の話じゃないけど）最初に知ったものを正しいものとして捉えるので、この固定概念を持たないうちに教えておく必要があるな、と危険視していた。

ワークショップの内容

アイスブレイク

アイスブレイクが無いと以降のアクティビティで活発な意見は出ない。アイスブレイクによって互いを（信頼とまでは行かないまでも）危険じゃない存在と認識してもらって、どんな意見を出しても安全だぞ、という認識をしてもらうためにも必要になる。単に遊びたいわけではない。

今回は「偏愛マップ」を採用した。A4の紙の真ん中に自分のアイコンを描き、あとは思いつくままに自分を構成するものや好きなもの、ハマっているものをカオスに書き散らす、というルールに則って自己紹介をする。形式がゆるいので各自の個性が出てしまうのが狙いだったりする。

初対面の人が一気に仲良くなれる「偏愛マップ」というものを試してみたら想像以上の効果があって、色んな人のを見てみたくなったお話

今回やってみての結果としては、もう少し互いを信頼している状況でやるべきかなと言う反省点が残った。偏愛マップはもともとクリエイティブなコミュニティと相性が良く、自分を発信することに抵抗がない人にとっては楽しいけど、見せびらかしたくないなという人にとっては難しく考えすぎてしまうことになる。今回は後者の傾向が多かった。自分が好きなアクティビティだけど、場所に応じて適切に選ぼうと思った。

ブレインストーミング

自分が思ったことをただただ話すだけでは上記の問題意識が伝わらず、押し付けがましく感じられる、話が入ってこないという想定ができたので、まずは各自が思っていることを表明してもらい、それに対してアドバイスや更に質問を繰り返して掘り下げる、という方法が好ましいと思った。

そのため、具体的にはブレインストーミングの形で「研修で覚えたこと、やったこと」を思いつくまま付箋に書いてもらって、それをホワイトボードに貼って眺めながら各自に共通する問題意識を改めて確認してもらうようにした。

研修のカリキュラムを書いていたりするので写真を載せられないのが残念だが、大きく数点のカテゴリに分かれることがパット見でわかった。

プログラミングや技術に関する興味
問題を捉えて解決することの難しさ
社会人としてどう過ごしていくか
コミュニケーションの難しさ、奥深さ

といった感じだった。技術一辺倒になると思ったら問題解決に対する付箋が想定よりも多く、学生時代に対処していた「問題（設問）」と今回立ち向かった「問題」が別物であることは、無意識的なところで認識していたようだった。

これについては、聞いてみたところ学生時代にワークショップやサークルなどでこういう問題解決プロセスの体験をした人がいなかったので、なるほど新鮮に感じるわけである。

上のような感じで、KJ法の要領でカテゴリ分けした後は、断片的だと感じた付箋に関しては具体的な想いを確認した上で、このカテゴリに関しては…と1点ずつ経験や理論的な側面をもとに今後の助けとなるような説明をした。特に、当時の自分は技術的な内容に対して「研修で覚えたことが全体の30%くらい」と誤認していたので、同じ認識間違いをしないように「5%もないです」くらいのことを言っておいた。

ブレーンストーミングとKJ法

コミュニケーションについては、主に雑談や仲良くなる、気まずい間を埋めるためのコミュニケーションと、自分の想いや意図を適切に伝え、またその話し手の説明をうまく引き出す、承認するといった聞き手としてのコミュニケーションという大きく2つがあることを説明した。

社会人として～は、実際は現場によって価値観やルールは（同じ〇〇社の現場であったとしても）全く異なるので、そこまで重く受け止めなくていいですよ、と安心させておいた。

プレゼンテーション

残りの時間は、自分が新人の立場で何を知っておいたらよいのか、というテーマで書いた以下の記事に沿ってスライドを作り説明した。

未経験からエンジニアをやるために

最初に思いついた6点についてのみ書いているので、これが全てではないことを自分でも分かっていたが、全てを伝えるのは無理だなとも分かっていたのでこの量に抑えた、つもりだったが、実際には想定より時間が膨れ上がってしまい、互いに対話するような時間がどんどん削れてしまった。これが最大の反省点だった。当初の目的は新人自身に問題意識や目的意識を持ってもらうことだったので、それが達成できていないことになってしまった。つらい。

フィードバック

BeforeとAfterに分けて、自分の中でどのような変化があったかを発表してもらった。これを最後に発表という形でやってもらうことで、参加者それぞれが自分のやりたいこと、やらなきゃいけないことを自然と探してくれる効果があるので、ただ終わりです、というよりも印象が大きく異なるので時間が押していてもここは削らないようにした。

新人は共通して勉強するということに対して見通しがたったようだった（エンジニアとしての勉強方法が分からない、不透明だという意見に対して、ちょっとずつできるようにする、学習サイトや環境構築をスキップできるようなカリキュラムから始める、という提案をしたため）。

おまけ

個人的ファシリテーションTips

付箋はできる限りポストイット強粘着を使う。付箋が剥がれて落ちてしまったらかなり予定が狂ってしまう。
付箋にはプロッキーやマッキーなどを使って、大きく書いてもらう。ホワイトボードや模造紙に貼ったときに見えるようにするため。
ホワイトボード用のペンは先が角芯になっているものを使って、横棒は細く、縦棒は太くという明朝体ライクな感じで文字を書くと、字に自信がなくてもうまく見える。ペンの持ち方を固定するだけでOK。「たぬき油性マジック」というフォントはこれを元にできている。
付箋を動かしたりホワイトボードに意見や結論を書くときは必ず参加者の承認をもらう。これによってホワイトボードがそのまま議事録になる。
クローズドクエスチョンとオープンクエスチョンを使い分けて話し手の意図を引き出す。
ファシリテーション・グラフィックは絵がうまくないといけないというのは嘘。