comix

ジャンプみたいなブログになりたい。

(私的)GoのWebAPI開発における現状: 論理編

この記事は?

インディー開発をしたり、本を読んだり、勉強会に参加したりして、GoのWebAPI開発における自分なりの実装パターンが固まってきたので現状を整理します。

具体的にはORM、フレームワーク、パッケージ構成あたりの話。

ある程度アンチパターンを踏んできてますが、僕自身プロダクションレベルでのGo開発経験がバリバリあるわけではないので、ここは間違ってるぞ!とか自分はこうしてる!など(建設的な)マサカリや大歓迎でございます。

tl;dr

前提

WebAPIの規模

以下のような小〜中規模程度のJSONで話すWebAPIを想定。

  • APIの数は20本前後
  • シンプルなCRUDベースのAPIが多いが、ちょっと複雑なリレーションやビジネスロジックも多少あり。
  • 外部システムとの連携は(システム内の)DBがメイン。しかし、Push通知など外部のAPIと連携する箇所も。

ちなみにインディー開発中心なので、ミッションクリティカルなシステムであることは想定してません。とは言え、ある程度の規模までプロダクションレベルに耐えうるものを想定。(と言うより、そこを目指しています…!)

テクノロジースタック

このあたりは好みもあると思いますが、僕は以下の構成でやることが多いです。

  • Alpine Linux
  • NGINX
  • Supervisor
  • Go 1.11系
  • MySQL 5.7系

上記の環境をDockerで作って開発してます。hot reloadの仕組みを入れるために fresh などを使うのはありだと思いますが、僕はIDEとして GoLand を使っており、ファイル保存時に自動でビルドが走るようにしてます。*1

なお、環境というかインフラはAWSやHeroku、VPS想定。GAE/GCPだとDatastoreを使うことが多いと思うので、また違ってきそう。*2

方針

銀の弾丸はないので、何が正しいか正しくないかは状況次第ですが、アーキテクチャやライブラリの選定基準や開発方針としては以下の2つを意識してます。

  • やりすぎない(オーバーエンジニアリングしない)
    • done is better than perfect!
  • 郷(Go)に従う

現状

前置きが長くなりましたが、ここからGo界隈でよく盛り上がるトピック別に現状を書いていきます。

ORM関連

いろいろ使いましたが、最終的に sqlx に落ち着いています。sqlx自体はORMというよりは database/sql パッケージをいい感じに使えるようにしたライブラリ。database/sql パッケージで頑張るのがGoっぽいとは思うのですが、structへのマッピングを自分でやるのは大変なので、メンテもきちんとされているsqlxを使うようになりました。

ActiveRecordに慣れている人は GORM もアリだとは思うのですが…と言うか自分も最初使ってました。しかし、エラーハンドリングが重要なGoの世界観と合わないと思ってるのと便利な分コードが複雑なので、慣れてきたら薄いライブラリを使うのがいいかなと思ってます。

ちなみに、スキーマ管理は schemalexsqldef がおすすめです。MySQLならschemalexが枯れてて安心感があります。

その他の選択肢

  • xoxo
    • DBから直接Goのモデルを生成してくれる便利なやつ。
  • upper/db
    • それでもどうしてもActive Recordっぽいものを使いたい人向け。

フレームワーク関連

いわゆるWAFは使ってません。フレームワークを採用するのも良いと思いますが、個人的には余計なDSLを覚えずに可能な限りGoだけで書きたいので、現状は使ってません。RubyにおけるRailsみたいなデファクトスタンダードとなるフレームワークが誕生すれば、また別かもしれない。

とは言え、全部自前で実装するのはつらいので、ルーティングは Gorilla/Muxミドルウェアnegroni を利用しています。JSONではなくHTMLをレンダリングするような場合だと、これだけだと辛いかもしれませんが、JSON形式のWebAPIならこれで充分かなと思ってます。

その他の選択肢

  • go-json-rest
    • フレームワークと言うよりルーティングとミドルウェアのライブラリ集+JSONがいい感じに扱えるライブラリって感じです。コードも読みやすいので、最初の選択肢としてはアリかなと思ってます。
  • echo
    • フレームワークを使うなら、パフォーマンスが良好&コミュニティも活発なのでこれが一番いいかな〜。 *3 GAE用のドキュメントが分かりやすかったので、GAEを利用する時にも良いかもしれません。

パッケージ構成

個人的にはGoに慣れてきて、一番困るのがこれかなと思ってます。フレームワークを利用していればまだいいのですが、使ってないと自由過ぎて困ります。ですので、これは今も試行錯誤していますが、最近はいわゆる?レイヤードアーキテクチャ+ポートパターンを採用しています。*4

概要図

こういうやつです。

レイヤードアーキテクチャ+ポートパターン
レイヤードアーキテクチャ+ポートパターン

基本的に通常のレイヤードアーキテクチャのように上から下に流れるようにしてる(下位のレイヤは上位のレイヤに依存しない)のですが、ドメインレイヤーにインターフェイス(ポート)を置くことで、ドメインレイヤだけどこにも依存しないようにしてます。

なお、破線部分については後述します。

フォルダ構成

こんな感じでやってます。

.
├── Gopkg.lock
├── Gopkg.toml
├── application
│   ├── article.go
│   └── user.go
├── config
├── domain
│   ├── article.go
│   └── user.go
├── infrastructure
│   ├── db.go
│   ├── article.go
│   └── user.go
├── main.go
├── presentation
│   ├── controller
│   │   ├── handler.go
│   │   ├── article.go
│   │   └── user.go
│   └── view
│       └── render.go
└── vendor

各レイヤの責務

僕がよく使うRailsCakePHPのようなMVCモデルと比較しながら説明していきます。

プレゼンテーション層

MVCで言うコントローラーとビューにあたる箇所。コントローラーの責務はリクエストを受け取り、それをアプリケーションレイヤで利用出来る形にしてアプリケーションレイヤを操作すること。そして、その結果を(ビューと連携して)レンダリングすること。ここは極力コード量が少なくなるように意識しています。ビューの責務はレンダリングに関すること全般。ただ、JSON形式のWebAPIだとコントローラー側でJSONを出力するだけで事足りることが多いので、あんまり書かないことが多いかも。僕は汎用的なレンダリングのロジックだけ書くことが多いです。

