アイロベックスメールマガジン　携帯版

当社も2009年度の新卒採用のページを公開しました。
2007年11月なのに、再来年の4月の入社を考えなくてはいけないのですから、システム開発の長さどころではありません。

学生さんには、プログラマと言っても、システムエンジニアと言っても、職種名ではピンとこない人が多いものです。
これは、特に当社が理系、文系問わずに募集しているせいかもしれませんが。

プログラマを2、3年やった後、システムエンジニアになる。

私が二十数年前に、この業界に就職してから、ずっと続いている育成方法です。

実際のところ、プログラマの「ものの考え方」、つまり、「視点の域」、「とことん細かく例外を考えること」
といった感性を理解できることが、SEとしては、かなり重要だと思っています。
プログラミング技術ではなくて、プログラマの感性を理解してほしいと思っています。

さて、これから数回に掛けて、システムエンジニアを目指しているプログラマ、そして、SEの若手に向けて、基本中の基本の考え方について紹介したいと思います。

今回は、その1「日時」についてです。

最近のシステム開発は、分析系システムであったり、ECサイト系の開発が多いのでしょうから、日時というのは、常に、リアルタイムの年月日、時刻を意味することが多いのでしょう。

そんなシステムばかり組んでしまうと、会計システムや販売管理システムといった、基幹業務の年月日についての感性が、育たなくなってしまうことが少し心配です。

そこで、知識だけでも、「日時」について考えてみたいと思います。
本当に初心者向けの当たり前のことばかりですので、キャリアが3、4年以上ある方は、読み飛ばしてください。

●日時には、今、そのとき、その瞬間という意味と、過去のある日時を意味する場合がある。

例えば、Aイベントホールの座席表を考えてみましょう。
予約受付システムを請け負った貴方が考える予約済の座席数、これは、お客様や担当者が画面照会したその瞬間、つまり、今現在です。

1秒後には数が違う可能性があります。

一方、あるイベントは、11月15日受付分までを
先行予約分として、チケット料を10パーセント値引きすると宣言していた場合はどうでしょうか。

この場合、予約済数が分かるだけでなく、値引き販売数もシステムで把握する必要があります。
例えば、11月26日昼13時現在の予約済数が623名で、11月15日までの受付分は、324名であるという、過去のある時点までの集計値をとっておく必要があるわけです。

もちろん、ハードやデータベースの性能が十分にある場合は、集計値をデータベースに項目として持つ必要はなく、クエリで、日付範囲指定で集計すれば大丈夫ということもあるでしょう。

しかし、次の場合はどうでしょうか。

B社では経営会議が毎月開かれています。
営業の月間成績表は、翌月3日には集計され、その表を基に5日に経営会議が行われます。

項目として、月間受注金額、（半期）累計受注金額、受注残金額が載っています。

