伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション.pdf

by yosshi_

Slide 1

Slide 1 text

ç 伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション July Tech Festa 2020 @yosshi_

Slide 2

Slide 2 text

● 吉村翔太 ● NTTコミュニケーションズ所属 ● 経歴 SIer 6年、現職インフラエンジニア 2年 ● Kurbernetes 、Prometheus　 etc ● 登壇 CNDT “Kubernetes Logging入門” etc ● コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”

Slide 3

Slide 3 text

今日話す内容と割合 • この取り組みをしたモチベーション ( 10% ) • 既存の設計書の課題 ( 40% ) • 設計書のモダナイゼーション ( 50% ) – 書くべき内容や使うツールの話 ( そのうち４割 ) – 仕事の進め方や働き方の話 ( そのうち６割 ) 新しいやり方を考えるより既存の課題点を洗い出しとやり方が定着するように働き方を変える方が高コスト

Slide 4

Slide 4 text

この取り組みをしたモチベーション

Slide 5

Slide 5 text

インフラにおける大きな変化 Infrastructure as Code • Infrastructure as Codeとは – ソフトウェア開発のプラクティスをインフラに活かす仕組み – インフラをCodeで管理できるようになる • Infrastructure as Code導入のメリット – インフラのversion管理が可能 – インフラのCI/CDが可能 – 再現性の向上 – 環境構築に関する作業の短縮が可能

Slide 6

Slide 6 text

ウォーターフォールモデルコーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テスト V字モデルと呼ばれたりもする

Slide 7

Slide 7 text

Infrastructure as Codeの適用範囲コーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テストこの辺がよくなる前半の設計書には変化がない

Slide 8

Slide 8 text

Infrastructure as Codeの適用すると • コーディング以降に相当するところに改善がみられる • 設計書のところには変化がない • 設計書が開発のボトルネックになるので変えたい

Slide 9

Slide 9 text

既存の設計書の課題

Slide 10

Slide 10 text

設計書をモダナイゼーションして達成したい要件 • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 – 旧来のシステムは一度作ると5年以上使うとか多い • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 – 10、20年同じ担当にいるベテランに頼り切った仕組みからの脱却

Slide 11

Slide 11 text

ウォーターフォールモデルコーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テストこの図から、現状の問題点を確認

Slide 12

Slide 12 text

ウォーターフォールモデルコーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テスト開発をSIerに委託するケースが多いこの辺を丸ごとお願いする

Slide 13

Slide 13 text

ウォーターフォールモデルコーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テスト開発をSIerに委託するケースが多い支援してもらうこともあるここも支援してもらったり

Slide 14

Slide 14 text

システム開発を委託する時の契約既存の開発は請負契約を前提としたものが多い • 請負契約 – 仕事が完成する事を約束する契約 – 納品物が決められて、契約不適合責任（≒瑕疵担保責任）がある – 納品物の中に設計書が含まれたりする • 準委任契約 – 労働力を約束する契約 – 納品物はなく、従って契約不適合責任がない捕捉：2020年4月の民法改正時に「瑕疵」が「契約不適合」という形に変更

Slide 15

Slide 15 text

設計書が完成するまでの流れ設計/執筆ユーザレビューチーム内レビュープロジェクトレビュー課長の予定が必要部長と課長複数名の予定が必要担当者だけかもしれないし、偉い人かもしれない • ここで表現仕切れないほどの打合せ数がある • 一個の変更に対して、確認が多い • 実機確認ではなく、これはドキュメントの話 • 請け負った先も契約不適合責任があるので全部確認

Slide 16

Slide 16 text

設計書が完成するまでの流れ設計/執筆ユーザレビューチーム内レビュープロジェクトレビュー課長の予定が必要部長と課長複数名の予定が必要担当者だけかもしれないし、偉い人かもしれない • システムとしては – 部長レベルが細く知ってる必要はなさそう　 • 契約書としては – この内容に紐づく金額が動くのでビジネスとして知る必要がある相応の金額が動くビジネスの契約の内容を経営者が確認するのはおかしいわけじゃない