アプリケーションレイヤ

いわゆるサービスクラスっぽい役割をする箇所。アプリケーションレイヤの責務はドメインレイヤとインフラストラクチャレイヤのビジネスロジックを操作すること。ちなみに、DBのトランザクションはここで制御しています。

ドメインレイヤ

みんな大好きモデルを扱う箇所。ドメインレイヤの責務はビジネスロジックの実装を持つことですが、技術的な実装(直接的なDBの操作やPush通知の送信など)は行ってません。また、先述の通り通常のレイヤードアーキテクチャとは異なり、ドメインレイヤとインフラストラクチャレイヤとの間にインターフェイスを設け、技術と実装を分離するようにしています。DBのモデル(struct)はここで定義していますが、インフラストラクチャレイヤで DTO を定義することもあります。*5

インフラストラクチャレイヤ

技術的な実装を扱う箇所。インフラストラクチャレイヤの責務は直接的なDB操作(SQLの実行)やPush通知の送信など技術的な実装を行うこと。通常のレイヤードアーキテクチャでは、インフラストラクチャレイヤはどこのレイヤにも依存しませんが、技術と実装を分離するために必要に応じてドメインレイヤのインターフェイスに依存させています。

オレオレルール

  • 厳密なレイヤードアーキテクチャでは直下のレイヤにのみ依存すると思うのですが、2個下のレイヤに依存するのはある程度OKにしています。
    • これが上記概要図の破線の意味です。
    • 理想は直下のレイヤにのみ依存させるのがベストだと思うのですが、現実問題として厳密にやりすぎると辛いときがあるのである程度は許容してます。
      • ただ、3個下は流石にダメ!(明らかに責務を越えてる)

なぜレイヤードアーキテクチャを採用しているのか?

個人的にはGoで小〜中規模のWebAPIを開発する時にクリーンアーキテクチャはちょっとtoo muchかなと思っています。*6 とは言え、薄いライブラリしか使っていないとMVCモデルでは少し辛いケースが多く、また、テスト観点から技術と実装を分離したくなることが多いので、このようなアーキテクチャにしています。ですので、逆に言うと、フルスタックなフレームワークやORMを使っている場合はMVC(+サービスクラス的なもの)で充分なケースも多いと思います。また、テスト観点だけであれば、インフラストラクチャレイヤがDBのみの場合は、インターフェイスを置かず通常のレイヤードアーキテクチャでもいいかなと思ってます。もちろん、単体テスト時のDBアクセスは低速でアンチパターンですが、RailsCakePHPをこれまで使ってきた身からすると、そこまで違和感ないので。

その他の選択肢

  • 縦割りパッケージ構成
    • レイヤではなく、機能で分けるパターン。具体的にはuser packageやarticle packageを作るパターン。
    • microservies化を想定しているならアリかなと思います。
    • Goっぽいなと思いつつ、個人的には共通処理の扱いが難しいなと思ってます。

パッケージ管理ツール

Go1.12から vgo が正式導入されますが、3rd partyの対応状況を鑑みると、まだ(2019年1月現在)は dep が無難かなと思います。とは言え、今後はvgoを使うのが主流になっていくはず。

最後に

書いてみて、コードがないと分かりづらい気がしたので次はコード編を書いてみたい。その時は今回書けなかったログとかエラーハンドリングのことも書くぞ。

あと、冒頭にも述べましたが、Goは導入事例が増えてきたとは言え、RubyJavaに比べると枯れておらず、ベストプラクティスがそこまで世に出回っていないので、自分なりの考えや現状を書くことで誰かのためになったり、議論のきっかけになったりすればいいなと思ってます。*7

2019年もGoGo!

参考サイト

脚注

*1:単純にMakefike経由でビルドしているだけ。

*2:『Clean Architecture 達人に学ぶソフトウェアの構造と設計』でも言及されている通り、技術的な実装に引っ張られないアーキテクチャが本当は理想なのでしょうが…。

*3:ただ、フレームワークはそんなにたくさんは試していないので、他にもっと良い選択肢があるかもしれない。

*4:この用語は『pospomeのサーバサイドアーキテクチャ』を参考にしています。

*5:このあたりは現在進行系で悩み中です…リポジトリパターンやDAOをどうやって使うとか…難しい…。

*6:もちろん開発するプロダクトや個人/チームのスキルにも依るとは思います。

*7:翻って、そこからまた自分が成長出来ればいいなとこっそりと思ってます。

2018 Retrospective

みんなが2018年の振り返りをやっているので、僕もやってみよう。

どうでもいいけど、昔はみんながやってることはあんまりやらないタイプだったのに、最近流行っているものをやっていないと、自分の感性や感覚がズレて来てるんじゃないか?と思って不安になる。知らんけど。

2018年のよかったこと

  • 7回登壇することができた!
  • Podcastに初めて出演した!
    • 恥ずかしくてまだ自分では聴いていないけど、何人かの人によかったよと言ってもらえたのでよかった! takattata.github.io
  • 南山大学公開講座が最高of最高だった!
  • 30冊ぐらい本を読めた!
    • 今年は読書を習慣付けるために1スプリント(2週間)に1冊本を読むというのにトライしたけど、波はありつつ数はクリア出来たのでよかったかな。

突然の2018年読んで良かった本ベスト3

第3位: 『プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化』

第2位: 『NETFLIXの最強人事戦略 自由と責任の文化を築く』

第1位: 『ナナメの夕暮れ』

2018年のわるかったこと

  • あんまり技術的な挑戦が出来なかった…
    • 特に後半はとあるプロジェクト(これはもうすぐお話出来るのでもう少し待ってけろ!)で忙殺されて、成長実感が関西人くらい薄味。あかん。
    • Gopher道場に参加したりGoでインディー開発をしたりしたぐらいかなぁ。
  • インディー開発のリリースが1つだけだった…
    • しかもチームのやつだけなので、個人では何も出せなかった!これまたあかん。
    • というわけで年末年始は早速インディーやってます。
  • 相変わらず英語を学んでいない…
    • 先月あたりにflamingoデビューしたけど継続していない。まじであかん。
    • 石原さとみさん!僕に英語を!教えて!
  • 海外旅行に行けなかった…
  • というか今年は国内もあんまり行けなかった!お金を貯めないと〜!
  • 来年は海外のカンファレンス行きがてら、観光とかしたい。

