2019年12月7日渋谷で開催された『ソフトウェア開発 炎上学概論』の閃利（株）河村の発表資料です。 https://connpass.com/event/154861/

2. 発火・防火
（炎上の原因と対応）

3. 発火・防火の要因概要
•発火：情報の不足
・技術情報、工数情報、仕様情報、スケジュールなど。
⇒ 防火：コマメな情報伝達・コミュニケーション、ドキュメントなどによる漏れの無い情報管理
•発火：遅い行動
・完全主義により発信を先延ばし、情報の不足により先手を打った行為ができない。
⇒ 防火：行動計画を事前に明確化、小さくて確定・決定を早めに行っていく。

4. 発火：ワークフローの未確立
• 各工程において何をすべきか明確化していない。
• 全体の工数見積ができない。
• スケジュールの修正が進行していくたびに起こる。
各工程ごとの作業項目、作業の流れを確立する。（マニュアル化する）
⇒ 工数見積、スケジュールの精度があがる。
防火

5. 発火：ドキュメントの未整備
• 各工程において収集・整理する情報が明確でない。
• お客様、チームでの情報の共有に漏れができる。
• 実行計画に漏れができる。
各工程・作業ごとに定式化したドキュメントを整備する。
⇒ 情報の漏れが少なくなり、情報の共有がしやすくなる。
※ワークフローとドキュメントは密接に結びつく。
防火

6. 発火：重い腰、先延ばしの課題
• 完全な状況を目指したり、やることが明確でないために提出や打ち合わせが遅れがち。
• 決定を持ちかえりや次回に回しがち。
やることを明確化したうえで、早めにできることから小さくでも提出、打ち合わせ決定を行なう。
⇒ 少しずつでも早めに動くことで、問題点を早めに明確化できる。
防火

7. 発火：曖昧な情報伝達、意思疎通の不足
• 決定事項、確認事項が明確化しておらず本来情報伝達すべきことができていない。
（ワークフロー、ドキュメントと関連）
• 個々人の関心事が狭く、時間的に先、組織としての全体の配慮がなく、注意喚起・意思疎通などが少ない。
• 言葉だけでの確認により、実際には完了していないことが多い。
・全体の作業内容をチームで共有し、個人の関心を超えて配慮をする。
・チーム内でのコミュニケーションのしやすい環境づくり。
・特に、マネージャやリーダが全体的な配慮とコミュニケーションを心がける。
・進捗などはコードなど成果物の確認など、形のある情報伝達を心がける。
防火

8. 発火：焦点や成果物が不明確な打ち合わせ
• 議題が明確でない、関係しない人が参加して、参加者の時間を無駄にしている。
• 会議の成果物が残らない、残りにくい会議で結局、関係者に事後で問い合わせをして会議の
意味がない。
・議題の焦点を小さくして関係者が密接に発言し、成果物を残す会議をする。
・全体的なブレインストーミングは控える。（やるならそれ専用の打ち合わせを設ける）
・情報伝達をすること前提で、会議参加者は絞る。
防火

9. 発火：無駄な作業
• 修正が頻繁にある書類、そもそも利用価値のない書類の作成。
• ライブラリやツールを使えばできることを自作して無駄な時間をかける。
• テストデータ作成などスクリプトやツールを使えばいいのに手動で行なう。
・工程ごとの作業を見直し、無駄な書類は作成しない。
・製造等においては積極的にライブラリやツールを利用する。
・データ作成などSQLやスクリプトなどをつかって作業を高速化する。
防火

10. 発火：事後レビューなし、実績データの未活用
• 案件が終わったあとに作業の改善点を話し合わない、共有しない。（同じ失敗をまたする）
• スケジュールや進捗確認の際に、実績を元に判断しないためスケジュールどおり行かない。
見積もりの精度が悪い。
・案件が終わったあとには、作業ごとの事後評価を行い、問題点を共有し、次回に解決できるよう
に策を講じる。
・進捗資料など作業実績を工数の見積もりやスケジュールに活用する。
防火

11. 発火：未分業で高負担、逐次作業
• プログラマーが設計からテスト、進捗管理まですべての工程や作業をにない、一つ一つの工程
の負荷が高くなり、速度が遅く、質が悪くなる。
• 未分業のため、工程を並行して進められず、工期が長くなる。
・設計、テスター、プログラマーなどを分業し、一人あたりの負担を減らす。
・設計後のテストや製造を並行して行い、工期短縮を図る。
防火

12. 発火：士気が低い・雰囲気が悪い
• マネージャやリーダー、メンバーが威圧的でギスギスすることで、若手などが萎縮してしまい、
生産効率が悪くなったり、状況をはじめとする情報の吸い出しができない。
• あまり他人のことに関わらないで置こうという雰囲気なり、助け合いができない。
・マネージャー、リーダー、先輩が士気を下げない、雰囲気が悪くならない環境をつくる。
⇒ マニュアル化できてないところをコミュニケーションで補ったりできる。
⇒ 助け合いがしやすくなる。
防火

