tchikuba's blog

クリエイティブが輝ける組織をエンジニアリングする

【書籍レビュー】「独習Python」を献本頂きました

技術書執筆者コミュニティのWINGSプロジェクト代表・山田祥寛さん著「独習Python」を献本頂いたのでレビューします。

なおこの記事の前提ですが、私はこれまで業務でPythonをゴリゴリ書いた経験は乏しく、読んだりデバッグ&修正のような感じの経験が多かったので、そもそもあまりPythonの言語仕様について詳しくありません。

今回の書籍レビューを通して、Pythonに関して体系的に知識を整理する良い機会となりました。

イントロダクションが充実している

山田さんの書籍全般に通じることですが、プログラミングが初めての方でもちゃんと歴史的な背景を学ぶことができるよう、丁寧にイントロダクションが記述されている印象でした。

プログラミングが全く初めての方でも、独学が得意な方であれば、これ1冊でPythonやプログラミングの基本的な概念を理解することができると思います。

細かい知識や用語の引き出しを持てる

私のように体系的にPythonを理解できていない方にとっては、特にPython特有の記法や概念をおさえることができて良かったです。

参考までに私がちゃんと理解していなかったものを列挙しておきます(Python特有のものではないものも含まれています)。

  • ジャグ配列
  • 切り捨て除算演算子の//
  • 各種内包表記
  • デコレーター
  • クロージャー
  • 関数のモジュール化
  • コルーチン

クラスの取り扱いはちょっと薄いような気がする

基本的にはPythonを学ぶ上で最初の書籍であることを想定しているからだと思いますが、オブジェクト指向の解説はちょっと駆け足かなと思いました。

Pythonでオブジェクト指向を本格的に学ぼうとする場合、決定本ってなんだろう?と思って軽くググってみましたが簡単には判別つかず😓

もしかしたら「オブジェクト指向設計実践ガイド」とかのが良いのかも?(Rubyだけどw)

番外編

多重継承

この書籍でも触れられていますが、 Pythonは多重継承を許容しています。

多重継承を許容しているプログラミング言語、他にはC++が有名ですが、その他って何があるんだろう?ってふと疑問に思いました。

言語仕様として多重継承はマイナーで、私がこれまで経験してきたプログラミング言語(主にC/PHP/JavaScript/Ruby)は許容していないこともあり、ちょっと気持ち悪いと感じてしまいますね😅

妻と恐竜

「妻クラスが恐竜(クラス)」ってなんか凄いものを見てしまった感じがしました😭

レビューは以上です。

私のように、その他のプログラミング言語の経験がある人が、体系的にPythonを学び直すのにもちょうど良さそうな1冊かと思いました。

気になる方はぜひ手にとってみてください😃

「クリエイティブが輝ける組織をエンジニアリングする」ポッドキャストCEO.FMを始めました

2020年1月24日から、一念発起して「CEO.FM」というポッドキャストを始めています。 2/9現在、エピソード#17まで配信済です。 365日、毎日配信を目標に、今のところ継続中😁

CEO.FMの配信テーマ

タイトルにもある通り、CEO.FMは「クリエイティブが輝ける組織をエンジニアリングする」番組です。 番組名の「CEO」は、いわゆる最高経営責任者の意味ではなく、以下の頭文字の略称です。

  • Creative(クリエイティブ)
  • Engineering(エンジニアリング)
  • Organization(組織)

私は、リブセンスでエンジニアリング・マネージャー(EM)、副業で技術顧問を複数社経験しています。

その中で、エンジニアをはじめとするクリエイティブ職種が力を発揮できる環境(組織)には、一定再現性があるのでは?という仮説(というかどちらかというと確証に近いもの)が湧いていました。

書籍「ティール組織」との出会い

様々な現場で奮闘しながら出会ったのが、ティール組織という書籍。

衝撃。私がこれまでの経験から感じていた課題感や前述の仮説と見事に一致していたからです。

4年ちょっと前のリブセンス・アドベントカレンダーで書いたブロク記事「21世紀型のクリエイティブな働き方・思考・組織の新しいあたりまえ」でも、自律的に働くこと/ホラクラシーについて言及していたり、昨年(2019年)5月に行われたGotanda.EM #2でのLTでは、従来の管理型ではない新しいマネジメントに注目していることに言及しています。




私にとって、ティール組織の在り方は、「クリエイティブが力を発揮できる組織には再現性があるのでは?」という問いへの、1つの答えでした。



ティール組織の実践者であれ

私はティール組織の実践者でありたいと強く願っています。

組織論について空理空論を振りかざして実践例や具体例に乏しい状態は、私にとって好ましくない。 現実の世界で、クリエイティブがよりクリエイティブらしさを保障される仕組みづくりに貢献していきたい。

そういう想いで、まずはCEO.FMを始めてみました。

CEO.FM企画案をテキスト化

ところで、リブセンスVP of Engineeringの@notoと以下のやり取りしてました。

ツイートの通り、私も動画/音声コンテンツはあまり見聞きする方じゃないんですよね。テキストの方が、思索しながら熟読したりなど、自分自身で情報のインプットのスピードをコントロールしやすくて。

そこで私や@notoのような方のために😁、CEO.FMエピソード#10までの企画案を公開しておきます。配信前にざっとメモしている内容なので、実際は話が発展しているエピソードがあったかも。

まぁ配信の雰囲気は感じて頂けるかなと思います。 もし興味関心が湧いた方がいましたら、ぜひ聴いてみてください!

#1 CEO.FMに込めた思いなど

  • 配信詳細
    • クリエイティブが活躍しやすい組織をエンジニアリングする、というテーマ
    • 要はティール組織なんだけど、自分のエンジニアとしての体験を踏まえた内容にしていきたい
    • テーマはこれまでtwitterでつぶやいたものやブログで記事化した内容を元にインスパイアされたものにしていく
    • 隙間時間の有効活用のために、できるだけ細かい時間配分を意識したい
      • 5-10mくらいが理想
    • 当初は1人で開始、回が進むにつれてできればゲストを呼びたい
      • 1人だと話が膨らむか不安
      • 対話の中でやった方が盛り上がるのでは

#2 配信スタイルと自己紹介

  • アイスブレイク
    • 5-10mと短い配信なのでできるだけ継続する
    • できれば毎日配信にチャレンジする
    • 365日配信にチャレンジ
    • まずは10日の継続配信を目標に
    • テーマを絞って配信
  • 配信テーマ
    • 自己紹介
  • 配信詳細
    • 現在何やってるか
      • リブセンスでIESHILというプロダクトのEM
      • Ruby on Railsの受託開発会社の技術顧問
      • kiitokでエンジニアメンター
      • 執筆関連(書籍紹介)
      • 一時期副業手広くやりすぎたので整理
      • 個人開発プロダクト2つほど
      • クリエイティブ関連で書道教室に通い始めた
    • これまでのキャリア
      • エンジニア16年くらい
      • 理系、大学では地震の研究「地球潮汐力の地震トリガーについて」
      • 新卒は起業を志してベンチャー・リンクというバリバリの営業会社へ
      • 1年足らずで退職後、小学校の教員になる勉強
      • その後友人に誘われて起業しようとして失敗
      • 反省を生かして2004年にエンジニアに
        • 社畜フリーランス
      • いわゆるSESで7年客先常駐
      • 4年富士通、3年CCC
      • 2011年前職で新規事業のEMとしてPRベンチャーへ
      • 2013年リブセンス入社
        • 1年転職会議
        • 1年転職ナビ
        • 5年IESHIL

