5.実務的観点から
実務においては、というとかなり畏まった言い方のような気がしますが言ってしまえば会社でやっているときにはという程度の意味合いです。
この前提でいくつか書いていきます。
社に所属してプログラムを作成するという時にはその利用が社内だけで完結する場合もあれば成果物としてそのプログラムを納品する、つまりは社外に取引先が居るという場合もあります。
前者では特に厳密な工程は無くほぼ何となくで作っている事例も多々ある気がするため、今回はわかりやすく対外的に作成して売るような事例で考えます。
また観点に関しても発注側・受注側の両方を含むような書き方をします。まず会社対会社のやり取りにおいては最初に契約を交わすことが殆どですがこれはここでは扱いません。契約後にどのような制作を行うかの会議が始まります。
ここでどのような出力にするのか扱うデータがどのようなものか、処理内容はどうか、納期はスケジュール、費用と言った項目を定めます。納期や費用については契約前に数社に声掛けをして提案からコンペをしたり入札制度をとることもありますが今回は簡単のため要件定義でまとめておきます。この点については読者の方々の状況に応じて調整して読んでください。
要件定義において、特に新規開発の場合において、重要となるのは開発の基幹部分と付随する派生部分の境界設定があります。
何を優先して作成するかという優先順位付けにも近い話でありこの基幹部分があまりにも大きすぎたり複雑なものだと開発工程もそうですがその後のテストが長引くことが多く、テストで問題が発生するとさらに修正というループに陥ることもあります。
そして期間の延長にも繋がりやすく費用的な面でも良いことはありません。基幹部分は(派生部分もそうではありますが)できる限り簡素に出来ないかと言う視点は持っておいた方が良いでしょう。また、開発と言うと受注側を完全に専門家として信頼しきって丸投げをする場合もありますがこれも非常に良くないパターンです。
現代の社会構造の是非はともかくとして、基本的には個人も会社も分業となっています。各々の特異なことを活かして頑張っていきましょうという姿勢であり全員が全員、全ての領域を理解して実践する必要はないのです。むしろ現代でそれをやると先に寿命が来ます。
そうして分業で動いている以上受注側として実装する会社にあるのは要件定義に基づいて開発をする責任であり、要件定義を完全に1から起こすというものではありません。要件定義はあくまで両者の意見と可不可の領域のすり合わせを行うものであり、需要から状況やらを掘り下げるのは発注側の責任です。
そうして発注側としては何をしたいのか、どういうデータを扱うことを想定しているのか、処理内容はどうか、最後にどのような出力を得るのかを考えます。受注側はその要望に基づいて開発が行えるのか、技術的に不可能なことは無いのか、というものを返します。
この調整を経て出来上がるのが要件定義であるべきで一方的に投げつけたり要求を圧すのはまた別種の何かと言っていいと考えています。また、技術的制約については起こりえる範囲の話ですがこれを回避して別の手段での実装を検討するのか、あるいは発注側のデータに加工を行うことで問題に対処するという例も考えられます。
このような場合には完全に開発側だけで話が終わらない可能性があり発注側としても何かを業務に追加するという道がある以上両者の責任範囲と内容は可能な限り明確に定めるべきです。
こうした部分が曖昧なまま開発が進むと一気に計画が破綻する未来に傾きます。結論として要件定義が最初にして最大の山場という話になります。
特に金融では実装すべき式・計算が複雑になることもありそうした実装は任せるにしてもそもそもの式の検証は必ず発注側で行うことが求められます。
当然に実装後でもその計算結果の整合性はチェックがありそのテストにパスして漸く開発が完了します。
このような感覚がないまま要件定義を進めてしまうと雲をつかむような話が延々と続いて開発に至ってしまう為各所での齟齬が起こり結果として何度も要件定義をやり直して追加開発となる事態も起こり得ます。
相手方に一方的に任せるのではなく共同して作成するという意識を持っておきましょう。
要件定義ができた後では双方の作業が始まりますがコードを書いてという作業に直でいくよりも、案件にもよりますが、処理の詳細を記載した設計書を作成することが多いかと思います。
これは要件定義で固まった内容について具体的に処理に落とす際の細かな要求を記載したものとなり大枠では処理フローに近いです。
そこにより堅牢な構造を入れ込んだり処理にかかる時間を何秒以内に落とすと言った使用する際に実用的かどうかという点も入り得ます。
特に処理速度が重要になる場合には要件定義で最大値を決めておき、各計算項目でどの程度の時間になるかを計測しつつネックを改善していくような例もあります。
設計書は主に開発側が作成して内部資料とすることが多いかとは思いますが、極端な事例に関しての処理の場合分けなどが要件定義であまり明確に決まっておらず回避したいくらいの認識だとこの設計段階で詳細を詰めていくという運用も起こり得ます。
本来は最初にやっておくのがベストなのですがこの辺りでは案件によって思いがけない問題が起きることもあり要件定義と詳細設計が螺旋構造をとることもままあります。
ただ注意していただきたいのはあくまでこの設計書はまだコードになっていない文書の段階の為プログラム、コードそのものに不慣れな人でも読めるはずです。
よって設計書ができた段階で一度発注側としても確認し互いの合意を得て開発工程に進むべきです。
ここを疎かにしてしまうと要件定義程に盤面返しとはいきませんがそれでも相応に問題の対処に時間がとられるのは確実です。
少し珍しい事例にはなりますが要件定義で合意した内容に少し誤解があってそのまま設計書を作成したところ確認した段階でその問題に気づき修正することで事なきを得たということもあります。加えてこういった資料はいずれ異動や退職で人が動いた後で実装されたシステムの中身を理解するのに役立ちます。
コードをそのまま読むのも良いのですが、その背景思想や経緯を知ることで改修の可能性や現状維持の正当性も考えられます。ですので現在の必要性とある程度先の将来を見越した資料作りをすることをお勧めします。
これよりさらに後の工程では開発、検証と続くのですが、そちらについては語ることは多くありません。しいて言うならば検証においては可能な限り実際の状況を想定したデータや負荷で試すべきですがこれをやらないというのはそもそも怠慢と言わざるを得ないので本作を読むような方には居ないと思います。
