tchikuba's blog

Beer Driven Developer / Lean Engineerの徒然

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

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

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

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

ちなみに余談ですが、先日Qiita記事にも書いたように、このシリーズのRails本「たった1日で基本が身に付く!Rails超入門」(通称:Rails超入門)を執筆中で今のところ来年(2018年)2月に発刊予定です。

買って下さい!(しつこいw)


【書評】たった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に限らず、ビジネスサイドと近い立ち位置で仕事しているエンジニアの方なら誰もが共感できる内容だったかなと思いました。

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

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

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

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

イベント「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言!~ 女性エンジニアとして長く働く秘訣 ~」に参加しました!

先日「dots.女子部勉強会 vol.7 わたし、一生エンジニア宣言!~ 女性エンジニアとして長く働く秘訣 ~」 というイベントに参加してきました。 私の妻も私と同じエンジニアでdots.女子部の一員として運営に関わっています。 妻からこのイベントを企画していることを事前に聞いており、参加を楽しみにしていました。

参加した当日はノートPCを持っていくのを忘れていたので、スマホからひたすらtwitterで実況中継していました(笑) 備忘録的な意味も込めて、当日のtweetをtogetterまとめっぽくお届けします。


※遠距離恋愛の参考にしたいというdots.女子部メンバーの話を受けて

夫婦共働きで子供がいるってどんな生活リズム?

家事の役割分担とかどうしてる?

子供にはお金がかかるけど、どうやって踏ん切りつけた?

夫婦でエンジニアって同業のメリット・デメリットは?

地方移住とか考えたりする?

※リモートワーク的な文脈での話。

2人目ができると更にカオスって聞くけどどう?

どれくらい産休・育休って取ったの?

今後の夢とかは?

終了後の懇親会

オサレなケータリング

竹馬 力さんの投稿 2016年3月24日

他の参加者の方の感想


やっぱりエンジニア夫婦って(・∀・)イイネ!!

勉強会に参加して感じたことです。 同業だと問題もあるという話を聞いたりもしますが、ふたりともエンジニアである場合、メリットばかりが目についてデメリットってほとんど思いつかないです。 テクノロジーへの理解があるという点、非常に共感しました。新しい製品を買ったりするのに家庭内稟議は圧倒的に通りやすいんじゃないかとw

あと、今回登壇されたご夫婦2組とも、男性の優秀さもさることながら、女性の優秀さが凄いなと感じました。 なのでプログラマである私の妻にも、このご夫婦に見習って凄くなってもらおうと思います(笑)

エンジニア・チームのダイバーシティ向上を!

私は日頃から、ダイバーシティの観点から、あらゆる組織は男女比率がおよそ半々である方が良いと考えています。 しかしながら現時点では、特にエンジニアの世界では圧倒的に男性比率が高い状況があります。

たとえば、10代、20代の女性をターゲットにしたwebサービス開発エンジニアは全員男性で、女性が1人もいない、などのケースも比較的よく耳にします。 中長期的に続くことが前提のサービスにあって、手を動かすエンジニアがdog foodingできることは、成功する確率を高める最も大きな要因の1つだと思います。 その意味では、女性向けのwebサービスであれば女性エンジニアが手を動かした方が、より良いサービスを創ることができるのではないでしょうか。

今後もしエンジニアのチームを構成することがあるとすれば、できる限り男女比率を半々になるようにやっていきたいと改めて決意した次第です!

21世紀型のクリエイティブな働き方・思考・組織の新しいあたりまえ

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

私は現在IESHIL(イエシル)という中古マンション価格査定サイトのエンジニアやってます。 担当は雑用係です。 リブセンスに入社して約2年半ですがリブセンスでwebサービスの自社開発の文脈に身を置いて色々思うところがあるのでその辺をちょっと言語化してみます。

プロフィールとバックグラウンド

私はエンジニアになったのが2004年8月でした。 7年間フリーランスのエンジニアとしてお客さんのところに常駐して作業するという形で、所謂社畜フリーランスでした。 前半4年間は大手SIer、後半3年間はエンタメ系事業会社に常駐していました。

