Technical Notes
テクニカルノーツ
開発プロセス
-
2014.11. 7共通フレーム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の作成を行います。
-
2014.4.23
共通フレーム2013をベースに開発プロセスを見直してみた その3
前回のおさらい 「共通フレーム2013」を入手し、開発プロセス再構築についてのディスカッションを繰り返した結果、問題の本質を把握することの重要性に気が付いたのでした。 現場の声 「現場」を「開発部」とした場合、と「経営層」とした場合では、問題の質が大きく異なることがわかります。 ■開発部の声 当時の担当者がもういないようなシステムの改修依頼が来た際、改修の経緯がわからず、仕様判断に困ることがある。 プロジェクト用ファイルサーバーはプロジェクトごとに管理方法が異なるので、最終成果物を探すのが難しい。担当者が退職した場合だと、引き継ぎから漏れたプロジェクトの最新ソースを探すのに一苦労した。 過去の見積契約内容をたどりたい場合、見積番号を調べにくい。現状では見積書ファイルは顧客名＋案件名等で管理されているが、見積番号はファイルを開かないとわからない。 ■経営層の声 プロジェクトを横断的に進捗把握できるツールがないため、個人の主観が混じった進捗報告を個別に聞いている。 小規模案件を多数受注している場合、誰があいているのかわかりにくい。対応期限でスケジュールが引かれているケースもあるため、案件引合時に空きリソースを判別しにくい。 開発部からの声は、構成管理にまつわる内容が半数をしめており、引合から保守作業の情報と成果物との紐づきに問題が集中していることが分かりました。 経営層からは、状況把握に関する内容が主であり、プロジェクト状況の共有方法について課題があることがわかりました。 まずは構成管理プロセスの見直し 現状の構成管理は、Subversion、Git、VSS、TFSなどの構成管理システムがプロジェクトごとに構築されている状態です。また、ファイルサーバー上に開発機を仮想マシンごと格納するといった特殊なケースもありました。 構成管理の対象も、ソースファイルだけのプロジェクトもあれば、リリースモジュールを含めているもの。ドキュメントも構成管理システムに格納しているものもあります。 「共通フレーム2013」によると、「ソフトウェア構成管理プロセス」と比較すると、 a) ソフトウェア構成管理戦略が作成されている。→構成管理手順は個別に作成しているケースもありますが、構成管理の手順がルール等を文書化したものはありません。 b)プロセス又はプロジェクトによって生成される品目が識別され、定義され、ベースライン化されている。→管理対象のベースライン。。。ありません。 c)品目の修正及び、リリースが制御されている。 d)品目及び修正の状態が記録され、報告されている。 e)品目の完全さ及び一貫性が確保されている。 f)品目の保管、取扱い及び納入が制御されている。→リリースの単位ごとにタグ打ちしているプロジェクトもありましたが、多くのプロジェクトでは、コミットをしているだけの状態です。→チケットシステムと構成管理システムが連動していないため、コメントを頼りにトレースすることになります。厳密な管理はできていません。 かいぜん 社内の構成管理サーバーをＧＩＴに統合し、ガイドラインを設けることにします。 ソフトウェア構成管理のガイドライン抜粋 管理対象物を次の通りとする。 ソースプログラム ソフトウェアビルドに関するコンフィグレーションファイル 納品対象のプログラム実行ファイル 納品対象のドキュメント 納品対象のコンフィグレーションファイル 管理対象物は、構成管理サーバー（資産管理番号 ＸＸ-ＸＸＸＸＸ）で管理する。※GIT利用手順参照 リビジョン設定のベースラインを次の通りとする。 リリース・納品時 管理対象物を社外へ提供する時 構成管理サーバーに過去資産を移行し、社内に周知しました。 社内周知の抜粋 寄せ集めであるわれわれのGitリポジトリは弱さではなく、力であることを知っている。われわれはSVN教徒、VSS教徒、TFS教、Git教、そして無信仰の人々の開発部である。帯広市内から来たさまざまな開発文化がわれわれを形づくっている。われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋を味わい、暗い歴史を超え強く立ち上がり、団結を強めた。だからこそ、過去の不在担当者への憎しみは乗り越えられると信ぜずにはいられない。開発文化間の隔たりは解消され世界が小さくなるにつれ、共通の人間性が現れると。そして、開発部は新たな構成管理サーバーへのライブラリアンとしての役割を務めねばならない。 ありがとう。バラク・オバマ。 ありがとう。どうしんウェブ。 そして歴史は繰り返す 社内統一の構成管理サーバーを構築し、利用手順やガイドランも設け、自分の仕事は終わった感でいっぱいになった「開発プロセス見直しの担当者」は、高楊枝で過ごしています。しかし、開発部員から「問題が解決していない」との声が聞こえ始めます。 われわれはソースデグレードやドキュメント不備による仕様祖語の苦渋をGitリポジトリに深く刻むことを覚えた。だからこそ、過去の不在担当者への憎しみは乗り越えられる。しかし、深く刻まれたコメントだからこそ、聞こえてくるのは呪いの言葉だけである。 次回は 構成管理サーバーを構築し格納対象を決めたにも関わらず何が足りていないのか。「共通フレーム２０１３」をベースに現場の声を取り込みます。
-
2014.3. 8
共通フレーム2013をベースに開発プロセスを見直してみた その2
前回のおさらい システム開発の経典を探し求め、ようやく手に入れた「共通フレーム2013」。 難解な経典に辟易しながらも、ディスカッションを繰り返すことで問題点の抽出までたどり着く。 ようやく開発プロセス再構築のスタートラインに立ったのでした。 魔法の杖 ディスカッションの目的は、「共通フレーム2013」と比較し作業プロセスに内在する問題点を発見することでした。問題を重みづけし、順次ガイドラインに盛り込んでいくことで、開発プロセスの見直し作業を完了する予定でした。 「共通フレーム2013」を読み込むことで開発プロセスが整備される。きっとそうに違いない。なぜなら、あんなに苦労して経典を手に入れたのだから。 わたしは、この作業を進めるにあたってかような幻想を抱いておりました。しかし、いくら読み込んでも「魔法の杖」が見つからないのです。 【共通フレーム2013 共通フレーム概説より】 1. 共通フレームの目的 共通フレームを産業界で「共通の物差し」として用いることにより、国内における「システム及びソフトウェア開発と、その取引の明確化」が可能となるだけでなく、増大するシステム及びソフトウェア開発の国際取引においても相互理解を容易にするなど、市場の透明性を高め、取引のさらなる可視化を実現する。 5.2 共通フレームで取り決めていないこと （１）文書化の詳細を規定しない 共通フレームは、文書の詳細な規定は行っていない。 共通の物差し。。。文書の詳細な規定は行っていない。。。 あッ！ わたしに見えていた「魔法の杖」はこの瞬間、「三菱鉛筆」であったことを知りました。 なるほど。共通フレームからあるべき作業プロセスをマッピングすることで社内の作業の品質が向上するわけではないということでしょう。それはそうだ。 しかしながらせっかく社内の作業プロセスを洗い出しているのですから、前回「共有した問題点」を改善する施策を盛り込むことにします。 銀の弾丸 共通フレームと社内の開発プロセスをマッピングしただけでは、「やっぱり上流は大事だよね」「手抜きしちゃだめだよね」等々、タスクの「抜かす」「省く」を、ルールとチェックで縛るのが限界です。しかし根本的な問題として「顧客合意したにも関わらずテスト段階、納品後に仕様が変わる」といったタスクの品質については是正できません。 テクニカルプロセスに関する、先人たちの知恵が詰まった問題解決メソッドを手に入れるため、あちこちの情報をかき集めました。 「発注者ビューガイドラインの公開」 むむむっ。IPA頑張っている。先人たちの知恵がまとめられている。 今度は「銀の弾丸」を手に入れたここちです。 さっそくガイドラインを参考に、いままで使っていた成果物テンプレートの修正作業を行い始め、設計エリアについてテンプレートを修正を行います。 問題は何か テンプレートへ「発注者ビューガイドライン」を反映する作業に明け暮れ、ひと段落したとき、グループディスカッションを開催しました。 「ルールや担当者の意識が改善しなければ、タスク品質は向上しない」 「テンプレートで目に見える問題が解決するのか疑問」 恥ずかしながら、テンプレートの作成に没頭しているうちに、テンプレートを作ることがゴールになっていたことの指摘を受け、懐に隠し持っていた「銀の弾丸」は「チオビタドリンクの空き瓶」であったことに気づいたのでした。 フレデリック＝ブルックス氏の"No Silver Bullet"（銀の弾丸などない）では、 ＜wiki pediaから引用＞ ソフトウェア開発の複雑性について 偶有的な複雑性は、ソフトウェア開発者自身が発生させていて解決可能な問題に間連する。例えば、アセンブリ言語のプログラムコードの記述と最適化や、バッチ処理によりもたらされる遅延は、偶有的な複雑性に由来する。 本質的な複雑性は、解決するべき問題によってもたらされる。そして本質的な複雑性を取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。 過去に行われてきたソフトウェア技術の発展は、ソフトウェア開発における偶有的な複雑性を攻略した。 ただし偶有的な複雑性に対する攻略であって、本質的な複雑性に対する攻略ではない。 利用者が３０の異なることを行うことを望むならば、テンプレートは３０の中に入っていたのか？ 仕事の仕方。。。 次回からは 次回は、解決すべき問題が「何を実行することなのか」をスタートラインに、改善策の検討を行います。
-
2014.1.23
共通フレーム2013をベースに開発プロセスを見直してみた
共通フレーム2013を購入するところから 「独立行政法人 情報処理推進機構（IPA）著 共通フレーム2013」をようやく購入しました。 会社にお願いして昨年手に入れようとしたのですが、書店ではすでに在庫がなく、図書館の蔵書まで探していただきました。司書曰く、「北海道には蔵書がありません。国会図書館か近畿の大学の蔵書ならあります。郵送で貸出しすることができますよ。」 すばらしい。図書館ネットワーク恐るべし。 さらに曰く、「出版社に問い合わせたところ、近々増刷の予定があるそうで、・・・（増刷予定の親切な説明）・・・、お急ぎなら、蔵書を郵送しますか？」 すばらしい。接客の鑑だ。図書館司書あなどりがたし。 結局、増刷後、IPAから直接購入しました。 どう見直すのか 前置きがながくなりましたが、既存開発プロセスを見直し、「共通フレーム2013」を反映します。現状の自社開発プロセスは独自基準。「共通フレーム２０１３」をベースにIPAの各種ガイドラインで再構成します。 長年、当社ではKKD手法をベースとした。。。古代バビロニアから伝わる。。。。プリンシプルな開発手順が数パターン存在しております。それらを案件に応じてテーラリング・実行といったスタイルです。今回の取り組みは「共通フレーム2013」のソフトウェア実装プロセスを中心にマッピングしなおし、不足している基準を検討します。 現状の開発手順「簡便なツール開発レベル」の手順（抜粋） 1. 提案・見積時 1.1 適用業務範囲の妄想 1.2 ツール摘要作業範囲の妄想 1.3 ソフトウェア構成の妄想 1.4 ツール機能一覧洗い出し 1.5 開発規模算出 1.6 WBS作成 1.7 要員スケジュール作成 1.8 開発スケジュール作成 1.9 前提条件作成 2. 受注 3. 設計～テスト 4. 納品～検収～売上 共通フレームのソフトウェア実装プロセスに強引にマッピングすると、、、 共通フレーム2013のソフトウェア実装プロセスのアクティビティを自社の「簡便なツール開発レベル」に当てはめてみると、小規模開発の場合、要件定義は見積、引合段階で行うことがほとんどで、以下のようになりました。 2.4 ソフトウェア実装プロセス 2.4.1 ソフトウェア実装プロセス開始の準備プロセス →1.6 WBS作成 2.4.2 ソフトウェア要件定義プロセス →1.1 適用業務範囲の妄想 →1.2 ツール摘要作業範囲の妄想 →1.3 ソフトウェア構成の妄想 →1.4 ツール機能一覧洗い出し →1.9 前提条件作成 2.4.3 ソフトウェア方式設計プロセス →1.3 ソフトウェア構成の妄想 →1.9 前提条件作成 マッピング結果をベースに社内で検討した結果 ソフトウェア要件定義プロセスは、設計の開始時点もしくは、基本設計の初期段階で「発注者ビューガイドライン システム振舞い編」に従った作業が終わった状態とイコール。小規模でも（ドキュメントとしては枚数がすくないかもしれないが）、ソフトウェアをブラックボックスとした発注者視点のできることとできないことを書面で合意しておくことが必要ではないか。 ソフトウェア実装プロセス開始の準備プロセスは、小規模であるからといってタスクをまとめるだけではなく、「EVM活用型プロジェクト・マネジメント導入ガイドライン」に従った管理指標を設定する必要があるのではないか。 小規模案件はとくに顧客に費用転嫁しないよう、管理資料に時間をかけすぎない工夫が必要。 等々 検討してわかったこと 小規模だからと言って、要件定義をさぼっていないか？ 要件定義が不要なのではなく、設計開始時点で明確になっているから工程として設けていないだけ。 少人数だからと言って、実績工数管理をさぼっていないか？ だいたいでは済まされない、積み重ねが見積精度の改善・向上につながる。 反映作業はこれから、、、 2014年4月までに完了させる予定です。経過は順次公開していきます。（できる範囲ですが） →次回 共通フレーム2013をベースに開発プロセスを見直してみた その2
