読者です 読者をやめる 読者になる 読者になる

2016年振り返り

去年に続く。

仕事

やったこと

2015年から始めた↓の開発リードを引き続きやっている。

www.fringe81.com

去年は管理手放したと言いつつも、定常業務を手放しただけで特に設計面とかは隅々まで全部自分が面倒見る!と息巻いて実際そうだったのだが、2016年の4月に新卒が入ってきた頃がピークで人数多く17人くらいになり、どう考えても全部自分がってのは物理的に限界が来た。と同時にマネージャーになったものだからより自分自身が直接的にではなく間接的に接するようになった。

ポジティブに捉えると、なんだかんだ重要な決め事は自分が絡めれば良いという割り切りが出来るようになったとは言える。大規模なアーキテクチャ変更の設計やらインフラ構成の変更、要件を仕様に落とすあたりのコトを自分が主導にはならないがレビューはかなり増えた。徐々に自分がいなくてもいいかなぁという状態になってきたという感覚がある。ひとえに皆の成長に依るところだとは思うが、育てたというより育ったという形ではあるので、後述するが私自身のマネジメント能力が未だ未熟だということは実感している。

役職

あと、4月にリーダーからマネージャーになった。 いつか書いたかもしれないが、社会人1年めのときの上司が新卒5年めでマネージャーになっていて、 自分も同じようなイメージを持ちながら仕事をしたものの鳴かず飛ばず転職。 そこから彼と同じところまで巻き返せたので、現業においてそれなりに頑張れたという自信にはなった。

技術面の成長

正直そんなに伸びた感覚がない。27歳という年齢で成長が鈍化した感覚があるのはまずい気がする。 細かいところ(インフラ方面)で覚えたことはあるものの、特にコレが出来るようになった!!!というものはない。

未来

やや揺れている。果たして自分はマネジメント職が自分にとって最もパワーを発揮できるのか?という点で。

Qiita:Teamに開発管理の記事書いたりしてサブチームでうまく回し始めているし。

去年はこう書いていたが、サブチームのリードが上手い人がいたということでうまく回っていただけで自分が上手かったわけではないことに気がついたのが2016年。メンバーのメンタルケアとか本当に苦手で、自分のEQの低さに辟易とすることがある。 また自分を主語とする思考/会話が多すぎて、人の気持ちや考えを理解するとかまで気が回らない事が多い。2015年も同じような振り返りをしているのでこれを克服するには相当な時間がかかりそうだ。何か矯正ギプス的な仕組みを入れられないか…

ただマネージャー業1年目の今はまだその決断をするのは全然早いので数年もがいて、29歳か30歳くらいの時点まではしがみつきたい。 ↓の本をベースにした研修で、あとはヒューマンスキルが伸びればっていうところは自覚が出来たのでやるだけである。

今いるメンバーで「大金星」を挙げるチームの法則――『ジャイアントキリング』の流儀

今いるメンバーで「大金星」を挙げるチームの法則――『ジャイアントキリング』の流儀

2017年の振り返りで「マネジメント業の自信が多少出来た」と書けたらそのまま行けると判断できる材料になりそうだ。

2017年

仕事においてマネジメント業を頑張るっていう一方で、業務外のところでは技術面を伸ばす勉強をやる。 マネジメント業が増えるに従って技術的な伸びが無いってのは、セルフマネジメントが出来ていないことの裏返しである。って、naoya氏かあんちぽくんさんのtwitterか何かでみた気がする。たしかに当たってて、マネジメントの仕事って基本先回り型なので(メンバーはその場を戦うことに集中するが)、朝早く出社して仕事やりきって、遅くても10時くらいに帰る ようになっていれば時間取れるんだよね。 確保した時間で月に2,3冊の本が読める状態を作れたら勝ち。

こういう話もあるし、チームとして動くにはどうしたら良いのってことを考えつつ、技術的にはlinux等普遍的なことを理解する勉強の時間を取ろうと思う。会社も大きくなってきて、現実的にやれるのか?というところは分からないがチャレンジする。

その他

去年

年明けから2日連続で立川爆音上映キメる年明けから2日連続で立川爆音上映キメる

