$30 off During Our Annual Pro Sale. View Details »

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

yosshi_
July 25, 2020

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

yosshi_

July 25, 2020
Tweet

More Decks by yosshi_

Other Decks in Technology

Transcript

  1. • 吉村 翔太 • NTTコミュニケーションズ所属 • 経歴 SIer 6年、現職 インフラエンジニア

    2年 • Kurbernetes 、Prometheus  etc • 登壇 CNDT “Kubernetes Logging入門” etc • コミュニティ活動 “Cloud Native Developers JP” @yosshi_ 自己紹介 “Prometheus Meetup Tokyo”
  2. 今日話す内容と割合 • この取り組みをしたモチベーション ( 10% ) • 既存の設計書の課題 ( 40%

    ) • 設計書のモダナイゼーション ( 50% ) – 書くべき内容や使うツールの話 ( そのうち4割 ) – 仕事の進め方や働き方の話 ( そのうち6割 ) 新しいやり方を考えるより 既存の課題点を洗い出しとやり方が定着するように働き方を変える方が高コスト
  3. インフラにおける大きな変化 Infrastructure as Code • Infrastructure as Codeとは – ソフトウェア開発のプラクティスをインフラに活かす仕組み

    – インフラをCodeで管理できるようになる • Infrastructure as Code導入のメリット – インフラのversion管理が可能 – インフラのCI/CDが可能 – 再現性の向上 – 環境構築に関する作業の短縮が可能
  4. Infrastructure as Codeの適用範囲 コーディング 要求分析 受入テスト 要件定義 基本設計 (外部設計) 詳細設計

    (内部設計) システムテスト 結合試験 単体テスト この辺がよくなる 前半の設計書には 変化がない
  5. ウォーターフォールモデル コーディング 要求分析 受入テスト 要件定義 基本設計 (外部設計) 詳細設計 (内部設計) システムテスト

    結合試験 単体テスト 開発をSIerに委託するケースが多い 支援してもらうこともある ここも支援してもらったり
  6. システム開発を委託する時の契約 既存の開発は 請負契約を前提としたものが多い • 請負契約 – 仕事が完成する事を約束する契約 – 納品物が決められて、契約不適合責任(≒瑕疵担保責任)がある –

    納品物の中に設計書が含まれたりする • 準委任契約 – 労働力を約束する契約 – 納品物はなく、従って契約不適合責任がない 捕捉:2020年4月の民法改正時に「瑕疵」が「契約不適合」という形に変更
  7. 設計書が完成するまでの流れ 設計/執筆 ユーザ レビュー チーム内 レビュー プロジェクト レビュー 課長の予定が必要 部長と課長複数名の予定が必要

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

    担当者だけかもしれないし、 偉い人かもしれない • システムとしては – 部長レベルが細く知ってる必要はなさそう   • 契約書としては – この内容に紐づく金額が動くのでビジネスとして 知る必要がある 相応の金額が動くビジネスの 契約の内容を経営者が確認するのは おかしいわけじゃない
  9. システム設計書 と 契約書 システム設計書 - 定期的に変更が入るもの - テスト結果に基づく変更 - 追加開発に基づく変更 - 変更差分が管理されるもの

    - 最終的には1日複数回のリ リースに追随する設計書にし たい 契約書 - 基本的には変わらない - 一度締結したら、そのまま 複数年数保管する - 経理や経営者など複数の 立場からチェックが入る 相反する性質
  10. こんな現状で新しい取り組みを始めるために 方法は2つ • 関係者各位を全て説得し切る – 正直、ムリ – 大きな開発だと社内外に多数の関係者がいる – 社長からのトップダウン命令とか、カリスマの登場とかそんなレベル

    • 小さく始める – 少ない人数と、シンプルな意思決定フローで仕事を始める – 実績を作って、それを周りに広めて大きく巻き込む 今回はこちら そもそも、今日はそのための発表
  11. 最後に欠かせないことがある • 自分の上司を味方につける – 上司と話して、ちゃんと仕事にしないと独りよがり • 加えてその上や、周辺の人たちも – これだけ大きな変更だと部長も味方につけないと難しい –

    周辺の課長とか、メンバーも理解者ないと厳しい 自分の話は、周りの部長や課長の方々、メンバーが 賛同してくれてるのでやれてる話です。
  12. この図から派生したの? I believe in this concept, but the implementation described

    above is risky and invites failure. でも、論文にはちゃんと注 意書きがある・・
  13. 手戻りについても、論文内で考慮されている・!? 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年前)の論文の中で、手戻りについては 既に書かれている
  14. インフラにおける大きな変化 Infrastructure as Code • Infrastructure as Codeとは – ソフトウェア開発のプラクティスをインフラに活かす仕組み

    – インフラをCodeで管理できるようになる • Infrastructure as Code導入のメリット – インフラのversion管理が可能 – インフラのCI/CDが可能 – 再現性の向上 – 環境構築に関する作業の短縮が可能 そもそもなぜ、これを使うのか?
  15. 実際の設計書の項目 -前半- • 概要(Summary)  設計書の概要について記載する • 目的(Motivation) ◦ 背景(Background)  この設計書が必要になった背景を記載する

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

    ◦ 要件(Requirement)  この設計に必要な要件を記載する • Goals  この設計が満たされた時の状態を記載する • Non-Goals  この設計の対象外となる部分に明文化する 冒頭でまとめてあると読みやすいから 背景と要件が残ってないと後から参加した人が困る 対象範囲を明記しないと、後々収集がつかなくなる
  17. 実際の設計書の項目 -後半- • 本文(Body)  設計内容について記載する • References  設計時に使用した参考資料について記載する • Open

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

    Issue  検討はしたが設計時にはまだ未定や今後の  検討項目についてIssueとして管理する アーキテクチャとか設計内容はここ 参考資料が残ってるとありがたい システムは常に未完成で永遠に改善の余地があるものだと考えてるから 明示的にissueを許容したい 優先順位をつけて、現状でやり切るとこと今後のタスクを分けて欲しい
  19. 設計書をどうやって書くか まずやりたいことと、やらないことを整理する • やりたいこと – diffで差分が取れる – そこそこ記述に自由度がある – 差分の状態とその理由を管理したい

    • やらないこと – フォントとか文字サイズとか設計書の細かい記述ルールは要らない – もう、ユーザレビューの必要な契約書じゃないから要らない
  20. 設計書をどうやって書くか ツールを決める • フォーマット – Markdown – 簡単にかけて、ちゃんとDiffが取れる • 差分管理

    – Git (Github, GitLab etc) – 差分とその理由が管理できる – ソフトウェア開発のプラクティスが利用できる
  21. チームメンバーに対して望むこと • ほかの人とうまくやっていけるか? • みんなと仲良く遊べるか? • 遊ぶのをやめるとき、きちんと後片付けできるか? • 新しいことにワクワクするか? •

    学ぶことが好きか? 参考 <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 スキルでなく素質のある人を加えよう 個人的にこれがすごく好き
  22. チーム体制 • 1チーム MAX4人とかに制限してみる – リモートの打合せでまともに議論できる人数 • 複数チームへの掛け持ちをやめる – 聞くだけの打ち合わせは減らす

    – 自分の仕事に集中して、他のチームのタスクは他の人を信じる 所属する度にスケジュール管理や 頭の切替えなどのコストが増える 結局、内職するなら 最初から作業に集中した方が良い
  23. 社内用語や独自の略称 • そもそも辞書に載ってる単語で表現できないか考える – 母国語が英語のメンバーからは、それはどう見えるのか? – 新しいメンバーや他社の人に説明するコストを都度払うだけの リターンはあるのか? • 新しく作るなら、辞書の単語だけを使って説明できること

    – 説明できないと、みんなが独自に解釈し始めるので再考する – この先も用語集をメンテし続ける覚悟はあるのか? オンボーディングのために、 自分達が第三者からどう見えるかいつも考える