Greenroom?

ぇっと、一応念のために書いといた方がいいのかな。

●qa7668352　：(2)
http://abyssinia.bbs.fc2.com/?act=reply&tid=2800138#14506621

で奨めてる(?)

■やさしくわかるExcel VBAプログラミング 第4版
http://www.amazon.co.jp/dp/4797364351

レビュ見るとあんま評判良くないですね。

手元にある版(『改訂版』2005年6月10日　初版第５刷)は
（わたし基準では）良書だと思うんですけどね。

まぁ、新しい版は見てないので、どんなふうになってることやら…。
ハズレだったらスミマセン。

　#　つか、VBA歴７年でこのレベルなのか、わたし　o....rz
　#　まぁ、ブランクの方が長いんだけどね。
　#　今んとこ、回答か実験でもなきゃコード書く機会ないし。

　#　あ、よく見るとコレ、版元SBP(現SBC)だ。
　#　こりゃ内容はともかくtypoは覚悟しないと…(^^;;;;;;;
　#　わたしが持ってる版はtypoあんま見かけないけどね。第５刷だし。

ちなみに目次はこんな感じ

------------------------------------------------
CHAPTER01　マクロの基礎
　01　ExcelVBAの基礎知識
　　STEP01　マクロとは、VBAとは
　　STEP02　恐怖のマクロウイルス #　(ワライ
　：
　05　エラー発生!!　Excelに怒られてしまったら
　　STEP01　Excelに真っ赤になって怒られてみる
　　：
　　STEP03　Excelに黄色になって怒られてみる(実行時エラー)
CHAPTER02　関数と変数　　　　　　#　←この辺で出てくるトコがpoint
CHAPTER03　オブジェクトの基本
CHAPTER04　条件分岐
CHAPTER05　イベントプロシージャ
CHAPTER06　繰り返し操作
CHAPTER07　マクロの記録　　　　　#　←この辺で出てくるトコがpoint
CHAPTER08　文字列と日付関数
CHAPTER09　自作関数
CHAPTER10　変数の型宣言と配列　　#　←この辺で出てくるトコがpoint
CHAPTER11　プロシージャとオブジェクト
CHAPTER12　ユーザーフォーム
CHAPTER13　セル操作の詳細　　　　#　←この辺で出てくるトコがpoint
CHAPTER14　ファイル操作
CHAPTER15　応用：帳票・出張管理システム
------------------------------------------------

見ての通り、
理学部や工学部のテキストみたいな肩肘張った内容ではないです。
プログラミングで食べていきたい人には向きません。

見ての通り、
そのままコピペして今日からすぐに使える、みたいな内容でもないです。
目の前の課題を今日中に片付けたい人には向きません。

------------------

でも

□01.　シンタックスエラー／コンパイルエラー／実行時エラーの区別がつく
□02.　関数や変数扱える
□03.　オブジェクト／コレクションとプロパティ／メソッドの区別がつく
□04.　分岐処理できる
□05.　イベントドリブンマクロ書ける
□06.　ループ処理できる
□07.　マクロ記録を使ってオブジェクトやメソッドを調べられる
□08.　文字列操作やシリアル値の処理ができる
□09.　Functionプロシージャ書ける
□10.　データ型を理解している／配列を扱える
□11.　スコープを理解している／複数のSubやFunctionを扱える
□12.　ユーザフォーム作れる
□13.　Rangeオブジェクトを自由に扱える
□14.　ファイルやフォルダを扱える
□15.　実務でVBAを運用する上で留意すべき点を理解している

もし全部チェックついたら
(VBAまわりでは)ふつー「初心者」とは呼びません。

　#　2400の『極意』のうち2397を丸暗記しても
　#　コレクション回せなかったら「初心者」だけどね。

これくらいの「基礎」ができてれば
たいていのことは自力でなんとかなりますし
逆引きや切り貼りでやるにしても基本的なところで躓いたりしませんし
質問するにしても、断然ハナシが早くなります。

　#　本サイトの質問者さんは、たいてい最初のチェックつかないよね。

------------------