【番外編】2018年のプライベートなこと

  • 凄い勢いでBリーグにハマっています🏀
  • 引っ越しが決まりました!

2019年の目標

  • 大きなカンファレンスで登壇(出来るような成果を出す)
  • 英語の技術書をスラスラ読めるようになる
  • インディー開発2本以上リリース
  • 本を最低でも12冊以上読む
  • 引っ越しを無事終える

全体的な抱負で言うと、今年は手広くいろんなことに手を出し過ぎた感もあるので、 来年は少しわがままをテーマに自分が本当にやりたいことだけをやっていきたい! (仕事はちゃんとやるという前提)

ひとこと

今年も大変お世話になりました〜。来年も再来年もよろしくお願いします!

南山大学人間関係研究センターの公開講座に行ったら最高の体験学習が出来た

f:id:itosho525:20181124014917j:plain

はじめに

5億年振りにブログを書くぞ。

今年に入ってから、スクラムマスターをやらせてもらったり、ここ最近はエンジニアリングマネージャーのお仕事をしたりしている。そういう役割を任されるうちに、会議のファシリテーターや1on1のメンターをする機会が増え、組織開発って面白いかもと思い始めた。

しかし、自分の力不足を痛感することも多く、会議に参加している人やチームメンバーに対して、コスト(時間)に見合った価値を提供出来ていないのでは?と思っていた。

そんな中、ヘイシャの人事部長からこんな情報をもらった。

こりゃ行くしかねぇ!って言うか、課題を感じているのに放置するのとかクソダサいし、チームメンバーに対して無責任だし、飛ばねぇ豚はただの豚じゃんかっこわる!と一念発起し、先週末受講してきたので、今回はそのレポートを書きたいと思う。

ちなみに、組織開発と聞くと仰々しいイメージがあるかもしれませんが、普段の仕事をする上でもとても役に立つ講座だったので、エンジニアの方にもめっちゃオススメです。

南山大学人間関係研究センターとは?

僕は組織開発の専門家ではないので、詳細な説明は公式のHPをご覧いただければと思いますが、ラボラトリー方式(自分や他者、グループを成長させるために行動を試みる場)の体験学習という"プロセスから学ぶ学習方法"の研究と実践を行っている教育研究機関です。

その中で、いくつかの公開講座が行われており、今回僕は「人間関係講座(グループ)」という講座を受けました。

ちなみに、恥ずかしながら僕は受けるまで全然知らなかったのですが、南山大学はこの分野で国内トップクラスの権威があるそうです。

どういう講座なのか?

「人間関係講座(グループ)」という名前の通り、グループの中での人間関係について学んでいく講座になります。もう一つ「人間関係講座(コミュニケーション)」という似たような名前の講座があるのですが、こちらはグループよりももう少し小さい単位(1〜2人程度)での人間関係を学ぶ講座のようです(こちらも今度受けてみたいな〜と思った)。

講座の主な目的(学習目標)として…

  1. グループの中で他者と関わる自分の特徴に気づく
  2. コンテント」と「プロセス」とは何かを理解する
  3. グループの中での人間関係(グループプロセス)に目を向ける重要性に気づく

の3つが挙げられています。

こちらも詳しくは公式の講座案内をご覧ください。

当日の講座内容について

講座は土曜日・日曜日の2日間行われます。具体的には、

  1. グループを組んで様々な課題に取り組む
  2. その振り返りをグループで行う

という流れを繰り返しながら、進んでいきます。実習やワークショップばかりではなく、所々小講座という形で理論的の話もしてもらえます。朝から夕方までみっちりやるので、とても濃密です。

学んだこと

メモレベルですが、僕はこんなことを学びました(間違っていたらごめんなさい)。

  • グループで何らかの仕事や課題に取り組むと、どうしても課題の内容そのものに夢中になってしまう。
    • 課題の内容そのもののことをコンテントと呼ぶ。
  • コンテントに夢中になると、他者の気持ちやお互いの関係に目が向けられない。
    • 他者の気持ちやお互いの関係のことをプロセスと呼ぶ。
  • コンテントは氷山の一角で、プロセスはコンテントの下に潜んでいる。
  • プロセスが上手くいかないと、グループのコミュニケーションがうまくいかず、コンテントの結果にも影響する。
    • コンテントが上手くいかないと、プロセスのチェックも疎かになり、悪循環に陥るなと思った。
  • プロセスにはタスク・プロセスとメンテナンス・プロセスの2種類がある。
    • タスク・プロセスはコンテントに直接働きかけるもの。
      • 例: 時間管理、目的や手順の明確化、アイディアをまとめるetc
      • 比較的観測可能。
    • メンテナンス・プロセスはコンテントに間接的に働きかけるもの。
      • 例: 雰囲気、関係性、個々人の様子etc
      • 目に見えないものが多い。
  • 「売上は全てを癒す」という言葉は、コンテントが上手く言っているとプロセスに多少問題があっても気にならなくなることなのかなと思った。
    • でも本当に全てを癒しているのかは怪しいなとも思った。
  • リーダーとリーダーシップは違う
  • リーダーシップとは、コンテントを達成するための過程で、影響を与えている人と受けている人の関係性のこと。
  • リーダーシップはタスクプロセスの中に位置づけられている。
  • リーダーシップにはP機能とM機能がある
    • P機能は情報や意見を求めたり、課題を推進したりといったコンテントに直接働きかけるもの。
    • M機能は雰囲気を和ませたり、励ましたりといったメンテナンス・プロセスを改善するもの。
  • 両方出来る人がいればそれはそれで素晴らしいが、人には得意不得意があるので、グループでリーダーシップの役割分担をするのが良い。
    • 分有型リーダーシップという言うらしい。
    • サーヴァント型リーダーシップはGoodだが、カントリークラブマネジメントはBad。
  • 実際にフィードバックを受けないと、相手の気持ちなんか分からない。