前半の4年間では小さいプロジェクトだったこともあり、ウォーターフォールで言うところの要件定義、基本設計、詳細設計、実装、テスト設計、 単体テスト、結合テスト、受入テスト、リリースなどソフトウェア開発の全工程を担当してエンジニアとしての基礎力を身に着けた時期でした。

後半の3年間では所謂「ステークホルダーと調整して設計書を書くSE」「ベンダーコントロールPM」的な立ち位置で 主に自分が手を動かさず人に手を動かしてもらう為の環境整備的なことをやっていました。 今思い返すと、この時期に所謂プロジェクトマネジメント的なところの基礎力を身に着けた時期だったと思います。

そうこうしているうちにより大きなやりがいと責任ある立場でやれる仕事をしたいと思い、新規事業のプレイングマネージャー的なポジションを探していたところ あの2011年3月11日が来て、人生短いんだからやりたいと思ったことをやるべきだと踏ん切りがついて前職となるPR会社の新規事業の開発マネージャーとして転職しました。 この時期に要求仕様の変化が激しい新規事業、所謂スタートアップ的な文脈ではウォーターフォール型の開発の行き詰まりを実感し、 アジャイルやリーンな開発(技術開発だけでなく事業開発含め)の手法を模索し貴重な経験をした時期でした。

開発マネージャーとして約2年間働いた後、現職のリブセンスに転職をして現在に至ります。 リブセンスでの強烈なエンジニア文化の中で、エンジニア含めた事業に関わる全ての人が効率の良さと気持ちの良さをどうやったら追求出来るかを最近良く考えます。

SIerから事業会社の文脈へシフトして感じたビジネスとエンジニアリングの関係性

自分のキャリアを振り返ってみると受託開発が主であるSIerから徐々に自社サービスを展開する事業会社へとシフトして行ったことになります。 私のキャリアの文脈が徐々にシフトしたのは単なる偶然な気がしますが、この経験があるからこそなのか、最近良く考えていることがあります。 それは、ビジネスとエンジニアリングは一体不可分であるということです。

ある意味これは最早当たり前の時代になってきたんだと思われますが、私が10年前にいたSIerの文脈だと実感として結構違っていました。 あくまでも受託開発では発注側のお客様がいて請負契約に基づいて予め定義したシステムを納品することが目的です。 出来上がったシステムがお客様が使ってみた結果、それがビジネス上価値を生み出すか否かは短期的には関係がありませんでした。

しかし事業が社内にあり内製出来るエンジニアチームを持っている文脈では事情が異なります。 当然ですが開発を行った結果ビジネス上無価値なものを作ってしまったとしたら基本的にその当事者が作り直す必要があります。 開発と運用が一体となっている文脈では、要件の変化に伴い柔軟にシステムを変更する必要がありまたそれに耐え得る品質を ソースコード上の保守性、DDD(ドメイン駆動設計)等を用いたビジネスドメイン設計、CI等で担保する必要があります。

これまでの私の経験上、感じていることをまとめると以下の様な図になる気がしています。

発注者と受託者という関係では、前者から後者へ金銭的な授受が行われる為、ビジネスパートナーといえど、構造上どうしても主従関係のような強弱がついてしまいます。 当然上手く行っている受託開発も存在しますが、経験上上手く行かないパターンを見ることが少なからずありました。

※ただ最近は一括請負契約の構造上の問題を解決する受託開発の手法の1つとして「納品のない受託開発」 を手掛けるソニックガーデンさんの事例は注目したいところです。

上記の図に表現した通り、時代の変遷と共にエンジニアリングの比重を相対的に大きくしていますが、これも実感としてあるところです。 昨今のビジネスにおいては「如何にビジネス上の営みをシステムに落とし込むか」という点の比重が徐々に拡大している気がします。 当然ながらビジネス上のシステム化とは、エンジニアリングの観点でのシステム化だけではなく、機械的に出来ることと出来ないことを選別した上で 人手でどこまで行うのか、人をどう配置するのか、関わる人に要求される職能は等、多岐にわたります。 しかしながらそれらの人が業務上関わる場所に全てシステムが介在することもまた事実であり、その範囲は時代を追うごとに拡大していると思うのです。

