モジュール内強度、モジュール間結合度

１つのモジュールは１つの機能で組み立てられていなければならず、かつ出入り口は１つでなければならないという趣旨のプログラム設計理論です。現在多くの開発を経験してますが、なかなかこの点が一般では理解されていません。むしろ汎用機全盛期にはこの考え方がきちんと採用されていたように感じています。
是非皆さん勉強してくださいね。

※只今家族が病気のため更新が滞ってます。メルマガも出せていません。お詫びいたします。

メソッドの話を前にしましたが

日本人の国民性というのでしょうか、例えば「習うより慣れろ」とか「人の技を盗め」といった
メンタリティーで仕事を覚えていくというのは以前からそう変わっていないように思います。
これは職人を育てていくにはある意味合理的なのですが、大量に人を育てるときは、それも
「極める」ではなく「一定の水準」に育てるにはどうしてもメソッドが必要になってきます。
以前、プロジェクトＸという番組があり、東京オリンピックの食事のプロジェクトで大量の料理人を
育成する必要に迫られたとき、帝国ホテルの料理長がすべてのレシピを公開したことが
番組になってました。当時の料理界ではおよそ考えられないことなんですよね。
ところが今でも多くの業界でかなりマニュアルは整備されたとはいえ、メンタリティーが
追いついてないと思います。われわれのソフト業界でもおそらく同じに感じてます。

帰納と演繹

まず、Wikiか何かで「帰納」と「演繹」という言葉を調べて見てください。
おそらは検索エンジンにWikiに限らず、引っかかると思います。
まず、これが我々のコンピュータソフト開発の基本理論です。
一般事象すなわち業務を抽象化＝モデルに置き換えること、
このモデルが実際の業務遂行に当たり、適用できるかを検証し、
その上で実際のプログラムとして実現できるわけです。
失敗しているシステムの特徴としてプログラム中に多くの例外条件や
エラー条件がハードコーディングされています。
これはメンテナンスの障害となるとともに入力エラーチェックとの
不整合に起因するデータ不整合や異常終了の原因にもなりえます。
ERPであろうがなかろうが、モデル化は不可欠な考え方です。

SEになるメソッド

これはコンサルでもPGでもそうですけれど、存在していないと思います。
小難しい理論やコンピュータ言語の教育はありますけれど。
どの工程に従事していても帰納と演繹の繰り返しなんですよね。
でも、これを行えるようになるメソッドを教育している会社とかは
正直知らないです。
一般的な事象からモデルが作れるようにならないと、
なかなか難しいですよ。

更新が遅れて申し訳ありません

家族が病気でその看病のため多忙で更新が遅れてしまいました。
今週末当たりからぼちぼちはじめて行きたいと思います。
しばし、お待ちをm(_ _)m

SAP CRMとABAPのメルマガも週末には出しますので･･･。

SAP CRM情報発信！

４月２２日(日)にメルマガを発行します。SAP CRMのアドオン開発のメルマガです。
よろしかったら是非登録してくださいね。よろしくお願いします。
ご登録はSAP Chipsまたはhttp://www.melma.com/backnumber_167838/

データの項目と流れを

まだ文章として固まっていないけれど、こんな感じでしょうか。

データ→ヘッダーと明細がある。
　　　　　マスターとトランザクション（取引）データがある。
　　　　　明細に対してサマリーデータがある。

一度もERPの仕事をしたことがない人はもし機会があったらチャレンジすると面白いと思います。
上記がどう実現されているのか。それはゼロから開発するときにきっと役に立ちます。ERPだけ
やっている人はDB設計のイロハから一度勉強する必要があるかもしれません。

うまくまとまんないですが。

設計書のレビュー

