大西ブログ

All your blog are belong to us

YAPC::Kyoto 2023 に参加し、キーノート喋ってきました裏話

ブログを書くまでがYAPC!!ということで、YAPC::Kyoto 2023 に参加し、恐れ多くもキーノートを話す機会をいただいて喋ってきました。

資料はこちらですが、資料に書いてない喋った内容が本題なので、そのうち動画が公開されたらそちらで見てください。→ 4/10 追記 公開されました!


発表者ノートつきのkeynoteオリジナルファイルは社内に共有しているので興味ある人は入社してください。 → 採用情報 - 株式会社はてな

YAPC::Kyoto 2023 感想

久しぶりのオフラインイベント楽しかったですね!懐かしい顔がたくさんあって同窓会みたいでした。Perlの同窓会でもあり、はてなの同窓会のようでもあった。
charsbar さんが最新の Perl の話をして、dan さんが正規表現の話をしたり発表にツッコミ入れたり、nekokak さんのエモい話を聞いて、爆笑LTを聞いて、と、久しぶりにYAPCに来た!という気持ちでいっぱいになりました。miyagawa さんが来るの知らなかったので会えてびっくりしました。naoya さんが来られなくて残念。
キーノートを指名いただき、緊張して発表しましたが、多くの方に良かったと言ってもらえてありがたかったです。「僕も頑張ろうと思いました」と感想を言ってくれる人が何人もいらっしゃって。まさに、そういう話をしようと準備したので良かったです。
聞いてくれてありがとうございました。

キーノートの裏話

構想2年制作2日

もともと、YAPC::Kyoto 2020 のときにキーノートのお声がけがあり、その時から暖めていたネタです。
聞いていただいた方はわかると思いますがエモーショナル成分多めのため、話す内容はだいたい決まっているけど、なかなかテンションが上がらず、結局直前2日間で一気に資料を作成しました。進捗が悪かったため社内の人にはご心配をおかけしました。

顔面神経麻痺

1月の末くらいから、顔面神経麻痺になってしまい現在治療中です。顔の右半分が麻痺してほとんど動かない状態からだいぶ回復してきた感じです。まだちょっと話しづらいところもあるので、トークの最初にお断りを入れようかと思ったけど余計なノイズだなと思ってやめておきました。

気をつけたこと
  • YAPCへの感謝と、できれば聞いてくれた人を励ます内容にする
    • できたかな?
  • 自虐になりすぎないように
    • 全体として自虐トークだったわけですが、自虐が過ぎると不快に思われる方もいるだろうと、最低限に留めました。はてなにはずっと優秀なエンジニアが揃っているので、劣等感が育つ機会は多かったのですけどね
  • 自慢になりすぎないように
    • 逆に、頑張った自慢、大変だったマウントにならないようにも気をつけたつもりです
  • 人とサービス
    • 20年間を彩ってきたたくさんの人について話し始めると40分なんてあっという間に終わるので、登場人物を相当絞らせていただきました
    • また、20年間を彩ってきたたくさんのサービスについて話し始めると以下略

スライドの最初の方に出てくる表だけ見ながら何時間でも話せますね。そういうイベントがあったら呼んでください

テーマソング

たまたま最近 LiSA さんの曲をデビュー当時から順に聴くというマイブームがあって、彼女のソロデビューアルバム「Letters to U」収録1曲目、「Believe in myself」の歌い出しの歌詞

いつか この曲聴いた 誰かが今を 愛せたらいい

が、ばっちりシンクロしてしまったので、この曲をテーマソングとしてずっと聞いてました。もし私のトークを聞いた誰かが今を愛せたらいいですね。

特別付録

スライドにある表の元シートを公開しております。

最後に

YAPC::Kyoto 2023 参加者の方、実行委員の方お疲れさまでした!
そして、キーノートという滅多に無い機会をいただけたことを感謝します。配信を家族で見てくれたようで、子どもに親の仕事を知ってもらう機会にもなりました。
ではまた、次のYAPCでお会いしましょう。

はてなのエンジニア×人事の取り組み