もっと言えばビジネスに近接する立場にある非エンジニアの日頃の業務にこそ、効率化の余地があることが多いとも感じます。 余談ですが最近日経の記事にコーディング・ブートキャンプの話がありました。

この記事から類推するに、非エンジニアが何らかのビジネス上の課題解決の為にコーディングを勉強する需要があるんじゃないかと思います。

いずれにしても現時点で痛感していることをまとめると、 ビジネス上1つのプロセスでしかなかったシステム化が、ビジネス上最も重要なプロセスの1つとなり、その後、ビジネスと一体化しつつある ということです。

これらのことは既に各方面の偉い人が唱えていることで、理論上は当たり前だと思うのですが、これを経験上私が感じれていることに スティーブ・ジョブズ曰くのconnecting the dotsを感じてちょっぴり嬉しいのです。 頭で理解したことと体験で会得したものでは実は雲泥の差だなと思いますので。

ゴール思考とシステム思考の融合

connecting the dotsのリンク先の記事に曰く、

点と点を繋げるということは、あらかじめ仕込むことは出来ないということです。 しかし、振り返ってみると「あの時のことが役立った」とか、「あそこで出会った人に、こんなタイミングで助けられた」といったことって意外とあるものなんですよね。

とあります。

私も自分の経験を振り返ってみて思うのですが、その通りだなと。 これ実はある意味「システム思考」だな、ということを最近しみじみ感じます。 少なくとも予め仕込むことは出来ないという点においては、ゴール思考とは遠い気がします。

私実は11年間エンジニアやる前、1年くらい超ブラック企業と言われた某営業会社で営業をしていた時期が(一応)ありました。 この企業が物凄い体育会系ノリだったのと超絶ゴール思考的で理系出身だった私には全く考え方が合わず辛い思いをした苦い経験でした。 既に亡くなった(笑)会社でもう時効だから書いちゃいますけど、当時の上司から2回辞表書けって言われて書いたりして(笑) 1回目の辞表なんて「まだ辞めたくないけど上司に辞表書けって言われたので辞表書きました」という内容の辞表だったりして(笑)

今でこそ笑い話ですが、この経験が実は比較的ネガティブな原体験として、極端なゴール思考では歪みが生まれて持続可能な発展でなくなる ということが自分の中に焼き付きました。その後も若干紆余曲折あったんですが、この体験が元になってエンジニアリングを1から勉強してエンジニアになろうと思えました。 当然ながらこの時はシステム思考なんて言葉も知る由もないんですが、振り返ってみれば、目の前の課題解決を積み重ねるアプローチを欲していたんだと思います。

また、実はゴール思考も適切な範囲であればモチベーションコントロールとして有効であることも体験していることも重要です。 システム思考だけだとビジネス上実現したいビジョン等から外れてしまっても暫く気付かないケースがあるように思います。 個人的にはゴール思考とシステム思考の融合を目指したいと考えています。私の体験上でもそれは理に適っていると思われるのです。

ヒエラルキーとホラクラシー

このような文脈にあってもう1つ私の中で良く考えることがあります。それはクリエイティブな組織の在り方についてです。 私はその1つの解としてホラクラシー型組織の構築があるのではないか?と考えています。 ホラクラシーとは、マネージャーの存在しないセルフ・マネジメント型組織のことで、ザッポスが導入したことで有名です。

最近のハーバード・ビジネス・レビューにホラクラシーに関する記事がありました。

この記事に曰く、

ホラクラシーの大部分は、優れたマネジメントによく見られる要素を単に体系化していると気づいた。 ホラクラシーの導入にまつわる細部にとらわれず、それが何に対処するためのものなのかを掘り下げて考えれば、見えてくることがある。 問題は、ヒエラルキーそのものがいかに正当性を失ったかではなく、速まっている世の中の動向に対してヒエラルキーでは動きが遅れることなのだ。

