コンピュータ上で実行されるのはプログラムである

「何を当たり前のことを言っているのだ」と言われそうですが、実際の開発現場ではこの当たり前のことが往々にして忘れられてしまいます。それは例えば一般的なソフト会社のキャリアパスを見ても分かります。経験を積むに従い、プログラミングから遠ざかるのが一般的です。専門家としてのプログラマーが少ないのが実情ではないでしょうか。常に素人に毛の生えたというと言い過ぎかもしれませんが経験の浅い人間が実際に稼動する、建物で言えば壁や柱や基礎を施工している、これがアプリケーション開発の実情だと思います。コンサルタントや上級ＳＥがどこかでプログラマーという職種を低く見ている、すなわち業界ではプログラミングというのはレベルの低い作業という大げさに言えば文化・思想が定着していると感じています。コンサルタントがどれだけ素晴らしいパワーポイントの資料を作りプレゼンを成功させても、そしてユーザ説明と承認が非常に重要であることは重々承知しているつもりですが、それでも実際のコンピュータ上で実行されるのは、パワーポイントの資料ではなく、プログラムだということをしっかり認識する必要があるんだろうと思います。

企業コンプライアンス

コンプライアンスとは法令順守のことですが、特に個人情報保護法の施行依頼この点のみが強調されすぎているように感じます。情報処理産業に従事するものの職業倫理が低下しつつあるようにも思えますが、これには雇用形態の多様化等々、検証すべき問題が少なくないように思います。一方でコンプライアンスを主張している企業サイドには偽装請負や多重派遣といった点に関しては法令を遵守する姿勢が欠如しているように思えてなりません。プロジェクトⅩという番組が以前人気を博しましたが、共通する点というのはモチベーションの高さと帰属意識の高さです。企業が潰れては元も子も無いのは分かりますが、モチベーションの維持にもう少し配慮がなされても良いもかもしれません。一方で技術者サイドもプロ意識を持つことに心がけていく必要はあるでしょう。企業・技術者双方にコンプライアンスの思想がしっかりと根付く必要性があると思っています。

生産性における問題

一般に客先常駐作業における作業工賃は作業時間数に換算されます。これには問題点があります。システム開発における技術者の開発効率は最大で６倍程度開くという話を聞いたことがあります。少なくとも生産性が高いものが損をしてしまう、これは以前から指摘されている点です。しかし、明確な解決策は示されていません。１人月の作業を仮に半月で終わらせることができるならば残りの半月は休んでいても良いのでは？という疑問が湧いてくるのは当然ですよね。現実には早く終わらせることができたならば新たな作業が割り振られるのが普通です。プロジェクトメンバーには新人も混じっていれば問題児も混じってます。こうしたメンバーのミスや未了作業の仕上げを手伝わされることになります。同じプロジェクトなのだから助けあうのが当然だとしても、作業効率・負荷に応じた傾斜的な賃金配分を契約金額の何割かに含ませることでこの問題は解決するのでは？と感じるのは私だけでしょうか。

コンピュータ言語の限界を知る

自分が使用しているあるいは専門にしているプログラミング言語の限界を知るにはなかなか良い手段が思いつかないのですが、失敗したプログラム設計には様々なヒントが隠されています。非常に作りづらかったり、通常ではまず使わない命令やクラスやDLLやら何かを使うハメになったときこれは嫌でしょうけれどチャンス到来と思いましょう。こんなプログラムなんて「ありえねーよ」というものを1本でも2本でも完成させると自然とその言語の得意・不得意としている機能が見えてきます。そうしたら本来クライアントの満足が得られることを前提に自分ならどう設計するかを考える習慣をつけましょう。きっと良い設計者になれると思います。

このテーブルはどっち？

テーブル設計の上で必ず意識しなければいけないのは、このテーブルはマスターなのかトランザクション（取引）テーブルなのかということです。様々な目的で、例えばデータを一時保管したり、バッチ処理の中間ファイルとしての役割のテーブルとかはもちろんあります。しかし、まず固めねばならないのは取引の最終保管の形式とマスターだと思います。なーんだ当たり前という声が聞こえそうですが、これが全然決まらない、頻繁に仕様変更が発生し、最終テストの段階になってはじめて矛盾や項目不足に気づくということが実際に起こります。最終の格納形式はどのようなOUTPUTが必要かで自ずから決まるはずです。まずはネットで検索してデータベースの正規化の意味をやり方をしっかり理解しましょう。仕事が出来る人は意識的・無意識的にを問わず、正規化を理解して設計に生かしているものです。

メンバーが揃わない

仕事が忙しくなるにつれ、残業が増えていきます。そのうち遅刻するのが当たり前になってしまうメンバー、体調不良で休むメンバーが出てきます。結果的には、朝ふつうに来て、夜は常識的な時間で帰宅しているプロジェクトメンバーと総労働で大差がなくなります。こうなってくると朝のほうがサーバーの負荷が少ないためレスポンスが良く、作業が効率的になるように感じますがどうでしょうか？特にプロマネやチームリーダーがこの状態に陥ると「夕方の指示」が当たり前になってきて、普通に来ているメンバーの工数を無駄にする傾向が出てくるように感じます。順調に進んでいるプロジェクトでは経験的には大した残業は発生しないものです。

JAVAの基本だけは押さえよう

　これは言い換えれば「Classの概念をしっかり理解しよう」ということです。Classがきっちり理解していなければ、何本C++やJAVAのプログラムを設計しようが力は付きません。これはVBを始めとする他の言語にも言える話、Classを関数あるいは共通INCLUDEで定義された共通サブルーチンや定数に置き換えて考えて見る習慣を付けて欲しいと思います。
　実はサブルーチンなり機能分割を考える上で幾つかの理屈というか理論があるのですが、これは後で触れるとして、設計の立場、要件定義の立場であってもかる～くJAVAには触れておきましょう。
　Javaの入門書は数多くありますので、これの基本の部分だけを繰り返して理解していくプロセスは他の言語にも応用のきく、優れたトレーニングです。そして最初の難関がクラスの概念の理解なんです。これをやっておくと後でこの重要性に気がつくと思いますよ。Javaの専門家にならない人でもJAVAに一度は触れておきましょう。