と書いたが、2017年も同じように立川行くことになりそうで、何も変わってなくて安心した。

逃げ恥観て非常に結婚したくなったのでそろそろ本気出す。
テストロテン分泌量を増やすべく筋トレもやる。

J2は出来るだけ色んなところに行きたい。1年で帰りたい。

久しぶりに勉強会で喋ってきた

Scala/Scrum/DDD 困ったこと50連発ガトリングトーク!! のLTで発表してきた話

続きを読む

春のMac大掃除作戦

年度末ということでPCの大掃除をする。 やったことを適宜更新かけていく。

homebrew

不要なFormulaの削除

brew list でインストール済みFormulaの一覧が出力できるが、依存関係上削除出来ないものもあるので、dependency treeを生成する。

brew install graphviz
brew install martido/brew-graph/brew-graph
brew graph --installed | dot -Tpng -obrew_dependency_graph.png
open brew_dependency_graph.png

こんな感じのが出力されるはず。

f:id:jsoizo:20160331004320p:plain

あとは良しなに不要なFormulaを消していけばOK

// 第2引数以降はFormula名を複数書いていく
brew uninstall ${Formula名}

キャッシュ、アップデート後のゴミを削除

awscliとかは頻繁にアップデートするので、古いバージョンのゴミとかキャッシュが結構溜まっていく。 これらを消してあげる。

brew cleanup

Docker

無名imageの削除

docker rmi $(docker images | awk '/^<none>/ { print $3 }')

要らないimageの削除

// 第2引数以降はimage名を複数書いていく
docker rmi ${image名}

2015年振り返り

仕事

やったこと

14年末、↓の開発リーダーにアサインされた。

前職で新卒の5月に当時のトレーナーだった先輩と"社会人3年めには10人月くらいの開発を任せられる様になりましょう"というキャリアプランを描いていたにもかかわらず半年で下方修正して、さらに会社でもお荷物っぽくなっていた時のことを思い返すと感慨深い。結局は元々のプランに戻せた。上司に感謝である。泣くほど嬉しかった。

www.fringe81.com

そこから1年、やっていたのは主にこんな感じ。

  1. エンジニアリングチームの管理
  2. プロダクトのアーキテクチャ設計
  3. パートナーとのコミュニケーション
  4. その他技術系の球拾い

10月くらいに規模が14人月くらいにまでなって来て流石に細部まで管理できなくなってきたので工程管理を手放した。

リーダーとかマネジメントってのがどういう仕事だっていうのは体系立てて理解出来ているわけではないんだけど、チームで一番若いし(当時は...)、とにかく正しいと思ったことに対して愚直に、ミスったらゴメンナサイ。っていう割り切りでやっていて、諸先輩方の優しさのおかげでそれなりにまわっていたと思う。"とにかく0→1でプロダクトを作る"という経験が出来たのが大事で、これはタイミングがないとなかなか出来るものではない。夏に良い評価をもらえたので少しは自信が持てた。

技術面の成長

技術的には、プログラマの多い会社においてリーダーはインフラ周りの仕事を巻き取ることが多く、結果としてインフラ構築の知識が若干伸びた。主にDockerの概念と使い方を実用できるレベルにもっていけたのは大きい。

プログラマとしては伸びはあまり無し。チームの人数が最初は5,6人程度だったのが14人くらいにまで多くなってきて、自分がコードを書くというのは無理になった。なので主にアーキテクチャの設計をやりつつ、前半戦は詳細設計のレビューをすることがあったのでシステムの作りとしての良し悪しを客観的に判断できるようにはなってきたかもしれない。

業務外での学び

仕事忙しくて本を読む余裕とかあまりなかった(言い訳)。 仕事で結果を出すことに集中していたというのもある。

大事なことは

  1. Product Management系の勉強会/オフ会
  2. DDD本のユビキタス言語と境界づけられたコンテキストの話
  3. Dockerの勉強会
  4. [番外編] SHIROBAKO

