Overview
Report
WikiDevOpsDays Tokyo 2021
育児的ソフトウェア開発¶
20年ソフトウェアエンジニア
15年生産性にかかわって
10年ジェンキンス
Launchableって会社でやってる
日本ではあんまり浸透しないなんでや
ソフトウェア開発に向き合う姿勢や文化がちがうってことわかったから今回話したい
習慣の一つだけ移植してもうまいこといかない。いろいろなものが複雑にからみあってる。
アメ車が日本で使えないのと一緒
日本のソフトウェア開発文化にコンテナとかCI/CDとか一部取り入れてもうまくいかないよね
Product MindsetとProject Mindsetの違い？
ソフトウェアは生き物として扱わないといけない。
出荷したら終わりじゃなくて、今はリリースしてからが勝負
人の1日という単位のように、ひとつのサイクルを小さくしたらいい
今日一日どう育てるかっていうのプラス、5年後に大学行くとか考えないといけない
Sun Microsystemsにいたけど、リリースは年1回
そういうところだと、長期視点を考えるプロダクトマネージャーはいらない
育児的なソフトウェア開発ってなると、そのバランスを考えていく必要がある
転職すると色々覚えなおさないといけない
子を育てるんだけど、親も育つ
だから、親であるソフトウェアエンジニアも社員で入れる
子供がいろいろやってくれる事を期待するように、社員もそれがうれしくなる。
集団的知性
子供をよその家庭にだすのは大変だよね
この子供はずっとここで育てるかわからないとかになると、考え方も変わる
昔はインターフェースだけ議論して個人でやるって事が多かったけど
今は一つのものをみんなで開発するってことがおおい
人の出入りがあるのはいい面もあって、良いプラクティスが持ち運ばれたりする
運転免許の更新と一緒で、1番うけつけ、2番受付みたいに
スループットに専念したものである。
でも、レイテンシにフォーカスするべきだよね。
レイテンシにフォーカスしたら、ひとつのチームで全ての工程を担当することが合理的になる
Microservice
Service Mesh
Enterprise Service Bus
Streaming data processing pipeline
Queue, gRPC
Infra as-a-Service
そうするとこのような技術が合理的になって使われていく
WFでこれを使おうとすると、本来の技術的なメリットが得られない
和服で洋式トイレにいくようなもの
品質保証の考え方も違ってくる
品質保証のゴールは、サービスレベル目標のためにバランスさせる事がゴール
それが言い出せるようになるのも、開発とテストが別になってないから言える事
ある程度の緊張関係があったほうが、ちゃんと作ったりするよねって話で昔はよかったけど
今は、レイテンシが重要になったことで、敵対的な関係じゃなくて、変わってるよね
ビルは火事、船が壊れても、影響が一部分だけになるように設計されてる
Production traffic replay
feature flag
real time monitoring
circuit braker
blue green deployment
chaos engineering
これらの最近流行ってるプラクティスはそのためのものになってる
バグが起きても早く見つけて早く治せるようにするっていうこと
Datadogが世界とったとおもったら、いろいろ新しく出てきてる
今まで1分の感覚だったのが、5秒になったのが新しいんだよ
この時間の短さにお金を払う人がいる
自分の開発現場でこれらのテクノロジがなぜ根付かないのかってなると
そもそもの組織の文化がそれを適用して得する文化じゃないから
自転車はとまってるとこける、走ってるからうごける。開発も同じ
ある程度サイクルが開発サイクルが短くならないと合理的にならないプラクティスがある
スピード早い人はどんどん早くなるけど、遅い人は早くならない
コアなアルゴリズムに手を入れるのは怖いけど、
9個と一緒にはしらせて結果を比べる
一部を適用する
のような方法を取る
会社の規模が大きいとスケールメリットが生かせなくなる
やっぱある程度の垂直分業が必要になるよね
だから結局一部は横断的にみるレイヤーが必要で
だからどこを縦割りにするのか？って考えないといけないよね
Developer productivity engineering
- dev pipeline
- ci/cd
- gitops SRE
- container
- servicemesh これらは垂直分業と連動する技術の流れ
垂直分業が組織の生産性資産を生む
Googleに入ると、開発神システムがあって、誰でも生産性10倍になる
だからGoogle辞めたくないって人もいる
Project Mindset
ソフトウェアは家を建てるようなもの
改築は別口で
常時必要じゃない
ゼネコンに依頼して高い並列度
一方で、組織の生産性資産はどう作られる？？
ソフトウェア開発が効率的に行く仕組みをつくれないのか？
寿司はアメリカに行ったらカルフォルニアロールになってしまった
このような転換が必要になるかもしれないし
今のやり方を極めていったところにいい結果があるかもしれない
独自の道を行くなら・・・
西洋的な技術の潮流のどこが役に立つ？
日本的な技術の発展はどこ？
誰が先行してる？
ガラパゴスしてるんだったら・・・
どこに出島を作ってどう広げる？
誰の力が必要になる？
テクノロジーは、必要とされるからある。
必要のない場所で、テクノロジーを使っても労力の無駄になるよ。
だから、それが必要になるような組織・文化を作っていくんだよ。
Moving our batches to containers¶
Daouda Camara Rakuten
ギニア出身
ヌーは大移動する。大群で。
でも簡単じゃない、途中で命を落とすこともある。なんで移動するの？
生き残りのために移動する。草があるところ、水があるところに。
バッチを古い物理サーバーから移動するのも同じ
RedisからCouchBaseにした。
５％から２５％から５０％・・・と読み込み量を古いものから徐々に移行した
MLOpsの始め方¶
https://www.slideshare.net/slideshow/embed_code/key/GAnANL5paqskVl?feature=oembed
Shibui Yusuke Tier4（自動運転）
機械学習にDevOpsが必要な理由とは・・・
POCとかから次の段階に行くためにDevOpsが必要になる。
成長するかわからないプロダクトにはまだ不要
ここ１～２年はモデル開発から利用に変わっていってる
機械学習から始める→課題から始める
汎用機版から始める→評価から始める
技術的な課題から始める→リリースから始める
コンバージョン＝今バー所率＊クリック数
クリック数＝クリック率＊表示回数
表示回数＝検索数＊レイテンシー
ML入れる前と後で比較して、評価していく
そんで複数のモデルを比較する
決済戦国時代において、早く安全なシステムを提供するために with Azure¶
Rakuten
便利で速い、そしてお得なペイがかつる
だけど、これは決済である。。。安全安心が最重要課題になる。
ガバナンスやセキュリティもある
PCI DSS v3.2.1の要件
早くビジネスを提供したくても
セキュリティや法令コンプライアンスを確実に担保しつつ迅速に追随し便利なペイにする
現実：決済業務を安全に提供するためには検証が確実に必要であり遅くなる
１．共同責任の正しい理解
SaaSやPaaSを積極的に利用して責任委譲し運用コストをさげる
２．環境の論理的な分離（ネットワークセグメンテーション）
セキュリティレベルごとに環境を論理的に分割する
ツール用などの環境は自由度を上げたい
３．ACLを適切に設定する
利用者ごとにアカウントを作成し、ロールを割り当てる
４．セキュリティアセスメントを定期的に行う
利用や設定は利用者の責任なので、定期的に最新化する
SonarQubeやDependency-CheckやTrivyを導入する
５．ログを集める
アプリ・インフラのログ監視だけでなく、攻撃侵入検知もする。
法令に従い、ログを長期バックアップする
The Practice and Implementation of DevSecOps¶
Jihai Zhou Tencent
Imperial college london as a PhD
沢山のギンコウで働いてきた
2012にBarclays bank
2018にHSBC bank
さいきんテンセントにはいった
2012にDevSecOpsとは、Gartnerがつくった
2017にホットトピックになった
全員がセキュリティの責任を担おうってこと
DevOpsは速くてより良くて協調的なチーム
Cyber Security Assesmentに1週間かかる
Traditionalだと3週間＋1週間
DevOpsだと1週間＋1週間
DevSecOpsだとすべてで1週間
開発者がリスクをコントロールできるようになるだけでなく
開発プロセス全体が早くなるし、コストも削減できる。
DevSecOpsの状況
DevSecOpsに関心がある業界は
テクノロジー業界、銀行、金融であり、これらで５０％
開発者とオペレーションの人材比率は・・・
dev100:ops10:sec1
これぐらいが現状である
もっともっとサイバーセキュリティ人材が必要
Developerのうちセキュリティが重要だと考えてる人５０％
でも十分な時間をかけることができてない
Application Security Tool
Application Firewall
Container and application security
open source...
...
Static Application Security Testing (SAST) for Coding
IBM App Scan
Checkmarx
Fortify
Dynamic Application Security Testing (DAST) for Testing
Interactive Application Security Testing (IAST) for Operation
Free Open Source Security (FOSS)
IASTが今後の主要なツールになってくる
Phase one; tools
導入しただけ、開発者は何もする必要がなくて、結果を見るだけ
Phase two; training
Study tutorial in cyber security tools
Online Training - Secure Code Warrior
Phase three; mindset
チームの中にサイバーセキュリティーエキスパートというロールを設置
CheckmarxをCICD Pipelineにいれた
FOSSのSonatype Neuxs IQ Server
DevSecOps Maturity Model
5 expert on application cyber security and be able to guide and train
4 be able to implement advanced application cyber security skills in development process DAST IAST
3 min 20-hour training and earn the skill on top of owasp top10 in practial devsecops work
2 min 10-hour training and understand well on owasp top 10 in practical devops work SAST
1 min 2-hour training and understand the basic of application cyber security
アジャイル・DevOps時代のテストと品質保証¶
https://speakerdeck.com/player/cec844673d104f66b8a6b38305918e04?feature=oembed
楽天でアジャイルプロセスを対応してた
メルカリで品質とかをアジャイルにするぜのエンジニアリングマネージャ
組織・技術・戦略について話してきたのでこれをまとめた
現状：アジャイル、Devops時代になってきた
そーするとアジャイルなテストが求められている
短期間でのデプロイ回数が増加
海外のデータで、年毎やQ毎から週毎や日毎のデプロイ回数が去年と比べて増加してる
銀行とかの業界が多いアンケートなので、驚くこと。
機能テストシステムテストはまだマニュアルが主流だが自動化がすすんでいる
スプリント内の仕様設計実装テストというすべてのフェーズでテストする。
第三者検証はのこるんじゃね？
まとめ：スプリントの最後にテストをしない、そのためには？
継続的テストやCICDや自動化や・・・
テスト自動化は必然
コスト削減のために自動化したって目的が達成されない
リードタイム減らしたいっていう理由での自動化導入じゃないと
計画する時に、テストを分類していく
APIテスト、スモーク、リグレッション（ハッピー）、リグレッション（例外）
データドリブンでユーザが良く行う行動をもとに
価値ドリブンで機能や画面をお金に換算して
スモークテストは開発者もテスターも使えるからともかくやったほうがいい
マニュアルテストのただの自動化は失敗しやすい
機械だから並列でもりっとやるのに向いてる
自動テストをふやしてって、マニュアルをリファクタしていく
継続的デリバリ成熟モデル
Level -1: 後進
プロセスは振り返りせず管理もまだまだで後手後手
SaaSでWebdriver書かなくてもいいの増えてきた
我々が欲しいのはご意見番ではなくて専門家
バグのもぐらたたきに専念するんじゃなくて
品質にどれだけコミットできるか・・・
DevOps Interview¶
Patrick Debois ベルギー
2009年にDevOpsDaysをイベントとして開始
３－４年に一度ロールをかえてきた
テスター デベロッパー サービスマネージャー
DevOpsは摩擦を取り除くことだった
テクノロジを活用すると摩擦を取り除くことができる
サイロを取り除く
DevOpsやCICDに時間をかけすぎても成功が約束されない
事業部門との協力関係も重要である
失敗し無くなれば失敗しなくなるほど、お金をかけなくなる
DevSecOpsがうまくいったら予算がつかなくなる
パイプラインをせっかく作ったのに、
サーバーレスになったら、使わなくなった。
プロセスに対するトレーニング、なぜあるのかを説明する。
部門の摩擦を削除するのにどう役立つのか？
モノリスをマイクロサービスしていくという話があるけど、
1つの大きな問題を1000の小さな問題に分解しただけ。
オーガナイザーのツテが影響して、参加者が決まってくる。
スイスでは銀行の人がオーガナイザーだったから集まった。
中国ではテクノロジーにフォーカスしている。
Phoenix Projectではサクセスストーリーが書いてる。
ビジネスよりの書籍になってるので、これが使えるのではないか。
あとなぜコラボレーションが必要と説明するのが難しいのであれば、
失敗はどうしても起こるとか、そういう方向の説明すればいい。
デーモンエドワーズは、ビジネスに説明する時、
大きなメーカーに行って改善を説明した。
CEOはこれは面白いといったが、製品の値段を数セントあげたら同じ改善ができると言った。
つまり、効率を押して推進してもうまいこと行かない。
DevOpsは常に話し合ってより良い仕事をするためにある。
なぜ7人が同じ問題に向き合ってても効率的じゃないじゃないか。
これの論点と同じ、信条の問題。
もうソフトウェアはAしたらBになって・・・みたいな単純なものじゃない。
どうしても失敗があるし、協力してやっていく必要がある。
ObservationとしてアンケートしてFeedbackを集めてるけどいい方法ある？
あなたは伝えたい相手のPainに気づけてないのではないか？
子供に問題を説明しても無駄、問題に気付かせなければならない
何かお手伝いできますか？って聞いてください
変化する必要がない相手を変化させるのは不可能
もし問題があればそれの橋渡しをしていく事ができる
信頼されてないのではないか？
ちゃんとコミットしていく事が必要
これはテクノロジーで解決できない
Leading Engineers To Water¶
Michael miggs
The art and science of engineer coaching
エンジニアコーチになるには・・・という内容
馬を水のあるところに連れていく事はできるが、飲ませることはできない
エンジニアに水を与える方法、コツを教えようと思います。
井の中の蛙大海を知らず＝Think outside the box
箱の中でぬくぬくと過ごしてしまう
The Engineering Mindset
エンジニアはみんな、いい仕事をしたいと思っている
コーチの目的とは何か
tech & process advocate
team confidant チームの相談できる人 （チームの代わりにリーダーシップチームと会話する）
stakeholder
コーチにとって使えるスキル
Engineering
Counseling
instruction
technical evangelist
コーチはチェンジエージェントである
変化を引き起こすのは何か？
惰性や慣性はほんとうに強い力になっている
共感のコンセプト
Pity i am sorry for you
symperthy i feel for you
*I feel with you
*I am moved by you
このレベルの共感が必要
the trust and influence infinity loop
https://www.leadingagile.com/wp-content/uploads/2017/11/TrustInfluenceLoop-1.jpeg
Leading Agileの中のコンセプト
チームに影響を及ぼす前に信頼を得る必要がある
Focus on empathy
- embrace hearts and minds
- influence in your personal style
- meet people "where they are", not "where you want them to be" 殆どのテクノロジーの問題は、人が絡んでいる。
Problem solving process
問題を解決する方法・・・
緊急コールを受けるのはコーチではなくチーム
コーチはチームがそれを解決できるようにする手伝いをする
ステップ１：共感を示す demonstrate empathy
ステップ２：問題をチームに戻す hand the problem back
"what do you think youre going to do?"
"what have you tried so far?"
ステップ３：許可を得てから提案する ask for permission and give suggestions
"would you like some suggestions as to how to solve the problem?"
"would you like some tips and ticks that worked for me in the past?"
ステップ４：チーム自身に決定させる let them make their choice
Trust the team to make the choice that works for them.
the team owns all decisions throughout discovery gathering and implementation
ステップ５：祝福する wish them luck and follow up
コーチが使えるツール
- mob pro & pair pro
- immersive learning space (?) チームが道場に来て学ぶ？？、外の環境のトレーニング
- ハンズオンやワークショップ
- リモートツールやセルフラーニング
- 1年間50日の新しいテクノロジを学ぶ時間
- 共感
DevOpsの組織におけるテスト活動の在り方¶
https://speakerdeck.com/player/e8ec85f505e04151af9e4b2948684be8?feature=oembed
運用の人を一人見つけて、繋げて、招待する
そしてどんどんとパイプを太くしていく
テスターがテストコンサルタントとして行動する必要性
マインドと組織の変革¶
北圀銀行 東証一部 石川県 100店舗
13年前に入社した
中期経営計画にDigital Transformationする
銀行は真面目で誠実だが、多様性がたりない
役員とかに報告する時はすごいもんでもんでから報告する
下の人は上の人がいったことをやればいい
徐々にシステムの立場が上がっていった
もはや何のために誰のために仕事してるかわからない状況に
文化を変える事で、デジタルトランスフォーメーションを実現！（？）
やってみたこと
Phoenix Project
アジャイル勉強会
システム子会社の設立
クラウドとアジャイル開発
アジャイル先進企業との協業
ECモールで売ったり
地域活性化のPJを実行した
6/3にPhoenix Project無料体験
PFNのML/DL基盤を支えるK8sにおける自動化¶
PFNの事業を支えるGPUクラスタ
研究者からの大量の機械学習ジョブが流れてきて
オンプレのGPUクラスタでどう処理してるか・・・
Workloadの種類によってはAzureやGCPやAWSに飛ばす
計算機クラスタはどんどん進化してる
MN-3aサーバGreen500でLevel3で1位にもなった
MN-Coreという自社開発のやつをつんでるよ
MLDLワークロードなPodの効率的なスケジューリング
プリエンプション（優先度の低いPodを追い出す）
スロットリング
公平性のあるスケジューリング
ギャングスケジューリング（Podの集合を一度にスケジュール）
PFNにおけるK8sクラスタの利用状況
クラスタの構成概要
MN-1 Master3 Worker GPU168 CPU22
MN-2 Master3 Worker GPU128 CPU22
データセンターごとに独立のK8Sクラスタとして運用
MN-1a = P100
MN-1b = V100
MN-2 = V100 ネットワークがより強い
Device Plugin FrameworkでK8SにGPUを認識させている
Nvidia Device Pluginをそのまま使ってるよ
Podがリソースとして要求しGPUを排他的に利用する
全ノードがNFSをマウントしている、それをPodがマウントする
HDFSも使ってる
障害の自動化¶
障害の例 ― ノード
Kibeletが正常に動作しない事が最も多い
メモリがひっ迫、ディスクがひっ迫、PIDのひっ迫
障害の例 - GPU
電力供給の問題でボードが利用できない
ECCエラーが多発したり
GPUがビジーで利用できない
GPU交換しなきゃいけないことが結構ある
障害の例 - ネットワーク
リンクダウン
アドレス設定されてない
名前解決できない
ネットワーク輻輳
障害の例 - NFS
疎通できない、マウントされてない
障害の例 - Pod
コンテナが再起動しまくる
ゾンビコンテナ
D stateで残ったまま
クラスタが障害ノードの数のグラフ
もう常にどこかが壊れてるｗ
分散システムは完全な意味でアップになることはない
だから検知と復旧の自動化が必要になる
K8sで自動化していくぜ
K8sのConditionを使える
PFNではNode Problem Detectorとゆうのも使う
Ready, MemoryPressure DiscPressure・・・
１．メトリクスの収集 PrometheusとExporter
２．アラート発砲 Alertmanager
３．チケット起票 Alertmanager-to-github（PFN）
４．復旧対応
自動化済みの場合；Node-operation-controllerで復旧を自動実行
自動化してない場合：イシューを対応する
Exporter
- kube-state-metorics; k8s
- node exporter; general
- NVIDIA dcgm-exporter; GPU
- blackbox exporter; NFS
Node Problem DetectorをDaemonSetとして各ノードで実行してる
問題を検知しConditionの変更とかEventを作成している
GPUはNvidia-smiコマンドで障害の有無を見る
kube-janitorというのも使ってて
リソースを自動的に削除してくれる
- janitor/ttl
- janitor/expires
クラスタの管理自動化の取り組み¶
・実マシンを使ったクラスタを新たに構築
・検証用にノードを外したい、戻したい
・クラスタをアップグレードしたい
で、ClusterAPIがつかえます！
（そもそもバニラK8sをオンプレ使用は相当な覚悟が必要）
まだAlphaだけどCluster APIつかって商用利用してます
1.20.2 + 0.3.14
MAASでベアメタルを管理してるのでMAASinfrastractureProviderを使ってる
独立QAチーム1年戦記：スクラムの外からチームと組織の品質を創る道¶
https://speakerdeck.com/player/1bcf07882f414afc87c8a69740c9fab3?feature=oembed
2016年から内製で教育アプリを作り始めた
講演の4象限
１現実ｘ古いパラダイム
２現実ｘ新しいパラダイム
３理論ｘ古いパラダイム
４理論ｘ新しいパラダイム
あいつは耳障りがいいことを言うにかかわらず・・・っていわれるからやったよ！
問題の所在
2021年のState of testingをみたところ
DevOpsで働いているテスターが増えてきた
テスターがSCRUMチームに参加すると・・・
腕のいいテスターであるほど、問題だらけだという事に気づく！
さして重要じゃない不具合報告が入るしコミュニケーションもめんどいし・・・
SCRUMチームからハブられる
１独立したQAチームが支援する
２テスターが開発者として参加する
なぜスクラムチームに入らないのか・・・
スクラムチームがたくさんあって、ひとがたらんから
原則
ビジネスの成長
ボトルネックへの対処
継続的な改善
品質文化情勢
顧客こそ品質の評価者
データドリブン
テストはチームに還る
品質問題から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語¶
Ito Jumpei ウイングアーク１ｓｔ
帳票文書管理ソリューション事業：SVFやSPAのQAをしている
今日伝えたい事：事例紹介
Issue
システムだから不具合あるのはわかるけど、軽微なバグが多すぎるよ
社内の問い合わせも多く担当者がデバッカーのようになってる。
→QA監査として入ります
ユーザーの要望をスピーディーに構築して早く使ってもらいたかった
プロトタイプ開発のつもりであり、テストする時間なんてなかった
今まで通りの開発を続けたいので、お客さんの温度感はチームに伝えてなかった
→サイロ化していた（？）
全体像をみんなが理解するまでみんな質問しましょう
で、お客さんを呼んでユーザーシナリオを説明してもらう時間を設定した。
そして、ユースケースをまとた。
ユースケースの中には複数のシナリオがある。
ユースケースを全部つくって、シナリオをあつめて、Product Backlogにする。
品質良いものにしたらお金もっととれる
プログラマも品質もっとあげよう！ってなった
テスト計画書はISO 29119-3を使った
QAファネル
フェーズゲートQA
インプロセスQA：実務業と品質文化
QAコーチ：技術移転や品質文化の浸透
QAコンサルタント：技術移転や技術向上
QAプロモーター：QAを推進していく
Microservices¶
Sam Newman
DevOpsの定義についてパトリックに聞いたけど、、、
モノリスからマイクロサービス
マイクロサービスは個別にデプロイできるサービスということ
DevOpsと比べると技術的ですね
DevOpsはサイロを打ち壊しソフトウェアのデリバリーにフォーカスするという文化
サイロを打ち壊すことができなければマイクロサービスはペインを生み出す
DevOpsの組織やAgileの組織にならなければビジネスを失う
Microservicesは別に使わなくてもビジネスを失うことはない
自律的なチームがよりスピーディーに動くための方法
Microservicesは使う理由があるとき使える、使う理由がないとき負債になる
みんなやってるんだから、うまく機能しなくても自分たちのせいじゃないよね
何がやりたいのかっていうアイデアがあって、それにMicroservicesがあってるか検証する
Microservicesの場合は何か変更を加えたい場合、ひとつだけをデプロイしたらいい
パーツを置き換えるときの安全性
マイクロサービスが生きるか死ぬか、どれだけ効果的にサービスの境界線を引けるか
間違えて線をひくと、分散されたモノリスになる
分散されたモノリスは、ただのモノリスよりも管理が大変になる
モノリスから1つづつマイクロサービスを抽出していく方法
抽出してメリットがあるものを探す
クレジットカード情報のはいった部分はサービス化しやすい
そうすると、その一つのサービスだけ監査させればよくなる
上司はマイクロサービスには興味がない
だから、ユーザーの仕事がやりやすいようにしたいわけだから
価値が提供できるものじゃなければならない
モノリスから機能を抽出して目的を果たす
モノリスの役割は減らせれたけど、まだある、でもいい
上司にDevOpsを説明するときどう説得したらいい
じゃあ、マイクロサービスはどうやって説得したらいい
上司は何をよりよくしたいかにフォーカスして、説得したらいい
ボスはコーディングがしやすいとかは興味ない
・システムがよりスピーディーなる
・新しい人材を採用しやすい
とか・・・
アプリケーションがスケールしないから顧客ベースがスケールしないとか
方法論で反対が来るってことはない
アプリケーションを再構築するのに2年かかります
2年かかるって言ったらクビになる
大改革じゃなくて、ひとつの成功事例を作る
事業部が抱えている課題に直接関係しなければならない
開発者がハッピーになるだけの目的じゃ意味がない
安全に変更を加える事ができるようになる
Event Sourcingというのはテクニック
データベースを変更する時は上書きするけど
上書きするんじゃなくて積み重ねていく保存方法
マイクロサービスはそういう細かいテクニックを試すこともできる
やってみて、問題があったら戻せばいい
品質保証からすると、一部分を変更するっていうのはリスクある
マイクロサービスは、1つからはじめるもの、一気に作るものではない
3か月6か月サービスを作った後様子を見てください
機能テストは明示的なスキーマを使ってスキーマの互換性の検証をしたらいい
セマンティックという方法、E2Eのテストをしたほうがいい（？）