久しぶりにブログを書きます。
この記事は、はてなエンジニア Advent Calendar 2022の22日目の記事です。

本記事は、株式会社はてなにおけるエンジニア×人事の取り組みを紹介するものですが、前置きとしてエンジニアだった私が人事部長になった経緯も書かれています。自分語り長文注意。

まず、私は

id:onishi です。はてなの創業メンバーの一人で、現在は取締役、組織・基盤開発本部長、人事部長などを兼任しています。加えて言うとおたくです。

2001年の創業から10年ほどはアプリケーションエンジニアとして、はてなの初期サービス群や、受託部門のエンジニアリングを担当していました。
2006年にはてなで初めてのチーフエンジニアという肩書を持ち、エンジニア組織のまとめ役をしていました。
2011年からエンジニアを主務から外し、この「はてなブログ」の立ち上げディレクターをやりました。
その後、事業責任者やサービス開発全体の責任者を経て、現職に至ります。

人事部長になる

2022年5月の 組織変更及び人事異動 (PDF) で、組織・基盤開発本部長、人事部長を兼任することになりました。
エンジニアからサービス開発のディレクションやチームマネジメント、事業推進、会社の経営執行と、業務の幅を広げてきました。
その際に、やはり自分のベースはエンジニアであり、エンジニア的な視点、アジャイルな姿勢は職種によらず傍らにあり、未知の領域に飛び込むときも、まずは自分で触ってみること、改善のサイクルを回すことを意識してきたのかなと思います。

2022年7月期 通期決算説明会資料 (PDF) にも、「取締役の大西を、組織・基盤開発に専念。エンジニア出身であることを活かし、開発陣含めた全職種の採用・配置・育成に手腕を発揮することを期待。」と書かれています。プレッシャーがでかいぜ。

組織・基盤開発って?

ところで「組織・基盤開発本部」ってあまり耳慣れない組織名だと思いますが、今回新たに立ち上げた部門です。
組織開発と基盤開発の両方を管掌することで、全社の事業を推進することを企図した本部です。具体的な管掌部門とその役割は以下のものがあります。

  • 組織開発(人事部)
    • 採用
    • 労務
  • 基盤開発(プラットフォーム部)
    • サービス基盤 (たとえばはてなID・はてなスターなど)
    • システム基盤 (たとえばインフラ・クラウド管理など)
    • 情報システム
  • 職能組織
    • エンジニア
    • デザイナー
    • カスタマーリレーションプランナー

気持ちとしては、コーポレートと事業の間を全部やる、という意気込みです。

インターネットに新しいもう一つのオフィスを作る

本部ミッションとして掲げたフレーズが「インターネットに新しいもう一つのオフィスを作る」です。
フレキシブルワークスタイル制度」を導入し、リモートワークも増え、働き方も変わってきました。出社率は平均10%程度という状況です。そんな中、実オフィスだけでなく、インターネットこそが新しいもう一つのオフィスである、と考えれられます。
そんなインターネット上の新しいオフィスで一緒に働く仲間を増やし、オンラインで労務を管理し、サービス基盤やシステム基盤、社内の情報システムを整備・運用し、快適なオンラインワーク環境を整えていくこと、それらを組織開発と基盤開発を横断して行うことが当本部の役割だと考えています。

やっていること

もともと事業側から採用に関してはコミットしていたのですが、人事部長になってまずは一通り自分もメンバーの一員として振る舞うことにしました。母集団形成、エージェント・媒体対応、候補者対応、日程調整、面接、オファー、オンボーディングと、全ての工程に関わっていますし、自分の手もまあまあ動かしてます。
事業側、採用人事側の両面の事情がわかることで、効率化を進めました。何がボトルネックになっているのか、ボトルネックを解消するためのワークフローの改善から取り組みました。

採用において重要な指標となる応募から内定呈示までのリードタイムの計測と改善は特に採用率・採用数の向上に貢献したという感覚があります。一緒に業務改善に取り組んだ id:motemen が採用管理システムのデータをインポートしたBigQuery やそのコネクテッドシートでの分析の仕組みを整えてくれたことも大きなポイントでした。リードタイムだけでなく様々な数値上の分析と、分析に基づく仮説検証という武器が得られました。

