2018.05.05

仕様の「見える化」と働き方改革

 工学の世界広しといえども、複雑膨大な設計情報をExcelで管理しているのはIT業界くらいだろう。ITは現代社会のインフラを成すほど重要なものだが、その有り様がOfficeのような汎用ツールで管理されているとしたら、なんと脆弱なインフラだろうか。Excelで設計情報が管理されている飛行機や高層ビルなど、怖くて誰も利用しないだろう。プロのIT技術者を名乗るなら、プロ用のCAD/CAM(エンジニアリングツール)を使おう。気に入るものがなければ、ITスキルを行使して自作しよう。私は長年そのように主張してきた。

 それでも、業界でのCAD/CAMの利用は進んでいない。今でも石を投げれば「Excel方眼紙」の峨々たる集積にあえぐプロジェクトに当たる。何回か説明したが、これにはそれなりの理由がある。まず、ExcelやWordやパワポやVisioでの仕様管理を前提とすれば、余分な工数や要員を見積に上乗せできるからだ。また、誰が担当しても設計品質に差がないっぽく見えるし、仮に稚拙な設計であっても、わかりにくい仕様の保守を独占する形で顧客を囲い込めるからだ。「開発実務を担当する外注要員との契約差額」、そして「無駄に多い外注要員を管理するための高額なプロジェクトマネージメント料」の二本柱で稼ぐSIerにとって、Excelでの非効率な仕様管理態勢はどんなに批判されてもやめられないのである。

 ところが今や「働き方改革」の時代だ。SCSKのように、残業の徹底的削減で名をあげたSIerもある。もしSIerが「外注要員を含めた全プロジェクトメンバーの働き方改革」に本気で取り組むならば、真っ先に狙い撃ちされるのはExcel方眼紙である。Excelでの仕様管理態勢は、プロジェクトメンバー(とくに外注要員)に余分な作業を強制することで成り立っているからだ。Excel方眼紙こそが、日々の面白みのない仕事や設計品質の劣悪さや長時間残業の象徴である。それにしても、開発プロセスの合理化要求は意外なところからやってきたものだと思う。私などがひとりで叫ぶよりも100万倍は効果的であろう。

■システム仕様を「見える化」する

 じっさい、拙作のOSSモデリングツール(X-TEA Modeler)は、最近ではExcelでの仕様管理態勢から段階的に脱却するための移行用ツールとして活用されている。膨大なExcel仕様書上の要点をツールが提供するリポジトリに登録する。それだけで、既存のExcel仕様書とツールが連係され、設計要素間の論理関係が手軽に「見える化」される。その効果は劇的で、「10年前にこのツールを知っていれば、あんな苦労はしなかっただろうに」という感想を何度ももらった。

 移行手順を説明しよう。まず、プロジェクトのルートフォルダに、モデリングツールのコンテンツファイル(ここではMfgOrder.xeadとしておく)を置く。そして、現行のExcel仕様書ファイルを、すべてその下位フォルダfunctionsに置く。またシステムに関する包括的な説明を記した資料については、別のフォルダgeneralに置く。そのうえで、テーブル定義と機能定義の一覧をテキストデータ化してツールにインポートする。

MfgOrder - コンテンツファイル(MfgOrder.xead)を置くためのプロジェクトフォルダ
 |
 +―functions - Excel仕様書ファイルを置くためのフォルダ
 |
 +―general - 包括的な説明資料ファイルを置くためのフォルダ
 |
 +―backup - コンテンツファイルの差分管理用フォルダ

 次に、機能定義(プログラム定義のこと)に対応するExcel仕様書の名称と位置を、たとえば"<CURRENT>\\functions\\仕様書_&ID_&NAME.xlsx"のように様式化し、ツールに登録する(<CURRENT>はコンテンツファイルの置場を示す予約語)。すると次図で示すように、ツール上でそれぞれの機能定義を選択すれば、対応するExcelファイル(それが存在するのであれば)へのリンクが自動的に現れる。包括的な説明資料については、システム定義の「用語とルール」の項目毎に外部ファイルを指定することで、リンクが現れる。こうしてツールは「システム仕様のエクスプローラ」となる。最終的には機能定義とコードファイルとをリンクさせてしまおう。

