Masteries

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

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

はじめに

このエントリは以下の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として年末年始でガッと読みました.

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

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

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

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

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

2018年の振り返り

あけましておめでとうございます, 2019年もよろしくお願いいたします. というわけで2018年が終わったので振り返りをします. 今年もKPTでやっていきましょう.

過去の振り返り達

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

K

「2018年にやってみてよかったこと, 2018年も継続して取り組みたいこと」

いろいろと良い結果を残せた

入社して2年目, 徐々に慣れてきたこともあってか, 去年は業務においてそこそこの規模の成果を幾つか出せました. 一番印象的なものは, 2017年からほぼ1年にわたって取り組んでいた「はてなブログのHTTPS化」が無事完遂したことでした.

papix.hatenablog.com

リリースにあたって大きな問題なく出せたのが何より良かったですし, そこで得た知見や気付きなどを, エンジニアセミナーや「Rejectcon 2018」で発表したり, GeekOutでインタビューして頂いたりすることができて, 外に向けて発信出来たのも良かったです. また, 詳しくは後述しますが, Go言語習得の取っ掛かりになったのもHTTPS化の作業がきっかけでした.

もう1つ, 「はてなブログのHTTPS化」より規模は小さいですが, 「はてなブログのPerl 5.28.1化」も思い出深い成果です.

developer.hatenastaff.com

日々の業務の合間にコツコツと5.28化の作業を進めて, 適宜リリースすることで「小さな成功体験」をコンスタントに得ていく進め方をしましたが, 今回はそれが「チームメイトをうまく巻き込む」動きに繋がって, チームメンバーの手厚いサポートの甲斐もあって, 最終的にはこちらもまた特段大きな問題なくリリースまでこぎつけました.

そのための手順書を作る中で意識したこと, 気づいた事をまとめてアドベントカレンダーに書いたところ, なんと人生初(多分)の700ブクマオーバーを達成しました!

papix.hatenablog.com

予想以上の反響があって驚いていましたが, 「気づいた事を, 正直に」書いた結果のが良かったのかも? と思っています. そこを参考にしたり, 他山の石にしてもらって, そのリアクションが700ブクマオーバーに繋がったのかなーと思っています.

「気づいた事を, 正直に」と言えば, 2018年はKichijoji.pmで2回, スクラムについての話をしました(詳しくは後述します). これもまた, チームで感じていた課題やそれに対して打った手, そしてそれが半年後にどうなったか... といった部分まで発表した結果, 懇親会でいろいろな方と議論したり, 意見をもらったりして, 非常に学びが多かったです. 今年の「YAPC::Tokyo 2019」では, その総集編的な発表をする予定ですので是非聞きに来てください(宣伝).

papix.hatenablog.com

...そういえば「YAPC::Okinawa」も2018年でしたね. 「Webサービスを監視するときに僕達が考えたこと」という発表をしましたが, ベストトーク賞の2位を頂けたのでした.

これもまた自分にとっては快挙と言える出来事で, 資料を作っている中で(会社のチーフエンジニア陣にレビューしてもらったりして)自分自身学びがあったし, それをしっかりと伝えることが出来た結果なのかなーと思っています. 嬉しかったですし自信が持てましたね.

こうやって振り返ってみると, 結構いろいろな領域で(?)コンスタントに成果を残せた1年だったなあ, と思いますね. 2019年も落ち着いて, コンスタントに成果出していきたいですね.

技術の幅を広げることができた

2017年は「手持ちの道具で戦いすぎた」というProblemを挙げていました. 一方で, 2018年は「道具を増やす」という観点で, 進歩のあった1年だと思います.

まずは前述の「はてなブログのHTTPS化」を通して, Go言語の理解はかなり深まりました. id:aereal さんが書かれた最高のお手本コードがあったというのも大きいですが, やっぱり業務を通して技術を習得するのが自分にとってはスピーディー出来るのかも, と改めて気づけた気がします. その時に学んだ事を活かして, Go言語でMackerelのプラグインを書いたり, サンプルコードをGoで書いたり, 継続してGo言語でコードを書く活動が出来ています.

papix.hatenablog.com

papix.hatenablog.com

