I/Oの発想がHOSTのままだった

大規模データをバッチ処理で扱う場合、

１．先にすべて、UNLOADして、テキストファイルで処理

２．すべて、DBで処理

いずれが処理効率がいいのだろうか？

そんな問が会議で出た。

HOST系でじゃかじゃかやってきた身としては、１と思っている。

ただ、オープン系（サーバ系というのがいいのか？）のみを経験している人は２という。

なぜだろうか？

私が考えるに考える上でのバックグラウンドが違うからだろうと思われる。

＜ホストの思考からいうと・・・＞

・サーバの配置は？

　HOSTで考えると、AP、DB、WEBサーバすべて同一筐体で考えている。（HOSTではそういう名前で呼ばないが、オープンに名前を統一している。）そのため、サーバ間のデータのやり取りが思考から外れている。

・データのアクセス

DBによるI/Oに比較し、SAMなどのシーケンスファイルを扱う、IBMのツール類のほうが断然処理速度が速い。DBによるI/Oプラス、プログラム領域へのI/Oを考えると、最初からファイルのほうが効率がいいのだろう。

＜オープンの思考から言うと・・・＞

・サーバの配置について

　バッチと言うよりかオンラントランザクションで考えるケースが多い。そのため、AP、DB、WEBサーバの配置を気にする。サーバ間でのやりとりが極力少なくなるような設計や処理方法を好む傾向あり。（当たり前なんだろうが）

・データのアクセス

　ファイルにすることは処理効率を下げるという人が多い。DBでできることはDBでというのが元々の思想。例えば、データを呼んできて、APサーバで処理させるよりは、PLSQLを書いて、DBサーバ内で処理することで、データ感のI/OやAPサーバでのメモリ消費を下げる、ということを考えるみたいです。

どちらの考えも一理あると思うのだが、大容量のデータを扱う場合っってどうなのだろう？私は経験上、テキストのほうが速いと思ってしまう。キーをしっかりした索引で検索するならDBのほうが速いのでは思うが、１件１件処理をしなければならないケースはテキストのほうが速いのでは？？と思ってしまう。

私自身、経験と知恵が足りないので、下記のサイトなどでしばらく学習・・・。

http://gihyo.jp/admin/serial/01/rdbms

今の開発で実経験ができるといいかなと。

概念モデルの書き方

概念モデルから論理モデルを作成するときに、ER図（概念モデル）を記載し、論理モデルを作ることでシステム構築ができるだろうと思っていた。

ただ、ER図や論理もどれも正解はなく、それぞれの業務とシステムの特性を考えながら選択するというのがいい方法らしい。

よく知られている論理モデル（データモデルといったほうが良いか）は以下の４つのようである。

1. リレーショナルモデル
2. ネットワークデータモデル
3. ハイアラキカルデータモデル（階層型）
4. オブジェクト指向データモデル

それぞれ、結果としては表している意味は同じであるが、表現が異なるだけであり、

それぞれの時代の背景などもあるようである。

ホスト系を中心に今まで見てきたので、論理モデルならあれか、遠い浮かぶのだが、オブジェクト指向に沿った開発だと、先々の開発工程や扱うツールに沿った形でモデルを表現したほうが良いのかとも思っている。

もう少し、データモデルに関して見たり、実際に実装してみる必要がありそう。

※概念データモデル・・・ビジネスの観点で必要な情報の体型をデータモデルとして表現

※論理データモデル・・・特定のデータベースに依存しないデータモデル。業務における意味を反映した項目名や項目に関する説明などを定義。

リレーショナルデータベース入門―データモデル・SQL・管理システム (Information&Computing)

posted with amazlet at 13.09.02

増永 良文
サイエンス社
売り上げランキング: 48,038

Amazon.co.jpで詳細を見る

 

４つの軸でみる

業務定義や要望、現状把握する際に様々なわからない言葉が出てくる。

また、知っている用語でも怪しいな？と思う言葉もある。

会議中にも頭をフル回転させて考えないといけない必要もある。

同期と話していてこれはとおもったのは、

「人」「物」「金」「情報」の視点を持って見ること。

経営やBSCなどで出てくるが、やはりこの視点は必要。

例えば、ものが直送した場合、物の動きとお金の動き、情報の動きが

ばらばらになる可能性が高い。

これを１つずつ腹に落として整理することで現状も把握可能であり、

要望も整理できるのではないかと思い始めている。

要求の獲得

BABOKやシステムアナリスト、超上流など様々な要求定義に関連する知見が増えてきている。

どれも概略として書かれているが、実践的なことはやってみないと、わからないなというのが最近の所感。

確かに、記載されていることは重要なプロセスと思うのだが、時間的制約と能力的な制約。及び、前提条件や現状にあるドキュメント量によって、やるべきことは異なる。

例えば、現状システムや業務を表すものがない場合は、それを補完する資料から作成する必要があるし、ある場合でも、俯瞰する資料がないならば、作成する必要がある。

なぜ、作成するのか。