#3 ネガティブな原体験

  • 配信テーマ
    • ネガティブな原体験
  • 配信詳細
    • ベンチャー・リンク時代の話
    • 世の中がどういう力学で動くのか興味感心があった
    • 自然と起業を目指すように
    • 当時「企業家排出機関」と謳っていたベンチャー・リンクへ
    • 原体験
      • 睡眠時間4時間取るならやりたいことを1時間やって睡眠時間を3時間に削るべき
      • 遅刻が原因で辞表を2回書かされた
      • 「未達は死」フォントサイズ84・赤文字でメーリングリストに送られる
      • イベントで私語してたら帰れと怒鳴られた
        • どうしてそんな言い方するんですか?
        • お前の給料誰が払ってんだ
      • 営業行ってきますと出たあと
        • カラオケ屋に行って仮眠
        • 自宅に戻ってペーパークラフト
    • 合理性に欠けるポイント
      • 人によって適切な睡眠時間は異なる
      • 一般的には7-9時間
      • 私自身、平均睡眠時間が8時間になるよう心がけている
      • 睡眠時間が削られるとネガティブ思考に陥りがち
      • 時間の使い方は本来個人のもの
        • 時間を守ることを否定してはいない
      • 育つのに一定の時間がかかる新卒に給料泥棒と言っても仕方がない
        • だったら新卒を採用すべきでない
    • 問題の本質
      • 極端なゴール思考は思い通りに行かなかった時の感情の揺れ幅が大きすぎて手に負えなくなる
      • 複雑性の高い課題を解決するにはシステム思考で課題設定する必要がありそう
      • 課題設定そのものが進化していく仮説検証的な姿勢が必要なのでは

#4 相手を人として見なくなった時に不幸が始まる

  • アイスブレイク
    • 配信の回を追うごとにご褒美
    • エンジニアの嫁ちゃんの話
    • 逆嫁ブロック
  • 配信テーマ
  • 配信詳細
    • ティール組織研究会について
    • そもそもティール組織とは何か
    • 虐待が起きるのは相手を人と見ていない時
    • 「人を機能としてみなす」ことはないか内省する

#5 新規事業に最適な組織運営

  • アイスブレイク
    • 「ザ・メンタルモデル」著者「由佐美加子さん」のTED動画
      • 約2年前に公開されたもの
    • 世界に自分がないと思っているものは実は自分の中にある
    • 自分の中にあるものを世の中に出して問うことの大切さを訴えている
    • 「世界を変える」大言壮語より身近な周囲の5人と共に幸せの方向に向かうこと
    • 私:お金がないと思っていたけど既にある、という発想になる
      • 一見、非現実的だけど実は凄く前向きな発想では
  • 配信テーマ
    • 新規事業に最適な組織
  • 配信詳細
    • 新規事業はいわゆるゼロイチを生み出すもの
    • 前職のPRベンチャーでの体験
      • エンジニアリングマネージャーとして従事
      • Facebookコマース/ソーシャルギフトサービス
      • 外注していたシステム開発を内製にシフト
      • エンジニアリング組織作り
      • ウォーターフォール的な予めしっかり設計する文化からの脱却
      • アジャイルやリーンスタートアップのプロセス導入を試行錯誤
    • 気づき
      • 半年後の目標を決めるMBO(目標管理制度)ではビジネスのスピード感に合わない
      • 新規事業はクリエイティブの1つの形
      • そもそもクリエイティブな仕事には従来型の目標管理のやり方は向いていないのでは?と考えるようになった
      • 組織の運営自体をアジャイルやリーンなやり方に合わせることが大切
        • 「俊敏」
        • 「贅肉がない引き締まった」
      • 一方で目標を設定すること自体に価値がないとは思わない
      • 「信頼駆動開発」
      • アドラー心理学「コントロールできること」「できないことを立て分ける」

#6 新規事業の在り方の変化

  • アイスブレイク
    • フィボナッチ数の回でお祝いと言ってたのに前回忘れてた
    • フィボナッチ数の説明
  • 配信テーマ
    • 新規事業の在り方の多様性
  • 配信詳細

#7 クリエイティブな仕事とは?Part1

  • アイスブレイク
    • FBで繋がってる姉がCEOFM聞いてるとFBに書いてた
    • ハッとした→できるだけわかりやすく配信するよう心がけたい
  • 配信テーマ
    • クリエイティブな仕事とは
  • 配信詳細
    • 典型的な仕事
      • 芸術家(音楽家、バンドマン、俳優、作家など)
      • スポーツマン
      • プログラマ(ハッカーと画家・ポール・グレアム)
      • デザイナ、ハスラー(企画職)などのIT従事者
    • アンチパターンを考えてみる
      • 人を歯車のように見て制御(コントロール)しようとする
      • 機械で置き換えられる定型的な仕事(創意工夫の余地がない)
    • 原体験
      • とある技術顧問先で現場の状況を踏まえず政治的にスケジュールが決定される
    • 結論
      • 個人:少なくとも裁量が専門性の範囲で権限移譲されている状態
      • 全体性:現場のメンバーに寄り添って現場がクリエイティブを取り戻すような働きかけをする

#8 クリエイティブな仕事とは?Part2

  • アイスブレイク
    • フィボナッチ数8おめでとう
    • 次回は13回目の配信
  • 配信テーマ
    • クリエイティブな仕事とは②
  • 配信詳細
    • 前回はクリエイティブな仕事を「専門性の範囲で裁量が保障されていること」と定義した
    • 今回は「専門性の定義」について
      • 特定の分野についてのみ深く関わっているさま。高度な知識や経験を要求されること、またはその度合い。
    • 原体験(興味関心事の変遷)
      • 大学生時代「教育」「新規事業」「経営」
      • エンジニア「エンジニアリング」「プロダクト」「組織」
      • 以前は「IT」「新規事業」「教育」
      • 現在は「組織」「クリエイティブ」「エンジニアリング」
    • 結論
      • 専門性の定義は従事する個人に委ねられていて、可変なもの
      • 組織(他の誰か)がオーソライズするものではない
      • 多様性が増す時代にあって、誰一人として同じキャリアを歩む人はいない=その意味で専門性のない人もいないと言えるのでは?

#9 コンウェイの法則の本質

  • アイスブレイク
    • オブジェクトから想像力を働かせること
  • 配信テーマ
    • エンジニアリング
      • コンウェイの法則
  • 配信詳細
    • システム設計は、組織構造を反映したものになる
      • 人の織りなす世界がプログラムに反映されること
    • 原体験
      • 無理なスケジュール、要件変更が頻繁、外注との棲み分け
      • プログラムの複雑性が増して手がつけられない状態に
      • 時間をかけてテストコードで保護しリファクタリング(組織も)
    • 人と法則(システム)は表裏一体=コンウェイの法則の本質(逆の矢印もあるのでは)
      • 法則は人が発見(開発)している
        • ニュートン/ファラデー/ケプラー
      • 人は法則(システム)からは逃れられない
    • エンジニア的な目線(主にボトムアップ)から組織改善へのアプローチの可能性を模索するのがエンジニアリングマネージャーの仕事ではないか

#10 クリエイティブな組織における適切な評価

  • アイスブレイク
    • 初回で365日毎日配信、まずは10回を目指したいと宣言して無事に継続
    • モチベーションは今の所大丈夫、むしろ+
    • ご褒美はマイク
  • 配信テーマ
    • クリエイティブな組織における適切な評価
  • 配信詳細
    • 原体験
      • 前職でやっていた360°フィードバック
      • KPT(Keep/Problem/Try)を1人1人言い合う
      • なんとも言えない感情(悪くない)
      • リブセンスでは359°でオンライン(イケてない)
    • 古い目標管理制度だと一方通行
    • より双方向の評価経済であるべき
    • 信頼関係を築くことがまず前提

最後に

ちなみに10回目の配信でご褒美としてAmazonでポチったマイクはこちら。

12回目の配信からこのマイク使って収録始めました🎤

ちなみにCEO.FMのハッシュタグは#ceofmです。 感想/ご意見などあればTwitterアカウント@tchikubaまでぜひ!

内容について共感頂き、かつ応援したいと思われた奇特なそこのあなた。

ぜひこちらのpaypalから善意の投げ銭をw

エンジニア目線でルンバi7+激オススメ!ファクトフルネスを拡張して言うと「レベル5」の生活を手に入れることができるよ

ルンバi7+を購入したら生活の質が向上したよ

久しぶりのブログ更新はいつもとは全く違う毛色でお届けします。

プライベートなことなんですが、比較的最近、中古マンションを買って引っ越しました。

フルリノベーションされたマンションなので、当然バリアフリーで段差がなく。