Slide 17

Slide 17 text

システム設計書　と　契約書システム設計書 - 定期的に変更が入るもの - テスト結果に基づく変更 - 追加開発に基づく変更 - 変更差分が管理されるもの - 最終的には1日複数回のリリースに追随する設計書にしたい契約書 - 基本的には変わらない - 一度締結したら、そのまま複数年数保管する - 経理や経営者など複数の立場からチェックが入る相反する性質

Slide 18

Slide 18 text

システム設計書から契約書の役割を取り除くために方法は2つ • 自社メンバーでの開発 – 会社間の取引で無くなる • 準委任契約 – 納品物はなく、システム設計書が契約書の一部に含まれない自分の話は、自社メンバーでの開発

Slide 19

Slide 19 text

参考：アジャイルでも準委任アジャイル開発版「情報システム・モデル取引・契約書」～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～　by IPA 参考< https://www.ipa.go.jp/ikc/reports/20200331_1.html >

Slide 20

Slide 20 text

参考：準委任契約での事例　参考< https://cloud.google.com/blog/ja/topics/customers/ntt-docomo-google-cloud-platform-gke >

Slide 21

Slide 21 text

様々な登場人物と意思決定のプロセス大きな開発だとそれだけの人数と背景、意思決定のプロセスが存在するシステム開発社だけじゃなくて、経営者、経理、実際に業務してる人など参考 IPA ユーザのための要件定義ガイド < https://www.ipa.go.jp/files/000079352.pdf >

Slide 22

Slide 22 text

こんな現状で新しい取り組みを始めるために方法は2つ • 関係者各位を全て説得し切る – 正直、ムリ – 大きな開発だと社内外に多数の関係者がいる – 社長からのトップダウン命令とか、カリスマの登場とかそんなレベル • 小さく始める – 少ない人数と、シンプルな意思決定フローで仕事を始める – 実績を作って、それを周りに広めて大きく巻き込む今回はこちらそもそも、今日はそのための発表

Slide 23

Slide 23 text

最後に欠かせないことがある • 自分の上司を味方につける – 上司と話して、ちゃんと仕事にしないと独りよがり • 加えてその上や、周辺の人たちも – これだけ大きな変更だと部長も味方につけないと難しい – 周辺の課長とか、メンバーも理解者ないと厳しい自分の話は、周りの部長や課長の方々、メンバーが賛同してくれてるのでやれてる話です。

Slide 24

Slide 24 text

前半のまとめ • 自社メンバー or 準委任契約で開発 • 小さく初めて、大きく巻き込む • 上司とか周りのメンバーを味方につける新しいことやる前にこの状態に辿り着くことが難しいんだよな

Slide 25

Slide 25 text

そもそもの話ウォーターフォールっていつ頃できて、元々どういうのなんだろう？

Slide 26

Slide 26 text

ウォーターフォールモデルのよく言われる課題コーディング要求分析受入テスト要件定義基本設計（外部設計）詳細設計（内部設計）システムテスト結合試験単体テスト前工程の誤り（手戻り）を考慮してない

Slide 27

Slide 27 text

調べてみると明確な答えはないけど、 1970年に発表された “ANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”のよう参考 < http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf >

Slide 28

Slide 28 text

この図から派生したの？ I believe in this concept, but the implementation described above is risky and invites failure. でも、論文にはちゃんと注意書きがある・・

Slide 29

Slide 29 text

手戻りについても、論文内で考慮されている・！？ Figure 3. Hopefully, the iterative interaction between the various phases is confined to successive steps. Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps. 1970年（今から50年前）の論文の中で、手戻りについては既に書かれている

Slide 30

Slide 30 text

そもそもお客様に納品するのはversion 2から 10ヶ月でパイロットモデルで開発して、その後30ヶ月使って開発する話が・・ 50年前に書かれてる・・・・今の慣習よりこのほうが良さそう

Slide 31

Slide 31 text

