Masteries

技術的なことや仕事に関することを書いていきます.

YAPC::Tokyo 2019で「チームが前に進み続けるために僕たちが考えたこと」というトークをしました

朝イチの発表でしたが, たくさんの方に聞いていただけて本当に嬉しかったです. また懇親会で「ベストトーク賞, 投票しました!」という声もいただけて, 非常に光栄でした. 公開した資料はこちらです.

「明らかに20分では足りなくて, ここは話せないだろうな...」と思って割愛した部分も付録としてスライドにしていますので, そちらも楽しんで頂ければと思います. あと今回, なんとトークメモを書いて頂きました. 死ぬまでに1回はこういうの描いてもらいたいと思っていたのでとても嬉しかったです. ありがとうございます!!!

その他

今回のYAPC::Tokyoでは, JPA側のスタッフとしていろいろ準備していました. とはいえ本格的に準備し始めたのは12月始まってくらい(10月〜11月は体調が破滅していて, 準備に取り組む余裕がなかった)で, そこから怒涛の勢いでタスクを片付けていく感じになりました. チケットの販促を目指して, 「あなたの注目トーク, 教えて!」という連載企画に挑戦したりしましたが... 効果があったんですかね(その辺りを計測する方法を考えるのを忘れていた!). とはいえ, 毎日毎日様々な記事が公開されることで, Twitterの投稿など, 「YAPC::Tokyoってイベントがあるんだって」と認知頂くきっかけにはなれたんじゃないかな, と思っています. ご協力頂いた皆様, ありがとうございました!

blog.yapcjapan.org

一方当日はRoom0のスタッフをやっていて, 基本的には1日中司会をしていました. 結果として, YAPC::Hokkaido以来2回目の「自分で司会して自分で登壇する」をやりました. スタッフ向けSlackで様子を伺いつつだったのでそこまで集中してトークを聞けなかったのですが, しんぺいさんのトークは流石でしたね(司会やるので聞きに行けない!!! と思っていたけど, スタッフ割当とタイムテーブル確認したらなんと自分が司会する部屋での発表だった). 難しい問題を, 一旦綺麗に分解して依存関係を洗い出して作戦を立てて... というのをシュッとできるのは流石と思いました.

...後はLTでドラ叩いたり, 懇親会でベストトーク賞を受賞したsongmuさんを胴上げしたりしていました.

結構始まる前は「大丈夫かな...?」と思ったりしていたのですが, さすがはYAPC::Japan, 参加者みな訓練されているので, 特段大きな問題もなく, 最後まで終わることができました. 終わりよければ全て良し... とは言いつつ, しっかり振り返って, 「次」に繋げたいですね.

...は, やります. YAPC::Fukuokaでは, 受け継いだバトンをうまく次に繋げるくらいしかできなかったですが, そこから今回のYAPC::Tokyo含めて, いろいろインプットをしてきました. そのへんの知見を活かして, 「受け継いだバトンを, よりよい形で次に繋げる」という所, やっていけたらいいなと思っています.

明日YAPC::Tokyo 2019で「チームが前に進み続けるために僕たちが考えたこと」というトークをします!

papix.hatenablog.com

こちらでproposalを出した件, 紹介しましたが無事採択頂き, 明日の11:20〜11:40, Room0にて発表することになりました.

今回も「僕達が考えたこと」シリーズとして, 初心者向けの内容になっています. スクラムを既に取り組んでいる方からすると少し物足りないかもしれませんが, スクラムに興味がある人はもちろんのこと, チームでプロダクト開発している人たち, 或いはこれから就職し, チームでの開発に取り組まんとする学生さんにも, 何か得るものがある... といいな, と思っています. 結構良い資料が出来たと思っているので, 朝一番の発表ではありますが, 是非聴きに来ていただけると嬉しいです. よろしくおねがいします.

「mackerel-plugin-nature-remo」のv0.1.0をリリースしました

幾つかPull Request頂いたので, Nature RemoをMackerelで監視する拙作プラグイン, 「mackerel-plugin-nature-remo」のv0.1.0をリリースしました.

github.com