当然ですが、これ以外にもたくさんの学びがありました。

感想

というツイートを終わった直後にしたのですが、本当に最高でした。とにかく実習が多いので、知識が体に取り込まれる感じというか、体で学んでる感覚がありました。

特に僕は振り返りの重要性を改めて感じました。仕事では今もそれなりに振り返りに力を入れていると思っていたけど、どちらかと言うと、タスク・プロセスの改善ばかりやっていたなという反省があり、これからはもっとメンテナンス・プロセスにも目を向けていこうと思いました。そして、そのためには、もっと個人からの個人へのフィードバックをしていかないといけないなぁと痛感。他人の分かった気になってる状況ほど厄介なものはない。

あと、全国津々浦々から様々なバックグラウンドを持った方が集まって来ているので、そういう人たちと触れ合えるのも単純にとても刺激がありました。もっと外に出ていかないと。

ただ、めっちゃ疲れるので、そこだけは予めご注意ください。

でも、とても心地よい疲れだったな。

ちなみに、僕がよく言われたこと

何度もフィードバックを受ける機会があるので、自分の特性を改めて認識したり、発見したりすることも出来ました。初対面の人からも普段よく言われることを言われると、本当そうなんだろうな〜と認めざるを得ない。というわけで、僕がよく言われたことを晒してみます。

  • 最後まで諦めない
  • 落ち着いている
  • ムードメーカー
  • 裏のリーダー
  • フラットに物事をみてる

耳障りの良い言葉が多いですが、それは初対面という関係性の中で言ってもらったことなので、ある程度忖度してもらっていると思います。長所と短所は表裏一体だと思うし、上記の特性も場合によってはマイナスに作用することもあると思うので、気をつけよう。

おわりに

というわけで、本当にオススメです!最後にお金を話をするのもアレですが、これが1万円ちょっとで受けられるのは本当にお得だなと思いました。人それぞれ感想は違うかもしれませんが、少なくとも受けて損はないと僕は言い切れます。

あと、受ける前にこちらの本を読んでおくと、講座の内容がより理解しやすいと思います(これも上述の人事部長に教えていただいた)。

ちなみに、受けるとこんな修了証をもらえます。

f:id:itosho525:20181124014922j:plain

【翻訳版】Docker, Inc is Dead

What's this?

Docker, Inc is Dead の翻訳記事です。

ご本人の許可は取っていますが、僕が英語ペラペラではないため、読み辛いのはもちろん、一生懸命訳してはいますが誤訳・ミスリードなどあるかもしれません。

ですので、100%正確な内容を把握したい方は原文をお読みください。また、ここ間違ってるよ!ニュアンスが違うんじゃない?などありましたらお気軽に(優しく)コメントいただけると幸いです。

Docker, Inc is Dead / Docker社は死んだ

Dockerにとって、2017年は非常に辛い1年だったと言っても過言ではありません。Uberを除いて、より活用され、賞賛され、十分に資金提供を受けたシリコンバレーのスタートアップの中で、Dockerが2017年に行ったような悪手を打ったスタートアップは思い浮かびません。人々は2017年を、ソフトウェアの偉大な一部分であるDockerが悪いビジネスのやり方によって台無しにされ、翌年に終わりを迎えた1年だったと振り返ることでしょう。この記事はDockerがどのようにして良くない方向に進んでしまったか、そして、それを修正しようとする努力があまりにも少なくまた手遅れであった様子を外部から見た回顧録です。

Docker is Good Software / Dockerは良いソフトウェアである

言うまでもなく、Dockerはソフトウェア開発に革命をもたらしました。cgroupsや名前空間、そしてプロセス分離などのLinuxのプリミティブな技術を利用して、それらを単一のツールにまとめたのは素晴らしい功績です。2012年に私は開発環境のポータビリティをより高める方法を見つけようとしていました。Dockerの登場により、開発環境はシンプルでバージョン管理可能なDockerfileになりました。Dockerfileにより PackerやVagrant、そしてVirtualBoxなどのたくさんのインフラツールからDockerに移行しました。DockerのUIは実際かなりよいものです!Dockerはたくさんの応用が出来る良いツールです。Dockerを作った人々は、自分たちが開発したツールをとても誇りに思うべきです。

Docker is a Silicon Valley Darling / Dockerはシリコンバレーの寵児である

Dockerの初期の成功はそれを取り巻く大きなコミュニティを築く会社になることに繋がりました。その初期の成功は資金調達に次ぐ資金調達を促しました。Goldman SachsやGreylock Partners、Sequoia Capital、そして、Insight Venture Partnersのような名立たる投資家がDockerに札束を与えるために列をなしました。現在まで、Dockerは総額2億4,200万ドルから2億5,000万ドル以上の資金を調達しています。

しかし、資金が十分にあり、何が何でも勝とうとしていた2010 年代のスタートアップと同様に、Dockerはいくつかの人事的なミスを犯しました。Dockerは自身の成長にともなって何人かの不快な人を保護しました。これにより私はDocker社のリーダーシップに対して、嫌悪感を感じるようになりました。プロダクトは品質を維持していますが、会社のそのような振る舞いは一切言い訳出来ません。悲しいことに、これはシリコンバレーによくあるケースであり、変えていく必要があります。

Kubernetes Dealt Damage to Docker / Kubernetesの扱いがDockerにダメージを与えた

Kubernetesの登場により、Dockerの運命(悲運)は加速しました。Dockerはオープンソースコミュニティで人気のオーケストレーションツールであるKubernetesの扱いが上手くありませんでした。Dockerが認めたオーケストレーションツールは、自身が持つ(Kubernetesの)競合製品であるDocker Swarmだけでした。この決定はKubernetesが最初にDockerコンテナを好んでいたのにも関わらず下されました。非公式な情報では、Docker Captains は、2017年初頭にKubernetes関連の記事やミートアップ、そして、カンファレンスがDockerによって批判されたことを確認しています。