子供いない夫婦2人でちょっと広めの1LDK。共働きで比較的公私共に忙しい2人なので家事の分担はこれまでの賃貸住まいでもちょっとした問題でした。

ちなみに私は、家事を自分たちでしなくても今どき都内なら家事代行サービスたくさんあるのでそれで手を打ちたかったんですが、嫁はプライベートな空間に第三者が入るのに抵抗がありました。

賃貸時も1LDKでしたがちょっと広くなったのでひとまず掃除が面倒だなぁと思っていたので、ルンバi7+を購入したら思いの外、快適で費用対効果抜群だったのでルンバちゃんを褒め称える記事ですw

ルンバi7+をAmazonでポチった(ポチることができた)

なんとなく値が張る家電って、できるだけ店頭で見て買いたいみたいな思いがあったんですが、エンジニア目線で見て妙にブランディングがしっかりしているiRobot社とかダイソン社とかはAmazonでポチっても問題ないよね感あり、Amazonでポチりました。

Amazonでルンバi7+をポチった

マーケティングなのかもですが、こういうマーケティング/ブランディングって海外のプロダクトのがちゃんと立ち位置築いている感じがする。

これが日本製のロボット掃除機買おうとすると「違いがよくわからん」ってなって、まず下調べするところから始まって面倒な時間が取られちゃうんですよね。

実際、ルンバのあと、縦置きの洗濯乾燥機も古くなってたのでSHARPのドラム式洗濯乾燥機(ES-W111)を買ったんですが、これは家電量販店のノジマに店頭で色々聞いて買いました。

その前にメーカーによる製品の違いを理解するために、ググる時間で2時間とか取られたので時間の使い方もったいない。そんな暇じゃないのだよ、こちとら。

という訳でなにが言いたかったかというと、iRobot社のルンバくらいブランディングの立ち位置があるとその辺の時間削減されてユーザー的にも幸せが訪れるということ。

ルンバi7+の何が良いのか

とはいえルンバも色々と種類があってピンきりなので調べたところ、i7+が最上位モデルで以下あたりが特徴でした(認識違ってたらツッコミください)。

  • ルンバが集めたゴミを一時的に集めておくクリーンベース付きのモデルがある
  • ルンバ本体のダストボックスが水洗いできる(それまでのモデルは水洗いできないみたい)
  • wifiで繋いでAlexaとも連携できる
  • 複数の部屋をちゃんと記憶できる(スマートマッピング機能)

個人的には特に最初のクリーンベースが気に入ったので迷わず最上位モデルのi7+の購入を意思決定しました。クリーンベースがないモデルだと、基本的に毎回本体のダストボックスを掃除してあげる必要があるみたいです。クリーンベースがあれば、30回分はそこに溜められるので1日1回の作業(本体の掃除)が1ヶ月に1回で済むので時間の節約になります。

実際に2ヶ月くらい毎日使ってみて、実はまだ一度もクリーンベースの交換用紙パックは交換していません。中を確認してもまだいっぱいになってないからですが、共働きなので一般的な家庭よりは自宅にいないからその分ホコリとかは少ないのかもですね。

1ヶ月ちょっと経って一度だけルンバ本体の掃除はしました。それほど必要なかったような気もしますが、一度メンテナンス手順を確認しておく意味でやりました。クリーンベースの紙パック交換もルンバ本体の掃除も、3ヶ月に1度くらいの頻度で良さそうかなという印象です。

要はメンテナンスにもほとんど手間暇かかりません。

ルンバi7+のアプリ

アプリもよくできてると思います。気になる点は、起動後にルンバに接続するまで少し時間がかかるというのと、ルンバが汚れを検出した時に重点的に掃除する「ダートイベント」の「詳細を確認する」のリンク先がオンラインヘルプになっているんだけど、ずっと「ご利用できません」ってなってることくらいかな(関係者の方なんとかしてくだせぃ)。

ダートイベント

一部スクリーンショットを紹介します。

まずアプリトップ。

アプリトップ

中心にあるでかい「CLEAN」って丸いところをタップすると、アプリから手動でも掃除を開始できます。厳密にはタップした後に全部屋か部屋を指定するか選べます。

続いて「お手入れ」をタップした画面。

お手入れ

これはルンバ本体のメンテナンスが必要かどうかを表示するところ。このステータスは自動というわけにいかないので自分で選択してそれぞれのステータスを管理する必要があるっぽい。

ちなみにそれぞれを選ぶと「ステータスのリセット」が選択できるんだけどこれがやたらと時間かかっていたのも気になった点かも。

ステータスのリセット

続いてトップから「履歴」をタップした画面。

履歴一覧

これはスクショの通り直近30件の掃除の一覧ですね。ここからそれぞれの履歴の行をタップすると以下のように掃除についての詳細が見れます。

清掃の詳細

初期は「清掃が完了し、ダスト容器が空になりました!」のところは閉じている状態です。スクショはそれをタップして開いたところ。

この通りうちの1LDKだとだいたい40分ちょっとかかります。

続いてトップから「スケジュール」をタップした画面。

スケジュール

こんな感じで清掃のスケジューリングを予め登録しておけば、その時間になれば自動で起動して掃除してくれます。エンジニア的に言えば要はcronジョブですね。意味が分からない人はスルーしてください。

続いてトップから「スマートマップ」をタップした画面。

スマートマップ

これ凄いなーと思ったのが、最初何度か掃除を繰り返すと自動で部屋の区分を提案してきてくれて、足りないところは自分で部屋の境界線を指定して部屋を定義できるところ。日々の掃除自体も部屋の形状を記憶して人工知能的な掃除効率化がなされているっぽい(日常的な掃除の動きを見ているとようわからんですが)。

ちなみにAlexaに個別の部屋を掃除するよう指示できるんですが、この部屋の名称を指定しないといけないので、「リビングルーム」と登録してるのに「居間」と言っても認識してくれませんので悪しからず。

リビングルームってアプリがサジェストしてくれた名前を指定したんだけど居間のがAlexa経由で使う場合は短いから便利かもしれない。まぁ「Alexaで」「個別の部屋を」掃除する利用シーンがそれほど発生しないんだけど。

こんな感じで、細部はツッコミどころありましたけど、アプリもなかなかによくできている印象です。

ルンバi7+のコスパ最強(投資回収が早い)

ここが一番言いたかったことです。

クリーンベース付きのモデルならメンテナンスコストはそれほど高くないので無視できるレベル。

自分で掃除機かけるよりちょっと時間かかる印象ではありますが、ソファなど家具の下に入り込んでまでちゃんと掃除してくれるので自力でやるより行き届く部分もあります。

仮に自分で掃除するのが半分の20分と仮定すると、我が家にルンバがやってきて2ヶ月なので、

1/3時間(20分)×2ヶ月(60日)×時給単価(m)=20m

という数式が成り立ちます。

本体価格が凡そ14万なので、

20m≧140,000

という不等式を解くと

時給単価m≧7,000円

が導けます(数学が日常生活で役に立った瞬間)。

つまり、自分の時給単価が7,000円以上あると思えるなら たった2ヶ月で初期投資回収できちゃう ということです。

時給単価そんなに高く思えなくても、例えば家事代行サービスの時給単価が東京だと2,000-2,500円なので約1/3と仮定しても、 6ヶ月、つまり半年で初期投資回収できます。

あとそもそもお金に換算しなくても、毎日20分「自分で掃除機かける」というタスクがなくなるので、 1ヶ月あたり10時間、時間をあけられるというのはプライスレスですよね。

ちなみに私はエンジニアなので、ある程度自宅でリモートワークする機会もあるんですが、ルンバのおかげで自宅の快適さが増してよりリモートワークしやすくなったのもプライスレスでした。

時間に追われるそこの奥さん!でもご主人でもなんでも良いんですけど、マジおすすめです。当然バリアフリー物件じゃないと導入しづらいってのはありますが。

FACTFULNESS(ファクトフルネス)とルンバi7+

話はちょっと変わるんですが、ルンバで生活改善みたいな流れって、以前読んだファクトフルネスって書籍を思い出すんですよね。