papix.hatenablog.com

一番得意なPerlほど素早く/ミスなく書けるレベルには至っていませんが, 若干試行錯誤しつつも微速前進なスピードで, Go言語でモノが作れるようになってきました.

また, 業務の中でReact/ReduxやTypeScriptの理解もだいぶ深まってきました. こちらは id:masawada さんにペアプロしてもらって, はてなブログにおけるReact/ReduxやTypeScriptのお作法(?)を伝授してもらって, 若干の四苦八苦はしつつ機能の追加や改修が出来るようになってきました.

年末年始はChrome拡張を書いたりして, ReactやTypeScript, そしてJavaScriptの開発環境周り(npmやGulpなど...)をキャッチアップしようと試みています.

papix.hatenablog.com

また, スクラムマスターに挑戦したのも良い取り組みでしたし, スクラムの導入を通して, チームをうまく回して前進させるという"技術"を少しずつ得ていくことが出来ました. チームで感じていた課題感を打破するべく挑戦したスクラムマスターでしたが, 正直に言うとちゃんとした(?)教育を受けた経験はなくて, 前職でアジャイルマスターの下でアジャイルをやった経験と, 「アジャイルサムライ」, 「カイゼン・ジャーニー」, 「アジャイルな見積もりと計画づくり」辺りを読み込んだ知識, そして id:daiksy さんのアドバイスを頼りに試行錯誤しながらやっていきました.

軌道修正も多々ありましたが, とはいえタスクの可視化やフローの整備なども含めて, 少しずつですが課題に感じていた部分が解決され, チームとしてまとまって, 前に進めてきた実感があります. とはいえ, チームでの「振り返り」をうまく活かす部分など, まだまだ課題は尽きないので, 引き続き情報や知見のインプットをしつつ, 2019年も試行錯誤を続けていきたいと思っています.

...こうやって振り返ってみると, 2018年は「業務を通して技術の習得に挑戦する」機会がたくさんあって, それが自分にとっては適切だったのか, 割と高速に試行錯誤が出来て, 結果として知見が溜まって技術の幅を広げることが出来た(?)気がします. なので, 2019年もそういうチャンスがあれば積極的に取り組んでいきたいですね. とはいえ, そういう幸運な機会は度々ないと思うので, 業務外でもうまくキャッチアップする仕組みは考えていく必要がありますね...

P

「2018年で良くなかったところ, 2019年に改善していきたいところ」

去年の振り返りを活かせなかった

今回2018年の振り返りを書くにあたって, 2018年の冒頭に書いた2017年の振り返りを改めて読んでみたのですが... 「あ, あの時はこんなことを思ってたんだ...」というのが正直な感想で, それは要するに2017年の振り返りをうまく2018年に活かせていなかった... という事に他ならないなーと痛感しました.

今半期から, 期末の振り返りに向けて, 1〜1.5ヶ月に1回のペースで定期的な振り返りをするようになったので, 2019年はその中で「2018年の振り返り(= これ)」も見返すようにして, 初志を思い出したり, 軌道修正したりしていきたいですね.

秋〜冬にかけての体調が最悪だった

2017年の振り返りでも体調をProblemに挙げていたのですが, 2018年も秋から冬にかけて体調を崩してしまっていました. 特に10月末〜11月辺りは非常に厳しい時期が続いていて, 通院したり, 体調芳しくなく朝起きれなかったりで, 勤怠の状況も極めて厳しい状況に陥っていました. 12月になって若干持ち直してきましたが, とはいえまだまだ油断のならない状況と思っています.

2019年はいよいよ30歳になるので, 体調管理にはこれまで以上に気をつけたい所です...

あまりにも危機感を感じなくなった

2017年に引き続き, 2018年も体調は芳しくなかったものの精神衛生状態は1年通して平穏な状態が続きました. とはいえこれは裏を返せば, 精神衛生に影響が出るほど危機感を感じることがなくなった, と言えます. 個人的には, 程よい「危機感」は爆発的な成長の糧になると思っていて, そういう意味では2018年はいろいろと得るもの, 成長したことはあったけれど, とはいえ勢いはなかったと感じています.

