関連スライド
ソフトウェア開発は懸垂が９割
okbee
>100
みつける・まとめる・つなげる
okbee
>100
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.2M
各ページのテキスト
- 第4回東海医療DX研究会 - なぜソフトウェアはクソになるのか okbee(岡部)
こんなことありませんか？ ・なんでこんな使いにくいものを作ったんだ？ ・いつになったら機能を追加してくれるんだ？ ・この機能、いつ改善されるんだ？ ・開発、時間がかかりすぎじゃない？
なぜソフトウェアがクソになるのか についてお話しします🔥
前提: 開発者は現場を知らない ・開発のプロではあるが、現場のプロではない ・一方、現場の方は開発のプロではない ・どんな形にすれば良いのか正解は知らない ・知識からソフトウェアを仕上げるのが開発の責務
９割の原因は会話不足 ・何よりも開発は現場を知らねばならない ・現場をどれだけ知って想像できるか ・開発と現場が寄り添い会話をすること ・シンプルだが、これに勝る解法はない
会話不足による機能中心開発 ・医療業界の業務フローは複雑で専門知識が必要 ・専門家 (DE) がいないと、まともな開発は難しい ・現場が分からないと機能中心の開発になる ・機能同士のつながりがなくクソになる
NEXT
前提: ソフトウェアは劣化する ・車のように作って終わりではない ・１つのソフトウェアと何年も向き合う ・コードを全部捨ててやり直し！はできない ・気づいた時には増改築を繰り返した家のように
宮崎駿 「ハウルの動く城」より
よしなにやるが蔓延る ・長年の開発により暗黙の実装が積み重なる ・こちらを直すとあちらが壊れる ・機能の追加や変更時に制約となって現れる ・妥協の結果、クソになる
開発スピードが鈍化する ・機能改善をしたいが、長年の負債が立ち塞がる ・早くやりたいが、早くやれないジレンマ ・ちょっとした工事が大工事になるため、後回し ・いつまで経っても改善されない…
NEXT
非現実的な期限 ・時間をかければ良いものができるわけではない ・しかし、非現実的な期限は制約となる ・ソフトウェアはある１つの仮説の具現でしかない ・話す・作る・見せる・改善のサイクルが必要
補足: 期限をなくせは誤り ・よく期限をなくせという開発者がいる ・しかし、ビジネスなので期限はあるのは普通 ・限られた時間・予算の中で何をするのかを決める ・やること・やらないことを決めねばならない
補足: 鉄十字のトレードオフ ・以下の４要素から３要素までしか選べない ・品質(GOOD) ・速度(FAST) ・費用(CHEAP) ・完成(DONE) プロジェクトマネジメントの鉄十字とアジャイルより https://note.com/takahiroyte/n/n8c6c78e082d8
解法 ・開発と現場でよく会話すること ・勝手に想像して機能を作らない ・コードは劣化していることを受け入れる ・いつでも変更できるよう開発者は準備する ・期限を制約として受け入れ何をするのか決める
Thank You ありがとうございました！