さった2月20日に開催された、超高速開発コミュニティのセミナー「超高速開発での設計を考える」で引き続き司会を勤めました。その報告をアップします。
超高速開発ツールでの設計を考える上でのポイント - DBC渡辺さんの思い
「設計者の発言」ブログで著名な渡辺幸三氏はファンも多く、当日の参加者からも、渡辺氏の講演に期待しているという声があったほどです。今回、このコミュニティの主旨に賛同され、ご登壇いただけたことを心から嬉しく思っています。
当日の語りはシャープな切れ味で会場を何度も笑わせていただきました。ポイントはおおむね次のとおりです。
- 過去のCASEツールブームが終息してしまった原因は、設計情報から構成されるアプリケーションのテンプレートとなる「レファレンスモデル」が登場しなかったことにある。（補足：私の理解では、そのあとに登場した ERP がこれに近い。しかし ERP は設計情報がクローズな上に、プラットフォームも固有のため、カスタマイズコストが高くなる構造である。渡辺氏のいう「レファレンスモデル」はオープンな設計情報であり、オブジェクト指向などのプログラミングに関する専門知識がなくても読めて、かつ変更できるという高い抽象性を備えるもの。）
- 超高速開発の世界では、開発環境はプラットフォームになる。業務要件はプログラミング言語で表現するよりも、抽象度の高い設計情報で表されるため、アプリケーションの定義が「コンテンツ化」しやすくなる。このような設計情報が資産として社会に流通・還元されることが、超高速開発を普及させる鍵である。
- 超高速開発の普及のためには、ツールの機能特性を説明したり、ツールに懐疑的な人の不安を取り除くための材料を用意するよりも、本格的な「レファレンスモデル」を提供することが近道である。プラットフォームと化した超高速開発ツールの上で、レファレンスモデルがその場で動作し、さらにカスタマイズできることを目の前で見せることは究極のデモ（プレゼンテーション）になる。これで心を動かされないユーザー企業は、ない。
株式会社ウイングの事例
GeneXus事業部の周佐氏は、日本でもっともGeneXus経験の長い開発者の一人です。2005年に日本でGeneXusの導入がはじまったタイミングから関わっていらっしゃるというので、10年になります。その経験を踏まえて、いくつかのお話をいただきました。
- GeneXusを採用する動機の一つに「設計書はすでにできている。開発工数を下げたいので、GeneXusで作ってほしい」という場合があるが、実はこのケースでは開発効率は上がらない。具体的には、プロセス中心の設計で、データベース構造がプロセスの従属物というアプローチでは、テーブル設計の不備をアプリケーションでカバーしようとするため、工数が膨らむ。
- GeneXusはプロパティ（機能）が豊富な分だけ、どういう場合にどのプロパティを設定したらよいか、という知識が必要になる。
- ユーザーインタフェースの問題は常にある。GeneXusのバージョンアップとともに、高度な UI を実現できるようになってきた。しかし本質的には、現場の意見をふんだんに盛り込んだUIは開発コストがかかることを踏まえ、そのUIは適切な要求なのか、過剰なのか、を判断することが必要。
- 渡辺氏のいう「レファレンスモデル」に同意できる。同社でも「GeneXus システムテンプレート」や、GeneXusのための開発プロセス「STREAM」を提供している。
- （本日のテーマである設計を考える、という視点から）GeneXusを要件定義から使うことを推奨したい。要件定義の段階で同時にデータモデルを整理すれば、要件定義という枠組みの中で「動くシステム」を使って現場が検証できる。もちろん要件定義の工数は膨らむが、後半の工程が楽になる。
- GeneXusを使っても、業務固有の入力チェックやバッチ処理などは決められたルールを実装するしかないため、工数削減につながるものではない。ただ、超高速開発という観点から、過剰なチェックにしないという意識はあってもいい。
株式会社ジェーエムエーシステムズの事例
企画営業部所属の袖嶋氏より、ご自身のこれまでの現場での開発実績を踏まえつつ、超高速開発ツールWagbyと出会ったあとで考え方が変わった、というお話をいただきました。
- 超高速開発ツールでは最初のモデリングが肝要なのは間違いないが、はじめからツール仕様ありきで要求を精査すると、つまらないシステムになってしまう。（機能はてんこ盛りでも、魂が入っていない感覚。）一方、ツールの特性を加味せず机上検討してしまうと、機能設計時に無理が生じる。この解決には、システム化の目的を出発点に、段階的変換で開発を進めていくのがいい。要求を「動的オペレーション」と「静的データ」という観点で解釈できるSEスキルが求められる。
- プロセスデータ（画面上の項目に近い）と永続的データ（データベースモデル）の二層を並走させる設計がよい。これにツール特性を加味させることで、プログラミングコストが激減する。
- プロジェクトの初期段階からツールを使ってモックアップをつくるのは効果的。しかし、ついあれもこれも作りすぎるとスコープが肥大化し、使われない機能が乱発される。上流工程で必要なのは、作りたがりのエンジニア気質ではなく、システム化による効果の高いところを狙って集中的に投資する姿勢である。特にカスタマイズはできる・できないの判断ではなく、実施するべきかどうか、という判断が必要。
- ツールは高速開発というメリットの裏に、制約が存在する。これを要求網羅や、過ぎた要求の抑え込みに、ツールの「早さ」と「縛り」を使うという発想につなげることができる。一度にすべての要求を作り込むのではなく、業務の成熟度に応じて、刻むIT投資を提案したい。
- 渡辺氏のいう「レファレンスモデル」の充実が鍵になることは同意だが、このようなモデルを自社投資で整備していくには相応のコスト負担が必要。このコミュニティをうまく活用し、1社では困難でもコミュニティ内でレファレンスモデルの充実を試行するというのは、面白いのではないか。
後半の議論で印象に残ったこと
セミナー後半では私の司会による（恒例の？）会場を巻き込んだ議論大会になりました。内容が盛り上がりすぎたのでブログ非公開とさせていただくことをご容赦ください。興味のある方は是非、次回にご参加いただければ。
一つだけ、公開します。細かい表現は私の脳内解釈で変わっていますが、大筋はあっていると思います。
「要求があいまいなままに開発を進めるとうまくいかない、というのはツールの採用に関わらず、最大の失敗要因として関係者には周知されている事実。にもかかわらず、そのような事例は後を絶たない。原因の一つは、ユーザ企業のIT投資のいびつさにあるという仮説を説明したい。IT投資の抑制が続くなか、たまたまポンと、経営陣がゴーサインを出したとき、現場担当者は "今このタイミングを逃すと、次はいつ決裁が通るかわからない。この機会に、使うかどうかわからない機能も、すべて盛り込んでおきたい。" という心理になってしまう。そのようなIT開発への投資環境では、理想とされる "小さくつくって徐々にステップアップ" が実現しにくいのではないか。」
「ユーザ企業の開発スキルが低下して、現代の超高速開発ツールを手にしても業務モデリングができなくなっている。現場担当者は UI ばかり気にして、モデリングの重要性はわからない。それではツールのメリットは活かせないのではないか。」
「この10年、ユーザ企業の開発部員は不況の影響で確かに外部へ出ていったこともあるかもしれない。しかし提案する側のSIerも、ユーザ企業の予算を獲得することが重視され、ユーザのためになるような鋭い提案が減っているということも同時に感じざるをえない。昔はもっと協力体制があった。ユーザ企業は超高速開発ツールに期待しているが、それはツールへの期待というより、ツールをうまく活かすような提案を出していただけるSIerへの期待にも重なる。100万円の今期予算があっても、作らない開発という姿勢で50万円で済むので、残りを来期でとっておけないか、という提案を持ってきていただければ、最初の仮説（何もかも盛り込む）が変わるきっかけになるのではないか。」
「SIerも変わらなければならないと感じている。超高速開発ツールの存在を知ったあとでは、SIerの仕事はユーザ企業の内製化を支援するノウハウ提供という立場が自然なように感じる。SIerが不要ということにはならない。しかし言われたものを開発するために人を出す、という（収益）構造は、維持できないだろう。その流れを理解し、率先していくSIerが次の世代をリードするのではないか。」
わずか1時間強という中で、アルコールなしで！、会場全体で熱く発言する人がどんどん登場する（誰も発言しない、シーン、とした時間がほとんどない）というのは、このコミュニティがうまく機能しているのだと改めて感じています。参加いただいた皆様、本当にありがとうございました。
最後に
超高速開発コミュニティ、今期最後のセミナーは「ナイトセミナー」となります。ライトニングトーク大会ですので、肩の力を抜いてご参加いただけます。どうぞお楽しみに。