ファクトフルネスについての詳細は割愛します。簡単に言えば「世の中を事実としてちゃんと正しく認識しようね。それから、世界はよりよい方向に発展しているから無駄にネガティブにならないように気をつけよう」みたいな内容の素晴らしい書籍です。正しい国際感覚を身に着けたい人には必読の書。

この書籍に、世界の人々の暮らしは、1日換算の生活費によってレベル1から4までの四段階に分類できるということが書かれています。

例えば歯ブラシなら以下みたいな感じです。

  • レベル1:指で磨く
  • レベル2:歯ブラシ(家族で1本)
  • レベル3:歯ブラシ(1人1本)
  • レベル4:電動歯ブラシ

掃除に関して言えば、ルンバが起こしたイノベーションって最早レベル4を超えてレベル5なんじゃないかと思うんですよね。

ITの急速な発達により、「これまで人間がやるとされていた仕事が自動化されて仕事がなくなる」ってイノベーションがもろ実現している。

こういうプロダクトって純粋に凄いなーって思います。

そういうイノベーティブな仕事に携わっていたい。

ちなみに余談ですが私の残りの人生をかけての使命は 「クリエイターを世の中に増やすこと」 につい最近決まりました。

そもそもこういう「イノベーティブな仕事ができる人」をもっと増やしていくことに、今後の人生の時間を使っていこうと決意しています。

イベント「~エンジニア×先生×NPOで語る、これが本当のプログラミング教育~みんなのコードmeetup」に参加してきました

2018/09/27(木)に行われたイベント「~エンジニア×先生×NPOで語る、これが本当のプログラミング教育~みんなのコードmeetup」にブログ投稿枠で参加してきました!

私はプログラミング教育には関心が高いのですが、どちらかというと現状は社会人向けの方にコミットしています。

TechAcademy [テックアカデミー]という社会人向けのプログラミングスクールでwebアプリケーションコース(Ruby on Rails)の講師(メンター)をやっていたりします。

が、過去、小学校の教員免許状も取得したこともあり、学校教育におけるプログラミング教育にも将来的には関わっていきたいなと思っています。

NPO法人のみんなのコードは、本業のリブセンスでのご縁もあり、以前から知っていましたが、今回のイベントに知人のFacebookエンジニアである安藤さんもパネラーとして参加されるというので、同日行われていたMeguro.rbの参加を見送って、このイベントに参加することにしました。

小学校プログラミング教育最前線のお話 by NPO法人みんなのコード代表 利根川 裕太

最初にアイスブレイクで2人1組になってトランプ5枚のカードを大きい順に並べ替えるゲームで和みました。 ソートアルゴリズムを特にIT機器を通さずに体験するゲームということで、広く言えばこういうものも、プログラミング教育の一環とも言えるのではないかと思いました。

その後、利根川さんからみんなのコードが目指す世界についてアナウンスがありました。 一応紹介しておくと、NPO法人みんなのコードは、プログラミングを教える人を教える活動を行っています。 つまり、教員の方を中心にプログラミング教育の教え方を教えるような感じです。

ご高齢ながらプログラミングを独学で習得して一躍有名人となった若宮正子さんなどのストーリーを通して、コンピュータを用いて何らかの課題解決をしている事例を紹介されていたのが印象的でした。

私が話を聞きながら疑問に感じたポイントは、プログラミング教育以前に、学校のような比較的伝統ある古い組織において、ITを導入することでより効率的に物事を進めたり、人とつながったりなど、ITの恩恵を受ける体験に実は乏しく、ITが持つ力の大きさみたいなものを教員が実感する必要があるのでは?ということでした。

そのような趣旨で質問してみたところ、プログラミング教育がきっかけになって、学校側のITリテラシーがあがる、という事例も実際に出てきているそうです。

エンジニア×先生×NPOのパネルディスカッション

後半からは、以下のパネラーの方々の簡単な自己紹介の後、プログラミング教育に関するパネルディスカッションが行われました。

パネラーの方々

  • エンジニア:FacebookエンジニアのAndo氏
    • 中学校の社会の教員採用試験も受けた経験あり。
    • デジタルハリウッドでの講師経験あり。
  • 先生:千葉大学教育学部附属小学校 教諭/ICT活用教育部 主任 小池 翔太氏
    • 5年目の小学校教員。
    • IBM×国立天文台「位置天文学×エンジニア」などのプログラミング教育事例の紹介。
  • NPO法人みんなのコードCTO:田中高明氏
    • 元世界史の教師からエンジニアに転向。
  • NPO法人みんなのコード主任講師:福田晴一氏
    • 和田中学校藤原さん(民間出身の元校長先生)と一緒にやっていた元先生。
    • 余談ですが私は藤原さんが提唱されているトライセクター・リーダーって考え方に共感してます。簡単にいえば、3つの全く違うそれぞれの分野で100人に1人の人材になり、それを3つ掛け合わせると100万人に1人の人材になれる、というキャリアみたいな感じ。

パネルディスカッション詳細

詳細と見出しには書きましたけど、ここからは議論が面白くて前のめりに聞くのが中心だったのであまり網羅的にメモできていませんが、個人的に印象に残った議論とその所感を中心に書き起こしておきます。

実際の教育現場がどうなのか?by福田氏

福田さんは元先生で、現在はみんなのコードで全国を飛び回って、先生のためのプログラミング教育について研修をされているそうです。いわゆる「プログラミング指導教員養成塾」的なものをされています。

福田さん曰く、全国を回った所感として、「3つの格差」について話をされていたのが印象的でした。

  • 自治体の格差
  • インフラの格差
  • 教員の格差

教育に関して、地方は東京から3年くらい遅れて広まっていくところがあり、「公教育の犯罪」とまで言及されていました。

以前からも流行り廃りみたいなものは、東京から広まっていくのはあったと思いますけど、単なる流行はSNSなどインターネットが普及する昨今では、地方に広まっていくのもかなりのスピード感あるなぁという印象があります。恐らく、インターネットの恩恵を享受しにくいサービスみたいなものは、やはり東京一極集中というのはある気がします。

学校の先生方にプログラミング教育の必要性を訴えるには、求められる背景の理論武装が必要だけど、一度理解してもらえればちゃんと堅実に推進してくれるという話は印象的でしたね。私もその昔、小学校に教育実習に行ったことがありますが、確かに教育の現場って理屈っぽい先生方多かった印象ありますね。理屈っぽいという意味では、エンジニアも同類項ですがw

学級経営にも生きるプログラミング教育by小池氏

プログラミングで求められる自発性みたいなものがあり、たとえば、アイルランドから始まったCoderDojoでは、あまりトップダウン的なアプローチで何かを強制的にさせることは行いません。あくまでも子どもたちの自主性にまかせてやることを決めるので、一人ひとりの個性が大切にされます。

同じような流れで、一度プログラミング教育を経験した子どもたちが、プログラミング教育以外の分野でも、ボトムアップ的なアプローチで色々と試行錯誤し出す、ということがあり、これは大きなメリットの1つであると小池さんが言ってました。

本来、「教育とは子どもたちの個性に合わせて行われるべき」というのが持論ですが、どこかで横並びの画一性みたいなものが管理上求められる部分もあるので、この矛盾とどう戦って行くのかが重要だなと個人的には思いました。子どもたちに合わせるなら、個人指導みたいなのがベストだけど、現状の公教育は集団授業前提なので、なかなか子どもたちそれぞれに合わせていられない部分はあると思います。

プログラミング教育のデメリットは?by安藤氏

公教育にはほぼすべての大人が子どもの頃に経験したもので評価してしまうけど、実は最新の公教育がどうなっているのか?という実態を把握している人はそう多くないです。だからこそ、安藤さんはプログラミング教育についても「知ったかぶりする人が多い」という表現をされていたのが印象的でした。

安藤さんは前述のCoderDojoでも子どもたちに教えた経験があります。教育の現場として、「IE(ブラウザ)を開くのに15分かかる」「キーボードで入力すると急激にハードルがあがる。”こんにちは”と入力するのに1分かかったり」と事例はなるほどなぁという感じでした。

個人的にはいい加減、キーボードに変わるより直感的な入力デバイスが必要な気がしていますが。誰かベンチャーでやらないかなw現状だと音声入力の精度がかなり向上している感ありますが、どうもプログラミングの入力となると記号などが多いので難しそう。音声入力専用のプログラミング言語とか作れば良いのかしら。

