IT化が急速に進む中、エンドユーザの方々は真にその恩恵を受けているでしょうか?
一般のエンドユーザの方々は、以下の様なジレンマに悩まされておられるのではないでしょうか?
・本当はもっと自社に適した業務システムを構築したい。
・自社専用のシステムを構築するには、莫大な費用がかかる。
・なんとか使えるパッケージシステムで我慢するしかない。
では、一方のシステムベンダーはどう考えているでしょう?
・最近、プログラマの派遣要求が多く、持ち出し(請負)作業が激減している。
・請負でシステム受注をしても、度重なる仕様の変更・追加による費用負担をして貰えず、結果的に赤字となる為、請負はしたくない。
・技術者の出入が激しく、請負システムでは退職したプログラマが開発したソースコードの管理に多大な費用がかかる。
・従って、請負より派遣の方が利益確保が容易だが、派遣先からは人件費の定期昇給分の単価増をして貰えず、結果として低賃金で雇うしかなく、
技術者の離職増となり、最近では若手プログラマの確保もままならない。
・プログラマの育成には多くの時間と費用がかかるが、定着率が低く、課題となっている。
・首都圏だと比較的に単価の高い仕事があるが、地方では困難。
では、派遣技術者を求めるユーザはどうでしょう。
・都度システム仕様書を作成して外注しても、仕様書に全ての要件を満たすのは困難。
・仕様書の不備に対する修正作業分の費用の捻出が困難。
・セキュリティ管理上でも、社内への技術者の派遣が好ましい。
・派遣技術者の定期昇給分の単価アップをしたいが、単価アップへの許可が下りない。
・結果として、技術的に未熟な若手技術者の派遣を受けざるを得ないが、この様な先の見えない派遣への若手技術者の希望が激減し、
人が集まらない。
また、もう一方のSEやプログラマはどうでしょうか?
・近年、IT技術の幅が広くなり、日々スキルアップに努力を重ねているが、その割には賃金も伸びず、派遣という使い捨ての先の見えない職場しかない。
・中堅になると経済的にやっていけず、フリーで働こうと独立するも、安定した仕事が受注できない。
・SEやプログラマは30代で使い捨てされるという噂があり、将来に不安。
せっかくIT技術が急速な進歩をしても、この様な状況下では今後の業務システム開発業界の成長は見込めず、エンドユーザもその恩恵を享受する事が
できません。結果として、大手企業のみが独自の業務システムを構築するにとどまり、一般の中小企業への恩恵は少なくなっています。
私はこの数年間、ずっとこの課題について検討をしてきました。そして、派遣という従事形態は今後も続く事が考えられますが、請負作業では以下の
様な対策により、かなりの部分の改善と対策が可能であるとの回答を得るに至りました。それは、他のプログラマが作ったシステムの解読にかかる膨大な
労力を軽減する為の、以下の抜本対策をする必要があると言う事です。
・開発手法(プログラム名や変数名の命名ルールの制定、詳細なコメントの記載 等)を実施する。
中でも、コメントについては非常に重要で、作成したソースコードが何をしているかを記載するだけではなく、何の為に作成したかも記載する。
第三者によるソースコード解析のカギは、そのプログラムが何をしているかという情報以上に、何の為に作られたものかという情報が重要と
考えています。
・開発環境(言語、データベース、ライブラリ等)を徹底的に標準化・共通化する。
・徹底した構造化プログラミングを実施する。
・ソースコードに利用した特殊技術はきちんとマニュアル化すると共に、各ソースコードの要所々々に利用したマニュアルの管理番号を記載し、対象
マニュアルの検索を容易とする。
・上記作業により、システム解析の為のドキュメント(テーブル仕様書、変数定義書、フローチャート、プログラム定義書 等)の自動生成が可能となる。
以上により、経験の浅い技術者でも、他の技術者が開発したシステムの解析が非常に容易になる事が判りました。
ここ数年、以上の事を実戦するとともに、システム解析の為のドキュメント(テーブル仕様書、変数定義書、フローチャート、プログラム定義書 等)の
自動生成システムを開発し、上記理論の検証をすると共に、本システムを「システム開発支援システム【システム改革】」と命名し、リリースしました。
本システムの概要を、以下ご紹介します。
1. メイン画面
2. テーブル仕様書からの各種ソースコードの自動生成
データベースを利用したアプリケーションを開発する場合、テーブルの初期化や検索・削除・挿入・更新 等々、同様のコードの膨大な記述が必要となります。 そこで、これらのソースコードを自動生成するシステムを整備しました。これ以外にも、Inport文やExport文、その他多くのデータベースアクセス用サンプルプログラムの出力が可能です。これにより、システム開発のソースコードの標準化の推進と大幅な工数削減が可能です。
以下は、テーブル仕様書とCreate文との双方向変換をした場合の例です。
3. 画面生成用ソースコードの自動生成
また、テーブル仕様書から、画面フォームデザイン用ソースコードの出力も可能です。以下は、上記仕様書から生成した画面フォームデザイン用ソースコードの出力例です。
上記の画面フォームデザイン用ソースコードを空のサンプル画面のモジュールに貼り付けて起動した場合の画面は以下の様になります。
4. ソースコードからのフローチャートの自動生成
ソースコードからのプログラミング条件を限定する事により、フローチャートの出力も可能です。以下は、出力例です。
他社のフローチャート生成方法とはことなり、ソースコード内のコメントもきちんと反映されると共に、ソースコードの行番号やログ出力行Noの
表示もされると共に、重要なマニュアルのリンクにより、ソースコードの解析がより容易となっています。
5. 変数定義書の自動出力
ソースコードから、変数定義書の出力が可能です。
その変数がどの様な型で、どこで宣言されていて、どのプログラムで使われているか等を明示する事により、プログラム解析の強い武器となります。
また、つかわれていない変数も一目でわかることから、ソースコードのゴミになる不要変数の確認にも有効です。
6. プログラムストラクチャの出力
プログラムの解析にはもうひとつ、どのプログラムがどのプログラムを読んでいるかを簡略に把握する事が有効です。
この作業を具体的にサポートするのが、プログラムストラクチャーです。
本システムでは、容易にこのプログラムストラクチャーの出力が可能です。
7. プログラム一覧表の出力
プログラムの解読の容易性向上の為には、プログラムのストラクチャやフローチャートだけではなく、どの様なプログラムがどれだけあるか、
を一括して見れる事も大変有用です。下記プログラム一覧表は、各プログラムの名称や目的、仕様だけではなく、Functionの場合の戻り値の型や、
設定されている引数の情報も一括して確認できる為、効率的な解読作業を強力にサポートします。
8. プログラム定義書の出力
プログラムの解読には、各プログラムの詳細なドキュメントが最も必要です。
下記プログラム定義書には、目的や仕様、引数の詳細、内部定義変数の詳細、呼出しプログラム等、詳細な情報が一目で見られる様に
出力されます。
この様なシステム開発支援システムの採用により、システム開発工数の大幅低減と、開発手法の標準化拡大を図る事ができます。