前途多難な要件定義が終わり、次のステップ「設計」に移ります。 作成した要件定義書を手に、どのような思いで設計に取り掛かったのでしょう。

要件定義の実務研修が一段落すると次のフェーズである設計の研修に入ります。
開発の流れの中では基本設計に当たる作業です。
　
　
　

基本設計

要件定義はお客様の要望をまとめる段階ですが、基本設計はそこから一歩進んで、要望をシステムとしてどう実現していくかを考え、そのためにどのような方法を用いるかをまとめていく段階です。

どのような画面なのかということや、データベースにどんな情報を入れるのかといったことなどを考えていくのです。

具体的には以下の事柄を行います。

• 方式設計・・・システムの構造や実行環境、開発環境やテスト環境、設計や実装を行う際の考え方の方針・記述方法を設計する
• システム構成・・・システムのハードウェア構成や、サブシステムの構成
• 運用設計・・・セットアップの手順やメンテナンス・バージョンアップの際の作業等、システム完成後の作業を設計する
• 機能設計・・・システムが提供する機能の一覧を記述する
• 業務フロー・・・ユーザの業務の流れを整理し、運用のイメージを把握する
• ユースケース設計・・・システムをどのように使用するかを事例ごとに設計する
• 画面設計（画面遷移、画面レイアウト等）・・・そのシステムがどのような画面を表示するのか、その画面にどのようなボタンやフィールドがありどのような挙動をするのか、またその画面がどのように遷移するのかということを設計する
• データベース理論設計・・・システムに使用するデータをデータベースにどのように格納するかを理論的に設計する

反省会

まず、私たちは要件定義のフェーズで身にしみた反省すべき点を改めることと、基本設計をうまく進めていくことを目標に反省会をして意識の統一をはかりました。

そこで出た反省点として、最も次の設計フェーズでも重要となると思われたのは、仕事の割り振り方です。

要件定義のフェーズで、書類を分担することで発生した各個人のシステムに対する考え方や、書類の内容のズレが結局後々まで響いて、何度も書類の直しをしなければいけない状況を生んでしまいました。

今回はできる限り個人プレーで作業するのを避け、皆の意識を合わせていきたいと考えていました。

基本設計スタート

反省会と同時に、今後基本設計をどのように進めていくかということも考えました。

私たちは、基本設計というものが未経験なうえに「プログラミング」も未経験です。そのため、システムを考えていく際には実装面から考える事が難しく、目に見える画面を考えることから始めたいと思っていました。

要件定義書からどのような画面を作るかということと、どのように画面が遷移するかということを考え、画面に必要な機能を抽出して基本設計書として作っていきたいと考えていました。

しかし、その方法で進めていきたいということをチーフアーキテクトに相談したところ、データベースを考える際に、画面に依存したデータベースの構造になってしまい、将来的なシステムの拡張が難しくなるので良くないということを教えてもらいました。

また、オブジェクト指向による実装で利用しやすいデータベースの構造とデータベースとして性能の良い構造とは異なるので、きちんと考える必要があるという事も教えてもらいました。

画面にもデータベースにも依存しないシステムを作るためにはMVCモデルに基づいた設計をすることが大切であり、その中のモデル層から考えていくのが望ましいというアドバイスを頂きました。

※MVCモデルとは、オブジェクト指向プログラミングに用いられる概念であり、コンポーネントの役割をModel（ビジネスロジックを担当する）とView（表示・入出力を担当）、Controller（ViewとModelを制御する）に分けてアプリケーションを設計する手法。

そこで、私たちはそのモデル層の要素となるものを要件の中から洗い出してピックアップする事から始めることにしました。

データベースそして画面

モデル層がある程度固まり、次にデータベースの構造を考えました。
モデル層を考える際にピックアップした要素の中から、データベースに格納すべきデータをさらに洗い出し、データの種類ごとに分類していきます。

私たちはモデル層の要素を紙に書き出し、模造紙の上で並べ替えをしながら最初の段階の試作ER図を作りました。

データベースの構造が見えてきたところで、一つ一つの画面の構成とその画面がどのように遷移していくかを決めていく段階に入りました。

要件定義のフェーズで反省点として出た分担作業による弊害が心配だったので、出来る限り作業の分担は避けてきました。

しかし、パソコンでの作業は各個人単位で行わないと効率も悪く、期限内に全ての書類を作ることができないと考え、下記のように４人で作業を分担して進めることになりました。

• データベースの構造を決めていく人
• 一番基本となる書類である基本設計書を書き進める人
• 画面のデザインを大雑把に決めていく人
• 出勤退勤を管理する画面の印刷された帳票のレイアウトを実際に使用する人と相談しながら決めていく人

この時点では、書類内容の知識の偏りは避けたかったので、それぞれの作業を持ち回りにしたいと考えていました。

レビュー予行・レビュー一回目

レビューの日取りは当初から決まっていたので、私達はレビューの日に向けて書類を完成させようと奮闘しました。

