 |
|
|
| 1 2 3 4 次のページ
|
|
| 私たちの携わる現場
|
筆者が関わっている現場は、ホストコンピュータを使用した中央集中型のシステム構造を採用しています。その中でSEまたはプログラマとして詳細設計やプログラム作成を行う傍ら、影響調査や要件に対するシステム検証といったクライアント支援を行っています。
そして、いうまでもなくクライアントはDOAを意識した開発標準を採用しており、データモデリングを中心とした開発体制と制度を適用したシステム開発の現場となっています。
|
| 届いてないよ、聴かせてよDOA
|
このように開発標準としてDOAを意識したシステム開発が行われていますが、筆者をはじめとしてSEやプログラマは、それを特別なものとして意識することはありません。
クライアントから求められることは、品質と期日です。その視点からするとSE・プログラマとして、詳細設計や開発工程のスケジュール管理、プログラムの作成のスキルなどのスキルセットが優先します。このため、DOAの分析技術を身につけて仕事に活かしていくまでには、暫く道程がありそうだと感じています。
実際に、筆者たちが仕事をはじめる段階では、業務プロセスの分析はすでに終了している場合がほとんどです。データの流れを精査した上で組まれたデータベース（論理構造）が基になって、実装に向けた設計とアプリケーション開発を行うことになります。
しかし、基本設計の段階から関わるプロジェクトが「まったくない」というわけではありません。
プラモデル作りで例えると、今までは説明書通りに作品を組み立て、塗装や付属品の計画を練り、でき栄えを確認するといったことを繰り返していました。しかし基礎設計から関わるプロジェクトでは、説明書を作成する側になるのです。
今後その立場での仕事は増えてくると思いますし、立ち入ったことのない領域に足を踏み入れる日もそう遠くないと考えています。それだけに「今の状態のままで、ユーザの要件をまとめて基本設計ができる日がくるのだろうか」という不安を覚えることもあります。
DOAに関する知識が乏しいSEやプログラマたちは、その時になってDOAをどのように意識するのでしょうか。ただ事実として、筆者をはじめとしたSEやプログラマは実際にDOAの現場に身を置いて仕事をしているわけですし、今日も明日も、この先暫くDOAに関わっていくことは間違いありません。
そこで今回は、筆者の「仕事」について率直に述べることで、これからDOAを経験するかもしれない読者の皆さんに何らかの示唆や参考になることを期待して寄稿することにしました。また、この機会を通して、今後のDOAに何らかのよい変化をもたらすきっかけになることを祈って、筆を進めることにします。
|
1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
システムズ・デザイン株式会社 DOA推進ワークショップ
ビジネス解析方法論であるDOAと、開発プロセス方法論であるRAD、ウォーターフォール、UPなどを現場の最前線で適用している技術者を中心に開設した、sdc独自のワークショップ。PDCAサイクルを回して、さらなる進化と「確かなモデリング∧確かな開発プロセス→いい仕事」の可能性を追求する。
|
|
|
|
|
|
