詳細設計書という名のゴミ

いろいろと厳しいご時世の中、確実に以前よりもお仕事の数は減っているようで、ウチの部門の人たちもプロジェクトから突如解任されたり、プロジェクト自体が自然消滅したりして、部門の席に帰ってきて暇している人がちらほらいる。同じ部門で、かつてトラブルプロジェクトを共に闘いぬいた某後輩くんもそんな中の一人で、つい最近帰ってきたんだが、しばらく暇らしい。

その彼が、何の前触れもなく言った。

「設計書を表記の揺れとかなく書くには、どうしたらいいんですかねぇ?」

作業に熱中していたところに不意打ちを食らった俺。意図をはかりかねて彼を見つめて黙って待っていると、彼は続けた。

「どういうツールがあればいいと思います?例えば、Javaのコード補完みたいに、決められた辞書から入力を補助するツール、あったらよくありません?」

俺ねぇ、そういう、人間の創造力を捨てて機械的にものを作るアプローチ、信じないんだよね。ツールは人の能力を増幅するものであって、足りない能力の補完はしてくれないんだぜ。話、聞く相手間違ってない?

「うーん、WordとかExcelでっていうこと?あるじゃん、IMEが。ツールなんか作んなくてもプロジェクト専用の単語詰めたユーザー辞書つくって、それメンバーに配ればそれでいいんじゃないの?ツール非依存だぜ」

俺は彼の出した要件を120%満たす完璧なソリューションだと確信した。しかも超汎用性が高い。

「えー、それは違うじゃないですかぁーw」

正解のつもりだったんだが…ギャグかなんかだと思われているらしい。「もーむす」って書いたら「モー娘。」になるとか、「あkb」って書いたらもしかして「AKB48」って変換してくれる、あれと今の話はいったい何が違うというのだ(なお彼の名誉のために言っておくと、彼も別の人から同じ話題を振られただけで、俺の意見を聞いてみたかっただけみたい。本当はとても優秀な人だ)。

まぁそんな雑談してたのだけど、この業界で繰り返されるこの手の話は本当に根が深い。いつも思うのだが、この議論の背景には必ず、プログラムを日本語で書いた「詳細設計書」がある。彼らはあえて口にしない、あるいは気づいていないが、これには以下のおかしな前提がある。

  1. コードを書くことは基本的に設計を伴わない単純作業である。コードを書き始めるということは、設計が終わったということ。
  2. プログラマーは「詳細設計書」がないとコードが書けない。単純作業をするためのほとんど考えない人たちだからな。
  3. だから要件を理解している上流担当の人が、日本語でプログラムをかくための説明書を作ってあげる必要がある。それが詳細設計書だ。

設計者は、処理の流れをExcelで書く。まぁExcelで書くかどうかはここではどうでもいいのだが、とにかくExcel、それがルールだ。で、入力情報はどこからどうやって持ってきて、どういう順番でどういう計算をして、監査記録をどこに残して最後にどこにどういう結果を出力するか、とかを、小学生の読書感想文以上につまらない感じで淡々と書く。愛とか感動とかそういう要素は一切ない。

プログラマーは、それを見てJavaとかのプログラミング言語に一字一句変換していく。この変換作業こそが、彼らのいう「実装」だ。ちなみに、プログラマーが親切心から設計書に書いていないことを実装なんかした日には「設計書と違う、勝手なことをするな」とか怒られかねないので、多少(いや、かなり)変だと思っても設計書に書いてあるままに作ることが多々ある。なにしろ、どんなに正しく作っても、スケジュール内に作らないとメチャクチャ怒られるからな。仕様が間違っていようが書いたプログラムが動かなかろうが、スケジュールに間に合わせることが全てだ。インド人や中国人と仕事をするならその辺どう考えているか、聞いてみてほしい。

SI業界はこの、「詳細設計書+実装」プロセスで長年やってきているが、どうしても良い品質のものが上がってこない。そこで彼らは、どうしたら「設計書」に書いてあることがうまく「コード」に間違いなく変換されていくか、ということを考え始めたわけだな。本人たちからは聞いてないけど、多分そうだ。

そこでまず、表記揺れがターゲットになった。同じ意味の言葉を何種類もの言葉で表現すると、正直よくわからない状態になる。だから、あまり設計者が意識しなくても、言葉があらかじめ決められた単語のセットに標準化されるようにしたい。辞書に載っている言葉しか使わなければ、誰が読んでも誤解はしないだろうし、入力ミスもなくなるから、つまらない誤植も減る。設計書の品質があがり、実装に伝わる際のコミュニケーションエラーも大幅削減。すばらしい!(…のか?)

しかし、だな。

俺からすると、どれだけ遠回りしてるんだあんたらは、って感じがしてならない。そんな無駄な苦労するくらいなら、最初からコード書け、と。

EclipseでJava書いてみろよ、クラス名間違ってタイプした数秒後には赤線が引かれている。途中までかいてCtrl+spaceすれば補完してくれるだろ?IMEの辞書に登録しなくても。しかもdeprecatedとか現在のContextで使えないエレメントは候補に出ないようにもできる。

クラス名変えたい?Refactor-renameすれば、間違いなく該当クラスのクラス名だけをほぼもれなくリネームしてくれるよな。ExcelでContextやらData Type意識した置換ができるか?

前のバージョンから何が変わったのか、Excelで正確に表現できるか?変更履歴シートを作る?その履歴人が書くんでしょ?正しいの?SCMのHistory diffするのとどっちが楽なのよ、それは。

もちろん、いきなり何でもかんでもコード書けっていっているわけではない。ただ、コードが得意としている分野を、なぜにそれを最も不得手とする自然言語とExcelで無理してやろうとするのか、そこが俺には全くもって解せない。全プロジェクトメンバーの中で、一番スキルレベルの低い人に合わせて作業しているとしか俺には思えないんだが、それは客から金もらって働くProfessionalな仕事の仕方なわけ?

それに、プログラミング能力のない人がプログラムの書き方を、Excelでプログラマに指南して、なんかいいことあるか?しかも、なんで、同じことを日本語とJavaにわけて、2人で2回も書いてるのよ?1人が1回Javaで書けばコスト半分だろ?GDつかってコスト1/3ってあんたらちゃんとトータルコスト計算してるのかよ。

…などとイロイロ一人で考えた一日だった。不毛だよな、SI業界。

Advertisements

34 thoughts on “詳細設計書という名のゴミ

  1. 日本の会社が プログラマを「育てる」という発想から抜け出ない以上、詳細設計書は必要でしょうね。
    あと、客がメンテのためにドキュメントを求めてるっていう事情もありますが。
    (ぐちゃぐちゃのソース、見たくないんだろうな・・・)

  2. メンテのためにドキュメントが必要なのは当然で、そのために詳細設計書は確かに必要ですね。でもそれはプログラムと同じことを日本語で書いたものである必要はないんですよね。プログラムを日本語ExcelやWordを使って表現してもわかりづらいですし。
    結局のところ、SIerが「従来からやってきた詳細設計とはそういうもの」という空気に流されてこれを問題ととらえていない、そして変えようとしていないこと、それからお客さん側も使うかどうかよくわからないままに形だけの設計書を、監査対策等のために求めている、というのが問題だと思っています。
    プログラマーの人はコード見ればわかるから、コードを日本語で説明した資料なんかあっても読まないですからね。そういう意味で、本来詳細設計書はプログラムを読む前の知識を得るためのものとして、プログラムに書かれていない、設計上の決まり事やその設計に至った理由とかが書かれているべきだと思っています。

    • 決まり事、理由という観点は大事ですね。ソースコードにも埋め込んでいるといいことがあるかもしれませんね。図と言語という視点で、設計図があるといいかも。http://researchmap.jp/jog1jgxcc-50024/#_50024 に整理中。

  3. システムが稼働しなくなるまでずっと同じメンバーで保守やっていくなら詳細設計書はいらないかもしれないが、そうじゃない。

    他のプロジェクトから異動してきたプログラマにいきなりコード見せたら卒倒するよ。

    クラスとの相関関係もインターフェースもコード読み込んで頭を整理するために結局は詳細設計書みたいなものを書くことになるだろうね。

    また、プロジェクトに他社も参画してるような場合に「あのクラスのインターフェースってどうなってる?」って聞かれた時または聞いた時にソースコード渡すのって超非効率でしょ。

    詳細設計書を共有しておけば無駄なやりとり不要でインターフェースの確認もできる。

    詳細設計書をゴミっていう人は自社開発など小規模なシステム開発しかしたことないんじゃないかな?

    • 勢いで書いているのでタイトルが良くないのは認めますけど、別に設計書がいらないという主張をしているつもりはありません。

      一言で詳細設計書といってもいろいろなタイプがあるでしょうから想定しているものが違っているだけだと思いますが、私がいっているのはプログラムと同じことをExcelでなぞるように書いてあるもので、本来的には詳細設計書と呼ばれるべきではないものです(が、私の見てきたプロジェクトの大半では詳細設計書と呼ばれていました)。実際に動いているコードと同期がとれているかすら怪しい日本語コードもどきをみてコードのメンテナンスをするくらいなら、最初からコードを理解する気で読んだ方がずっと効率が良いと思っています。

      まぁ、私は大規模開発は嫌いですから経験が足りないのかもしれませんが、大規模開発で大量にソースコードがある中で、ソースコードと同じ数の日本語プログラム説明書Excelなんかつくって渡されても、それこそ迷惑な話です。誰がそんなもの読むのかと。

      そういう無駄なことを一生懸命人海戦術でやっているから、デスマがなくならないんですよね。

  4. Pingback: ツカエル!ネットの話題 » Blog Archive » 03月08日 17:00版

  5.  詳細設計書を、コードと同じレベルの詳細さで書くのはナンセンスだと、私は思います。なんのために詳細設計書を書くかが不明確なんだろうと感じます。
     一方で別側面の話として、表記の揺れに関しては、それが詳細設計書であろうと、科学論文やプレゼン資料であろうと、テクニカルドキュメントにおいては、表記の揺れるものを書く人間に私は不信感を持ちます。言葉や記号を定義せずにふゎっとドキュメントを書いているんじゃないかと疑ってしまいますね。

  6. Pingback: 詳細設計書という名のゴミ | Gm7add9 | ブログハッカー™ 2chまとめブログアンテナ

  7. > クラスとの相関関係もインターフェースもコード読み込んで頭を整理するために結局は詳細設計書みたいなものを書くことになるだろうね。

    この用途で詳細設計書を書くんなら、コーディングの前に設計のプロセスを持っていく必要はないんですよ。むしろテストが終わって動作が確認できた後に書いたほうが一致度が高い。

    こういう進め方のプロジェクトも結構あるんで、名前をつけて推進させていきたいんですけど
    なんかナウい名前ないもんですかね。品質保証が喜びそうな名前のやつ。

  8. >他のプロジェクトから異動してきたプログラマにいきなりコード見せたら卒倒するよ。

    >また、プロジェクトに他社も参画してるような場合に「あのクラスのインターフェースってどうなってる?」っ>て聞かれた時または聞いた時にソースコード渡すのって超非効率でしょ。

    結局これって一言で言うと、ソース読むスキルが低い、もしくはEclipseなどのIDEの習熟度が低いって事ですよ。SIerはIT業界の中でも技術力の観点でみるとかなり低い方だから、そんな所で長く仕事してる人の考え方ですよね。そんなものを下敷きにしてても良いものはできない。

    だって、バグが発生した時に設計書見る人いないでしょ?設計書なんか見てバグフィックスできる人見たことないし、それよりもソースと整合性が取れてるかの担保はどうやって取るの?
    スキルの低い高い関係なく、バグフィックスする時は「ブレーク張ってステップ実行」もしくは「ログ解析」でしょ。どっちにしてもソースを起点としたものです。

    Javaで言うと、JUnit(Javaのソースなので、Selenimuやその他のカバレッジ系のツールよりも限りなくソースに近いもの)ですら、メンテできなくてゴミ化していってるでしょ。私はフリーランスで10年、今はスタートアップに携わってますが)、JUnitがまともにメンテされてる現場なんかお目にかかった事がないです。

    ましてやソースですらない設計書なんかがメンテできてる訳がない。リリース(SIerでいう納品)が過ぎたらゴミ化していくだけのテンポラリーファイルですよ。

    一番の問題は、プログラマを含めて関係者のスキルの低さ、これに尽きます。Excelみたいなドキュメントが介在する事が更に(ソース読むなどの)スキル向上を妨げている。
    ITのモノを作ろうとしてるなら、もっとソースに精通すべきなんですよ。ソースの読めない・書けないPM、ディレクターはゴミでしかないってのが私の持論です。
    事実、スタートアップや伸びてるベンチャーには、「ディレクションしかできません」、「要件を詰めるしか能がありません」なんて人種いないですから。

    アメリカではかなり定説化してるみたいですが、「コーディング=設計、実装=ビルド」です。なので、今の時代では実装は一瞬で終わるという事です。

  9. >一番の問題は、プログラマを含めて関係者のスキルの低さ、これに尽きます。
    ちょっと話がずれるかも知れないのですが、そもそも「なんかおかしい、違うよね」と言う状況が改善しない・されない原因の一つに「関係者がそもそもスキルを上げたくない、上げようとしていない」というのもあります。

    例えば私が担当してた保険系の会社ですと、
    顧客の担当者「私は保険の仕組みを考え、より良い保険を作って行きたくてこの会社入ったのに、何故かIT部門なんてのに回されて、よくわからないサーバーがどうだ、仕様がどうだなんて話に付き合わされてる。こんなもの担当の会社が全部やれば良いのに!」
    一次請け「やばい、俺プログラムできないしパソコン分からないのにSIerなんて会社に入っちゃった。超やばい。プログラミングなんてしたくない!そうだ!下請けに全部押し付ければ良いんだ!」
    …以下最後の下請けまでループ。

    と言った流れの結果、改善はしなくて良い、とりあえず言われたものだけ作れ文化が醸成されておりました。

    そもそもITの仕事したくもない人がなんでSIerに入ってくるのか、不思議な事象の一つでしたね。

  10. あえてツッコミますけど…
    建築現場の人間に向かって設計書なんて無駄だからイメージ図だけで建造物そのものを作れとか、料理人にレシピも渡さずに未知の料理作れって言ってるのと同じ。
    不毛な話に聞こえます。

    一番の課題は、詳細設計書とプログラムがリンクしていないことじゃないですか?

    • 多分通りすがりさんの「設計書」のイメージが、私の書いた「詳細設計書と呼ばれるもの」と違うだけだと思います。
      設計書を作るなとか詳細設計がいらないとかいっているつもりは全くありません。
      へたくそな文章なのは認めますが、いいように話をすり替えないでくださいね。

      あえてまじめに答えますけど、私が言っている一番の問題はプログラムで簡単に表現できることを、いちいち表現力に乏しいExcelと日本語で書いていることです。Excelと日本語でしか表現できないから、そこから作成されるコードはツールやプログラミング言語の持っている機能を有効に使わない、ifとforみたいな超基本構文だけで書かれたような、メンテナンスしづらいグダグダなコードが大量に作られます。

      コミュニケーションの役に立たないゴミのような資料をつくって余計な仕事を増やしてコードの品質を著しく落としているくせに、設計書とかたいそうな名前をつけて呼んでくれるなっていう話です。

      • ソフトウェア開発が、建築現場に例えられてしまうこと自体が問題だと思います。それが成立するためには、設計書に従って作れば、製品が完成すると担保されているだけです。ソフトウェア開発はそうじゃない。
        私がこの業界でやり始める前は分かりませんが、少なくとも現在のソフトウェア開発は、詳細設計書なんか書いたところで、その通りに実装して完成した試しはありません(ポストによっては、そのように努力したくなる事を否定しませんが、やっぱり不毛だと思います)。

  11. >結局これって一言で言うと、ソース読むスキルが低い、もしくはEclipseなどのIDEの習熟度が低いって事ですよ。

    いいか、大規模なシステムの場合は他チームとの連携が必要な箇所においてソースコードが上がってこないことが多々あるわけよ。

    君はそんな状態のない事を前提に話してるよね?

    経験値の低いアマチュアぷろぐらまーなのかな?w

    そもそも効率のいい悪いを指摘してるのにスキルを引き合いに出してくるとかどんだけ頭悪いんだよw論点のすり替えも甚だしいわ。

    つまり、インターフェースの確認がソースコードから読み取れない奴のために設計書が必要だ!ってことだろ?

    こんなバカなこと言い出す奴はシステム作るなよwそんな自分勝手な奴が作っていいのは個人で開発するアプリぐらいだ。

    管理人さんの言いたいことはわかったよ。

    • 大規模なシステムなら、モジュール間のインターフェースは最初に書くべ。システム全体から見たら詳細設計書だろうが、モジュールから見たらそれが機能仕様書。機能仕様書がいらないとは書いてないよね。その程度の掘り下げではとても分かったようには見えないけど?

      • まず、他システムの連携なんて死ぬほどやった事あるんですが。なんで決め付けてんだか。

        そもそも他システムの連携に、詳細設計書が必要なの?他の会社やチームが作ってるモジュールやシステムの詳細設計書見て何すんの?納品の受け入れでもするつもり?発注元でもないのに。開発するんでしょ?

        Javaでいうとインタフェース、Cとかだとプロトタイプ宣言があれば十分でしょ。
        ドキュメントがあるとすれば、I/F設計書とかエラーコードなどのコード値系の定義書などの補足資料。他システムの詳細設計書が必要だと思った事は一度もないな。

        他システムのソースがあがってこようがこまいが、インタフェースに則ってモック作って自分たち側だけの実装してればいいじゃないの?もしインタフェースも決まらないとしたら、詳細設計書なんてあがってくる訳ないよね?
        なんで、他システム連携と詳細設計書の要不要が関係あるのか全く意味が分からん。

        それに、コード定義書のようなものがあったとしても、結合テストで動かしたら全然違うコードが返ってくることなんてザラにあるぜ。

        PayPal、GMO、J-Paymentを始め、海外の決済代行会社との連携は死ぬほど経験してんだが、コード体系が仕様書通りだった事なんてただの一度もなかった。特に海外は。日本語化されるタイミングが遅いとか、頻繁にコード体系が変わるとか。そんなのに追従してこちら側のアプリを改修するのは無理だから、エラーが返ってきたら「ゴメンナサイ画面」に飛ばすくらいしかやりようがない。
        そんな所に詳細設計書があったとしてどうすんの?
        ドキュメントはどこまで行ってもドキュメント。

        Javaで言うと、Eclipseという優秀なツールが現に存在していて、前にも書いたが本番サーバでは(ドキュメントを解析して動いてる訳ではなく)、ソース(かそれをビルドしたもの)が動いてて、バグフィックスも機能拡張もソースを元に行われる以上、開発にまつわる全ての事に対して、Eclipseを基軸に考えるのが一番スマートだって話。そこにExcelやWordを介在させればさせるほど余計な脂肪分が増える。

        ただ、補足資料や開発メモの類のものは必要だろうから、それは残せばいいと思う。ただExcelである必要は1ミリもない。Wikiでもマインドマップでも、写真でも好きなもので残せばいい。

        ちなみに俺はたった半年足らずだけど、ニューヨークで仕事してた事があるが、アメリカ人はMS-Officeなんてほとんど使ってなかったぜ。

        日本人チームが単なるテンポラリー資料の為だけにExcelに罫線入れて、色付けてキレイなドキュメント作って、会議室予約して、皆のスケジュール押さえて、はいミーティングってやってるうちにとっととモノが出来上がってた。やるとしたら担当者(仕様決定権者)のところに言って仕様を確認するくらい。そこで何らかのメモが必要なのであればnotepadでメモる。
        想像通り、その現場ではアメリカ人は漏れなく定時上がり。日本人はビルの閉鎖時間まで毎日残業。

        ドキュメントに囚われる事が如何に無意味か、君も遠い未来には分かる時がくるでしょ。

  12. 詳細設計書がコード一行一行を日本語に訳したものだとしたら、主が指摘する通り明らかに無駄ですね。

    そんなことに時間をかけるならば、テストとバグ潰しに時間かけるべきです。

    とりあえずコメントを見る限り、詳細設計書の認識がみんな異なることは確かなようです。

  13. 1. 管理人さんの言っている書類を詳細設計と呼ぶかどうか
    2. 詳細設計と呼ぶと決めた書類にコードを日本語で逐語訳するかどうか
    3. 詳細設計書に他に何を書くか

    これら1〜3はプロジェクト毎に決めるべき内容であると考えます。

    ですので、プロジェクトの最初のほうで、
    納品先の事情や、プロジェクト予算の都合、むふふな事情を勘案し、合意後、定義しておきます。
    例)納品先が書類の標準化などをしている場合、その規定に従うか

    このエントリーは管理人さんがご覧になった(だろう)詳細設計書をそうすると決めた
    プロジェクトがあったいうことを意味していて、大変興味深いです。
    10年くらい前までは、よくお目にかかったのですが、最近は見なくなりました。
    今でもあるんですね。

    無事プロジェクトが終わり運用/保守フェーズに入ると
    逐語訳の載っている書類は助かる反面、その保守に頭を悩ますことが多いです。
    書類の正確さの担保の難しさ、簡単にコンパイル/テスト出来るソースコードの信頼性の高さが、担当者のモチベーションダウンに拍車を掛けます。

    ただし、コンパイルやテストが簡単に出来ない環境や、そういう状況を長く経験された方は、書類の力を疑わない人も多く、書類のメンテまでが保守開発です!とモチベーションダウンしない人もいます。

    私は、今後、逐語訳付き書類を新規に作るようなプロジェクトにはしたくないですが、万が一そうなった場合は、ソースコードを貼って、ごまかします!

  14. 管理人さんの言ってる詳細設計って、
    例えば、

    要求仕様
     10回helloを表示する

    詳細設計
     変数iを宣言
     iを0に初期化
     ループ文でiが10より小さかった真とする
     ループ文の中で”hello\n”という引数を表示関数に渡す
     ループ文の中でiを1加算する

    コード
    int i;
    i=0;
    while(i<10){
    printf("hello\n");
    i=i+1;
    }

    ってことだと思いますが・・・
    昔、回路設計の会社で働いてた頃、同じようなことがありましたね。
    先輩に詳細設計が必要な理由を聞いても納得できる回答が返ってきませんでしたが・・・
    たぶん実装(言語)が分からないお客さんに提出しなくちゃいけないから、詳細設計が必要な気がしていますが、開発側の観点からすると、不要ですよね・・・

  15. 詳細設計書はプログラマに見せるため「だけ」のドキュメントじゃない。
    上流の設計した人や、その先にいる顧客との認識合わせにも使うというかむしろそっちがメインと言ってもいい。
    エンドユーザとの認識合わせをプログラミング言語でなんてできるわけない。
    お客にソース読み書きできるようになれとかjavaやeclipse覚えろなんて
    愚痴や冗談ならわかるけど本気で言ってるとしたらビジネスマンじゃない。
    そもそもそうなったらプログラムしか書けない人は失業するよ。

    • 客にソース読めなんて一言もいってませんが。
      プログラマ向けとお客様向けの説明が両方詳細設計書でできるっていうあなたの意見の方が、よっぽど冗談に聞こえますけど。

    • 上流設計との認識合わせは渡された基本設計書の視点や粒度で行うため、上流設計に詳細設計書やコードをフィードバックする開発プロセスはありません。 上流や顧客との役割分担が普通じゃないように見えます。

  16. クラスとの相関関係とかは、ソースの「トピック」だからソースでは表現できないしあると便利なのは分かります。 トピックとしての疑似コードのコールツリーはクラスの相関関係も分かるから特に便利です。 でも多くのコールツリーは文書でなくてもツールで見えるよ。コードが非公開でもね。 だから、図は概要レベルのものをたまにしか見ないな。 また日本語だけの図は理解不能。 概念は関係性によって理解されるものだから関係性を検索して調べられるように図にシンボルがないとダメ。 用語では揺れるからダメだね。 あとコードで表現できるレベルの細かいフローの図は自動生成じゃないと信頼できないね。マルチスレッドならコードで表現できないから要るけどね。
    大規模開発でも、各モジュールの説明書がちゃんとあれば、システム全体の内容(関係性)はトピックで十分だよ。

    だから詳細設計書という名のコードのトピックは必要だけど、コードレベルの詳細は要らないからゴミになるよな。

  17. 本当にそうですね。コードレベルの詳細設計書。
    昔のコーディング用紙かなんかと勘違いしているのか全てを網羅的に書くことが正しいと思い込んでいるのか、不必要な情報が溢れて設計の意図や重要事項が把握できない図や設計書を幾度見たことか。
    誰のために何を書くのかが定まっていない現場や会社では特にそう。
    そいうところってやたらと体裁には拘りますね。
    UML記法を無視した体裁ルールがあったり、チケットすら日報風の定型でないと許さないとか。
    そのくせ全体を示す設計書はなく、よく考えられていないコンポーネント図だけあり、仕様は現場リーダーの頭の中なんてね。
    定型で書かせることで管理してるつもりになっているのでしょうが、そうさせる合理的な理由がない。
    でも声がでかいのですよそういうのに限って。
    それと開発者自身も向上心がなく勉強もしてないから改善しようとする意見なんて出てこない。
    ただ大変だから(面倒だから)っていうぐらいにしか思ってないから声のでかさに負けてしまう。

    • コミュニケーションマネジメントの観点から言って報告を求める側が報告のフォーマットや内容、タイミングを指定するのは当たり前なんですが。
      でないと各々が好き勝手な内容上げてきてリーダーやマネージャが理解するのに手間が掛かります。
      リーダーやマネージャは他にもする事あるし、何より時間単価が高いのでそんな所にリソース掛けるのは勿体ないのです。

      • 好き勝手な内容とはどういうものでしょうか?
        チケット化された作業に対する内容しか上げないと思いますが。
        それに理解するのに手間が掛かるというのは体裁の問題ではなく、記載内容の問題でしょう。

        もしかすると、通りすがりさんの現場も私が過去に入った現場と同じようなチケット管理をされているのかもしれませんね。
        * 1週間とか2週間の工数のチケットがアサインされる。
        * サマリーにはHOGEHOGE機能実装とだけ書いてある。
        * そして毎日の終業時に、本日行った作業内容、明日行う作業内容、発生した問題といった日報風の体裁でコメント欄に記述し、進捗率と所要時間を入力してサブミットする。

        リーダーやマネージャが、これで一体何を誰とコミュニケートするつもりなのか私には皆目見当がつきません。
        かく言う私もPLの立場ですが。

  18. 誰に向けたドキュメントかってことでしょうね。
    1. お客さん
    2. プログラムを実装する人
    ここで1と2の間に齟齬がないようにしなければならず、それを何かしらの方法で証明・担保しないといけないかと。
    そうでないと仰るように実装に対して「そんなの設計書のどこに書いてあるんだ!勝手なことすんな!」ってなっちゃう。
    個人的には詳細設計は最低限外してほしくないところを書いて、お客さんとの担保はテスト項目でとれるといいなぁと思います。

  19. Pingback: 詳細設計書≠プログラム仕様書 | おれのソース

  20. 詳細設計書とプログラム設計書を混同した環境(もしくはSIerと)でお仕事してるのかなと思います。
    規模が大きいシステムだと後者は見たことがありません。
    プログラム設計書ではない詳細設計書であれば絶対必要だと思ってます。
    プログラマーは万物創生の感に浸ってしまいがちですが、コードが書けるとシステムを設計できるの間には、残念ながら大きな溝があります。それを上手に埋める手法を確立していくモチベーションとして、詳細設計書は必要だと考えています。

  21. 米国でプログラミングの仕事にかかったことがあるが、あちらには詳細設計書なるものはない。だってもともと英語で仕様書を書いて、英語が元であるC言語やJAVAで記載する。つまり彼らにとってみればコンピューター言語そのものが英語だからね。
     詳細設計書はごみだと思うが、それでお金がもらえるのならそれはそれで仕事なんだろね。よく思うのは、エクセルで書いた設計書が完璧で、出来上がったシステムがメタメタ、処理速度度外視、結局システムが使えない。そしてそれをチューニングという別の仕事が生じる。
     アメリカのプログラマからみたらただのバカ。こうなったらAIを進化させて、勝手にプログラミングまで落としてしまうプログラムツールを作ればいいんじゃとか思ったり。それとSIのSEをやっててプログラミングができないのは日本のSEだけ、アメリカでそんなこと言ったら即クビです。

Comments are closed.