Cさんの10月の営業成績は、【月間受注金額1,600万円】・【（半期）累計受注金額1,600万円(10月は半期の初めの月です）】・【受注残金額 4,300万円】であったとします。

11月は、【11月30日までの新規受注金額700万円】・【受注から売上になった金額2,300万円】ありました。

ところが、10月に受注した案件でトラブルがあり【400万円が受注取り消し】となってしまいました。

しかし、【12月2日付け新規受注金額3,200万円】取ることができました。

さてCさんの12月3日に出した営業成績表はどうなるでしょうか。

答え→【月間受注金額300万円 (700-400)】・【（半期）累計受注金額1,900万円】・【受注残金額2,300万円】

ここで注意すべき点は2つ。

11月の帳票でも、10月の訂正分は、マイナスされるということ。
受注残金額といった、一瞬の残を表示するようなものも固定月報に印刷する場合は、11月末日を締として、翌月分の日付の伝票は集計しないということです。

特に、経営会議で検討するような表には、リアルタイム性よりも、月間、月間で積み上げた場合に
正しい合計となるものが求められます。

もちろん、ここで集計のキーとなる日付は、入力年月日ではなくて、伝票年月日（受注伝票であれば、受注年月日）です。

こういった、「伝票」としての業務の集計方法を覚えておきましょう。

そして、これらの数値は、何ヶ月後に見ても、常に同じ値が表示、集計されることが、
ほとんどの場合必要となるのです。

プロジェクトとしてのチーム運営を考える場合、当然、リーダーの資質・覚悟が最も重要であると言えます。
なぜなら、リーダーが目的を見失ってしまったり、本来の責任から逃げてしまったりした場合、チームとしての機能は、うまく働かなくなってしまうからです。

一方、システム開発という仕事の中で、プログラマが次のキャリアアップを目論む場合には、サブSEとして設計に徐々に携わり、SEになっていく、といったことが通常となっていました。

しかし、プログラマとSEの職務の特性には違いがあり、ここに問題が潜んでいると思われます。

なぜならば、プログラマとして優秀な人というのは、どんな要求にも応えられる技術者を意味しているからです。
優秀なプログラマは、難易度が高いプログラムを、人よりもバグが少ない状態で、より速く生産するといったことが可能です。

そのため、孤独な戦いを強いられることが多く、人に説明したり、現状報告をすることよりも、とにかく作ればよい、結果を出せばよいといったことに目的をすり替えてしまう人も多く見られます。

しかし、大規模システムを、破綻無く成功させるためには、どうするか？
という視点で見てみると、こういった優秀なプログラマが居なくとも、また、そういった人の手を借りずとも構築できる仕組みが、圧倒的に望ましいのです。

仕組みに求められるものは、個人としての優秀さよりもむしろ、チームへの貢献度であり、それは、プロジェクト全体としての品質や生産性が安定することなのです。

そこで、プログラマとして技術が高い人は、共通のフレームワークを作ったり、プロジェクト全体のルールが守られているか、といった守り役を仰せ付かることになります。

実はこの役目こそ、先のSEやプロジェクトマネージャーとしての役割に直に結び付いているものとなります。

個人としての優秀な技能を、いかにチーム全体の品質、生産性の底上げのために使うのか、それこそが最も優秀なプログラマの役割となるわけです。

当然、予定外に自らの作業分担をはみ出した作業が発生します。
しかし、どんな場合もプロジェクトマネージャーに相談し、全体の効率、求める結果の優先順位を考えて作業に携わるべきであり、そのためには、個人としての当初の「達成度」や「満足感」を捨てなければならないことも多々あるわけです。

プログラマとして、新しい技術、より難易度の高い技術に挑戦することは、常識であり、当然のことです。
一方、チームとしての成果を求められるプロジェクトに係わっていく以上、その個人のキャリアステップは、どうやってチームに貢献していくか、どうやって全体としての成果を出すのかを考え、実践していくところにあるわけです。

プログラマ、SEといった職業名も、もっと細かく区分けされる時代ですが、実際のところ、役割名があるが故に、その役割名に準じた仕事をするのが自分の仕事だと思ってしまうことが、一番の問題であると私は思っています。

なぜならプロジェクトという視点で考えた場合に、個人が能力を発揮すればそれでよいというやり方では、やはり、成果を出すことは叶いません。
個人個人の積み重ねを、チームとしての成果に繋げるためには、常にチーム全体や「のりしろ」を気遣いながら作業を進めることが、SEだけでなくプログラマにも必要なのです。

読者の方から激励のお便りをいただきました。嬉しいものですね。
その時に、「何かご要望は？」とお聞きしたら、このタイトルがご注文でした。
お題いただきました。・・です。

SEの促成栽培については、このメルマガを書き始めた頃からの、私自身の課題です。
これを語るために、「何が出来たらSEなのか？」ということを、初心に戻って考えようと思いました。

SEの定義は、プログラムを組み合わせて、業務の仕組みを作る人である。

では、「プログラムが得意な人がいいのか」というと、この業界では、何十年も前から、そう思われてきましたが、「そうとも言えない」と私は思っています。

ただ、プログラマに指示をしたり、報告を受けたりすることが作業になりますから、プログラマが「どのようなことを考えているのか」を知り、プログラマの癖を理解していることが、望ましいことになります。

優秀なプログラマは、「もし、例外的なデータが入ってきたらどうなるのか？」「もし、プログラムが起動しているところで電源が落ちたら？」といった、1％の確立でしかありえないようなことでも、「絶対にないこと」でない限り、そのリスクを想定して、プログラムを作るのです。
それが、優秀といわれる所以です。

ですから、彼らの不安を解消してくれるSEが、プログラマにとって、一番頼りになるのです。

例えば、文字型の項目「税フラグ」というものがあるとします。
この「税フラグ」を使用する場合、プログラムには、

1の場合は・・・・。
2の場合は・・・・。

というように、処理を記述します。

仕様書には、この1と2の場合についてのみ、記述されていたとしても、プログラマは、0のとき、NULLのときなど、全てのデータパターンにおいて、正しく動くプログラムを作らなければいけないのです。

NULLである場合が存在するのか、といったことも含めて、そのシステムで発生するデータパターンを、きちんと説明することが非常に重要です。

実際、プログラマにしてみれば、データパターンだけでなく、
・プログラムで用いるレコード件数が、何件を想定しているのか。
・レスポンス（応答時間）はどのくらいまで待つことを許されるのか。
など、説明がなければ、分からないことばかりなのです。

このような一つ一つの背景を、きちんと説明しておかなければ、プログラマに、余分なコーディングをさせることとなり、生産性の悪さにも繋がります。

プログラマが理解していれば、作成をする前から、対処していたものを、説明が足らなかったばかりに、作り終えてから修正しなければいけない、ということさえ、引き起こしてしまうこともあるのです。

ですから、SEは、プログラマからの質問がなくても、また、「仕様書を読んでから質問します」などと言われても、無理やりにでも、

1．誰が、いつ、どこで、そのプログラムを使用するのか。
2．そのプログラムが、システムの中でどのような役目をするのか。
3．データの中身について、どんなパターンが考えられるのか。
逆に、どんなパターンは考えなくてよいのか。
4．データの件数と、求められるレスポンス。

を、丁寧に説明するべきなのです。

そういった意味では、優秀なプログラマは、SEが教えてくれなくても、これらのことを突っ込んで聞くものです。
だから、若手SEは、キャリアのある（優秀な）プログラマと、仕事をするのが良いと思うのです。

●ポイント

SEは、プログラマの不安を解消し、一番最適な技術やアイデアを引き出すために、そのシステムの情報を、正しく伝える責任があります。
プログラムの設計については、プログラマに正確な情報を提供し、お互いの役割を果たせるような、コミュニケーションをとる義務があります。

「難しい」「大変だ」は、“ボケ”の言葉。

なんか、変なことを書きました。
大阪の人は、幼少の頃から、“ボケ”と“ツッコミ”の教育を、知らず知らずのうちに受けているというのは、本当でしょうか。
そういう意味では、頭の回転が速い人が多いような気がします。（気がするだけ・・・）

さて、システム開発をしていて、「これは！」と、頭の中で電球が輝くときがあるのですが、どんなときかというと、プログラマとの会話をしたときです。

前回もお話ししましたように、プログラマというのは、些細なことを、全て網羅して理解していないと気持ちが悪い、というような人たちです。

お客様やSEが、「そんなこと、どちらでもいいのではないか？」と思うようなことを、丁寧に、細かく考えて、プログラミングしてくれるのです。
褒めているのか、けなしてるのかといえば、褒めています。

しかし、そんな彼らも、ときに曖昧な発言をするときがあります。
「たぶん・・・」とか「・・・と思います」とか、「・・・・・・・」
黙ってしまうのもプログラマの特徴なのかもしれません。

こういうとき、SEはこれを“ボケ”だと思って、“ツッコミ”を入れることが要求されるのです。

「それって具体的にどういうこと？」
「どこに書いてあったの？」
「どういう検証をしたの？」
といった事実に落として、聞くことが必要になります。

一番注意すべき、プログラマの言葉は、
「大変なプログラムなんです」
「難しいんです」
といった言葉です。

言葉いじりをするつもりはありませんが、「難しい」って、どういう意味でしょうか？

彼らにとって、これらの言葉は
「仕様が100％理解できていない」
「どういうプログラミングをしたらいいのか、今は判断がつかない」
「プログラムで経験したことがない機能が含まれている」
といった意味なのです。

これをきちんと切り分けて、対策を練ってあげる必要があるのです。

「仕様が100％理解できていない」
この場合は、簡単です。
大きく、全体像をイメージとして分かりやすく話してあげること、これは前回、伝えたような内容です。
それから、細部においては、プログラマの視点に合った、図やデータ事例を見せてあげることが必要でしょう。

初心者の場合には、先輩プログラマを通して伝えてもらうことも必要かもしれません。

「どういうプログラミングをしたらいいのか、今は判断がつかない」
といった場合は、どのような選択肢が考えられるのかを、レビューする必要があります。
これも、SEと上級プログラマ、本人の3者で行うのがよいでしょう。

そして、
「プログラムで経験したことがない機能が含まれている」
これは、自社に経験者がいるのであれば、問題ありません。
経験者からサンプルを貰うこと、経験者を補助につけることが大事です。
こういった場合に、補助なしで、サンプルだけで仕事をさせるのは、リスクが大きくなります。

問題は、自社で経験者がいない場合です。
この場合は、一部機能だけを検証するプログラムを作らせる必要があります。
「やればできる」部分を徹底的に省いて、テストさせるのです。

そして、「難しい」という言葉、これを私は認めません。

プログラムで難しいロジックは不要なのです。

「難しい」は、「組合せが多様である」というように分解するのです。
そして、
「組合せパターンを網羅しての設計ができているか？」
はたまた、パターンではなく、
「方程式といったもので解決ができないのか」
を、考えるべきなのです。

プログラマの「大変だ」「難しい」は“ボケ”の言葉。
SEからの“ツッコミ”を待っている、アラームなのです。

最近は、「画面入力だけ作ってください」といった依頼も増えてきました。

これは、一つには、CSVや、テキストデータを作る仕組みさえ作っておけば、帳票やグラフは、データウェアハウスで、自由に作表した方が良いといった理由があります。

しかし、長年、システム作りをしてきた立場から考えると、「入力」だけのシステムというのは、やはり「何かが足りない」ような気がします。

24時間稼動のシステムも増えてきました。
そして、誰がいつ、どんな情報をインプットし、アウトプットしたのか、を管理する（操作ログ）仕組みも当たり前の時代になりました。

しかし、それがあるからといって、操作ログを頻繁に見るようなことは、現実的ではありません。
操作ログは、膨大な数に上ってしまうからです。

ログについては、いずれお話することとして、今回は「帳票の意味」について、掘り下げてみたいと思います。

システムで帳票を作成する意味は何でしょうか？

1）Excelや、データウェアハウスの扱いに慣れていない人でも作表できる。

2）レイアウトを定型にすることで、膨大な情報の集計から、企業として重要なポイントだけを切り取って表現することが可能となる。

3）情報の入力、チェック、作表、蓄積、消込みといった一連の流れの中で、ある一定のタイミングで情報が集計されることが保証される。

4）誰がいつ、どこで作表しても同じ結果が出る信頼性がある。

この中で重要な視点は、3と4だと思います。
特に、3の「一定のタイミング」ということ。
4の「時を選ばない」ということが、SEが成長する上で欠かせない知識です。

「一定のタイミング」が、どのタイミングなのかは、その帳票を見る人全員が、はっきりと分かっている必要があります。

例えば、国内だけで商品を販売している企業について考えてみましょう。

ここのお店は、ネット通販も行っていて、24時間、在庫の予約が可能であるとします。
しかし、出荷は、宅配業者にお願いしているので、毎日、夕方18時までには終了するとします。

売上を計上する基準というのは、業種・業務によって多少異なりますが、ここでは、最も一般的である「出荷基準」で売上計上している、という前提で考えます。

1日から末日までを集計した、「月間在庫管理表」を作成するとします。
末日を集計するタイミングは、いつが良いのでしょうか？

これが、全国の倉庫・支店で、18時までに出荷が全て終了し、その時点で、出荷入力が全て完了しているということであれば、末日の18時以降に帳票出力ができるはずです。

しかし、出荷入力は倉庫で行うが、最終的に売上承認や、訂正処理を本社で営業が行うということであれば、末日までの集計は、社内の業務ルールとして、翌月の3日、4日の営業終了時間までに、全ての伝票が入力されているということになります。

こういった場合、当然、業務ルールを守れない人や、突発的な業務事故が起こることもあるわけです。
その場合にどう対処するか、といったことも含めて、社内の運用ルールを決めてもらい、更に、システムでは、運用ルールが守られていることを保証する必要があるのです。

例えば、2月29日までの伝票を、3月4日の18時までに全て入力する約束をしたとします。
ここで、帳票を作成したという時点（締）が、システムには必要となるのです。
そして、その時点は全社一律であり、1秒でも遅れた入力や、修正については翌月の帳票に反映させる必要があるのです。

すでに動いている業務をシステム化するという仕事であれば、抽出条件、タイミング、合計の種類など、設計の大部分について、どういうものを作成すれば良いのか、ということを、お客様は、直ぐ答えてくださいます。

現在、役に立っている表、そして、こういうものがあれば便利なのになぁ、といった思いが蓄積してあるからです。

しかし、運用ルールについては、こちらから積極的にヒアリングしない限り、お客様から進んでお話しいただけることは、非常に少ないのです。

月末・期末・締日の慌ただしい中で、どのようにミスを防ぎ、全社的に整合性の取れたものを出力するかといったことは、ヒアリングの中から、SEも一緒に考えることが必要です。

業務ルールとあわせた運用ルール・仕組みを、お客様と確認しながら提供することが求められるのです。

「これはSEの仕事じゃない」と思ってしまえば、抜けてしまうことですが、あれも、これも、SEの仕事なのです。

帳票についていえば、その帳票が、システムの情報の中から「どんな条件」の情報を抜いて集計するものなのかといったことは、明確に提示する必要があります。
また、数多くの運用ミスを防ぐ為の仕組みも必要となります。

データベースの設計をするタイミングは、基本設計書が出来上がってから、と信じ込んでいる若いSEは多いようです。

実際に、システムの全体スケジュールでは、納品は、基本設計書と同じタイミングですしね。

しかし、打ち合わせの途中でも、頭の中に「データモデリング」のイメージは出来上がっており、大体このような設計になるんだろうなぁ、とどのSEも思っているようです。
そして、驚くべきことに、SE同士で話してみれば、このデータベースの設計は、ほとんど一致します。

これには、システム設計の基本パターンというものが存在するからというのが一つの大きな理由でしょう。

詳細なER図を書くまでもなく、テーブル（エンティティ）の名前や、そのエンティティに、どんな項目が登録されるかは、80％以上決まっているのです。

ソフトウェア工学で言えば、エンティティには2つの種類があります。
「マスタ」と「ジャーナル」です。

マスタとは、Master（主人）からきています。
システムを支える情報であり、頻繁に値が変わらないものがマスタとなります。
「社員マスタ」、「得意先マスタ」、「商品マスタ」といったものです。

ジャーナルは、Journal（日記、日誌）の意味で、日々の情報を記録するものです。
「売上ファイル」、「仕入ファイル」、「出勤ファイル」といったものです。
ジャーナルは、昔はトランザクションとも呼ばれていました。

トランザクションは、Transaction（処理、取引)であり、ジャーナルと同じように、日々の取引ファイルを意味していました。（COBOLの索引ファイルでシステムを作っていた頃）

