新ITの導入・システム開発のプロジェクトが進み、外部設計もしくは基本設計と呼ばれる段階に入ってきました。
発注側からすると設計行為ですので、受注側にお任せ段階に入ったと思いたいところですが、このフェーズまでは発注側も気を引き締めて対応していきたいところです。
その理由は、
ITシステムの外から見た仕様、特にエンドユーザが関わる観点で確定しなければいけないため。
ITシステムの基盤設計において能力・性能・安全性等を確定しなければいけないため。
総合テストの裏返しとして、仕様を確定、テストシナリオを作れるレベルにしておかなければいけないため。
ということで、発注側が強く関与する必要があり、しっかり関与しないと後から揉めごとになるので、注意が必要です。
外部設計と基本設計とは
外部設計と基本設計を併記しましたが、基本的には同じものを指しています。
方式設計やベンダーによってはまったく別な表現をしていることがあります。
基本設計の次に続くものは、詳細設計となります。
あくまでも言葉としてですが、基本とか詳細とかいってもどこからがそうなのかがわかりづらいでしょう。
基本という言葉が要件定義的なことも含んでいて、そもそも曖昧な言葉になっているかと思います。
ここでは外部設計とします。
外部設計は、外部から見える部分の設計ということになります。
とはいうものの、データベースの設計も確定する必要があります。内部のようで、外部に影響するものなので、設計は必要です。
基盤部分は方式設計と言えるものとなります。
外部設計での発注側から見たタスク
外部と言いながら、画面や帳票といった実際に見えるものと、その他の見えないものが対象となります。
見えるものについては、ユーザである発注側事業者に決定の責務があります。
もちろん、ベンダーはどのように実現できるかを設計者として提示しなければなりません。
しかしベンダーの力量が足りなかったり、段取りが悪かったりということは往々にしてあります。
進捗状況を見るために成果物の定量的な情報を把握します。
外部設計での見えない部分の網羅性
見えない機能部分のタスク
画面や帳票と言った見える部分は比較的分かり易いですが、見えない部分もあるため、どのようなタスクがあるのかが分かりづらくなります。
では、どのような見えない部分があるのでしょうか。
外部設計における内部処理ロジックの設計の網羅性
まず、処理ロジックです。
同じように見える一機能であっても、内部の処理ロジックにより複雑さはかなり異なります。
重要な部分ほど共通化されており、複雑かつ影響度も大きくなりがちです。
重要な部分は同じ一つのタスクでも3つ分として見るなど強弱をつけておきます。
外部設計における外部連携設計の網羅性
次に、外部連携です。
外部システムとの連携はシステム間で行われるので動いてはいるが見えないということになります。
しかし、画面と同じように設計が必要です。
難しいのは、相手がいることです。自分だけで決められるものではなく、相手との決めごとが設計となります。
よって、相手とのやり取りを踏まえてタスクを計画する必要があるため、より重いタスクとして見込んでおきます。
さらに、相手システムと自分のシステムの仕様を押さえておく必要があります。
同じように見える項目であっても、実は税抜き金額と税込み金額のように差があるなど、認識のずれが生じることがあるため、調査等のタスクも考えておきます。
外部設計におけるデータ設計の網羅性
そして、忘れてはいけないのが、データの設計です。
データの設計はあとから変えると影響が大きい場合があります。
変更の影響がなるべくないように設計するのがテクニックではありますが、データの複雑さは設計の複雑さとなっていくのが普通です。
そのことを踏まえて、後から複雑さを入れ込むことがないよう、最初から設計段階で、データの持ち方を設計します。
システム内部のことなので、ユーザ側としては、うまくやっておいて欲しいというところかもしれませんが、少なくとも重要な部分はよく確認しておく必要があります。
データは項目だけではなく、発生、蓄積、更新、消失のサイクルを考慮して、いつどのようになっているかを把握します。
リアルに見たいデータが翌日しか見られない、あるいは逆に翌日でもいいのに無理やりリアルにしてシステム負荷が上がってしまうといったことがあります。
使うシーンを元に確認すると、設計者が見落としているケースもよく見つかります。
外部設計での見えない非機能部分の設計
機能以外では非機能の設計があります。
基盤方式設計、移行設計、テスト設計、運用設計です。
外部設計における基盤方式設計
基盤方式については性能に関わる面が含まれます。性能要求は要件定義にて決められているべきものですが、それがどのような設計にて実現できるかは、発注側ではわかり得ないことが多いです。
わからないものに対して、OKなのかNGなのかは言及しようがありませんので、性能を満たす設計であることを明示させることが重要です。
ベンダー側より免責事項が並べられていることがあるかもしれませんが、構築後性能が出ないことを想定して、よく確認しておく必要があります。
外部設計におけるテスト設計
テスト設計は出来上がったものをどのようにテストして最終的に仕上げるかという設計ならびに計画になります。
作り上げるためのテスト工程なので、お任せでいいと思ってしまうこともありますが、発注側が設計段階でよく確認しておいたほうがよいです。
他のシステムと連携していれば尚更です。
開発途中でのテストについては、比較的お任せになりますが、完成品に近づいてからのテストはいかに要求が実現されているかを確認することになります。
テストの方法として不十分ではないか、あるいは確認したいことができるかを確認します。
多くの問題としては、データの量・種類を用意したうえでテストできるか、現状との比較はできるか、実ユーザの実運用を想定したテストができるか、という観点となります。
外部設計における移行設計
移行設計においては、移行要件をより具体的に計画することになり、これも重要です。
移行においては、業務とシステムをそれぞれどのように移行するのかを考えていきますので、発注側が考える場面もかなり多いことになります。
業務については、いつどのように切り替えるのか、切替前後にやることは何か、切替後のためのスタッフ教育をどうするかなど、発注側が決定の必要がある項目が多くあります。
システムについては、現行システムをいつ止めて、新システムにいつ切り替えるか、何のデータをいつ切り替えるか、といった点になります。
この中でもデータについては、業務内容そのものであることもあり、システム任せにできない部分があります。しかし、データはシステムであるイメージがあるので、発注側の関与が少なくなってしまうことがよくあります。
多くの揉め事の要素なので、発注側と受注側の役割と責任を設計しておく必要がある、という観点で確認しましょう。
外部設計における運用設計
運用についても、業務とシステムの両面があります。
新ITシステム稼働後の業務の継続性について設計するのが、業務運用設計となります。
業務フローが変更になるのであれば、組織にどのように実装するかを設計します。
システム運用は、新ITシステムを安定稼働させるために日常的に監視や保守を行うことです。
新ITシステムはそれ固有の運用が発生するはずですので、設計を行います。運用の設計により機能設計に影響が出かねません。
またその後のランニングコストにも影響します。よって、誰がどのような運用を行うかを具体的に決めます。
外部設計での発注側マネジメント法
発注側確認体制の構築
外部設計の発注側確認を行うにあたっては、確認の体制を敷く必要があります。
確認すると言っても、しかるべき人が確認しないと、ただ出てきたものをいいか悪いかを言うだけとなってしまいます。
そうなると、責任を持った回答になりませんので、結果後で揉め事になります。
すなわち、発注側としては、その機能をわかっている人が確認する体制としないといけないということになります。
わかっている人というのは、使う人とは限りません。使う人でもいいのですが、使うことを推進する人のほうがよりよいです。
どうなるべきかを認識し、コスト意識やセンスを持った人がいるのが一番よいです。しかしそのような人は大企業であっても用意できない可能性が高いです。
よってそれに近い人をなるべく用意するというのが現実的となります。
また、見えない部分の確認も可能であれば行いたいです。
見えないのですから、発注側の確認範囲ではないとも言えるかも知れませんが、失敗が潜んでいる可能性もあります。
見えない部分の失敗は、IT寄りの人でないとわかりませんので、そのような人がいればベターです。
タスクと設計書成果物の進捗確認方法
外部設計については、ITシステムのユーザが使う機能や見えない部分について、タスク化がされるはずです。
タスクは設計書という成果物に対し、作成プロセスがタスク化されます。
機能は分類され、さらに具体化された機能単位となっているはずです。
具体化されていないと、タスク漏れということになります。
作成プロセスは設計書作成という一つのタスクになっていると、マネジメント面からすると不十分です。
プロセス分解の原則に従うと、4つくらいのプロセスからタスク分解されているべきです。
すなわち、機能分析、着手・実行計画、作成、仕上げ（確認レビュー）といったものになります。
タスク分解は特性に合わせて行うべきですが、4つぐらいに分かれているのは妥当です。
そして、進捗確認は、その分解したタスクに対する進捗を計ります。
作成しただけで完成と見做すと、実は手戻りが後から多く発生し、終わっていないということがよくあります。
設計書成果物の完成確認方法
外部設計タスクの進捗確認の中で、最も重要なのは完成しているかどうかの確認です。
実働するプログラムであれば動かなければ完成していないということがすぐにわかりますが、設計書ですと、未完成度合いがわからないケースがあります。
仕上げ（確認レビュー）というタスクの事例を挙げましたが、仕上げにおいては、1回のレビューではなく2回以上は予定すべきです。
仕上げにおいて初めて課題が発覚することがあります。
課題を論点として、議論が発展し、機能が必要、とか変更が必要、ということになることもあります。
仕上げ段階で課題が発覚したことが問題ではなく、まさに仕上げされていると考えるべきでしょう。
ただし、プロジェクトとして考えた場合は、期間の問題が発生します。よってレビュー期間を長く取るというのは一つの手段です。
しかし、作成した後に期間を長く取るばかりが、手段ではないはずです。
やはりもっと初めの段階で議論の場を設けられるよう計画したいです。
重要機能においては、レビュー期間や回数だけではない尺度を持って、予め計画されているのが望ましいと言えます。
論点進捗で見る外部設計マネジメント
タスクの進捗以外の観点で、論点進捗という観点があります。
これは上流の工程でも出てきたものですが、外部設計段階でも論点マネジメントは必要となります。
機能はメイン・サブ、難易度の高低、機能間・システム間連携有無などから分類できます。
そしてそれらは重要性や規模に関係してくるでしょう。
重要であったり、複雑であったりすると、タスクの考え方も変わってきます。
どのように実現するか、機能は足りているのか、他に影響していないか等議論したうえで、設計を確定すべきです。
作成してからわかるのでは遅いので、作成する前に見出したいです。
理想的には設計タスクの前段階である分析段階で論点を見出し、論点を潰していくことを含めた計画を立てる段取りとしたいです。
論点が明らかになっていれば、論点の数が潰れていき、設計に反映されれば実際の進捗が見えることになります。
ただたんに設計書が作成されているかどうかだけではなく、必要な議論がなされた上で、正しく設計されているかを見る視点が増やせます。
課題消化進捗で見る外部設計マネジメント
論点と似ていますが、課題についても進捗の指標として監視していきます。
課題は、計画に対する進捗を阻害するものです。
課題から解決のための論点は抽出されますが、論点とならないものもあります。
論点として扱うほどのものでないものと、論じるまでもなく是正すべきものがあります。
従って課題のほうが大きい概念となります。
課題は、上流工程でも同様でしたが、最初の段階で多く発生すべきです。
発生していないと問題がなく進んでいるというよりは、課題が見出せていないので、後から課題が発生すると思っていたほうがいいです。
よって、課題の発生状況と消化状況を日々のトレンドとして把握することで、タスク進捗とは別の切り口での進捗を計ることができます。
外部設計マネジメントでのありがちな問題
設計が終わらず申し送りとなることが多く、重要なことほど申し送られる
外部設計においては、要件の実現方法として論点が発生し、検討するケースが多くあります。
プロジェクトは期間が決まっていますので、作業として設計を進めていきたいという特に受注側ITベンダーの気持ちは理解できます。
しかし、肝心の論点が議論されないまま、想定で進められてしまったり、そもそも論点が抽出されていなかったりして、進んでしまいます。
そのまま工期を迎えると、間に合わなかったものについては申し送り事項として、次工程が進められてしまいます。
得てして、重要なものほど議論が必要ですので、時間を要し、結果先送りとなってしまうことがあります。
決定にあたり関係者が多いものは特にそのような傾向にあります。
決定は発注者側である認識で、受注者は判断を委ねてしまう傾向にあります。
決定させるのは受注者のプロとしての役割ですが、意図した時と意図しない時はありますが、できていないことはよくあります。
重要であったり、複雑であったりする事象ほど先に検討していかないといけません。
内部設計を始めてしまっていて、肝心の外部設計が検討されていない
それほど大きくない規模のシステム開発であれば、設計と実装を分けて考えなくてもアジャイルで開発するということはあるでしょうが、一定規模であれば、順次段階的に設計していかないと、逆に手戻りが多くなり工数増加の原因となります。
外部設計段階では、機能の連携や機能間整合性、もしくは外部連携も含めて一貫した整合性を保たないといけません。また要件を充足し、ビジネス目標を果たさないといけません。
その中で、内部設計を部分的にでも始めてしまうと、整合性が保てなくなる可能性が出てきます。
もっと問題なのは、ある機能において内部設計を始めてしまい、外部設計の確認すべきことができていないことです。
エンジニアは作ることに着目してしまいがちですので、どう作ろうかを検討してしまいます。
最悪な場合は作り易さを優先してしまいます。
その場合、得てして発生する問題は、実現すべき機能が実現できない、ということです。
ある設計が終わらないと始められない設計は、それが終わらないと逆に始められない
システムの設計は一定規模以上となると複雑で、機能が関連し合っています。
設計の段階で、一部機能を呼び出すことが前提になっているようなことがあったとして、その呼び出す部分の設計を保留にしていたとします。
呼び出される側の設計は、呼び出す側からどのように呼び出されるように設計するのかが決まるのを待っていました。
よって、設計は進んでいませんでした。
ということが起こり得ます。
うまく設計しようと工夫しようとすると、逆に複雑に絡み合ってしまい、進みづらくなってしまいます。
蜜結合、疎結合という言葉があり、蜜結合であるとこのようなことが起きると言われていますが、実務上はそればかりが原因ではありません。
解決にあたっては、スキルの高い設計者が必要です。
発注側としては、設計にてこのようなことが起きてしまうのは、理解しがたいことかもしれませんが、後々大きな問題となります。
要求や要件の不明確さにより設計が上手く進まないというITベンダー側の言い訳にさせないために、設計スキルの問題であることをよく見極めたいところです。
IT導入・システム開発での外部設計マネジメントで本当にやるべきこと
ITシステムの外部設計というと外部というだけに、操作や参照する見える部分の設計と思えますが、見えない部分の割合も大きいです。
そして、全体を設計し整合性を保つのは、それ相応のスキルが必要です。
実行する前に、委託する人がスキル保有者であるかどうかは見極めたいですが、まだ実行していない段階では何ともいえないことが多いのではないでしょうか。
発注側は、自ら利用する部分の設計においては責任があるかもしれませんが、それを実現するのは受注側の問題です。
仲良く進めていると、いつの間にかうまくいっていないことがすべて発注側の責任、すなわちすべてのコスト負担を強いられることになりかねません。
また設計途中で発生する課題・問題を解決に導くのは、スキル保有者であり、プロである受注側ITベンダーでありますが、その力量を見極めるのは素人ではかなり困難と言えます。
しかし素人であっても3点ほど気を付けてもらえれば、かなり問題を防止できます。
まず1点目は、要求をブラさないことです。要求は構想・企画段階で決めており、要件定義にて実現方法を具体化しています。外部設計は要件定義に基づいて進めているはずです。
要求はビジネスに直結していますので、何をすべきかが表現されているはずです。
システム開発は進めていくうちに、ブレが生じがちですが、目的に立ち戻り、そしてブレないようマネジメントしていくことです。
仮にブレたら、変更を認めて、対応していくしかありません。
2点目は、役割分担を明確にすることです。
受注側はプロのはずですので、プロとして仕事を遂行してもらわないといけません。発注側は発注側としての要求提示や成果物の確認が役務になります。
上手くいっているときはいいですが、うまくいかなくなってきたら、受注側に手のひらを返されます。仲良くやっていると同じ穴に入れさせられてしまいます。
やはり発注側と受注側の役割を保ったまま、常に責任を意識して対応していくことです。
そして3点目が客観的な進捗状況確認です。
進捗のマネジメントは先述のとおりではありますが、実務上は、様々想定外の問題が発生します。
特にまだ上流工程と言える外部設計までの段階においては、仕上がり具合が最後まで分かりづらいです。
できる限りタスクを詳細化して、進捗を計測するのと同時に、その進捗が妥当なのか、本当の要求を満たしたうえでの完成状況なのかを見ていくことです。
これらのことは、できる人は少ないかもしれませんので、他に頼める人がいれば頼むというのも一つの手段です。
コメント