変数の宣言は強制する

VBEのメニューバーの[ツール]－[オプション]で表示されるダイアログボックスで、標準設定だと変数の宣言は強制されていないが、以下の画像の赤枠のように、強制することをお勧めする。

「いちいち変数を宣言するなんて面倒」と思う方もいらっしゃるだろう。ごく短い処理であればそれでも済む場合もあるが、それでも変数の宣言を、それも適切な型での宣言をさせた方がよい、と思う。

思いつく理由としては

・使っていない値に設定してしまう危険性がある

・型を間違ってしまう危険性がある
がある。

※以下のサンプルコードはまたしても実行していないので、おかしな場合はご連絡を。

【使っていない値に設定してしまう危険性がある】

例えば次のようなコードがあったとする。

Sub aaa_0()

　　'AとBの加算結果を表示する

　　A = 1

　　B = 2

　　C = A + B

　　MsgBox D

End Sub

上記プログラムでは何が表示されるだろうか？実際はこれほど単純なミスも希であろうが、例なのでご了承頂くとして、コメントに入れたとおりの結果は得られない。

このときに、A、B、C　を宣言しておけば、間違えてDを使ったとしてもエラーが出るので防止することができる。

Sub aaa_1()

'次の３行を追加

　　Dim A As Integer

　　Dim B As Integer

　　Dim C As Integer

　　'AとBの加算結果を表示する

　　A = 1

　　B = 2

　　C = A + B

　　MsgBox D　　　'←宣言されていないのでエラーが発生する

End Sub

【型を間違ってしまう危険性がある】

例えば次のようなコードがあったとする。

Sub bbb_0()

　　'AとBの加算結果を表示する

　　A = 1

　　B = 2

　　C = "A"

　　D = A + C

　　MsgBox D

End Sub

変数を定義していないと変数は Variant型になる。Aの内容は数字の1、Cの内容はアルファベットのAなので、一見足し算なんぞできないように思えるが、+　は文字列の結合をする演算子でもあるのだ。よって、「文字同士の結合」だと勝手に解釈されてしまう。

Sub bbb_1()

'次の４行を追加

　　Dim A As Integer

　　Dim B As Integer

　　Dim C As String

　　Dim D As Integer

　　'AとBの加算結果を表示する

　　A = 1

　　B = 2

　　C = "A"

　　D = A + C　　'←演算結果が数字ではないのでエラーが発生する

　　MsgBox D

End Sub

【まとめ】
上記のように、変数の宣言はミスを防いでくれるのだ。多くのコンピュータ言語は「変数の宣言は当たり前」であり、また「Variantのような何でも屋の型はまずない」のである。（詳しい方へ：プリミティブな型、とご理解願います）

型を正しく宣言しないと、宣言したソフトウェアよりもテスト工数が多くなり、製造に余計なコストがかかる、ということにもなるのである。たとえ短いプログラムであったとしても、かならず「正しい型を宣言する」ようにすることをお勧めする。

マネージャーの仕事

体験的に、うまくいっているプロジェクトは
・仲がいい
・雰囲気が明るい
・言われなくても動く
・他人の作業をカバーする
・情報が共有化されやすい

という傾向があるように感じている。こういうプロジェクトは自律的であり、リーダーやマネージャーはあまりコントロールの必要性がない。うまくいっていない所ほど、上記に挙げた状況から遠くなるようだ。

ここまでの仕事は、マネジメントでも必要なことであるが、マネージャーの仕事ではなくリーダーの仕事でいい、と考えている。

ではマネージャーは何をすればよいか？

リーダーにはできない部分、リーダーとあまりかぶらない部分、リーダーとかぶっているか否かに関わらず重要なことを見るのである。
例えば、作業効率が上がるよう責任者と掛け合って環境を整えたり、貢献した人に報いる制度など士気を鼓舞するしかけを設けたり、メンバーの健康状態や残業やそれによる費用などを確認したり、である。

そういう中でも、最も重要な仕事がステークホルダー（利害関係者）の調整であろう。これが厄介ではあるが、これさえ調整がつけばプロジェクトの方向性が狂うことはあまりない。逆にこれを放置して進めると費用が無駄になったり感情的なしこりが残ったりと、プラス面はない。

実際の調整には、相手の性格、立場、システム導入後のメリットデメリット（システムに限ったことではないですが）などを考慮し、根回し、情報操作（言葉は悪いですが、伝えるタイミングを変える等）、ミーティングなどを経て合意にこぎつける。過程では辛く苦しいこともあるが、うまく調整がついたときはしてやったりという気分になれる。
場数を踏まないと難しいかもしれないが、場数から慢心から油断が生じて失敗したこともあった。それ以来、いつも初心で臨むように心がけている。コツとしては可能な限りどのステークホルダーにもメリットが享受できる案に調整しておくこと、誠実に事に当たることであろう。

マネージャーの仕事ぶりが悪いとプロジェクトは迷走するし、顧客は金銭的な被害を蒙る。シンプルであるが重要な役割なのである。

VBAからは逸れるが、決して別物ではないので記載しておく。

情報処理試験 申請忘れ

春の情報処理試験、うっかり申し込みを忘れてしまった・・。

受験しようと思っていたのはシステム監査。このところ仕事で敢えて監査よりの事も顧客に提案していたりして、個人的には準備万端であっただけに・・。といっても、それで受かるほど甘い資格ではないことは重々分かっている。

個人的には、ここ数年でシステム監査の重要性は増すと考えている。

システム監査、というものに馴染みのない人も多いだろう。ちょっと解説してみると・・。

もともとは、会計がきちんと間違いなく行われているか、というところの会計監査がある。が、会計がシステム化されると「システムがちゃんと動いてるのか？」を会計監査をする立場の公認会計士がする必要が出てきたのだ。

そのために「システムではこのくらいのチェックポイントはいるでしょ」と、システム監査が生まれた訳である。

それが発展してきて、システム独自にチェックが必要になってきている。システムも企画段階、開発段階、運用段階では監査の項目が異なるし、最近では情報セキュリティも考慮が必要になったりと、発展はしている。

簡単にいえば、「システムが思惑通りに動作しているのか」をチェックするわけであるが、J-SOXなどを考えると今後は非常に重要になってくる技術ではないかと考えている。