とあります。

確かにヒエラルキー型組織で優れたマネージャーは、出来るだけ現場に裁量を与えて信頼し、問題が発生した場合だけ出来るだけ迅速に対応し 問題の責任を取るタイプが多い気がします。極論、成功は部下の功績とし、失敗は上司(自分)の責任とするタイプですね。 まぁ体験的には大体ヒエラルキー型組織だと中間管理職層は人間が腐っていく例を良く見てきた気がしますが(笑) 私が開発マネージャーだった際にこういう優れたマネージャー像を目指して奮闘してましたが、理想像からは程遠い感じだったような気がします(汗)

いずれにしてもスピード感を持って変化に対して対応していく為には現場でコトに当たっている当人が誰かに判断を仰ぐことなく 自分の判断で臨機応変に行動することが出来てしかもその判断が正当であれば(結果がどうあれ)最も正しいと思います。 まぁ逆に振り返って判断が正当でないように第三者からは見えても、結果がマズい方向ではなく良い方向であればヨシとすることもあるかもしれません。

私は、クリエイティブな仕事に携わる人々が関わる組織が今のところ最も上手く行く方法論としてホラクラシーを捉えています。 逆に1ヶ月ほど前にバズってた、CIAのスパイマニュアルの記事がヒエラルキーの問題点を端的に表していると思いました。

曰く、

会社内での組織的位置付けにこだわる。 これからしようとすることが、本当にその組織の権限内なのか、より上層部の決断を仰がなくてよいのか、といった疑問点を常に指摘する

これとかまさに先ほど書いた現場の臨機応変な判断を阻害する真逆の論理で一見正当性が見えるので厄介なんですよね(苦笑)

「不二」という視座から垣間見る21世紀のスタンダード

ちょっとここまで書いた所で息切れしてきましたが(笑)そろそろ結論めいたことを書きたいと思います。 結局のところ私の体験という文脈の中でしか実感を持って判断出来ないと思っていまして、その意味では至極主観的極まりない話だということが前提ですが。 現時点での私の文脈(コンテキスト)では、これら一見相反するように見えるものが実は一体不可分である、ということです。

まず、ビジネス上使われる一部に過ぎなかったエンジニアリングが、経営の中心となりつつあります。 次に、極端なゴール思考の行き詰まりや矛盾から、持続可能な発展を考慮したゴール思考によるビジョンに基づいたシステム思考の重要性に気付きました。 最後に、ヒエラルキー型組織の矛盾の中でキラリと光るマネージャーを垣間見たり、理想像目指して奮闘したりするも、 マネージャーとなってコードを書かなくなったらエンジニアとして終わりなんじゃないかと自問自答して、 私自身の手でエンジニアのホラクラシー型組織を実現したいと夢見て現実と奮闘していたりします。

私の体験としては実は予期せず元いたコンテキストがあったからこそ、気付きを得たと言えますし、 対立しているように書いたことも実は存在意義が多分にあり一体不可分なのだと思えるのです。 これを代弁する考え方に仏教の用語で「不二(ふに)」という言葉があります。

曰く、

対立していて二元的に見える事柄も、絶対的な立場から見ると対立がなく一つのものであるということ。

前述のような見方が絶対的な立場か否かは分かりません。

ただ、ヒエラルキー型組織でウォーターフォール型開発を一通り経験出来たからこそ、その長短を体得することができたのだと思います。 ビジネスと遠いところで開発をしていたからこそ、ビジネスに近接するところで開発する際の違いを痛感し開発プロセスを多少なりとも改善してきました。 そもそもホラクラシー型組織を上手く回す為にはセルフ・マネジメントが出来る優秀なメンバーのみで組織を構成する必要がありそうです。 職能的にジュニアクラスのメンバーは一向に力を発揮出来ないことになりそうですが、敢えてヒエラルキー型組織で力を付けるという選択肢もあるかもしれません。

