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

Transcript

1. ç 伝統的なエンプラ企業で取り組む インフラの設計書のモダナイゼーション July Tech Festa 2020 @yosshi_
2. • 吉村 翔太 • NTTコミュニケーションズ所属 • 経歴 SIer 6年、現職 インフラエンジニア 2年 • Kurbernetes 、Prometheus　 etc • 登壇 CNDT “Kubernetes Logging入門” etc • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
3. 今日話す内容と割合 • この取り組みをしたモチベーション ( 10% ) • 既存の設計書の課題 ( 40% ) • 設計書のモダナイゼーション ( 50% ) – 書くべき内容や使うツールの話 ( そのうち４割 ) – 仕事の進め方や働き方の話 ( そのうち６割 ) 新しいやり方を考えるより 既存の課題点を洗い出しとやり方が定着するように働き方を変える方が高コスト
4. この取り組みをしたモチベーション
5. インフラにおける大きな変化 Infrastructure as Code • Infrastructure as Codeとは – ソフトウェア開発のプラクティスをインフラに活かす仕組み – インフラをCodeで管理できるようになる • Infrastructure as Code導入のメリット – インフラのversion管理が可能 – インフラのCI/CDが可能 – 再現性の向上 – 環境構築に関する作業の短縮が可能
6. ウォーターフォールモデル コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト V字モデルと呼ばれたりもする
7. Infrastructure as Codeの適用範囲 コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト この辺がよくなる 前半の設計書には 変化がない
8. Infrastructure as Codeの適用すると • コーディング以降に相当するところに改善がみられる • 設計書のところには変化がない • 設計書が開発のボトルネックになるので変えたい
9. 既存の設計書の課題
10. 設計書をモダナイゼーションして達成したい要件 • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 – 旧来のシステムは一度作ると5年以上使うとか多い • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 – 10、20年同じ担当にいるベテランに頼り切った仕組みからの脱却
11. ウォーターフォールモデル コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト この図から、現状の問題点を確認
12. ウォーターフォールモデル コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト 開発をSIerに委託するケースが多い この辺を丸ごとお願いする
13. ウォーターフォールモデル コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト 開発をSIerに委託するケースが多い 支援してもらうこともある ここも支援してもらったり
14. システム開発を委託する時の契約 既存の開発は 請負契約を前提としたものが多い • 請負契約 – 仕事が完成する事を約束する契約 – 納品物が決められて、契約不適合責任（≒瑕疵担保責任）がある – 納品物の中に設計書が含まれたりする • 準委任契約 – 労働力を約束する契約 – 納品物はなく、従って契約不適合責任がない 捕捉：2020年4月の民法改正時に「瑕疵」が「契約不適合」という形に変更
15. 設計書が完成するまでの流れ 設計/執筆 ユーザ レビュー チーム内 レビュー プロジェクト レビュー 課長の予定が必要 部長と課長複数名の予定が必要 担当者だけかもしれないし、 偉い人かもしれない • ここで表現仕切れないほどの打合せ数がある • 一個の変更に対して、確認が多い • 実機確認ではなく、これはドキュメントの話 • 請け負った先も契約不適合責任があるので全部確認
16. 設計書が完成するまでの流れ 設計/執筆 ユーザ レビュー チーム内 レビュー プロジェクト レビュー 課長の予定が必要 部長と課長複数名の予定が必要 担当者だけかもしれないし、 偉い人かもしれない • システムとしては – 部長レベルが細く知ってる必要はなさそう 　 • 契約書としては – この内容に紐づく金額が動くのでビジネスとして 知る必要がある 相応の金額が動くビジネスの 契約の内容を経営者が確認するのは おかしいわけじゃない
17. システム設計書　と　契約書 システム設計書 - 定期的に変更が入るもの - テスト結果に基づく変更 - 追加開発に基づく変更 - 変更差分が管理されるもの - 最終的には1日複数回のリ リースに追随する設計書にし たい 契約書 - 基本的には変わらない - 一度締結したら、そのまま 複数年数保管する - 経理や経営者など複数の 立場からチェックが入る 相反する性質
18. システム設計書から契約書の役割を取り除くために 方法は2つ • 自社メンバーでの開発 – 会社間の取引で無くなる • 準委任契約 – 納品物はなく、システム設計書が契約書の一部に含まれない 自分の話は、自社メンバーでの開発
19. 参考：アジャイルでも準委任 アジャイル開発版「情報システム・モデル取引・契約書」 ～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～　by IPA 参考< https://www.ipa.go.jp/ikc/reports/20200331_1.html >
20. 参考：準委任契約での事例　 参考< https://cloud.google.com/blog/ja/topics/customers/ntt-docomo-google-cloud-platform-gke >
21. 様々な登場人物と意思決定のプロセス 大きな開発だとそれだけの 人数と背景、意思決定のプ ロセスが存在する システム開発社だけじゃな くて、経営者、経理、実際に 業務してる人など 参考 IPA ユーザのための要件定義ガイド < https://www.ipa.go.jp/files/000079352.pdf >
22. こんな現状で新しい取り組みを始めるために 方法は2つ • 関係者各位を全て説得し切る – 正直、ムリ – 大きな開発だと社内外に多数の関係者がいる – 社長からのトップダウン命令とか、カリスマの登場とかそんなレベル • 小さく始める – 少ない人数と、シンプルな意思決定フローで仕事を始める – 実績を作って、それを周りに広めて大きく巻き込む 今回はこちら そもそも、今日はそのための発表
23. 最後に欠かせないことがある • 自分の上司を味方につける – 上司と話して、ちゃんと仕事にしないと独りよがり • 加えてその上や、周辺の人たちも – これだけ大きな変更だと部長も味方につけないと難しい – 周辺の課長とか、メンバーも理解者ないと厳しい 自分の話は、周りの部長や課長の方々、メンバーが 賛同してくれてるのでやれてる話です。
24. 前半のまとめ • 自社メンバー or 準委任契約で開発 • 小さく初めて、大きく巻き込む • 上司とか周りのメンバーを味方につける 新しいことやる前に この状態に辿り着くことが難しいんだよな
25. そもそもの話 ウォーターフォールって いつ頃できて、元々どういうのなんだろう？
26. ウォーターフォールモデルのよく言われる課題 コーディング 要求分析 受入テスト 要件定義 基本設計 （外部設計） 詳細設計 （内部設計） システムテスト 結合試験 単体テスト 前工程の誤り（手戻り）を考慮してない
27. 調べてみると 明確な答えはないけど、 1970年に発表された “ANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”のよう 参考 < http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf >
28. この図から派生したの？ I believe in this concept, but the implementation described above is risky and invites failure. でも、論文にはちゃんと注 意書きがある・・
29. 手戻りについても、論文内で考慮されている・！？ 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年前）の論文の中で、手戻りについては 既に書かれている
30. そもそもお客様に納品するのはversion 2から 10ヶ月でパイロットモデルで開発して、その後30ヶ月使って開発する話が・・ 50年前に書かれてる・・・・今の慣習よりこのほうが良さそう
31. そもそも、本当のウォーターフォールって何？ 50年前に今のやり方の課題と改善方法が提示されるんだ けど・・・・もしかして、間違ったやり方が伝わって今に残っ てる・・・？？ 自分の目でソースを確認して考えるのは大事だな
32. 設計書のモダナイゼーション
33. 要件の振り返り • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 • リモートワークに対応した働き方が必須 – IT業界が率先してやらなくてどこがやるのか New
34. 今回の設計書の題材 Container OS Kubernetes Container Kubernets Cluster 主にここを使って説明 Container この構成で作りたい時の設計書の話
35. 設計書には何が書かれてるべきか？ 以下の２つを参考に考えてみる • Design Doc – Googleが公開してくれているアプリケーションの設計書 • OSSのProposal – OSSの機能の設計書
36. インフラにおける大きな変化 Infrastructure as Code • Infrastructure as Codeとは – ソフトウェア開発のプラクティスをインフラに活かす仕組み – インフラをCodeで管理できるようになる • Infrastructure as Code導入のメリット – インフラのversion管理が可能 – インフラのCI/CDが可能 – 再現性の向上 – 環境構築に関する作業の短縮が可能 そもそもなぜ、これを使うのか？
37. GoogleのDesign Docから学ぶ 参考< https://docs.google.com/document/d/1s1ryja1V8dDotMK2WBGT2wnwchZ_x7Tag2L3OZfn5Po/preview#heading=h.fcbb4abee2b1 > そもそもソフトウェアのプラクティスを使うために始めたので 代表的なものから学ぼうとするのは自然な流れ
38. OSSのProposalから学ぶ どうして、ここから学ぶ？
39. 要件の振り返り • 高頻度の変更に耐えるようにしたい – ビジネス要件の変化が激しくなり、変更頻度増 • オンボーディングしやすい設計書にしたい – 人事異動に加えて、退職や中途入社など今や当たり前 • リモートワークに対応した働き方が必須 – IT業界が率先してやらなくてどこがやるのか New この要件を全て満たしている 開発事例だから
40. 実は今回のお話は • OSSのProposalの考え方をインフラの設計書に取り入れる話 • そのために – 現状の課題を洗い出して、説得の材料を揃えて – 実際にやり切るために働き方を変えた 今のやり方が良くないと言ってるだけでは 何も変わらない
41. Kubernetes Enhancement Proposals (KEPs) 参考< https://github.com/kubernetes/enhancements/tree/master/keps > テンプレートがある
42. Kubernetes Enhancement Proposals (KEPs) 参考< https://github.com/kubernetes/enhancements/blob/master/keps/NNNN-kep-template/README.md > こういう構成になってる
43. Kafka Improvement Proposals (KIP) 参考< https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum > Kubernetes１個しかみないと勿体ないので せっかくだからKafkaもみてみる
44. 実際の設計書の項目 -前半- • 概要(Summary) 　設計書の概要について記載する • 目的(Motivation) ◦ 背景(Background) 　この設計書が必要になった背景を記載する ◦ 要件(Requirement) 　この設計に必要な要件を記載する • Goals 　この設計が満たされた時の状態を記載する • Non-Goals 　この設計の対象外となる部分に明文化する
45. 実際の設計書の項目 -前半- • 概要(Summary) 　設計書の概要について記載する • 目的(Motivation) ◦ 背景(Background) 　この設計書が必要になった背景を記載する ◦ 要件(Requirement) 　この設計に必要な要件を記載する • Goals 　この設計が満たされた時の状態を記載する • Non-Goals 　この設計の対象外となる部分に明文化する 冒頭でまとめてあると読みやすいから 背景と要件が残ってないと後から参加した人が困る 対象範囲を明記しないと、後々収集がつかなくなる
46. 実際の設計書の項目 -後半- • 本文(Body) 　設計内容について記載する • References 　設計時に使用した参考資料について記載する • Open Issue 　検討はしたが設計時にはまだ未定や今後の 　検討項目についてIssueとして管理する
47. 実際の設計書の項目 -後半- • 本文(Body) 　設計内容について記載する • References 　設計時に使用した参考資料について記載する • Open Issue 　検討はしたが設計時にはまだ未定や今後の 　検討項目についてIssueとして管理する アーキテクチャとか設計内容はここ 参考資料が残ってるとありがたい システムは常に未完成で永遠に改善の余地があるものだと考えてるから 明示的にissueを許容したい 優先順位をつけて、現状でやり切るとこと今後のタスクを分けて欲しい
48. 設計書をどうやって書くか まずやりたいことと、やらないことを整理する • やりたいこと – diffで差分が取れる – そこそこ記述に自由度がある – 差分の状態とその理由を管理したい • やらないこと – フォントとか文字サイズとか設計書の細かい記述ルールは要らない – もう、ユーザレビューの必要な契約書じゃないから要らない
49. 設計書をどうやって書くか ツールを決める • フォーマット – Markdown – 簡単にかけて、ちゃんとDiffが取れる • 差分管理 – Git (Github, GitLab etc) – 差分とその理由が管理できる – ソフトウェア開発のプラクティスが利用できる
50. その他の便利ツール -描画- draw.io diagrams tbls 図もCodeで管理できると嬉しい
51. その他の便利ツール -静的サイト- Markdownを綺麗な静的サイトにする方法が色々ある
52. その他の便利ツール -IPアドレス管理- とても便利なので 即導入していいと思います。
53. ここから働き方の話
54. チームメンバーに対して望むこと • ほかの人とうまくやっていけるか？ • みんなと仲良く遊べるか？ • 遊ぶのをやめるとき、きちんと後片付けできるか？ • 新しいことにワクワクするか？ • 学ぶことが好きか？ 参考 <https://xn--97-273ae6a4irb6e2h2k6c0ec7tvc3h1e0dwi7lj952k.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%82%B9%E3%82%AD%E3%83%AB%E3%81 %A7%E3%81%AA%E3%81%8F%E7%B4%A0%E8%B3%AA%E3%81%AE%E3%81%82%E3%82%8B%E4%BA%BA%E3%82%92%E5%8A%A0%E3%81%88%E3%82%88%E 3%81%86/ > 07 スキルでなく素質のある人を加えよう 個人的にこれがすごく好き
55. その上で、まずスキルアップ • 設計対象に対する知識の習得 • 設計対象を実際に手元で動かして遊んでみる 何もわからない人同士でいくら打合せしても意味がない まずは動かしてみて中身を少し理解してから設計した方がいい
56. 良くない状態 スケジュールが打合せで常に埋まっている - 考えたり、アウトプットを出す時間がない - 他の人が声をかけ辛い 関係者の予定が合わないから ランチミーティングとか言い始めると 休みがなくて大変
57. 理想の姿 スケジュールに余裕がある - 自分でコントロールして作業ができる - 他の人が声をかけやすい 月、金に定例がないと休みやすい 日勤帯にだけ打合せだと楽 まずは残業なしでやり切るスケジュールを考える
58. チーム体制 • １チーム MAX4人とかに制限してみる – リモートの打合せでまともに議論できる人数 • 複数チームへの掛け持ちをやめる – 聞くだけの打ち合わせは減らす – 自分の仕事に集中して、他のチームのタスクは他の人を信じる 所属する度にスケジュール管理や 頭の切替えなどのコストが増える 結局、内職するなら 最初から作業に集中した方が良い
59. コミュニケーションルール • チャットとWeb会議にツールを決める – 簡単なやりとりはチャット – 話す必要があったらWeb会議 • チャネルとかで分けて、どこでどういう話をできるかルールを決め る – 質問しやすい場所を作ると新しく着た人が安心できる – 仕事以外の雑談ができる場所もあると良い
60. 打合せの仕方 • 誰が必要か明確に定義して、なんとなくで参加者を増やさない • アジェンダは事前に作成する • 必要な資料があったら、事前に目を通す • 議事録はリアルタイムで作成する • 決定事項、課題、宿題事項は整理する
61. 社内用語や独自の略称 • そもそも辞書に載ってる単語で表現できないか考える – 母国語が英語のメンバーからは、それはどう見えるのか？ – 新しいメンバーや他社の人に説明するコストを都度払うだけの リターンはあるのか？ • 新しく作るなら、辞書の単語だけを使って説明できること – 説明できないと、みんなが独自に解釈し始めるので再考する – この先も用語集をメンテし続ける覚悟はあるのか？ オンボーディングのために、 自分達が第三者からどう見えるかいつも考える
62. 最後に、周りの巻き込み方 • 実際に自分が楽しそうにやってみる • やってみた内容は、発表なりして周りから分かるようにする • 興味持ってくれる人がいたら、話しかけてみる