さった7月5日、超高速開発コミュニティ主催のイベントに参加してきました。事前申し込みは70名超えという人気で、非会員の方も多くいらっしゃいました。このテーマの人気が高いというのは、裏を返せば上流設計についてはまだ情報収集すべきフェーズとみなしているSIerが多い、ということでしょう。
当日は5名の経験者が持論を語ったあと、パネルディスカッションを行うというスタイルでした。以下、発言者は特定せず、私がなるほどと思ったメモを記録として残します。
- システム開発はなぜ困難か？それは「Excel仕様書」と「コーディング主体」の二つの問題がある。Excel仕様書作成では設計工程に多くの人員が投入されるため品質が低下する。コーディング主体のため実装と設計の分業体制により品質が低下する。航空機の設計や、高層ビルの設計をExcel仕様書で行うだろうか？しかし大規模システム開発は同程度の複雑さをもつにも関わらず、Excel仕様書のままである。
- 低品質な設計であるにもかかわらず、その実態が低品質な実装に覆い隠されているという現状がある。
- もちろん（超高速開発）ツールを導入したからといって自動的に設計品質が改善されるわけではない。訓練や職業適性は必要である。良いギターを買ったら誰でも良い演奏ができるということはない。どのような分野でも適切な訓練と素養は必須である。
- 設計とプロトタイピングを繰り返せば設計品質は向上するという意見があるが、その効果は限定的であろう。航空力学を知らずにプロトタイピングを繰り返しても飛行機は完成しない。つまり設計の基本スキルというのは存在する。
- しかし（超高速開発）ツールを使うと、開発者の設計スキルがあらわになる。すなわち、これまで人海戦術がボトルネックだったものが、ツールの導入により開発者の設計スキルがボトルネックになる。ますます上流設計が重要になる。
- 上流設計の技術スキルの要は、DB設計と業務知識。この二つを抑えれば、複数の超高速開発ツールを使えるようになってもいい。
- SIerはこれまでの派遣業から、タレント事務所になっていく。つまり量のビジネスから質のビジネスになる。タレントはお金をかけてちゃんと育成するものである。
- 現在のシステム開発の「ドキュメント」は実際には設計情報ではなく、証拠物件という側面があることを否定できない。まともな設計情報を作る方法を知らない、さらにいうとそのようなものをつくっても儲からないというSIer側の事情がある。
- 超高速開発ツールのメリットを3つあげるとすれば「開発スピードの高速化」「学習コストが低い」「メンテナンス性が高まる」こと。このメリットを実感できるのはSIerではなくエンドユーザであるため、エンドユーザ自身の開発が理想。これは（昔の）End User Computing とは違う。とはいえエンドユーザがなにもかもできるわけではないため、エンジニアが参画することは必要。
- 開発スピードの高速化は、開発費が安くなるということではなく、アジャイル開発と相性がよいことがメリット。つくって確かめて、ダメならやり直すということができる。動くソフトウェアを中心にすれば現場を巻き込みやすい。
- 設計情報の作成というプロセスによってエンドユーザのイメージと、開発者のイメージを整合させ、共通認識を持たせることができる。つまり上流工程では “整合性のとれた設計” を意識すべきである。
- 実装を意識しない上流工程では「論理モデル」「業務フロー」「業務定義」「業務用語集（ディクショナリ）」を整備することが中心になる。
- 業務フロー（ビジネスルールともいう）の上流設計のよくある失敗事例は、(1) 分析前の早い段階で業務とITの分担を決めてしまう。(2) ルール担当が必要以上にIT要素を取り込もうとする。(3) レガシーソースから自動的にルールを抽出しようとする。がある。
- ビジネスルールとは手順ではなく業務知識である。EAでは、データやプロセスからルールを分離する。そしてルールは「制約」「ガイドライン」「推論」「計算」「アクションイネーブラ」から構成されるものである。
- 上流工程は、システム全体を俯瞰することである。その意味では開発の「前工程」と捉えられる。そして「前工程」と「後工程」の間には、明確な因果関係がなければならない。これを INPUT と OUPUT と表現したとき、OUTPUTだけをみてその品質（内容）を確認することは難しい。アプリケーションをつくってはじめて、前工程のOUTPUTの品質がわかるという特徴がある。
- 一方でソフトウェアは前工程に戻ってOUTPUTをつくりなおすことができる。これは製造業では難しい。材料をつかってしまったら元に戻せない。
- 問題はINPUT（仕様）が不確定であることと、仕様は相互作用であること。業務は単独で存在しないが、エンドユーザは独立して運用しているつもり。
- エンドユーザにとってシステムを語ることは以前よりも難しくなっている。昔は紙や電話を使っていたため、業務フローが見えていた。今はコンピュータ入力なのでなおさら業務の流れを現場担当者が理解しづらくなった。
- 上流工程では、システム全体の相互作用の仕組みを明らかにすること、つまり「概念モデルの導出」が必須である。ここで関係者全員が腹に落ちた、という状態にならないまま開発を進めてはならない。
- 概念モデルを見つけるための AsIs 分析は必須であろう。概念モデルが導出できれば、そのあとにToBe機能要件の導出へ進められる。
- よくあるERPパッケージ導入の失敗問題の本質は、本来は自社業務とERPが提供する「概念モデル」のレベルで整合性をとるべきなのに、機能レベルでチェックしてしまうことで生じる。パッケージが提供する「機能」は通常、数千もあるため、いちいちチェックすることは難しい。そして概念モデルが間違っていれば、導入したシステムは意味がなくなってしまう。
- 上流工程を「顧客の要求事項のとりまとめ」と勘違いするSIerが多い。いくら業務を詳細化しても概念モデルは浮かんでこない。これを導くのは容易ではないため、プロが必要になっている。
まだまだあったように思えるのですが、ざっとこんな感じです。そしてパネルディスカッションでの意見は次のとおり。
- 高速開発ツールのメリットは (1) 生産性が高い => はやく検証できる。(2) 自由度が低い => プログラム言語でない、ことがメリットになる。変更が発生したときに修正しやすい。汎用言語指向は、突き詰めるとExcelになり、大規模システムとしての整合性がなくなる。個別最適ではなく全体最適をめざすのが高速開発ツールの特徴。
- UIの部分は自由度が求められる反面、自由に書くと品質担保が難しいという問題がある。そのバランスをどこでとるかに明確な回答はない。ここがSIerの調整能力の見せ所。
- 高速開発ツールの導入で、上流工程の「工数」は、どう変わるのか？設計できない人材がプロジェクトに入っていれば、どんなツールを使っても工数は減らない。工数削減は初期開発ではなく、その後の保守が楽になることが大きい。
- 上流工程の段階で得られたテーブル定義に対し、その時点で現行データを新テーブルに移行する方法を提案したい。下流工程を迎える安心感が大きい。AsIs と ToBe をつなげるにはデータ移行による検証が、いちばん手っ取り早い。つまり上流工程の流れは「データモデル => データ移行 => 業務連携」という視野で進めていくのはどうか。
- 先に機能構成や、アプリのデザインや、業務連携を議論して、それからデータモデルにとりくむのはバッドノウハウに思える。
- 運用中にテーブルが変わったらどうする？設計段階では 1:1 だったものが 1:N になり、それが N:N になる、ことはありうる。それは業務の変更なので技術者は受け入れることになる。この場合もツール利用のメリットがある。ツールによる変更吸収のカバー率が高ければ、安心できる。
- エンドユーザは上流工程の段階、つまり最初の段階で UI を欲しがるものである。「許容派」は、画面上の項目からエンティティをみつければいい。「ありえない派」は、このアプローチは画面ごとに独立したテーブルをつくってしまうことにつながる懸念がある。そうなると重複項目や、類似項目が散見されるようになってしまう。この点についてもSIerの判断に委ねられるであろう。
最後にパネルディスカッションをまとめたSCSKの堀井さんの一言はよかったです。
下流工程の予算を上流工程に回せるようになることで上流工程の品質をあげられるのが、従来のスクラッチ開発との最大の違いではないでしょうか。
なお当日の発表スライドは、超高速開発コミュニティ会員の方がダウンロードできるようになっています。私のメモでは書ききれなかった情報量ですので、興味ある方は是非とも入会をご検討ください。情報収集のためのユーザ会員は無料で会員になることができます。（本イベントに参加できなかった方も資料のダウンロードサービスは利用できます。）