話が逸れました。

いずれにしても、公教育におけるプログラミング教育は、そのハードルをかなり下げる必要があるという主張は共感できました。確かに、野球やサッカーの競技人口の裾野は広がっていますが、だからといってみんながプロの選手になる訳ではないです。プログラミングも同様で、職業エンジニアに求められるハードルと混同してはいけないと思います。

「議論のすれ違いー」

このように安藤さんは表現していましたが、私もまったく同感で、ポジショントークによるものが大きい気がしています。産業界ではいわゆるホワイトカラーの仕事が増えていて、かけた時間と成果が一致しない類の「質」が求められるようになってきています。この流れの中で、プログラミング的思考が求められることが少なくありません。それでなんとなく一斉に「これからはプログラミング教育の時代だー!」みたいな温度感高めの人たちが一定増えているのが現状かなとも思います。

この話を書いていて思い出したのが、サイバーエージェント系列のCA Tech Kidsの代表とCA藤田さんとの対談のこの記事です。この記事の後半に出てくるのですが、プロ野球と同じように、高校生向けのドラフト会議のエンジニア版をやるというのが興味深いなぁと。こんな感じで、エンジニアとしてのエリート教育もあって良いと思います。大事なのはダイバーシティですね。野球でもサッカーでも、だいたい日本代表レベルで活躍する人って、地域のリトルリーグとかそういうのやってましたよね。ガチ勢は意外と学校の部活とかやんない感じでした。そんなノリでプログラミング教育も浸透すると良いのかなぁと思います。

プログルの紹介by田中氏

公教育におけるプログラミング教育のハードルを下げる取り組みとしてみんなのコードとして取り組んでいるのが、プログルです。これはプログラミング教育における定番Scratchっぽいものですね。

イベント当日は、自治体別アクセスランキングなどを見せてもらいましたが、全国からアクセスされて使われていました。

Scratchもそうですが、これ系のやつって子どもたちにやらせるとみんな総じて「楽しかったー!またやりたい!」ってほぼなるんですよね。この満足度はやりがいあって良いなと。うがった見方ばかりしかできない大人にはならないように気をつけましょう(違)。

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

既に所感もあわせて記述したのでその通りですが改めて。

どの目線で話をするのか、というのが一番大きいですね。やはりプロのエンジニアになるためのプログラミング教育と、プログラミング的思考を養ったり、プログラミング教育の出会いの場を提供するという公教育では役割が違って当然です。2020年小学校教育でプログラミング教育が必修化されるとか、センター試験で科目化されるとかの時代の流れもあって、このあたりの棲み分けが現状カオスになっている印象はあります。

何事も活動が広まっていくプロセスにはカオス期というのは避けて通れないので、あと5-10年くらいかけてもっと洗練されていくのかなと思います。公教育の体育の授業でソフトボールや野球をやるのと、リトルリーグに所属した人がプロ野球選手になるプロセスに文句いう人がいないように、プログラミング教育が自然になっていく時代がやってくるのは間違いないでしょう。

私はエンジニアなので、日本が少子高齢社会の中で高い生産性を保ってより高い価値ある仕事を創造していくには、プログラミング教育は何かしら必須であると考えています。そのうち時代がやってくるさ♪という傍観者ではなくて、何かしらプログラミング教育へのコミットメントを増やしていきたいです。

頑張ります!

【書籍レビュー】超入門シリーズ本を献本頂きました

前回に引き続き、WINGSプロジェクトが監修し、技術評論社から出版されている超入門シリーズ本を以下の3冊献本して頂きました。

それぞれの本についてレビューをば。

※関係者の方々、対応が遅くなり申し訳ありません。。


【書評】たった1日で基本が身に付く! HTML&CSS超入門

webサイトとはそもそもなんぞや?という点からちゃんと解説されている

超入門書なだけあって、そもそもwebサイトがサーバーに設置されていてブラウザなどのクライアントからアクセスして読み込むものだ、的な基礎的な部分からちゃんと解説されています。 また、技術的側面だけでなく、webサイトを設置する目的やどう設計するか?についてもちゃんと触れられている点が素晴らしいです。

HTML5をベースとしたセマンティックwebが意識されている

超入門書といえど、headerタグやfooterタグなどを通してセマンティックwebについて早い段階でちゃんと解説されています。

CSS(Cascading Style Sheets)の基本がしっかり理解できる

CSSの発展の歴史を紹介していたり、HTMLタグをwebページの装飾目的で使うことを戒めたりなど、経験あるwebサイト制作者の方の言葉が散りばめられている辺り、好感が持てる印象でした。

あと、私自身はサーバーサイドエンジニアなのでHTMLとCSSはなんとなくのフィーリングで理解しているところもあったので、例えばボックスモデルなどは恥ずかしながらmargin, border, padding辺りの違いについての認識が甘いところがあります。その辺りがちゃんと体系的に再確認できたのは良かったです。

同様の理由で、段組みレイアウトの辺りの解説もまた、何がブロックレベル要素で何がインライン要素なのかとかあまり意識できてなかったり、フロートレイアウトなどもフィーリングで理解していたところがあったので正直勉強になりました。

レスポンシブデザインに対応している

最近では必須のレスポンシブデザインに対応しており、具体的にはスマートフォン対応する具体的な方法についても解説されています。 私自身、メディアクエリとかちゃんと理解できてなかったところがありました。。

総評

本書を一通りなぞれば、コーヒーショップのレスポンシブなホームページのサンプルを制作することができます。 本書を足がかりにすれば、読者は基本的なwebデザインのうちHTML・CSSコーディングができるようになると思います。

その意味で本書は良書だなーと思いました。

また、私みたいにサーバーサイドエンジニアが本業なんだけど、フロントエンドはそこまで詳しくないけどちゃんと体系的にイチからインプットしたい、というモチベーションがある人には刺さるかもしれません。 とはいえフロントエンドもある程度できるエンジニアにはちょっと物足りないかもしれませんが。

余談ですが、「本業サーバーサイドエンジニアに贈る基礎から学ぶフロントエンド」的な書籍があったら実はニーズあるんじゃないかと思いましたw

【書評】たった1日で基本が身に付く! JavaScript超入門

webアプリケーションとはなんぞや?についてちゃんと解説されている

超入門シリーズ本にはおなじみですが、ターゲット読者層がプログラミング未経験者なので、そもそもwebアプリケーションってなんだっけ?とかサーバーサイド、クライアントサイドの違いみたいな基礎的なところから解説が始まります。

執筆者の立場として個人的に思うのですが、このあたりの解説ってすんなり説明するのが意外に難しいところだったりします。 どこまで歴史的な背景やバックグラウンドを説明するのかとか。

このあたりの部分、前半部分での説明が超入門者向けにも過不足なく非常に分かりやすいのではないかと思います。

また、JavaScriptでできることの幅が広がりつつある昨今ですが、その辺りにも触れつつ、本書でカバーする範囲をクライアントサイドのwebアプリケーション機能開発に特化していると明記していることもわかりやすさを担保することに繋がっている気がします。

イベントやAPI、WebStorageについて扱っている

超入門者向けでも、JavaScriptによるwebアプリケーションの基礎としてイベントドリブンモデルについて解説されています。 本書はwebアプリケーション前提なので、JavaScriptを語る上で密接に関わってくるイベントについて1つの章を割いて解説を加えているのかもしれません。

後半の章では、Flickr APIを用いて画像検索するアプリ作成を行っており、より実践的な内容になっています。 更に、Webstorageについても触れられており、こちらもAPI同様、より実践的な内容かなという印象です。

Windows環境にApacheインストールの辛い

これも超入門シリーズ本全般で辛いところではありますが、環境構築でWindowsを前提とするツラミはちょっとあるかなと。 webアプリケーションにおけるJavaScriptというところで、Apacheのインストールは避けられなかったかもしれませんが。

オブジェクトがいきなり出てくる

超入門者にとって、前半の早い段階でオブジェクトという概念がいきなり出てくるのでちょっとギョッとするかもしれません。 JavaScriptの性質上、しょうがない側面も大きいかなと思いつつ。。

