2022/02/09 09:45
kkeisuke
“開発する上で書く必要のあるドキュメントの種類を明確にする”
2022/02/09 12:11
kako-jun
対数グラフと似てるけど、tが小さいときに、指数関数っぽい上向きカーブになってるところが細かくて、体感と一致してるわ。まるでドキュメントが無いほうが、どんどん効率が上がってくかのように錯覚するの
2022/02/09 14:16
UKIBORI
これは凄い試みだなぁ “チャットの履歴を一定期間しか残さない GitLabはLet your Slack or chat messages expire quicklyとし、チャットのメッセージを一定期間しか残さないようにしています。”
2022/02/09 14:37
sasasin_net
まったくそのとおりで、ぐうの音も出ない
2022/02/09 14:46
sharaku3eyes
ドキュメント無しは最終的に開発効率マイナスいって事故多発する
2022/02/09 15:22
namagon
(略) 包括的なドキュメントよりも動くソフトウェアを、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。
2022/02/09 15:23
saikyo_tongaricorn
それができれは苦労しないってやつ
2022/02/09 15:59
chinpokomon_master
問題を間違えている。PMFしてからの問題はPMFしない事に比べたら大したことないのでドキュメント書かなくていいからとっととPMFする事が大事。ドキュメントがない苦労はPMFしてからすればいい。典型的な誤謬。
2022/02/09 16:31
morimarii
まずドキュメントを含めてプロダクトだと定義するところからでないの/誰のどういう要求からどのような仕様になったかってのか大事なんですわ
2022/02/09 17:21
tetsu23
そのグラフはちょっと違うかと。ドキュメントを書くぶん、最初の立ち上がりは遅くなるはず。ドキュメントを書くのは大切だとは思うんだけど、それを工数に入れずに書けっていうこと多くて困る。
2022/02/09 17:40
tumo300-500
フェーズ(というか作っているものの堅さ)に依る、かなと。PMF 前後もそうだし、今後は運用回すだけです、なのか、ゴリゴリ機能を削って入れてします、なのかでも違いそう
2022/02/09 18:21
typographicalerror
“チャットの履歴を一定期間しか残さない” これやりたい
2022/02/09 18:24
dfk3
以外というか当然というか、仕事より寧ろ趣味開発の方が仕様書、図面、ソースコード可読性、進捗管理etc.がキッチリしてないとゴールまで行けない。趣味は不定期進捗になるので都度詳細を忘却する。
2022/02/09 19:04
hiroomi
“構造化された文書に力を入れない組織は、チームメンバーが同じデータを何度も要求し、中断、会議、最適でない知識の伝達の拷問的なループを作り出す”
2022/02/09 19:36
mohno
再構築するために必要なドキュメントは必要だし、そうでない情報は理解の邪魔になりそう、ということはある。インターフェイス(関数)の仕様は書いても、プログラムの隣に逐一コメントを書くな、というか。
2022/02/09 21:00
aike
ドキュメントを参照する作業をユースケースとして定義して、そのユースケースがいつ頃どのくらいの頻度で発生するかを予測して、割に合うようならドキュメントを書く、というのが良いと思う。
2022/02/09 21:20
hase0831
“ドキュメントがあれば防げた事態がうまれます。こうして貴重な時間が消費されていくのです”
2022/02/09 21:21
raamen07
ぶっちゃけテストもドキュメントも書いても書いても開発が継続するとバグは無くならないしよく分かんない仕様は存在し続けるんだよな。作った奴がさっさと辞めるのを止める方がいいと思う。
2022/02/09 21:24
yamami78651
ドキュメントなしで進めるのは認識の齟齬が起きやすいし、多くの人は初回設計では書きそう。一方で更新がおざなりになる印象。SSOTを意識するよりも仕組みで解決できるようにIFやDB項目とかは自動化したいところ
2022/02/09 21:34
hisaichi5518
テストあると開発効率あがるみたいなのに近いと思ってる
2022/02/09 21:45
stefafafan
アジャイルソフトウェア開発宣言に関しては "左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく" の部分も強調したい感
2022/02/09 21:49
ssssschang
ものには限度というものがあり、行き過ぎるとnginxの設定ファイルをきれいな方眼Excelに起こしたり、無限にスクショを貼り付けるような虚無作業が発生する。ありなしの二元論で論じるのは危険
2022/02/09 22:06
arx0balest
コードがドキュメントです(怒)
2022/02/09 22:09
yasu-osu
“ドキュメントを書くことがいかにプロダクト開発の速度を上げるかを書きました。"なんですよね。
2022/02/09 22:21
nabinno
開発だけでなくてチーム組成でも同じ事が言える。ベースにあるのは作業ログ。その中で方針が生まれ、手順が生まれ、IaC化される。振り返りはドキュメントが全て。息を吐くようにドキュメントを書こう。
2022/02/09 22:24
deztecjp
グラフの縦軸が「開発効率」なの、全く納得できない。「効率」が一直線に上がるわけがないし、最初がゼロなのも奇妙。「大規模化に伴う効率の低下を補う」くらいの感覚。「成果物の産出量」なら、まだわかる。
2022/02/09 22:36
hateshinaiz
ドキュメント書いてる暇があったらコード書いたほうが早いという人種がいて、彼らにドキュメント書かせるのが超難しい
2022/02/09 22:58
ippeichangg
ドキュメントっつっても内容やらお作法が色々あるからな。ドメインに近い仕事をすると特に意図や経緯について書かれたものがより重要になる。
2022/02/09 23:09
masatotoro
ドキュメントを残しながら設計を進めたいものです
2022/02/09 23:10
suekunhello
memo
2022/02/09 23:10
a-kuma3
そもそも、要求の理解とか、いわゆる設計をすっ飛ばしてコードを書きだす輩が多い。ドキュメントが大事、というより、それをアウトプットできる行為をしてるかどうかが肝要なんだが。
2022/02/09 23:11
kagehiens
効率は上がっていくのを期待はできなくて「落ちない」ようにするだけだろ。グラフを一回微分しろ。
2022/02/09 23:33
maketexlsr
ドキュメント書く能力とコード書く(その他)の能力は別だからなー。脳内のメモリの状態を文章以外の方法でスナップショット取る方法があれば…。(これ、AIの説明可能性と地続きだったりしないかな?)
2022/02/09 23:36
for-my-internet-demo
最近こんな話題ばっかりで引き継ぎフェーズの会社が多くなったんやな。OSS でも初学者がコピペで雰囲気わかるような綺麗なdoc出てきたの実は意外に最近の話ってイメージですわ
2022/02/09 23:54
SWIMATH2
slackの保存期間短くするのエクストリームドキュメンテーションという感じしておもろいな
2022/02/10 00:20
MERCY
これ自体には特に異論は無いけど、嘘を書いたドキュメント(古い情報も含む)が混じってる位なら、全く無い方がまだマシ
2022/02/10 00:28
nishi1231chang
いや、トップブコメはPMFに達するまでに極少人数の開発でできる前提だが、そうとは限らない。あと、数人以上になるとドキュメント無しではすでに少しづつコミュニケーションコストも上がり、生産性が落ち始める。
2022/02/10 00:28
pmint
クソグラフから始まるプロジェクト管理論。人員数を2倍にすれば効率も2倍になるクソグラフ。
2022/02/10 00:43
baronhorse
ドキュメンテーションは難しいんだよな。製品/テストコードより時間かかることとかざらにある
2022/02/10 00:54
carrier_pigeon
「開発する上で書く必要のあるドキュメントの種類を明確にする」だよなぁ。SIerの要求する文書の粒度細かすぎ。設定ファイルとかはIoCでよい。ただし何をどう設定できるのかという仕様や判断理由は必要。
2022/02/10 02:05
nakag0711
説明書的なものと仕様書的なものがあるが…説明書がない機能はユーザにとってないのと同じ。直観的に使えると思ってるのは往々にして作った本人だけ。仕様書がない機能はテストできないのと同じ
2022/02/10 03:34
hiromi_ayase
言いたいことの本筋ではないと理解した上でいわせてもらうが、ドキュメントがあるからって人が増えれば線形に開発効率が上がるかのような表現はやめるんだwwww
2022/02/10 05:40
kat21
バランス問題なのは間違いないが、人数が増えたらドキュメント化は必要。誰が、なんのために読むか、という観点で残すのがいいね。
2022/02/10 06:27
shophonpo8
ドキュメントがないと、設計者の能力不足に気づくの遅れやすい。他人の仕事の未熟さは関係ないのでなく、自分に影響ある箇所に未熟なやつがいるとこっちにも影響でるし、そこがブラックボックス化になりやすく危ない
2022/02/10 06:54
shioki
“少人数のときはいいのですが、大人数になると目に見えてドキュメントがないことへの弊害がみえてきます”
2022/02/10 07:06
fjwr38
ドキュメントを書いたことを忘れるということは度々発生すると思うんだ
2022/02/10 07:37
strawberryhunter
「昔からいる人のタスクは分割され新しい人に割り振られます。そのとき新しい人にどのように仕様を伝えるのでしょうか。そうです、ドキュメントです。」用途はそれだけなの?費用対効果に合うのかなあ。
2022/02/10 07:40
shiba_yu36
2022/02/10 07:45
ledsun
“トップダウンでドキュメントが必須だと明確にチームに伝える” ドキュメントを書くことも仕事だって明示しないといけない
2022/02/10 08:27
toaruR
正確なドキュメントならなー\(^o^)/
2022/02/10 09:30
securecat
“トップダウンでドキュメントが必須だと明確にチームに伝える”←これ、ゆってるだけで工数見積の精度高める努力してない場合ありそうな? ドキュメントの妥当性検証の時間とか含め。
2022/02/10 09:38
u_1roh
スター集めてるブコメひどくない?PMFした後はドキュメント書いた方がいいよって書いてあるじゃん。読まずにコメントしてるのかな…
2022/02/10 09:47
raimon49
GitLabのチャットメッセージに期限付けるやつ、よく話題になるけど相当にハードコアなルールだよなぁ。逆に言えば、それくらい振り切らないと人はドキュメントを書かないのか。
2022/02/10 09:50
kagerou_ts
PMFまでは目をつぶるとしてもそれ以降も書かれないからご覧の有様なんでしょ。これを解決する方法は古来よりひとつしかない。ドキュメント書く人/時間を割り当てる。決定権を持ってる人間が理解しないと無理。
2022/02/10 09:57
GEROMAX
必要なものを必要なだけ作るだけさ
2022/02/10 11:56
peller
Requirement(要求)・Specification(仕様)は純ドキュメント必要。でも実装に関わることはコードがドキュメントだよ。
2022/02/10 12:53
tattyu
更新されないドキュメントががあるよりは無い方がまだましなんだよな。ドキュメントの保守って指示出す人が想像するよりずっと重たい作業なのでみんなの意識が高くないといけないのが大変。。
2022/02/10 15:51
takezaki
“プロダクトが無事PMFをはたし会社も人が増えてきました。そのような状況になるとドキュメントがないことによる弊害が見え始めます。”
2022/02/10 20:33
rararoro-ryo
最近はADRの有効性を言う人が多いけどなぁ。
2022/02/10 21:51
masutaka26
これはめっちゃいいな。議事録も Slack にあるのはキツイんだよな 🌀 "GitLabはLet your Slack or chat messages expire quicklyとし、チャットのメッセージを一定期間しか残さないようにしています"