システム開発において設計書のレビューは重要である、ということに異論を差し挟む人はあまりいないように思います。でも効果的なレビューが実際行われているのでしょうか。よくユーザレビューは行われますが、私は上流工程の成果物を下流工程の担当者がレビューするプロセスがあっても良いのではないかと思います。要件定義書を見て基本設計書を書くのはユーザではありません。基本設計書を見て詳細設計書を書くのは？やはりユーザではないんですよね。詳細設計書を見てプログラムを書くのは？つまり次工程に回したときの疑問点がないようにそのドキュメントの情報だけで次工程が成立しうるかという問題があるように思います。下流工程ほど若い担当者になる傾向があるのでなかなか難しいですけれどね。でも以前も話ましたが、コンピュータの上で実行されるのはパワーポイントのドキュメントではなくプログラムであるということは何度も繰り返し申し上げたいことです。

メルマガ発行しま～す

タイトルはABAP通信、SAP Chipsかhttp://www.melma.com/backnumber_167719/でお願いします。第１号の発行は次の日曜日4/8を予定です。最新号のみの公開ですが、バックナンバーは５号毎にPDFでダウンロードできるようにする予定です。

メルマガを発行する予定です

SAPはERPのデファクトスタンダードと言っても過言ではありません。私はこの仕事に長く関って来ました。一方でSAPの資料は非常に少ないのも事実、特に英語圏ではない我々には欧米以上に乏しい情報しかありません。私の経験をメールマガジンでシェアできればと思います。現在、審査中のためいつとはお約束できませんが、審査が通り次第、このBLOGで告知するとともにSAP　Chipsというホームページに購読の登録フォームを用意いたします。

創刊の折には是非ご購読いただければと思います。はなはだ力不足かもしれませんが、できるだけのことはしてみますので。

今、サンプルコーディングとか書いてます

なかなか更新が遅れがちですいません。今、CRMのサンプルコーディングを自分のホームページにアップするべく奮闘中なんですが、なかなか時間がとれなくてすいません。ここも数日間、お留守にしちゃいました。英語で発信もしたいから記事を英文で書いたりね。慣れないことはするものじゃぁないですね（笑)　これから先ソフト業界にインパクトとなるのは工場労働者で問題となっている「偽装派遣」「偽装請負」の問題が飛び火してくることです。まだどういう形になるか見えませんが、要注意のトピックですよ。特にフリーエンジニア＝個人事業主の人は身の振り方も考えないといけない事態に発展するかもしれません。

昼は昼飯を食べる時間です

だらだらとした会議をやって何も決まらないってことは少なくないですよね。
昼休みになってもいつまでも端末に向かっている人もいたりします。
でもちゃんと休まないとかえって効率が悪くなるだけだと思うんですよね。
もちろんキリの良いところまで仕上げとくって目的なら良いと思いますが。
私の場合、メモを付箋に書いてキーボードやディスプレイのところに
貼っておきます。思いついたことやら中断した作業の再開箇所とか･･･。
こうすることで思考の中断を最小限にできますよ。

だらだら仕事するのだけはやめましょうよ。オンとオフのメリハリがしっかり
つけましょう。

次工程はお客様

「次工程はお客様」という言葉を知っているでしょうか。要件定義をしたらＳＥに丸投げ、設計したらＰＧに丸投げ、社内外の力関係で理不尽な要求を下流工程に押し付けてないでしょうか？ＰＧはＰＧで単体テストをしたらＳＥに丸投げ、ＳＥは結合テストをしたら、コンサルに丸投げ、何か手落ちがあっても「そんなことは言われてない」とか「言われたとおりに仕上げただけだ」で押し切ってませんか？もし、自分の次がお客様だったら、そんなやり方で済まされるでしょうか？そして要件定義書～運用テスト結果まで成果物は全て納品されるのが原則だとするならば･･･。

技術屋の心を学ぶ