これらを踏まえた上で、私自身の経験に即して、これからの時代以下のような流れになっていくのかなと考えています。

  • 事業会社の内製化により下請けも含めたSIerは斜陽産業化する。
  • 事業会社がweb企業・インターネット企業となるのが当たり前になる。
  • 新しいビジネスを起こす人はエンジニアの素養のあることが当たり前になる。
  • エンジニアの素養のある人が起業するので、エンジニアの評価がよりまともになり、まともなエンジニアがよりHappyになる。
  • 非エンジニアの職種では徐々に人工知能や機械学習による自動化が進みよりクリエイティブな仕事をせざるを得ないようになる。
  • 日頃ルーチンワークが辛いと言って仕事がつまらない思いをしている人は少なくなっていく。(仕事自体がなくなるので)
  • プログラミング教育が官民共に爆発的に広まる。
  • エンジニアの仕事はコーディングによってビジネス上の価値を創造することが評価のポイントになる。
  • 世の中の複雑性は増していく一方で先が簡単に読めなくなり、反復型アプローチが問題解決の主流になる。
  • ある一定の人々に共感される極めて倫理的なビジョンを有するテックドリブンな企業が緩やかに受け入れられ世界を変えていく。
  • 急進的なスタートアップより、持続可能な発展を掲げるスモールビジネスが大量に浸透していく。
  • 副業やリモートワークがより普及して組織力は弱まり、クリエイティブな個人がクローズアップされる。
  • 自律した働き方の出来るクリエイティブな個人が集まり、プロジェクト単位でギルド的集団を形成し、質の高い仕事を成し遂げる。
  • 自律した働き方が出来るまでの職業訓練が比較的安価で受けられる教育的な仕組みが出来ていく。

私自身はこれまでの経験を踏まえてやりたいことが比較的明確になりつつあるのですが、 キーワードはITと新規事業と教育ということで一応一貫しているつもりなのでこの方向性は常に持ちつつ、 これまでのエンジニアとしての技術的な方向性から、更にビジネス・経営的な方向性で社会貢献出来る人材になろうと決意しています!

この記事はリブセンスアドベントカレンダー2015(その2)の5日目です。

「ECMAScript6勉強会」HappyHalloween JS 祭!!に参加してきました!

2015年10月31日(土)に行われた「ECMAScript6勉強会」HappyHalloween JS 祭!!に参加してきました! ハロウィンということで仮装して参加すると参加費が半額になるというちょっと変わったイベントでしたw

※リアルタイム更新してました!

『Good evening, ES6』byよしこ氏 @yoshiko_pg

  • 発表スライド
  • var –> constで変数の上書き禁止が可能に
  • Template Strings
  • 関数のDefault Parametersが使えるように
  • Rest Parametersで…argsで引数がarrayで取れるように
  • Spread operator(スプレッド演算子)でapplyメソッド使用せずに配列を展開出来るように
  • yoshiko氏の年齢がサンプルコードで暴露されてる(笑)
  • Destructuringで変数の入れ替えの為のtmp変数が不要に
  • Effective ES6(slideshareのスライドがオススメ)
  • ES6をES5に変換するBabelを使うとES6で書くことが出来る
  • Scratch JS(chrome拡張)入れるとES6をコンソール上で試せる
  • gulpfileをv3.9.0以上ならES6で書ける

『Promises』by矢倉 眞隆氏 @myakura

  • 発表の様子
  • 非同期処理について洗濯機とかお風呂とかの例
  • JSでの非同期処理だとコールバックヘルに陥りがち
  • thenで非同期処理を実行することが可能。メソッドチェーンで繋げることが出来る。
  • Async functionでコールバックパターンから開放される方針。try,catchで書ける。MS EdgeやFirefoxで実装される予定。

