VisualBasicをメインで使うチームの地雷感
地雷度、高いと思う。
こういった話題を挙げると、何かとVB6なのかVB.NETなのか書けよとか言われるけれど、基本的には両方で、「VisualBasic」の名を持つもののことだ。
VBそのもののディスりではない
VBそのものの言語仕様だとかに関するディスりではない。 結果的にVBディスりになってしまうかもだけど。
私はVBが嫌いなんだけど、言語的に優れていないとか優れているとか言語自体を批判する気は今回ない。
今現在、「チームでVBを使っている」「仕事はVB」と言っている人だったら、基本的にはVB.NETを使っていることだと思う。前言したように私はVBが嫌いで、そんでもってC#が好き。ここで機能的に見てもそのC#と比較してそこまで致命的（能力的）な格差は無く、基本的にVBはクライアントの要求を十分こなせる言語であるとは思っている。そもそもVB.NETの力の中核は.NET Frameworkだしね。
私が思っているのは、VBを好んで、あるいは大々的に使う企業やチームの地雷度が高いなぁということ。
VBを使うチームの意識
このご時世にVBを使うチームにはある特徴がある。
その特徴とは、チームメンバの大半の向上意識が低くいこと。特にそれはトップに近づくと謙虚に出ていて、プロジェクトを引っ張るSEやメインプログラマの役回りとなる人間がより"そう"であることが多い。
そうしたプロジェクトにおけるトップに近い人間は基本的に高齢であることが多い。年齢という大雑把なくくりで人間性を判断すべきではないとは思うが、それでも言ってしまおう。だいたい彼らは新しいことを進んで学ぼうとしない。
彼らはとことん学習コストがかかるのを嫌い、非常に保守的である（これを保守的というのかな？）。
彼らにとってC#やJavaを習得せず、VBと名のつく言語を使おうとするには下記のような意識がある。
- 自分たちはVB6を学んだ。VB.NETも文法的に似ているのであれば、新たに言語を学ばずに済むだろう。
- C#？ C言語系はポインタとかの考え方めんどそう。いずれにせよ同じ.NETなんだから今まで通りVB.NETを選択しておけば安牌だ。
- VBだったら単純だし誰でも読めるし書けるだろう。社内あるいは派遣の老若男女問わずに。
てな具合。これらが正しい考えであるかどうかは別として。
3つ挙げたけど、理由としては今までの自分（あるいはチーム内）で培ってきたVBに対する知的資産や経験を極限まで怠慢に利用しようという魂胆がある。
もちろん、教育コストがかからないことを重要視するのも大切である。だが、利用するプラットフォームが異なるにしても、現代ではC#、Java、PHP、Pythonといった豊富な言語選択肢があり、SIerという商売をしていれば大体はVB以外にも触れる機会がある。そうした中で、あえてVBを選択する時は高確率でこうした学ぶことに対する怠慢で言い訳がましい意識が伴う。
教育コスト以外の話でよくあるのが、クライアントの依頼で大昔にVB6で作ってもらったシステムを改修することになり、VBという名前繋がりでVB.NET化しようというお仕事もあるかもしれない。「文法が近いならソースを再利用できるかもしれない……」とか変なことを考える。
私が言うのであればそんな昔のものである時点で、そもそもイチから作り直した方が良いシステムだろうと思うし、VB6時代のソースコードを再利用しようという時点で生産性が悪い。けっこう違うんだよなぁコレが。
私はそういう仕事に対して「初めから作っちゃったほうがいいですよ」と言うのだが、営業とその他の勢力により「これでいいんだよ」って言われてこういう仕事をやる。すると、何だかおじいちゃんの形見の時計だとか、長年住んでいる思い出の木造住宅だとか、そういうものをなんとかして直してあげているという慈善的な気分になる。ごめん嘘。本当はそんな温かみなど無い。そうでも思わないとやってられないのだ。
VBは過去の遺産を連れてくる
こうした意識によってVBが選択される場合、基本的にその意識に引っ張られて過去の遺産が引き継がれる。もちろん良い遺産ではない。負の遺産だ。
…
具体的には下記みたいな感じ。
- ハンガリアン記法
- ソースコードにとにかくコメントを残す
- 修正したソースコードはコメントアウトして残す
- オブジェクト指向がわかっていない
- 自動化されていないデプロイ方法
- ただひたすらの人力＆人海戦術によるテスト
前述した意識の話関連から、基本的には昔のやり方も採用されやすい。
例えばハンガリアン記法は結構嫌いな部類だ。
ハンガリアン記法とは？
変数とかが何型か分かるように、変数名の頭にデータ型の識別子をつける記法。 例えば、String型の変数ならstrName、Integer型の変数ならintAgeといった具合に命名する。
ハンガリアン記法は一見、初心者から見ると「すげー変数の型が一発でわかるぜ」と関心させるような力がある。これは初心者があまりコーディングテクニックというべきものに触れたことがないからによる（まあ、ハンガリアン記法は最早テクニックでもなんでもないけど）。
が、そもそも今のIDEだったらマウスカーソルを合わせれば何の型なのかわかるもんだし、周辺の処理内容を眺めれば利用している変数の型の推測なんてすぐにつく。
また、処理内で使う変数なんてデータ加工や合計値、識別子となるパラメタを放り込んでおくバッファみたいなもんで、処理間をやりとりするデータなんてクラスのメンバとして定義されているもんである。
それに加え実際にはハンガリアン記法は変数名を長くするだけでなく、もっと有害な場合もある。
例えばintValueと言いつつホントはLong型なんてものもある。これは途中でIntegerからLongに宣言部を変えたんだけど、変数名を修正していないとかそういうアホな原因から生まれたお肌に優しい天然由来のトラップだ。型をわかりやすくするためのハンガリアン記法がフェイクとして出現するとか本末転倒だな。
あと、VBにはコメントが多い。すげー多い。
ソースコードの内容をいちいちコメントで説明するのが大好きな人が多い。
'未成年の場合 If intAge < 20 Then 'メッセージを表示 Msg.Show("お酒はダメよ") End If
こんな感じのレベルのコメントがマジで多い。そんなもんソース見りゃ分かるわ、的な。
これは単純にVBを求める層が技術的に低い水準であることに起因する。前述した「VBだったら誰でも読めるし書けるだろう」といった考えから発生する。VBを選択した時点で「どんなエンジニア未満のエンジニアでも大丈夫」といった思想があり、この鬼のように優しいコメントはそうした思想を実現するものである。
もちろんコメントを一切残さないのも問題だが、なんでもかんでもコメントで解説するのはそれだけ自分がソースを理解するのに時間がかかっているということになる。つまりはプログラマとしての能力が無いと言っているようなもの。前述のハンガリアン記法にもこれは当てはまり、ソースの前後から型を自然と推測できない、つまりは便利なIDEがあるにもかかわらずそれに加えてもソースを読む力が弱いからハンガリアン記法を好むのだ。
また、コメントといえば修正したロジック部分をまるごとコメントアウトして残すという文化やルールもある。
'↓2014/04/01 修正ここから F.Yonezawa Start --------- ' 消費税改訂により、下記処理をコメントアウト。 'Dim decTax As Decimal = 1.05D ' 'decTotal = decPrice * decTax '↑2014/04/01 修正ここまで F.Yonezawa End --------- '↓2014/04/01 追加ここから F.Yonezawa Start --------- ' 消費税改訂により、下記処理を追加。 ' 固定で取得していた消費税を共通関数で取得するように修正。 decTotal = decPrice * GetTax() '↑2014/04/01 追加ここまで F.Yonezawa End ---------
例えで書いたソースコードもいい感じに馬鹿っぽさが出てて良いと思う。なんで消費税ハードコーディングで計算してんだよとかね。
少し話が脱線したが、例えとしてこんなような履歴管理がソースコード上で普通に行われている。
こうしないと上の人間が怒る。そりゃもう怒る。
証跡や過去の履歴を残すという大切さはわかる。だが、GitやSubversionといったバージョン管理ツールがあるこのご時世にソースコード上でこんなことをやる意味（必要）はないし、ソースコードの可読性を損なうだけだ。
結果として、VBのソースコードはVisualStudio上から見た時に緑色が占める割合が高い。VB自体は冗長になりやすい文法なので、それと相まってソースコードがクソ長くなる。それでアホみたいにスクロールして読まなければいけない。地獄かな？
なんかもう書く気力が薄れてきた。まあ続けよう。
ここまで述べた通り、ソースコードに対する読解力やツールの応用力が低い。総じて能力が低いのでオブジェクト指向をうまく活用しようとしない。というかできない。
例えばクラスやインターフェースはメンバやメソッドの存在を定義付ける為のただのルールだとしか思っておらず（あるいはそういう使い方しかできない）、いらんところまで実装や継承を促して、がんじがらめにしたりする。ソース見るとクラスに対して同じ数のインターフェースが居たりして（そのインターフェースはその対になる一つのクラスにしか実装されない）、「何考えてんのコイツ……？？？」って感じになる。これはインターフェースをおまじないや掟のようにしか考えていないから発生する。
他にデプロイを自動化しようという考えや、テストを効率化しようとかも考えない。当然のごとく考えない。そもそもそういう考えがわかない。ただ時間がかかるタスクとしてどーんと工数が割かれ、Excel方眼で作られたスケジュールシートに長い長い棒線が引かれるだけである。
よって地雷
よってVBを好んでよく使うチームは地雷が多い。
向上心や技術力が低い集団である可能性が高いと言える。
私は尊敬できるVB使いという人間に今までで一人だけ出会ったことがある。派遣のNさんだ。
派遣のNさんがVBが好きだった理由は、学生の頃からBASICに慣れ親しんでいてBASIC系そのものの文法が好きだということからで、.NETの技術についても熟知していたし、C#も使いこなしていた。つまり、アホみたいな言い訳の為にVBを選択しているわけではない人間だった。よく技術書やMSのブログも読んでいたぁ。
現実で出会った尊敬すべきVB使いはNさんだけだが、ネット上にもNさんに似た人は沢山居る。
VBは嫌い……いや、大嫌いだ。
まあ、大嫌いであれど正当で然るべき採用理由があるのであれば、ある程度の個人の好き嫌いは仕事として割り切り目をつむるが、VBを採用する組織的背景というものは基本的にどうしようもない。
ここまでのレベルでどっぷり怠慢してきたSIerは良い仕事ができない。
ああ、これは仕事意識とか成果物のクオリティが低いという意味の戒めだけではなく、実際の受注において良い条件の仕事の話が来ないということだ。
できるのは自身たちの能力不足による生産性の悪い作業ばかりなのに対し、曲がりなりにもこのSIerの根底にあるのは効率化と生産性を求めるシステム開発であるという根本的なズレが発生する。
言わば「便利なシステムを開発しよう」という人間自体が、便利で効率的な仕事をできていないし追求していない。「切れりゃなんでもいいでしょ」って言いながら、ナマクラ包丁を作り続ける鍛冶屋さんみたいなもんだ。
そんな集まりの組織ができる仕事なんてたかがしれていて、今以上の存在にはそう安々となれない。であれば、そうした最低の位置をこれからも墜落寸前低空飛行し続けるか、気がつけば他に仕事を奪われて撃墜されているかのどちらかしかない。
ソースコードの質は悪く、ツールも使わず、結果的にアホみたいに時間と人をかけて作業をするので、営業もそれをある種わかっていて買い叩かれたようなアホな案件をとってくる。
ただの開発言語であるVBひとつから話を掘り下げすぎただろうか。
いや、決して言い過ぎではない。これは日本SIer界という魔界でわりとマジで言えることだと思う。
ある程度プログラマとして仕事をし、色々な企業の人と出会ったが、VBをメインとする環境は常にこんなんだった。
ちなみにC#の開発プロジェクトでも「なんか変だな」と思ったら、やっぱりSEとPMがVBしか組んだことが無い人間で、笑顔で「VBしか組めないよーC#とかJavaとかって難しいよね」とか笑顔で言ってた。
メインがVBとか言っているような組織は注意した方が良いだろう。
例えあなたがVBに対してBASICの頃から抱き続けた愛着があったとしても、他人がそれを分かち合い、より高度なことを実現できる仲間が居るとは思わないほうが良い。
彼らは地雷だ。
