Technical Notes
共通フレーム2013をベースに開発プロセスを見直してみた その4
前回のおさらい
共通フレーム2013をたよりに構成管理プロセスを見直しました。登録対象や手順を設けました。
しかしながら、開発現場からは「ソースファイルに恨みのコメントを刻むのに役立っている」と。。。
耳を傾けたこと
「開発プロセス見直しの担当者」が現場の声に対応したのは、構成管理プロセスのみ。つまり「最終成果物を探すのが難しい」の1点のみ。現場の声を聴いたのは自己満足のため！？
■開発部の声
- 当時の担当者がもういないようなシステムの改修依頼が来た際、改修の経緯がわからず、仕様判断に困ることがある。
- プロジェクト用ファイルサーバーはプロジェクトごとに管理方法が異なるので、最終成果物を探すのが難しい。担当者が退職した場合だと、引き継ぎから漏れたプロジェクトの最新ソースを探すのに一苦労した。
- 過去の見積契約内容をたどりたい場合、見積番号を調べにくい。現状では見積書ファイルは顧客名＋案件名等で管理されているが、見積番号はファイルを開かないとわからない。
■経営層の声
- プロジェクトを横断的に進捗把握できるツールがないため、個人の主観が混じった進捗報告を個別に聞いている。
- 小規模案件を多数受注している場合、誰があいているのかわかりにくい。対応期限でスケジュールが引かれているケースもあるため、案件引合時に空きリソースを判別しにくい。
関連するプロセスを見出す必要がありそうです。
現場の声1．改修の経緯がわからず、仕様判断に困ることがある
そもそも「改修」ってなんのことか？改修は改修だろう。。。google先生に頼らずに自分で考えてみることにします。
「システムの仕様を変更し、プログラムに変更を加えること」
「システムリリース後の機能変更や追加」。これはシステムを利用する人の視点でしょうか。プログラマ視点で考えると、システム構築中でも「作成終了したプログラムを修正するケース」もあてはまります。
ここでは改修を「システムの要件、システムの仕様、ソフトウェアの仕様、プログラムの仕様に変更を加えて、システムを再リリースするまでのプロセスこと」と定義します。
では、「改修の経緯がわからず」とはなんのことでしょう？シチュエーションを想像すると、
- お客様から「システムが出力している合計金額が合わない」との連絡を受けたシステムエンジニアが調査したところ、プログラムは設計書のとおりに金額出力していた。ただ設計書の改訂履歴を見ると、お客様からの指摘により改訂されて現仕様になっていた。この改訂を破棄して元の仕様に戻せばよいのだが、なぜこの改訂がなされたのか、知る人がいない。お客様に確認しても、「そんなことあったかなぁ。あったような気がするなぁ。どうだったかなぁ。わからないなぁ。そっちで何とかしてよ」との回答をいただいた。そしてシステムエンジニアは重たいため息をついた。
- システムエンジニアが、機能追加しようと設計書を読み込んでいたところ、矛盾した仕様を発見した。改訂履歴をみたところ、仕様変更があり複数の機能に同じ処理を追加しているが、特定の機能だけは他と同じ仕様にすることはできない。このままの仕様だと、システムの要件を一部満たすことができない。それでも良いという合意のもと対応されたのか？お客様もシステムエンジニアにもわからない。
そしてお客様とシステムエンジニアは苦笑いをした。- プログラマが、修正作業のため修正箇所を確認していると、理解できない謎のロジックが追加されているのを発見した。プログラムの部分的な修正だけと踏んでいたが、このロジックがあるために、どのような影響を与えているのか全体的に調べなくてはならない。面倒なのでやりたくない。システムエンジニアにこの修正目的を確認しても知る人がいない。
そしてプログラマはイライラした。
このような状況下で、「仕様判断」は何をさしているのか。
- 過去の対応が不完全なため、変更した内容をそのままとすべきか、変更を加えるべきかの判断。
最後に、「困る」とはどういうことでしょうか。
- お客様が「正しい仕様？そんなの覚えてねぇー、いいからやれと」おっしゃるが、「やれ」を実施するのがハイリスク。何か問題がおこったら、どうせ、めちゃくちゃ怒られるんだろう。こんな担当やりたかない。
- 仕様を提示した通りに修正してくれればよいのに、プログラマが悲鳴をあげている。うるさい。進捗ミーティングの際、横柄な態度をとるようになった。
- なんでこんないい加減な仕事をどいつもこいつもしてるんだ、今日中に完了しろと言われているのに、こんな広範囲な作業できるか。腹たつなぁ。
なるほど、これは困る。「ソースファイルに恨みのコメントを刻むのに役立っている」という理由をよーく理解できる。
人間味ある対応
「改修する」人たちは、なにかしらの矛盾を見つけたとき、矛盾を生み出した経緯を知りたがります。そして過去の記録を探しまわります。矛盾が解消されてもされなくても、探し回る手間に不満を感じます。どう対応すべきでしょうか？
愛で解決する。
これに尽きるのではないか。しかし「プロセスに不具合があるから問題が生まれる」と信じ、過去のプロセスを探ることにします。
共通フレーム2013からプロセスを想像してみる
いずれの問題も、過去の改修は仕様変更の手続きにのっとり、 お客様のレビューも実施しています。プロジェクトごとに管理方法がことなり、変更結果だけ記録されたものがほとんどでした。記録上暫定対応なのか恒久対応なのか判断できなく、複数の当事者間でことなる認識のケースもありました。
共通フレーム2013「1.3 合意・契約の変更管理プロセス」では、以下のように定義されています。
合意・契約の変更管理プロセスの目的は、取得者と供給者の二者間で締結した契約内容に影響を与える変更要求が生じた場合、二者間で合意できる新たな契約内容を導くことにある。このプロセスは取得者または供給者の変更要求の提示で始まり、変更要求の取り下げ、全部又は一部了承など二者が合意する結論で終わる。
契約にかかわる変更については、お客様との取り交わしが厳密に行われており、今回ヒアリングしたケースはマッチしませんでした。
共通フレーム2013「2.2.6 要件の記録」では、以下のように定義されています。
要件定義者は、ライフサイクルを通して及びその後も、要件管理に適した形式で、利害関係者要件を記録する。
この一文を読んだとき、ある先輩ＳＥの発言がフラッシュバックしました。
小規模だからと言って、要件定義をさぼっていないか？
新規にシステムを構築する場合、要件をまとめあげるシステムエンジニアがいて、システムを設計・製造するメンバーとは別の人が行うことが多いです。そして、無事リリースされてから数年後、お客様からちょっとした改修したいことが列挙された要望リストが提示されることが少なくありません。
この改修を担当する人は、設計・製造を担当していたシステムエンジニアやプログラマであることがほとんどです。そして、彼らは要件定義を見直すほどの、改修はないと判断しがちです。よく知っている設計書に新しい仕様を追記していくのです。改版履歴もきちんと残して。。。
「ライフサイクルを通して及びその後も」というのはとても重い言葉です。当たり前のことを実行することほど難しい。予算との兼ね合いで要件は知らないけど、「こんな画面、こんな機能を作る。」と宣言してしまえば、システムは構築できてしまいます。本当にお客様のためになるシステムづくりの基本は、お客様の視点を持つことすなわち
要件定義者は、ライフサイクルを通して及びその後も、要件管理に適した形式で、利害関係者要件を記録する。
この考え方を、実践しているプロジェクトもありました、プロジェクト開始後、設計書の修正から入るのではなく、少ない工数をやりくりしながら改修の目的、経緯、対応方針をA3用紙1ページにまとめあげ、要件にかかわる事項をお客様と共有してから、設計作業に入っていました。
共通フレーム2013からプロセスを開発プロセスを見直してみる
小規模な改修案件の多くの場合、要件は見積の前提に記載され、設計者が要件定義書で合意する内容が見積書の前提条件に記載されます。そのため、WBSに、要件定義作業が割愛されケースが目立ちます。お客様との要件の合意は見積書なされるからです。
社内の見積作成の流れを要約すると次のとおりです。
- 担当者アサイン
- 見積者の決定
- 要求仕様の把握
- 担当者による要求・要件仕様の把握
- 担当者アーキテクチャの検討
- 開発部1次レビュー
- 開発工数の算出
- 開発規模の把握
- 標準工数の算出
- WBS作成
- 開発スケジュールの検討
- 要員配置
- 工数最終決定
- 見積仕様作成
- 開発部2次レビュー
- 見積承認
- 見積書作成
- 開発部3次レビュー
- 会社レビュー
- 顧客提示
2.3.開発部1次レビューでは、業務機能とシステムの実現可能性を中心にレビューが行われます。4.4.開発部2次レビューでは工数や前提条件の妥当性を中心に判断が行われます。5.2.開発部3次レビューでは事務手続き上のチェックが行われます。
要件定義が必要かどうかを決定するプロセスについて、共通フレーム2013では「テーラリング」とよばれるタスクが定義されています。社内の手順ではテーラリングに相当するタスクはありません。
2.3.開発部1次レビューのタイミングで、テーラリングを行うよう社内のルールを変更します。テーラリングには標準ＷＢＳの準備が必要になるため、合わせて作成することにしました。
次回は
標準WBSの作成を行います。