総評

全体的にプログラミング言語としての側面からJavaScriptを論じるというより、より実践的なwebアプリ開発を行う手段としてのJavaScriptを紹介した書籍という印象を受けました。

プログラミングを全く学習したことのない人向けにしては、プログラミングの基礎的な部分、例えば3大制御構造などについて体系的な解説がそれほど多くなかった印象だったので注意が必要かもしれません。

逆に、JavaScriptを使って具体的にどういうアプリが作れるのか?という点にフォーカスしたい方にとっては良書と言えそうです。

【書評】たった1日で基本が身に付く! Java超入門

コンパイルエラーなど基本的な部分が紹介されている

超入門向けらしく、半角スペースをなくすとコンパイルエラーが発生するなど超入門者向けの内容がちゃんと解説されています。

(凄い細かい話ですが)nullの正しい発音がコラムにw

nullは英語では「ナル」と発音するそうです。nullの紹介のところでコラムとして「正しく発音しましょう」って紹介がありました。 ちなみに私は普段「ヌル」と発音してます。スミマセン!

二重ループが取り上げられている

プログラミング初心者にとって最もつまづきやすいのがループと言われます。 ループを取り扱う章の最後に、本書ではループ処理がネストしている二重ループについて取り上げられています。 これはプログラミング初心者にとっては有り難い解説かもしれません。

同様に、配列の章の後半で配列とループ処理、ループ処理と条件分岐の組み合わせについても取り上げられており、二重ループ同様、プログラミング初心者にとってはプログラムが複雑になる過程をちゃんと説明してくれていて理解の助けになりそうだなと思いました。

クラス解説で後半2章分割かれている

クラスの基礎について1章分、クラスの利用について1章分を割いており、クラスに関する解説はかなりページ数を割いている印象です。 このあたりはそもそも扱っている内容が重いせいか、その他の章の解説に比べて超入門者がページをまたいであちこちに行ったり来たりして理解を深める必要があるように感じました。

このあたりをプログラミング初心者に分かりやすく解説できる自信は正直私もないのですが(汗)

総評

総合的に見て、プログラミングが全く初めての人にとって、Javaを学習する目的で本書は向いていると思います。

ただ、個人的にはそもそも「オブジェクト指向」という概念がプログラミング初心者には分かりづらい気がするのでその点をどうフォローするか、というのはある意味プログラミング教育の永遠のテーマと言えるかもしれません。

RubyKaigi 2017 2日目 Matz基調講演+α

RubyKaigi 2017は広島での開催。昨年は京都で今年は広島ということで、暫く地方の流れなのかしら?

Keynote : Yukihiro “Matz” Matsumoto @yukihiro_matz

  • 世界最大規模のRubyカンファレンスがRubyKaigi
    • 何を話すか困る
    • 松田さんには聴衆置いてきぼりでも良いので聞いたこと無い話、技術的な話してよとオファー来る
    • 才能の話をする
    • 天才プログラマーと言われるけど自分でそう思ったことはない
    • 自称プログラミング言語デザイナ
    • matzが初めて触れたプログラミング言語はBasic
    • 自分の思考をまとめるツール=プログラミング言語
    • I love all programming languages.
    • 「matzは他の言語に攻撃的だから嫌い」と言われることがある
    • Rubyのmatzだから他言語を貶めてRubyアゲようとしてる、と言われるけど本人全くそんなつもりはない
    • とはいえ昔Pythonのメーリスに乗り込んでRubyならこんなことできるよと言ったこともあるけど(笑)
  • Simula(1968):初のオブジェクト指向言語の話を
  • Animal – Horse – Zebraが表現できるように
  • Dr. Kristen Nygaard(クリステン・ニゴール)
  • 「全てのオブジェクト指向言語は私の孫みたいなもんでなぁ」←会った時言われた
  • 単一継承(木構造)→多重継承(ネットワーク構造)
  • C3リニアリゼーションアルゴリズム
  • Mixin(Lisp界隈はFlavorsと呼んでた)
  • アイスクリームとチョコチップのたとえ
  • Rubyはこれをmoduleとして採用
  • namespace(ex.Net::HTTP)/singleton(ex.FileUtils)/メソッドの集合(ex.Math)としてのmoduleも
  • 2013年2.0から新たな機能
  • Alias method chain:欠点もある→Module#prependがRailsコミュニティから複数人から提案があった
  • 一度prependしたら外せないようにするのは敢えて→待てよ
  • CLOS(Common Lisp Object System)という言語を想起
  • アスペクト指向プログラミングといっても良い(Gregor Kiczalesが考えた)
  • リファインメントとしてのmodule
  • なぜモンキーパッチングというのか?
  • ゲリラ→ゴリラ→モンキーになったっぽい
  • ActiveSupportがモンキーパッチングの良い例
  • 2.days.ago(これRubyかよ)ってのができるようになる
  • スコープを区切ったモンキーパッチングなら良いのでは
  • Selector namespace (Smallscript)
  • Rubyのリファインメント
    • C#のエクステンションみたいな→ex.RSpec:特定のスコープだけで呼ぶ(現時点でリファインメント使ってない)
    • 既存のメソッドを置き換える
  • Structual type checkとしてのmodule(まだプロポーザル)
    • 静的型付けとして将来的には取り込まれる可能性
  • Ruby3x3への取り組み
    • MJIT
    • Rubex
    • Fiber / Guild
    • AutoFiber(Unicorn作った人)
  • 静的型付けの取り組みも本日午後に3発表あり
  • Matzが手を動かすというよりゴールを示すリードデザイナ
  • RubyはMatzの言語というより我々の言語
  • ご覧のスポンサーの提供でお送りしています(笑)ブースに行ってくれると私の顔が立つ
    • Heroku
    • VASILY
    • Sansan
    • Speee
    • RakSul
    • リクルートマーケティングパートナーズ
    • Linkers

こっから先は話聞くのをメインにしてたので細かくはメモとってなかったので気になる所だけ…

An introduction and future of Ruby coverage library : Yusuke Endoh @mametter

  • カバレッジの種類にも色々ある
    • 条件true/false両方をカバー
    • LINEカバレッジだと後置ifなど見逃すケースも
  • カバレッジをゴールにするのはよくない
  • SimpleCovはcoverage.soのラッパー

Improve extension API: C++ as better language for extension : Kouhei Sutou @ktou

  • 高速化の為にはC/C++とRubyを行ったり来たりしないこと
  • C++11
    • 型推論auto
    • ラムダ式
  • 遅延メソッド定義

Automated Type Contracts Generation for Ruby : Valentin Fondaratov @rubymine

  • JetBrainsの中の人の静的解析の話
  • RubyMineの各プロジェクトのテストコードをクラウド化して情報集める的な(たしか)

Type Checking Ruby Programs with Annotations : Soutaro Matsumoto @soutaro

  • ずっと前から色々型チェック関連やってる人
  • Steep

Bending The Curve: Putting Rust in Ruby with Helix : Godfrey Chan @chancancode / Terence Lee @hone02

  • Herokuの中の人&もうすぐ中の人(デカい外人もHerokuの中の人)
  • RustでRubyのライブラリ作ろう的な https://github.com/tildeio/helix

イベント「非エンジニア起業家に求められるプログラミングスキルとは」に参加しました!

昨晩「非エンジニア起業家に求められるプログラミングスキルとは」 というイベントに参加してきました。

私はエンジニアで本来参加対象者って感じではないんですが、参加した目的は以下でした。

  • 参加者がエグゼクティブ向けプログラミング教育のターゲットとなる可能性のある人なので、話してニーズがあるかを確認する
  • 起業家にどれだけプログラミングスキルが求められる温度感なのか確認する
  • 今進めているプログラミング教育メディアの構想の壁打ちをしてみる

目的は概ね達成できたかなと思っています。 参加者の中で実際にニーズを持っていそうな人・ペルソナが特定できなかった部分はちょっと課題。

