Tweet
Tweet

Slide 1

Slide 1 text

エンジニアのための ドキュメント力養成講座 ～構造化思考から始めよう～ 2020年5月 ver1.1 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）

Slide 2

Slide 2 text

自己紹介 twitter/note/Qiita で情報発信中。 良かったら覗いてみてください♥ 中野 康雄（なかのやすお） 兵庫県宝塚市出身 S49年生 ARアドバンストテクノロジ株式会社 取締役執行役員（事業担当） 兼TechCoE事業室長  全社戦略、事業管理、PJ品質管理 人材育成、中途採用、一部PJ業務 などを担当  元流通経済大学 非常勤講師 （Eビジネス論）  PMP/情報処理安全確保支援士 AWS認定ソリューションアーキテクトアソシエイト JDLA G検定 2

Slide 3

Slide 3 text

ARIってどんな会社？ 創業11年目のSI＆サービス提供 社員数390名、国内3拠点 （渋谷、大阪、名古屋） 仮想化、音声、クラウド基盤、 アプリケーション、AIへと領域拡大 近年はデザインやITコンサル体制拡充 パッケージ製品や自社SaaS提供も Biz Tech Creative 三位一体提供型の 次世代DXファームを目指し奮闘中 ARI で検索！ 3

Slide 4

Slide 4 text

はじめに 4

Slide 5

Slide 5 text

エンジニアとして必要な ドキュメンテーション力を 身につける 今日のテーマ 5

Slide 6

Slide 6 text

プロジェクト工数の7割はドキュメント作成 6 引用： » 2019年度調査『ソフトウェアメトリックス調査2020 システム開発・保守調査』の報告資料 JUAS 一般社団法人 日本情報システムユーザー協会 https://juas.or.jp/news/topics/2823/ 実はシステム開発で プログラミングなど実装は 約 3割しかない

Slide 7

Slide 7 text

アジャイル時代は ドキュメントは書かなくて良い よくある誤解その2 合意形成や情報共有のために ドキュメントは一定数必要 7

Slide 8

Slide 8 text

ドキュメント作成力は資産価値が高い 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured 8

Slide 9

Slide 9 text

今日のアジェンダ • ドキュメント作成に求められるスキル • 構造化思考とは？ • 構造化思考の演習 • ドキュメント作成の進め方 • 最後に • Appendix 9

Slide 10

Slide 10 text

ドキュメント作成に求められるスキル 10

Slide 11

Slide 11 text

システム開発系ドキュメントの特徴 • 自分以外の誰かが読み、更新されることが前提とされる  レビュワー  後工程の担当者  保守担当者 • 抜け漏れや、読み手によって解釈が異なることは許されない  検討すべきことの抜け漏れは手戻りにつながる  解釈が異なる記述をしてしまった場合も同様 • 納期があり生産性が求められる  書き手が納得いくまで時間をかけて良いわけではない  事前に作成工数の見積りが求められる 11

Slide 12

Slide 12 text

システム開発系ドキュメントに求められること • 品質  誤字脱字、最低限の体裁、表記の統一  書くべき項目がすべて書かれている  内容が正確 • 読み手にわかりやすいこと  全体構成、見出しの粒度、順序が適切  各文章がわかりやすい  体裁が適切に「デザイン」されていること（タイトル、表紙、インデント、ページ番号など） • 生産性や作業管理性が高いこと  標準化され一定のルールがある方が書きやすく、レビューもしやすい  作成にかかるタスクが分解できている（見積りの精度が上がる）  完了までの段取りが出来ている（アウトライン化） 12

Slide 13

Slide 13 text

そもそもシステム開発とは どういった行為なのか？ まずその本質を理解することから はじめたい 効果的なドキュメンテーション力を得るために 13

Slide 14

Slide 14 text

シ ス テ ム 開 発 の 時 間 軸 システム開発の大きな流れ 要件 人間の 世界 システムの 世界 設計 実装（ソフトウェア/基盤） 要求 要望 仕様 要件 1.要望要求から要件に選別する 2.要件に対する仕様を記述する 3.仕様を満たすように設計する 4.設計通りに実装する 5.仕様＆要件の実現を確認する 14

Slide 15

Slide 15 text