とはいえ, これまで危機感を感じていた時は, 主に「自分と他人を比べる」時の, 劣等感とか不甲斐なさとかを噛みしめる中で感じる事が多くて, 結構これはコントロールが難しいし, そもそも最近は他人に対して感じた劣等感や不甲斐なさから自分を追い込むことがなくなってきたので, 2019年は他の, なるべくコントロール可能なやり方で, 程よく自分を追い込んで, 危機感を煽ってみたい(?)と思っています.

...その辺り踏まえて, 2019年のTryとして, 「もっとチャレンジする」を掲げようと思っています.

T

「2019年, 改めてチャレンジしていきたいところ」

もっとチャレンジする

前述した通り, 今年でいよいよ30歳になります. 前職時代に中途採用に関わる機会があって, その時に思ったのは「20代のうちはある程度ポテンシャルを見込んで評価してくれるが, 30代は実力でしか評価されない」というのが大なり小なりあると思っていて, それを踏まえて今の自分を見つめると, まだまだ実力不足でしかないですね. なので, 2019年はもっとたくさん経験を積んで, 実力の糧にしていかないといけないと思っています.

そのために, チャレンジして自分を追い込むのも必要だと思っていて, 30歳になるといういい節目もあるので, 例えば「ロールを変える」という挑戦をしてみるのもアリかも, と考えたりしています. 例えばエンジニア兼任ディレクターのようなポジションをやってみたり, 或いはSREとしてインフラ周りの仕組みを再整備したり... 引き続き「教育」的な部分にも関心があるので, そういった挑戦もしてみたいという気持ちもあります. とはいえアレもやりたい, コレもやりたい! だと大抵中途半端な結果に終わるので, しっかり上長やメンター, 関係する人たちと相談して, いい感じの(負担になりすぎない)チャレンジをしていきたいです.

海外に行く

去年も書いていたのだけれど, 去年は結局海外のカンファレンスに行く機会がなかったですね. 2019年は, ひとまずThe Perl Conference in Riga(TPCiR)に行くぞ! という気持ちを高めています. はてなブログの開発の様子を通じて, 日本におけるPerlを使ったWeb開発事情の現状をお話する, みたいなトークをしたいと思っています. これもまたチャレンジの一環ですね.

そうなると, 引き続き壊滅的な英語についても何とかしないといけない気がしますが, とはいえ体調管理のことなどを考えると, 英語しっかり勉強するぞ! と心に決めても途中で挫折するのは容易に想像が出来るので, まずはヒアリングを突破口にするのはどうか? とか考えたりしています. 英語で会話していて困るのが「何を言っているかわからない...」というところで, そこが改善できれば聞き取れた単語から会話の内容を想像したり... 出来るのではないか...?

後はライブの日程とTPCiRの日程が重ならないことを祈るのみですね. 重なったら... いろいろ検討します...

まとめ

こうやって振り返ってみると, 2018年は割といろいろ成果残しつつ学びも多い, よい1年でした. これも日々お世話になった皆様のお陰だと思っています. 本当にありがとうございました.

一方で, 引き続き体調面など不安はたくさんで, 2019年はその改善をしながら, いろいろなチャレンジを通して経験を積んで, 実力というか, エンジニアとしての戦闘力を高めていける1年にしたいと思っています. 至らぬ点もまだまだ多いですが, 2019年も引き続き, ご指導ご鞭撻の程よろしくお願いいたします!

今開いているタブのURLをクリップボードにコピー出来る「chrome-copy-url」を書いた

年末年始, ちょっとはJavaScriptを書いて慣れを深めよう, という気持ちの元, 簡単なChrome拡張を書いてみることにしました.

github.com

出来ることは, このエントリのタイトルに書いた通り, 「Chromeで今開いているタブのURLをクリップボードにコピー出来る」, のみです. この拡張を導入すると, 次の画像のようにcみたいなボタンが出てくるので(多少はかっこよくしたい...), それを押すとクリップボードへのコピーが実行されます.

f:id:papix:20181230034447p:plain

調べていないけれど, 多分同じような事が出来るChrome拡張はたくさんありそうで, そういう意味ではJavaScript練習のための車輪の再発明をしている, という感じですね.