OFFICE DE YASAIというサービスを運営している 株式会社KOMPEITOのCEOの川岸さん(登壇者)と話して感じたんですが、 ある程度ステージが進んだエグゼクティブだとより短期的な成果を求めるのでどこまで何が良くなるのか? ということを提示できないとニーズを掘り起こすのが厳しそうだということ。

また、その意味ではよりアーリーステージの起業家の方がニーズがあるのかもしれないと思いました。 ただ、アーリーステージ起業家の場合だと、本人がプログラミングスキルそのものを身に付けるという話なので、 その意味では私が想定するエグゼクティブ向けプログラミング研修とは違うかも。

全体的にエンジニアの私にとってはそれほど真新しい話はなかったんですが、 サムライインキュベートが支援するようなサービス開発のベンチャーは基本的に起業家がプログラミングできることか チームにエンジニアがいることが支援の条件でやはりアメリカ同様プログラミングスキルに対する ビジネス評価の温度感は高いです(当然か)。


あとは以下、昨晩のメモと感じたことを箇条書きで記しておきます。

  • アメリカにはプログラミングスクール女子校がある

女性向けサービス開発を行う上で女性の感性が必要なので女性がプログラミングスキルを身に着けて起業家になる女子校があるそう。 嫁に運営やらせたら面白いかも?とちょっと思いました。 こういうニッチに特化した方が集客しやすい側面がありそう。

  • エンジニアを起業家にする教育を施す学校のニーズは一定あるかも?

登壇していたG’sアカデミーも起業家向けのプログラミング教育を行ってますが、 むしろエンジニア界隈で最近主流になってきているプロダクトマネージャーの流れで、 エンジニアを起業家にする方が筋が良い場合があるのでは?と思いました。

その延長線で、エンジニアを起業家にする教育を施す起業家養成学校をやったらニーズはありそうな気がしたんですがどうでしょう。

  • 和田さん曰く「プログラミングとエンジニアリングは分けて考えている」

最低限動くモノづくりができるというプログラミングと、より良い設計やコードといった高度なエンジニアリングとは分けて考えている、 ということ。 CEOはプログラミングはできるべき、エンジニアリングまでは必要ない、とのこと。この主張は分かりやすく共感できた。

  • G’sアカデミー児玉さん曰く「スクールの立ち上げに複数関わってきた経験から言えば、集客は難しい。良い講師を揃えれば生徒が集まるかというとそうでもなく工夫が必要」

直感的に経験からの重い言葉と理解しました。 個人的にはスクール立ち上げの経験がないので実感としてはまだ分からないですが、 恐らくスクールに参加しようと思わせるマーケティングが必要だということと理解しました。


現在少しずつ実験的に開発を進めているプログラミング教育メディアの構想は筋は悪くなさそうという感触は得られました。ただ、ターゲットとなるペルソナは今回のイベントの参加者とはちょっとズレがあるのでその点は考慮が必要で引き続きヒアリングを進める必要がありそう。

【書籍レビュー】Ruby on Rails 5 アプリケーションプログラミングを献本頂きました

久々にブログ更新。

ここ最近、友人から紹介されてWINGSプロジェクトという技術書執筆者のコミュニティに属して、色々と執筆を行っていたりします。 たとえば、CodeZine「サンプルコードで学ぶRuby on Rails 5実践入門」という連載中です(もうすぐ連載終了予定ですが)。

さて本題ですが、このWINGSプロジェクトの主催者である山田祥寛さん著「Ruby on Rails 5 アプリケーションプログラミング」という技術書を献本頂いたのでレビューを書きます。

網羅性が高い

全体的にRailsの機能をまんべんなく解説しています。 たとえばDBから動的にセレクトボックスを生成するoptions_from_collection_for_selectビューヘルパーなど、かなり広範囲にカバーされている印象でした。 また、ActiveRecordのlock_versionカラムによるオプティミスティック同時実行制御についても触れられています。 さらに、フロントエンドの開発のところで、CoffeeScriptには三項演算子がないなど、CoffeeScriptの基本的な文法まで触れられているのでRubyしか触ったことがない人にとってもこれ1冊でRailsの基礎を身につけることがある程度できそうです。 あとscss -iでSCSSがインタラクティブモードで起動できるとか実は初めて知ったことも書いてありましたw

解説が分かりやすい(特に解説図)

専属テクニカルライターとしてキャリアの長い山田さんならではの分かりやすい解説が特徴かと。 Rails初心者が読んでも非常に分かりやすいと思います。 また、ところどころで差し込まれている解説図が直感的に理解しやすいもので感心しました。

随所にRails5以前のバージョンの知見が散りばめられている

NOTEとしてRails5以前だとどうだったかの解説があります。 たとえばStrong Parametersの解説など、3系・4系のバージョンと絡めてRails5への理解を深める解説が散りばめられています。

註釈が結構細かい

右側が本文、左側の余白に様々な註釈があり、知識を補強する解説が掲載されています。 結構かゆいところに手が届く感じの註釈が多い感じで表層的な理解に留まらず背景知識も深く理解できそうです。

環境構築はちょっと注意が必要

環境構築がWindowsとLinux両方をサポートしているのですが、Railsをガチで開発する場合結構Macで開発することが実際多いかなと。 Macでの手順の記述がないのはちょっと残念な印象です。 また、Railsも直接gemをインストールしていますが、実践的にはrbenvでRubyをインストールしてbundler経由でRailsをプロジェクトローカルにインストールすることがほとんどなので、その辺のデファクトが分かっていない人にとってはちょっと注意が必要かなと。 まぁ、そもそも上級者向けの書籍ではないのでその辺は当初から割愛しているのかな、とは思いますが。

Action Cableの詳細解説がない

Rails5の目玉機能の1つにAction Cableがあることはサラっと触れられているのですが、残念ながら詳細の解説がないです。 この辺はページ数の関係で省略したんでしょうか。まぁこれちゃんと説明すると結構面倒なんですよねw

総評

個人的には網羅性と分かりやすさの観点で、初心者を脱却しつつある方が体系的にRailsを捉え直すのにちょうど良い書籍かなと。 全くの私見ですが個人的にはパーフェクトRuby on Railsより分かりやすい印象ですw

【速報】RubyKaigi 2016初日参加レポート

聞きながらの自分用メモなのでちょっと正確でない点がありそうですが。

Ruby3 presented by matz

  • Typingの話
  • SmallTalk→Java→Ruby,JavaScript→Swift,Go→?
  • 近視眼的な判断で静的型付けを選択するのは危険
  • そもそも未来の型とは?
  • Duck typing: アヒルが歩くように。アヒルのように振る舞えばOK
  • Duckとは期待される振る舞い
  • プログラマのメンタルコストを下げたい
  • GoのStructual SubtypingはNominal Subtypingより良さ気
  • Rubyには歴史的にこれまで型指定がない
  • 動的型付けの欠点もある
  • エラーメッセージが親切じゃない
  • 型は絶対に書きたくない(会場笑) DRYじゃないし
  • Type Annotation,Mixed/Gradual Typingはダメなアイディア
  • 人にお願いするんじゃなくて技術で解決したいよね
  • 型推論は素晴らしい
  • インタフェース書きたくない
  • 型の名前を決めるのは結構なコスト。振る舞いがわかっていれば名前を付けたくない
  • 振る舞いを決める型のデータベースのようなものと型推論を組み合わせると80%くらいは推論可能では
  • オープンクラスとかで再定義しちゃうと型推論無効に
  • 型データベースをgem化して利用して型推論の精度向上とか
  • ダックタイピングを維持して型推論をRubyらしく行う
  • これらの構想はすべてRubyistが楽しく生産性を維持できるために検討していること
  • Ruby3はいつか? I don’t know.(会場笑)
  • 次の東京オリンピックの時にはRuby3あると良いなぁ
  • OSSコミュニティは前に進めないとつまらない。前に進めるためには何でもやる

dRuby presented by @m_seki

  • dRubyが生まれたのは1999年
  • dRubyはオーパーツ
  • shttpsrv: WEBrickより前のRuby製webサーバ
  • Rubyのように振る舞う分散オブジェクト
  • DRb.start_serviceだけでdRubyの準備可能
  • サーバーとクライアントが入れ替わる例
  • OOPっぽい感じ
  • Queueを使って待合せのデモ
  • dRubyはtwitterのプロトタイピングでdRuby/Rindaだったらしい
  • プロトタイピングとしての利用価値がある気がする
  • セキュリティ系メソッドは消してしまいたい。危ないものは危なく見えるべき