「素人」なら「素人」のままでもいいと思うんですよね。
「逆引き」や「質問」で間に合うならそれでいいんです。

　#　わたしも「素人」だし。
　#　今更CやJava書けるようになってもあんま嬉しくないし。喰えないし。
　#　…読めたらちょっと嬉しいな、とは思うけど。

でも「初心者」なら、
早めに「初心者」卒業した方が、本人も周りも助かる…みたいな。

以上、「アドバイス」でした。長乱文陳謝。

例えば、参考画像のような「九九の表」を作るときどうする？　ってハナシ。

======================

「わかりました！　複合参照ですね！　
　C3セルを
　　=$B3*C$2
　として右方・下方にフィルすればバッチリです！」

うん、まぁ、そうなんだけど
それじゃぁ【　面白くもなんともない　】よね(笑

======================

「イルカは配列厨だから
　C3:K11を選択して
　　=B3:B11*C2:K2
　をCtrl+Shift+Enterで確定した方が「堅牢」、とか言うつもりだろ」

そだね。
配列数式にしてセル範囲にまとめて返しちゃえば
行や列を入れたり抜いたりできなくなるから
ちょっとやそっとのことでは壊れなくなるよね。

でも、今回は「参照」のハナシで「堅牢性」のハナシじゃないの。

======================

　C3セルを　

　　=$B:$B*$2:$2

　として右方・下方にフィル

ってどうよ？　ってハナシ。

配列数式じゃないよ、普通の数式。「共通部分参照」ってやつね。

「　【自行B列】　の値と　【自列第2行】　の値を掛ける」
…すこぶる明示的じゃない？

[名前]の[定義]で
　$B$3:$B$11：被乗数
　$C$2:$K$2：乗数
みたいに[名前]をつけておけば
　=被乗数*乗数
みたいな書き方もできる。

算術演算だけでなくて
　=VLOOKUP(B:B,Sheet2!$B$2:$F$99,2,0)
　=INT(B:B)
みたいな使い方もできる。

くどいけど、配列数式じゃないよ、普通の数式。

======================

共通部分参照の利点は

●【明示性】が高い

例えば

　=MATCH(B3,$F$3:$F$12,0)

とする代わりに

　=MATCH(B:B,$F$3:$F$12,0)

のように書いた場合
　「$F$3:$F$12から【自行B列の値】を探す」
ってことで、自行の番号「3」という余計な情報がない分【端的】…だと思うのよね。

●どの行でも【同じ表示】になる

例えば
　C3セル：　=MATCH(B3,$F$3:$F$12,0)
　C4セル：　=MATCH(B4,$F$3:$F$12,0)
は、R1C1形式で表示すれば、どちらも
　=MATCH(RC[-1],R3C6:R12C6,0)
であって、内部処理的には同一の数式だけど
A1形式で表示する場合には【自セルの位置によって】表示が異なるよね。

当たり前っちゃぁ当たり前なんだけど
【同じ数式なのに、セルによって表示が異なる】
って、よく考えると気持ち悪いよね。

共通部分参照を使えば、
　=MATCH(B:B,$F$3:$F$12,0)
と【自セルの位置に関わらず同じ表示】になる。

●入力セルの行位置を気にしなくてよい

例えば
質問文で表位置が明示されていない場合
「第２行が見出行で、３行目以下にデータが入っているとします」
みたいに、回答者側でキメウチしなきゃならないよね。

あるいは
回答者が参照する行を間違えたとか、
質問者が入力する行を間違えたとか、
そういう理由で「うまくいきません」ってなるケースも多いよね。

その点、共通部分参照であれば
【どの行に入力する式も同じ】なんだから
「C列のセルを　=MATCH(B:B,$F$3:$F$12,0)　として下方にフィル」
で確実に片付く。

●セル抜き・セル入れ・セルの入替に強い

「堅牢性」のハナシ。

共通部分参照であれば【どの行に入力されている式も同じ】なので
セルを抜いたり、入れたり、入れ替えたりしても参照がズレたりしない。

======================

なんで流行らないんだろうな…。

いや、「なんで」かはわかります…(^^

●０：「！？」ってなる

まぁ、あまり見かけないからね。

●１：「間違ってる」と言われる

「たまたまうまくいってるだけで、そういう参照の仕方は誤りです！」とか怒られる。

いや、そういう機能なんだけどな。

●２：「やめた方がいい」と言われる

「そのような参照の仕方はやめた方がいいです！」とか説教される。

理由を…。

●３：配列数式と間違われる

「#1さんの数式は、Ctrl+Shift+Enter　で入力する必要があります。」とか【勝手に誤解説】される。

いや、配列数式じゃなくて普通の数式だって。

●４：マジメなハナシ。

共通部分参照の唯一(?)にして最大の欠点は…

　関数の引数が元来「単一の値」なのか「配列」なのかを意識する必要がある

ってことね。

例えば
「自行A列の値と自行B列の値を加える」という場合

　=A:A+B:B

は通るけど

　=SUM(A:A,B:B)
とか
　=SUM(A:B)

は（そういう意味では）通らない…当たり前だけど。
SUMの引数は元来配列だから、共通部分参照は機能しない。

引数のタイプに応じて参照を使い分けるのもそれほど難しいことではないけど
「ハイレツってなに？　だっちゅーの？」（ふるっ
みたいなユーザに【混乱を招く】ってことなのかな。

回答では使ったことないけど、手元では結構やってたり(ぇ
便利なんだけどな、ホント。

田中教徒が三言目には口にする「保守性」、ナニソレ、楽しいの？

=================================

【　そもそも数式における「保守性」ってなによ？　】

●「理解しやすいってことです！」

現在機能している数式を何のために「理解する」必要があるの？

●「何かの拍子に壊れちゃったとき、修正しやすいってことです!!」

「何かの拍子に壊れちゃう」ような数式って
「保守性」以前に「堅牢性」の点で問題があるのでは？

　■「堅牢性」を騙る(数式篇)
　http://abyssinia.bbs.fc2.com/?act=reply&tid=2807968#5249503

　■脆弱な連番vs堅牢な連番（動画）
　http://video.fc2.com/content.php?kobj_up_id=20100503AuHRwXxC


「壊れたときのこと」のことを考えるよりも
「壊れないこと」を考える方が先では？

●「掛率とか割引額とかが変更されたときに対応しやすいってことです!!!」

そういう「動く要素」を数式に埋め込んでる時点でマズいのでは？

そういう「動く要素」は、セルにあらかじめ書き出して
直接数式いじらなくても変更できるようにしとくべきでは？

●「動く要素」の数自体が変われば数式の構造を変えないと駄目でしょ!!!!

もし
　=IF(A2>=B2,"A",IF(A2>=B3,"B",IF(A2>=B4,"C","D")))
を
　=IF(A2>=B2,"A",IF(A2>=B3,"B",IF(A2>=B4,"C",IF(A2>=B5,"D","E"))))
に変えなくちゃならないって種類のことなら…

　つ　VLOOKUP

まぁ、↑の例は極端だけど、「動く要素の数自体が変わる」ってことについて
事前に対応することは可能だよね、大抵の場合。

●表の行数や列数が変わることだってあるでしょ!!!!!

それも事前に対応できるよね、大抵の場合。

●シートのレイアウトが変わることだって…!!!!!!

つ　[名前]

=================================

数式における「保守性」とは…

　【　保守が要らないってこと　】

=================================

●そんなの理想論です!!!11!!!1!

ん～っと、そういうハナシではなくてね。

・「判りにくくて壊れにくい数式」と「判りやすくて壊れやすい数式」
・「可読性」と「堅牢性」
どちらを志向するかってハナシ。
「可読性」と「堅牢性」ってトレードオフだから、大抵の場合。

「保守性」⇒「可読性」派
・毎年、年度初めに"判りやすい"数式をガチャガチャいじくりまわす

「保守性」⇒「堅牢性」派
・最初にリソース投入して堅牢な数式をガッチリ作ってそのまま使う

どちらがいいかってこと。

●田中先生は「判りやすい数式」＝「良い数式」っておっしゃってます!!1!11!!!1!

そりゃそうだよ。田中先生は「教える人」だもの。

「判りやすくて壊れやすい」数式
　↓
「保守」という作業が発生
　↓
Excel勉強しないとイケナイ人がいっぱい

「保守が不要なほど堅牢な」数式
　↓
「保守」という作業がない
　↓
Excel勉強しないとイケナイ人が減っちゃう

この世界はね
中途半端なスキルのユーザが、「判りやすくて壊れやすい」数式を、日がな一日
作っちゃ壊し、作っちゃ壊し、作っちゃ壊しするマッチポンプで成り立ってるの。

「壊れない数式」とか言い出したら
数式を作る人も、数式の作り方教える人も仕事なくなっちゃうw

いや、この節はまぁ、【冗談】です、一応ｗ

いわゆるひとつの「演算誤差」について。

正確に言うと
「IEEE 754 浮動小数点数の演算において発生する誤差」
…でいいのかな？　ごめん、よくわかりません(ぉ

もっと正確に言うと
「IEEE 754 浮動小数点数の演算において発生する誤差を、
　Excelが場当たり的に補正するので挙動が読めない件」

■エクセル「演算誤差」対策講座
http://pc.nikkeibp.co.jp/pc21/special/gosa/

「演算誤差に関する質問」があると、
待ってましたとばかりに「そんなことも知らねーの？」的な回答がつくので、
演算誤差自体については皆さんご存知なわけですよね、もちろん。

その割に、
「演算誤差を考慮した数式」を見かけないのはなんでかなぁーっと、
私なんかは思っちゃうんですが…いや「なんで」かはわかります(^^;;;

==================================================

●時間・時刻

【皆さんご承知の通り】
シリアル値で入ってる時間や時刻は小数点数ですから
算術演算すると演算誤差が発生する可能性があります。

【皆さんご承知の通り】
シリアル値で入ってる時間や時刻は小数点数ですから
算術演算の結果、演算誤差が発生している可能性があります。

【皆さんご承知の通り】
シリアル値についてはExcelが演算誤差を補正しますが
この補正は場当たり的なもので信頼できません。

【皆さんご承知の通り】
演算誤差が発生している時間や時刻について
一致／大小判定を行なうと、意図した結果が得られない可能性があります。

で、そういうことを皆さんよっくご承知のハズなのに、
なんで
・誤差があるかも知れない値をそのまま使って判定するんですか？
・誤差が出たかも知れない値をそのまま返すんですか？
…いや「なんで」かはわかります(^^;;;

私が時刻や時間が絡んだ質問を原則スルーするのは
「演算誤差を考慮した数式」では
「演算誤差を考慮しない"すまーと"な数式」に対抗できないからです。

時刻や時間の処理が苦手だからぢゃありません。

といいつつ、私も思いっきりしくじってたり(ぉぃ
■関数教えて！
http://bekkoame.okwave.jp/qa5101819.html

==================================================

●種類のカウント

個数の逆数を足し上げて種類をカウントする数式がありますよね。

　=SUMPRODUCT(1/COUNTIF($A$1:$A$99,$A$1:$A$99))

みたいな。

　　　----------------------------------
　　　ちょっと実験。

　　　１．A1:A27に　"TEST"　と入力する

　　　２．B1　を　=SUMPRODUCT(1/COUNTIF(A1:A27,A1:A27))　とする

　　　とーぜんB1セルには　1　が返りますよね。

　　　３．B2　を　=B1=1 とする

　　　あれ？
　　　----------------------------------

「逆数を足し上げてる」時点で胡散臭いと思わなくちゃいけませんよね。

考えてみれば当たり前のことなのに
この種の数式を丸めてから返す人がいないのはなんででしょうね？
…いや「なんで」かはわかります(^^;;;

といいつつ、私もしくじってたり(コラ
■指定の範囲から値を抽出整理整頓して表示する関数。
http://bekkoame.okwave.jp/qa5104727.html

「エラー処理」の部分で種類をカウントしてるんですが
演算誤差の丸めを忘れてるのでエラーが見えちゃうことがあります。

もっとも
このケース(規模)では誤差が顕在化することはありませんし
たまたま安全側に倒れるようなので被害は出ないハズですが…。

==================================================

ちなみに私、

　=INDEX(C:C,1/LARGE(INDEX((A$4:A$99="○")/ROW(A$4:A$99),),ROW()-ROW(E$3)))

みたいな数式をよく書きますが、
「逆数の逆数」をINDEXの第2，第3引数とした場合
演算誤差が補正されて整数として処理されるのは確認済みです。

でも
　ROW()+1/COLUMN()　
みたいな感じで単一数値アドレスを取り回すときは
整数部分(行番号)の桁数だけ小数部分(列番号の逆数)の下位桁が
切り捨てられちゃうので注意が必要。

　#…なんで逆数なんだろう？
　#　ROW()+COLUMN()/10^5
　#ぢゃいけないの？　＞　私

　#ずっと前からなんとなく逆数とってたんだけど
　#何か理由があったんだろうか？？？

==================================================

そういえば

「Excelの有効桁は15桁まで」⇒「千兆より大きい数字は扱えない」
みたいに誤解してる人が結構いるような気が…。

↑みたいな誤解はまだ被害は出ないけど
「整数8桁，小数点以下8桁ならアリ」とか思ってる人がいそうで怖い。

田中教徒が二言目には口にする「可読性」、ナニソレ、美味しいの？

=================================

「難しい関数は使わずIFだけで判りやすく書いてみました」
みたいなことを言う人がたまにいますよね。

「なんかいなかんじはしようせずひらがなだけでへいいにきじゅつしてみました」
こういうこと？

あるいは、

　3^4
と書くよりも　
　3*3*3*3　
と書く方が判りやすくて

　3*3*3*3　
と書くよりも　(((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3)))+(((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3)))+(((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3))+((3+3+3)+(3+3+3)+(3+3+3)))
と書く方が判りやすいとか、そういうこと？

ナルホド。
掛け算だけで書けば、累乗を知らない人にも簡単に理解できるし
足し算だけで書けば、乗算を知らない人にも簡単に理解できますね(^^

IFだけ使って数式書けば
IFしか知らない人にも「動作」を追うことはできるよね。

でも、IFだけ使ってごちゃごちゃネストした数式って
「意図」とか「構造」とか「挙動」とか
「動作」以外の部分の「可読性」は明らかに悪化してるよね。

その数式の「意図」や「構造」や「挙動」の判りやすさよりも、
IFしか知らないような人でも「動作」を追えることの方が大事？

私がIFではなくINDEXやMATCHやCHOOSEやMODを使うのはそういう理由。
「ムズカシイ関数」を知ってるのがウレシイからぢゃありません。

=================================

「作業列を使って判りやすく処理しました」
みたいなことを言う人がよくいますよね。

【作業列を使った方が「判りやすく」なることがある】
【作業列を使った方がたいていの場合速い】
否定しません。

問題は…
その作業列が
・いったいどういう意図で何を計算していて
・その結果をどこで使ってるのか
・数式を変更するとどこに影響するのか
を、作った本人以外が把握するのは結構面倒だということ。

ワークシート分析？
そですね。そんな機能もありましたね。忘れてました(爆
受け取ったブックを一つ一つ「分析」できるほど
のんびりした職場じゃないんです、スミマセン。

【速度的に問題がなく】【将来的に変更の可能性がない】ならば
ネストして、パッケージ化／ブラックボックス化した方が
ブック全体の「可読性」が向上するし、取り回しも良くなる
…こともあります(笑

なんかやけに重たい計算してる作業列があって
パッとみた感じ、どこからも参照してないように見えるんだけど
最悪他のブックから参照してる可能性もあって消すに消せない
みたいなこともありますしね。

Excelコンテストみたいな状況であれば
作業列一つ一つに丁寧にコメントつけたりなんてのもアリでしょうけど
「作業列ごとにコメントつける」というタスクが発生すること自体
作業列を使うことによって作業効率が悪化してますよね。

ついでに言うと、Q&Aサイトの回答で数式を提示する場合には、

【数式の数が増えるほど、ヒューマンエラーの発生率が上がります】

「エラーの発生率が高い」というのは重大な欠点では？
　
私が数式一発回答を寄せることが多いのは主としてそういう理由。
「フクザツな数式」を作れるのがウレシイからぢゃありません。
　
=================================

「[名前]を使って判りやすく…(以下ry」

えっと
・[名前]がどこで使用されてるかが【判りにくい】んですが…。
・[名前]が現に使用されてるかどうかが【判りにくい】んですが…。
・[名前]が実際にどこを参照しているかが【判りにくい】んですが…。
・[名前]に見出行・見出列が含まれてるかどうかが【判りにくい】んですが…。
・[名前]に揮発性関数使われると死ぬほど重たくなるんですが…。
・[名前]使ってるシートのコピーでトラブることが多いんですが…。

いや、私も[名前]使いますけどね、しばしば。
ものには「程度」ってもんがあるだろうと。
コンテストはコンテスト、実務は実務。

Excelコンテストぢゃないんだから、
総ての参照に[名前]付けて「名前一覧シート」みたいなもの一々作ってたら
日が暮れるだろと。

例によって長文ですが、私が言いたいことは
参考画像みれば一目でわかるハズ…わかる人には(ぉ

======================================================

例えば、

ダミーデータしかいじったことのないような
「回答の専門家」「プロの回答者」の皆さんはきっと、

　ROW()-ROW(A$2)

みたいな感じで連番取ってるのを見て

「ばっかじゃねーの？　
　ROW(A1)って相対参照すれば、1から順に連番が返るって知らねーの？(ﾌﾟｹﾞﾗ」

とか思ってるんでしょうけど…

■「テーブル内の行抜いただけで#REFエラーが返る」
のはまだ許すとしても（←ホントは許せない）

■「テーブルのドラッグ移動や切り貼りができない」
のはまだ許すとしても（←ホントは許せない）

■「【テーブルの外にある】セルや行を抜いただけで#REFエラーが返る」
のはまだ許すとしても（←ホントは許せない）

■「【テーブルの外で】セルや行を挿入すると【エラーも吐かずにデータが抜ける】」
ような数式が…

　実務で使えると思ってんのかゴラァ!!!11!!!1!!!1

って思うんですよね、私としては。

======================================================

あるいは、

知識もスキルも立場も異なる赤の他人と共同作業したことがないような
「回答の専門家」「プロの回答者」の皆さんはきっと、

　ROW(INDIRECT("1:"&COLUMNS($B$6:$H$6)))

みたいな感じでテーブル列数分の自然数配列作ってるのを見て

「ばっかじゃねーの。　　
　なんでINDIRECT使うの？　つROW($1:$7)　(ﾌﾟｹﾞﾗ」

とか思ってるんでしょうけど…(以下ry

もっとも、こちらは速度とのトレードオフになるので、
埋める量や状況によっては選択の余地がなくもないですし、
私も実際

　ROW(INDIRECT("1:7"))

みたいな書き方はしばしばしますけど…。

=====================================================

こんな書き方もありますね。

　ROW()-2

とか

　{1,2,3,4,5,6,7}

とか。

これの是非もまぁ状況に依存するわけですけど、やっぱり

　表位置や列数が動かないと読み切った上で書いてんだろうなゴラァ!!!11!!!1!!!1　

とか思うんですよね、私としては。

======================================================

まぁ、多くの人たちは、たぶんそーゆーことを全部判った上で
ROW(A1)とかROW($1:$7)みたいな記述の方が「すまーと」に見えるから、
質問者ウケする数式でとりあえずポイント確保したら
後は野となれ山となれってことなんでしょうけど…。

とりあえず、参考画像のような状態みて
吐き気を催さないような人とは仕事したくないなぁと思ったり。

「最適化」とか「速度」とかって、
Excelで「でーたべーす(ワライ」を運用するようなケースは別にして
高々数十・数百行の「リスト」とか「一覧」とか取り回す際に
「堅牢性」を犠牲にしてまで追求すべきものですかね？