採用サイトでも、エンジニア採用専門の特設サイトを拡充したり、社員インタビュー・座談会コンテンツを増やしたり、エンジニア採用の採用ピッチ資料も作成してもらいました。

採用以外では、人事データの一元管理とその活用を進めました。サービス基盤部門が協力し、SmartHRのAPIを活用して、社内システムを制作し、業務改善に進めました。

人事データを活用したシステムの例としては、はてなのユーザーアカウントシステムにスタッフの特権フラグを自動で付与・解除するシステムであったり、組織別トラックバック一覧の自動生成であったり、報酬通知書の作成システムであったり、幾つも実際の業務に取り入れることができました。

アウトプット推進

人事を中心とした取り組み以外にも、エンジニアの情報発信には長年力を入れてきました。
Hatena Developer Blogの運営は、チーフエンジニアを中心に、楽しくアウトプットをサポートすることに尽力してもらいました。また、社内の編集者からも支援を受け、コンテンツの品質向上に貢献してもらう体制を確立してもらいました。中でもはてなで働くエンジニアにアンケート連載は、社内の編集者の強いサポートを受けて運用できています。

エンジニアを中心に普段の姿を気楽に伝える新しいチャネルとして、ポッドキャスト Backyard Hatenaを始めたのも、この1年の出来事でした。「社内の雰囲気がわかる」と求職者の方からも好評の声をよくいただきます。

技術勉強会、Hatena Engineer Seminar もチーフ×エンジニア×広報×企画の有志チームで定期開始を実施、毎回クイックにレポートに書き残すことで、やるだけではないコンテンツ化にも取り組んでもらいました。



などなど、たくさんの取り組みがありました。自分が主となったものもあれば、完全にお任せしたものも多数あり、多くの人を巻き込んだ取り組みができたなと感じています。役員が人事に、特に採用にコミットするという姿勢を見せ続けられたことが一番できたことかもしれません。

できたこと・できていないこと

採用リードタイムを始めとした、採用フローにおける数字面の改善は大きく結果に影響したと感じています。フロー改善により、単純に選考回数も倍増できましたし、伴って採用数という結果にも出ています。採用数が◯人に!前年比◯倍!とわかりやすい結果が出ていますが詳しい数字はこの場では控えます。

また、こうした取り組みや、その結果の成果については、外部からの表彰という形で顕れたことも良かった出来事でした。
Owned Media Recruiting AWARD 2022 by Indeedでは、特に情報発信について高く評価いただき、グランプリを受賞することができました。企業のオウンドメディアを推進する会社として、自社の取り組みがこのように評価されたことは大変うれしかったです。

一方で、まだまだできていないこともたくさんあります。

たとえば採用フローもまだまだ改善ができると感じています。手作業を自動化していくこと、ボトルネックを徹底してなくす。採用の各フェーズのコンバージョンは現時点でも悪くない数字ではありますが、さらなる改善・向上の余地があります。
アウトプットについてもより推進していくべく、「アウトプット表彰」という新制度を考えました。一般に人材紹介手当を出す会社は多いと思いますが、「採用に結びついたアウトプット」を表彰する試みを始めました。
そういった新しい試みは常に仮説を立てて、試してみて、結果を見て改善する、というサイクルを回していきます。
組織開発と基盤開発の横断的な取り組みもまだまだ発展の余地があります。現在「組織・基盤開発合宿」として不定期に組織の課題を技術で解決するというテーマでハッカソン的なイベントをしていますが、これもより戦略的に、大きな課題を解決できるようになりたいですね。
そして、人事組織自体の強化もこれからです。今、超少人数で超高効率を実現していますが、これをスケールさせるのが次の課題です。

さいごに