シ ス テ ム 開 発 の 時 間 軸 要件は仕様化されなければ実現できない 要件 人間の 世界 システムの 世界 氏名を表示できたらいいな その他多くの要望 各ページに氏名を表示できること 各ページのヘッダ部分に 「○○[半角スペース]●●」と表示する。 ○○は姓、●●は名を表す。 ユーザー内 整理 QCD制約踏まえた 要求精査 各ページに氏名を表示したい 網羅的かつ 誤解を与えない 言語化 仕様の網羅的かつ誤解なき言語化が システム開発の最初の勘所 設計 実装（コード） 要求 要望 仕様 要件 • あったらいいなだよね？目的は？本当に必要？ • 個人の意見？みんなの意見？ • 要求の優先順位は？ • 予算や納期踏まえて今回どれやる？ • ページのどこ？ • どんな風に表示するの？ 参考： https://qiita.com/digdagdag/items/2808205d89344ab8a3a1 イメージ 15

Slide 16

Slide 16 text

ドキュメント作成の勘所 網羅的かつ 誤解なき言語化 16

Slide 17

Slide 17 text

効果的なドキュメント作成に必要なスキル知識 構造化思考力 作文/表現技術 記述対象に 関する知識 特にここが ポイント！ 17

Slide 18

Slide 18 text

今回は構造化思考に 絞ってお話します 18

Slide 19

Slide 19 text

構造化思考とは？ 19

Slide 20

Slide 20 text

構造化思考とは？ 全体を分解したり 個別を集約することで 情報を整理する考え方 注：私の定義 20

Slide 21

Slide 21 text

構造化思考 ２つのアプローチ １．全体を分解する ２．個別を集約する 大きなテーマを分解して整理する 思考の補助線を引き情報を整理する 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured どっちも大切 21

Slide 22

Slide 22 text

構造化されている例 資料間の関係  画面一覧と画面設計書  機能一覧と各機能設計書  システム構成一覧と構成別パ ラメータシート  移行全体スケジュールと各移行 作業詳細手順書  共通仕様書と各個別仕様書 各資料内の目次構成 例：要件定義書 1. システム導入の目的と目標 2. システムの概要／システムの構想 3. システム導入後の業務フロー 4. 機能要求 5. 入力要求と出力要求 6. 品質・性能要求 7. セキュリティ要求 重複を避ける 漏れ重複ない章立て （一般例） 22

Slide 23

Slide 23 text

構造化することのメリット（１） 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured ドキュメントを作る上で最も避けるべき「漏れとダブリ」をなくせる 23

Slide 24

Slide 24 text

構造化することのメリット（２） 枠組みが共有できると 読み手に伝わりやすい なぜか？ 画像引用： https://www.missiondrivenbrand.jp/entry/thinking__Structured 24

Slide 25

Slide 25 text

情報＝枠組み＋内容 情報を伝えるときは、枠組みと内容を分けて考えると効果的。 枠組みが共有できると内容だけに集中できる。 枠組み 内容 情報 前提事項 仕様 進め方 イメージ 画像引用：https://www.itmedia.co.jp/bizid/articles/1009/21/news058.html 25

Slide 26

Slide 26 text

構造化のポイント 分かる＝分ける 26

Slide 27

Slide 27 text

構造化の上手下手はどこで決まるか？ 1. 漏れダブリをなくす 2. 粒感を揃える 3. 順序を整える 27

Slide 28

Slide 28 text

これを気持ち悪いと思えるか？ 春、夏、冬 野菜、肉、サンマ 昭和、平成、大正、令和 28

Slide 29

Slide 29 text

枠組みの力を借りて情報伝達の精度を上げる 春、夏、秋、冬 野菜、肉、魚（サンマ） 大正、昭和、平成、令和 29

Slide 30

Slide 30 text

これらへの感度を上げよう 1. 漏れダブリをなくす 2. 粒感を揃える 3. 順序を整える 全体→詳細、時系列、大→小、頻出→レア、正常→異常 など 30

Slide 31

Slide 31 text

構造化思考のポイント 文字列は何を伝えているのか？ 31

Slide 32

Slide 32 text

それぞれに意味がある 春、夏、秋、冬 野菜、肉、魚（サンマ） 大正、昭和、平成、令和 32 季節 食材 年号

Slide 33

Slide 33 text

こういう問題昔やりましたよね？ 問題：□に入るものを答えよ Q1：１, 2, 4, 8, □, 32, 64 Q2：J, F, M, A, M, □, J, A,・・・ 33 この問題の本質は、各Qの主題を探すことにいる

