ＪＢＣＣ主催「第18回Xupperユーザ事例紹介セミナー」が2014年11月13日に都内で開催された。
上流分析・設計ツールXupperが1994年に誕生してから今年でちょうど20年。今年は、4月にケン・システムコンサルティングがＪＢＣＣ本体に組み込まれてXupper事業部となり、10月1日からSIイノベーション事業部として再発進した節目の年でもある。
セミナーではまず、中央コンピューターサービス ネットワークサービス事業部 取締役部長の所達也氏が登壇。続いて、明治座 業務管理室 室長でDAMA日本支部の広報担当理事の赤俊也氏が講演し、最後に、日本電気のSIサービス＆エンジニアリング統括ユニット プロジェクト・マネジメント統括本部の大場彰夫氏が講演した。
中央コンピューターサービス株式会社 取締役部長 所 達也氏
工期短縮、コスト削減、品質向上を実現するポイントとは？ビジネス環境が急激に変化するなか、一部のスーパーエンジニアに頼ってITを構築し運用することが難しくなってきた。属人化が課題となって、変化への対応力を失うリスクもある。中央コンピューターサービスの所氏は、「業務システムの保守における納期短縮・コスト削減・品質向上への取り組み～ Xupper 採用の背景とポイント～」の講演を行い、同社に存在したITの課題を、Xupper採用でどう乗り切ったのかを解説した。 |
 |
