僕がソフトウェア開発について学んでいること
はじめに
たまにはエンジニアらしいことを書こうとしてまとめていたことが、あまりに長くなったのでqiitaに投稿することにした。
マルチポストになってしまうが、本来の目的であるここにもそれをまとめておこうと思う。
おわりに、に書くつもりではあるけれど、僕はコンピュータサイエンスを学んできたわけでもなく、文系出身であり、勉強も不十分なのです。
間違いなどがあればご指摘ください。
目次
1. 前提知識
1-1. ソフトウェア工学の概略
ノイマン式コンピュータが生まれた1940年代から、ソフトウェアに対する社会的な需要は爆発的に拡大した。しかしそれまで存在していなかった「ソフトウェア開発」というものに対する経験や知識は当然成熟しておらず、需要に対する開発速度及び品質の低さが問題となった。その歴史的文脈から1960年代にソフトウェア工学という工学が生まれ、ソフトウェア開発に関する技術が研究され始めた。
ソフトウェア工学の中で、様々なソフトウェア開発方法論(SDM)が発明/定義されていった。構造化プログラミング、オブジェクト指向プログラミングなどの考え方及び技法がこれに当たる。
SDMの研究と共に(正確には相互的に内包された研究として)、システム開発ライフサイクル(SDLC)という概念が生まれた。これは開発計画から設計実装運用保守、そして廃棄までの過程を標準的なモデルとして示したものである。
以下、条件付けせずにライフサイクルモデルと記載した場合、SDLCについて言及したものであるとする。
参考資料
1-2. ライフサイクルモデル
以下、代表的なライフサイクルモデルを列挙する。
ウォーターフォールモデル
システム開発における各工程を、水が流れるように順序立てて進めていく開発手法である。
基本的に工程を後戻りさせることはせず、下記のような流れでシステム開発を進行させていく。
(引用元:http://sysdev.sakura.ne.jp/development/169)
また、昨今ではウォーターフォールはV字型の図で解説されることが増えた。
内容としては同一で、どの工程がどの工程へ対応しているかを強調する目的で表現を変えているだけのものである。
(引用元:http://sysdev.sakura.ne.jp/development/169)
メリット
- プロジェクト計画の見通しを立てやすい
- 要求定義/要件定義及び設計が先に完了するため、開発者の迷いを減らせる
- 適用開発例が多く、参考になるプロジェクトが多い
- 各工程での成果が明確になる
- 進捗管理がしやすい
デメリット
- 全工程を予め定義/作成しなければならないため、プロジェクト計画立案自体にコストがかかる
- 工程を後戻りさせることを想定させていないため、仕様変更があった際に多大なコストが生まれる
どのようなプロジェクトに向いているか
- 要求/要件/目標が固定されており、途中変更のないプロジェクト
- 予め全ての要求/要件/条件/期間/工程/責任を定義しなければならないプロジェクト
- 発注/受注案件など。
- 何が出来ていれば成約か、特に相互の責任を明確にすべき場合
- 発注/受注案件など。
- 期間的制約の強いプロジェクト
プロトタイプモデル(反復型)
プロトタイプモデルと呼ばれる開発モデルは、しばしば手法としてのプロトタイピングと混同される。
ここでは一般にプロトタイプモデルと呼ばれる開発モデルと、プロトタイピングを利用した開発を分けて考える。
まず、一般にプロトタイプモデルと呼ばれる開発手法の例を挙げる。
一般的なプロトタイプモデル
- 立ち上がり期に機能を制限した実際の製品のプロトタイプを開発し、ユーザによる評価を受け機能追加/修正していくという手法
- 純粋なプロトタイプモデル(反復型)といえる
(引用元:https://thinkit.co.jp/article/914/1)
純粋プロトタイプモデルのメリット
- 計画立案時に全ての要件を作成するコストが発生せず済む
- ユーザとの認識のズレを最小限に留めることが出来るため、手戻りの際のコストが(ウォーターフォールモデルに比べて)低い
- ユーザ自身が当初想定していなかった要求に気づく機会がある
- ユーザがコア機能を早期に利用できるようになる
純粋プロトタイプモデルのデメリット
- 画面数や機能が多いプロダクトの場合、プロトタイピング工数自体がコストとなる
- 当初に要求/要件を明確にしないため、ユーザが満足するまでプロジェクトが完了しないリスクがある
- 付随して、プロジェクト全体の見通しが立てづらい
- 評価者(ユーザ,ステークホルダ)の人数により、評価工程のコストが大きくなってしまう場合がある
- 評価者の選定が難しい
どのようなプロジェクトに向いているか
- 比較的小規模なプロジェクトに向いている
- 期間的制約の弱いプロジェクト
- 対象ユーザの課題が深刻であり、すぐさま改善を進めていきたい場合
- ユーザ自身が課題をどう解決していけば良いのか見通しが立っていない場合
- 評価者(ユーザ,ステークホルダ)が少ない場合
プロトタイピングを開発工程に取り込む例
- 上と同様、機能を制限したプロトタイプを作成するが、要求/要件定義をする目的としてプロトタイプ利用し、その後本設計を開始するという手法。他の手法と併用される場合。
要件定義のためのプロトタイピング利用手法
要求に対する提案のためのプロトタイピング利用手法
(引用元:http://f.hatena.ne.jp/teeeeeeemo/20180220175918)
プロトタイピングの目的
- ユーザとベンダの間に想定のズレがないか早期に検知する
- 要求/要件の妥当性の検証
- 技術的実現可能性の検証
スパイラルモデル(反復型)
ウォーターフォールモデルとプロトタイプモデルを併せた開発手法であると言われる。
しばしばプロトタイプモデル、インクリメンタルモデル(後述)と混同して語られることがあり、それらとの違いは理解が難しい。
特徴としては、システムを複数のサブシステムに分割し、サブシステム毎にウォーターフォールモデルで開発を進めていくという点。
サブシステム毎にプロトタイプを作成し、その後ウォーターフォールモデルで開発を行うという形。
また、サブシステムの要求定義から評価(テスト)までを反復する点にも注目しておきたい(後のインクリメンタルモデルとの大きな違い)。
(引用元:http://webpg014.hotcom-web.com/page6.html)
メリット
- 計画立案時に全ての要件を作成するコストが発生せず済む
- 一つ一つの機能(サブシステム)について、ユーザの満足度を高くできる
- ユーザが機能を早期に利用できるようになる
デメリット
- 計画立案時に全ての要件を作成する必要はないが、完成システムのイメージはステークホルダ間で共有されていなければならない
- ウォーターフォールモデルと比較すると、スケジュール/工程管理が複雑になる
- システムの分割が困難な場合がある
- それぞれのサブシステムが高い独立性を持つ場合にしか利用できない
- 評価者の選定を慎重に行わなければならない
どのようなプロジェクトに向いているか
- 作りたいものの大凡のイメージはできており、しかし全体要件を定義出来るほど要求が明確でない場合
- システムをサブシステムに上手く分割できる場合(機能の独立性が高い場合)
- 期間的制約の弱いプロジェクト
インクリメンタルモデル
個人的な見解としては、ウォーターフォールの変化系モデルであると考えている。
スパイラルモデルと同様に、システムを複数のサブシステムに分割し、サブシステム毎に開発していく手法。
スパイラルモデルと違い、全体の要求定義は先に完了させ、反復は行わない。
ウォーターフォールモデルの工程を並行で走らせるイメージ。
(引用元:http://www.itmedia.co.jp/im/articles/0310/08/news001.html)
メリット
- ユーザが機能を早期に利用できるようになる(スパイラルモデルと同様)
- スパイラルモデルやプロトタイプモデルと比較すると、工程管理が容易
- 要求定義が完了しているため、開発者の迷いを減らせる(ウォーターフォールモデルと同様)
- サブシステム毎の開発を行うため、ウォーターフォールモデルよりは手戻りコストが低い
デメリット
- 要求を予め定義しなければならないため、プロジェクト計画立案自体にコストがかかる(ウォーターフォールモデルと類似)
- 並行して開発を進行させていくため、開発内容が重複してしまう場合がある
- ウォーターフォールモデルと比較すると、スケジュール/工程管理が複雑になる(スパイラルモデルよりは容易)
- システムの分割が困難な場合がある(スパイラルモデルと同様)
- それぞれのサブシステムが高い独立性を持つ場合にしか利用できない
どのようなプロジェクトに向いているか
- 要求/要件/目標が固定されており、途中変更のないプロジェクト(ウォーターフォールと同様)
- 予め全ての要求/要件/条件/期間/工程/責任を定義しなければならないプロジェクト(ウォーターフォールと同様)
- 発注/受注案件など。
- 何が出来ていれば成約か、特に相互の責任を明確にすべき場合
- 発注/受注案件など。
- 機能を随時リリースし利用していきたいプロジェクト
- 期間的制約の強いプロジェクト
1-3. アジャイル開発
1-3-1. agileとは？
agileとは
(動きが)機敏な、はしっこい、(…に)機敏で、はしっこくて、頭の回転の早い、機敏な、明敏な
(引用元:https://ejje.weblio.jp/content/agile)
(引用元:https://ec-orange.jp/ec-media/?p=18702)
アジャイル開発をライフサイクルモデルと別項としたのには理由がある。
これまで紹介したライフサイクルモデルは、ソフトウェア工学の研究から生まれた、システム開発を効率的に進めるための経験則的ソフトウェアプロセスの集合、いわばフレームワークのようなものであった。これらはソフトウェアプロセスを定型化/評価し、いかに効率的な開発/保守を行っていくかという目的で考案されたと言える。
一方で、アジャイル開発という考え方はそれらとは少し違った見地から生まれたものである。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
(引用元:アジャイルソフトウェア開発宣言)
私たちは以下の原則に従う:
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
動くソフトウェアこそが進捗の最も重要な尺度です。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
(引用元(一部抜粋):アジャイル宣言の背後にある原則)
これまでソフトウェア工学で行われていたソフトウェアプロセスの定型化という研究とは逆に、ソフトウェアプロセスを柔軟かつ漸進的な非定型のものとして扱おうとしていることが読み取れる。
こうした思想が生まれた背景には、いくつかの理由が考えられる。
第一に、ソフトウェアプロセスの複雑化に伴う責任の明確化によって、副次的な成果物(要件定義書、仕様書、詳細設計書、テストエビデンス等)が増大し、「プロダクトを作る」という本質的な目的を達成するため道のりが遠くなってしまった側面があること。
第二に、webが発展したことによりソフトウェア開発に求められるものが変化したこと。ソフトウェアの利用される速度/頻度と改善要求の頻度は少なくとも相関、比例しているといってしまってもいい。少なくないソフトウェアが24h絶え間なく利用されるようになり、これまでの定型化されたプロセスを用いていては変化の速度に対応できない場合が出てきたのではないかと私は考えている。
第三に、ソフトウェア工学がある程度成熟してきたことで、基礎的な研究を応用できるタームに至ったのではないかと考えられる。前掲のアジャイルソフトウェア開発宣言の通り、アジャイル開発の理念は決してこれまでのソフトウェア工学で培われた経験則を否定/軽視するようなものではなく、それらの価値を認めた上でより現代にふさわしい価値を重視するというものである。既存のモデルを適宜最適な形で取り入れつつ、プロジェクトやチームによりふさわしい形の新しいモデルを追求していく、という姿勢こそがアジャイル開発の根幹であると言える。
以下に、約15年前、2003年時点での玉井による論を引用抜粋しておく。
開発/保守環境と運用環境の境界が喪失しつつあることにも，注目すべきであろう(中略)これまでのようにまず開発/保守環境でプログラムを作成し検証して，その後，運用環境へ移行するという段階を踏んだ作業は現実的でなくなってくる
引用元:玉井(再再掲) 144頁
1-3-2. アジャイル開発の手法
アジャイル開発と一言で言っても、スクラムやエクストリームプログラミング(XP)、リーンソフトウェア開発など様々な手法がある。
アジャイルの基本的な考え方は上述し、アジャイル開発に内包される様々な手法には細部の違いはあれ一定の共通した特徴がある。
そのため、ここではアジャイル開発手法の一つであるスクラムを紹介するに留める。
1-3-3. スクラム
Ken Schwaber/Jeff Sutherland両名によって開発されたアジャイル開発手法の一つ。
細かい手法やルールについては公式ガイドがあるのでそちらを参照の程。
(引用元:http://www.nec-solutioninnovators.co.jp/column/01_agile.html)
スクラムの特徴は公式ガイドにあるように以下の三点が挙げられる。
- 軽量
- 理解が容易
- 習得は困難
私も実際の業務にこのスクラムを浅い知識のまま取り入れたことがある。その経験から言っても上記三点は納得できる内容である。特に二点目の"理解が容易"と三点目の"習得は困難"という点は注目すべき特徴である。開発手法の自体の理解は容易だが、理解するのと実践するのとでは違いも多い。実際には数多くの問題が発生する。
公式ガイドにあるように、スクラムという開発手法は常にチーム構築/システム開発プロセスの改善を行っていく手法である。このことを軽視し、上辺だけスクラムを取り入れてしまうと私のように「なんちゃってスクラム」状態に苦しむことになる。実際、スクラムを取り入れ失敗するプロジェクトは数多く存在している。スクラム体制のコーチングのみで価値を認められるエンジニアも存在するほどに、スクラムの習得は困難である。
では、スクラムの実際の取り組み方を公式ガイドから抜粋し紹介する。
スクラムの理論
スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。
- 透明性
- プロセスの用語を参加者全員で共有している。
- 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。
- 検査
- 適応
- プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断し た場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムチーム
スクラムチームは以下の三つの役割で成立する。
- スクラムマスター
- プロダクトオーナー
- 開発チーム
スクラムマスター
- スクラムの促進と支援責務
- 開発チームへの支援
- プロダクトオーナーへの支援
- 組織への支援
- 上記促進支援によるスクラムチームが創造する価値の最大化
- スクラムを成立させ続けるためのサーバントリーダー(奉仕/支援型リーダー)
プロダクトオーナー
- プロダクト価値の最大化責務
- プロダクトバックログの管理・透明化
- プロダクトバックログ:プロダクトに必要だと把握しているものをすべて順番に並べた一覧
- 開発チームの作業価値最適化
- プロダクトバックログアイテムの周知
開発チーム
- 自己組織化責務
- サブチームはない
- 並列したプロフェッショナルであり上下関係はない
- スプリント毎のリリース責務
スクラムイベント
スクラムは規則的なイベントを規定している。時間制限のあるイベントのみが存在でき、不要な時間的コストは削減されなければならない。
スプリント
スクラムのコアといっていい機能である。
- リリース判断可能なプロダクトインクリメントを作るための、1か月以下のタイムボックス(規定する)
- スプリントゴールに悪影響を及ぼすような変更を加えない。
- 品質目標を下げない。
- プロダクトオーナーのみがスプリントを中止できる。
- とはいえ、スプリントを中止すべきことはほとんどない
スプリントに内包されるイベントは以下の4つである
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
1.スプリントプランニング
以下の問いに答えを出す会議である。先に挙げた三本柱の内、透明性の部分に関連の強い場。
- スプリントの成果であるインクリメントで何を届けることができるか？
- インクリメントを届けるために必要な作業をどのように成し遂げるか？
2.デイリースクラム
主に開発チーム作業計画をする場。日々の開発に関する検査、適応の機能を備える。
3.スプリントレビュー
スプリント自体の検査の場。
注意：一部のみ抜粋している。
- スプリントの終了時にインクリメントの検査と、必要であればプロダクトバック ログの適応を行うものである。
- 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
- プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないも のについて説明する。
- プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在 の進捗から、可能性のある目標とデリバリーの日程を予測する。
- 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを 議論する。
- 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定 義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
- グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるイン プットを提供できるようにする。
- 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性 をレビューする。
スプリントレトロスペクティブ
スプリントに対する適応の場。
- スクラムチームの検査と次のスプリントの改善計画を作成する機会 である。
- スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。
- スクラムマスターは、このミーティングがポジティブで生産的になるようにする。
- 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
- うまくいった項目や今後の改善が必要な項目を特定・整理する。
- スクラムチームの作業の改善実施計画を作成する。
以上がスクラムという手法の規定である。
より詳細/正確な規定、実践的な内容については以下を参照。
- スクラムガイド - 日本語訳
- Scrum基本のキ - 西村直人
- スクラム概論 - Ryutaro "Ryuzee" YOSHIBA
- Agile-development-course-advanced - Miho Nagase
2. 要求工学
ソフトウェア工学とそれがもたらしたライフサイクルモデル、及びアジャイル開発についての説明は終えた。
どのライフサイクルモデルにも必ず存在するのが「要求定義/要件定義」というプロセスだ。私にとって、いやおそらく多くのエンジニアにとって、これはプログラムを書くこと自体よりも非常に難しいプロセスである。
例えば顧客が「ごはんを食べたい」と言った時、私たちは何を明らかにし、何を考え、何をすべきなのか。
顧客が求めているものは"ごはんを食べる"という行為なのか、"お腹をいっぱいにしたい"ということなのか、それとも"外食に行きたい"、"ごはんでも食べながら人と話したい"ということなのか。また、求められているごはんとは何か。お米を炊いたものか、それともごはんはお米という意味ではなくてパスタかラーメンか、そのどれでもいいのか、どれでもダメなのか。今どれくらいごはんを食べたくて、いつまでにごはんを食べたいのか。また、いつまでごはんを食べたい状態は続きそうか。我々はごはんを作れば良いのか、ごはんを食べれる場所を作れば良いのか、ごはんを食べられるお店を紹介すれば良いのか、ごはんを一緒に食べてくれる人を紹介すればいいのか。そして、それはどこまでが顧客の決めるべきことで、どこから我々のすべきことなのか。
このような問いは書ききれないほどある。要求/要件定義がいかに奥深く難解な問題であるかということが、この例でわかってもらえるかと思う。
要求工学とは
要求工学とは、要望、要求について、あるいはそれを仕様化するプロセスについての研究と言える。
プロジェクトの失敗原因の多くは要求に起因する
要求工学知識体系(REBOK)概説 - 独立行政法人情報処理推進機構
システム開発において、手戻りやスケジュールの遅延、重大なバグが発生した時点で少なからず開発プロセスに失敗、欠陥があったと言える。
そして上記引用の通り、IPAはプロジェクト失敗の多くの原因は要求/要件定義にあるとしている。
これは私を含む多くのエンジニアが肌で感じ取っていることでもある。
要求定義/要件定義に関する書物は現在確認できるだけで100冊を超えており、それは要求/要件定義の難しさを多くの人間が感じている証左である。
上掲IPA資料、ソフトウェア工学(再掲)にも要求獲得、要件定義の難しさやそれに対するアプローチ技術の重要性が説かれており、これらは昨今ソフトウェア開発における一つの大きな課題として工学と呼ばれるにまで至っている領域である。
要求獲得、要求定義、要件定義、仕様化のプロセスについてはまだ未成熟な領域である。つまり、ベストプラクティスは未だ確立されていない難解な課題であるということは前提として認識してもらいたい。
2-1. 要望、要求、要件の違い
重要：この三つはそもそも人によって解釈が違うものである
- 要望：demands
- 要求：requirements
- 要件：requirements
“requirement”は，通常“要求”又は“要件”と訳される。
(引用元：JIS規格X0166)
今回は、抽象度の違いという観点から特に要望/要求について定義し、要件定義に至る前段階に必要なプロセスを明らかにしたい。
抽象度の高い順に並べると要望>要求>要件(>仕様)であるという前提で話を進める。
2-2. 要望と要求の関係
通常、要望は英語でDemandsという。要求はRequirementsということから、この二つには明確な違いがありそうだということがわかる。
その前提の上で、まずは私なりの要望と要求の関係を定義したい。
- 要望 = 顕在化してない要求(潜在的要求)
- 要求 = 顕在化し、具体性を得た要望
私はこのように要望と要求を区別し、またその関係性を定義する。
そして、要求工学の力を借りつつ、私自身の経験から要求をさらに細分化していく。
システム開発にまつわる"要求"というものは、下記のような段階的プロセスを経て獲得されるものであると私は考える。
- 要望の発露
- 要求の認識
- 要求の分析
- 要求の定義
- 要求分析結果の合意
- 要求の検証
まず、要望が何らかのプロセスを経て1.顕在化(発露)する。そして、それは要望保持者と要求獲得者(要求定義をしたい者)の両名に"未成熟な要求"として2.認識される。次に、認識された"未成熟な要求"を"成熟した要求"へと進化させるプロセスを経る。このプロセスを3.要求分析と呼ぶ。最後に、成熟した要求を文書化して明示(4.要求の定義)し、要望保持者と要求獲得者の間で5.要求分析結果の合意を得る。そして、成熟した要求が両者に共有された後、6.要求の検証を行う。
IPAのREBOKに基づく定義に当てはめると、1,2が要求獲得、3が要求分析、4,5が要求の仕様化、6が要求の検証・妥当性確認・評価に当たる。
同IPA資料にもあるように、このプロセスは決して直線的なものではなく、上で紹介したいくつかの反復型ソフトウェア開発ライフサイクルモデル、アジャイル開発の思想のように反復による改善を必要とするものである。
2-2-1. 要望の発露(顕在化)プロセス
先ほど"要求 = 顕在化し、具体性を得た要望"と定義した。
では、どういった経緯を経て要望は顕在化するのか。
要望が顕在化し"未成熟な要求"へと変化するプロセスには少なくとも2つの種類がある。
- コミュニケーション型要求発露
- 自己完結型要求発露
これらはあくまで私個人が名付けたものであり、一般的な用語ではない。それぞれ図を用いて説明する。
2-2-1-1. コミュニケーション型要求発露
上図に示したように、要望は要求獲得者(例えば要求獲得をしようとしているSIer)と顧客(ユーザ)間のコミュニケーションによって顕在化し、まず"未成熟な要求"へと変化する。
この場合、作業を楽にしたい、しかし"どうすればできるのかわからない"というわからなさや、そもそもこれは課題なのかというわからなさがコミュニケーションによって解消されたことにより要望が顕在化される。その"わからなさ"が要望を要望として留まらせていた原因と言える。
このプロセスを要求獲得者側として行う際に注意するべき点は正にそこであり、医療現場や社会学、心理学などにおけるインタビューの手法を取り入れるなどして、"わからなさ"の障壁と原因を理解した上で可能な限り適切にコミュニケーションを図る必要がある。適切でないコミュニケーションがもたらす結果は、要求獲得者のバイアスによる誘導、つまり"本当に顧客が要望していること"からの乖離といえる。
妻木によれば、この段階で具体的に取られる調査手法には以下のようなものがある。
- 情報の収集
- ステークホルダ分析
- 構造化インタビュー
- 観察
- 文献調査
- プロトタイピング
- 問題の定義
- 情報の整理
- 合意形成
- モデリング
2-2-1-2. 自己完結型要求発露
一方で、要望の顕在化までは顧客自身が行なっている場合がある。
顧客が要望を顕在化している状態では、SIerやソフトウェア開発をする側はほとんどの場合その要求を聞き取ることしか行わない。
上に挙げた妻木による調査をすでに顧客側が済ませており、ある程度整理された要求が提示されるという期待からである。しかし要求を獲得するという本質的な目的に対しては、この期待は危険を孕んでいる。
自己完結型要求発露によって顕在化した要求は"最も未成熟な要求"である可能性が高い。顧客自身が行った要望の健在化は(顧客が社内調査をした結果だとしても)第三者とのやりとりを介して発露した要求ではない。提示される要求はコミュニケーション型要求発露プロセスを経た場合よりもあいまいさが強く、主観によるバイアスの影響も多大に受けている可能性がある。
しかし一方で、自己完結型要求発露によって顕在化された要求は、コミュニケーション型要求発露にはない当事者であるからこその業務知識、背景、課題感が含まれている可能性も高い。後のプロセスである"要求の分析"、"要求の検証"プロセスを経る際に鍵となる何かしらの要素がこの段階で露見することもある。
2-2-2. 要求の認識プロセス
要望の顕在化プロセスを経て、要求は初めて両者に認識される。
時には、顧客本人にとってもこの段階で初めて発見される要求及び要望がある。
(例) 「この作業を楽にしたい」 -> 「こういうシステムがあれば楽になるんだ」 -> 「じゃあそれが欲しい」
(例)「気づいていなかったけれど、実はこんなことにも困っていたんだ」 -> 「じゃあそれもどうにかしたい」
特にコミュニケーション型要求発露においてこの発見は顕著である。この場合においては、顧客自身も要求獲得を為したと言え、顧客ベンダ双方が要求獲得者としての性質を得る。
要望の発露と要求の認識プロセスを分けた理由はここにある。要望が発露した時点で要求として認識されたと捉えることもできる。しかし顧客自身が気づいていない要望/要求の発見という要求獲得における重要な課題の鍵を握るのはこのプロセスであると私は考える。
2-2-3. 要求の分析
2-2-1,2-2-2のプロセスを経ることで"未成熟な要求"を獲得した。
次の要求の分析というプロセスは、獲得した要求を成熟させる重要なプロセスである。
要求工学の領域ではない一般的な「要求定義」と呼ばれる工程で行われることとほぼ同様である。
分析の手法は多々ある。この分析こそが要求定義のコアであり、シナリオベースモデル、領域分割モデル、ゴール指向モデルなど様々な分析フレームワークが開発され、この難題をいかに解決するか日々研究がなされている。
ここでは、私の経験から最低限分析しておきたい3つの項目を挙げる。
- 要求の背景調査
- なぜその要求が生まれたのか？
- 誰が
- いつ
- どこで
- どのように
- なぜ、その要求は"今"要求として顕在化したのか
- なぜその要求が生まれたのか？
- 要求の正当性を明確化
- その要求は本当に必要とされている要求なのか？
- 誰に、どのくらい必要とされているのか
- その要求は何を解決し、何をもたらすのか
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- 新しい価値の創造リソース
- 人員コストの削減
- etc...
- もたらされるものは、本当に求められているものと同じなのか？
- 例えば業務効率の改善に関する要求であった場合、解決により何が顧客にもたらされるのか
- システムやツールが欲しい、という要求は正当なものなのか？
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか？
- それは「本当に欲しい」のか？
- "楽になるシステム"ではなく"楽になるオペレーションフロー"では解決できないのか？
- ここで、オペレーションフローを変更できない等の背景が発見されることもある
- システムと併用してより効率的な解決ができる方策はないか？
- システム利用権限保持者を拡大すれば、より効率が上がるのではないか？
- システム導入と同時に保守/運用が別途必要になるのか？
- 要望保持者、要求獲得者の適切でないバイアスが含まれていないか？
- その要求は本当に必要とされている要求なのか？
- 要求の具体化
- 要求が解決されるとは、どういうことなのか
- 先の図の例で言えば"楽になる"、"使いやすい"とはどういうことか
- 何が解消されていれば要求の解決に至れるのか
- 要求が解決されるとは、どういうことなのか
問いの例として、いくつか具体的な問いを掲載した。要求分析というプロセスは、何度も何度も立ち返り問いを発することで改めて要求の意義、要求の本質と詳細を明らかにしていくことが目的である為、重複した問いも時には必要であると私は考えている。
より根本的な課題背景を知ることで、必要とされているシステムが変わってくることはザラにある。 そもそも要求が正当でなく、作った後に「使ってない」と言われることもまたザラであると言える。1990年代に行われたスタンディッシュ・グループのレポートによれば、システムに搭載した6割以上の機能が使われていないという。
(参考：アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 2013 平鍋健児、野中郁次郎)
1990年代の調査が現代に通用するのかどうかは別として、そうした非効率的な状況を回避するために、背景の認識、正当性の検証、具体化というこのプロセスが必要なのである。
要求の分析は決して開発者のみに利益があるものではなく、両者にとって利益のあるプロセスである。
要求の分析プロセスを経ることによって、顧客にとっても開発者にとっても気づきが与えられる。本当に必要とされている解決は何か、それはどれくらい致命的な問題で、解決することで何が起こるのか。
しかし一方で、開発側が敢えてこの要求の分析プロセスを回避している場合もある。例えば開発会社にとっては顧客にとって無駄なものであったとしても、案件として受注をして言われた通り納品してしまえば報酬がもらえる。この問題は受注/発注双方の課題でもあり、システムインテグレーション、システムコンサルティングの領域に波及する。
2-2-4. 要求の定義
前プロセスである"要求の分析"で明らかになった"要求の本質と詳細"を書面化するプロセスが本プロセスである。
一般的には、この時点で要求仕様書という要求をシステム仕様にまで落とし込んだ書面を作成する場合もある。
しかし今回は先述した通り、要求と要件を明確に区別し話を進める。その上で、要求の分析プロセスで明らかにしたものはビジネスの要件であり、決してシステム要件ではないということを断言しておく必要がある。
即ち、このプロセスで作るべき書面は、"ビジネス要件"を明示したものである。
2-2-5. 要求の合意
2-2-4. 要求の定義で作成したビジネス要件をまとめた書面は、両者によって分析結果に齟齬がないか検証合意される必要がある。
このプロセスでは分析の結果の正当性を問う。ここで注意しなくてはならない点は、そもそもの要求の正当性ではなく分析の結果の正当性を合意するという点である。
要求の正当性を問うプロセスは別にある。次のプロセス要求の検証である。
2-2-6. 要求の検証
ここまでで、ある程度成熟した要求が定義された。要求の分析結果は書面化され、ビジネス要件の具体的な姿が見えるところまできた。
その要求は本当に必要なものだったか、本質的な問題は別のものではなかったか、当初持っていた要望とは別の要望が生まれてはこなかったか。ここでようやく、顧客と要求分析者の間で要求の正当性を改めて問うことができるようになる。
2-2-7. 反復
先述した通り、これらのプロセスは反復型ライフサイクルモデルやアジャイル開発の思想のように、反復して行わなければならない。
その理由は以下2点である。
- 分析結果を受けて、要求が変化し得ること
- これまでのプロセスで得た"気づき"による新たな要求がまだ一連のプロセスを経ていないこと
例えば先の図で"本当は別のものが欲しいのかも"という新たな要求が顕在化した。その原因は何か。それは潜在的な要望が新たに発見されたことに他ならない。
はじめに、要望を以下のように定義した。
要望 = 顕在化してない要求(潜在的要求)
要望が潜在的な要求であるように、要望にもまた顕在化しているものとしていないものがある。顕在化した要望は新たな要求となり、再度一連のプロセスを経てその正当性、必要性が議論されて然るべきものである。また、要望は一度洗い出したらそれが全てというものではない。常に新しい要望が生まれ、それは潜在的であることもあるし、顕在化している場合もある。
この流動性、複雑性こそが要求工学という技術を生んだ要因であると私は思う。
おわりに
僕は現在webエンジニアとしてご飯を食べているが、高校や大学で情報系のことは一切と言っていいほど学んでこなかった。所謂「ちゃんと勉強してきた」エンジニアではないのだ。大学は社会学部社会学科というゴリゴリの文系学科を出ているし、卒業研究のテーマなんて「若者と自殺について」というような感じで、もう本当に全然プログラミングのプの字も知らずに生きていたのだ。
僕がエンジニアになったのは4年前くらいのことになる。最初に入った会社の配属先発表で「システム開発室ね」と言われたその瞬間、僕の車輪はエンジニアというレールの上を回り始めた。それなりにプログラムを書けるようになって、それを楽しいと思うようになってきて。ちょっとハードワークすぎてうつ病になったりもしたけれど、それでも僕はエンジニアリングというものが今も好きだ。
僕がボランティアで大学生にプログラミングを教えているのも、自分がエンジニアリングという仕事を好きだというところが根底にはあって、もし僕の知識を彼らに提供することで彼らがより幸せな人生を送れるのだったら素晴らしいし、彼らがエンジニアになるにせよならないにせよ、この楽しさというものを理解してくれたらとっても嬉しいなあという思いからだ。
しかしいつからか、「ちゃんとコンピュータサイエンスを勉強している奴には勝てないなあ」ということに気づいてしまった。多分それは本当のことなんだろう。僕は昔から算数や数学が苦手で、高校入試の自己採点をした時なんて、数学は0点だった。国語と英語の点数のみでどうにか受かった。本が好きで、純粋経験とか唯我論とかそういう哲学を知るのが好きで、理屈が好きで、小説家になりたいと思っていて、この上ないくらいに文系の極みのような人間だ。
一般的にエンジニアというと理系の仕事だと思われる。僕もそう思う。でも僕は今でも、シグマと言われるとウッという拒否感が出てしまう。for文というシグマと似たようなプログラムの構文があって、それを日常的に使っているのに、やはり数学には苦手意識があるのだ。
そんな僕は、「エンジニアとして何をしたらいいのかな」と漠然とした悩みを持っている。webエンジニアの一般的なキャリアパスとしては、エキスパートとしてプログラミングを極めていく道と、マネジメントの方に進む道がある。僕はなんだか、どうなりたいのかよくわからない状態になっている。
もっとプログラミングを勉強していきたいし、でもちゃんと勉強してきた人たちからすると僕なんてにわかエンジニアというか、そういうような存在になってしまうよなあと。業務ではPHPを使っていて、それだけじゃあダメだと思ってrubyやjavascript、C++なんかも触ってみたけれども、なんだかそれもちょっと違うような気がしている。
そこで立ち返って、僕に出来ることはなんだろうと考えることにした。
僕に出来ることは、何かを入れて、何かを出すこと。
本や論文、人が書いた文章を読むこと。
そして、それを自分なりに解釈して、書くこと。
インプットとアウトプット、多分僕にはそれしかできないんだと思う。
息を吸うのと同じだ。僕には多分、これしかできないんだと思う。
だからいっぱい本を読んで、いっぱい日記や記事を書こう。
