---
title: なぜソフトウェアはクソになるのか
tags: 
author: [okbee](https://docswell.com/user/okabe-yuya)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/VJNY4VZ878.jpg?width=480
description: 第4回東海医療DX研究会
published: December 06, 25
canonical: https://docswell.com/s/okabe-yuya/KWRMND-2026-06-16-223409
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/VJNY4VZ878.jpg)

- 第4回東海医療DX研究会 -
なぜソフトウェアはクソになるのか
okbee(岡部)


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YE9PQ6ZXJ3.jpg)

こんなことありませんか？
・なんでこんな使いにくいものを作ったんだ？
・いつになったら機能を追加してくれるんだ？
・この機能、いつ改善されるんだ？
・開発、時間がかかりすぎじゃない？


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GE8DGZ19ED.jpg)

なぜソフトウェアがクソになるのか
についてお話しします🔥


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LELMGDQM7R.jpg)

前提: 開発者は現場を知らない
・開発のプロではあるが、現場のプロではない
・一方、現場の方は開発のプロではない
・どんな形にすれば良いのか正解は知らない
・知識からソフトウェアを仕上げるのが開発の責務


# Page. 5

![Page Image](https://bcdn.docswell.com/page/4JMYQP16JW.jpg)

９割の原因は会話不足
・何よりも開発は現場を知らねばならない
・現場をどれだけ知って想像できるか
・開発と現場が寄り添い会話をすること
・シンプルだが、これに勝る解法はない


# Page. 6

![Page Image](https://bcdn.docswell.com/page/PJR981LN79.jpg)

会話不足による機能中心開発
・医療業界の業務フローは複雑で専門知識が必要
・専門家 (DE) がいないと、まともな開発は難しい
・現場が分からないと機能中心の開発になる
・機能同士のつながりがなくクソになる


# Page. 7

![Page Image](https://bcdn.docswell.com/page/PEXQ8YW8JX.jpg)

NEXT


# Page. 8

![Page Image](https://bcdn.docswell.com/page/3EK9K3VLED.jpg)

前提: ソフトウェアは劣化する
・車のように作って終わりではない
・１つのソフトウェアと何年も向き合う
・コードを全部捨ててやり直し！はできない
・気づいた時には増改築を繰り返した家のように


# Page. 9

![Page Image](https://bcdn.docswell.com/page/L73WZGM675.jpg)

宮崎駿 「ハウルの動く城」より


# Page. 10

![Page Image](https://bcdn.docswell.com/page/87DKR16MJG.jpg)

よしなにやるが蔓延る
・長年の開発により暗黙の実装が積み重なる
・こちらを直すとあちらが壊れる
・機能の追加や変更時に制約となって現れる
・妥協の結果、クソになる


# Page. 11

![Page Image](https://bcdn.docswell.com/page/VJPKWQYQE8.jpg)

開発スピードが鈍化する
・機能改善をしたいが、長年の負債が立ち塞がる
・早くやりたいが、早くやれないジレンマ
・ちょっとした工事が大工事になるため、後回し
・いつまで経っても改善されない…


# Page. 12

![Page Image](https://bcdn.docswell.com/page/2EVV85GPEQ.jpg)

NEXT


# Page. 13

![Page Image](https://bcdn.docswell.com/page/57GL568QEL.jpg)

非現実的な期限
・時間をかければ良いものができるわけではない
・しかし、非現実的な期限は制約となる
・ソフトウェアはある１つの仮説の具現でしかない
・話す・作る・見せる・改善のサイクルが必要


# Page. 14

![Page Image](https://bcdn.docswell.com/page/4EQYZ49WJP.jpg)

補足: 期限をなくせは誤り
・よく期限をなくせという開発者がいる
・しかし、ビジネスなので期限はあるのは普通
・限られた時間・予算の中で何をするのかを決める
・やること・やらないことを決めねばならない


# Page. 15

![Page Image](https://bcdn.docswell.com/page/KJ4W3QX171.jpg)

補足: 鉄十字のトレードオフ
・以下の４要素から３要素までしか選べない
・品質(GOOD)
・速度(FAST)
・費用(CHEAP)
・完成(DONE)
プロジェクトマネジメントの鉄十字とアジャイルより
https://note.com/takahiroyte/n/n8c6c78e082d8


# Page. 16

![Page Image](https://bcdn.docswell.com/page/LE1Y1PN57G.jpg)

解法
・開発と現場でよく会話すること
・勝手に想像して機能を作らない
・コードは劣化していることを受け入れる
・いつでも変更できるよう開発者は準備する
・期限を制約として受け入れ何をするのか決める


# Page. 17

![Page Image](https://bcdn.docswell.com/page/GEWG824WJ2.jpg)

Thank You
ありがとうございました！