SEで働き始めました。 ドキュメント作成ばかりに工数、時間をかけていてアホらしく思えてきました。フォーマットへの異常なこだわり。レビューの時間取るなど 本当に非効率的すぎませんか？

Question

もちろん大事です。品質を高めて維持するためには。ですが、まずちゃちゃっと試作品作ってそこから考えて行く方が良くないですか？
コード書いてもないのに設計書でコーディングできるレベルの資料作るの普通逆じゃないですか？軽くコーディングしてから詳細設計書で固める方がいい気がするのですが、今はAIもあってコーディングなんて簡単じゃないですか。設計書が大事だと思いますがコードも書かずに設計書書いてるので頭の中でまとめながらやるの頭悪いですよね。
上司に言う気力は生まれません。
だらだら書いてるだけなのでお金もらえていいのですが効率的に取り組めるのになと思いながらやってます。
皆さんはSEにおけるドキュメント作成どう思いますか？また時間どれぐらいかけていますか？

Answer 1

私も同じです。

建築家なら、高層ビル建てる時、設計書作って、検証してから
大工が作ると思いますが、

新しいビジネスモデルやシステムつくるときに、成功するかわからない、どこに穴があるかわからないものを、現物確認なしで作るなんてありえない。

小さく初めて、検証しながら大きくし、チームメンバーが理解しないとまずいのなら、コードから自動でドキュメント作成する方に振り切るべきと思います。

なので、携わるひとそれぞれで答えは変わりますが、
私は質問者様の課題感に共感しました。

Answer 2

いまはドキュメント作成にかける時間が仕事の3割くらいですかね。コーディングやテストは2割に満たない。残りの5割がレビューだの会議です。実にアホらしい。
質問者さんはQC（品質コントロール）のためには必要だとお考えですけど、実際に品質向上に繋がっているとは言い難いですよね。現実的には問題が起きたときの責任を明確にするための証拠を残しているだけです。
でも会社組織というのは何かあったときに誰がどう責任を取るか決めるのが大変です。そこを速やかに明確化できるのは意義があります。

もう一つ大事なのは、ドキュメントが未来への情報提供になることです。
「そういえば昔、同じようなことをやっていたよな？」という事例が発生したときに、ちゃんとしたドキュメントが残っているとそのときに働いている人が非常に助かります。IT業界は転職を繰り返す人も多くナレッジの維持が困難な業界ですから、未来に向けてドキュメントを残しているという意識は持ったほうが良いと思います。

未来は意外とすぐにやってきます。
潜在していたバグが見つかった、なんてのが一番よくある話です。ほかにもユーザが想定外の使い方をしてるのでガードをかけたいとか、追加機能要望とか、Windowsのバージョンアップで動かなくなった機能があるから対応しないといけないとか。

そういうときに、ドキュメントがきちんと残っているとすごくありがたいのです。自分は中途入社でいまの会社に入りましたが、6年以上前のドキュメントが揃ってないので、古いシステムは叩き上げのベテランしか対応できないのが実情です。でも5年前から後はしっかりドキュメントが残ってるので、中途入社の自分でも理解ができるんです。

実は私も20年前はSI業者に向かって「成果物としてドキュメントは一切要らないです。その代わりプログラムのソースコードや、ミドルウエアのパラメータ設定情報を納品して下さい」と言ってました。著作権がどうの～とかゴネられた記憶がありますけど、そのくらい、ドキュメントが信頼できなかったんですよね。いまはドキュメントの信頼性が上がっていると感じます。しかし生産性が落ちているとも感じます。20年前はプログラム10本くらい並行でコーディングしてテスト、デバッグを1週間くらいで一気にやってましたからね。いまでは考えられない話です。

Answer 3

一人で作れる超小規模ならばそれでも良いけど。

ほとんどの時間が認識合わせの時間だから。

Answer 4

質問者様のお気持ち、すごくよく分かります。私もシステム開発の現場で働いていますが、同じように「これ本当に必要なのかな」とモヤモヤした経験が何度もあります。

実際のところ、現在の日本のSIerや大手開発現場では、コードを書く前の設計書作成やフォーマット調整に膨大な時間を割く運用が根強く残っています。効率を重視する立場からすると、試作品（プロトタイプ）を先に作って動かしながら仕様を固めるアジャイル的な進め方のほうが理にかなっているように感じられますし、特にAIを活用できる contemporary な環境であればなおさらそう思われるのはごく自然なことです。

ですが、このようなドキュメント重視のやり方が横行している背景には、業界特有の事情があります。多くの開発プロジェクトでは、設計と実装を別の人間や協力会社に担当させることが多いため、「誰が読んでも同じ実装ができる状態」を作らざるを得ないという側面があります。また、障害が発生した際の責任の所在を明確にするための担保や、将来的に別の担当者に引き継ぐ際の保守性を確保するという目的も大きいです。品質保証のプロセスとして、設計段階での不整合をレビューで潰すほうが、後からコードを修正するよりもコストがかからないと考えられていることも理由の一つです。

時間配分に関しても、プロジェクトの規模や手法によって大きく異なりますが、従来のウォーターフォール型の現場では、全体の工数の3割から5割近くをドキュメント作成とレビュー調整に費やすケースも珍しくありません。私自身や周囲の事例を見ても、新規開発のフェーズでは実装と同じかそれ以上の時間を仕様書作りに取られることはよくある話です。

非効率だと感じながら付き合っていくのはストレスが溜まるものですが、思考の整理ツールとして割り切って活用したり、AIを使ってドキュメントの初期案やフォーマット整形を自動化して自分の手を動かす時間を減らすなど、個人でできる範囲の効率化を模索してみるのも手です。無駄に思える作業もお金をもらいながら業界の構造や文脈を学ぶ機会と捉えて、適度に力を抜きながら進めていくのが精神的にも良いのではないかと思います。