オースティンでのdockercon17はこの Kubernetes-less を信念にして開催されました。その後、dockercon EU 17では突如DockerはKubernetesに全力を尽くすことを決めました。この突然の変化は、Kubernetesが盛り上がり間もなく優勢になろうというところに参画することを狙ったものでした。これはKubeConとCloudNativeCon North America 2017のスポンサーとブースを持っていたことによって、更に心象を悪化させました。

Moby?

Mobyが発表された4月のdockercon17で、Dockerが何をしているのか誰も理解出来ませんでした。MobyはDockerプロジェクトの新しい上流のものとして説明されています。しかし、Mobyの公開は事前にアナウンスされていませんでした。Solomon Hykesのdockercon17での発表を受けて、GithubでDockerからMobyへのドラスティックな変更が起きたとき、何百万の声が恐怖で叫んだかのようでした。このドラスティックで思慮の浅い考えにより、巨大なリポジトリの名前変更は内部で問題を引き起こし、Githubスタッフによる手動での対応を必要としました。

変更がうまく管理されなかっただけでなく、メッセージも十分に考慮されていませんでした。これは謝罪に繋がり、後に手書きによる変更の説明を求められました。これは既に雲行きが怪しいコンテナ分野とDocker(Moby?)のエコシステムを更に混乱させました。Moby公開の扱いはこの業界で働く人々を困惑させ続けています。これによりDockerブランドが傷つけられた可能性もあります。

The Cold Embrace of Kubernetes / Kubernetesの冷めた受け入れ

Dockerの遅く、気まずい土壇場でのKubernetesの受け入れは、差し迫った崩壊のサインです。Docker Swarmが死んだかどうか尋ねられ時、Solomon Hykesは以下のようにツイートしています。 "DockerはKubernetesとSwarmの両方をファーストクラスの市民として手厚くサポートし、相互作用を与えます。オープンさと選択は全ての人にとって健全なエコシステムをつくりだします。" ここでの問題は、Docker Swarmは完全に出来上がっているわけではないので、そのような状況からは程遠いということです。Docker Swarmのプロダクトチームと一握りのオープンソースのコントリビューターだけではKubernetesのコミュニティに追いつくことが出来ません。DockerのUIと同様にKubernetes UIはかなり優れています。これはコンテナ分野において、Dockerが取るに足りないコンサルティング会社であることを認めているようなものです。

Conclusion / 結論

Dockerの真の問題は一貫したリーダーシップの欠如にあります。組織の中で一人の人物を中心にした戦略的なフォーカスがあったようです。この人物は会社の中核からはかなり遠のきましたが、依然として籍を置いています。会社は再編成を行い、エンタプライズにフォーカスすることになりました。この変化はDockerの投資家にとって理解できるものです(結局会社は信託の責任を負っています)。しかし、この変化は熱狂的な成功によってもたらされたブランドが持つクールな要素を減らすことになります。"偉大な文明は殺されるのではなく、自殺するのだ。"と言われますが、Dockerはまさにそれと同じことをしました。

Bonus: Conspiracy Theory / おまけ:陰謀論

私はTwitterで2017年というDockerの厄介な時期について持論を展開しました。Dockerは自身の会社の終わりが近いことを知っている可能性があります。組織の変更により、Exit予定(買収による可能性が高い)が明らかになり、会社の技術的な中核チームはいくつかの変更を優先しました。CNCF(訳注:Cloud Native Computing Foundationのこと)に containerd に寄贈し、MobyをDockerの上流にして、Kubernetesを受け入れることで、Dockerの人々が行った良い仕事は不朽のものになります。これにより、Dockerの従業員によってなされた技術的な進歩がライセンスによるロックを心配することなく、 OracleMicrosoftのような大規模な会社がDockerを買収することが出来るようになります。これはソフトウェアと企業に両方にとって、ベストな世界です。言うまでもなく、2018年はDockerにとって興味深い年になるでしょう。

Eureka English Evening に参加してきました

f:id:itosho525:20170828002941j:plain

はじめに

先日、Eureka English Eveningというイベントに行ってきました!ブログ枠で参加させていただいたので、当日の様子を簡単ではありますがレポートさせていただきます。

どういうイベントなの?

詳細は下記のconpassのページをご覧いただければと思いますが、端的に言うと、Eurekaさんが企画している技術英語を学ぶための勉強会で、今回はコードレビューがメインのお題でした。

eure.connpass.com

当日の流れ

Presentation

最初はコードレビューで役に立つ単語やフレーズの紹介をしてもらいました。PR(Pull Request)のコードがOKな時、NGな時などシチュエーション別に説明してもらったので分かりやすかったです。

ただ、実はちょっと遅刻してしまったので、最初のほうは聴けていません…。ごめんなさい。

Practice

続いては実践編ということで、練習問題用のPull Requestをグループに分かれて、それを英語でレビューするというグループワークをやりました!5問ほどあり、書いたことのない言語のコードもあったので、英語以前の問題もあったのですが、とても勉強になりました!

※ちなみに事前に英語力のアンケートをとっており、適切にグループ分けをしてもらっているので安心でした。

Performance

少し休憩を挟んだ後、最後は会話練習ということで、再度グループワークでYES / NOゲームを行いました。 お題が定番の動物からプログラミング言語Java, PHP, Ruby, Pythonなど)、OS(iOS, Windows, Linux, Androidなど)など多岐に渡り、面白かったです。

感想

英語系の勉強会は初めて参加したのですが、とても愉しく勉強になりました!よくある技術系の勉強会だと実際に参加しなくても、後からスライドをみればある程度事足りることも多いのですが、やはりワークショップ系の勉強会は実際に参加しないと学べないことがたくさんあるので、そういう意味でも参加して良かったです。

ただ、自分の英語力の低さを痛感しました(一緒にグループワークをした方にはご迷惑をお掛けしたかと思います…)。個人的にはOSSにコントリビュートしたり、OSSを公開したりする際に英語力が必須になるので、そういったことがもっと出来るようになりたいという想いが今回参加したモチベーションの一つだったのですが、もっともっと英語を勉強しなくてはと気持ちを新たにすることが出来ました。頑張るぞ〜。