ところが、現在ではRDBを使ったシステムがほとんどで、RDBMSのトランザクション処理と混乱しないように、私はジャーナルと言っています。

実際には、さらに細かく分けて、マスタに3つ、ジャーナルに3つ、種類があると思っています。
一般的な「販売管理　売上・仕入から請求まで」を例に挙げてみます。

●マスタの分類

1)業務で使用するメインマスタ

・社員
・役職
・営業所

この考え方は、どのシステム開発会社でも同じだと思います。

2)常に、どんなシステムにも（システム的理由で）存在するマスタ

・管理
そのシステム全体で、使用する値が1つである場合に、このマスタにセットする。プログラムのConfigと違い、マスタの値を変更するだけで、プログラムに何の影響もなく、システム全体の振る舞いを変えることができる。

例：現在の期、期首、期末日、会社名、代表者名、住所……、消費税率とその期間

・名称
RDBといえども、コードと名前さえあればいい、といったものが多い場合に、1つのテーブル上で、共有して設定しておく。本来のRDB設計の観点からいえば邪道かもしれないが、便利なことが多く、弊害は、ほぼない。

・メニュー
・プログラム名
・メッセージ

3)業務独自でシステム的に必要なマスタ

・帳票定義
・権限
・運用管理
・カレンダー

●ジャーナルの分類