というわけで、いろいろやっているわけですが、冒頭にも書いたように、自分のベースはエンジニアであり、エンジニア的な視点、アジャイルな姿勢は職種によらず傍らにあったなあ、と一年を振り返っても再実感しています。そして、エンジニアもディレクターもそうだったように、人事という新しい仕事も楽しいと思えたのが何よりの収穫でした。
まずは手を動かしてみる。動かしながら学ぶ。仮説を立ててそれを検証する。小さいサイクルでリリースをする。そういった姿勢は、多くの場面、たとえば採用人事といった場面でも強みとなるなと感じています。エンジニアのみなさんの活躍する業務領域は、みなさんが思っているよりも遥かに広大で、いろんな領域にそれぞれのやりがい、楽しみがあるのだと思ってもらってもいいのではないでしょうか。

はてなでは、事業を牽引するエンジニアも、それを支える人事も募集しています!特に一緒に人事をやってくれる人はご連絡ください!

以上、はてなエンジニア Advent Calendar 2022の22日目でした。
昨日の記事は、私がキーノートを務めさせていただくYAPC::Kyoto 2023のコアスタッフでもある、id:papix による「カンファレンスの中の人」でした。
明日の記事は、id:yajimasan です。お楽しみに!

小学校高学年の子どもに読ませている本

この記事は何らかのアドベントカレンダーに参加している記事ではありません。
近年はアドベントカレンダーに参加してやっと年一記事を書くという体たらくですが、今年はアドベントカレンダー参加にもミスってしまった。けど何か書いてみる。

現在我が家には中2、小6の子どもがいる。自分が子どもの頃そうであったように、願わくは本好きに育って欲しいと思って、なるべく欲しがる本を買い与えたり、本を勧めたりしています。そんな事を書いてみます。

ちなみに記事の著者の小説の好みはこちらに詳しいですが、古いし偏ってます。

「子どもを本好きにするには」