あたりか。結構仕事に直結している。というか、自分自身の好みよりも仕事で必要なことをとにかくインプットしたというのが実情。よって雑というか方向性のない学びが多かった。結局は各々大事で欠かせない事柄であるので良いのではあるが、2016年はもう少し集中をしても良い。ということでプロダクトマネジメント、エンジニアリングマネジメントとDocker使ったインフラ構築の改善に振っていく。現状仕事という形でアウトプットすることが出来ない都合、プログラム書いたり設計する話は一時的に止めておいたほうが効率的かもしれない。

2016年

なんとかプロダクトをローンチできたというのは良かったが、一方で物事のススメ方が短絡的というか感情ドリブンになりすぎたという反省点もあって、大体周りが上手く回収してくれていたので助かっていたという感覚はある。これからは"1→Nでプロダクトをグロースさせていく"フェーズで、キッチリ数値目標見ながら無限にある選択肢から最良な解を選んでいくということをしなければならない。

ということで、2016年は以下が目標になるかな。

  • 一回反芻するというアクションを癖にする。ロジックを構築して伝える
  • 組織マネジメント, プロダクト開発の手法を2つ自分のモノにする(意識的に使い分けてられるようになる)

私は人を結構ガミガミ言って動かすタイプで、言われた側はストレス溜まるので本当はうまく問いかけたりしながら持って行きつつ締めるところはキッチリ。みたいなコトが出来ると良いのだが…それは時間がかかりそうだ。できれば望ましいが、優先度は低い。

未来

悩んだ。私は結局何になりたいのだろう?少なくとも経営者ではない。ということは分かっているが。プロダクトを作るという中で自分が一番向いているロールがなんなのかを見失って要る。というのも、現状のものすごく中途半端な状態で、かすかなWeb広告の業務知識と若干の管理能力から今の仕事をしているわけだが、それを抽象的なスキルとして自分のものにできているという実感が無い。

エンジニアとしても同様。結局どこにも強みがない。こちらも上記と同様でカーネルハッカーにでもなるかというと違う。ということはわかっているし、プロダクトとか管理寄りの人間であるということは理解をしている。だが、プログラムを書くことに対する未練がタラタラであるかぎり完全ではない。

最近、"私の仕事ぶっちゃけ私じゃなくても良くね?"と感じる事が多い。設計は優秀な先輩がやってくれる様になったし、Qiita:Teamに開発管理の記事書いたりしてサブチームでうまく回し始めているし。勝手に回る状態になっているというのはそれで良いのかな?という思いと、自分で細部までコントロールしたいという思いとで揺れる。たぶん前者が勝つべきだ。兎に角全方位球を拾いまくって平均値上げるしかない。

理想はココのProduct Management Triangleの下記ACが厚くなってくることかな。

f:id:jsoizo:20151231215548p:plain

まとまりがないが、今はあと1年はプロダクト開発とエンジニアリングマネジメントに集中して、1年くらいあとに1人のプログラマに戻る。んでまた2年くらいしたらマネジメントやる。のが良い路線かなぁ…

その他

f:id:jsoizo:20151231175619p:plain

ひとことで言うと、慢心、環境の違い

ここで、継続高校隊長ミカさんのお言葉をお聞きください。

人間は失敗する生き物だからね。大事なのはそこから何かを学ぶってことさ。

f:id:jsoizo:20151231180916p:plain

年明けから2日連続で立川爆音上映キメる予定。ミカさんのフィルム当たらないかなぁ…

ほんのちょっとだけdockerわかった気になった

週末にこれ

qiita.com

を書いていて、ほんのちょっとだけdockerをわかった気になったので思ったことをつらつら書いていく。

元としてはCoreOS上でdroneをビルドしていて、"gitとdockerさえあれば何でもできるな"。と思ったのがポイント。droneのビルドのためにgolangが入った環境が必要だから、イメージに対してソースを渡してその中でビルド実施。アウトプットされたバイナリファイルを実行する環境が必要となったら今度は実行用の超軽量イメージにファイルを渡して実行。と言った形で、コンテナそのものはほぼ単一の目的に対してのみ提供される。モノリシック→マイクロサービスの流れとかcatしてgrepしてcutするunix哲学に似ているのかなぁと思った。

dockerを使ってシステムを組む時のメリットは、アプリケーションが載った環境を名前空間によって簡単に分割できる点だと理解している。それって要はマイクロサービスじゃん。単体でデプロイ&動作できるし、コンテナ同士の連鎖や掛け算によって大きなシステムを構築することもできる。的な。