『Function and Class』by川田 寛氏 @_furoshiki

  • 発表の様子
  • Arrow Function
    • 朝起きたらクリックイベント書きたくなる(笑)CoffeeScriptであるやつ(–>, =>)
    • function,selfを書かなくて済むようになる
    • 引数は括弧を省略可能
  • ES6クラス
    • ES5まではclassなのにfunctionだしprototypeとか謎の宣言が必要だったがES6からclassが使えるように
    • extendsも使えるように

『ブラウザで今すぐES6を使おう』by林 優一氏 @frontainer

  • LIGのCTOやってる人
  • ES2015のブラウザ実装状況はIE10で10%,Chromeで65%程度
  • WebPack
    • Module Bundler require();したものの依存関係を解決してまとめる
    • webpackコマンドで1つのJSとして合体して出力してくれる
    • webpack.config.jsで設定を定義しておくとwebpackコマンドのみでいける
  • Browserify?
  • Loader
    • 読み込んだファイルに何かしらの処理をさせる
    • html-loader
    • babel-loader
  • babel-runtime
    • ファイルサイズに注意だが使った分だけ増える
  • frontplate
    • gulp + webpack + babelをまとめたやつを林さんが公開

『Years with JavaScript.Next』by dynamis氏 @dynamitter

  • 発表の様子
  • FF1.0の日本語担当で死んだ思い出
  • ECMAScript4はYahoo!とMSの猛烈な反対に合い陽の目を見ず
  • FirefoxOSでES6書こう
  • 佐藤徹平さん(@teppeis)イチオシ
  • FxDevCon キャンセル待ちだけど参加してね

QA

  • エディタ
    • vim, webstorm, atomとか。Visual Studio Codeも使いやすいかも
    • FirefoxのScratchpadが便利でオススメ
    • ES6に一番対応出来てるのはFirefoxじゃなくてEdge13(96%ぐらいES6対応が完了)
    • プラグインでESlintとか入れればどのエディタでも使える

「dots.2周年記念パーティ」に参加しました!

2015年10月30日(金)に行われたdots2周年記念パーティーに参加してきました! rubyのパパことmatzの話が聞けるということで楽しみにしてたイベントでした。 またdotsは渋谷のイベント・コワーキングスペースを2015年8月から運営しており、運営に関わっている人が知人でもあり、ちょこちょこ利用させて貰ってます。


※リアルタイム更新してました!

まつもとゆきひろ氏

  • PHPで出来てるdotsにあまり関係ないruby開発者のまつもとゆきひろです(笑)
  • スライドタイトルにデザイナってつけたのは渋谷でお洒落感出したかったからむりくり。
  • ひろゆきの方が圧倒的に多い名前で2ch作った人ですよね?って間違えられた。
  • 同じように西村博之氏がruby作った人ですよね?って間違えられたことがあるらしい。
  • プログラミングなんて教育出来ないですよねーとか言って嫌がられる。
  • 昔のスパコンは今のiPhone5と同じCPUパワー。
  • 言語が進化することで脳の限界で出来なかったことを出来るようになった。
  • 本質を理解すればバズワードではなくなる。
  • C10K/C100K問題
  • 変わらないものが大事。数学・アルゴリズム・コンピュータ基礎・基本プロトコル・人間・インタフェースの原理
  • matzが尊敬するデイブ・トーマス
  • 中学の時にプログラミングやったらコンピュータが思う通りに動いて「カワイイ」と思ったのが原点
  • basic言語の辛みからプログラミング言語に関心を持った高校生時代。Pascalの本とか。
  • 未来はコンピュータと直接インタラクションするようになる。スタートレックのコンピュータみたいな。
  • reactとか面白い。

パネルディスカッション

  • エンジニアの働き方とか
  • ビットジャーニー代表井原さん:なんで呼ばれた感満載で技術分かんない
  • VASILYのCTO今村さん:かっこいい写真
  • クラウドワークスCTO大場さん:娘と一緒に登壇
  • クックパッドCTO舘野さん:本日のモデレーター

