アカウント名:
パスワード:
高速開発ツールなどが流行りだした頃の話なので、Excel以下の設計書は無視してくださいね。そのレベルならどの文書作成ツールでも変わらないので。もちろんExcel方眼紙に代表されるよう、Excelは文書作成ツールとしても優秀なのですが。
Excel設計書の欠点は「汎用」の「ファイル」であるということです。設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。ただし面倒なので、専用のツールがあればそれを利用するのが望ましい。
ファイルの何が駄目かというと、よくある間違ったバージョン管理のように、どのファイルが最新なのか、どのファイルを正とするのかわかりにくいということがあります。顧客への提出前に最終チェックしてたら漏れに気づいて修正したけど元ファイルに反映されていなかったとか。
次に汎用の何が駄目かというと、何を変更したのか分かりづらいということが挙げられます。設計書の項目を増やしたこと、値を増やしたこと、値を変更したこと、すべてExcelにとっては等価でありすべて同様の変更履歴となります。専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになります。できれば設計書に変更が入れば自動的に変更履歴を書き出してくれるところまでして欲しいですね。
最初に戻って高速開発ツールの話になりますが、最終的にはシステムと統合されてシステムで設計変更すると設計書とプログラムテンプレートに反映されるという触れ込みでした。ERツール推しの人もおそらくその流れでの発言でしょう。もちろん現在でもそこまでは実現されていないはずです。一部は実現できているのですが。ただ上述したようにExcelでの欠点は分かっている上に、その欠点がモダンなプログラマと相性が悪いのも間違いありません。
たしかにEXCELで設計書を書いて悪いはずが有りません。ただしそれはフルスクラッチでシステムを書いて悪いはずがありません。とかドット絵でゲームを作って悪いはずがありません。などと同じレベルの発言です。フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったように、3Dゲーム全盛時に暗黒時代を迎えたように、近い将来競合他社に手も足も出なくなるでしょう。少なくともExcel設計書に満足せず工夫し、設計書作成業界をキャッチアップし続ける必要はあります。
>設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになりますEXCELで同じことをするのは大変ですが、それより楽にできるのでしょうか? gitなんかでも、変更毎に全体をzipで固めて記録するだけで、影響があったかどうかは、人間が解釈します。
記録出来るようになります言いますが、どんなキャッチアップすべき進歩なのでしょうか?何も、具体的にはおっしゃっていない様で、参考にならないです。EXCELでない何があるのでしょうか?
また、フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったシステムと言うのは、単なるわら人形です。そんなものは過去に存在しません。
現在は自社独自でシステム開発するよりはパッケージ導入の方がメインですよ?日経BPでもSIerに開発能力がなくなり御用聞きに成り下がってるだのSIer不要論が出ているとまで嘆かれてます。少々文脈が異なりますが。
とりあえず現在のところ実現されているのは高速開発ツールやBPMなどですね。少なくともどの設計変更が何のために行われたのかは記録できます。そのことによって、その設計変更の元がキャンセルになったときにどこをロールバックすればいいのか分かります。あるいは追加で設計変更するときにどこまで影響があるのか把握できたりもします。
単に記録するだけならExcelだけでもいいですよ。そう言ってるじゃないですか。その記録をどのように生かすかという観点がこれからの(大規模)システム開発には必要なんです。
高速ツールは、コードが無いのにどう、履歴を自動で得るのか?その点では、退歩になっていないでしょうか?やって無いので確かなことは知りませが。。。 パッケージだって同じ方向性です。パッケージのせいで、システム全体を自動で俯瞰し難くなる(機能間は使用者が、「見立て」でカバーしている)ので、その見立てを自動で得るのは、ソースを全体見られた頃より困難で、・何年経っても、何も出てこないのは、現状認識としては、#4011219さんも肯定すると思います。
・モダンなものが有るはずで、今のものは劣っている。・何年経っても、何も出てこない。・現実、今のものが比較的にベターだ。というのをここでは、解呪と言っています。 更に、xが最後に付いたEXCELデータは、拡張子を.zipに変えて解凍すれば、いくつかの.xmlファイルになり、シート名と.xmlファイル名の対応.xmlファイルから追っていくと、セルとかが、エレメントになっており、プレーンなテキストファイルより、有利な場合すら有ります。 ただそれでも、その有利さは「たいしたこと無い」(少し変更内容が多いだけで、変更箇所の判定が「文書の大部分」になってしまい、自動の解析として、意味を成さなくなる。)ことが検証されているので、誰も口にしないたけです。 ご指摘のより良い、学ぶべきものとは、具体的には何でしょうか?
如何に手を抜くか。プログラマの命題でもありますね。現在の状況を簡単に言えば、ドキュメントなんて別個に起こしたくないということです。設計変更の打ち合わせをしたら、それがそのまま設計書およびその履歴になってほしい。そのためにはIT知識の比較的少ないクライアントでも直観的に分かるような表現とそれを管理するツールが必要です。
全くご説ごもっともです。 問題は、・何年経っても、何も出てこない。点です。多分、何も降って来やしないんだろうと想像出来ます。 必要なのは、理解しますが、無い素晴らしいものを誉めるだけで、立場を得られるのは、困難です。
>Excel設計書の欠点は「汎用」の「ファイル」であるということです。>設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。 データなのは確かかも知れませんが、・設計時はまだいろいろな事が固まっていない・だから、スキーマに相当するものを頻繁に変更する。一人の人が一時間に10回変えるかも知れない・そのデータベースを10人でいじっていたら、一回の変更の作業時間は0.6分しか取れない・だからと言って、NoSQLが良いかというと、IDとTEXTのデータにしかならず、・ファイルで担保されていた「ファイル内」という一とまとまりさが失われる。なので、ファイルで良いと思います。 >専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのかそれはスキーマに相当するものを頻繁に変更する事が無い場合に限られると思います。設計の「がちゃがちゃさ」をあまりに少なく評価しています。 >設計書に変更が入れば自動的に変更履歴を書き出してくれるプログラムならレッドマインでも使えば良いでしょうけれど、それはプログラム言語というのが、「スキーマに相当するものがかなり固定」で有る為です。 あなたは設計書の話をしていないと思います。
スキーマレスデータベースというのがあるんですよ。流行ったのはNoSQLの前ですね。NoSQLは分散データベース関連なので。親コメで書いたように、スキーマの変更はスキーマの変更として履歴に残すべきです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
Excel文書がなぜ駄目なのか (スコア:0)
高速開発ツールなどが流行りだした頃の話なので、Excel以下の設計書は無視してくださいね。
そのレベルならどの文書作成ツールでも変わらないので。もちろんExcel方眼紙に代表されるよう、Excelは文書作成ツールとしても優秀なのですが。
Excel設計書の欠点は「汎用」の「ファイル」であるということです。
設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。
ただし面倒なので、専用のツールがあればそれを利用するのが望ましい。
ファイルの何が駄目かというと、よくある間違ったバージョン管理のように、
どのファイルが最新なのか、どのファイルを正とするのかわかりにくいということがあります。
顧客への提出前に最終チェックしてたら漏れに気づいて修正したけど元ファイルに反映されていなかったとか。
次に汎用の何が駄目かというと、何を変更したのか分かりづらいということが挙げられます。
設計書の項目を増やしたこと、値を増やしたこと、値を変更したこと、
すべてExcelにとっては等価でありすべて同様の変更履歴となります。
専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになります。
できれば設計書に変更が入れば自動的に変更履歴を書き出してくれるところまでして欲しいですね。
最初に戻って高速開発ツールの話になりますが、最終的にはシステムと統合されて
システムで設計変更すると設計書とプログラムテンプレートに反映されるという触れ込みでした。
ERツール推しの人もおそらくその流れでの発言でしょう。
もちろん現在でもそこまでは実現されていないはずです。一部は実現できているのですが。
ただ上述したようにExcelでの欠点は分かっている上に、その欠点がモダンなプログラマと相性が悪いのも間違いありません。
たしかにEXCELで設計書を書いて悪いはずが有りません。
ただしそれはフルスクラッチでシステムを書いて悪いはずがありません。とかドット絵でゲームを作って悪いはずがありません。などと同じレベルの発言です。
フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったように、3Dゲーム全盛時に暗黒時代を迎えたように、近い将来競合他社に手も足も出なくなるでしょう。
少なくともExcel設計書に満足せず工夫し、設計書作成業界をキャッチアップし続ける必要はあります。
Re:Excel文書がなぜ駄目なのか (スコア:1)
>設計変更でどこに修正が入りどのような影響があったのかということを記録できるようになります
EXCELで同じことをするのは大変ですが、
それより楽にできるのでしょうか? gitなんかでも、変更毎に全体をzipで固めて記録する
だけで、影響があったかどうかは、人間が解釈します。
記録出来るようになります言いますが、どんなキャッチアップすべき進歩なのでしょうか?
何も、具体的にはおっしゃっていない様で、参考にならないです。
EXCELでない何があるのでしょうか?
また、フレームワークやミドルウェアを駆使したシステムに太刀打ちできなくなったシステム
と言うのは、単なるわら人形です。そんなものは過去に存在しません。
Re: (スコア:0)
現在は自社独自でシステム開発するよりはパッケージ導入の方がメインですよ?
日経BPでもSIerに開発能力がなくなり御用聞きに成り下がってるだのSIer不要論が出ているとまで嘆かれてます。少々文脈が異なりますが。
とりあえず現在のところ実現されているのは高速開発ツールやBPMなどですね。
少なくともどの設計変更が何のために行われたのかは記録できます。
そのことによって、その設計変更の元がキャンセルになったときにどこをロールバックすればいいのか分かります。
あるいは追加で設計変更するときにどこまで影響があるのか把握できたりもします。
単に記録するだけならExcelだけでもいいですよ。そう言ってるじゃないですか。
その記録をどのように生かすかという観点がこれからの(大規模)システム開発には必要なんです。
Re:Excel文書がなぜ駄目なのか (スコア:1)
高速ツールは、コードが無いのにどう、履歴を自動で得るのか?
その点では、退歩になっていないでしょうか?
やって無いので確かなことは知りませが。。。
パッケージだって同じ方向性です。
パッケージのせいで、システム全体を自動で俯瞰し難くなる
(機能間は使用者が、「見立て」でカバーしている)
ので、その見立てを自動で得るのは、ソースを全体見られた頃
より困難で、
・何年経っても、何も出てこない
のは、現状認識としては、#4011219さんも肯定すると
思います。
Re:Excel文書がなぜ駄目なのか (スコア:1)
・モダンなものが有るはずで、今のものは劣っている。
・何年経っても、何も出てこない。
・現実、今のものが比較的にベターだ。
というのをここでは、解呪と言っています。
更に、xが最後に付いたEXCELデータは、拡張子を.zipに変えて
解凍すれば、
いくつかの.xmlファイルになり、シート名と.xmlファイル名の
対応.xmlファイルから追っていくと、セルとかが、エレメントに
なっており、プレーンなテキストファイルより、
有利な場合すら有ります。
ただそれでも、その有利さは「たいしたこと無い」(少し変更内容が
多いだけで、変更箇所の判定が「文書の大部分」になってしまい、
自動の解析として、意味を成さなくなる。)ことが検証されているので、
誰も口にしないたけです。
ご指摘のより良い、学ぶべきものとは、具体的には何でしょうか?
Re: (スコア:0)
如何に手を抜くか。プログラマの命題でもありますね。
現在の状況を簡単に言えば、ドキュメントなんて別個に起こしたくないということです。
設計変更の打ち合わせをしたら、それがそのまま設計書およびその履歴になってほしい。
そのためにはIT知識の比較的少ないクライアントでも直観的に分かるような表現とそれを管理するツールが必要です。
Re:Excel文書がなぜ駄目なのか (スコア:1)
全くご説ごもっともです。
問題は、
・何年経っても、何も出てこない。
点です。多分、何も降って来やしないんだろうと想像出来ます。
必要なのは、理解しますが、
無い素晴らしいものを誉めるだけで、立場を得られる
のは、困難です。
本当でしょうか? (スコア:1)
>Excel設計書の欠点は「汎用」の「ファイル」であるということです。
>設計とはデータなので、専用のデータベースとクライアントを利用するのが正しい。
データなのは確かかも知れませんが、
・設計時はまだいろいろな事が固まっていない
・だから、スキーマに相当するものを頻繁に変更する。一人の人が一時間に10回変えるかも知れない
・そのデータベースを10人でいじっていたら、一回の変更の作業時間は0.6分しか取れない
・だからと言って、NoSQLが良いかというと、IDとTEXTのデータにしかならず、
・ファイルで担保されていた「ファイル内」という一とまとまりさが失われる。
なので、ファイルで良いと思います。
>専用ツールなどを使えば、このときの設計変更でどこに修正が入りどのような影響があったのか
それはスキーマに相当するものを頻繁に変更する事が無い場合に限られると思います。
設計の「がちゃがちゃさ」をあまりに少なく評価しています。
>設計書に変更が入れば自動的に変更履歴を書き出してくれる
プログラムならレッドマインでも使えば良いでしょうけれど、それはプログラム言語という
のが、「スキーマに相当するものがかなり固定」で有る為です。
あなたは設計書の話をしていないと思います。
Re: (スコア:0)
スキーマレスデータベースというのがあるんですよ。
流行ったのはNoSQLの前ですね。NoSQLは分散データベース関連なので。
親コメで書いたように、スキーマの変更はスキーマの変更として履歴に残すべきです。