v0.0.2では, Raspberry Piなどで動作するLinux ARMのバイナリを生成するようになりました. また, v0.1.0ではNature Remo miniへの対応や, グラフ定義方法の変更などを実施しています. これによって, v0.0.2以前で生成されるグラフとv0.1.0以降で生成されるグラフは互換性がなくなります(別のグラフとして描画されるようになります).

Pull Requestを送ってくださった id:takanamito さん, id:Songmu さん, ありがとうございました.

プログラミング教育に関する私見

はじめに

このエントリは以下の2つのエントリを読んで, Twitterに垂れ流した文章を推敲してまとめたものです.

blog.3qe.us

soudai.hatenablog.com

前提

※記事公開後に追加した文言です.

このエントリでは, プログラミングの未経験者に対するプログラミング教育について述べています. この記事では, 「プログラミングの未経験者」について, 「日常的にパソコンを使っており, 基本的なPCの操作やタイピングが出来ること」を前提とすることとします(あくまで"プログラミングの"未経験者について考えているので, このエントリでは"パソコンの"未経験者については考慮しないこととします).

2つの視点

未経験者へのプログラミング教育について考える時, マクロな視点とミクロな視点(?)があると思っています. 前者はどのようにすれば効率よくプログラミング教育をしてエンジニアを育てることが出来るか? という視点で, 極端な言い方をすれば「どうすればエンジニアの大量生産を出来るか?」と言えると思う. 一方で後者は, プログラミング教育をする対象を選べる(選考出来る)環境で, どう選考しどう育てるか? という視点で, こちらは言い換えると「少数精鋭で育てる時にしっかり成長してもらうにはどうすればいいか?」という見方です.

まず, 前者の「大量生産方式」については, id:Soudai さんも言っているように, かなり難しいものがあると思っています. 「プログラミング言語の使い方」はまだしも, それを応用して, プロダクトを作っていくというスキルは, 小学校で学ぶ国語や算数レベルのもの(= 一定の教育をすれば概ね皆が習得出来るもの)ではなく, 大学の研究のような, 「自らテーマを決めて, 作戦を立て, ゴールに向けて進んでいく」ようなスキル, 経験が必要だと思っているからです.

エンジニアとして育つ為に必要な適性

一方で, 「少数精鋭方式」について考えると, 適性のある人を見極めて教育すれば, プロダクト開発に従事出来るエンジニアを育てることは出来ると思っています. その「適性」についてはいろいろな意見, 考え方があると思いますが, 自分は「自走出来るかどうか」が大事だと思っています.

「自走出来る」というのは, 受動的にプログラミング教育を学ぶだけでなく, そこから疑問点, 課題を見つけて, 周囲の力を借りたりしつつも解決出来る... そういう振る舞いを出来るかどうか? だと個人的には定義しています. 言い方を変えると, PDCAを回せるか? という捉え方も出来ると思います. 大学の卒業研究も, そういった振る舞いが求められるし, それを実践する場だと思っています(本来は...). まあ, モチベーションがあり, そういったアクションを実践出来るのであれば, プログラミングに限らず, 何でも習得していけるという気はしますね.

自分はPerl入学式という, プログラミング未経験者〜初心者を対象としてPerlを学んでもらう勉強会を開催していて, そこにはこれまでたくさんのプログラミング未経験者の方が参加して頂いています. そのカリキュラムを完遂した方の中で, その後も趣味でコードを書いたり, プロダクトを作ったり, カンファレンスで登壇したり... といった形で継続して成果を出しているのは, やはり「自走出来る」人であったと思います.

未経験者採用の"打率"を上げる

昨今, プログラミング教育についての話題が盛り上がっています. これは義務教育にプログラミング教育が入るとか, そういった話題が盛り上がっているのもありますし, 各社でエンジニアの人材不足が問題になっている, というのも理由の1つだと思います.

エンジニアの経験者中途採用が引く手あまたという状態の中で, この課題に立ち向かうために, プログラミングをしたことのない人たちや, 趣味レベルでしか経験したことのないような人たち(ここではそういった人たちを"エンジニアの卵"と呼ぶことにします)を新卒/中途で採用して, 自社で教育する... という動きをしている会社も出てきました. 実際, 前述のPerl入学式でも, シーサーさんが中途採用したエンジニアの卵な方々への, Perl教育をお手伝いさせて頂く... という機会がありました.

post.tetsuji.jp