素敵な機会を与えていただいたいEurekaさん、本当にありがとうございました!第2回目があればまた是非参加させていただきたいと思います!

当日の資料

www.slideshare.net

2016年をフリカエル

あけましておめでとうございます。今年もやらしくお願いします。 そういえば、去年の振り返りをしていなかったので今日は勝手に思い出話に花を咲かせたいと思います。

1月

仕事の引き継ぎでめっちゃ忙しかった記憶。確か最終日までデプロイしてましたね。

本当にお世話になりました!

2月

というわけで、6年近くお世話になった会社を辞めて、転職しました。

itosho525.hatenablog.com

もうすぐ1年経つので振り返り等はその時書きたいと思いますが、いまのところ愉しく働いています。

あ!あと、ディズニーのミラコスタに初めて行きました。お金貯めてまた行きたい。

3月

正確には2月ですが、うるう日限定のWebサービス PRESENT4229 をリニューアルしました。 2012年に初めてつくって、2016年が2度目の運用だったのですが、予想遥かに越える反応をいただいて、本当につくってよかったなと思いました。引き続き4年後(もう3年後)をお楽しみに。

リニューアルの顛末はこちら。

speakerdeck.com

4月

結婚式の準備でめっちゃ忙しかった。徹夜で動画編集しまくってた。 この頃はIntelliJ製品(RubyMine&PhpStromを愛用している)よりAdobe製品を触っている時間の方が長かったな〜。

5月

30歳になった!

パワプロ2016を買ってもらって未だにマイライフやっています。

6月

結婚式を挙げました。

準備とか色々大変だったけど、やってよかったなーと思います。 YDDしながら夫婦仲良くやっています。

YDDについてはこちら。

speakerdeck.com

7月

結婚式の燃え尽き症候群で全く何もしていない。

8月

伊藤直也さんの一人CTO Nightのレポートがめっちゃバズった。書いてよかった〜(こなみかん)

itosho525.hatenablog.com

あとは乃木坂ちゃんのライブに行ったりしてました。

9月

北海道に行ったり、ディズニーシーに行ったり。 東京以外なら札幌に住みたいという思いを強くした。

10月

会社の仲間と Kocoromo というAndroidアプリをつくりました。 (僕はサーバーサイド担当)

iOSはもうしばらくお待ちください。

そして、Mr.Childrenの武道館公演を観に行ったのですが、まさかの最前列でした。 後世にまで語り継ぎたい一生の思い出。

あと、開発合宿にも行った!

rei19.hatenablog.com (一緒に行った会社の仲間のブログを拝借)

11月

PHPカンファレンスにスタッフとして参加しました。 基調講演の司会をするという「貴重」な機会をいただきました。

来年は発表したい!

12月

箱根の温泉でのんびりして、一年の疲れをとりました。

感想&今年の抱負

プライベートではやっぱり結婚式が一番の思い出かな〜。正直当日ってあっという間に終わっちゃうんだけど、それまでの準備が何だかんだ楽しかったし、妻との絆も深まったように思う。

エンジニアとしてはその瞬間その瞬間では全然何もやってねー!って感じで結構焦りを感じたり、ダメだな〜なんて思ったりしてたのですが、こう振り返ってみるとまぁまぁ頑張ったような。 でも、やりたいことの半分も出来ていないので、今年はもっともっと頑張りたいな。

というわけで、今年も来年こんな風に振り返り出来るように平和に元気にたのしく暮らしたいです。

私的アイドル楽曲大賞2016

こんばんは。タモリです(●_●)

Mステのスーパーライブを観てたら、AKB48に知らないメンバーがいて、びっくりしました。 僕が疎くなったのか、AKB48の凋落が始まっているのかは分かりませんが、それでも今年もたくさんのアイドルと音楽が生まれたので、恒例?の独断と偏見に基づくアイドル楽曲大賞を発表したいと思います。

私的アイドル楽曲大賞2016

時間がないのでTwitterリスペクトで各曲140字以内でまとめたいと思います。

第10位:「エルナト」柚希未結

www.youtube.com

妄想キャリブレーションである柚希未結(当時は神堂未祐奈)さんの初オリジナル曲です。僕は神堂未祐奈さんがいた頃の妄想キャリブレーションが一番好きだったので贔屓目があるかもですが、もっと売れてもいいのになぁと思います。

第9位:「かちとばせ!栄光のレインボー」ベボガ!(虹のコンキスタドール黄組)

www.youtube.com

ベボガ!と言えば、ぺろりん先生が有名だと思いますが、楽曲もなかなかいい。特に落ちサビがエモい。アイドルが好きなプロ野球選手の登場曲に使われたら面白いのになぁ。虹コンもそうだけど、今最も勢いがあるアイドルグループでは?

第8位:「きっかけ」乃木坂46

www.youtube.com

最初聴いた時、AメロとBメロの歌詞がめっちゃMr.Childrenっぽいなと思ったら、後日桜井和寿さんがカバーしてて、合点がいきました。何かに悩んだり迷ったりした時に聴くとミスチルばりに沁みる一曲。

第7位:「アンバランスアンブレラ」妄想キャリブレーション

www.youtube.com

我らが妄想キャリブレーションの2ndシングル。正直、メジャーデビュー後のEDM路線は好みじゃないんだけど、この曲は流石ソニーミュージックというクオリティで結構ヘビロテしました。ただ、僕はやっぱり利根川サウンドが好きかな。

第6位:「Summer Wind℃-ute

www.youtube.com

僕は鈴木愛理さんが日本でNo.1のアイドルだと思っていて、春のツアーでこの曲を生で観て、改めて鈴木愛理をもっと世の中の人に知って欲しいなと心から思いました。これまで色んなアイドルの解散をみてきたけど、℃-uteの解散はまだ受け入れられないです。

第5位:「サヨナラの理由」乃木坂46

www.youtube.com

橋本奈々未さんの卒業シングル。イントロから泣ける。作曲は乃木坂御用達の杉山勝彦さんですが「まじでこの人天才だろ」と改めて思い知らされました。ただ、サビのダンスはちょっと変じゃない?

第4位:「僕だけのハッピーエンド」3776

www.youtube.com