日本の製造業の強さは下請けの優秀さにあったという話があります。そして昨今の製造拠点の海外移転やさらなるコストダウンで苦しんでいる町工場は数多くあると思います。そして町工場の実情というのはなかなか私たちの目に触れ、耳にする機会も少ないでしょう。でも彼らの「思い」こそ物作りの原点なのだろうと思います。マイナーな作家ですが小関智弘氏は旋盤工でありながら小説家・詩人としての著作があり、そうした現場の空気を感じさせてくれる数少ない証人の一人です。
我々システム屋は相変わらずの人手不足、以前に比べて厳しくなったとはいえまだまだその品質や姿勢を問われることは少ないように思います。であるがゆえにこうした物作りの人たちから学べることが少なからずあるように思います。システムは芸術品ではなく一品もので作られる工業製品に似ているところがあります。また例えプレハブ住宅であっても施工業者次第で出来不出来があります。
技術屋のマインドを学ぶことがまず言語を覚え手法を覚える前にあってしかるべきだと思うのです。

データフローダイアグラム

皆さんはデータフローダイアグラムをご存知でしょうか。汎用機全盛期のときにはかなり有効性があるといわれた手法です。データの流れと機能を中心に記述する方法です。まずこの手法を覚えると要件定義フェーズはスムーズにいくと思います。また他人の書いたわかりづらい要件定義書をこれをメモ書きして分解していくと理解が早く進みます。現在はオブジェクト指向ですので古臭く感じるかもしれませんが、コンピュータ処理はイベントとプロシージャー（手続き）の組み合わせです。そして正規化をしっかりマスターすることです。失敗プロジェクトに万が一参加してしまっても自分ならこう設計するのに、という仮説を常に立てる習慣が必要です。そうすると力がつきますよ。

ＳＥの休日

このブログを読んでいる人はさぞかし仕事ばかりしているように見えるかもしれません。そして休日は自宅でお勉強・・・。実は何もしてませーん（笑）というかフィットネスクラブに通っています。岩盤浴でもマッサージでもなんでもいいんですが、ボディとメンタルのメンテナンスしていないと、特にこの仕事は「おかしく」なっちゃいます。酒も悪くはないですが、酒に頼って眠る習慣とかは絶対つけてはだめです。体壊しますよ。没頭できる趣味があればそれにこしたことはないのでドライブでもテニスでもゴルフでもカラオケでもバンドでもなんでもしたら良いのですが、もし無趣味だったらフィットネスに通うといいです。　
　なかには自宅サーバまで立ち上げて家でもコンピュータをいじくり倒している人がいますが、楽しいから続くのであって無理したら続かないです。勉強する時間は確保しつつも発散し気分転換する日を必ず確保したほうが良いと思います。

昼寝の効用

皆さんはお昼休みはどう過ごしているでしょうか？弁当を食べながら仕事をしている人もいるでしょうし、同僚や上司・部下と食事したり色々でしょう。もし可能ならば10分くらいの昼寝を取ると疲れも取れますし、午後の仕事の効率も上がります。寝すぎはいけないのですが、短い睡眠は非常に効果のある方法ですよ。ただ客先に常駐してたりすると周りの目がありますよねぇ。こうした根拠のあることが認めてもらえるようになると良いのですけど。

海外サイトは難しくない

　英語というと敬遠する方が少なくありません。しかし特にプログラミングの情報、サンプルコードを探す場合はそれほど高いハードルではありませんよ。というのもコーディング自体を読むことは可能です。単語の断片的な解釈はできますよね。ですからコーディングと知っている単語を手がかりにそれが何を意味しているかを理解することはさほど難しいようには思えません。精神論は個人的には好きではないのですがようは「やる気」なんですよね。
　人に教わることはもちろん大切ですが、自分で調べていくことはよりスキルが強く根付きます。私自身行き詰ったとき、誰も現場でそのやり方を知らないとき、海外サイトを様々な検索ワードで探します。たいてい見つかるものですよ。見つからなくても代案を思いついたりするから不思議なものです。

ERPの功罪

