2019-04-10 DevOps Days Tokyo 2019 Day2
2019/04/10 に開催された DevOps Days Tokyo 2019 Day2 のイベントレポートです。
■Day1の様子
■Welcome to DevOpsDays 2019, Day Two!
Alex Papadimoulis さん
Sho Sato さん
●DevOpsDays Tokyo
・2017: Two DevOps Principles
チームをまたいだコラボレーション
Dev, Ops, QA, Management etc
できる限りすべてを自動化する
Builds, Deployments, Infra etc
・2018: DevOps in Japan
エンプラ系企業が興味を示している
SI系企業はDevOpsを検討している
・2019: DevOps is for Everyone
あらゆる組織で実現は可能、巨大なエンプラでも
特殊な誰かのためだけのものではない
エンジニアやTechサイドの人間だけでは実現できない
・ #DevOpsDayTokyo で 1200+ Tweets
●Agile Japan Community
アジャイルは日本に深く根付きつつある
実行委員の多くがはじめてDODaysに参加
情報交換できた
・コラボレーションミーティング
Asgile isn't enough, you need DevOps
Automated testing can be improved through DevOps
Focus on customer
●ビジネス価値
・Cool Japan 2008: ガラケー
5年後使っているか？
・マーケットは常に変化する
携帯電話はスマートフォンにリプレイス
時代の節目に対応する必要があった
・DevOpsの新しい時代が始まりつつあるのではないか？
■スポンサーセッション: SoftBank
●今日来ているのは業務システムの開発・保守をしているチーム
・ほとんどはウォーターフォールで堅実に
・MVNO参入など、タイムリーな提供が必要になってきた
●DevOps、アジャイル開発にも3年前からチャレンジ
・成功事例もありますが、失敗や苦労もたくさんありました
・情報共有しましょう！
■スポンサーセッション: Solace
●Solace
・カナダの300名ほどの会社
日本は2名
・DevOps, Agileなどでも使うインフラ提供
●EventBroker
・EventDriven な Microservice への潮流
Data中心から、Events中心へ
モノリスから、UI->各サービスへ
●日常の中のイベントドリブン
・寒いな -> 暖房つける
・従来型
クライアント: 暖房つけて
サーバー: つけました
・イベントドリブン型
クライアント: 寒い
EventBroker:
エアコンサーバ
ダウンジャケットサーバ
他のBrokerへ
●EventMesh
・マルチクラウドでメッシュ状に張り巡らされたBrokerが連携
●DigitalRiver
・Lakeに対して、流れを作っている
・APIレイヤの受けに川を作って、アダプタを抜き差しする
■Five Development Practices for Agile DevOps
David Bernstein さん
●アジャイル
・デミングさん
アジャイルの父だと思っている
アイデアを補完するアプローチ
・元はアメリカの製造業のようなやり方だった
5年間このやり方でできた
アジャイルで良くなっていった
・ジーンキムさんの本で感銘を受けた
ソフトウェアのことをわかっていない状況だった
ここから大きく変わった
・「スクラムしかいらない」という間違い
スクラムは、入り口
●素晴らしい開発者を知った
・100倍以上の生産性
・話してみたら、考え方、見方、プラクティスが違う
・つかう言葉が違っているかもしれないが、特別な人ではない
・我々でも学べるスキルを持っている
・誰でもなれるかもしれない
・プラクティス、原則
オープンクローズドの原則がはじめにある
5つのプラクティス、12のデザインパターン
30くらいのプラクティスを理解できれば、我々もなれる
●チャレンジしているのは、持続可能なソフトウェアの開発
・リリース後にコストがかかる
ライフサイクルで見ると保守が、5倍のコスト
開発後のbugfixには、初期開発時の2倍のコスト
・メンテナンスできるソフトウェア
理解できるプロセスをつくるということ
・物事の関係性を見て、新しいものを構築する
・コンピューターのためではなく、人とのコミュニケーションのため
コミュニケーションの裏でコンピュータが動く
・コンピュータだけでなくいろいろな分野に使える
●ソフトウェアは他のビジネスを自動化する
・われわれ(ソフトウェア開発)の業界は自動化が難しい
・このためのアプローチがDevOps
宝物は、継続的な開発とテスト
UTの品質で変わってくる
UTで継続的に開発できるかを判断できる
●書籍
・レガシーコードを越えて
Beyond Legacy Code の翻訳
夏に発売！
・9のキープラクティス
プラクティスを進めるためにはみんなが分かる必要がある
devが理解できる方法
managerが理解できる言葉
・stakeholderが理解できる言葉で書いた
アメリカのアジャイルでは行われてこなかった
・HowToではなくWhyToの本
●質問
・Scrumやっている？
-> たくさん
どのくらいの期間やっているか聞くと、最長で5〜7年
技術的負債が溜まってくるから
・XPやっている？
-> たくさん
スクラムギャザリングでは3人しかいなかった
・CIやっている？
-> たくさん
・TDD / ATDD は？
-> 3割くらい
●アジャイル宣言
・ソフトウェア開発者が、ソフトウェア開発者のために作った
・アジャイルはビジネスになってしまった
作ったメンバーは、ソフトウェア開発者の手元にもどしたい
・Agile Software Development with Scrum
スクラムは、XPをよりスムーズに進めるためにある
●継続的に結合する
・ウォーターフォール
9ヶ月目で、6ヶ月遅れていることに気づく
integrationは痛みを伴うから、後に回したい
・小さく頻繁に進めれば痛みではなくなる
開発者のPCでローカルのテスト -> build -> テストサーバ
・すごい開発者がいる
ファルコさんとか有名になる
1分に3回テストしている
これだけフィードバックが得られればスーパーパワーを貰える
・お客さんのフィードバックの源はビルド
・プロジェクトのハートビート
間違えていれば教えてもらえる
3週間後にQAから教えてもらう、ではかなり時間がかかる
●3つのdone
done : feature開発、開発者のPC
done-done : build server
done-done-done : コードがクリーン、サポートできる、理解できる
・どのように構築すればメンテが楽になるかを理解することがスタート
・品質を理解する = 費用とコストとのトレードオフ
●継続的にデプロイ可能であること
・契約、季節、ビジネスの要因で納期が決まる
・常にリリース可能にするとムダが少なくなる
・目隠しされていたら、歩いてくださいはむずかしい
フィードバックが大切
●ビルドを自動化する
・ワンクリックで使える状態にしたい
・朝早くいくと、誰もいない、仕事しやすい
後ろに友だちが来たが、気づかなかった
テストを動かしてgreen
ちょっと考えて、もう一度実施してgreen
「なんで2回動かしたの？」
-> 気持ちいいからw
こういうことだと思う
・早い段階で統合、リリースする
●最初の一歩を踏み出す
・CIをやろう！
・あるならよりよくやろう！
●XP
・失敗しているプロジェクトのメンバーたちから生まれた
・オープンなスペースで、全員参加でXPしている
●コミュニケーションとコラボレーション
・開発者はマニアだと言われる
・開発者は意外とコミュニケーションが得意なはず
システムという複雑なものを、チームで作っているのだから
●ペアプロ
・導入が大変なものの一つ
マネージャーが嫌がるから
「リソースの半分をそっちにとられるのは嫌だな」
-> 開発者はリソースではない
・一人ではできないことも、複数人ならできる
重いテーブルを動かす
と同じことが、開発にもある
・二人で話していると、割り込みが入りにくい
・情報のシェアがスムーズ
・ペアリングは、パワーを使うが、充実感がある
・バディプログラミング
一人で作業するが、最後の1hだけバディと作業
ここからペアプロに入るのも良い
●スパイク、スウォーム、モブ
・モブ
技術的負債が多すぎる会社で生まれた
みんなで集まったら、1年ぶりにコードが書けた
社長が進捗に喜んで、世界中に広めている
・スパイク
わからないから時間を区切って調査
解決したか、新しい疑問が出たかを把握
・スウォーム
新しい課題がみんなに影響するなら、みんなで調査
●不明点のためのタイムボックス
・emergent design
わからないことは時間を決めてリサーチ
構築前に話すと、タラレバになってしまう
・ATDD, BDDは事例でテストしているから良い
脳も同じで、事例が必要
●コードレビュー、レトロスペクティブ
・ペアリングしていても、コードレビューは必要
・なぜこのプラクティスを使うのかを話せる
●常にメンタリングし、メンタリングされる
・人だけでなくアイデアも
●プラクティス5: クリーンなコードを書く
・20年前はなかった
・アジャイルな人たちから、プラクティスが生まれてきた
●定性的だけでなく、定量的に測定できる
1. 品質の高いコードは凝集度が高い
1つのことしかやらない
オブジェクトは1つのことしか考えない
アジャイル宣言
品質に向かうとアジリティが上がる
2. 品質の高いコードは疎結合
バラバラに検証できる
拡張性も上がる
3. 品質の高いコードはカプセル化されている
やっていることを外側にする
詳細を隠すと、他では依存がなくなる
多くのコードが手続き型
カプセル化しなくちゃ
4. 品質の高いコードはアサーティブ
自分中だけで仕事ができる
５．品質の高いコードは冗長ではない
redundant 2つのことをやろうとしているのは冗長
コード品質が私達を導いてくれる
品質を向上させるなら今日！
●プラクティス6 先にテストを書く
・TDD is dead と言われている
失敗した人たち
多くのテストを書きすぎ
実装に依存している
・使い方が間違っている
・リファクタリングしやすくなる
・BDD, ATDDでテストを書く
・私達がテストと呼んでいるもの
Acceptance tests -> Customer tests
Unit tests -> Developer tests
Other -> Quality Assurance tests
・内容を理解できて、コミュニケーションできる
・品質保証
TDDはQAを代替するものではない
適切にできていることをテストすることはできる
人の命が関わるソフトとメッセージングソフトでは必要な品質が違う
・良いテストを書く
同じ理由で失敗するテストは他にない
unit testはコードの単位ではなく、振る舞いの単位
・TDDは迅速なフィードバックを提供
チームでやると10倍くらい早くなる
・TDDはリファクタリングを助ける
パーティするよ、家に帰ったらキッチンが1ヶ月掃除していないから汚れていた
コードも同じ。まず掃除。
・テスト可能なコードを書く
寝ながら、映画を見ながらでもできる
・TDDで失敗したプロジェクトをよく見る
スクラムコミュニティでも10%くらいXPを実施
そのうち10%くらいが正しくTDDしている
つまり １％くらい
・チームに導入する
「どうやったらTDDを導入できる？」
開発者に強制することはできないよ
効果が理解されれば使ってくれる
・「テスト熱中症」になる
TDDでなければプロジェクトに参加しません！のレベルまで
●プラクティス9: レガシーコードをリファクタする
・マネージャーとのやり取り
「2週間かけて、チームでリファクタするよ」
「なぜ？」
「より安く変更できるようになるから」
・メリット
コストが下がる
理解できる
UTできる
新しいfeatureを追加できる
更にrefactorできる
・投資？借金？
このアクションをテストするか？
1回で柔軟にしたい
技術的負債をすぐ返す
deadbeatになろう
クレカを1回払いでしか使わない
・変化に対応するためのリファクタリング
変化が怖くなる
文化を変える必要がある
・オープンクローズドのためのリファクタリング
拡張にopen、修正にclose
最終的なものを変える
これをできるだけ小さくする
欠陥のリスクがあるから
・2 stepに分ける
クリーンにする
修正する
・2度目に正しくやる
1度目では理解が難しい
2つ例があれば、抽象化して理解できる
・真のアジャイル精神
アジャイル宣言
継続的デリバリー
継続的インテグレーション
QAが別なら、なが～いライフサイクルが並走している
●Q: ペアプログラミングでレビューは早くなる？
・ペアでテクニカルな部分を見る、レビューでは大きな観点で済む
●Q: レビューがテクニカルな問題しか見ないのは、文化がおかしい？
・ペアを進めていくうちに、信頼関係が広がって行く。
●Q: 理解度が違う時はどうする？
・1人が進んでいるときは、教える機会。
・説明することで学ぶ。
・ペアリングは同等の立場、役割。
■Wasted Gold Mine & What Data Can Do To DevOps
Kohsuke Kawaguchi さん
●プロジェクタの接続が悪いので、Jenkinsのはじまりの話
・15年前、CVSだった
・Sunで働いていた
JavaEEでXMLを扱っていた
・いにしえのCVS
ディレクトリを間違えるとコミット漏れ
よくあった
・電話を受けてチェックすると、コミット漏れ
10 minに一回くらいチェックしていた
・Jenkins生まれることろまで行けずw
●やっていること
・Jenkins
ボトムアップで利用が始まる
規模が大きくなるにつれて、管理が必要になってきた
・cloud bees
OSS と 会社の2つのレバーで動いている
●最近の自動化
・Pipelineが流行ってきた
・ValueStreamで考えるとごちゃごちゃがつながっている
・個々の部品は自動化されているが
全体が把握できない状態
個々の内容を把握しないといけない
・デジタル廃棄物
捨てられた古いサーバには金の部品がたくさん
掘るよりゴミを漁ったほうが早い
・ソフトウェア開発の現場でもデータを大量に捨てている
●Cost/time trade-off
・Situation
100s engineers
10s projects
1 shared jenkins infra
100,000s AWS cost
・CFOから質問
このインフラ費用、どういう効果があるの？
・用意してあったしかけ
小、中、大のjenkinsインスタンスを選べるようにして満足していた
処理時間とコストを可視化して解消
●Whose problem is it?
・Situation
1000s engineers
1 DevOps team
・Question
インフラが1箇所コケると、アプリエンジニアにスパムエラー通知
・正規表現で切り分けた
70年代の対応だね
Bayesian filter
受けた人が、俺の問題じゃないよボタン
●Knowing where changes
・Situation
~80 devs: Dev > QA > Ops
10s microservices
frequent promotions apps
・Question
Dev環境に入ったのって、いつQAに来るの？
入った内容って何？
・ValueStreamMap
Stageに入っているコミットを可視化
-> コミュニケーションで得ていた情報を見えるように
自動化の効果は、必要な情報を必要な人が見えるようにできること
●事例をまとめると
・DevOpsが必要なのはわかっている
・ボトムアップではじまる
・まだ組織的に取り組む方法が見えていない
●定量的なデータをつくることが必要
・技術者にとって大切なこと
知らない人に伝えるためには、数字が必要
・外部の人も含めて効果を理解してもらわないといけない
・利益につながっていかないと続かない
●Smarter testing
・Step1: 依存関係分析
1つのリポジトリで管理
物によってテストが時間かかる
依存が関係なければテストをスキップ
・Step2: Predictive Test Selection
10万単位のコミットから1%を抽出
リグレッションテストに効果があるかを判断
-> 1/3のテスト
AWSコストは半分
バグの混入は 0.1% 増えただけ
●Deployment Risk Prediction
・SRE team
・数百人が毎日デプロイ
-> 何が起きているのかわからない
・機械学習
・40,000 deploy 100 failure
・app names, commit message
・効果
・99% を予測可能に
・false positive は5%程度
・対応
危ない時にサポートメンバをアサインしないとデプロイさせない
チームメンバーの判断はあてにならない
長くメンテされているシステムは、危険度が高い
レガシーコードだから感覚的には当たり前
定量化できると、リファクタの必要性が判断できる
●事例の気付き
・大きい会社でないとできない学習効果
この差は開くばかり
ユニコーンとドンキー
・Donkeys
開発チームが別々で独自の文化
中央にDevOpsチームができても、村の手助けは難しい
宣教師を送り込む程度
村の人々は、わかってないのに口出すな
・Unicorns
我が社のやり方がすでにある
アプリチームは、自由度が下がる間隔ではなく
面倒な部分をやっといてくれてありがとう！
カリカリに作り込まれていて
他の方法を選ぶ余地もない
これは成功の要因になっているはず
●Gapが大きすぎる
・どう進めるのが良いのか？
well-funded DevOps teamは必要、つぎは？
成功事例を作って、他を巻き込む？
古いものは忘れて、グリーンフィールドに注力？
クラウド移行やマイクロサービス化に併せて実施？
●Q: 外部サービスを利用するようになってきた、これはどう思う？
・ソフトウェアを開発するコストが認められる様になってきた
・これからも広がっていく
●Q: 学習モデルの、deploy危険度を判定結果はどうエンジニアに伝える？
・モデルの精度を上げてから伝えた
・何をしていくかは課題
●Q: 自社はダメなパターンで進んでいる。どうすれば？
・NGパターン
DevOpsチームが製品を、開発チームに売っている状況
-> 村ごとに差ができてしまう
・成功パターン
mono repoで、ビルドスクリプトがそもそもないとか
-> 面倒な部分を引き受けてくれてありがとう な状況をつくる
・売り方の問題なのかもしれない
■開発効率を最大化するデプロイメントパイプライン
Genki Sato さん
●Yappli
・モバイルネイティブアプリをブラウザ上で構築、運用できる
・どちらかと言うとエンタープライズ向け
・サービス継続率 99%
●状況
・開発開始から 6年
・チーム開発期間 2.5年
・技術的負債がリリースサイクルに響いてきている
●つくり
・設計上、IDEの恩恵を受けにくい
フレームワークなし
テストつくりにくい
混ぜるな危険不具合
ピタゴラスイッチな不具合
・これまでに感謝しつつ、再構築中
Golang+Nuxt.js
UIも全面刷新
・チームのスケールに比例させたい
●うまくいったポイント
・全面刷新は2回目、失敗を活かせた
全社で共有されていたから合意を得やすかった
・機能追加しないことを決めた
・設計段階から、エンジニア全員で勉強 & コンセンサス
選定基準は抽象的に
・DDD、設計相談、コードレビュー
・チーム全員で集中する体制
新規機能開発を一時的に止めた
プロジェクト以外のことに集中する日
2週間に1日、メイン以外だけ
ビジネスサイドの改善を取り込んだ
●開発サイクル
・開発プロジェクトの入り口
従業員起案
事業戦略ベース
開発・運用ベース
-> 営業、CS、開発などで優先度を協議
・Protocl Buffersでレビュー効率が上がった
使用の確認と合わせて実施
uber/prototoolでチェック、フォーマット
json schema & HTMLドキュメント の2重メンテが要らなくなった
・lint / UT/ IT を CircleCI
・全部通らないとmergeできない
・個人作業はforkしたリポジトリ
-> 通知を全社向けから切り離した
・チェックポイントが増えて、影響が広がる前に検知できるようになった
●どう品質を担保するか？
・リリースサイクルは週次
・QAの検証は2step
単体検証
全体検証
・混ぜるな危険、ピタゴラスイッチな不具合を検知
・単一機能ごとに全体検証はコストがかかる
・週次にまとめてコスト削減
・顧客からも良いリリース頻度
●環境
・環境は10set
・GitLab flowライクなブランチとの紐付け
●インフラ構成
・Terraform
IAM含めた初期構築がメイン
更新頻度の高い運用設定もアプリとセットで管理
・顧客フィードバックはCS経由
・本番環境でE2Eテスト
・モニタリングはDataDog
●Q: 設計を抽象的にしているねらいは？
・レイヤードアーキテクチャ使います とかだと、理由がわからなくなる
●Q: コードとドキュメントの整合性はどう担保している？
・ドキュメントは画面遷移程度
●Q: 他に失敗したから変えたことは？
・チーム全体で進めるようにした
■Data-Driven x DevOps
Masato Ishigaki さん
●プロダクトをグロースさせる文化をつくる
・売上を上げる、利用者数を増やすの観点だと DevOpsだけだと弱い
・Data-Drivenを併せて考えている
●仮説 -> 開発、Rel -> 効果検証
・役割
Data-Driven : 仮説の妥当性を担保して
DevOps : 高速にMVPを構築、デリバー
Data-Driven : 効果測定をして分析
・直感に頼る仮説は量産されやすい
・普通の人が、売れる商品を考えるにはdata-drivenが必要
●BMLループ
・Agile, DevOps, Data-Drivenを割り当てている
・今日はData-Drivenの部分の話
●Product -> Measure
・データを集約させることが最優先
・誰でもクエリできるように
・ユーザ属性を蓄積
・プロダクトをリリースした瞬間に、ユーザー行動が可視化される
●Measure -> Data
・ビジネス価値があるデータを可視化する
・ビジネスモデルを理解して KGI, CSF, KPI を決める
KGI: 中長期
CSF: KGI達成の要因
KPI: CSF達成の数値
LTV, CVR, CTR etc
・CSF/KPIは、定数ではなく変数であるべき
自分が影響を与えられない値は、変数
・CSF/KPIは、先行指標
どれが先行指標になるか？
相関指標を探る
アカウント作成
10日以内に複数の友達とつながる
-> この人はエンゲージメントする を発見
●Data -> Learn
・現状把握
・仮説検証型アプローチ
施策がどういう結果をもたらしたか
※鞍替えではなく、新しい決済手段を見るなら、ほかも見ないと
・探索的データ分析
ユーザー行動をベースにボトルネックを探る
ファネル遷移を可視化
●Learn -> Idea
・仮説立案の心得
・データの奴隷になってはいけない
・Data-informedな側面も必要
Data -> 意思決定
意思決定 -> Data
・定量と定性のバランス
すぐにリリースできても、使われないと意味がない
■Value Stream Mapping ワークショップ
h-arai さん
Kenta Sasa さん
●ValueStreamMappingとは
・ソフトウェア開発工程での、始まりから終わりまでの
工程と時間経過を見える化するモデリング技法
・全体を見える化することで、ムダや改善点を洗い出すことができる
●VSMの目的
・現状認識、目標決定
・改善点のみえる化
・関係者間の合意
●ワークショップの流れ
・スコープの定義
・プロセスの洗い出し
・VSM記述
・分析
（・改善点に優先度設定、計画に落とし込む）
・Fun! Done! Learn! でふりかえり
●スコープの定義
・チーム内でVSMで記述するプロジェクトを決める
メンバの実際の業務がベスト
・決まったらチーム内で内容をシェア
サービス内容
環境情報（クラウド/オンプレ）
●ムダ/改善ポイントの例
・待ち時間
・ムリ/ムラ/ムダ
・Value Add Time
・欠陥 -> 手戻り
・引き継ぎ
・フロー効率、リソース効率
・スタンプラリー
参加したグループのVSM
Fun! Done! Learn!
■DevOpsDaysなのにDevOpsって言ってないDevOpsの話
Kota Mikawa さん
●ヴァル研究所
・駅すぱあと
・みえる化
・MaaS
●歴史
・駅すぱあと
windowsソフトで始まった
・90年代に大ヒット
正著が追いつかない
人力で対応
・技術的な蓄積が滞る
暗黙知がはびこる
運用のためのツールが増える
運用チームはない
-> 秘伝のソース
・そんな中、世の中はwebとモバイルへ
->死屍累々
・もっとよくできるはず
・昼寝しながらでも成果がでるようにしたい
-> 変えていくしかない
●疲弊から脱出
・サーバ周りが負担でしかない
素人ではあるが、回していた
知識はそこそこ溜まっていた
物理サーバなのでスケールは難しい
ピークで落ちる
・AWSが日本にきた！
技術的にものめり込んだが
two pizza teamなどにも刺激を受けた
・Your Build it; You Run it.
2006から言っていた、早い！
●ツールも入れまくる
が、いけてるツールはこれまでのセッションを参考に
●結果
・運用負荷は軽くなった
・開発速度も上がった
・オーナーシップもめばえた
●いがみ合う営業と開発
・成果が出づらい
・障害対応でスタンスの違いで営業から吊るし上げられる
-> Phoenix projectを複数冊渡す
・僕らが目指していたのはなんでしたっけ？
「価値を届けること」は結果だった
届いていることもあった
・一緒になって働く、一緒に顧客を考える
営業を巻き込んでいろいろやった
ドキュメント改善
リリースレビュー
一緒にロードマップ
一緒にお客さんの元に行きまくる
一緒に数字を追ってみる
-> 価値観の共有ができてきた
数字でも成果が出てきた
共通の価値感があれば、ジェンガのように良い手が残っていく
■トラディショナルな企業でズンズン歩んだ積み木細工のDevOps
Takeshi Arai さん
photo by @fullvirtue さん
●トラディショナル
神が宿るソース
データとロジックが密結合
モノリシック
高い複雑度
組み合わせ爆発
10 x 10 なんて組み合わせ数はわからない
アルゴリズムを活用
forループをなくす
変数は3文字
-> 秘伝のソース
・課題がぼんやり見えてきた
Opsデータメンテ疲弊
ボールの投合
匠で回っている
・学びと文化の醸成
本を読みまくる
アジャイルから多くを学んだ
・ひとこそすべて
・学習する組織
ラーニング・オーガニゼーションが大切
小田理一郎さんを呼んだり
・ミンツバーグ
・知識労働者の生産性
人は資本財
・リーダーの役割
組織の雰囲気・環境構築
・文化の重要
会社組織に共有されているもの
外部から企業を見たときのイメージ
●適用しただけでは上滑り
・同時多発的に動きが起きた
・卒啄同時
親鳥とひなのタイミングが揃う
・人にフォーカスすることをどんどんやった
●結果
・壁一面にみえる化が進んでいる
・監査部門がモブワーク
・社内の各所で朝会
・AWSから通知が来るとダースベイダーが怒る
-> お供えする神社
・ボスが集まるあんどん
・おやつ神社
オフィスグリコもあるけど自給自足
・モブルーム
・VSMもいたるところで
・社内セミナー、勉強会もたくさん
・会社見学ツアー 1,000人達成
・NHKから取材
●コミュニケーションの飽和度
・8名 vs 400名 で同じ成果
-> コミュニケーションが濃かった
・媒体によって暖かさも違う
・ルールで縛るよりも、モラルになるように
・暗黙知化
マンネリはモラルに変わるシグナルかもしれない
・SECIモデル
・ナレッジ・エコノミー
成長は知識の主席に依存する
知識が内部に流れ込むフローをつくる
・なぜやったのか？
おもしろいから
・なぜやれたのか？
ミドルアップ
ボトムアップ
信頼貯金
よく働く
無茶ぶりにも対応
・エンジニアの生存戦略
世の中の常識を取り込む
・ヒーローを待っていても変わらない
答えは自分から
自分の意思で動くことが大切
人間がどの様に想像し、実行するのかがポイント
・カイゼン・ジャーニー
一人で行動を起こすと視界がひらけてくる
周りがついてこれなくて、心が折れたらコミュニティや本でも救われる
あなたは何をしている人なんですか？
足りないピースだったから、勝手に個人でかじを切った
社会、会社、個人ののぞみが重なる場所
何かを社内に持ち込むと
自動的にインストール、スケールされている
この現象はなに？
DevOps？アジャイル？カイゼンマインド？企業文化？
わたしにとってのDevOpsとは
現場で学びながら作り上げていった文化、場やカイゼンマインド
なのかもしれない
●Q: 組織としての構造の違いはあったのか？
・オフィシャルには変わっていない
・自分たちで活動を増やしていった
●Q: 秘伝のタレはどうやってなくなった？
・なくなってはいない
技術的負債を返すタイミングを逃したまま
でも、30年生き残っている
・秘伝のタレは残っているが、補強するようになった
ATDDなどもやっている
●Q: 拠点が別れている場合、どうコンテキストを共有する？
・雑談する、ご飯を食べるなど直接話す機会をつくる
●Q: ツール導入や営業を巻き込むのってどうやった？
・自前 -> 利用に切り替えた
・それぞれの人に併せて説明
■Conference Wrap-up and Live Review
Alex Papadimoulis さん
Sho Sato さん
DevOps Days Tokyo 2020 は 同じ日程で開催します！
場所は、ちょっと道が分からないかもしれませんがココですw
■感想
2日間を通じて、顧客に価値を届ける流れ全体がスムーズになるように、リードタイムの短縮、やるべきことに集中できる環境、仕組みを用意する、仮説検証を繰り返して、より洗練していく流れにソフトウェアを適用することで、定量化できる幅が増え、根拠に基づいた判断、機械的な予測ができるようになってきた事例をたくさん聞かせていただきました。
DevOpsの普及が進んで、ソフトウェア開発という業種にも自動化・自律化の可能性が見えてきたのをヒシヒシ感じてワクワクが止まりません！
登壇者の皆さん、運営の皆さん、すてきな場の提供をありがとうございました！
いいなと思ったら応援しよう！