Welcome to haconiwa presented by @udzura

  • Drone.io
  • dockerらしいコマンドをしょっちゅう打ってた
  • Sqaleで使ってるLXC
  • haconiwaコマンドでRubyで書かれたプロファイル定義を実行とか
  • hacorbコマンドとかでmrubyスクリプトのコンテナ実行
  • cgroups的な
  • 最初はCRubyで実装
  • システムコール扱うのに色々嵌ったのでmruby実装へ
  • mrubyはコンテナが取り扱うシステムコールをサポートしてるので使いやすい

A proposal of new concurrency model for Ruby 3 presented by @ko1

  • 資料
  • Ruby 3に取り入れられたいと思う並列プログラミングについて
  • C言語のポインタと比較するとRubyはGCあるのでハッピープログラムできる
  • data raceやrace conditionが発生する例を通してスレッドセーフなプログラミングが如何に難しいかを知る
  • Mutexを利用して同期を取るのはバグと性能低下の狭間にある
  • Ruby 3ではGuild(ギルド)というスレッドにかわる新たな概念を提案
  • Guildは複数スレッドを含む上位概念的なもの
  • 複数のGuild間での可変オブジェクト受け渡しにはチャネルを使ってコピーするか移籍(transfer membership)という新しい概念で
  • Guild内のスレッド間はスレッドセーフが保証される
  • これらのGuildの概念でRuby 3で実現したい並列プログラミングのゴールをすべて満たす感じに
  • Guild概念導入でスレッドセーフが保証されないキモいコードを書けないようにする方向性

Isomorphic web programming in Ruby presented by @youchan

  • 去年はHyaliteの話をした
  • Menilite: クライアントサイドでもARとか使える的な(JS嫌いなのでw)
  • デモ、デモ、ひたすらデモ

Unifying Fixnum and Bignum into Integer presented by @tanaka_akr

  • Ruby 2.4ではFixnum,BignumクラスがなくなりIntegerに統合
  • 環境によってFixnumが扱えるサイズは異なる
    • 手元の環境(OS X Yosemite)だと(262-1).classはFixnum,(262).classはBignum
  • Fixnum,BignumはCommon Lispから来てる
  • 以下のコード無限ループになるけど許容するしか。 max = 1 max *= 2 if max.class == Fixnum puts max
  • 教育的に分かりやすい、数学的にも正しい、とmatzに押し込んだ

Scalable job queue system built with Docker presented by @k0kubun

  • coockpadでrails開発者の開発効率を向上する為の開発
  • RubyKaigiでrailsの話をすると怒られる
  • syoryukenってgemはSQSをジョブキューとして使うやつ
  • barbequeを作った
  • web consoleもあるよ(rails製)
  • kuroko2という社内のクローズツールが秀逸すぎたので本来ジョブキュー使うべきところでも出番なし
  • kuroko2はOSS化進めてる
  • ECSとAutoScalingグループでスケールを自動化

イベント「CTOだったNight」@dotsに参加してきました!

最近比較的よく行ってる渋谷dotsで行われた「CTOだったNight」というイベントに参加してきました! 主催はnanapiの元CTO和田(wadap)さん。 話の内容をメモっておいたんですが、思いの外面白かったのでブログ記事としてアップしておきます!

最初は自分用の箇条書きとして書いてたのでちょっと読みづらいかもですがご容赦を…

ビズリーチ/レイハウオリ竹内さん

はじめに

  • ビズリーチ最近CMやってるらしい
  • CTOを1年前に退任した理由
    • マネジメントの割合が大きくなる
    • エンジニアが自由に研究開発するのもお金がないと
    • そのための事業創造したい

うまくいくCTOとうまくいかないCTOの10の違い

  • (1)なんでも作れる技術力
    • 人間力があって技術力はそこそこだと超技術力があるエンジニアに尊敬されない
  • (2)技術を手段として使える
    • 技術を目的化した発言する人は経営陣が耳を貸さない
  • (3)経済のルールに争わない
  • (4)何よりも人を大切にできる
    • 5-10人くらいに増えるタイミングで引っかかるCTOが多い
  • (5)ビジネス人格
    • キャラ設定が必要
    • 人格とか
  • (6)本気で社長と対立しない
    • 社長が非エンジニアだとムカつくことしか言わない
    • 人間は動物だと思って悟りを開いた→社長が可愛くみえてくる
    • しょうがないしょうがない
  • (7)発信力
  • (8)外交力
  • (9)株/SOの交渉ができる
    • ちゃんと取らないとダメ
    • 最低5%は取らないと→希薄されても2,3%とか
    • 1%だったら辞める
    • 蓋開けるとCFOがいっぱい持ってたのが通例なのでCFOなんかに負けないように頑張りましょう
  • (10)何があっても辞めない
    • 辞めない、という前提に立つと価値観を変えないといけない場面がある

BASE藤川(えふしん)さん – モバツイでCEO/CTOをやってた頃の振り返り

CTOがエースエンジニアであり続ける問題

  • AWS運用で工数取られる
  • CTOは自分よりも技術的に優れた人間を探すべき
  • CTOが技術を触って良いのはコアコンピタンスだけに絞る
  • 人工知能系CTOとか育成問題に悩む

足回りと未来をつくるコンフリクト

  • 余裕がなさすぎてやるべきことを理解できてなかった
  • 現状維持バイアスを捨てるべき

BASEでは

  • コードを書かない宣言
  • 社長のビジョンを支える立ち位置
  • マイクロマネジメントの罠にハマっていないか
  • 港区には近寄らない(夜の街)

パネルディスカッション

CTOを辞めた理由

  • 営業が強くてエンジニアの立場がない
  • 新しい働き方や新しいサービスを自分でやってみたくなった
  • 社長と合わなかった、最後何かが切れる音がした感じ
  • エンジニアよりデータサイエンティストが大事でエンジニア育てる文化がなかった、頭の悪い経営陣

もしCTOをやり直すなら

  • もっと人を見る、リスクを負ってでも入れてくれるか、SOとか
  • 早目に人を入れればよかった
  • なんでも自分でやっちゃう、もっと優先度高い仕事できれば、採用をもっと任せればよかった
  • IPOとか長く続く会社とかやってみたいと思う、スポットライトは2年半で売却、IPO3%,10%,1/3とか

社長(経営)との関係性

  • CTOだったけどリードエンジニア的な振る舞いだった、あまり経営求められず
  • 営業系出身社長だと放任でコミュニケーションがとれず1on1入れたり、エンジニア出身だとマイクロマネジメントになりやすい、外部を入れると通じる
  • 飲み行く、はっきり言う関係性ができてれば良い、社長って人格に欠陥ある人多い、でも本気でいう
  • 社長が中途半端にコード書けると良くないからPHP以外の言語選んだり

これからCTOになる人に伝えたいこと

  • エンジニア的な論理はプログラミング以外のところにも役立つ
  • コミュニケーション、エンジニアだけじゃなくビジネスサイドの人とも、コミュニケーションを仕組化する、CTOは孤独だから相談する人を作っておく
  • 会社全体とかビジネスのことを考えるようになるから良い、営業の話も聞きながら技術的負債に向き合ったり
  • マネジメント系の本とか読むとか勉強してアウトプットできるようになる、マネジメントだけどコーチングできてないとか、お互いフィードバック貰って成長・学習する

所感

CTOに限らず、ビジネスサイドと近い立ち位置で仕事しているエンジニアの方なら誰もが共感できる内容だったかなと思いました。

私自身も経験に照らし合わせて非常に共感した次第です(笑)

大切なことは異文化コミュニケーションであることを受け入れつつも、コミュニケーションを諦めないで主張すべきは主張することかなと。

また、場合によってはみずからの価値観を見直す柔軟性も必要なことだなとも思います。

ある意味政治というか、相反する部分をいかに粘り強くコミュニケーションを取って折り合いをつけるか、という点が重要ですね。