未来に必要な技術とは?

  • スティーブ・ジョブズ見たらクズだった。クズさが必要by大場さん
  • ベースになる技術が必要
  • 好きなモノを突き詰めてる人に任せたいと思う

未来に繋がる考え方は?

  • 何の為に学ぶかをしっかり持つ。信念が大事
  • 仕事してても好きな仕事を優先してたまつもとゆきひろさん。クズ感出てきましたねby大場さん
  • 人の能力の総量は桁が違うということはない。あとはパラメータの問題。なので何か1つのことに振る方が集中出来る。byまつもとさん

どう働くべきなのか?

  • エンジニアが得意なことを1つの会社が囲うのは勿体無い。会社もオープンソース化すべき。by井原さん
  • 毎朝保育所に子供をデプロイ(笑)して出社するとか、全力出せる時間が少なくなる。生活も子供中心。労働のオープンソース化までやりたいby大場さん
  • 朝来ないからと言って全力を出せないとは思っていない信頼感がある。エンジニアはパフォーマンスを出せる時間に集中することby今村さん

今後のオープンソースの動向

  • 欲しいOSS
    • クラウド・ビッグデータ等のOSSは既にあるよね。hadoop,sparkとか。2世代目に凄いの来るかも。byまつもとさん
    • meteorとかactive value?コンセプト。リアルタイムでデータを出力し続ける。データバインディングに革新が起きればSPAが画期的に変わってくる可能性。byまつもとさん
    • 口に出すの恥ずかしいソシャゲを登壇中にやるまつもとゆきひろさん(笑)
    • TreasureData, Elasticsearchとか、更に運用を楽にしてくれるOSSがもっと出てくるかも。by大場さん
    • hashicoop製品使い始めたところ。決定版はまだまだなので欲しい。マーケティングオートメーション的なOSSとか。意思決定を支えるOSS。サービスレイヤーに近いOSS。by今村さん
    • kaizen platform的なものとかあるけどミドルウェアが違うので各社自社で実装している。by舘野さん
    • 製品を半オープンソースにして製品のコードを使っている会社のエンジニアがプルリクエスト送ってくるみたいな。企業のありかた。レベニューシェアとか。by井原さん
  • 注目される開発コミュニティ
    • 黎明期のOSSコミュニティは自身の影響度が大きいのでエンジニアとしてはやりがいがある。by舘野さん
    • 日本人がいないコミュニティに入ると国際化対応とか日本人しか分からないところで貢献できるよねby大場さん
    • 開発コミュニティの敷居を下げるような活動とかOSSとかが必要。最初の一歩を手伝うような活動とかby今村さん
    • コードレビューすらしていない会社もたくさん。OSS以前の問題で底上げが必要かもby井原さん
    • 大体動くけど隙があるOSSは他の人がコミットしてくれる。OSSに必要なのは炎上力だ!byまつもとさん
    • DHHとか敢えて目立つ発言して炎上させてる節がある。あれもOSS運用力の一つかもby舘野さん
    • コミュニティへの帰属意識が変わってきている。github時代は様々なOSSにコミットするように変わってきているbyまつもとさん
  • 質問
    • 好きなことに全振りすれば良い。サポートにはサポートの、新技術を開発する人にはその人の意味があるbyまつもとさん
    • ダブルクリックというユーザーインターフェースが悪い(笑)by今村さん
    • ハードウェア系もArduinoから始まるオープン化で組合せでやりたいことが出来るようになってきたby舘野さん
    • toC向けのハードウェアサービスレイヤのイノベーションはこれから起きるんじゃないか。mrubyとかも2020年とかにもっと爆発的に広まるんじゃないかby舘野さん
    • 新しいことが生まれる時は未知との遭遇から。ハードウェアエンジニアとウェブエンジニアだと摩擦が起きるけどそれを乗り越えたらイノベーションがbyまつもとさん
    • 時間の使い方や優先順位を伝えるのも重要だがノンバーバルな部分が伝わるのでちゃんと朝・晩は一緒に娘と飯を食うように自分にルールを課したbyまつもとさん