13. 発火：工数見積が甘い
• 作業が明確でないとやるべきことの工数が漏れている⇒合計工数が短くなる。
• 手戻りや修正、突発事項、準備、レビューなど異常系や間接的な作業の工数が計上されていない。
• 消化工数も、新人とベテランでは異なる。（同じ作業でも、ベテラン:0.3人日、新人:1人日とか）
⇒みんな同じ消化工数にすることで、実績と予定がずれてくる。
・作業はマニュアル化して、レビューや準備などの間接作業も含め、工数の漏れを減らす。
・異常系についてもバッファ係数をかけて多めに工数を取る。
・参加メンバーの生産性もある程度考慮して、スケジュールを決める。
防火

14. 消火
（炎上後の対応策）

15. 消火策：よく見られる手法
• 残タスクの整理：何を成すべきか、優先順位、実行可能順を整理する。
• タスクと期日、現在の生産性をみて、人的な投入を行なう。（ただし、できるだけ経験者。未経験者を大量にいれない。）
• 期日延長の交渉をお客様など関係者と行なう。（可能なら）
• できる限り、無駄な作業は省く。（自動化やタスクの取捨選択、生産性の高い人が行なう）
• 悪者をつくったりむやみに他人を批判しない。（雰囲気の悪化を防止する。）
・案件の後半に来た場合、劇的な生産性の飛躍はないが、とりあえずはこれで終わらせる。
・そもそも初めから同じことをしておけばいいのだが、物事が進むことでやるべきことが見えてき
ている。
・炎上したら、正直、終わらせることはできても、何らかの痛みは伴う。（防火に務める）
評価

16. 事業規模別
の
発火可能性

17. 防火策の達成度合い（筆者主観）
フリーランス 小企業 中企業 大企業
ワークフローフロー確立 ☓ ☓ △ ○
ドキュメント整備 ☓ ☓ △ ○
迅速な行動・決定 △ △ ☓ ☓
明確な情報伝達 △ ☓ ☓ ☓
活発な意思疎通 △ △ ☓ ☓
焦点や成果物が明確な打ち合わせ △ ☓ ☓ ☓
効率的な作業 ○ ○ △ △
事後レビュー、実績データの活用 ☓ ☓ ☓ ☓
分業 ☓ ☓ ☓ ○
計画的で段取りの良い作業 ☓ ☓ △ △

18. 防火策の達成度合=数値（筆者主観）
フリーランス 小企業 中企業 大企業
ワークフローフロー確立 0 0 1 2
ドキュメント整備 0 0 1 2
迅速な行動・決定 1 1 0 0
明確な情報伝達 1 0 0 2
活発な意思疎通 1 1 0 0
焦点や成果物が明確な打ち合わせ 1 0 0 0
効率的な作業 2 2 1 1
事後レビュー、実績データの活用 0 0 0 0
分業 0 0 0 2
計画的で段取りの良い作業 0 0 1 1
合計 6 4 4 10

19. 理想の防火へ近づけるために
（少しずつ動く）

20. コミュニケーションと少しずつの改善
• フリーランスや中小企業の場合、マニュアルやドキュメントはなく、行き当たりばったりで情報が
判明してくる。（大企業でも程度の差はあれ同じかも）
・コミュニケーションを早く、多目にして、情報の不足を補う。
・体裁や形式はともかく、情報を文字情報として共有する。
・問題や改善策があればチーム内に即座にあげて、すぐにできる対応を取る。
※完璧なことではなく、今すぐにできることを行なう。
・自分たちの不足を早く認知し、分かる人にアドバイスを貰う。（早めに）
対策

21. ソフトウェアの開発工程（参考）

22. 参考文献
• 『[システム開発] 火事場プロジェクトの法則 ~どうすればデスマーチをなくせるか? 』
山崎敏, 2006年,株式会社技術評論社
※大中企業のSIのプロジェクト管理の問題点が書かれている。
• 『人月の神話【新装版】』
フレデリック・P・ブルックス，JR. (著), 滝沢徹 (著), 牧野祐子 (著), & 1 その他, 2014年,
※大規模開発における人員増加の問題点などについて。
• 『デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか KINDLE版』
エドワード ヨードン (著), 松原 友夫 (翻訳), 山浦 恒央 (翻訳),2006年
※デスマーチが起こる原因を外国の視点で。
• 『IT業界の病理学』,司馬紅太郎,秋山浩一,森龍二,鈴木昭吾,都筑将夫,堀明広,佐々木誠,鈴木準一,2019年,株式会社技術評論社
※プロジェクトの管理だけでなく運用なども含めて、業界の仕事の進め方についての問題点が概要的に書かれている。アジャイルなど
への問題点も指摘している。