▼仕様書ファイルへのリンクが自動表示される
20160505

 せっかくモデリングツールを使うのだから、データモデルもまとめたほうがいいし、Excel仕様書上の他の内容についてもツールに移行したほうがいい。たとえば、機能定義毎に「テーブル入出力」を登録することで、テーブルと機能との関係が見える化される。また、各機能からどの機能が起動されるかを登録すれば、「機能階層ビュー」と呼ばれるツリービューとして機能間の起動関係が見える化される。

 モデリングツール上では、こういったクロスレファレンスやCRUD表のようなマトリックス表現が自在に取り出せるようになっている。仕様変更時の影響調査など一瞬で済む。全要素に対する文字列の探索・全置換も出来るし、バージョン毎の差分も眺められる。こういうことはリポジトリを使うことで初めて可能で、Excelだけでは到底無理な芸当だ。

 それらの定義要素間の関係を登録してゆく過程で気をつけてほしいことがある。いったんツールにそれらを移行したなら、Excel仕様書上の該当部分をどんどん削除してほしい。それらを残せば、モデリングツール上の定義と外部ファイル上の定義とをダブルで維持する羽目になるからだ。機能単位でひととおりの仕様情報が移行されたと思えたなら、その機能に関するExcelファイルそのものを削除してしまおう。最終的に残った外部ファイル上には、「ツールが提供する様式では表現しきれない細々した仕様情報」だけが記録されていることになる。

 つまり、「定義要素間の関係」についてはツール上で眺め、「定義要素内部の詳細情報」については外部ファイル上で確認する、という態勢である。それで、たとえばシステムに何らかの障害が生じた場合なら、関連する定義要素をツール上で素早く特定し、必要ならば細かい情報についてリンクされた外部ファイルで確認すればよい。ここまでやれば、仕様管理態勢においてExcelやWordは補助的なものでしかない。けっきょくOfficeツールがダメという話ではなく、その使いどころの問題である。それを仕様管理態勢の「核」にしているとしたら、ソフトウエア開発のプロとしてはあまりに情けないという話だ。

■本当は怖い働き方改革

 さてここからが「働き方改革」に関する本題だ。この態勢を実現すると、設計の巧拙がはっきりするとともに、仕様情報の管理コストが激減する。これに合わせて、思い切って要員を少数精鋭化してほしい。これまでのようなちまちました分業もやめて、腕のいい技術者1人を主任設計者として、リポジトリとExcelファイルの保守を全面的にまかせるべきだ。システム仕様の広域な一貫性と整合性を維持するためには、そのやり方がもっとも効率的かつ効果的だからだ(育成とリスクヘッジのため、実際には見習いを補欠要員とした2名態勢のほうがいいだろう)。仕様が誰にとっても見やすくなりつつも、限られた技術者だけに編集を許すのである。

 せっかく効率が改善されても、人手が減らされるのなら働き方改革にならないではないか――そう思えるかもしれないが、心配ご無用。徒手空拳の人海戦術で戦うからこそ、膨大なコミュニケーションコストによる効率の低下、そして、無駄な分業による設計品質の低下が起こる。モデリングツールやDSPといった最新鋭の武器を導入し、さらに人員を精鋭だけに絞り込む。ここまでやることで、設計品質の改善と同時に、技術者の働き方改革を達成できる。合理化ツールを導入しないままで闇雲に残業時間を削るだけでは、事態はますます混乱するだけだ。

 重要なので繰り返そう。システム開発における働き方改革の肝は、「ツール導入による開発プロセスの合理化」と「少数精鋭化」の合わせ技にある。さあそのとき、あなたは創造的な仕事をやれる精鋭としてプロジェクトに残れるだろうか。非効率なやり方と多すぎる要員の是正――これこそが我々にとっての「本当は怖い働き方改革」の正体である。

| | コメント (0) | トラックバック (0)

«新人にオブジェクト指向の魅力を知られてはいけない