大事なことはすべて村上春樹の『風の歌を聴け』に学んだ
この記事は随時追記するかも。
かなりポエミーな雑記です。
『僕たちが認識しようと努めるものと、実際に認識するものの間には深い淵が横たわっている。』ってずっと昔に書かれているんだけど、素通りしてしまっている気がする。
これってつまり『認知のバイアス』だとか、『7つの習慣』でいうところの『パラダイム』の議論にも通じていると思う。
好きとか通り過ぎて何回も読み返しているけど、まだこういう気付きがある。
「インフラエンジニアの現場における仕事と文化」のDiff #DevKan
2016年2月5日のDevLove関西の表題のイベントに参加してきました。(いちおう受付スタッフも)
Developer Infrastructure in DevLove Kansai
話し手:Wantedly 坂部広大さん
www.slideshare.net
Devlove現場甲子園東日本大会での坂部さんの話がもう一度聞きたいと思って、DevLove関西でもやってもらえました。 念願かなった感じです。
syncメッセンジャー
1月からsyncというメッセンジャーアプリをローンチしたとのこと。 syncはfacebookのメッセンジャーが仕事の話が混じってしまうことを嫌う人のために、仕事領域のメッセージサービスとして特化した形を目指しているそうです。
「話を聞きに行く」「応募情報の自動入力」のボタン(OpenAPI)を作った話。
東日本大会のときはわかっていなかったのですが、相川さんというかたとタッグを組んで実現されてたのですね。 ただOpenAPIを作るというだけではなく、企画書を書いたり、使ってもらえそうなところを訪問してちゃんと営業までする、というのがインフラエンジニアとしての領域、もしくはエンジニアとしての領域を『越境』していると感じます。 そしてそれが、「Ownership」ということなのかと。 そうでもしないとWantedlyのメンバーとして生き残れない感じがあるんじゃないかなぁと邪推してしまいます。
インフラエンジニアがボトルネックにならないために
Wantedlyのサービス開発はとにかくプロトタイプを早く作り、どんどん早くリリースして検証したいという感じらしいです。 Devのエンジニアがリリース依頼して、インフラがリリースするという流れだとタスクが溜まってインフラチームがボトルネックになる。
解決する道は2通り
- インフラエンジニアを増やして人海戦術
- インフラの質を上げる
Wantedlyは後者のアプローチを取ったそうです。
『Facebookは5人で10万台のサーバーの面倒を見ている。俺たちもfacebookになろうぜ!』
『変化に強いインフラ』を目指すために
- 自動化
- セルフサービス化
を実現する。 直近の取り組みとしてCoreOSにすべてのコンテナを置き換えたとのこと。 ChefやPackerを使った構築の自動化だと、結局は「秘伝のタレ」化がなされてしまい、アプリのエンジニアがどこを変更すればいいかわからなくなるとのこと。 Dockerfileだけにしてしまえばインフラエンジニアじゃなくてもわかる。
GitHub Issueのフル活用
これはエンジニアだけでなく、ビジネスサイドの人もそうです。 そこに「Why」と「What」を必ず盛り込むため、チーム間でIssueのバトンタッチができるとのこと。 そして、PullRequestで「nginxのワーカープロセスを議論する」ということができているとのこと。
『インフラエンジニアこそ情熱的に仕事をする。』
感想ですが、どうすればこのように越境するエンジニアリングができるのか、ということを考えながらこれから先歩んでいきたいと思っています。
WhyとWhatを大切にし、必要ならばどんどん企画書を書き、営業もできるように。。。。
地道にAWS構築自動化に取り組んでいるお話し
話し手:Serverworks 永田明さん
www.slideshare.net
Serverworksのインフラエンジニアとしての構築のお仕事
サーバーワークスの提供しているのはAWSを中心として様々なサービスを組み合わせて最高のサービス基盤(インフラ)を提供すること。 そのため、セールスをしている人もセールスと言いつつ凄腕のエンジニア。 大体の構築はわかる。
もともとは、BacklogのWikiにパラメータシートをMarkdownでうめこみ、それをもとにお客様とやり取りするスタイル
そのほかAtlassian Confluenceにノウハウをためているとのこと。 でも、、「その情報あったんかい!」てなることも多いとのこと。
Wikiに記述されたパラメータをAWSのマネジメントコンソールからポチポチ転記。 その結果としてミスすることもある。
属人性が非常に高い設計フェーズだった!
自動化タスクフォース
これではあかん、ということで構築を自動化しようという運動が持ち上がったそうです。
最初にやったのはYAMLをJSON(AWS CloudFormation)にするスクリプトの作成
やってみたけれど、課題が…
CloudFormationのそもそもの課題として動かないとどこがおかしいのかわかりづらい。 AWSマネジメントコンソールは入力値のチェックもしてくれるし、元のほうがよかったのでは…
でも
そもそもAWSはプログラマブルなサービス そして我々はトップレベルのベンダー
自動化を続けるために、小さく早く試して、たくさん失敗できるようにしよう
まず、達成すべき課題として以下の2つがある * YAMLの二重管理 * スクリプトの実行環境がローカルで毎回アップデートについていかないといけない
これを解決するために
WEBアプリ化
Jenkinsによるバッチ処理実行するようにすることで、実行環境が常に最新化されスクリプトが実行する人が気にしなくてもいいようになった。
そして、Jsonだけじゃなく、Markdownを生成。
生成されるのは、属人的に作られたものじゃなく、フルスペックのパラメータ表。
これによって、ひな形のYAMLができて、無難な設計が共有されるように。
いわば『秘伝のタレ』
自動構築化後の課題
自動で構築しても確認は必要。 そして、確認は目視。 CloudFormationは動かないとどこがおかしいのかわかりづらい問題。 逆に動くと快感らしい。。。
確認のためにRSpecをもととしたWebアプリをつくる、、、ということを目指しているそう。
自動テストの文化を作るところから再スタート
感想ですが、今までやってきたことがアンチパターンになる場合もある、という言葉に深く共感します。 そのために、改善と軌道修正をやめたら負けということも。
自分も今の現場で自動化の取り組みをしていますが、今まで築きあげてきたものがレガシーになったときに、捨てたり式年遷宮的にちゃんと切り替えができるように考えていかなければいけないんじゃないかなーと思いました。
全体の感想
スタートアップとクラウドのトップベンダーという2つの現場の文化の違いはとても感じられたし、自分の現場とも比較することができ、とてもよかった!
坂部さん、永田さん、会場のMOテックスさん、参加してくれた皆さま、本当にありがとうございました。
Microsoft の DevOps ハッカソンに参加しました #DEVOPSJP
2016年1月23, 24日に開催された表題のハッカソンに参加してきました。
ハッカソンへの参加は初めてでした!楽しかった!
DevOpsとは
なんぞ、ということを牛尾さんと小塚さんがプレゼンしてくれました。
アジャイルマニフェストと違って、はっきりと明文化されたものがないため、言ってることが定まらなかったという変遷があるとのこと。
ただ、ツールをさすのではないので、特定のツールにたいして「このツールはDevOps対応ツールですよ」と売り込んでくる場合は注意が必要。
10 deploy / day
開発者とインフラ技術者が協力し、ソフトウェアライフサイクルやビジネス価値の創出を改善する活動
草の根から始まって、途中からトップダウンに
開発部門と運用部門の壁
開発部門
「リリース終わった やったー」
運用部門の気持ち
「上からなんか使えるのかわからないもの降ってきた」
いがみあったりするようにならないように。。。
PO , dev, qa, opsが1チーム
DevOps 1番最初にやること Dev側 = テスト駆動開発
システムテストをがっつり自動化
50時間以上のシステムテスト
Jenkinsを利用して、並列に2時間
※お金を扱うのでトランザクションミスったら終わる
クックパッド
単体テスト以上は必要ない
間違っていたら8秒で戻せるようにしている
DevOps 1番最初にやること Ops側 = Infrastructure as Code
Visual Studio Team services 便利そうです。
カンバン機能(its機能)とビルド機能などがつながっている。
gradle, xcode, gulpなどのビルドもできる。
ハッカソン実践 『Dockerでオートスケールを実現する』チーム
目指すのはサービスの負荷が高くなった時に自動的にコンテナが立ち上がり、ノードに追加されて負荷を分散するシステム
なんか、MS寺田さんに見せてもらったデモをとにかく参考にしたという感じです。
パクリかもしれない。
1日目はAzureの操作に戸惑いすぎてほぼ何もできず、みたいなかんじでした。
Jenkins入りのイメージを起動したのですが、そいつがDockerコンテナの中で動いていたのでDockerコンテナの外側からビルドなどのコマンドをすることはできず。。
2日目にやったことはタスクボードに張り付けてログを取ってました。
が、画像が荒すぎて見えない
チームで実現したDoneは以下のような感じ
足回り
- Visual Studio Team Services上にソースコードとDockerfile保存用のGitリポジトリを作る
-
Wordpressを動かすDockerfileを試作
Jenkinsが動かない問題
Jenkinsジョブ設定
- SCMポーリングでDockerfileの変化をフック
- dockerコンテナをビルドし、イメージをDockerHubにプッシュする(Jenkinsのプラグイン使用)
CloudBees Docker Build and Publish plugin - Jenkins - Jenkins Wiki
Tutumまわり
- webhookでDockerHubのイメージの変更を検知
- Azure上にDockerコンテナ作成、起動
- Tutum上でコンテナを増やす
ビルドパイプライン全体
- Dockerfileをgit pushするだけでAzure上にコンテナが立ち上がる
ただし、Wordpressは試作のDockerfileでは動かなかったです。
というわけで
1コンテナでWordpressを動かす
- bug: コンテナ上でリンクが作成できない(権限の問題)
- 上記bugfix: tarボールの解凍時に適切な場所にcpしてしまう
update for boot2docker aufs issue · CentOS/CentOS-Dockerfiles@d2b7b93 · GitHub
- bug: mysqld, httpdデーモンプロセスを動かしたコンテナが即終了する
- bugfix: tail -f /dev/nullを最後に実行する
複数コンテナでWordpressを動かす
- tutumでオートスケールできないか調査
- haproxyで2コンテナにロードバランス
といったところでタイムアウトです。
肝心のオートスケールは実現できませんでしたが自分一人ではできないこともチームで挑戦することでいろいろ実現できました。
DevとOpsという垣根はなかったです。Opsしかやってない感じはありましたが!
自分はGitまわりとWordpressを1コンテナで動かすというところに注力していたので、Tutumの操作はチームメンバーにやってもらっていましたが、非常に便利だと感じました。
発表自体はちょっと残念な感じになっちゃったのですが、個人的にはDockerを実際に使い、tutumにも関われて非常に満足でした。
ハッカソンというイベント自体もそんなにパーフェクトにやろうと構えず、失敗してもいいという気持ちで参加してもよいことが分かったので行ってよかったです。
声かけてくれた自動化コーチに感謝です。
牛尾さん、寺田さん、小塚さんをはじめとしたスタッフの皆さま、チームのメンバーの方、そのほか参加者の皆さま、本当にありがとうございました。
素晴らしいイベントでした。
「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」の再演 #DevKan
2016年1月22日に開催された表題の勉強会に参加してきました。
エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。
<話し手>久保 明(@HappyLuckyAkira)さん
やっぱりプレゼンが面白い!
自分のプレゼンと比べるべくもありません。
学び方についてですが、とくに勉強会に参加するときに無理にアウトプットを出そうとか、会社で参加した勉強会の内容について共有しようとか、そういう構えはしなくてもいいんじゃないかというふうにおっしゃってました。
まったくその通りだと思います。
とりあえず聞くだけ聞いてみて面白くて楽しかったらオッケーだと思います。
アウトプット出すにしても徐々に徐々に、段階的にでいいと思います。
派生開発についての勉強会については質問も上がっていたけど、自分も気になります。
開発は変化を前提としているほうがありがたいですけど、そうではない場合どうしたらいいんだろう。
あり方については深い、、、、とおもいます。
時々自分のエンジニアとしてのあり方間違っているのではないかとか、何のために生きているんだろうか思う次第です。
そういうときはステレオポニーの『星屑カンテラ』を聞いています(どうでもいい)。
ワークについて
ペットボトルからコップに水を入れる動作の手順を説明するチェックリストをつくる、というのをやりました。
自分は15ステップでしたが、お手本は27ステップ。
以下に、「これくらいはわかるだろう」という思い込みで省略されているのかということが分かりました。
いろんなことを省略して阿吽の呼吸のハイコンテキストでコミュニケーションができるのが理想だと思いますが、それを目指すためには差をちゃんと埋めていく努力が大切かなあとおもいます。
そのほか質問でありましたが、バグとか起きても犯人捜しでネガティブにならずに、このタイミングで見つけてくれてありがとうというふうに思いましょうとのこと。
場の空気を換えるのは難しいそうですが、そういう認知のバイアスを変えていくのも継続してやることで自然とチームの雰囲気改善につながるんじゃないかと思いました。
久保さん、会場のロックオンさん、スタッフの皆さまありがとうございました。
『それぞれの現場で実践した【自動化】の話』に参加・発表してきました #DevKan
2016年1月18日にあった表題の勉強会に参加・発表してきました。
自動化とは何か?ゲーム開発において実践した自動化とは?
<話し手>森田 和則(@pg_morita)さん
DevLove現場甲子園西日本大会の再演です。
2度目になりますが「ベヨネッタ2のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
バグチェック作業の自動化について
自動化の意義はクリエイティブなことに集中したいから。
そしてなるべくコードを書くという作業を減らしたいから、というのもあるそうです。
ブログ記事の動画を見せてもらいましたが本当に素晴らしいです。
ゲームの負荷などのパフォーマンスを表示する処理ではjQueryを使いこなしてすごく見やすいビューを作っています。
意外なことにjQueryプラグインを使うのがかなり好きなのだとか。
クリエイターさんがVFXなどを変更して結果としてパフォーマンスが落ちたときに、一発でわかるという感じです。
自分はまだまだプロダクトのため、開発で本当にやりたいことに集中するための自動化というのができていないため見習っていきたいです。
特にテスト系をもっとしっかりやりたい。きちんとしたXPやりたい。
森田さんありがとうございました!
ECサービスフロントエンドエンジニアがリリース改善やブラウザ自動テストに取り組んでみた話
発表したスライドは以下になります。
初めてなのもあり、つたない発表で申し訳ありません。
(※ スライド中の、「第2部 完」の画像は手書きです)
会場のサイバーエージェントさん、お聞きくださった方、スタッフの皆さま、本当にありがとうございました。
Accountableの解釈の誤りと自分事化、そして意思決定の明確なルールについて
Accountableの誤訳
- 「誰が責任を取るのか?」という時に使われる
- 端的に言いかえると「落とし前をつける責任」である
- 落とし前をつける = 引責辞任する、賠償金を支払う、 減俸、 懲戒処分とかをうける
コーチングで使われるAccountableと自分事化について
ビジネスコーチングを過去に受けたことがありますが、コーチはAccountableとVictimの対比でAccountableのことを説明されていました。
Accountableはほぼ「自分事化」「自己責任化」という態度で、Victimはその逆で「犠牲的」「主体的でない」「誰々のせいで私は~することができない」という態度という説明だったと思います。
当然ですが、Accountableになるほうが良いとアドバイスを受けました。
気を付けなければいけないと思っているのが、物事に対し自分が「誰々のせいで私は~することができない」という犠牲的な態度になっていないかということです。
本当にそうなのか?ということを考えてみることが自分事化だと思います。
Accountableと意思決定の明確なルールについて
“Mike is responsible for holding Sally accountable. Tom is responsible for holding Mike accountable. I am responsible for holding Tom accountable.”
「マイクはサリーをアカウンタブルにしておく責任がある。トムはマイクをアカウンタブルにしておく責任がある。俺はトムをアカウンタブルにしておく責任がある。」
アジャイルコーチというロールについて
エンジニアの学ぶべきことの深度は日々増加していて専門性も高くなり、そのために協調して働くスキルが必要になってきていると思います。
付け加えて言うなら、深くなってるんだから潜るのには勇気がいります。
誰もが教科書やコードを読んで、教えてもらうことなく技術を使いこなせるとは限りません。
たとえ技術力や意思力でヘタレだったとしても、そういった未知の領域に潜っていく勇気を与えてくれるのがスクラムやらXPであると思います。
スクラムやXPが生産性にすぐに直接影響を与えることが大きいとは自分は思っていません。継続的にやってこそ効果が出ると思います。
スクラムやXPの具体的な内容についてはここでは言及しませんのであしからず。
ただわかっているのは、やみくもにそういったプロセス改善のフレームワークを用い、プロジェクトがうまくいかないこともあると思います。
根本的な原因は、そのフレームワークそのものにあるのではなく、プロダクトの品質をキーにしたマネジメントをしていないということだったりします。
あるいは人同士の相互作用でプロダクトができるのを無視して、信頼関係の醸成やコミュニケーション(特に意思決定のルール)を軽視していたりすることだったりもします。
原因はともかく、うまくいっていないという現実の課題に踏み込まないまま、プロセス改善のフレームワーク(の上辺だけ)を適用しようとすることだけに注力しようとするのは自分は非常に危険だと思っています。
(そんな状態が続くとエンジニアのフレームワークに対する嫌悪感がたまり、悪のオーラ力がたまってハイパー化します。あるいは、エンジニアのソウルジェムが濁っていき、魔女化します。)
上手くいかないときはアジャイルコーチに頼ってみよう
そこで出てくるのがアジャイルのコーチです。
僕の知っているアジャイルコーチの最初に言った一言は「スクラムの教科書的な答えが知りたいですか?開発をうまく回したいんですか?」という内容です。
スクラムを単純に教えてくれる先生ではありません。
現場の課題に踏み込み、信頼して任せるということ
よく言われることだと思いますが、(良くないOJTのように)放任するというのと、信頼して任せるのは違います。
最初の段階では、アジャイルコーチはチームに問題があるかどうかを観察し、その課題に対してチームがちゃんと踏み込めるようにお膳立て(ファシリテーション)します。
具体的には、振り返り(retrospective)の効率的なやり方としてタイムボックスを提案してみたり、ときには簡単なワークショップもその場でやったりもします。
僕たちのチームの最初の課題として、KPTのproblemが浅く、tryの理由づけとして機能が弱かったというのがありました。
それを解決するのになぜなぜ形式でチームに問題の掘り下げをさせ、ボトルネックになっていることは何かということを追求させました。
やってるのはあくまでもお膳立てですが、ちゃんと現場の課題に踏み込みます。
コーチはそうした観察とデウスエクスマキナのような(だとちょっと言い過ぎかもしれませんが)交通整理を繰り返して、ある程度になった時点でチームを信頼して任せてくれたと思います。
決して教科書読ませてワークショップやって良かったねして、あとは自分でやれという感じではないです。
(新入社員の初年度研修などはそういうふうにせざるを得ない事情もあると思いますが・・・)
アジャイルコーチ、何となく良さそう!
アジャイルコーチとして、ファシリテーションの技術だけでなく、アジャイルに限定しない問題解決のプラクティスの引き出しが重要になると思います。
あくまで個人として感じたことですが、いいコーチはチームの困ってることを助け、自信を着けさせてくれると思います。
皆さんがアジャイルコーチというロールについて知らなかったのでしたら、「何となく良さそう」と思ってもらえるとうれしいです。