　ＥＲＰの出現によってシステム開発の有り様は大きく変わりました。半完成品のパッケージソフトに必要なシステム設定（膨大なパラメータを与える）を行い、さらに追加機能があれば付属の開発ツール用いあるいは外部とのインターフェイス機能に別の開発ツールでプログラムを作成するという、１０年以上前は珍しかった開発が当たり前のように行われるようになりました。
　ここで生じるメリットなんといってもエラーデータがパッケージの中に入りこまないため一定のデータの精度が確保されることなんだと思います。プログラムとデータどちらが大切かといえばデータです。極論すれば、仮にプログラムを消失してもまた作れば良いのですが、データはその時点でしか取得できなかったり重要な取引情報であったりすることが少なくないからです。
　一方で促成栽培のコンサルタントが増加し、かつ彼ら彼女らがシステム開発の主導権を握ってしまうことです。一番おそろしく感じるのは技術的な裏づけのないまま追加機能の仕様を決めてしまい、おそろしく複雑なプログラムが出来上がることは珍しくありません。彼らの多くは残念ながらプログラミング理論や開発言語の特性を知らないのです。いくらでも代案が用意できたのにと悔しい思いをすることはコンサルタントの資格の無い私にはよくあります。従って、追加機能が整理されず全くＥＲＰの利点が生かされないシステムになることもあります。ＥＲＰの特性と開発に習熟した中間的立場の技術者の育成と評価の向上は不可欠だと私は感じることがよくあります。

ＳＥＯ対策あるいはＷｅｂ

　団塊世代の大量退職を目前にし、今後の基幹系システムをどう維持するのか、あるいは再構築していくのかというのはなかなか難しい問題です。この問題は取りあえず目をつぶるとすると、一応の基幹系の再構築は一巡したのかなぁとＥＲＰの世界を見ていると感じます。もちろん今後もＥＲＰを選択するかしないかに拘わらず基幹系システムの開発はあるでしょう。しかし、一応の再構築を成し遂げた会社はおそらくＷｅｂによる集客や広告・マーケティングに力を入れてくるように感じます。私はＷｅｂは専門外ですが段々そうも言ってられなくなるでしょう。正しいタグでＨＴＭＬを作成できる人材がひょっとすると再評価されはじめるかもしれません。それとＪａｖａ、ＡＳＰ、ＣＧＩと様々なＷｅｂプログラミングがありますがこれとの絡みも出てくるに違いないと見ています。
　なかなか私自身も時間が取れないのですが、正しいタグでＨＴＭＬからホームページを作成する、そして以前も話ましたがMobable Typeでブログを作る。さらにはブログそのものを自分でレンタルサーバー上で作成してみるという勉強はしておいたほうが良いのかもしれませんね。

数学を少しだけ

ＳＥというと数学的知識が要求されると考える人も少なくないかもしれませんが、実際に事務処理＝アプリケーションソフトにおいてはほとんど要求されません。これはアプリケーションＳＥの人なら分かるでしょう。でも論理回路と集合論については学習しておいたほうが良いと思います。
　スイッチ理論とも呼ばれる論理回路は例えば論理積や論理和などの概念が学べます。これをコンピュータ言語に置き換えるとIF文やCASE文でありテストパターンの設計にも応用が利きます。
　集合論ですがこれはいわばリレーショナルＤＢに応用が利きます。WHERE条件の無いSELECT文が全体集合だと考えて見るとイメージしやすいんじゃないでしょうか。
　もっとも厳密にはリレーショナルＤＢの理論は集合論とは少し違うようなのですが。いずれにせよ真と偽で構成されるブール代数の考え方と対応します。
　微分積分のような複雑な計算や数学的素養は初歩を学ぶうえでは必要ないので数学の入門書などを読んでみるとプログラムやプログラム設計というものが見えてくると思います。

ドキュメントの重要性

