SIerのプログラミング技術向上を求む
1. お客さんが使うのはソフトウェア
SIerはきちんと仕事をすると言われているらしいけど、運営やドキュメント作成は本当にしっかりやってると思う。
（長時間のドキュメントレビューなど、やりすぎだと思うこともあるくらい）
しかし対照的にプログラムについてはあまりにもノータッチだと思う。
新人が書いたものがそのまま納品されていたりする。
（ここでの新人は初級プログラマを想定）
先輩にプログラミングが分かる人がいないのが大きな原因だと思うけれど、それでよいのだろうか。
新人が書いた提案書をそのまま顧客に持って行ったりすることがありえないように、新人が書いたプログラムがそのまま納品されるのもありえないと思う。
お客さんが使うのはドキュメントでなく、ソフトウェアだから。
2. ソフトウェアの品質
「新人が書いたとしても、テストで問題がなかったからいいのではないか？」
もしそのソフトウェアが一度もメンテナンスされることがないのであればそうかもしれない。
けれど現実的にはそのようなことはありえなくて、何度も何度も修正が入ることになる。
その時に上級プログラマが書いたプログラムと新人が書いたプログラムの間には、とてつもなく大きな差が生まれる。
上級プログラマが書いたプログラムに修正を加える場合は20分でできるものが、新人の書いたプログラムに修正を加える場合は200分以上かかったりする。
さらに、新人の書いたプログラムは可読性が低く、修正箇所が多く、重複も多く、不具合の生まれる可能性も高い。
3. 外から見ても耐震偽装はわからない
（このエントリのネタ出しをしてた頃から時間が経ちすぎて、かなり懐かしくなってしまった）
今まで書いてきたことの繰り返しになるけれど、プログラミング工程をブラックボックスにしないで、中身をチェックしないといけないと思う。
たとえ最初の納品前のテストで問題がでなかったとしても、そのプログラムは潜在バグの宝庫の可能性がある。
悪質なプログラマは、システムエラーだけはおこさないように、エラー発生時も処理を続けるためのTry Catchを書いていたりする（実話）。
外から見ても耐震偽装は気づきにくいが、中身を見ればすぐに分かる。
4. ものづくりを楽しめるように
SIerには要件定義等、上流工程が好きな人が多いのかもしれないけれど、僕はプログラミングが好きだ。自分の頭に描いたものがカタチになっていくのがとても楽しい。
しかし・・・
今、仕事でプログラミングをする時は、過去に一括外注で作られたシステムのメンテナンスをしているが、これは楽しくない。ため息をつきながらメンテナンスをしている。
理由は前に書いたように、可読性が低く、修正箇所が多く、重複も多く、いらいらしてくるから。
中身を見る前は20分と見積もったものが、実際には200分もかかるから。
楽しみながらやるのと、ため息まじりにやるのと、どちらがいい仕事ができるかと言えば楽しみながらに決まっている。
楽しんでこそプログラミング
仕事としてプログラミングをしていて、ここ数年同じシステムをASP.NETで開発しています。
元々は一括外注先がプログラミングをして、その修正をずっとしています。
開発環境はVisualStudio2003。
なかなか重たいIDEなので、実行したり止めたりするデバッグ作業はかなり大変です。
そんな環境でプログラミングをしているうちに、楽しさをだんだん忘れつつありました。
仕事として、作業としてプログラミングしている感じになっていました。
そんな中、知人にplaggerを紹介してもらいました。
早速、ActivePerlをインストールし、plaggerをインストール。CustomFeedを試してみる。
なかなかうまくいかない。
英語のエラーメッセージと格闘。
設定ファイルと格闘。
文字コードと格闘。
うまくいかなくて大変？・・・いやいや、これが楽しいんです。
学生の時にやってた懐かしい感じ。
だからのこの業界に就職したんだったと思い出しました。
仕事は辛いこともあるけど、辛くならなければいけないものではない。
仕事だからって、楽しんでこそプログラミングだ。
.Netでも楽しめる方法を探そう。
Microsoft Sliverlight
WPF/EがいつのまにかMicrosoft Sliverlightと名前を変えていた。
専用サイト(http://www.microsoft.com/silverlight/default_01.aspx)のイメージ動画がなかなかかっこいい。
ちょっとMacっぽいけど。Microsoftにも作れるんだなぁなんて思ってみたりして。
イメージ動画はWPFのデモを見た人だったら「なるほど、イメージがでてるな」って思える内容。
WPFによってボタンやリストボックスの形が自在にカスタマイズでき、アニメーションがつけられ、これまでと全く次元の違うUIになりますよっていうのを伝えたいのだと思います。
開発者としては、見ながら「これがリストボックスなんだろうなぁ」とか、つい想像してしまいます。
今は開発環境がとても貧弱(≒エディタベース)なのでWPFで何か作ろうとは思いませんが、Expression Studioや次期VisualStudioが出たら流行るかもしれませんね。
コードの書き方で工数を減らす
あるシステムに対する仕様変更で、見積よりも大幅に工数が増えたことがあり、その原因として以下の理由があげられました。
そして、次回は仕様や内部構造を伝える時間を取りましょうということになりました。
しかし、もっとよい解決方法があります。
それは、
- 新しくチームに加入したプログラマが見ただけで理解できるコードを書く
です。
例えば以下の2つのコードを比べてみてください。
コードA
IF date > DATE1 and date < DATE2 THEN
result = qty * RATE * RATE2
ELSE
result = qty * RATE
END IF
コードB
IF IsSummer(orderDate) THEN
tax = SummerTax(quantity)
ELSE
tax = NormalTax(quantity)
END IF
コードAを見てもなんのことやらさっぱりです。
しかし、コードBは見ただけで「注文日が夏季の場合は税金が変わる」ということがわかります。
「夏季の税金を変更する」という仕様変更があった場合、コードAの場合はどこを変更していいのかさっぱりわかりませんが、コードBの場合は「SummerTax()」を修正すればいいんだと一目でわかります。
こういうコードを書いておけば、内部構造を説明するといった余計な工数をかけなくて済みます。
SIer新人プログラミング教育
新人が入ってくると最初に行われるのはプログラミング方法の教育です。
言語はJava。
大規模開発で最もよく使われる言語なので妥当な選択だと思います。
しかし、Javaを教えると言ってもそれほどJavaらしいことを教えるわけではないと思います。
if文であったり、while文であったり、15年前の言語から変わりません。
一応オブジェクト指向という言葉は教えるし、継承などの考え方も教えます。
けれど教育時に作るサンプルプログラムは、オブジェクト指向とは遠く離れた15年前のプログラミング方法で作られます。
「教育だから」「はじめは簡単なものから」
そうやって15年前の技法しか知らない新人達は、実際の開発でもその技法でコーディングをおこない、粗雑なプログラムが作られていきます。
現場で教える方も15年前の技法しか知らないものだから、結局何年たっても15年前の技法から進歩しません。
SEと呼ばれる職種は数年たつとプログラミングをおこなわなくなります。
オブジェクト指向の本質を理解し使いこなすには、それ相応の年月が必要だと思いますが、そこにたどり着く前にプログラミングをやめてしまいます。
そして、後輩に15年前の技法を教える立場になってしまうのです。
NVARCHARの桁数の罠
SQLServerにはVARCHARのユニコード対応版である、NVARCHARというデータ型があります。
このNVARCHAR型の桁数がなかなかの曲者なんです。
VARCHAR(10)には何文字格納できるか？
こう聞かれれば「半角10文字、全角5文字」と答える人が多いのではないでしょうか。
おそらくVARCHAR(10)の10は半角文字数と認識されていると思います。
ではNVARCHAR(10)ではどうでしょうか？
正解は「半角10文字、全角10文字」です。
NVARCHARはユニコードを扱うので、全ての文字を同じバイトで格納します。
従って半角全角の区別はありません。
NVARCHAR(10)の10は半角全角の区別なく、単純に文字数です。
この差を意識せずにNVARCHAR(10)をVARCHAR(10)に変換しようとすると
たちまち桁あふれエラーが発生してしまうので注意が必要です。
SEとPG
私のチームではSEとPGは以下の役割を担っています。
PGは別会社に委託することが多く、委託するには我々が顧客と合意した内容をもれなく伝える必要があります。しかし、外部設計書に全てをもれなく記述するのは困難なのが実情です。
そのため委託先からできあがってくるプログラムは、多くの場合求めている仕様と異なっています。
そこで我々は委託先のプログラムを受け取った後に「受入検証」というフェーズを設け、SEとPGとで不具合票等のやりとりを何度もおこない、求める仕様に近づけています。
この「受入検証」は以下の2つの問題を抱えています。
- 時間がかかる
- プログラムが修正修正の繰り返しで汚くなる
この問題を解決するにはどうすればよいでしょうか？
問題の原因は前述のようにSEからPGへの仕様伝達がうまくいっていないことにあります。
では仕様伝達をうまくおこなうためにはどうすればよいでしょうか？
外部設計書をこれまで以上にもっともっと時間をかけて詳細に記述すればよいでしょうか？
いや、それでは開発期間がいたずらに延びてしまいます。短納期が要求される現在のシステム開発に、開発期間を延ばすような方法は認められません。
すこし考え方を変えてみましょう。
SEからPGへ、仕様を伝達しなければよいのではないでしょうか？
つまり、SEがPGを、あるいはPGがSEの役割を兼ねればよいのではないでしょうか。
具体的には「SEがプログラミングをおこなう」、「PGが外部設計をおこなう」のです。
こうなってくるとSEとPGを分けることにあまり意味はなくなってきます。
あえて分けるとすれば、提案、要件定義あたりのコンサルをおこなう役割と、外部設計以降を担当する役割くらいで分かれるのではないでしょうか。
外部設計以降は各担当が一気に設計をおこない、一気にそのまま製造してしまう。
このメリットは先ほどの受入検証の2つの問題を解決するだけではありません。
設計者が製造者を兼ねるということは、設計段階でサンプルプログラムを作成することが可能になります。
設計段階で顧客にサンプルプログラムを提示できれば、設計の質もかなりあがることが期待できます。
「百聞は一見にしかず」です。
デメリットとしては人件費の安いPGという職種がなくなり、人件費があがることが予想されます。
しかしそれが本来の姿ではないでしょうか。
プログラミングは単純作業ではないのです。