もう少し具体的なイメージに落とすと、もしかしてdockerが出てきた背景は"疎結合,高凝集"みたいなオブジェクト指向の概念をインフラ世界に持って行きたかったのかも。アプリケーションは疎結合にすることはできた。一方でアプリケーションは動作するOS含めたインフラに依存するが、インフラを疎結合にすることはできない。例えば、同一ホスト内で複数アプリケーションが動いていたとして、片方は最新のlinuxカーネルに対応しているがもう片方はそうでない場合、インフラ起因でアプリケーションのアップデートができなくなる。結果技術的負債が貯まる。ドメインモデルの成長(つまり事業の成長)を阻害する原因になる。それをdockerという形でアプリケーションが依存するインフラはdockerコンテナ内に押し込め、つまり"カプセル化し"、結果疎結合になる。要するに境界づけられたコンテキストがdockerの名前空間よってインフラレベルで線引きができるようになる。やったぜ!的な。ぶっちゃけVMでも同じことできるはできるけど、VMだと抽象化レイヤーが少し低くて、VM同士を関連付けて動かしてとか結構面倒。dockerはライトにやれるのがとにかくでかい。

クラウドによってコンピューターリソースを抽象化して自由に伸縮させられる、dockerでアプリケーションを完全に隔離された環境を構築できる。かつそれらをWeb APIによって簡易にできる。極めて低いレイヤーをプログラマブルに扱える。結果サーバリソースが最適化され、コンピューティングに対するエネルギー効率が良くなる。地球にやさしい!!

と、ここまで書いていて気づいたが、
dockerってPaaSやってるdocCloud社が仮想環境をライトにポコポコ建てるために作ったものだったから、疎結合云々は私の拡大解釈でしかないのかも。ただ、そんなに大きくずれた事は言っていないんじゃないかな。

お酒飲んだ後だから全くまとまった文章じゃないんだけど、そんなかんじ。

明日朝早く出社できるように頑張ります。

Docker実践LT 2015-10-14

行ってきた。勉強会発表デビュー戦。

connpass.com

発表について

割と戦える領域のトピックだったし、デビュー戦の割には喋れたんじゃないのと思う。

当日朝までdrone.io(v0.3)の docker buildプラグインでハマリ、結局うまく行かず。Docker in Dockerでやることにした。個人的にはDocker in Dockerってあまりかっこいいと思ってなくて(※ ここでいうDocker in Dockerとはネストしている状態のことを指す)、子をprivilegeモードで起動しつつ子は親ホストのsocketを叩くみたいになっている方が美しいと考える派である。なので若干の悔しさがあるが、それは未来頑張るとして、一旦はやりたかったことがやれたから良かったかなと。

drone自体は結構いいツールで、Dockerを前提にしたイマドキのCIって感じ。発表でも喋ったが次期バージョンアップで大分洗練されて出来ることが増える。gitterでも盛んにディスカッションされているし、OSSなCIの中では一番いいと思っている。ガンガン使ってPRでも出したいくらい(golang分かんねけど)。会社のやつはこの週末の内にv0.4にあげてみようと思う。

他の人の発表について