　年配のエンジニアと話をすると決まってこんな話になります。かつては自腹を切ってシステムの参考書をプログラミング言語の開発書を買い、一生懸命勉強したものだと。要件定義・基本設計・詳細設計・プログラミング・単体テスト・結合テスト・統合テスト・運用テストと書いてみると詳細設計は単体テストで検証され、結合テストでモジュール間の連携が試されます。基本設計は統合テストで検証され、要件定義は運用テストで検証されるというのはかつては常識だったのですが･･･。このことを知っていればドキュメントの重要性がすごく良く分るはずなんです。
　残念ながら今は一つ一つ教えてやらないとだめなんですね。そして教えたことを覚えようともしない感じがしてなりません。ほっておいても伸びる人、一生懸命指導しても全然な人、そして背中を押してやれば伸びる人、３タイプいると思うのですが、「背中を押してやれば伸びる人」が減ってきていると思うのです。昔は良かったなんていうと年寄りだと言われそうですが（苦笑）

それはないよ（苦笑）

プロジェクトの設計者から今日言われました。「仕様のわからないところをまとめておいて、何が仕様で分らないのか僕も分らないから」つまり質問してもこの設計者から回答は得られず、しかも何が仕様として不明確な自分自身でもお分かりになっていないという恐ろしい事態になってしまっています。過去、何度も現在の問題点をまとめて提出するよう求められているにも拘わらず何１つ先に進んでいないという極めて困った状況です。でも以外とこういう方は多いんですよね。かくして課題だけ積み上がり･･･。

簿記の学習

アプリケーションＳＥには簿記が必要だと前に以前書きました。簿記は例えば商業高校や大学の商学部を出た人にはなじみがありますが、一般的にはとっつきにく代物です。まず日商３級からじっくり勉強しましょう。とはいっても買うのは問題集１冊ぽっきりです。これを理解できるまで繰り返しましょう。浮気はダメですよ（笑）。１日３０分程度取り組めば、このレベルなら十分理解できるはずです。経験上３回ほど繰り返せば合格できると思いますが責任は取れませんので(^^;)　がんばってくださいね(^^)v

クリーンデータを投入せよ

夜間バッチ処理の処理結果を毎朝運用担当者が確認するのは一応正しいと思います。しかし夜間バッチの処理が終了した段階で初めてエラーデータが混在していることが判明するようなプログラムが組み込まれており、実際にエラーデータが夜間バッチを流れてしまうとするならば、翌朝あるいは発覚した時点の深夜あるいは早朝からの対処が要求されてしまいます。これを防ぐ設計が最低限運用を考慮した設計と言えると思います。そして理想的には何度でも再処理が可能であることが理想的と言えるのではないでしょうか。実際、会計システムでは一度転記された仕訳は消去は会計制度上できないので１００％の再処理可能なシステム作りは無理としても転記直前データまでは完全に再処理できること、転記結果が一覧できることは必須でしょう。そしてクリーンデータが保証されるよう入力側のプログラムでしっかりとしたエラーチェックが実装されていなければなりません。「何を当たり前なことを言っているんだ」と言う人もいますが、実際、こうしたことができていない失敗？システムは意外と多いものです。

英語は必須

コンピュータソフトの多くは海外、とりわけアメリカで開発されたものが多いですよね。SAP R3はドイツですが。海外のサイトを検索してみてください。英語のサイトには多くの技術情報や情報交換がなされています。母国語が別言語でもヨーロッパをはじめ多くの国の人が英語を媒介として情報交換をしています。ところがこうしたサイトには日本人はほとんどいうか皆無です。私も一時、海外の掲示板で少しだけ書き込みをしてましたが、しゃべれなくても良いから英語の読み書きができることは非常に差別化になります。なぜなら人より情報が早いのですから。英語の学習教材は多く出ていますから（そして安いもので十分だと個人的に思います）、１日15分位で良いから勉強されることをお薦めします。

フリーランスとして活躍するには