経験上ではシステム関係者とユーザ及び、経営関係者は、共通の用語・定義で語らせないと行けないからである。それぞれの言語で語られると、意味合いは違うのに、同じ言葉を使ったりしており、後々、「おや？おや？」ともなる。

また、ドキュメントがないと、何について話をすればよいかわからなくなり、それぞれが言いたいことをいって、話が終わるケースもままならない。

ヒアリングであろうとインタビューであろうと、ノープランで望むことはNGであり、現在ある資料の中で、現状とみられることを整理し、課題として捉えられることを想像し、何を聞き出したいかを明確にして望まないと、ユーザは何を話してよいのかわからなくなる。また、要求を引き出すにしても、TVなどのインタビューと同様で、引き出し手が思っていたとおりに展開が進むことはそうない。議論がブレないように、何を軸に話を進めていくのかは事前に準備が必要である。

相手に合わせて資料をつくる

長い時間使われ続けているシステムほど、システムドキュメントや

業務運用に関わる、業務フローやデータフローが残っていない。

または、ドキュメントはあるが、構築時点のもので、メンテナンスがされていない

場合が多い。

そのような場合でも、システムの再構築やBPRを行う場合、現行調査が必要となってくる。理由は、新業務を入れる場合でも現行業務を変える場合でも、既存で稼働している仕組みと結合させる必要がある場合が多く、影響調査が必要だからである。

今では、リバースエンジニアリングツールも多く出ていると思うのだが、まだまだ人海戦術でソースやある資料をかき集めてドキュメントを作るのが主流かなと思われる。

どんなドキュメントを作るかというのはITproや書籍に参考例は書いてあるので、

そこに任せておくとして、私なりに気をつけている事があります。

・クライアントで利用されている文言、定義で記述する

・作成した資料を見たり、使う相手を考えて作ること

　（エンドユーザなのか？システム部門なのか？

　　一般社員なのか、役職者なのか？）

　　→　それによって、システムより業務よりのドキュメントに変える必要があるし、　　　　まとめるテーマを変える必要がある

どちらも当たり前のことだが、意識して資料を作らないと一般用語やITの用語になってしまう。クライアント企業や人が日頃から使っている言葉で表さないと、言いたいことは同じなのに、資料が違うとか本質とは関係のない議論で終始してしまう。また、自分たちのことを考えていないな・・・と思われてしまうこともあります。

簡単にできることを当たり前にやることから始めるのが結構難しいです。

現行システム調査

ここ最近、とある企業の現行システムの整理をしている。整理といっても、アーキテクチャがこうで・・・サーバとサーバがこうで・・・というわけではありません。

JOBの種類や、DBの関連性(CRUD)、帳票の数など、素情報を集める作業です。

かつ、作業を進めながら、現行システムがどうやって動いているのかを把握していくという作業。

SIerだとよくある作業だよな・・・。と。

この作業フェーズですが、維持・保守されているシステムがどれだけしっかりメンテナンスされているか・・によって、調査の難易度が変化します。

メンテナンスはシステムだけを表していません。

システムを作る・維持するにあたっての仕様書、要件書、ユーザマニュアルなど、すべてをひっくるめてのものです。

個人的に、あるとやりやすい、やりにくいと感じているのは以下のとおり。

＜やりやすい＞

・ユーザーマニュアル・・・どうやって扱っているかを時系列で終えるので頭にはいる。

・業務フロー・・・要件定義していればあるはず。

・データフロー・・・データライフサイクル見えます。（特に業務メッシュで資料が揃っていると最高）

＜やりにくい＞

・コーディングと仕様が乖離している　・・・コードから業務や言葉を推測するのは結構ハード

・ノードキュメント・・・業務で扱われている項目が一切わからず（泣）

市場製品として、現行システム分析ツール（GTOne)とか出ていますが、一般的には人力で解読するのがまだ主力なのかと思っています。（若干、分析ツールは高い？）

システムが肥大化すればするほど、年季が経てば経つほど、読み解くのが苦しくなってきます。そうならないために、システムとそれを支えるものをどう定義していくのか。

なんでも困ったら外部に委託・・の前に、自分たちで対応できることを考えてほしいなと思う次第でした。（多忙で片付けず・・・）

作業の状態を説明できること

何気ないことだが、自分が与えられているタスクに対する計画の予実、課題を端的に説明できるというのは、忘れられがちだが重要である。

特に、相手の所有時間が分単位（１−１０分程度）しか取れないとき、ダラダラと話を展開されると、本題へもたどり着かず、ストレスだけをためてしまい、時間が来てしまう。

そのため、いかに説明できるかが、重要であると見ている。

QCDの視点で見れば、

Q：作業の成果物に対する、完成度について、質問・課題を提示

C：お金に関わる話しなら説明

D：計画に対する差異（大きければ、報告）

というのを先にまとめておけば楽に説明可能かと。

突っ込んだ質問をしている人もいるだろうが、上記の視点で、根拠を持って、対応すれば、多少間違っていても話はできると思われる。

毎朝の電車の中でも、当日の朝一でも良いので、毎日振り返っていると・・・説明は多少簡単にできるようになるはずである。

今の立ち位置を見失わずに進むのがコツだろうと感じている。