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

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

詳細設計・プログラミングは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環境に慣れる意味でも。

成果物の考え方

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