フリーランスのエンジニアはソフト業界にはかなりいます。スーパーエンジニアは別としてそれほど魅力的な報酬が出るわけではありませんが、しがらみの少ない世界ではあります。おそらくは仕事をどのポジションでも出来ることが条件的には有利でしょうか。建築士として設計ができ、かつ現場で施工ができる大工さん（本当にいるか知りませんが）をイメージすると分りやすいかと思います。設計のみ、コンサルタントのみとなると力があれば話は別かもしれませんが、段々仕事が先細りしていくように私には見えてしまいます。プログラミングが出来ること、それでいて基本設計からでもＯＫなこと、これだと仕事はなかなか切れないようです。コンピュータソフトでは運用担当者と開発者が明確に別れていますが、できる限り運用も経験したほうがいいですよ。保守・運用に携わるとどんな設計をしたらいけないかが、見えてきます。しかし開発経験がないと見えてこないんですよね。こんなもんだで終わってしまうことがないよう色々経験できると良いんですよね。そういう意味では転職も悪くないと思いますよ。

詳細設計・プログラミングはINPUTから

過去の記事においてOUTPUTから設計を開始することが大切であると述べましたが、下流工程に入ると事情は変わります。INPUT側から製作を開始するべきです。詳細設計・プログラミングは全てINPUT側から行います。これはデータ設計の矛盾を早期に発見するためとOUTPUT側のテストの際、これらをテストデータ作成ツールとして利用できるため、開発効率があがること、テストツールとして利用される結果早期のバグ発見、OUTPUT側との仕様の矛盾の早期発見が可能になります。このことによりデータ精度が担保されることとなり信頼性の高いシステムが構築されることになります。基本設計はOUTPUT側からはじめ、詳細設計はINPUT側から始める、これが鉄則だと思います。従って、基本設計が終わらない限り、下流工程には入ってはいけない理由が分るかと思います。

システムをゼロから作る時代は終わった？

ERPソフトの普及は目覚しいものがありますが、ここにきて一巡はしたのかなぁとは感じますが、この市場はまだまだ少しずつ伸びていくと思います。かつてはシステムは全てゼロから作るのが普通でした。ERPはいわば半完成品です。基本動作・基本機能が一応は保証されており、これを軸に追加機能を構築していくというスタイルをとるのが広く行われるようになりました。上手にやればゼロから作るよりも安くて信頼性が高いものが作られると考えられています。その際、気をつけたいことはアウトプットを得るにはパッケージのどのテーブルから値が取得できるのかを考えることです。よく分からないまま構築しているとどんどんテーブルを追加してしまい、ERP本体と更新タイミングがずれるなど同期が取れなくなってくる恐れがあります。当然追加開発の部分はベンダーはサポートしてくれないわけであって、注意を要します。経験の豊富なコンサルタントはどのテーブルから何を取れば良いのか熟知しています。しかし実力の無いコンサルタントはただ「こうして」とプログラマーや設計者に丸投げする放置プレイも少なくありません。下流工程担当者が優秀であればコンサルタントの技量をカバーして余りある成果をあげる人もいますが、絶望的な結果になることも少なくありません。かくしてERPのメリットを生かせないシステムが作られます。こうした事例は少なからずあるように思えてなりません。

簿記２級をとろう

私のブログの読者はアプリケーションエンジニアを想定しています。アプリケーションエンジニアはネットワークや基盤系のエンジニアと異なり深くOSやらネットワークについての理解は要求されません。もちろんこうしたことに造詣の深いスーパーエンジニアであれば言うことないのですが、私も含めてそんなすごい人にはなかなかなれないでしょう。スキルと呼ばれるものは仕事を通じて身につくものが圧倒的に多いと思います。そうした意味では私たちのようなアプリケーションエンジニアがサーバのOSをインストール・設定し、ルーターやら通信機器を設定をし、ログインユーザの管理をし、ネットワークの監視をするということは、まず無いと思います。それではアプリケーションエンジニアの武器・強みはなんでしょう。それはユーザの業務にいかに精通しているかなんだと思います。しかし、まずその基本は簿記です。企業に対応するとなると最低日商２級のレベルが欲しいところです。簿記を理解したうえで実際の業務を構築すると、もちろん教科書と実務には相違点は少なくないのですが、システム全体が見えてくるようになります。簿記が全く分からない人間が会計システムの導入や運用に携わっている例を少なからず目にするにつけ、薄ら寒い思いをするのは私だけでしょうか。

