アカウント名:
パスワード:
＞何十もある小さなセルにコードが隠れているため、もし慎重にコードを査読
単純な計算だけなら追うのも楽なんだけど、一つのセルの中にif()関数を入れ子にして、さらに別のシートを表引きしたりするものになると、見るのもイヤになる。 単純な計算ならシートの機能だけで作ればいいけど、複雑な条件判断が絡んでくるならマクロを使うべきだし、表引きだとかが絡んでくるならデータベースで作った方が構造がスッキリしてわかりやすくなるんだけど。 で、そういうのを作ってる人に言わせると、Excelなら誰でもいじれてメンテナンスできるとのこと。 私は絶対手をつけないな。というより怖くてできない。 あと、表計算ソフトって、セルの保護機能が弱いから、うっかりデータを書き換えても気がつかないのが怖い。 よく、表計算ソフトを使って集計しているのに、電卓で検算していると揶揄されているけど、表計算ソフトの融通無碍な操作性が、データの完全性に不安感を引き起こしているのが原因だと思う。 私の場合、表計算ソフトを使うのは、単純な表か、データ処理の最終段階で見栄えを整えるくらいにしている。データ処理自体は、ここ十年ほどはAccessで行ってる。リアルタイムで計算結果を表示するような使い方で無いなら、データベースのほうが業務には使いやすいと思うな。
普通の事務員こそ、データベースの使い方を覚えるべきだよ。
えっと、私自身は今はExcelのワークシート関数積極的利用派です。
マクロウィルスが流行ったせいで、今時のExcelはマクロを自動実行させない設定なのが普通でしょう。「このファイルはマクロを動かしても大丈夫かどうか」を一体どうやって確認するのか、そういう点で、私は「ワークシート関数で実現出来る処理には、マクロは使うべきではない」と思ってます。今はもう、積極的にできるだけマクロは使わないようにしています。
> 表計算ソフトって、セルの保護機能が弱いから、うっかりデータを書き換えても気がつかないのが怖い。
それは制作者がちゃんと保護設定してないだけ。Excelにはそれなりな保護機能があります。必要最小限の「手入力するセル」だけ変更可能にして、残りのセルは全て変更不可にすれば、「うっかりデータを書き換え」るなんてことはありません。
Excelの保護設定での最大の問題は、保護されていないセルに対して、「カットアンドペースト」すると、そのセルに対する参照まで移動してしまうこと。(例えば、保護されていないセルA1とB1があった場合、A1もB1も書き換え可能なので、A1をカットしてB1にペーストなんてこともできます。ですが、それをやっちゃうと、別のセルがA1を参照していた場合、たとえ保護していたセルであっても、カットアンドペーストに追従してB1への参照に書き換わってしまうし、B1への参照があったとしたら、参照先が消失したので#REFになっちゃう)これについては、ちょっと泥臭いですが、INDIRECT とか OFFSET とかを使って解消可能です。
まあ、そうやって安全なシートを作ってると、どんどんコードとしての可読性は悪くなっていきますし、コードの一覧表示が出来ないから保守性が悪いという点についてはもう確かにその通りなのですが、とりあえず、セル内のコード記述レベルでは、改行を多用しインデントすることで、できるだけ可読性を高めるようにしています。例えば
=IF( LEFT( OFFSET($H2, 0, -3), LEN(N$1 & "→") ) = N$1 & "→", -OFFSET($H2, 0, -2), 0 )+IF( RIGHT( OFFSET($H2, 0, -3), LEN("→" & N$1) ) = "→" & N$1, OFFSET($H2, 0, -2), 0 )
って感じ。これを全部一行にまとめて
=IF(LEFT(OFFSET($H2,0,-3),LEN(N$1&"→"))=N$1&"→",OFFSET($H2,0,-2),0)+IF(RIGHT(OFFSET($H2,0,-3),LEN("→"&N$1))="→"&N$1,-OFFSET($H2,0,-2),0)
って書くより格段に読みやすいと思います。#これは、「A→B 100」って入力があったら、Aを-100、Bを+100するための処理の一部。#OFFSET($H2,0,-3)・OFFSET($H2,0,-2)は、E2・F2への参照です。E2・F2は保護されていないセルなので、上述のカットアンドペースト問題から守るため、「H2の3つ左」「H2の2つ左」という指定にしてます。
マクロが安全かどうかは普通に証明書をすればよいのでは。特定の人だけに配るなら自己署名で問題ないし。
ああ、そうか。改行してしまえばいいのか。今初めて知りました。実際長い関数処理は可読性が最悪ですがこれでだいぶマシになりますね
私も半年くらい前に改行すれば読みやすいことに気がついて実践してます。でも、「そのままコピーしてもエラーしか出ないぞ」と言われた。orz
「関数は一行に戻して入力してください。実は改行にも目に見えない文字が使われているのです。」という一文を付け加えてます。
確かに，データベースでロジックは済ませといた方が楽ですね。
FileMakerなら，Excel並みの手軽さだと思う（Accessほどの自由度はないが）ので，もう少しその手の分野にも使われてよいと思うのだが，Excel代わりに使うには高いんだよなあ。
if()関数の長大な入れ子を一つ作れば、あとのセルにコピペで済ませられるのが表計算ソフトの良いところ。ただ、そのコピペが何かの拍子に間違っていることがあるんだよな。Errorが表示されてれば発覚しやすいけど、たまたま計算できてもっともらしい数値を表示してると気付かない。
Accessは個人的には好きだけど、引き継ぎが大変なのであまり使えません。Excelバリバリ使う人でも一歩引いてる感じ。Excelをそれなりに使えている人は尻込みして仕事を引き継いでくれません。Accessで作った簡単な表を引き継いでもらって、何年かして戻ってみたらExcelのフィルター機能使いまくった凄いものに改造されてた。。。
関数ダイアログを使えば計算経過を確認できるんで、Debugによく使うんだけど、関数をネストすると関数ダイアログは途端に使いにくくなるんだよなぁ。
Excelの場合、手元にある手書きの表かなんかにあわせて見た目を作ってから、プログラム的な動作を作り込むことが比較的容易なので、初心者も手軽に気軽に使える。 一方、Accessの場合、最初に対象業務で必要なデータ項目を考えて、データ構造を設計しないと、実用的に使えないあたりが敷居の高さにつながってる気がしますね。 けど、対象業務を適切に分析してデータ構造を設計すれば、データ再利用もしやすいし、変更もしやすくなるんだけどね。 このプロセスを必要以上に難しく考えてしまってるんだよな。 その業務で必要なデータが何かと、データ同士がどのように関連しているか、を理解できて、 データベース設計の基本を理解すれば、それほど難しくは無いんだけど。
引き継ぎが難しいのは同意です。 まずAccessを使おうという人自体が少ないので。 データ共有の手段として、AccessやSQL Server（のようなRDBサーバー）を活用できれば、かなり業務効率が上がる組織も多いはずです。
「メンテナンス性がおちるから、コードをコピペするなとあれほどｗ」
というのが、スプレッドシートでコードを書く時の問題の一つだと思う。
VBAを使えばいいのでは？
>で、そういうのを作ってる人に言わせると、Excelなら誰でもいじれてメンテナンスできるとのこと。ではあなたが今後やってくださいと言うと、まずやりたがる事はないという。#もしかしたら、逆に自分しかメンテできないようにしているのかもしれないけど。
そもそも誰でもいじれてメンテナンスできる（と言いはる）ものにするという事は当人はやりたくないという事が多い。
全ての使っているセルのフォーミュラをダンプする（条件付き書式とか、名前とかも）ツールを作ればいいだけでは無いですかね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
全く同意 (スコア:4, 興味深い)
＞何十もある小さなセルにコードが隠れているため、もし慎重にコードを査読
単純な計算だけなら追うのも楽なんだけど、一つのセルの中にif()関数を入れ子にして、さらに別のシートを表引きしたりするものになると、見るのもイヤになる。
単純な計算ならシートの機能だけで作ればいいけど、複雑な条件判断が絡んでくるならマクロを使うべきだし、表引きだとかが絡んでくるならデータベースで作った方が構造がスッキリしてわかりやすくなるんだけど。
で、そういうのを作ってる人に言わせると、Excelなら誰でもいじれてメンテナンスできるとのこと。
私は絶対手をつけないな。というより怖くてできない。
あと、表計算ソフトって、セルの保護機能が弱いから、うっかりデータを書き換えても気がつかないのが怖い。
よく、表計算ソフトを使って集計しているのに、電卓で検算していると揶揄されているけど、表計算ソフトの融通無碍な操作性が、データの完全性に不安感を引き起こしているのが原因だと思う。
私の場合、表計算ソフトを使うのは、単純な表か、データ処理の最終段階で見栄えを整えるくらいにしている。データ処理自体は、ここ十年ほどはAccessで行ってる。リアルタイムで計算結果を表示するような使い方で無いなら、データベースのほうが業務には使いやすいと思うな。
普通の事務員こそ、データベースの使い方を覚えるべきだよ。
Re:全く同意 (スコア:4, 参考になる)
えっと、私自身は今はExcelのワークシート関数積極的利用派です。
マクロウィルスが流行ったせいで、今時のExcelはマクロを自動実行させない設定なのが普通でしょう。「このファイルはマクロを動かしても大丈夫かどうか」を一体どうやって確認するのか、そういう点で、私は「ワークシート関数で実現出来る処理には、マクロは使うべきではない」と思ってます。今はもう、積極的にできるだけマクロは使わないようにしています。
> 表計算ソフトって、セルの保護機能が弱いから、うっかりデータを書き換えても気がつかないのが怖い。
それは制作者がちゃんと保護設定してないだけ。Excelにはそれなりな保護機能があります。必要最小限の「手入力するセル」だけ変更可能にして、残りのセルは全て変更不可にすれば、「うっかりデータを書き換え」るなんてことはありません。
Excelの保護設定での最大の問題は、保護されていないセルに対して、「カットアンドペースト」すると、そのセルに対する参照まで移動してしまうこと。
(例えば、保護されていないセルA1とB1があった場合、A1もB1も書き換え可能なので、A1をカットしてB1にペーストなんてこともできます。ですが、それをやっちゃうと、別のセルがA1を参照していた場合、たとえ保護していたセルであっても、カットアンドペーストに追従してB1への参照に書き換わってしまうし、B1への参照があったとしたら、参照先が消失したので#REFになっちゃう)
これについては、ちょっと泥臭いですが、INDIRECT とか OFFSET とかを使って解消可能です。
まあ、そうやって安全なシートを作ってると、どんどんコードとしての可読性は悪くなっていきますし、コードの一覧表示が出来ないから保守性が悪いという点についてはもう確かにその通りなのですが、
とりあえず、セル内のコード記述レベルでは、改行を多用しインデントすることで、できるだけ可読性を高めるようにしています。例えば
って感じ。
これを全部一行にまとめて
って書くより格段に読みやすいと思います。
#これは、「A→B 100」って入力があったら、Aを-100、Bを+100するための処理の一部。
#OFFSET($H2,0,-3)・OFFSET($H2,0,-2)は、E2・F2への参照です。E2・F2は保護されていないセルなので、上述のカットアンドペースト問題から守るため、「H2の3つ左」「H2の2つ左」という指定にしてます。
Re: (スコア:0)
マクロが安全かどうかは普通に証明書をすればよいのでは。
特定の人だけに配るなら自己署名で問題ないし。
Re: (スコア:0)
ああ、そうか。改行してしまえばいいのか。今初めて知りました。
実際長い関数処理は可読性が最悪ですがこれでだいぶマシになりますね
Re: (スコア:0)
私も半年くらい前に改行すれば読みやすいことに気がついて実践してます。
でも、「そのままコピーしてもエラーしか出ないぞ」と言われた。orz
「関数は一行に戻して入力してください。実は改行にも目に見えない文字が使われているのです。」
という一文を付け加えてます。
そんなときこそFileMaker (スコア:3)
確かに，データベースでロジックは済ませといた方が楽ですね。
FileMakerなら，Excel並みの手軽さだと思う（Accessほどの自由度はないが）ので，
もう少しその手の分野にも使われてよいと思うのだが，Excel代わりに使うには高いんだよなあ。
Re:全く同意 (スコア:1)
if()関数の長大な入れ子を一つ作れば、あとのセルにコピペで済ませられるのが表計算ソフトの良いところ。
ただ、そのコピペが何かの拍子に間違っていることがあるんだよな。
Errorが表示されてれば発覚しやすいけど、たまたま計算できてもっともらしい数値を表示してると気付かない。
Accessは個人的には好きだけど、引き継ぎが大変なのであまり使えません。
Excelバリバリ使う人でも一歩引いてる感じ。
Excelをそれなりに使えている人は尻込みして仕事を引き継いでくれません。
Accessで作った簡単な表を引き継いでもらって、何年かして戻ってみたらExcelのフィルター機能使いまくった凄いものに改造されてた。。。
Re:全く同意 (スコア:2)
関数ダイアログを使えば計算経過を確認できるんで、Debugによく使うんだけど、
関数をネストすると関数ダイアログは途端に使いにくくなるんだよなぁ。
データベースの敷居の高さ (スコア:1)
Excelの場合、手元にある手書きの表かなんかにあわせて見た目を作ってから、プログラム的な動作を作り込むことが比較的容易なので、初心者も手軽に気軽に使える。
一方、Accessの場合、最初に対象業務で必要なデータ項目を考えて、データ構造を設計しないと、実用的に使えないあたりが敷居の高さにつながってる気がしますね。
けど、対象業務を適切に分析してデータ構造を設計すれば、データ再利用もしやすいし、変更もしやすくなるんだけどね。
このプロセスを必要以上に難しく考えてしまってるんだよな。
その業務で必要なデータが何かと、データ同士がどのように関連しているか、を理解できて、 データベース設計の基本を理解すれば、それほど難しくは無いんだけど。
引き継ぎが難しいのは同意です。
まずAccessを使おうという人自体が少ないので。
データ共有の手段として、AccessやSQL Server（のようなRDBサーバー）を活用できれば、かなり業務効率が上がる組織も多いはずです。
Don't repeat yourself (スコア:1)
「メンテナンス性がおちるから、コードをコピペするなとあれほどｗ」
というのが、スプレッドシートでコードを書く時の問題の一つだと思う。
Re: (スコア:0)
VBAを使えばいいのでは？
Re: (スコア:0)
>で、そういうのを作ってる人に言わせると、Excelなら誰でもいじれてメンテナンスできるとのこと。
ではあなたが今後やってくださいと言うと、まずやりたがる事はないという。
#もしかしたら、逆に自分しかメンテできないようにしているのかもしれないけど。
そもそも誰でもいじれてメンテナンスできる（と言いはる）ものにするという事は当人はやりたくないという事が多い。
Re: (スコア:0)
全ての使っているセルのフォーミュラをダンプする（条件付き書式とか、名前とかも）
ツールを作ればいいだけでは無いですかね。