【勉強会】Deveropers Summit KANSAI 2016
20160916 DevSumiKANSAI2016
これに行ってきた
クラウドの発展とデベロッパーの役割について
- グロースエクスパートナーズ 鈴木雄介さん
www.slideshare.net
クラウドがもたらしたこと
- 非機能要件をコーディング出来る
- ITサービス運営のスピードアップ
- 開発のみが早いだけでは価値は出ない
- システムを動かしてビジネス価値を生み出す
Agile
WFの課題
- 欲しい最終成果物が、進めるうちに変わってしまう
- 中間成果物では品質は確認できない
Agileのメリット
- 「今」欲しいものを得られる、後でいいものは次に
- 定期的に評価ができる
DevOps
ダークカナリア
- 開発者だけがアクセスできる本番環境
- 更新系はやらない、検索エンジンとか
カオスモンキー
- 非機能のテストは本番環境でしかできない
- 自動化スクリプトのテストは本番環境でしかできない
MSA
MSAの注意点
- 巨大なシステムをいかに管理するか
- アプリ管理ではなく、システム全体の管理
- 設計指針ではなく、結果論
- MSAで再構築するのではなく、少しずつトライするべき
- １システムではなく、企業全体のシステムが対象
どうサービスを分けるか
- ドメイン（問題領域）≒業務
クラウド時代のDeveloper
- IaaSのコード化は実質コード量が多い
- PaaSがいい、制約に従えるなら
- 技術の選択
- 何に最適な技術なのか
- 流行っているかは関係ない
- スペシャリストorゼネラリスト
- ビジネスパーソンとしてのデベロッパー
- コミュニケーション能力、プレゼン能力
- チームビルディング
正しいものを正しくつくる
- ギルドワークス 市谷聡啓さん
www.slideshare.net
Do the Wrong things Wrong (DWW)
「間違ったものを、間違ったまま作る」
- わからないことを、わからない人同士で、昔ながらのフェーズゲート開発
- どのような状況で、どのように作れば正しいか
- 正解はない、何が適切か、問い続けながら進める
解決策＝アジャイル開発、なのか？
Agile/Scrum
Do the Wrong things Right（DWR）
「間違ったものを、正しく作る」
- 作り方のみ正しくしても、何を作るかがわかっていない
- 間違っているか？という問い自体が存在しない
- 仮説検証のプロセスが実施されない
プロダクトオーナーが絶対正しいのではない
- そもそも経験が足りない
- 人の一生で、ソフトウェア開発はたかだか３００人月
- 理想的なプロダクトオーナーは現実にはいない、と思っていい
忠誠を誓う対象は「目的」
- プロダクトオーナーでも、エヴァンジェリストでもない
- 上司でもユーザでもない
Do the Right things Right（DRR）
- 正しさとは、絶対的なものではなく、相対的なもの
- ここでは、目的により適合するものが、より正しい
- Start with Why（Why→How→What、ゴールデンサークル）
正しいを探すアプローチ
- 顧客開発
- 人と時間とお金をかけてモノを作ってから顧客を探すより
- 顧客を探してから、必要なものを作る
- リーンスタートアップ
- MVP：Minimum Viable Product
価値探索
- ユーザインタビュー
- プロトタイプを作って検証
- 仮説キャンバス
- ユーザストーリーマッピングでのMVP特定
MVPは実用最小限、といいつつ現実は、MVPが重くなりがち
- 本来は検証のはずのMVPが、重厚なので、MVPで事業スタートしてしまう
- MVPよりもっと小さい単位で、何度も実験して、学びを揃えてから、つくる
- 正しいものづくりに正解はなく、問いのみがある
日本で世界最先端のDevOpsチームに追いつき、追い越す方法
- マイクロソフト 牛尾 剛さん
DevOpsの本質
DevOpsには明確な定義がない、目的を明確にすることが重要
GeneKim'sのThreeWays
- 1way：リードタイム短縮
- 2way：本番環境・ユーザからのフィードバック
- 3way：継続的な実験と学び
- どれだけ準備しても障害は起こる
- 本番環境はない、検証と学びの場と考える
MicrosoftのDevOpsの歴史
QA＋Dev＋Ops＋Business ↓Agile Engineering＋Ops＋Business ↓DevOps Feature
- QAとかOpsがコーディングをするわけではない
- チームを統合して話をするようにした
導入ステップ
- DevOpsのプレゼンテーション
- 自分の組織のDevOpsとは何か共通認識を。
- ValueStreamMapping
- リードタイムとプロセスタイムを書く
- 文化とギャップ要素のインストール
- DevOpsハックフェスト
- 実際にやってみる
- モニタリングと継続的改善
文化とギャップ要素のインストール
西洋文化
- アメリカと日本のギャップは生産性の違い
- 生産性の違いは、物量の違い
- 同じValueを少ない時間で出す
BeLazy
より少ない時間で成果を最大化する「エッセンシャル思考」 * 例えば、優先度の話
アメリカで1番のDevOpsチームに入った話
新しいことをやっているわけじゃない、当然のことを当然に
- Focus：集中、に重点をおく
- ペアプログラミングをがっつりやる
- 朝会
- カンバン
- テレメトリー、メトリックのトラッキング
- Fチーム・Lチーム、新規開発チームとバグ修正割込系開発
- FとLの最長者を常に入れ替え続ける
エンジニアの教育と成長についての課題と、組織で行っていること
- はてな 大西 康裕さん
- さくら 江草 陽太さん
意識の高い人を採用→ルールの徹底→文化の醸成
はてな
採用時のポイント
- 表層的でない知識
- 成長意識、向学心
- エンジニアリングセンス
評価指標を明確にする
- 成長：目標に対する結果が出せたか
- 行動：適切なプロセスが選択できているか
- 専門性：業務遂行に必要になるもの、ただし達成・未達成が基準でなく成長目標
自発的な活動を促進する
- チーム内の技術エントリー、個人ブログ、ブックマーク数で報酬あり
- 技術エントリーの読み上げ、共有することで活発になる
- 技術勉強会、持ち回りで20分発表、テーマはなんでも
- 技術書購入→書籍レビューを共有
- 勉強会・輪読の補助、だいたい続かないので、最後まで続いたら打ち上げ補助
- 実績の公開は、個人が比較されてプレッシャーになるのでやめた
情報共有
- 可能な限りグループウェアを統一する
- チーム内の共有、新規参画者も入りやすい
さくら
課題
- 中途の即戦力が多く、成長を支える仕組みがなかった
組織としての方針
- X理論：人はもともと働きたくない
- Y理論：働きたい
- X→Y理論ベースへ転換し、自主性を尊重するようにした
- ルールを緩和して、自由に働けるように
カイゼンの基本 ～組織・プロダクト・プロセスをどう改善するか～
- Ryuzee.com 吉羽 龍太郎さん
Done is better than Perfect - Mark Elliot Zuckerberg -
カイゼンとは？
- 自分たちの仕事を「安全に」「簡単に」すること
- ７つのムダ「作りすぎ」「手持ち」「運搬」「加工」「在庫」「動作」「不良を作る」
- 忙しいからカイゼンできない、ではない、カイゼンできないから忙しい
- 時間ができたらやる、ではずっとやらない
カイゼンのペース
カイゼンの型
- カイゼンの方向性を、全員が理解・再認識する
- カイゼンの場では、現在の状況整理、次の目標設定、これを繰り返す
- 全体最適か、部分最適か、状況によるが、まずは穴がある部分から埋めるべき
- バケツリレーの例、超高速でバグを作ることになる
品質
- 100％良品であるべきだが、不良は起きる
- 何か起きたら自動で知らせる仕組みを入れる
- 不良が起こるのは、標準化・合理化が不十分なため
- 達成に対するプレッシャーをかけすぎない、それ自体が問題を引き起こす
自働化（NOT自動化）
- 自動システムを監視、異常を検知したらシステムを止める仕組み
- ひとりの人間が多数のシステムを管理できる
効率より効果
- 穴を塞ぐこと自体に効率を求めない、早く埋めるべき
ムダをなくす
- 不要なものは捨てる、いつか使うかも？は大抵使わない
- 必要なものはJustInTimeでとり出せる
- 活動を維持する、場合によっては強制力も必要
一気にやらない
- 達成しないし、失敗したときに戻れなくなる
見える化
- 見えないものはカイゼンできない
- ValueStreamMappingも手法の一つ
- 記法は「トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!」
- ValueStreamMap作成手順→作業の洗い出し、順序付け、成果物の定義
- 「止まる」「遅い」「戻る」の洗い出し
チケットの在庫管理
- チケットが多くなりすぎると管理できない、優先度つけられなくなる
- 本当にそんなに必要なの？必要ないチケットがまざってない？
- 捨てる基準、捨てる工程を定義しておく
カイゼンのパターン
- Eliminate（消す）
- Combine（統合する）
- Rearrange（入れ替える）
- Simplify（単純化する）
チーム
個人の成果ではなく、チーム全体の成果を上げる
- 人数が多いと、それだけで無駄な仕事が生まれることがある
- 組織が恐怖で支配されるとカイゼンが難しくなる、個人の成果が求められるから
チームの能力を見える化
クロスファンクションで、誰が何をできるか * エース、プレイヤー、監督 * 何ができる、何がしたい、をつけて成長させる
タックマンモデル
チームは進化する（形成、混乱、統一、機能）
まとめ、カイゼンの進め方
- チームで全体で取り組まないと意味がない
- 目標を立てて、結果を数字で見えるようにしておく
- 知恵を活用、ツールに頼りすぎないこと
- 漏れを無くす
- 今が最高だと思わない
- 試してみてダメなら他を試す、言ってしまったから変えられないとかNG