自治体向けソフトを30 年にわたって開発
|
中央コンピューターサービスは、北海道・中標津に本社を置く従業員55 名のソフト開発ベンダーだ。人口数千人規模の地方自治体向けに、総合行政システム「TAWN」を提供している。TAWNは1985年にオフコン版として開発・販売され、1994年にPC 版、2010 年にWeb 版がそれぞれ開発された。 時代にあわせてプラットフォームと機能の改善を重ねることで、大手ベンダーには相手にされにくい小規模自治体に30 年にわたって支持され続けてきた製品だ。だが、そうした長きにわたる製品開発のなかで、システムの巨大化やメンテナンス性の悪化を招くようになっていたという。 そこで、2010 年にXupper を導入し、上流工程の手法、手順の統一化や設計手法の標準化を進めた。その結果、「工期短縮」「コスト削減」「品質向上」という3 つの目標を達成することができたという（図1）。「保守性や品質が以前にくらべて格段に上がった。選んで本当によかったと思っている」と所氏。所氏は講演で、同社がこうした取り組みを進めるうえで、何が課題になり、どう解決したのかのポイントを具体的に紹介していった。 |
※画像をクリックすると拡大します 図１Xupperが実現する3つの目標 |
新入社員からも"ダメ出し"された開発体制
行政システムは、規模に限らず、自治体運営に求められる機能を等しく実装していく必要がある。たとえば、最新のWeb版の「Web-TAWN」は、住民記録、国民年金、選挙などの住民情報システム、介護保険などの福祉情報システム、人事給与などの内部情報システム、上下水料金などの生活情報システム、住民税などの税務情報システムで構成される。画面数は3500 枚、帳票数は900 枚、テーブル数は1900 件、管理項目は2 万件といった規模だ。
「求められる機能をとにかく早く実装して提供することに努めてきた。現場にヒアリングしたその場で画面をつくったこともある。機能が頻繁に追加されるため、マニュアルを残すことも少なかった。少数精鋭だったこともあり、それでも回っていた」
しかし、開発から20 数年後、中途入社のSEから直接ダメ出しがきた。ドキュメント管理がずさんで、基本設計書もなく、データベースも正規化されていないといった、根本的な開発体制の見直しを迫るメールだった。なんとかしなければという危機感にかられた所氏は、課題をリストアップ。ドキュメントや設計、データベースの見直しのほかにも、OSのバージョンアップへの対応、市町村合併による市町村の減少による売上減、業務システムの巨大化、度重なる法改正と保守、スーパーSE の退職による開発体制の維持など、さまざまな課題が山積していた。
課題解決のカギは属人化の排除
所氏は、Web 版TAWN の開発にあたり、プロジェクトの目標として、工期短縮、コスト削減、品質向上を掲げた。さらに、課題解決のカギは、属人化の排除にあると見定め、上流工程と下流工程の改革、設計・保守用ドキュメントの体系化、設計・保守ドキュメントの情報化、DB設計の最適化を図ろうとした。そこで、検討事項になったのがCASE ツールの導入だ。
CASE ツールに求めた要求事項は、大きく6 つ。具体的には、（1）上流工程の手法、手順が確立、統一できること、（2）業務分析、設計手法を標準化し品質および保守性の向上が望めること、（3）開発スタッフ全体のスキルの平準化が図れること、（4）情報の共有化が図れること、（5）容易に操作、運用ができること、（6）導入コスト、ランニングコストが導入メリットに見合うことだ。
「こうした要件を満たすツールというのは実はほとんどない。特に、われわれが抱えていた課題を解決できそうなソリューションはXupper以外になかった」（所氏）
所氏によると、Xupper採用で大きなポイントとして、機能が充実していること、さまざまなアプリケーションとの連携実績があったこと、国産ツールであったこと、API などの独自開発が可能だったことを挙げた。
「運用をはじめると想定外のことが起こる。国産ツールであり、独自開発ができるとそれらに柔軟に対応することができることは大きい」（所氏）
実際、運用を開始してから、Xupper とExcel による設計書作成が平行していた時期があったが、ＪＢＣＣ の協力をえてExcel からのインポート機能を独自開発して、乗り切ったという。
工数見積や製品品質の向上にも使いたい
|
導入後は、CASE ツールの要求事項に掲げた6 つの点について、大きな成果を出しているという。特に、上流工程の手法や手順の統一化、設計手法の標準化は、工期短縮やコスト削減に直接効いているとのこと。また、人の入れ替わりなどの際にかかる教育コストについても、これから大きな効果が現れてくるだろうとした（図2）。 今後の展開としては、大きく2 つの取り組みを紹介した。1 つは、工数見積精度の向上とスピードアップだ。具体的には「Xupper で作成した設計情報をもとに影響する画面数や入出力項目などを自動算出できるようにし、見積もり提示へのレスポンスを上げる」ことを考えている。もう1 つは、製品品質の向上とスピードアップだ。「画面、帳票、DB などに関する情報をもとに影響箇所の洗い出しやテストケースの自動作成、自動実行などを行う」計画だ。 最後に所氏は、「これまでのやり方と変わると、面倒なことが増えたと思い、手法変更に抵抗する人もでてくる。その場合は変更した手法をただ押し付けるのではなく、手法を変更する目的をしっかりと伝えていくことと同時に、現場の声にも十分耳を傾けることが大事だ。また、ツールは目的を達成するための手段でしかない。課題を明確にして、それを乗り越えていくことが大事だ」と話し、講演を締め括った。 |
|
中央コンピューターサービス株式会社様の事例PDFは下記よりダウンロードできます
株式会社明治座 様
無意識に騙し絵を描かない為に
|
|
組織のコミュニケーションをうながす適切なモデル
明治座の業務管理室 室長で、DAMA日本支部の広報担当理事を務める赤氏。もともとベンダーでプログラマーやSE として活動し、その後、ユーザー企業側に移り、情報システム部門や業務改革を担当。現場の視点にこだわりつつ、上流工程におけるコミュニケーションのあり方を追求している。Xupper ユーザーとして、これまでも講演を行ってきたことでもお馴染みだ。
そんな赤氏が今回掲げたテーマは「騙し絵」を描かないための方法。具体的には「シンプルで強靭なモデル」をどう作り、活用するかということだ。赤氏はまず、池波正太郎の小説「真田太平記」や「旅路」などを引き合いにこう切り出した。 「『この世のなかは、それぞれの勘違いによって成り立っている』し、『さまざまな数えきれない色合いによって成り立っている』。開発やビジネスの現場もそう。勘違いが当たり前のようにある騙し絵のようなものだ。無意識に騙し絵が描かれていることに気づかないまま、後工程に進み、騙し絵のからくりに気づいたときには、すでに遅いという事態に陥りがちだ」
そこで大事になってくるのがコミュニケーションだという。そして、コミュニケーションを円滑に行うために必要になるのが、シンプルで強靭な業務モデルだ。「業務モデルは理屈よりもわかりやすさを優先するのがポイントだ。また、データを中心に考えていくことが求められる」と赤氏。
リポジトリでデータソースを一元管理するメリット
|
赤氏によると、エンタープライズアーキテクチャ（EA）やXupperなどのツールも「データ」を重視しているのだという。これには理由がある。データをきちんと定義しておくことで、後工程の品質が確保されるからだ。データ定義を怠ると、たとえば、ヤードとポンドを取り違えた結果、航行ミスが起こり、火星探査機を人為的に爆破せざるをえなくなったNASA のような事態に陥ることすらある。 「自然に正しいデータが溜まる仕組みを構築することが大切だ。その際のポイントは上流工程からデータマネジメントの概念をすり込んでおくということ。そこで、重要になってくるのがリポジトリだ」（赤氏） リポジトリには、作成したデータモデル、プロセスモデル、CRUDマトリックスなどの情報が一元的に集約される（図1）。リポジトリがあることで、データベースのフィールドがどのエンティティ、画面で使われているかを即時に把握できる。これにより、影響度分析などが容易にできるようになる。さらに、成果物を自動的に生成するといったことも可能だ。 赤氏は、「プロジェクトの隠れたコストには、コミュニケーションのコストと成果物作成のコストがある。コミュニケーションコストはモデルの構築で削減できる。成果物作成のコストをリポジトリ搭載のツールを使うことで削減することができる」と解説した。 |
図1：リポジトリにデータソースを集約して一元管理 |
「氷山の理論」で見る要求と要件
さらに赤氏は、要求と要件の違いが「騙し絵」を描くことにつながりやすいと指摘。要求と要件の違いを「氷山の理論」を使って説明した。氷山の理論とは「目に見える部分は8 分の1 程度で、残りの8 分の7 は水面下に沈んでいる。氷山の動きの威厳は目に見えない8分の7によって保たれている」というヘミングウェイによる考え。
これについて、「要件として実現されている8 分の1 で、残りの8分の7 の要求を満たさなければ、氷山の動きの威厳を保つことができない」と考える。つまり、「要求は、ユーザーが情報システムで実現したいこと。要件は要求をふまえて、情報システムに盛り込むべきもの。この違いをつかみ、本当に必要なものを要件として定義していくことが求められる」（同氏）わけだ。
ここで、要求仕様を引き出すことと、要件定義自体を行うことを混同してしまうと、ビジネス上のゴールが不明確になる。「不明確なまま実装フェーズに入ると、いきなりデスマーチが発生する」ことになってしまうのだ。
また、そもそも、ユーザーは要求と要件の違い以前に、ビジネス要求とシステム要求がきちんと判別できていないケースが多い。ユーザーが言ったことを真に受けてしまうと、さらなる混乱を招くことになるわけだ。
「要求と要件の整理は、最初が肝心だ。源流に極めて近いところで始めないと下流への流れをうまく作ることができない。一滴の水滴が川のうねりを経て、最後には大海に流れ込んでいくイメージだ」（赤氏）
トップダウンで骨組、ボトムアップで肉付け
|
では、上流における業務モデリングで大切なことは何か。まず、赤氏が重視している基本原則は「トップダウンで骨組、ボトムアップで肉付け」だ。「現場の知恵は有効だが、ボトムアップが強すぎると「部分最適」に引っ張られる。間違っても、ボトムアップでトップダウンを潰すようことはあってはならない」とした。 モデリングでは、データモデル、ブロセスモデル、CRUDマトリクスという3 つのモデルについてポイントを説明。データモデルの留意点は、業務部門に見せても理解できないことを踏まえ、画面イメージとエンティティを切り出して、フィールド一覧として提示するといった見せ方の工夫が必要だとした。 また、プロセスモデルについては、現場で要求をひろい、現場が理解できるわかりやすい業務フローを描くことが重要だという。現場の人間を巻き込むには、現場視点に立ったストーリー性の高い話で惹きつけるのがポイントだ。また、モデルを作る際には、5W2H（When、Where、Who、What、Why、How、How many）をきちんと定義することが重要になる（図2）。 最後に、赤氏は、「高品質のプロセスにより生成されたデータは、企業組織の資産になる。天高く舞う鳥の視点を持ちつつ、地べたを這って泥臭く仕様を固めていってほしい」とアドバイスした。 |
※画像をクリックすると拡大します 図2：プロセス作成では、5W2H を明確に定義することがポイント |
株式会社明治座様の事例PDFは下記よりダウンロードできます
日本電気株式会社 様
アプリケーション開発の最新状況を知る2020年問題によるソース不足や就職の不人気、ビジネスモデル変更を迫るクラウドの台頭など、SIerやユーザーによるアプリケーション開発の現場は転換点を迎えている。NECの大場氏は「アプリケーション開発近代化への挑戦！～設計リポジトリの活用による設計情報の管理と品質向上～」と題し、そうした開発現場の状況と、今後どのような方向に進むべきかについて各種提案を行った。 |
 |