今後の展望

クリップボードに格納する前にフィルターをかける機能を実装してみようと思っています. 例えば...

  • URLエンコードされたURLをコピーしたら文字列を復元されてクリップボードにコピーされる
  • 予め指定した, 不必要なクエリパラメータを削除出来る機能

...とかあったら便利かも? と思ったので, そういった機能を実装しつつ, JavaScriptの練習をしていこうと思っています.

雑なチェックプラグインを書いた話

こんにちは, id:papix です. この記事は, 「Mackerel Advent Calendar 2018」の16日目の記事です.

qiita.com

昨日は, id:albacore さんの「学生サークルでMackerelを運用してみた話」でした. 闇に飲まれよ! (お疲れ様です!)

albacore.hateblo.jp

雑なチェックプラグインを書いた話

さて, 担当の日が来たにも関わらず, 良いネタがなかったので, 最近書いた雑なチェックプラグインの話をします.

自分は自宅にEdgeRouter Xを置いていて, 更に契約した回線がグローバルIP付きだったので, EdgeRouter XでVPNを使えるようにしたり, いろいろ遊んでいました. その時に書いた記事がこの辺りの記事です:

papix.hatenablog.com

先日, 外出中に自宅にあるEdgeRouter XへVPN接続をしようとしたところ, どうも繋がりませんでした. 「アレ?」と思って, VPN接続のために設定していたIPと, Mackerelに登録されているEdgeRouter XのグローバルIPを確認すると... なんと違うIPアドレスになっていました.

...ハイ, 要するに「グローバルIPは割り当てるが, それは固定ではない」というオチでした. 確かに契約している回線の公式サイトとかを見に行くとそのように書いてあって, 要するに自宅にある通信会社から貸与された機器(終端装置みたいなもの?)の電源が落ちたり, メンテナンスがある度に, 使えるグローバルIPが割り当てられる... という仕組みになっているようです.

check-gip

せめて, グローバルIPが変わった時に気づけるようになりたい. ...ということでMackerelで使えるチェックプラグインを作ってみました. 2時間くらいで雑に作ったので, 名前も「check-gip」という, なんかよくわからん感じの名前になっています.

github.com

これまで何度か, Mackerelのプラグインを作ったことはありましたが, 多分チェックプラグインを作るのは初めてです. とはいえ, Mackerelの場合は公式で提供しているチェックプラグイン集があり, それをお手本として作れば, そこまで苦労することはありませんでした.

github.com

使い方

今の自宅では, 通信会社から貸与された機器からLANケーブルがEdge Router Xのeth0に繋がっていて, ここにグローバルIPが割り当てられています. なので, グローバルIPを適当なドメインと紐づけて, その名前解決の結果と, Edge Router Xのeth0に割り当てられたグローバルIPアドレスを比較するプラグインを作ることにしました.

名前解決はnet.LookupHostで, インターフェイスからIPアドレスを取得する部分はGoのnetパッケージを使って強引に実装しました. 例えば, myhome.example.comにグローバルIPが設定されていて, それとチェックプラグインが動いてるサーバのeth0に割り当てられたIPアドレスをチェックするなら, このように設定します:

[plugin.checks.check_gip]
command = "check-gip --host myhome.example.com -i eth0"

これで, 例えばeth0に割り当てられたIPアドレスが変わってしまったりしたら, Mackerel上でアラートが出るようになります.

さいごに

最近書いた雑なプラグインの話をしました. ...ここまで書いていて, これよりも, 「指定したインターフェイスに割り当てられたIPアドレスと, 引数で渡したIPアドレスをチェックする」みたいな実装にして, check-interface-addressみたいな感じで提供した方が汎用性ありそう, と思いました. そういう感じで書き換えることも検討したいです.

...言いたかった事としては, Mackerelはチェックプラグインも割と簡単に作れるので, このような「俺得チェックプラグイン」をサクッと作って(今回はGoで書きましたが, 別にPerlでもRubyでもシェルスクリプトでも何でも作れます!)使えると便利! っていう感じです. 皆さんも是非俺得チェックプラグインを作ってみましょう!!!

明日は...

明日の担当は miwarin さんです. お楽しみに!