1)業務で使用する主ジャーナル

画面入力、外部連動で最初に作られるジャーナル

・売上
・売上明細
・仕入
・在庫移動

2)システムの難易度を下げるためのジャーナル

・帳票のための駆動表
・月次などの印刷のレスポンスを上げ、過去照会を容易にするための実績集計

3)システムのログを取るためのジャーナル（また、システム的なバグを見える化するために使用する）

・バッチの中間ワーク
・バッチログ
・操作ログ

マスタ、ジャーナル共に 1）は、どのシステム開発会社でも、どのSEでも、考える基本のものとなります。
つまりこれがデータべースの基本です。
しかし、優れたSEは、自分の設計に 2) や 3)も当たり前のように基本パターンを持っているものです。

内容や考え方は、システム会社によって、そしてSEによって、様々なものがあるはずです。
特にジャーナルの 2)システムの難易度を下げるためのジャーナルは、若いSEには思いつかないものが多いはずです。

他の会社でも、同じ会社内でも、他人が設計したシステムでこういうものを見つけたときに「なぜ、何のために、このようなジャーナルを設計しているのか」を考え、真似することをお勧めします。

優れたSEの作るシステムは、データベース設計にそのヒントが隠されているのです。

桜舞い散る4月になりました。当社にも新入社員が登場しました。

