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

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