最近のアプリケーション開発の現場
これまでのXupper ユーザ事例紹介セミナーで、幾度となくテクノロジーとプロジェクトマネジメントの最新動向を伝えてきたNEC の大場氏。今回のセミナーでは、最近の開発現場を巡る状況を振り返りながら、労働集約型開発から知識集約型開発への道筋と具体的な対策を提示した。
大場氏はまず、最近のアプリケーション開発の傾向として、大きく3 つの傾向があると指摘。1 つめは開発期間の増加と開発コストの低下だ。目的や要求が複雑化して、要件定義や外部設計に多くの時間がかかるようになる一方、年率10%程度のコスト削減要求が求められているという。
2 つめは、ライフサイクルや作り込みへの要求が強まったこと。新規にシステムを開発するのではなく、システムを変更しながら継続的に使用する傾向が強くなっている。そのために、システムのライフサイクルを通じて「早く安く良く」開発すること、効率的に高品質を維持することが求められるようになった。
3 つめは、開発リソースの確保が困難になってきたこと。SE は、新3K と呼ばれるほど人気が低迷しており、特に優秀なリソースの確保が難しい。一方で熟練した高スキルのIT 技術者は高齢化して
いるのが現状だ。
大場氏は「理系の就職人気ランキングを見ると、2010 年以降、IT に関わる企業は上位10 社に1 社もランクされていない状況が続いている。人気だけでなく、実際に、優秀な人材が業界に入ってきていない」と人材不足の深刻さを語った。
労働集約型開発から知識集約型開発へ
そのような中、目指すべき開発手法として提案しているのが「知識集約型開発」だ。従来の開発手法は「労働集約型開発」で、中流工程（製造?評価）以降に人的リソースを規模に応じて投入する。開発要員のスキルにより生産性が変動するのが特徴だ。これに対し、知識集約型開発は、開発要員の労力を上流工程（設計）や評価試験の設計に注力させ、中下流工程はできるだけツールによる自動化を行う開発スタイルとなる。
特徴は大きく3 つあり、（1）上流工程の設計や評価試験の設計に時間と労力をかける、（2）ツールの自動化によって中下流工程を効率化させる、（3）設計情報の共有および維持フェーズにおける効率化のために、設計情報を一元管理し、メンテナンス性の向上やデグレードの抑止を行う、となる。
「品質の作り込みを上流で行うが、仕様は必ずしも確定するわけではない。設計情報を一元管理することで、各フェーズで手戻りは容易。製造やテストは、自動化によって、作り込みバグのゼロ化を目指す」（大場氏）
つまり、短期開発やリソース不足、品質の作り込みへの要求、追加・変更開発によるバグ混入などの課題に対応できるアプローチというわけだ。そのうえで、大場氏は、知識集約型開発を推進するうえでのポイントは、アプリケーション開発のテクノロジーとプロジェクトマネジメントの融合だと主張した。
知識集約型AP開発のためのテクノロジーとツール
| アプリケーション開発テクノロジーとしては（図1）のような技術を組み合わせて利用する。たとえば、「アドバンスドDOA（データ中心設計）」や「SDE（NECのSystemDirector Enterprise）」といったツールを使って、上流の設計情報からテストシナリオを自動生成するようにすれば、「母体品質確保」「開発期間短縮」「影響調査が確実・容易」「バグ混入防止」といった効果が期待できる。 |
※画像をクリックすると拡大します 図1：知識集約型ソリューションによる狙いと効果 |
|
あわせて、プロジェクトマネジメントとしての取り組みを進めることで、効果を高める。たとえば「OODA（ウーダ）」と呼ばれる「観察（Observe）」「予想（Orient）」「決断（Decide）」「実行（Act）」をすばやく繰り返すことで迅速な意思決定を行うことで、プロジェクトが予定通り健全に遂行されているかを判断できるという。 |
※画像をクリックすると拡大します 図2 ：知識集約型AP 開発ソリューションのツールマップ |
プロジェクトマネジメントで注目すべきポイント
プロジェクトマネジメントのポイントは、まずは、PDCA サイクルに加えて、先ほどのOODA サイクルを導入することだ。PDCA がQCD を確保（特に品質の確保）する取り組みだとすれば、OODAは、QCD の確保（特に品質の確保）がなされているかを確認することで、意思決定を迅速化する取り組みになるという。
また、組織体制としては、スペシャルSE によるスモールチームが重要だ。少数精鋭にすることによって知識の集約化を図り、多くの場数を踏ませることで優秀なSE（スペシャリスト）を育成していく。その際のチームビルディングでは、俊敏性を高めるために、「相互信頼」「直観的意思決定」「契約的リーダーシップ」「重点・焦点・方向づけ」という4 つの属性を考慮する。これら4 つは、OODA ループを回す上でもポイントになるという。
開発自体は、スモールチームによるイテレーション開発のかたちとなる。イテレーション開発により、開発要員の習熟度・スキルの向上を実現し、開発リスクを低減することができるという。
最後に大場氏は「品質は上流工程で作りこまれる。もし上流工程で作りこまなければ、後工程でそれを確保しようとしてもできない」と、品質確保における上流工程の重要さを重ねて強調した。
日本電気株式会社様の事例PDFは下記よりダウンロードできます