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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. 既存の設計書の課題
   

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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年前）の論文の中で、手戻りについては
    既に書かれている
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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もみてみる
    

    View Slide

44. 実際の設計書の項目 -前半-
    ● 概要(Summary)
    　設計書の概要について記載する
    ● 目的(Motivation)
    ○ 背景(Background)
    　この設計書が必要になった背景を記載する
    ○ 要件(Requirement)
    　この設計に必要な要件を記載する
    ● Goals
    　この設計が満たされた時の状態を記載する
    ● Non-Goals
    　この設計の対象外となる部分に明文化する
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

53. ここから働き方の話
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide