パスワードを忘れた? アカウント作成
15248707 journal
日記

dotkuwaの日記: 解呪2 13

日記 by dotkuwa

なにやらホラー映画の続編の様なタイトルになりましたが、
・EXCELでDBやPGの設計書を書くのはダメだ
というのも解呪すべきでは無いか?
という趣旨です。
EXCELで設計書を書いて悪いはずが有りません。
 
EXCEL文書の設計書には、
・個々の工夫の説明を
・全部書く
のが一般的です。プログラムで出来る事の真似をして、
実行ロジックを書くのは間違いです。
(やってみれば分かりますが、すぐに破綻します。)
 
プログラムは、
・延々と連鎖が続く、木でできたグラフ
を表現でき、
・「実際に動く」を表現
できます。
 
もちろんこの特典の代償として失点も有ります。
・分かりやすい小ささのプログラムの一部分に
 個々の工夫の説明をまとめる事が出来ない。
 (プログラムのそれなりの範囲に散らばって、
  それら全部で、一つの個々の工夫の説明となる。)
です。関数という括りはもちろん、オブジェクトと
いう括りでもまとめる事が出来ない場合が有ります。

もちろん、工夫とはとても言えないトリビアルな内容なら
まとめる事も可能でしょうけれど、
仮にも「工夫」と言えるレベルの内容だと、間違い
無く散らばります。

 
なので、その失点を補完する為にEXCEL文書が
必要なのです。
(もちろんEXCELで無くてはならない訳では
 有りませんが、ここでは「EXCEL文書かその
 類の文書」程度に捉えて下さい。)
 
ーーーーーーーーーーーーーーーーーーーーー
 
・EXCELでDBやPGの設計書を書くのはダメだ
と言っていた人間は、
・では何が良いのか
を明確にはしませんでしたが、想像するに、
・EXCEL文書とプログラムの利点を融合しようとした
のだと思います。
なぜなら、
・ダメだとしたEXCEL文書より良いものとして、
 ERツールとかを推していた
からです。
実行可能な文書というやつだと思います。
 
これは完全な誤りでした。
役割分担がきちんとしていた、EXCEL文書とプログラム
を、何の根拠もなくまぜこぜにしただけだからです。
 
・実行可能文書ならプログラムが有ります。
 そしてプログラムは、実行可能であるが為の失点も有ります。
・それを補完する(個々の工夫の説明を全部書く)為の
 EXCEL文書だったはずが、
・その役割の文書内に、実行可能の要素を入れて
 「改良した」とイキっても、
EXCEL文書で得られていた特典を減らし、失点を増やす
 だけ

となったからです。
 
その役割の文書に実行可能の要素を少しでも入れただけで、
・分かりやすい小ささの実行可能文書の一部分に
 個々の工夫の説明をまとめる事が出来ない。
という失点が、即座に現れたはずです。自分が見た限りでは、
100%そうでした。

 
この点は解呪されるべきです。
EXCELで設計書を書いて悪いはずが有りません。

  • by dotkuwa (9387) on 2021年04月04日 18時05分 (#4006488) 日記

    何で、
    ・ERツール
    でExcel文書の代わりはダメなのか?
    ですが、
     
    ・ある工夫から作ったプログラムを見て、
     逆に工夫を読み解くのが困難
    なのと同様に、
    ・ある工夫から作ったデータベースのエンティティや
     リレーションを見て、
     逆に工夫を読み解くのも困難
    であるからです。
    もろ、実行可能文書の欠点が現れています。
     
    もちろん、プログラムの「パフォーム、アンティル、
    終わるまで」とかの様な本当に動的な話とは、
    DBのERは違い、もっと静的ですが、それでも
    実行可能文書の失点が如実に現れます。
     
    だからです。
    多分、複数の工夫が、実行可能文書では同じ表現と
    なってしまうのだと思います。
    明細を捨てて合計だけ取っておくと、後で明細を
    調べる事が出来ないのと同じかも知れません。
     
    ある意味、実行可能文書は「明細」を捨てて、
    その分、「実行可能」という権能を得ているの
    かも知れません。

    ここに返信
  • by Anonymous Coward on 2021年04月03日 8時27分 (#4005937)

    むかし設計書はWordの現場にいたことがあるのでAC

    ここに返信
    • by Anonymous Coward

      その設計書がどのフェーズのものかによりますが、それでもwordで書いても良いでしょ。

      だいたいダメなものは、何を使ってもだめです。

      • ソフトウェア開発に携わっていて、アクセス許可も有るのに、
        自分はプログラムは見ない、だから「プログラムで無い」
        実行可能文書が必要だ、とする倒錯的な人が
        いなくなれば、どんなツールでも(クラウドのチャットツールでも)、
        何でも問題無いはずです。
        要は文系的な、心の持ちようだと思います。

  • by Anonymous Coward on 2021年04月05日 11時31分 (#4006751)

    高速開発ツールなどが流行りだした頃の話なので、Excel以下の設計書は無視してくださいね。
    そのレベルならどの文書作成ツールでも変わらないので。もちろんExcel方眼紙に代表されるよう、Excelは文書作成ツールとしても優秀なのですが。

    Excel設計書の欠点は「汎用」の「ファイル」であるということです。
    設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。
    ただし面倒なので、専用のツールがあればそれを利用するのが望ましい。

    ファイルの何が駄目かというと、よくある間違ったバージョン管理のように、
    どのファイルが最新なのか、どのファイルを正とするのかわかりにくいということがあります。
    顧客への提出前に最終チェックしてたら漏れに気づいて修正したけど元ファイルに反映されていなかったとか。

    次に汎用の何が駄目かというと、何を変更したのか分かりづらいということが挙げられます。
    設計書の項目を増やしたこと、値を増やしたこと、値を変更したこと、
    すべてExcelにとっては等価でありすべて同様の変更履歴となります。
    専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになります。
    できれば設計書に変更が入れば自動的に変更履歴を書き出してくれるところまでして欲しいですね。

    最初に戻って高速開発ツールの話になりますが、最終的にはシステムと統合されて
    システムで設計変更すると設計書とプログラムテンプレートに反映されるという触れ込みでした。
    ERツール推しの人もおそらくその流れでの発言でしょう。
    もちろん現在でもそこまでは実現されていないはずです。一部は実現できているのですが。
    ただ上述したようにExcelでの欠点は分かっている上に、その欠点がモダンなプログラマと相性が悪いのも間違いありません。

    たしかにEXCELで設計書を書いて悪いはずが有りません。
    ただしそれはフルスクラッチでシステムを書いて悪いはずがありません。とかドット絵でゲームを作って悪いはずがありません。などと同じレベルの発言です。
    フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったように、3Dゲーム全盛時に暗黒時代を迎えたように、近い将来競合他社に手も足も出なくなるでしょう。
    少なくともExcel設計書に満足せず工夫し、設計書作成業界をキャッチアップし続ける必要はあります。

    ここに返信
    • >設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになります
      EXCELで同じことをするのは大変ですが、
      それより楽にできるのでしょうか? gitなんかでも、変更毎に全体をzipで固めて記録する
      だけで、影響があったかどうかは、人間が解釈します。

      記録出来るようになります言いますが、どんなキャッチアップすべき進歩なのでしょうか?
      何も、具体的にはおっしゃっていない様で、参考にならないです。
      EXCELでない何があるのでしょうか?

      また、フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったシステム
      と言うのは、単なるわら人形です。そんなものは過去に存在しません。

      • by Anonymous Coward

        現在は自社独自でシステム開発するよりはパッケージ導入の方がメインですよ?
        日経BPでもSIerに開発能力がなくなり御用聞きに成り下がってるだのSIer不要論が出ているとまで嘆かれてます。少々文脈が異なりますが。

        とりあえず現在のところ実現されているのは高速開発ツールやBPMなどですね。
        少なくともどの設計変更が何のために行われたのかは記録できます。
        そのことによって、その設計変更の元がキャンセルになったときにどこをロールバックすればいいのか分かります。
        あるいは追加で設計変更するときにどこまで影響があるのか把握できたりもします。

        単に記録するだけならExcelだけでもいいですよ。そう言ってるじゃないですか。
        その記録をどのように生かすかという観点がこれからの(大規模)システム開発には必要なんです。

        • 高速ツールは、コードが無いのにどう、履歴を自動で得るのか?
          その点では、退歩になっていないでしょうか?
          やって無いので確かなことは知りませが。。。
           
          パッケージだって同じ方向性です。
          パッケージのせいで、システム全体を自動で俯瞰し難くなる
          (機能間は使用者が、「見立て」でカバーしている)
          ので、その見立てを自動で得るのは、ソースを全体見られた頃
          より困難で、
          ・何年経っても、何も出てこない
          のは、現状認識としては、#4011219さんも肯定すると
          思います。

    • ・モダンなものが有るはずで、今のものは劣っている。
      ・何年経っても、何も出てこない。
      ・現実、今のものが比較的にベターだ。
      というのをここでは、解呪と言っています。
       
      更に、xが最後に付いたEXCELデータは、拡張子を.zipに変えて
      解凍すれば、
      いくつかの.xmlファイルになり、シート名と.xmlファイル名の
      対応.xmlファイルから追っていくと、セルとかが、エレメントに
      なっており、プレーンなテキストファイルより、
      有利な場合すら有ります。
       
      ただそれでも、その有利さは「たいしたこと無い」(少し変更内容が
      多いだけで、変更箇所の判定が「文書の大部分」になってしまい、
      自動の解析として、意味を成さなくなる。)ことが検証されているので、
      誰も口にしないたけです。
       
      ご指摘のより良い、学ぶべきものとは、具体的には何でしょうか?

      • by Anonymous Coward

        如何に手を抜くか。プログラマの命題でもありますね。
        現在の状況を簡単に言えば、ドキュメントなんて別個に起こしたくないということです。
        設計変更の打ち合わせをしたら、それがそのまま設計書およびその履歴になってほしい。
        そのためにはIT知識の比較的少ないクライアントでも直観的に分かるような表現とそれを管理するツールが必要です。

    • by dotkuwa (9387) on 2021年04月07日 19時19分 (#4008590) 日記

      >Excel設計書の欠点は「汎用」の「ファイル」であるということです。
      >設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。
       
      データなのは確かかも知れませんが、
      ・設計時はまだいろいろな事が固まっていない
      ・だから、スキーマに相当するものを頻繁に変更する。一人の人が一時間に10回変えるかも知れない
      ・そのデータベースを10人でいじっていたら、一回の変更の作業時間は0.6分しか取れない
      ・だからと言って、NoSQLが良いかというと、IDとTEXTのデータにしかならず、
      ・ファイルで担保されていた「ファイル内」という一とまとまりさが失われる。
      なので、ファイルで良いと思います。
       
      >専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのか
      それはスキーマに相当するものを頻繁に変更する事が無い場合に限られると思います。
      設計の「がちゃがちゃさ」をあまりに少なく評価しています。
       
      >設計書に変更が入れば自動的に変更履歴を書き出してくれる
      プログラムならレッドマインでも使えば良いでしょうけれど、それはプログラム言語という
      のが、「スキーマに相当するものがかなり固定」で有る為です。
       
      あなたは設計書の話をしていないと思います。

      • by Anonymous Coward

        スキーマレスデータベースというのがあるんですよ。
        流行ったのはNoSQLの前ですね。NoSQLは分散データベース関連なので。
        親コメで書いたように、スキーマの変更はスキーマの変更として履歴に残すべきです。

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...