自分のことで頭いっぱいで他の人の話はあまり聞けてないから覚えていることをメモレベルで。

  • Dockerを開発環境に導入した話
    • 私の環境と同じ。結局docker-machineさえありゃええねん
    • composeは便利よね。F81ではdocker runを叩くshを作ってやってるけど、汚くなってくるからYAMLファイルをgitで管理するのが美しいし、そうしたい。
  • AWS Elastic BeanstalkでDockerを動かせた
    • Beanstalkの画面扱いづらそうだなぁ…
    • BeanstalkとEC2 Container Engineどっちがいいんだろって思った
    • Beanstalkのほうがよりやれることが少ないという理解
  • Build your APK beyond Docker
    • x86Androidエミュレータをリモートで操作する話
    • Dockerはプロトコル
    • Dockerコンテナって形で抽象化されていればどこでっていう場所の問題が無くなる良さはあるよね。所謂冪等性。
    • write once run run anywhere的な
  • 非アプリエンジニアによる 【初級】kitematic hack
    • kinematicを初めて聞いた
    • kinematic : docker-machineのGUI, dockerhubだけしか対応していない
    • Electron
    • このhackではマイクラコンテナを非表示にするってのをやってたが、dockerhub以外の所からpull出来うようにhackも出来そう
  • Docker ライフサイクルイベントフック
    • docker rm $(docker ps -a -q) を本番で叩くのは雑。 F81では結構やってる…
    • や、CloudFormationでサーバ建てるのに時間がかかりすぎるのが悪いんや。と言い訳しておこう
    • dockerのAPI直接叩いたことなかったしやってみようかな
    • docker-pluginsは楽そう
    • sbt-musicalみたく、dockerでビルド中に音楽を流すとか思いついた
  • DockerでGUIアプリケーションを動かす
  • 毎日2000個のコンテナをstartする鯖が突然死して僕が驚愕した話
    • 2000個はやべーな...
    • Side CIではGitHubのPRにフックしてコードを静的チェックしている
    • 突然死はごくたまに遭遇したことあるけど、いっぺんに来るとかこえーな…
    • ゾンビ化コンテナはcronで定期的に消している
    • この辺の運用は会社によって違いそうなので本番運用系で各社どうしているのか聞いてみたい
    • devicemapperつかってるとディスク足りてるのに足らないって出る
    • drone検証している時、devicemapper遅い疑惑あったし、使わないほうがいいかもね
      • CentOSでdockerいれるとデフォルトでdevicemapper
      • Ubuntuだとaufs
      • droneって起動時にベースイメージからCI用のイメージ作って実行してるんだけど、その処理速度がUbuntu > CentOSだった
      • dockerのバージョンは同じなのでFS問題かと
      • 次回のネタとして天下一FS武闘会でもいいかもしれない
    • CoreOSだとoverlayfs, aufsよりはいいと聞いたことある。違いがよく分かってない
  • docker swarm 触ってみた
    • 気になるネタなのに自分の1つ前のセッションだったから全く記憶に無い
    • swarmのデモ.立ち上げてクラスタにjoinしたりleaveしたり
    • spark動かす時の基盤に出来ないかな?って思ったけど"swarm使わないほうがいいよ。未だベータだし"と聞いてうっってなった
    • とはいえMesosもハマりそうで嫌だし...悩みのタネになりそう

まとめ

まわりレベル高いセッションあってビビった。 とは言えまったく歯がたたないレベルかというとそうでもなくて、とても良い刺激。 Dockerの運用は結構会社によって違いそうで、F81ならホストで男気sh実行みたいな感じだし、だれだったかはホストOSでは何もしないポリシーだった。この辺りはノウハウが未だ溜め途中だと思うので積極的にシェアしていくといいかもね。

外部勉強会で発表するのって、教育のジレンマで凄く学べる。マサカリ飛んできたら怖いしね。 発表する前は緊張するもんだが、喋り始めるとなんてこたぁ無いんで、ビビらず飛び込んでいけばいいと知った。

まだ次回作の予定はないようなので、引き継いで弊社開催にしてもいいなぁと思った次第。定期的に会ってコミュニティを育てていったほうが底上げになりそう。

蛇足

終わった後で飲みに行って、その場で私以外全員Railsの人だった。 結構思想違うなぁってのを感じた。良くも悪くも実装はフリーダムって感じ。フリーダムなんだけどRailsというレールには乗らなきゃdisられる。 Scala界隈とは逆だなぁと思うと同時に、LL言語からScala使いはじめる人はそのフリーダムな感じが嫌になって来るのかも。

2015-10-05

毎日日記書くと宣言してから、ものの見事に三日坊主したので反省している。

仕事忙しくなってきたのでDDD本読むペースは鈍化している。実践本を一旦たたんでEvansを噛み砕くように読み中。現在まだ3章。道のりは長い。

考え方みたいなのはわかってきたんだけど、"こうやればDDDうまくやれているなぁ"という実感を全く身につけられていないのでもっとコード書いたり読んだりしないとだめっぽい。結局口だけっぽくなりそう。