Slide 34

Slide 34 text

構造化思考のポイント ある問題に対して答を見つけるために 考えるべきことを論点という 34

Slide 35

Slide 35 text

今日の最重要ワード 論点 35

Slide 36

Slide 36 text

論点とは その問いに答えるためには 何を考えるべきなのか？ どんなことを答えるべきなのか？ 36

Slide 37

Slide 37 text

目次とはその資料の論点である 各資料内の目次構成 例：要件定義書 1. システム導入の目的と目標 2. システムの概要／システムの構想 3. システム導入後の業務フロー 4. 機能要求 5. 入力要求と出力要求 6. 品質・性能要求 7. セキュリティ要求 漏れ重複ない章立て （一般例） 37 要件定義書の論点 つまり 何を書けば 要件が定義できたと 言えるのか？

Slide 38

Slide 38 text

アインシュタインの言葉 「もし自分が死にそうな状況で、 助かる方法を考えるのに１時 間あるとしたら、最初の55分 は適切な質問を探すのに費や すだろう」 38 画像：https://honcierge.jp/articles/shelf_story/1521

Slide 39

Slide 39 text

何かを考え、表現するときのコツ 何を伝えるべきなのか？（主題） ↓ それを伝えるためには 何を示せればよいのか？（論点） ↓ その内容 39 主題 論点1 論点2 論点X 内容1 内容2 内容X いきなり答を考えようとしない ・・・ ・・・

Slide 40

Slide 40 text

先輩達は考えた 汎用的な事柄を考え表現するのに 毎回論点から考えるのは 非効率だし品質もばらつく 40

Slide 41

Slide 41 text

そこで生まれたのが 主題と論点及びその表現方法などの 組み合わせ一式を フレームワーク/テンプレートという 41

Slide 42

Slide 42 text

いろいろあるので調べてみよう ただ過剰に頼りすぎると 思考が縛られることもあるので注意 42 フレームワークやテンプレートはあくまでも 主題を得るための論点の１つの形でしかない。 背景や文脈にのっとってテーラリング（応用）できる力が必要 フレームワークやテンプレートは 初心者には極めて効果的な手法

Slide 43

Slide 43 text

良いドキュメントを書くには？ 1. そのドキュメントの読み手と主題を 正しく把握する （誰のどんな問題を解決する資料なのか？） 2. その主題の論点を考える 3. 各論点について回答を深堀りし 適切に言語化/図式化する 4. 見た目を最適化する 43

Slide 44

Slide 44 text

構造化思考の演習 44

Slide 45

Slide 45 text

構造化思考の演習 実際にやってみましょう 45

Slide 46

Slide 46 text

構造化演習（１） 部門の飲み会の幹事を引き受けました。 参加数を最大化させられる案内文を考えたいです。 どんな項目が含まれているとよいですか？ 46

Slide 47

Slide 47 text

構造化演習（２） プロジェクトの振返りの意見を集めたいと思います。 依頼フォームを検討してください。 47

Slide 48

Slide 48 text

演習のポイント いきなり項目を挙げはじめるのはNG 目的を果たすために 何を考えればよいかを考える （目的が指示されてなければ仮説を立てる） 48

Slide 49

Slide 49 text

構造化演習（2）ある事例 49 » コミュニケーションの方向に着目したふりかえりの方法 - よこなのへたのよこずき https://ihcomega.hatenadiary.com/entry/2020/04/28/055258 • KPTでやっていた • でも過去振り返りの時間が足りなくなることが頻発 • 議論しなくてもよいことは議論しなくてもいいのでは？ • チーム(または個人) で続けたいこと • 自分 がドヤりたいこと • チームメンバー にお礼したいこと フレームワークを使うことがゴールにならないように 結果や得たい成果を常に忘れないようにしたい

Slide 50

Slide 50 text

ドキュメント作成の進め方 50

Slide 51

Slide 51 text

仕事の進め方にもつながる構造化思考 タスク←ゴール アウトラインから考える 51

Slide 52

Slide 52 text

そのドキュメントの目的は明確か？ なんとなくの積み上げ ≠目的達成 52

Slide 53

Slide 53 text

ドキュメント作業に入るその前に ターゲットとなる読み手 目的や得たい成果 アプローチや論点 上司/依頼者と確認できているか？ 53

Slide 54

Slide 54 text