そもそも、本当のウォーターフォールって何？ 50年前に今のやり方の課題と改善方法が提示されるんだけど・・・・もしかして、間違ったやり方が伝わって今に残ってる・・・？？自分の目でソースを確認して考えるのは大事だな

Slide 32

Slide 32 text

設計書のモダナイゼーション

Slide 33

Slide 33 text

要件の振り返り • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 • リモートワークに対応した働き方が必須 – IT業界が率先してやらなくてどこがやるのか New

Slide 34

Slide 34 text

今回の設計書の題材 Container OS Kubernetes Container Kubernets Cluster 主にここを使って説明 Container この構成で作りたい時の設計書の話

Slide 35

Slide 35 text

設計書には何が書かれてるべきか？以下の２つを参考に考えてみる • Design Doc – Googleが公開してくれているアプリケーションの設計書 • OSSのProposal – OSSの機能の設計書

Slide 36

Slide 36 text

Slide 37

Slide 37 text

GoogleのDesign Docから学ぶ参考< https://docs.google.com/document/d/1s1ryja1V8dDotMK2WBGT2wnwchZ_x7Tag2L3OZfn5Po/preview#heading=h.fcbb4abee2b1 > そもそもソフトウェアのプラクティスを使うために始めたので代表的なものから学ぼうとするのは自然な流れ

Slide 38

Slide 38 text

OSSのProposalから学ぶどうして、ここから学ぶ？

Slide 39

Slide 39 text

要件の振り返り • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 • リモートワークに対応した働き方が必須 – IT業界が率先してやらなくてどこがやるのか New この要件を全て満たしている開発事例だから

Slide 40

Slide 40 text

実は今回のお話は • OSSのProposalの考え方をインフラの設計書に取り入れる話 • そのために – 現状の課題を洗い出して、説得の材料を揃えて – 実際にやり切るために働き方を変えた今のやり方が良くないと言ってるだけでは何も変わらない

Slide 41

Slide 41 text

Kubernetes Enhancement Proposals (KEPs) 参考< https://github.com/kubernetes/enhancements/tree/master/keps > テンプレートがある

Slide 42

Slide 42 text

Kubernetes Enhancement Proposals (KEPs) 参考< https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md > こういう構成になってる

Slide 43

Slide 43 text

Kafka Improvement Proposals (KIP) 参考< https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum > Kubernetes１個しかみないと勿体ないのでせっかくだからKafkaもみてみる

Slide 44

Slide 44 text

Slide 45

Slide 45 text

実際の設計書の項目 -前半- ● 概要(Summary) 　設計書の概要について記載する ● 目的(Motivation) ○ 背景(Background) 　この設計書が必要になった背景を記載する ○ 要件(Requirement) 　この設計に必要な要件を記載する ● Goals 　この設計が満たされた時の状態を記載する ● Non-Goals 　この設計の対象外となる部分に明文化する冒頭でまとめてあると読みやすいから背景と要件が残ってないと後から参加した人が困る対象範囲を明記しないと、後々収集がつかなくなる

Slide 46

Slide 46 text

実際の設計書の項目 -後半- ● 本文(Body) 　設計内容について記載する ● References 　設計時に使用した参考資料について記載する ● Open Issue 　検討はしたが設計時にはまだ未定や今後の　検討項目についてIssueとして管理する

Slide 47

Slide 47 text

実際の設計書の項目 -後半- ● 本文(Body) 　設計内容について記載する ● References 　設計時に使用した参考資料について記載する ● Open Issue 　検討はしたが設計時にはまだ未定や今後の　検討項目についてIssueとして管理するアーキテクチャとか設計内容はここ参考資料が残ってるとありがたいシステムは常に未完成で永遠に改善の余地があるものだと考えてるから明示的にissueを許容したい優先順位をつけて、現状でやり切るとこと今後のタスクを分けて欲しい

Slide 48

Slide 48 text