UNIXあるいはWebを覚えるために２

このトピックは私もまだ実践していませんが、将来レンタルサーバーを利用しMovable Typeのブログをテンプレートから構築してみたいなぁと考えています。いきなりLinuxに飛びつき自宅サーバという手もありますが、なかなか大変です。余っているPCがあり余力のある人はいきなりやっても良いかもしれませんが。Windowsに慣れきっているとLinuxはコンピュータ屋でもとっつきにくい代物です。私も以前挑戦しましたが、インストールが成功するまでが大変でした。最近のLinuxはそうでもないのかもしれませんが。しかしLinuxをインストールして何をするのかというと困ってしまいませんか？

UNIXあるいはWebを覚えるために

私の専門はクライアントサーバーシステムです。しかし今後Webは避けて通れないはずです。Webが専門外の人はまずはホームページを作ってみましょう。当初はプロバイダーからスペースを借りることで十分ですが、CGIが設置可能なことが最低条件です。そして_JavaScriptやPerlを駆使してインタラクティブなホームページを作ってみましょう。そしてFTPを使用して時々更新をしてみましょう。　段々とWebがどのようなものかなんとなくですが分かってきます。可能ならTelNetログインも認めているスペースが借りられるとベストですね。以前、こうして勉強を私はしたことがあります。今はJava ServletやPHPでの構築が主流なのでしょうけれども、ほんの少しで良いのでかじってみると良いかもしれません。それと一緒にブログもつけてみましょう。今のWeb環境に慣れる意味でも。

成果物の考え方

システム開発プロジェクトを進めるに従い、数多くのドキュメントが作成されます。プログラムとともにこれらのドキュメント類を成果物と総称するのですが、その代表的なものが要件定義書・基本設計書・詳細設計書の３つだと思います。もちろん運用手順書やテスト仕様・テスト結果なども重要ですが、とりあえずこの３つに絞って話そうと思います。まず要件定義書と呼ぶに値するものは、ユーザの業務が定義されていること、このうちコンピュータ化される部分が明確に分かること。このコンピュータ化される部分を読めば当該機能の基本設計書が作成できることが条件です。基本設計書は少なくとも処理概要と入出力デザインと入出力の項目定義が最低必要だろうと思います。そして基本設計書が全て揃った上で詳細設計書に着手するのが理想です。なぜならば共通機能の導出をここで行いたいからです。そして基本設計書を見れば詳細設計書が必ず作成できることが必須です。詳細設計書は間違いなくこのドキュメントを見ればプログラムが作成できることこれが理想です。なかなか私も理想通りのものは作れないですし、作らせてもらえないことも少なくありませんが、設計書はかくありたいです。

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

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

企業コンプライアンス

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

生産性における問題

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

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

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

このテーブルはどっち？

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

メンバーが揃わない

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

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

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

工数をドブに捨てる奴

貴方のプロジェクトにこんな人はいないかな。作業指示を夕方にする人。これはたいてい×！もちろん作業タイミングを見て夕方になることはあります。でも、朝なんら状況を確認することなく作業を進めさせ、夕方になってからプログラムなり設計なりの変更指示をする人。こうなるとその日１日の作業が最悪全てやり直しになります。打ち合わせの関係でどうしても夕方に方針なり仕様変更が出てくる恐れがある場合、極力その可能性を早めに伝えてくれるリーダーやコンサルタントはある程度信頼できます。こちらもその心づもりで、修正がしやすいようにあるいはそこの作業を飛ばして別の作業をするなり、技術的なウラを予めとっておくなりできるからです。これは週単位、月単位でも同じです。行き当たりばったりの上長の下にはつきたくないもの。膨大な無駄工数が消費されていきますから。