とりあえずまこなり社長の動画を見よう 54 https://www.youtube.com/watch?v=ArMNB_QTSXw

Slide 55

Slide 55 text

最後に 55

Slide 56

Slide 56 text

今日のまとめ  ドキュメント作成に求められるスキル  漏れなく誤解なく言語化する  知識＋作文能力＋構造化思考  構造化思考とは？  「分かる」は「分ける」  分解＋グルーピング（思考の補助線）  構造化思考の演習  いきなり手を付けず、何を考えるべきかを考える  ドキュメント作成の進め方  目的から逆算して段取りを考える 56

Slide 57

Slide 57 text

良いドキュメントを書くには？ 1. そのドキュメントの読み手と主題を 正しく把握する （誰のどんな問題を解決する資料なのか？） 2. その主題の論点を考える 3. 各論点について回答を深堀りし 適切に言語化/図式化する 4. 見た目を最適化する 57 ★ 構 造 化 思 考 ★ 作 文 表 現 技 術

Slide 58

Slide 58 text

作文技術やPJ知識もめちゃくちゃ大切 こちら参考になれば 58 https://qiita.com/yasuoyasuo/items/1eb7298f91a44dce7abc

Slide 59

Slide 59 text

作文技術を学ぶ上で激しくおすすめの資料 59 https://speakerdeck.com/namura/shui-gadoujian-temosoutosikashou-kequ-renaiwen-shu-shu-gong-kai-ban

Slide 60

Slide 60 text

量が質に転嫁する ドキュメントを書く機会は 自分で作ろう 60 どの現場もあったら助かる資料は必ずあるはずです SNSやブログでも積極的に情報発信していこう

Slide 61

Slide 61 text

Qiita Organizationやってます 61 https://qiita.com/organizations/ari-group?page=1

Slide 62

Slide 62 text

Appendix 62

Slide 63

Slide 63 text

エンジニアのキャリアを考える上で大切なこと 63 ハード スキル ソフト スキル エンジニア（プロフェッショナル）の 市場価値 ハードスキル 体系だった知識や技術 定量化や表現が比較的しやすい ソフトスキル  ヒューマンスキル  定量化や表現も比較的難しい 経験値  判断や設計センスに場数は必要  経験を再現性あるスキルに 変える力も重要 経験値 参考：https://www.slideshare.net/hiroyukitakah/ss-62940166 →自己研鑽がこちらに偏りがち →後回しにしがち

Slide 64

Slide 64 text

武器は最新/最適で多いに越したことはない 64 □PHP、□Java、□SQL、□ASP.NET、□PL/SQL、 □Perl、□C#、□Object-C、□Swift、□C言語、 □COBOL、□C++、□COBOL、□Excel、□VBA、 □VB、□SQL Server、□Ruby、 □Ruby On Rails 、 □VB.NET、 □Oracle、□C#.NET、□Access VBA、 □ASP、□iOS、 □Android、□Windows、 □Linux、 □UNIX、□CSS、 □JavaScript、 □Flash、□HTML、 □Photoshop、□Illustrator、 □ AutoCAD、□Cisco、 □VMware、□Azure、 □AWS、□Docker、□Redmine、 □Git、 □GitHub、□PMBOK ハード スキル ソフト スキル エンジニア（プロフェッショナル）の 市場価値 経験値 ・・・・・

Slide 65

Slide 65 text

ハードスキルを成果に変えるにはソフトスキルが大切 65 ハード スキル ソフト スキル エンジニア（プロフェッショナル）の 市場価値 カテゴリ 項目 コミュニケーティング コミュニケーション ネゴシエーション リーディング ビジョニング チーム活性力（他者への影響、笑力） 率先垂範 動機づけ マネージング 計画性 モニタリング（目標達成型進捗管理） エフェクティブネス（効果性） コンフリクトマネジメント 関係調整力 判断力 認知力 全体的（戦略的）視点 情報収集 問題発見力 課題解決力 プロフェッショナリズム （プロ意識・自己規律） 責任感（達成志向） 倫理観・誠実性 多様性の尊重 引用：PM育成ハンドブック/ IPA（独立行政法人情報処理推進機構）発行 経験値

Slide 66

Slide 66 text

エンジニアのための ドキュメント力養成講座 ～構造化思考から始めよう～ ＜完＞ 2020年5月 ver1.1 ＡＲアドバンストテクノロジ株式会社 中野康雄（@yasuoyasuo）