企業としては, こういったエンジニアの卵を採用して教育するのであれば, 少し言い方が汚いですが, その"打率", つまり「業務に従事出来るレベルまで育った割合」は, なるべく10割に近づけたいはずです. ここまでの話を振り返ると, そのために重要なのは, 「教育カリキュラムを整備する」よりも, むしろ「適性のあるエンジニアの卵を採用する」ことの方が重要である, と思います. ...もちろん, 教育カリキュラムを疎かにしてもよい, という話ではなくて, 適性のあるエンジニアに良い教育カリキュラムを提供できれば, その上を高速に走って, 業務に従事出来るまで素早く育つことができるはずです.

...とはいえ, 「高速に走る」ためには「自走出来る」といった適性が必要で, そこを見極めて採用する必要があり... といったことを考えると, 実はミクロな視点でのプログラミング教育おいては, より大事なのは「どう教育するか」ではなく「どう採用するか」, つまり人事の力が重要になってくる, と言えるでしょう. エンジニアとして業務に従事出来るレベルに育つために必要な素質を持っているか, そして企業文化との適合度合いや, 万が一のこと(= エンジニア職として進むことを断念した時)を考えた人材配置計画など, そういったアレコレを考慮した上で, うまくエンジニアの卵を採用することができれば, 高い"打率"を維持できるはずです.

インターネットが広く普及し, 様々なWebサービスが生まれていく現在, 「エンジニア不足」という問題は, ますます難題になっていくと思います. その解決策の1つとして, これからますます「企業による未経験者へのプログラミング教育」の重要性が高まり, それに本腰を入れて取り組む企業も増えてくるのではないか, と予想しています.

まとめ

  • エンジニアの大量生産は現実的ではない
  • 少数精鋭でエンジニアを育てるのはまだ現実的であろう
  • 未経験者をエンジニアとして育てるのであれば, 「自走する」といった素質が重要
  • 企業がエンジニアの卵を育てるならば, 大事なのはカリキュラムの整備ではなくうまく採用すること
  • エンジニア不足はますます課題となり, プログラミング未経験者への教育に取り組む企業は増えていくのではないか

「アジャイルレトロスペクティブズ」読んだ

年末年始に読んでいました. 「アジャイルサムライ」, 「カイゼン・ジャーニー」, 「アジャイルな見積もりと計画づくり」をお手本にして, チームにアジャイルのエッセンスを取り入れている中で, 「振り返り」をもっと良くしたいという気持ちになっていて, そのためのinputとして年末年始でガッと読みました.

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルのうち, 「振り返り」の部分に特化した本なので, ページ数も思ったより少なくサクッと読めたので良かったです. また, 振り返りをするときに使えるアクティビティがたくさん紹介されており, 付録として, 「どのフェイズでどのアクティビティを使うと良いか」のクイックリファレンスが載っているのも良かったです. 日々のイテレーションで使えるアクティビティ, 複数回のイテレーションを過ごした後に使えるアクティビティ, そしてプロジェクトが終了したり, 一段落したときに使えるアクティビティ... で分類されていて, 「振り返り」の場所(?)を設計するとき, 或いは改善していく時に非常に役立ちそうと思います.

「振り返り」, やはりチームにとって重要で, 例えば今のチームであれば物理カンバンを導入したり, ユーザーストーリーから作っていくフローを整えたり, いろいろ試みていて, 一定の成果は出ていると思っています. 一方でそこで満足してしまったら停滞してしまう... という危機感もあって, そうならないために(チームが常に前に進み続けるために)振り返りが重要, と思っています. 一定期間の自分たちを振り返って, 課題を見つけて, その対策を立てて, しっかり取り組む... その繰り返しが, 改善に繋がって, チームを前に進めてくれる... と信じています.

今回, 「アジャイルレトロスペクティブズ」を読んでみて, チームに活かせそう, と思った部分は結構ありました. ただ, 「これは合わないかも?」という部分や, 咀嚼不足で「どう活かせるかな...?」と思い悩んだ部分も多々ありました. 活かせる部分はすぐにでも取り入れて活かしつつ, 定期的に読み返して, 新たに得た知見を本で得た知見と結びつけたりとか, そういった形でこれからのチームに活かしていきたいですね.