そしてレビューの前日にはレビューの予行を行いました。
書類の製本にてこずってしまい、30分ほど開始時間が圧してしまったものの、レビュー予行の内容は、要件定義の予行ほど書類自体の至らなさを指摘されず、書類作りの作業としては少しの成長を感じました。

しかし、本番であるレビュー当日に最も重大な問題を指摘されてしまったのです。

画面レイアウト一覧の内容に不備が多すぎて、本来の役割を果たしていないものになっていたのです。画面レイアウト一覧のお手本として頂いていたデータの確認が不足していたことと、分からない点を自分たちの勝手な判断で進めてしまった結果、記入されるべき情報が全く不足している自己満足の書類が出来上がっていました。

画面レイアウト一覧や付随する画面遷移図は前日のレビュー予行の時点ではまだ未完成な部分が多く詳しく見て頂いていない部分でもあり、最悪の出来でした。

レビューを中止されても可笑しくない状態だということを言われ、相談の大切さと問題を私的な観点から勝手に自己解決してしまうことの怖さを思い知り、重大な失敗をしてしまったことで精神的なショックも大きいものでした。

しかし、このような失敗は実際の仕事上では、実務研修以上に多大なる損失となることです。研修の時点でこのような経験を積んだことを忘れずに実務に活かすことで、初めてこの失敗が意味があるものとなると思います。

その場は、レビューをして下さる側のご好意で画面レイアウト一覧以外のレビューを進めることにしてもらい、画面レイアウト一覧を修正してから再度レビューを開催して頂くことになりました。

二回目のレビューに向けて

一回目のレビューを受けて書類を修正していくことと合わせて、一回目のレビューで失敗をおかしてしまった画面レイアウト一覧は、記入すべき項目を追加して画面設計書として作り直すことになりました。

更に、今後システムを実装したりテストをするにあたって必要になるエラーの一覧と、エラー以外のメッセージも作成しました。

画面設計書は、テンプレートを作って頂き、画面レイアウトに足りない部分を新しいドキュメントに合わせて直していくという作業になりました。作業を進めていくと、画面設計書に記入しなければいけない部分について、前回のレビューの時点では全く考えられていないところが多々あり、システムについての理解と考え方の甘さを実感しました。

また、データベースの設計にも難関が待ち受けていました。
以前に言われていた実装で使用しやすいデータベースの構造と、データベースとして性能の良い構造との違いを深く考慮しないですすめていた為に、システムの全てについての技術者であるチーフアーキテクトと、データベースの技術者であるデータベースアーキテクトの認識に大きな違いが生まれていました。それぞれが納得するデータベースの構造へ固めるまでに多くの議論をする必要がありました。

しかし、その議論についてはデータベース関係の書類を担当した人のみが参加し、他の人は各自の作業に追われることとなっていました。

データベースの理解

二回目のレビューは、一回目の失敗を教訓に作業を進めたため、書類の方向性を大きく踏み外すという失敗はしませんでした。

二回目のレビューで指摘された問題は、データベースについての理解の偏りでした。作業の分担をしてから、作業の進行を優先し当初予定していた作業の持ち回りが出来ずにいたため、データベースについて確実に理解していたのは、データベース関係の書類作成をした人のみだったのです。
書類作りを優先してしまい本当の目的を忘れてしまっていた結果でした。

意識あわせの時間を考慮できなかったのは、私自身、リーダーとしての全体の作業量の見積もりが甘く、計画的な作業の進め方をリードできなかったことが原因だったと思われ、とても悔やまれるとともに反省点として是非今後に活かしたいことです。

二回目のレビューを終えた後に、全員でデータベースについての理解度を統一するための機会を持つことになりました。

チーフアーキテクトも交えて、新人全員へデータベースの構造を詳しく教えてもらう機会を設けて頂いたのですが、そこで更に画面設計書、延いてはシステム全体に影響する重大な機能の抜けを発見してしまいました。

一つの機能の抜けを修正するためにも、その機能に関る書類全てを修正しなければなりません。

やはり、システムの全貌を全員が同レベルで理解しながら一つ一つの書類を作成していかなければうまくいかないのだということを実感しました。

基本設計を終えて

全員がデータベースを理解し、その後やっとのことで基本設計書のフィックスを迎えることができました。

しかし、現在もその後の実装やテストのフェーズを進めるに従って、仕様が変更された時や詳細を記載していない点が発覚した時に書類の更新を行っています。

設計というものについては基礎研修の講義で学んでいたつもりでしたが、想像していた以上にシステムに近づいて詳しく考えなければならない部分が多く、それが今後のフェーズを左右するものだということを知りました。

一つ一つの作業をするにあたっても、不明な部分、曖昧な部分を相談や質問によってはっきりと確定していくことがどれほど大切かということも身に沁みました。

次はいよいよ実装のフェーズに入ります。要件定義や設計とはまた異なる分野へ取り掛かることに期待と不安を同時に抱きつつ、日々精進していきたいと思っています。