こんにちは、コーディングファクトリー部の丸山です。
先々月の話になりますが、社内コーダー向けに「モジュールコーディング」についての勉強会を開催しました。
通常の業務を行いながらの勉強会の企画や準備は、かなり大変ではありましたが、実際に実施してみて、「ものさす塾講師のときの経験が生きたなぁ」と感じたり、新たに得る部分も大きかったので、今回は勉強会を開催したきっかけ、開催してみて感じたことをお話します。
 

勉強会を開こうと思ったきっかけ

勉強会のスライドの表紙です。見やすさにこだわりました。

コーディングファクトリーにも情報を共有する場が全くないわけでなく、コーダーミーティングと呼ばれる月1回のコーダーどうしの情報共有会があります。
それとは別に勉強会を開こうと思ったきっかけは2点。

1つ目は、神山ものさす塾などを経て入社した新人コーダーも増え、コーディングファクトリーが大所帯になってきました。そのため、もう少しだけがっつり情報を共有できる場があると良いなと思ったからです。
また、私たちコーディングファクトリーのコーダーが模範にしている「コーディングガイドライン」に沿うことで、ある程度の個々のコーディングの差を補うことはできるのですが、新人コーダーのソースコードを眺めていて、
「この部分はもうちょっと切り分けられるなぁ」
「この部分をモジュールと考えるのは多少無理があるかもなぁ」と感じることがたまにあります。
そのため、その部分を意識していくためのポイントをアドバイスできたらと思いました。

2つ目は、昨年私は神山ものさす塾1期で講師を経験したのですが、通常案件のお仕事に復帰してからはその経験を生かす場がなかなかありません。
そのため、講師の経験を生かす機会として、勉強会を開いてみました。
 

勉強会開催までの道のり

まずは、みんなの前で発表するためのスライド資料作りから始めました。
社外で開催される勉強会などで発表されるエンジニアの方のスライドや、SlideShareでスライド資料を見る機会は多かったので着手はすんなりできました。
そこからの作り込みに入る段階で、「ここは文字量が多すぎるから、スライドでは減らして、解説で喋ってカバーしよう」や「この部分は質問されたときに現状だと困りそうだから下調べしておこう」などを考えつつ進めていきました。
 

実際に開催してみて

資料の準備と仕事の両立が予想より大変だった

毎日の案件を行いながら、空き時間や帰宅後にスライド資料を作成するというのはけっこう大変で、思うように進みませんでした。
また、今回の勉強会では伝えたい内容を詰め込みすぎて、スライド100枚近くのボリュームとなってしまい、発表の時間も全体で１時間半近くなってしまったので、もう少しコンパクトにまとめることが重要だと思いました。

勉強会の運営と発表者はわけたほうが良いかも？

今回は、勉強会の主催と発表者を兼ねていたので、自分やメンバーの案件の状況を見ながらのスケジュール調整や資料の準備などを行ったのですが、かなりしんどかったです。
主催と発表者を兼ねた運営を行っていくとどうしても当人のモチベーションや忙しさに左右されてしまうため、開催が不定期になったりそのまま立ち消えたりしがちです。

また、私自身の考えですが、誰かひとりの頑張りに頼るとその人に依存してしまうため、情報や負担が偏ってしまうと思います。それよりも皆がそれぞれ情報発信していく場になっていくと良いなぁと思っています。そのためにも、開催するハードルを下げるための施策は必要だと実感しています。

神山ものさす塾の講師をやっていたおかげで活かせたこと

神山ものさす塾の講師をやっていたおかげで活かせたこともありました。
合間に「聴衆が参加する（聴衆を引き込む）時間」を持つというのは、ものさす塾講師をやっていく中で実践して得たものなのですが、今回の勉強会でもクイズ形式で「このサイトのモジュールはどこで切り分けるでしょうかー？」というような質問を投げかけて２、3分議論する時間を設けました。
このおかげか、１時間超の長丁場ではありましたが、中だるみせずにやりきることができたかなと思います。

「聴衆が参加する時間」を持つというのは、例えば YouTube などで海外の大学の講義や発表を見ているとよくあるのですが、聴衆に質問を投げかけたり、ユーモアのあるフレーズで笑いを取ったり...などをよく見ます。そうすることで双方向の参加となり、発表者も聴講者もモチベーションが保たれるので、私個人としては良いのではないかと思っています。

また、リハーサルはしていたとは言え、勉強会の途中に伝える内容が一瞬飛んだりすることはありました。
そんなときもその場で詰まらず、考えながら話すという感覚も、講師生活を終えてしばらく経った今も衰えずに残っていたので、今後もこの2つは大切にしていきたいと思います。

実際のWebサイトを見せ（左）、参加者どうしで議論した後に正解例（右）を紹介していました。

今回は勉強会を主催してみて思ったことをお話しました。
はじめてだったので、上手くいったこと、問題点など今後の課題はまだまだ山積みです。

今後も勉強会を継続してみて上手くいったらまたご紹介したいと思います。

おまけ

モジュールコーディングについて
モジュールとは

モジュールとは、見出しやテキストなどページ上の役割ごとに切り分けられるひとまとまりのパーツのことです。
例えば、ものさすサイトを例にすると、下の画像のように、ヘッダー、ヒーローイメージ、説明テキスト、見出し、サービス説明のモジュールとそれぞれ切り分けることができます。

モジュールの切り分け例、ヘッダー、ヒーローイメージ、見出し...など役割ごとに分けます。

そしてその役割ごとに、HTML、CSS もモジュール単位に記述していきます。
最近はWeb制作者の間でもCSS設計理論が流行しています。
クラス名のつけ方のようなマークアップの仕方が取り上げられることが多いですが、モジュールごとに分ける、役割ごとに分けるというような単位を区切ってWebサイトのパーツを認識することも重要であると思いますので、覚えておくと良いでしょう。

また、モジュールの捉え方と HTML、CSS のクラス名の命名などのマークアップの仕方については、以前のコーダーのあーだこーだの「新しい時代のCSSへ 〜コーディングガイドライン策定 #03〜」でお話していますので、そちらもご覧になるとわかりやすいと思います。
「モジュール・コーディング」という考え方自体は、現在の Webサイト設計ではベーシックになってきている SMACSS や BEM、FLOCSS のようなモジュールやコンポーネントと呼ばれるひとまとまりのパーツごとに要素を切り分けて管理する方法ですので、そんなに目新しい手法というわけではありません。

しかし、最近のWeb制作技術の流れは非常に速く、常に情報感度を高く持ってキャッチアップしていかないとすぐに取り残されてしまいます。
一人で考えて自問自答しつつ理論を組み立てていくことも非常に重要ですが、勉強会のような場所で自分の考えを共有したり、逆に他の人の意見を聞いて考えを吸収していくことも重要でしょう。