わたしがこの業界に入ったのは4月ではなく、8月なのですが、いつも、この時期、新人を迎えると過去のことを懐かしく思い出します。

ちょっとだけ、過去に遡って自分の経験をお話しましょう。

当時、プログラマで職を得たわたしは、プログラマに専念していた3年間を含め、少なくとも5年間はプログラミングをしていました。　

COBOLという“手続き言語”と呼ばれたものが最初に覚えた言語でした。

当時のプログラムは、現在のプログラムと比べてはるかに簡単なことしか実現できないにも関わらず、想像を絶するような「かったるい（面倒な）手順」が要求されました。

一人一台のPCすら無かった頃ですから、プログラミングを行うのは紙と鉛筆でした。

コーディング用紙という、カラムごとに線が引かれた設計用紙にプログラムコードを全部書いていきます。

複写機能を使うことさえできず、紙にひたすら延々とコードを書きつけることが仕事でした。

そのため、プログラミングの作業は長時間を要しました。

しかし、この無駄に思えた長い時間も、今になって思えば良いことでもありました。

当時の自分にとって、一度書いたコードが間違っていたり、後から無駄だと気がつくことは、それこそ天を仰ぐほどつらいことでした。

だからこそ、無駄なコードを書かないため、正常に動作するコードを作るために一生懸命に頭を使ったわけです。

「急がば回れ」それが常にテーマでした。

最終的に無駄にならないコードを書く。

書き出す前に、作り出す前に、どれだけ考えてから走り出すのか。

現代のプログラマは、当然のごとく、PCの画面にプログラミングをパンチすることでプログラミングを行います。

また、ひょっとすると、過去のプログラムを元にして作成することの方が多いかもしれません。

昔は、方法が無かったために、仕方無く紙にコーディングをし、無駄なコードを書くのが嫌なばかりに、頭を使うことを覚えたわたしでした。

しかし、この「先に考える」という力は、とてつもない財産を与えてくれたような気がします。

プログラミングも、設計もプロジェクトマネージメントも、そして文章力もすべて、まずとことん「考える」ことが大事なのだとつくづく思うのです。

考えることも一種の慣れが必要です。

そして、慣れた人は間違いなく成長が速いのです。