楽曲派御用達の3776さんが4位にランクイン。こういう曲があるからアイドルオタクやめられないよね。アイドルの楽曲に偏見を持っている人ほど聴いて欲しい一曲です。まじでエモい。

第3位:「二人セゾン」欅坂46

www.youtube.com

曲のクオリティも去ることながら、MVのクオリティがヤバイ、そして、何よりも平手友梨奈さんがヤバイ。ぶっちゃけ欅坂46ってコケるんじゃないかなって最初思ってたんだけど、全然そんなことなかった。ごめんなさい。

第2位:「完全なるアイドル」わーすた

www.youtube.com

いま一番売れて欲しいアイドル。メンバー全員可愛いし、曲もバラエティー豊かでよい。そして何よりパフォーマンスのクオリティが高い。@JAM EXPO で観て以来、完全にハマってます。

第1位:「サイレントマジョリティー」欅坂46

www.youtube.com

アイドル史上最高のデビュー曲。イントロからアウトロまでその全部が最高。何も言うことない。

一言

最近在宅気味なので来年はもう少し現場に行ってみようかしら。

伊藤直也さんの一人CTO Nightに一人で行ってきた

巷で話題?のnaoya さんの一人CTO Nightに行ってきましたので、超雑ですがメモを公開しておきます。

イベント詳細: https://doda.jp/event/seminar/20160830.html

オレオレメモなので多少ニュアンス違うところあるかもです。特に二部のパネルディスカッションの部分はかなり文脈を端折っているので雰囲気知るくらいに読んでもらえれば。

もし大きく間違っていることあったらご指摘くださいm(__)m ちなみにアニメの話はあんまりなかったよ。

では、早速。

第一部【プレゼンテーション】最速で最高のアウトプットを生み出すチーム作りとは?

【プレゼンテーション内容】 CTO・技術顧問を複数社経験した伊藤直也氏が、過去の実際の事例をもとに、最高のアウトプットを生み出すチーム作りを解説します。

  • 前提として、、、
    • 50〜300人くらいの規模の組織が対象
    • CTOのマネジメントというよりはVP of Engineering寄りのマネジメントの話
    • マネジメントもいろいろあるけど組織マネジメントとヒューマンマネジメントの話が主

開発組織マネジメントのコツ

  • 『イシューからはじめよ』って本がいいよ
  • エンジニアはプロセス中心というか手段を提供する仕事
  • なので、問題設定とどうやって解くかがごっちゃになりがち
  • マネージャーは問題解決ではなく問題発見にフォーカスすべき
  • 正しい課題にフォーカスすれば自然と問題は解決するはず
  • 開発組織のマネジメントはスポーツチームのマネジメントに近い
  • 組織(構造)があるから

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

内製開発チーム

  • 横串の構造が多い(セールス、プロダクト、エンジニア)
  • エンジニアとセールスが直でやりとりする
  • そのために間にプロダクトチームをいれる
    • セールスの要望が直接届かなくなりエンジニアからエンドユーザーがみえなくなる
  • マトリクス型組織にする(チームをつくる)
  • ラーニング(知識)が蓄積されるような構造が望ましい

日経新聞での事例

  • 外注時代にひとりの人が複数のプロジェクトを兼務
    • 個人にラーニング結果がたまっていく
  • よかれと思って内製開発をはじめたが状況好転せず
    • なぜならチームという枠組みが存在しないから
  • どうしたかと言うと、、、
    • 兼務を解消
    • 1チームに1ミッション

日経電子版 開発内製化の取り組み / nikkei web development 2015 https://speakerdeck.com/yosukesuzuki/nikkei-web-development-2015

Kaizen Platformでの事例

  • 枠組みがあるのに実質チームとして機能していない
  • 1on1してもミッションは同じなのにひとりでやっているという回答
  • 原因はPMとエンジニアが1対1で仕事している
  • PMが空いた人からアサイン
  • コンテキストスイッチが発生
  • 隣の人がきついときヘルプできない
  • どうしたかと言うと、、、
    • PMが直接アサインするのではなくエンジニアのリーダーに
    • チームとして会話する

偶然に期待しない

  • コントロールできる対象をマネジメントする
  • 個々人の意識はコントロールできない
  • 組織構造はコントロールできる
  • 問題があるとき人ではなく構造に原因を求めるべき

優先度が上がらないことを進ませたいとき

  • リファクタリングを推進したときなど
  • そういうときも組織(チーム)構造で変化を起こす
  • 一休では技術基盤チームをつくった(直接的な売上にはつながらない)
  • 決済プラットフォームとかをつくるのもあり
  • ただしころころ構造を変えるとラーニング結果が蓄積されないので注意されたし

組織構造は時間的断片

  • フェーズにあわせて横と縦のバランスを組み替える

デザイナー横断組織の変遷 http://techlife.cookpad.com/entry/2016/07/15/092518

組織課題の発見とアプローチ

  • 『チームが機能するとはどういうことか』という本からの紹介
    • この本、読んだことあって内容知っているのでメモが更に雑ですm(__)m
  • 心理的安全性と責任
  • 両者が高いと学習するのでその状態に持っていこう
  • チームが置かれている状況がどこかによって対応方法が変わる

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

一休での事例

  • レストラン事業部:(乱暴に言うと)ぬるま湯だった
    • チームごとのミッションの明確化
    • ロードマップの精度を向上させる
  • 宿泊事業部:(乱暴に言うと)プロダクトはつくれてるけどちょっと疲弊してた
    • チームビルディング
    • 技術基盤部の確立

ここまで組織レベルの話

ヒューマンマネジメント

  • 『ピープルウェア』の有名なお言葉

ピープルウエア 第3版

ピープルウエア 第3版

フレーミングをちゃんとやる

  • 認知フレーム(思い込みや信念のこと)
  • フレーミング≒期待値調整

フレーミングのコツ

  • ちゃんと説明する
    • 「やっておいて!」だけではなく「こういう理由で◯◯にやって欲しいからお願い!」
  • 最初にがんばる
  • 直接対話する