設計書をどうやって書くかまずやりたいことと、やらないことを整理する • やりたいこと – diffで差分が取れる – そこそこ記述に自由度がある – 差分の状態とその理由を管理したい • やらないこと – フォントとか文字サイズとか設計書の細かい記述ルールは要らない – もう、ユーザレビューの必要な契約書じゃないから要らない

Slide 49

Slide 49 text

設計書をどうやって書くかツールを決める • フォーマット – Markdown – 簡単にかけて、ちゃんとDiffが取れる • 差分管理 – Git (Github, GitLab etc) – 差分とその理由が管理できる – ソフトウェア開発のプラクティスが利用できる

Slide 50

Slide 50 text

その他の便利ツール -描画- draw.io diagrams tbls 図もCodeで管理できると嬉しい

Slide 51

Slide 51 text

その他の便利ツール -静的サイト- Markdownを綺麗な静的サイトにする方法が色々ある

Slide 52

Slide 52 text

その他の便利ツール -IPアドレス管理- とても便利なので即導入していいと思います。

Slide 53

Slide 53 text

ここから働き方の話

Slide 54

Slide 54 text

チームメンバーに対して望むこと • ほかの人とうまくやっていけるか？ • みんなと仲良く遊べるか？ • 遊ぶのをやめるとき、きちんと後片付けできるか？ • 新しいことにワクワクするか？ • 学ぶことが好きか？参考 07 スキルでなく素質のある人を加えよう個人的にこれがすごく好き

Slide 55

Slide 55 text

その上で、まずスキルアップ • 設計対象に対する知識の習得 • 設計対象を実際に手元で動かして遊んでみる何もわからない人同士でいくら打合せしても意味がないまずは動かしてみて中身を少し理解してから設計した方がいい

Slide 56

Slide 56 text

良くない状態スケジュールが打合せで常に埋まっている - 考えたり、アウトプットを出す時間がない - 他の人が声をかけ辛い関係者の予定が合わないからランチミーティングとか言い始めると休みがなくて大変

Slide 57

Slide 57 text

理想の姿スケジュールに余裕がある - 自分でコントロールして作業ができる - 他の人が声をかけやすい月、金に定例がないと休みやすい日勤帯にだけ打合せだと楽まずは残業なしでやり切るスケジュールを考える

Slide 58

Slide 58 text

チーム体制 • １チーム MAX4人とかに制限してみる – リモートの打合せでまともに議論できる人数 • 複数チームへの掛け持ちをやめる – 聞くだけの打ち合わせは減らす – 自分の仕事に集中して、他のチームのタスクは他の人を信じる所属する度にスケジュール管理や頭の切替えなどのコストが増える結局、内職するなら最初から作業に集中した方が良い

Slide 59

Slide 59 text

コミュニケーションルール • チャットとWeb会議にツールを決める – 簡単なやりとりはチャット – 話す必要があったらWeb会議 • チャネルとかで分けて、どこでどういう話をできるかルールを決める – 質問しやすい場所を作ると新しく着た人が安心できる – 仕事以外の雑談ができる場所もあると良い

Slide 60

Slide 60 text

打合せの仕方 • 誰が必要か明確に定義して、なんとなくで参加者を増やさない • アジェンダは事前に作成する • 必要な資料があったら、事前に目を通す • 議事録はリアルタイムで作成する • 決定事項、課題、宿題事項は整理する

Slide 61

Slide 61 text

社内用語や独自の略称 • そもそも辞書に載ってる単語で表現できないか考える – 母国語が英語のメンバーからは、それはどう見えるのか？ – 新しいメンバーや他社の人に説明するコストを都度払うだけのリターンはあるのか？ • 新しく作るなら、辞書の単語だけを使って説明できること – 説明できないと、みんなが独自に解釈し始めるので再考する – この先も用語集をメンテし続ける覚悟はあるのか？オンボーディングのために、自分達が第三者からどう見えるかいつも考える

Slide 62

Slide 62 text

最後に、周りの巻き込み方 • 実際に自分が楽しそうにやってみる • やってみた内容は、発表なりして周りから分かるようにする • 興味持ってくれる人がいたら、話しかけてみる