絵本館の五味太郎さんのポスターの「子どもがどんな本をえらんでも、けっしてもんくを言わない」。これが真理で、これに尽きると思う。
( 参考: http://ehonkan.co.jp/download/honzuki_poster.pdf )

かのスタージョンの法則に「どんなものも、その90%はカスである」とあるけど、90%のカスの経験が10%の価値を知ることにつながると思っている。また何がカスで何が価値があるのかを決めるのも、経験から自分で決めること。
というわけで、子どもが欲しがる本は特に止めずに与えるようにしてる。マンガでも。下の子は気づくとジュニア空想科学読本を読んでます。面白いけど、18冊も読むかねとか思う(けど言わない)。

子どもが最近読んでる本

小6, 中2ごちゃまぜで(お互いの本を読み合ったりしてるので)

レーベルで本を選ぶ

上述のように、角川つばさ文庫をよく読んでるけど、宗田理のような古いものもあれば、新海誠の映画原作もあったり、バラエティ豊かで面白いなーと思った。
子どもも、同じレーベルは手に取りやすいので、意外と読書の幅が広がるきっかけになる。

古典ジャンル小説もある

古典なんだけど絵が今風になっていて面白い

ラノベの再パッケージ化もある

ラノベ自体がニュージャンルだと思ってるおじさんなのに、それが再パッケージされてすごい(って20年とか経ってるんだけど)

ハルヒって、スニーカー文庫、つばさ文庫、角川文庫と3レーベル制覇しててすごい。

子どもに本を勧める

子どもが読む本は全部ではないけど自分も読むようにしてて、本の感想を言い合ったりしてる。そうやって読書信頼関係をもっておいて、時々そっと本を勧めてみる。嫌がられたら深追いはしない。
失敗例もあって、森博嗣を勧めようと書店で「すべてがFになる」を手渡したら、あらすじがこう。

孤島のハイテク研究所で、少女時代から完全に隔離された生活を送る天才工学博士・真賀田四季(まがたしき)。彼女の部屋からウエディング・ドレスをまとい両手両足を切断された死体が現れた。偶然、島を訪れていたN大助教授・犀川創平と学生・西之園萌絵が、この不可思議な密室殺人に挑む。ミステリィの世界を変えた記念碑的作品。

「ウエディング・ドレスをまとい両手両足を切断された死体」で拒否反応を示して中を見ようともしてくれなかった。
この経験を活かして、人が死なないミステリを勧めようと、「ビブリア古書堂」とか「古典部シリーズ」とかを勧めてそっちはうまくいったのであった。
そのうち、人がバンバン死ぬミステリも勧めたい。その次はSFミステリを経由してハードSFも読ませたい、と夢が膨らむ。

まあそんなこんなで、本好きになってくれてうれしいという話でした。おしまい。

プロジェクト計画について思うこと

この記事は、はてなエンジニア Advent Calendar 2018 の3日目の記事です。
昨日の記事は, id:t_kyt の「time_zone設定の違うMySQLのレプリケーションについて - 角待ちは対空」でした。

最近のわたし

アドベントカレンダーでしかブログを書いてない有様の id:onishi です、こんにちは。最近はこんなことをしています。

はてなダイアリー終了とブログへの統合、利用いただいているユーザーのみなさんへの影響も大きいですし、15年続いたサービスの終了とコンテンツの移転はプロジェクトとしても大きいものです。

オープンなプロジェクト計画

というわけで、わりと雑な僕でも本プロジェクトについては、利用していただいているユーザーの方にも、社内にも、チームメンバーにもプロジェクトの意義を説明できるように、プロジェクト計画書を作り、社内に公開し、さらにそれを作る過程も社内に公開しながら進めました。
そこから得られた知見や気付きをブログにもまとめてみようと思い、本エントリを書いています。

PMBOK

今回、計画を立てるにあたって「プロジェクトマネジメント知識体系ガイド」いわゆる PMBOK (Project Management Body of Knowledge)を参考にしました。

15年続くはてなダイアリーは、社内外にステークホルダーも多く、十分な整理が必要と感じたので、より教科書的なアプローチを試み、それを社内に共有しよう、と思ったのでした。

PMBOK における 5個のプロセス群

PMBOKはプロジェクトマネジメントの知識体系であり、扱う範囲は大きいです。具体的には以下の5つのプロセス群に大別されます。

  1. 立上げプロセス群
  2. 計画プロセス群
  3. 実行プロセス群
  4. 監視・コントロール・プロセス群
  5. 終結プロセス群

今回はひとまず、この1,2番目の「立ち上げ」「計画」両プロセス群について、PMBOKを参考に「プロジェクトマネジメント計画」を立てるということをしました。

PMBOK における 10の知識エリア

またPMBOKは各プロセスをマネジメントの対象により10のプロジェクトマネジメント知識エリアとして分類しています。

  1. プロジェクト統合マネジメント
  2. プロジェクト・スコープ・マネジメント
  3. プロジェクト・スケジュール・マネジメント
  4. プロジェクト・コスト・マネジメント
  5. プロジェクト品質マネジメント
  6. プロジェクト人的資源マネジメント
  7. プロジェクト・コミュニケーション・マネジメント
  8. プロジェクト・リスク・マネジメント
  9. プロジェクト調達マネジメント
  10. プロジェクト・ステークホルダー・マネジメント

プロセス群と違い、知識エリアについては、全ての知識エリアについてプロジェクトの計画を行います。

プロジェクトマネジメント計画書

PMBOKに沿って、10個の知識エリアについて考えそれぞれについてのマネジメント計画を「プロジェクトマネジメント計画書」として作成しました。
書いてみて思った、特に意識した知識エリアについてピックアップしてみます。

1. プロジェクト統合マネジメント

各プロセスを束ねるためのマネジメント、メタな感じですね。このエリアにおいて「プロジェクト憲章」を定め、プロジェクトに迷いが生じた時に立ち戻れるポリシーを定めることが大事です。

実際のプロジェクトにおいて、日々の判断が必要であり、その判断の根拠となりうる、プロジェクトの価値観を明らかにすることは非常に大事だと思っています。リーダーが間違った判断をすることがあっても、価値観をチームで共有できていればメンバーから「それは違う」と言い出せます。そういうチームが良いチームだと思います。

3. プロジェクト・スコープ・マネジメント

プロジェクトのスコープ、つまり何をするかを定義することは、逆に「何をやらないか」を定義することでもあります。

定義が曖昧な時、しばしば起こるのは「作りすぎ」だと思っています。世の中はやれるならやった方がいい事に満ち溢れていますが、全部やってたら終わらないのです。
同様のものに「5. プロジェクト品質マネジメント」があります。必要な品質を満たし、でも過剰品質とならないこと、を意識します。

8. プロジェクト・リスク・マネジメント

プロジェクトの想定されるリスクについてマネジメント計画を立てます。
リスクについて予想するけど対策しない、ということは結構あります。「回避」「転嫁」「軽減」「需要」の4タイプに分けて、想定されるリスクに対して対応戦略を考えます。

たとえば今回のプロジェクトだと、「古いサービスを整理するので思ってもみない仕様がでてきて想定していた工数では足りない」みたいなリスクを想定した場合、「回避」対応としては「単純に工数をもってくる」とか、「軽減」対応として「ある程度の仕様について諦める」といった態度が考えられます。プロジェクト計画の段階で、リスクに対する対策を決めておくのは、実際にリスクが顕在化したときにスムーズな判断を助けてくれます(くれました)。

10. プロジェクト・ステークホルダー・マネジメント

プロジェクトに影響する人を特定しておき、マネジメント戦略を立てます。

このプロジェクトでは「ユーザーさん」から社内の各部署まで、多数のステークホルダーを設定し、関係性を明確にしました。
歴史のあるサービスは当然関係者も多く、何かの決定が思わぬ影響を及ぼしたりすることがままあり、ステークホルダーを整理しておくことで、連絡漏れとか思わぬ影響といった事故を未然に防ぎたいです。

その他の知識エリア

と、4つほど取り上げてみましたが、その他のエリアも重要ですので、軽視せずプロジェクト計画したいですね。

プロジェクト憲章とインセプションデッキ

さて、プロジェクト憲章を作るに当たって、チームメンバーから「インセプションデッキを作ろう」という声が偶然タイミングよく出てきました。そこで、プロジェクトマネジメント計画書における「プロジェクト憲章」をインセプションデッキとすることにしてみました。
インセプションデッキは「アジャイルサムライ」で紹介されたことでも有名な、プロジェクトの開始時に定義すべき10個の質問・回答集です。

インセプションデッキの質問

  1. 我われはなぜここにいるのか?
  2. エレベーターピッチ
  3. パッケージデザイン
  4. やらないことリスト
  5. プロジェクトコミュニティは...
  6. 技術的な解決策の概要
  7. 夜も眠れなくなるような問題は何だろう?
  8. 期間を見極める
  9. トレードオフ・スライダー
  10. 何がどれだけ必要なのか

これは、実際に立ててみたプロジェクトマネジメント計画書の項目とほぼ一致するものでした。「やらないことリスト」は「スコープ・マネジメント」、「プロジェクトコミュニティ」は「ステークホルダー・マネジメント」、「夜も眠れなくなるような問題」は「リスク・マネジメント」そのものですね。
そもそも体系化されたプロジェクトマネジメント知識は、アジャイルな開発における計画においても有効であり、参考にされているものだということですね。ちなみに、PMBOK6版においてはアジャイルについての解説が強化されています。

両方やって思ったことは、以下のようなことです。

  • PMBOKにおける「プロジェクトマネジメント計画書」は、方法論がしっかりしていて、これに沿って書きやすい、と感じた。一方で扱うプロジェクトの範囲が、小さなものから大きなものまで幅広いため、資源やコストのマネジメントについては(今回は)オーバースペックに感じた
  • 「インセプションデッキ」は、要素としてはPM計画書とにているが「わかりやすく相手に伝えるツール」として優れていると感じた

という意味で、今回両方を実際に書いてみてそれぞれの特徴を感じました。

プロジェクト計画の共有とアップデート

さて、プロジェクト計画において大事だと感じることは、その計画をちゃんとステークホルダーに共有すること、そして、計画を更新することだと思います。
PMBOKはウォーターフォール型のプロジェクトもアジャイルなプロジェクトも扱います。計画段階においては、どちらも計画は大事です。計画を実行するにあたって両者に生じる違いは、手戻りが難しいウォーターフォールに比べて、アジャイルは定期的に振り返り、プロジェクト自体を改善していくことができることだと思います。
その意味で、「精緻な計画を立ててそれを実施する」というのではなく、「書けるところからでも計画を書いてみる。それを定期的に振り返り、計画自体をアップデートする」ことがアジャイル開発においては特に大事だと考えます。

今回のプロジェクトでは、四半期で計画の振り返りをし、大事に思っていたことが実現できたか、当初と想定が違い優先順が変わることはなかったか、ステークホルダーの見落としがなかったかといったことを確認し、文書をアップデートし、その内容についてチームメンバーから意見も求め、結果を共有しました。
これは四半期と言わず毎月くらい実施しても良かったですね。

まとめ

計画を立てて、チームの意識を統一する、リスクへの対策を考えておくことは、プロジェクトが大きくなるほど大事ですが、小さいプロジェクトでも軽視せず、意識することが大事だと思います。インセプションデッキは必ず作る習慣をつける、とか。

最後に、ブログ統合のプロジェクト憲章(インセプションデッキ)に掲げた文章を紹介します。

はてなのコンテンツプラットフォームサービスの未来に向けた開発を行う

近頃、複数のサービスの終了のニュースが続いていますが、ユーザーさんのコンテンツを扱う、コンテンツプラットフォームサービスは、はてなの柱であり、その未来に向けた開発をしていきたい、そのための準備としての整理のつもりです。今後のはてなにどうぞご期待ください。

一緒にプロジェクトを進める仲間も募集中です!
hatenacorp.jp

Scratchを使った子どもへのプログラミング教育

この記事は、はてなエンジニア Advent Calendar 2017 の19日目の記事です。
昨日の記事は, id:papix の「「雑に文章を書く」活動と, そこから得たもの - Masteries」でした.

僕には今、小6と小4と二人の子どもがいるのですが、2年ほど前から子どもたちに Scratch を使ってプログラミングを教えています。そこから得た知見などを書いてみます。(最近はサボってるのでごめんよ子どもたちよ)

Scratch とは

説明も不要なくらい有名になってますが、Scratchとは、MITメディアラボが開発している子ども向けのビジュアルプログラミング言語です。アラン・ケイのスクイークをベースに開発されています。
ブロックのように命令を組み合わせてマウスでプログラミングでき、マウスだけでも簡単なプログラムは作れるので児童にプログラムの基本概念を教えるのによい(とされている)。
Scratch 2.0 はFlashプレーヤーを搭載したブラウザだけで動くので、今すぐあなたもプログラミングできます。この記事の中にも動くプログラムを幾つか埋め込んでいるので是非試してみてください。

https://scratch.mit.edu/

なぜ子どもにプログラミングを教えるか

義務教育でプログラミングが必須授業だとか、AI社会に向けて、とか色々言われています。が、割とどうでもよくて、僕は子どもと共通言語ができる、自分のやっている仕事を子どもに理解してもらえる、というのが大きいと感じています。

我が家での導入

プログラミングスクールの体験会に参加

Scratch自体はエンジニアなら触れば大体わかると思いますが、子どもにどういうテンション、カリキュラムで教えるのか、を体験するために、無料体験会に参加してみました。
PC触るのも初めての子どもを対象にしていたので、すごくわかりやすいテキストを写経するだけの簡単なものでしたが、子どもが熱中し、できたものを自分で作り上げたものとして誇らしげにしている様が印象的でした。

書籍の購入

子どもが読めるテキストを購入しました。教えるテキストとして、また自分の理解のために。ある程度進んだら、本を与えると自分で勝手にプログラムを作る、本を発展させて自分で作りたいものを考えるようになるといいですね。

阿部先生の本。アラン・ケイのメッセージも載っててグッときます。Scratch1.4ベースですが最初に読ませる本としてはベストでは。

2冊目。Scratch2.0ベースになってるし、2冊目として高度化した内容。この2冊は最初に買う本としておすすめです。

その他の書籍の紹介

(我が家では)子ども受けはイマイチだったものの、面白かった本も紹介します

ヴォーダマンの本。前半Scratch、後半Pythonという構成。Scratchで学んで手続き型プログラミングって、Pythonでも一緒だよ、という主旨だけど子どもはタイピングできなくて詰む。

こちらはもう少し高度な内容。一冊かけてシューティングゲームを作る。基本~応用初級くらいまでが学べる。

Scratch でアルゴリズムを学べる。線形探索とかソートのアルゴリズムをScratchで学べる。自分は面白く読んだけど、子どもに読ませるのは少し先かな。

do it yourself

本で基礎を学んで、なんとなく「何でもできる」感を感じてもらったら、あとは好きに作らせるといいですね。音を鳴らすもいい、カメラを使うもいい、Scratchでできることに限界を感じたら、もっと高級な言語を学ばすなり、ロボティクスにいくなり、どっちに行っても楽しいです!(子どもも親も)プログラミング教育最高。

やってみる

前置きが長くなりましたが、Scratchプログラミングの例として fizzbazz を書いてみましょう。

f:id:onishi:20151021190649p:plain:w400

https://scratch.mit.edu/projects/194480042/#editor


Perl ならこんな感じですね

my $i = 1;
my $serif = '';

while (1) {
    $serif = $i . '! ';
    if ($i % 15 == 0) {
        $serif = $serif . 'fizzbuzz';
    } elsif ($i % 3 == 0) {
        $serif = $serif . 'fizz';
    } elsif ($i % 5 == 0) {
        $serif = $serif . 'buzz';
    }
    print $serif . "\n";
    sleep(1);
    $i++;
}

一緒じゃん、ということで、子どもに手続き型プログラミングを教えるのに Scratch は最初の一歩に良いなと思っています。
とにかく、マウス(トラックパッド)の操作さえ教えれば、キーボードをほぼ触らずにプログラミングが組めるのは画期的で、参入障壁が低いです。

メッセージング

Scratch の基本は手続き型プログラミングですが、スプライトのクローンでオブジェクトも作れるぞ!(ちょっと違う)
そして複数のスプライトとその間のメッセージ通信ができるぞ!(ただしブロードキャストのみ)

f:id:onishi:20151021180930p:plain


リミックス

GitHubのソーシャルコーディング、素晴らしいですね!Scratchでもソーシャルコーディングできる!
クリエイティブ・コモンズの継承ライセンスで公開、リミックスができます。リミックスツリーというビューがあり、ビジュアライズされます。他の人の作ったプログラムに自由に改変を加えて発表でき、それがさらにという循環が生まれます。
自分の作ったプログラミングが公開できて、コメントがもらえたり、forkして新しいプログラムが生まれるという体験をローティーンでできるのはすごい!僕も実際コメントをもらったりforkされたことがありましたが、ちょっと感動がありました。

いろいろやってみた

というわけで、Scratch が楽しいので、勉強がてら自分でも Scratch ブログを始めてみました。
まだ記事数は少ないですし最近更新も滞っていますが、興味ある方は是非読んでいただければと思います。
oniscratch.hatenablog.com

おすすめ記事

その他いろいろやってます!見てください!&アドバイスください!

Scratch の発展・今後

Scratch2MCPI

みんな大好きマインクラフトでプログラミングを勉強しよう!ラズパイで Mincraft Pi を動かして、Scratch でプログラミングできます!子どもの興味を引く「自作PC(ラズパイ)」「マイクラ」「Scratch」で完全勝利ですね

Scratch 3.0

Flashで動作していた Scratch が HTML5, WebGL といった標準化技術で使えるようになるぞ!

Appendix

教育

サイトなど

最後に

駆け足になりましたが、プログラミングは楽しいですよね、それを子どもに教えるのもまた楽しい。未来の日本のために、我が子の未来のために、自己満足のために、子どもとの対話のために、プログラミングを教えましょう!
あなたの知見も教えてください!

はてなで一緒に働きませんか?