1on1

  • 任天堂の岩田社長が1on1やってた
  • 組織の課題発見に繋がる
  • フレーミングできる
  • お願いごとは相手のバケツが空になってから
  • 事前アンケートを採ってそれを題材に話す
  • バウンダリーオブジェクト(間にものをおく)

任天堂の岩田社長が遊びに来たので https://www.1101.com/iwata/

(注意)人の話題は強く意識を持っていかれる

  • 誰それさんが辞めたがっているなど
  • 人の話題に意識をとられすぎないように

信頼を勝ち取る

  • リファクタリングのために時間が必要です

    • なんで?→まぁいいよと言われるようにする
  • ビジネスvsエンジニアリングの対立構造に持ち込まない

    • これを普段やっているとあとでこまる

アンチパターン

文化改革症候群

  • 文化とかビジョンみたな言葉が出てきたら危険

変化にあたって現状否定

  • 必要以上に現状を否定しない
  • 未来思考で説く

サーヴァント型リーダーシップの罠

  • 雑用をいっぱいしてくれる
  • でも大きな方向性を示してくれない
  • いざというときの意志決定ができない
  • Fate/Zero観ろ

123: The Grail Dialogue (Naoya Ito) - Rebuild http://rebuild.fm/123/

エンジニア幸せ向上委員会

https://twitter.com/naoya_ito/status/770537380906274817

力を集約する != みんなが同じことを考える

  • みんながみんな同じことを考える組織…宗教?
  • 価値観の異なるメンバーを同じゴールに向かわせる

即効性のあるHOW TO

  • 壁打ち相手を見つけよう
  • 技術プロセスの課題解消(即効性がほしいときに)

第二部【パネルディスカッション】伊藤直也氏のマネジメントお悩み相談室 withソラコム 玉川憲氏

【パネルディスカッション内容】 事前にマネジメントに関して寄せられた「お悩み」に対して、伊藤直也氏がアドバイスを行います。エンジニアの皆さまから寄せられた「お悩み」を伊藤直也氏にぶつけてくれるのは、自身もマネジメントや技術統括の経験を豊富に持つソラコムの玉川憲氏。

メンバーが守備範囲外のことをしてくれない

  • 日本っぽい(守備範囲外のことをやると怒られるじゃん)
  • 指示待ち人間がいるのは待っているほうが得をするから
  • 守備範囲を変えないといけないのでは?

プランナーとうまくいかない

  • インフラエンジニアとアプリケーションエンジニア仲悪い問題と似ている
  • 昔インフラエンジニアがSLAを守るために重いバッチ処理をkillしたことがあった
  • AWSが生まれたのはインフラエンジニアとアプリケーションエンジニアの会話をなくすため(技術で解決パターン)

デザイナーやエンジニアのことを理解してもらうには?

  • まずは信頼してもらうこと
  • でも難しいかも
  • JapanTaxiの川鍋さんみたいに技術のことわからないけどエンジニアリングを大事って言ってくれる人がいると楽

会社(組織)の思考をきりかえるには

  • 一休の営業はIT企業だと思っている人が多くない
  • 最初はもどかしかった(こんなことも知らないのか!
  • でもそういう多様性を受け入れていくことが大切では?

経営陣が人件費を払っているんだからエンジニアは売上が上がる機能開発をしろ!と言ってくる

  • CGMの会社だと難しい(ソシャゲなら話は別)
  • お前が言うな!と思うけど言っちゃダメ
  • 難しい

マネジメント職につく覚悟がつかない

  • 調整ばっかりしているのは確かに辛い
  • 1on1症候群にならないよう

キャリアを含めた技術力が上の人との1on1

  • そもそも技術力がある人が人として上ではない
  • 1on1で技術の話はあまりしない
  • 道を指し示す必要はない
  • 壁打ちでいい
  • ソラコムではスタンドアップミーティングを事前にbotでやる
    • シェアしたいこと
    • 改善したいこと
    • 改善してほしいこと

ROIで優先順位をつけられるとリファクタリングとかできない

  • 同列に並べちゃいけない
  • ロジックで攻めると数字で負けるからよくない
  • 信頼感とか寝技に持ち込む(そしてチームつくっちゃう)

採用についての質問

  • コンテンツをひっぱって採用できる会社は限られている
  • ブログとかメディアやってるのは既に大きなサービスがある企業の付加価値
  • Job Descriptionを外資はちゃんと書く
  • 日本は3行とか
  • 一休でもブログやるとかnaoyaさんを全面に押し出したけどあまりうまくいかず
  • 転職エージェントに出しているJob Descriptionを見直した
  • 面接官が上から目線はNG(エンジニアに多い)
    • 悪い噂はすぐに広まるのでちゃんと説明する
  • AWSの社長?はずっと握手してきたw

開発の速度を定量化したい

  • 相対的にしかみれない

会社全体の技術力をあげていきたい

  • 技術力をあげていきたいというエンジニアは実は少ない
  • ドメイン知識が豊富な人もいる
  • 新しいことは知らないけどコンピューターサイエンスやアルゴリズムの詳しい人もいる
  • ワークライフバランスを大事にしている人もいる
  • いろんな人がいるから多様性を大事に
  • いまあるカードをどう組み合わせるか
  • みんなが勉強マンになる必要はない
  • みんながそうなるとモダンだけどやたらと複雑になること多い
  • 勉強マンとかは技術基盤にいれたり
  • リーダーシップとってる人が勉強してれば勝手に真似してくる(コントロールはできないけど)

1on1の頻度

  • 1週間に1回やると話すことがなくなることがあった
  • フェーズによる
  • 本末転倒にならない頻度でやる

信頼を得るには

  • 一休の場合は元々技術顧問だったので。
  • 地道に積み重ねるしかない。

ひとこと

Rebuildで聴いたことがある話も多かったけど、今まで細切れで聴いていたこともひとつのプレゼンテーションとして綺麗に整理されていたし、とても参考になりました。 僕は今の会社ではマネージャー職ではないけど、マネジメントという仕事も組織としてよいサービスやプロダクトを人々に提供するための手段の一つだと思うので、どんどん取り入れられるところは取り入れていくぞ!

にしても、やっぱりnaoyaさんの話は分かりやすいなぁ〜。

speakerdeck.com