OUTPUTが決まればINPUTが決まる

システム作りの基本は「OUTPUTが決まればINPUTが決まる」。これに尽きると思います。クライアントがどんなOUTPUTが欲しいのかを項目（コードやテキストの桁数も含めて）まず決めてしまうことです。もちろん、後から追加項目は出てくるでしょう。でも、何がいつのタイミングで欲しいのか即時？随時？日時？月次？半期？･･･。とにかく必要なレポートの顔ぶれを全て揃えてしまうことです。各レポート毎に正規化を試みます。自ずからテーブル構造が見えてきます。これでデータベースの論理設計はある程度完成してしまいますよね。それから、そのデータはいつのタイミングで入手されるのかが決まってきます。そうすればINPUTの設計が自然に出来上がるはず。実際、なかなかスムーズには行きませんが、とにかくOUTPUTを決める重要性を強調したいと思います。

仕様が決まらない

　今、参加しているプロジェクトでは困った問題が発生しています。それは全く仕様が決まらないままカットオーバーまで余すところ数ヶ月をきってしまっている状態です。しかもこんな時間にブログを書いている位だから残業もない。やらねばならない課題が山積しているにも拘わらず何も決定していないんです。残念ながら発言する立場にいないため何も言えないのですが、このプロジェクトの中心メンバーに自分達が非常にまずいことをしているという自覚が全く無いのでは？というシーンによく遭遇します。突っ込んだ仕様の質問に対し全く返答ができず全部ペンディング事項にしてしまうんですよね。かくして時間だけが過ぎていく。プログラムはほとんど全て７～８割方完成しているのですが、そこから先、全く進まないために１つも単体テストが完了していないという恐ろしい状態です。開発手法はスパイラル・モデルだからこれで良いんだという言い方をプロジェクトマネージャーはしています。スパイラルモデルの定義を述べよと言われると私も答えに窮しますが、明らかにこれはスパイラルではなく、開発手法についての無理解が原因です。

プログラムを知らない

　特にERPの世界で顕著なのは全くプログラミングを知らない人がこともあろうにプログラム設計をしている例がかなり見受けられます。プログラミング言語の特性を知り、どこまでなら仕様として盛り込めるのか、どのように将来のメンテナンスを考慮したプログラムのモジュール分割を行うかといった配慮が全くなされないことは珍しくありません。　
　結果、ユーザーインターフェースの使い勝手の向上によりやれることが増えた分、コーディングステップ数がただでさえ肥大傾向にあるのに無茶な仕様は考慮を欠いた設計により作った人間以外には理解困難な巨大なプログラムが出来上がります。
　共通機能をクラス化、サブプログラム化をしてないばかりに将来においてメンテナンスが行われたときに、思わぬ矛盾や潜在バグが健在する恐れがあるのです。　このブログではこうしたソフト開発にまつわる問題点を私なりの視点から独断も交えて指摘するとともに、一人一人のエンジニアが育つためにはどのような処方箋があるのか私なりに考えて行くつもりです。

熟練工がいない

ソフトウエア業界には熟練工はあんまりみかけないです。業界が若いせいもありますが、一般的にはプログラマー→システム・エンジニアorERPコンサルというキャリアパスを経て30代後半にはプロジェクトマネージャー、40代には管理職、いわゆるシステム開発のベテランがフリーエンジニアを除いてあまり見当たらない世界なんです。 例えば建築業界なら大工として左官として腕を磨いていく、設計するのはゼネコンでも施工するのはこうした職人達で技術の継承がなされるとともに役割がきちっと定まっている。逆をいえばコンピュータ業界では下手をすると素人に毛が生えた程度の人間がシステムを設計し、開発しているかもしれない、という怖さがあります。 コンピュータプロジェクトがうまくいかない、完成したものの運用に苦労するのは、まずこうしたところに問題があるのだろうと感じています。