僕がソフトウェア開発について学んでいること
はじめに
たまにはエンジニアらしいことを書こうとしてまとめていたことが、あまりに長くなったので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++なんかも触ってみたけれども、なんだかそれもちょっと違うような気がしている。
そこで立ち返って、僕に出来ることはなんだろうと考えることにした。
僕に出来ることは、何かを入れて、何かを出すこと。
本や論文、人が書いた文章を読むこと。
そして、それを自分なりに解釈して、書くこと。
インプットとアウトプット、多分僕にはそれしかできないんだと思う。
息を吸うのと同じだ。僕には多分、これしかできないんだと思う。
だからいっぱい本を読んで、いっぱい日記や記事を書こう。
もっと本を読みたい、もっと文章を書きたい。
昔から、物語を読んだり観たり聴いたりすることが好きだった。というより、僕にはそれしか熱中できることがなかった。それにもかかわらず、最近では本を読むことがめっきり減ってしまった。精々週に一度か二度、長い通勤時間を利用して青空文庫をペラペラとめくるくらいだ。
最も好きな作家は坂口安吾で、次がゲーテ、並んで森鴎外とヘッセ、中島敦、山田詠美。この並びを見ればわかる通り、僕の好きな物語に確固たる系統はない。敢えて言うのであれば、あまりに情熱的な、魂から溢れ出たような文章が好きなのだ。それが織り交ぜられた物語に、心から圧倒されることが好きなのだ。話自体が面白いとかつまらないとか、設定が面白いとかそんなことは関係ない。デカダンだろうがフェチズムだろうがナルシシズムだろうが諦念だろうがフェミニズムだろうが、どんな姿勢でどんなメッセージを発していてもかまわない。一文一文に込められた熱量、魂、そのあまりの迫力に打ちのめされるあの感覚に取り憑かれてしまって、たまらないんだ。僕は文章と物語に、憧れていたい。
中学生頃から、友人と過ごさない時間の大半を読書に費やした。大学では、映画を撮りたいという友人に脚本を書いた。今思えばあの稚拙な短編物語を短編映画にまでしてくれた彼には感謝の言葉もない。僕の物語への執着は、ずっと続いた。それどころか、年々その激しさを増していった。初めてオズの魔法使いの絵本を読んだその時から、一度たりとも物語から離れたことなんてなかった。
それなのに、仕事が、生きるためにお金を稼ぐということが。僕が一番大切に思っていたものを奪ってしまった。あるいは、僕が一番大切にすべきだったものは、生きるために働くなんてことではなくて、この思いそのものだったのかもしれない。
それでも今、僕は欲しい本がたくさんある。ほしい物リストにはたくさんの本が入っている。
どれもこれも、仕事をうまくやるための本、自分の能力を磨くための本ばかりだ。僕はそれが悲しい。昔は本に実利なんて求めていなかった。僕が好きだったのは教科書ではなく、物語だったはずなんだ。いつからだろう、本が何かを与えてくれるものだと勘違いし始めたのは。本は、読み手が何かを感じ取るもので、あちらからは何もしてくれないものだって、ずっと思ってきたのに。
僕は、物語をもう一度取り戻したい。仕事や、嫌な人間関係や、茫漠と横たわる人生の不安は絶えず僕を苦しめている。生活に追われ、本を読む時間だってほとんどない。それでも僕はこれから、たくさんの本を読もうと思う。たくさんの文章を書こうと思う。そうして僕は物語を、僕なんかでは敵いっこない尊い魂に圧倒されるあの快感を、この手に取り戻そうと思う。
アーリータイムズ
僕は今、フレックス制度を利用して早帰りをしている。嬉しい。早帰りといってもそこまで早いわけでもない。コアタイムが10-16時と決められていて、そして僕の家と会社は遠い。どれだけ急いでも帰宅出来るのは結局18〜19時になってしまう。それでも、普段0時くらいに帰っているのを考えれば十分に嬉しい。 体調が優れない為やむを得ずとった強行ではあるが、僕は今嬉しいのだ。
イイ話
昨日友人が言っていた。お金は高いところから低いところに流してしかるべきで、低いところから高いところに流すのはヤクザのシステムだと。そしてこれは優しさや余裕においても同じことだと。なるほど言い得て妙である。そう言われるとそんなような気がしてくる。もしかすると、早帰りをしたことで僕も余裕を感じているのかもしれない。バラバラに座ろうとする親子に席を譲ることが普段よりスムーズに出来た気がする。
余裕のあるやつが余裕のないやつを助ければいいんじゃない?と彼は言った。素晴らしい考えだ。僕も本当にそう思う。僕自身もそうありたいと思うし、人にもそうで居てほしいと思う。できれば、余裕のある側でありたい。
これを書きながら昨日の友人との会話をだんだん思い出してきた。確か僕らはそのイイ話の前に、お互いにブチ切れたことがあったよねという話をしていたんだ。こんなにイイ話ができる人間でも、やはり余裕がないと怒ったりしてしまうことはあるのだ。10年近く付き合った友人らが、お互いにムカついた話をした後で大人みたいな話をする。とても人間らしくて気に入っている。素直で素朴で素敵な話の流れだった。
大学生の頃、別の友人と似たような話をしたことがある。その友人と僕はバンドを組んでいた。彼は非常に時間に寛容だった。バンド練習の際に誰かが遅刻をしてきても、本当に何とも思わず仕切り直すことができる人間だった。そして彼は他人に対してと同様に、自分の時間にもあまり執着をしていなかった。僕の知らないところではあるが、彼自身が何かの待ち合わせに遅刻することが少なからずあったようだ。ある日彼は何の気なしにこう言った。
遅刻したら怒られるじゃん。でも、みんなが怒る意味が正直あんまりわからないんだ。
僕は彼の言葉に共感を覚えた。僕らは二人でじっくりと、その分からなさの原因を探ることにした。おそらく何ヶ月、すくなくとも何週間かこの話題は続いた。結論を言えば、彼と僕は暇だから怒らないんじゃないかという話になった。今思えばなんて結論なんだろう。文系大学生が二人集まって真剣に議論した結果とは思えない。
でも確かに、当時僕らのカレンダーは基本的に真っ白だったし、そもそもカレンダーを埋めるものだなんてこれっぽっちも思っていなかった。だから何か面白いことがあれば飽きるまでやっていたし、納得のいかないことがあれば納得いくまで考えたり話したりした。それから好きな女の子の話なんかもずっとしていた。
他の人たちのカレンダーはきっと真っ黒になっていて、決められた時間で決められたことをやれないと他の予定に支障が出ちゃうから怒るんじゃないかな。
当たり前のことだ。そんな当たり前の結論が、当時の僕らには想像もつかない新たな発見だった。想像が出来なかったから、ゼロから仮説を立てて、こうなんじゃないか、ああなんじゃないかと今思えばよくわからない推理をしていた。
でも、その想像のつかなさが、それこそが僕らの純真だったと思うよ。今では僕らはカレンダーを"埋める"とは言わず、スケジュールを"空ける"と言うようになってしまった。なんで、いつこうなったんだろうね。自分達とは違う人のことを想像していたはずなのに、今はもう違う人ではなくなってしまったね。このことについて、また話し合いたいね。
かなわねえな
かなわない、僕は善い人間には、かなわない。
僕は、世界には善い人間がいることを知っている。そしてその少なさと尊さもまたよく知っている。
善い人間はいつも僕を助けてくれる。悩みごとがあれば一緒になって考えてくれて、放っておいて欲しい時は放っておいてくれる。何かをお願いすれば快く引き受けてくれるし、僕が何かをお願いしたことを喜んでくれたりもする。少し時が経てば、最近どうだと不意の連絡を寄越してくれ、正にそれが欲しいというタイミングに僕の心配をしてくれていたりする。そして、僕に心配をさせてくれることもある。
善い人間は、きっと僕以外の人間も助けている。彼等はいつも誰かの為に考え、行動し、一緒になって喜んでいる。少なくとも僕にはそう見える。本当にかなわないよ。仕事をして生活をして、彼等にも僕と同じような暮らしがある。彼らも僕と同じように悩むことだってあるはずなのだ。しかし彼等は僕と違い、いつだって優しく善い人間でいることが出来る。どうしていつも、凪いでいられるのだろう。なんでそんなに、静謐であれるのだろう。
僕はといえば、根っこの部分からもう善くない人間だ。善悪の二元論で語るならば、当然僕は悪人に近い側にいる。私欲が喉の渇きのように付き纏い、呼吸をする度に厭忌の粘りは増す。これぞ嫌な人間というような行動を取ってしまうこともあり、本当に嫌になるよ。こんなことばかりの時間と、こんなことばかりの自分が。そしてどこか善い人を羨んでしまうこの浅ましさも。
それでも僕は今、仕事や生活、この暮らしにそれなりに向き合った形で日々を費やせている。僕が思うに、その少しの前向きさの源泉になっているのはやはり、今や今までに一緒に居てくれた善い人達の存在であると思う。これからくる過去も、これまで見た未来も、全部が全部彼等のお陰であって、それが心から分かってしまう。本当にかなわないと何度も思い知らされるよ。
僕はやはり、彼等のように穏やかでありたい。病める時も健やかなる時も、そうありたい。ただ生きているだけで苛烈さは寒風の如く吹き荒ぶけれど、もうそれに慣れるのも嫌なんだよ。もう彼や彼女にかなわないと思い知らされるのは、嫌なんだよ。
善い人間って奴は、ほんと参っちゃうよな。
諸君、我々は売り手市場に乗じて労働環境の改善を推し進めるべきなのだ。フォースと共に
今日本は空前絶後の売り手市場らしい。そんなことは知っている、自分には関係ない、という人もちょっと待って欲しい。確かに売り手市場というと、転職や就職をする人にのみ関係のあることのように感じてしまいがちだが、実は既に日々労働に勤しんでいるあなた方や僕にとっても、もしかすると転職や就職をしようという人以上に貴重なチャンスが訪れているのかもしれないのだ。
いつでも転職できるという最強の武器
今の労働環境に少しの不満も無い人間なんていない。もしいるとすれば、ブラックな社訓を魂に刻み込まれ最早人間に戻ることも出来なくなってしまった被害者(ゾンビ)か、成長の意志を捨て人の足を引っ張ることに楽しみを見出した無意識の加害者(ゾンビ)くらいだろう。いやこの話もまた長くなるから今はゾンビの話はしない、これからの人間の話をしよう。
我々はゾンビではなく、誇り高き人間である。誇り高き人間は、より良い環境でより生産性の高い仕事をしたい。より短い時間でより高い価値を創造したい。つまり誇り高き人間は、なるべく働きたくない。なるべく働きたくない人間は、誇り高い。
悲しいかな、誇り高き人間はその利発さ故、安定というものの価値もまたしっかりと理解できてしまう。安定というのは人間にとって劇薬のようなもので、それさえあれば多少不満足な労働環境においてもそれなりの納得感を持って働けるようになってしまう。安定という毒に目が眩み、愚かにも不満足な現状をそれなりの現状と錯覚し、またそれにしがみ付いてしまう同族がいるということだ。あるいは僕も、その一人であるかもしれない。
しかし誇り高き人間達よ、立ち還れ。
我々にとって、今の売り手市場という状況はこの上ない追い風と言える。いつでも転職が出来る、という客観的事実は我々が持ち得る最強の矛だ。最強の矛であり、同時に最強の盾でもある。右手には最強の矛、左手には最強の盾。そうだ、遂に我々は決戦に向かう用意を終えたのだ。この事実がある内に、多少強引にでも労働環境の改善を推し進めるのだ。
営業の同族よ、無根拠なノルマ水準を下げるよう交渉せよ。そして厚顔にもインセンティブの上乗せを要求するのだ。
エンジニアの同族よ、納期を気にせず心の健康が保てる現実的な工数を申告せよ。そして厚顔にもより高い水準の学習補助、福利厚生を求めるのだ。
ディレクターの同族よ、出来ないことは出来ないと明言せよ。自らの業務の専門性を社会に認知させ、インセンティブを獲得するのだ。
我々の下、我々の為、我々の向かう先に確かに正義の風は吹いている。 安定を求める愚かな同族もまた、今回ばかりは安心して行動せよ。アプローチに多少失敗し社内に居づらくなったとしても、次の職には困らない。そして何より、諸君らの行動の結果如何に関わらず、言いたいことが言えるポイズンな土壌、風潮は後に続く勇者にも引き継がれ物語はやがて伝説へと続くのだ。
諸君、売り手市場は決して他人事ではないのだ。我々一人一人の行動で社会はより生きやすい社会へと進化していく。そして今、諸君らには最強の武具が与えられた。行動を起こすならば今が最上、千載一遇の好機なのである。行動せよ、崇高な思いを胸に。集合せよ、我々の未来のために。諸君らの献身に期待する。以上。
追伸、僕は行けたら後から行く。
正当な対価を要求するための責務、またその難しさについて
前回のエントリで不適正な対価で優秀な人材を雇おうとする企業について、長々と批判と愚痴をごちゃ混ぜにして書いた。
社員に「クリエイティビティ」,「イノベーション」を求める企業と支払う対価について - ここはクソみたいなインターネッツですね
この問題に関し、翻って求職者や労働者、つまり雇われる人間の側にはどんな責任があるのかを改めて考えたい。一連のエントリが、単なる一労働者の企業に対する愚痴になってしまっている現状から脱却したいという思いだ。
自身の価値を伝えることの難しさ
結論から言って、雇われる側の人間が正当な対価を要求するためには、自身の価値を雇う側にアピールすることが必要だ。
就職や転職、評価面談の際に自身が積み上げてきた実績、現在の能力とその価値を正確にアピールしなければ、適正な対価など得られるわけがない。しかし、それはとても難しいことだ。上手くそれをこなせている人間は非常に少ない。
その"難しさ"は一体どこからくるものなのだろうか。
事例
僕は以前所属していた企業にて、ある制度を作った経験がある。その制度とは、企業が定めた数十の評価基準について被評価者があらかじめ1〜5の定量的な自己評価をつけておき、評価面談の場で実際の評価と突き合わせ、そのズレについてすり合わせを行うというものだ。正当な対価を要求するために自身の価値を数値化する。これは正に"自身の価値をアピールする責務"を実行させる制度であった。そして、この制度を実施することにしたきっかけは、労働者側に「自分が正当に評価されていない」という不満が散見されたことだった。果たしてその結末はと言えば、この制度は失敗に終わった。一度か二度と実施した後、僕が想定していた不満の軽減や労働意欲の向上といった効果が全く得られていないことが分かったのだ。
なぜこの制度は失敗したのか。なんとその原因は被評価者にあった。評価に不満を持っていたはずの被評価者たちのほとんどは、杜撰な自己評価を行ったのだ。ある人は事実として残したはずの成果を低く申告し、ある人は根拠もなく自身に高評価を付け、ある人はすべての項目を中間の点で埋めた。一方で当然ながら評価者は被評価者の実績データを根拠とし、出来る限り公正な評価を持ってきた。評価者からすれば、被評価者が提出した自己評価は余りにも粗慢であり何の参考にもならない紙切れに過ぎなかった。この制度は、この制度を欲していたはずの被評価者が原因で失敗したのである。これは僕にとって、予想外の事態だった。
なぜ正確な自己評価が出来ないのか
僕の考えでは、この問題には二つの原因がある。
一つ、そもそも人間は自身を正確に認識することが苦手な生き物であること。
二つ、実績のアピールと自身の誇示を混同していること。
人間にはアプリオリな機能として、虚栄心、闘争心、猜疑心、敵対心、嫉妬心、羞恥心など自身を大きく見せたい欲求や、逆に自身を小さく見せたい欲求などが備わっている。極論として、人は物事を主観でしか捉えられない。可能な限り客観に寄せようとしても、やはり主観的客観という不確かな客観性までしかどうしても到達できない。それは自分自身を"観る"ときも同様であり、そして主観というものは基本的に先に挙げたような感情による影響を受ける。例え観る対象が定量的に測れる実績や明確な事実であったとしても、それをどう捉えるか、どう観るかという点には感情の影響がでてしまうのだ。自分自身のことを定量的に評価する場合、思い入れ、つまりは感情の強さが他者へのそれとは圧倒的に違う。感情のバイアスがより強くかかってしまうのは道理であると言える。感情が多様であるように、それがもたらす影響の方向も様々だ。客観的であろうとしすぎれば恐怖や恥ずかしさといった感情のバイアスから自身を過小評価してしまうし、主観のみで捉えようとすると虚栄心や闘争心といった感情が過大評価を呼んでしまう。反対に、他者を観る場合は思い入れに比例して感情のバイアスは弱くなり、比較的客観的らしい判断ができる。要するに、人は自分のことになると冷静さを欠きがちなのだ。
二つ目もそれに連なる話であり、冷静に考えれば、自身の正確な価値を評価者に伝えることは必要なことで、恥ずかしがったり謙遜などをすべきことではないと理解できるはずだ。しかし冷静さを欠いた人間はそれが分からなくなってしまう。積み上げてきた成果を正確に伝えれば良いだけだというのに、どこか「自慢話のようになってしまうのではないか」とか「あの人に比べればまだ自分はダメだ」だとか、不必要な謙遜や卑下をしてしまう。一般的に、自分はまだまだだ、というフレーズは向上心を示すポジティブなニュアンスを感じさせる。たしかに謙遜は美徳であり向上心があることも優れた資質であると言える。しかしこの場合では、それらはなんの役にも立たない。正確な事実を伝えるべき場でのそれらは、観たいものをボヤけさせるフィルター、磨りガラスで作られたレンズの様なものだ。謙遜や卑下、羞恥やセルフハンディキャッピングはこの場では一切必要がない。当然、虚栄も誇張も同様だ。ありのままの事実をありのまま伝えるだけで良いはずなのだ。
この問題をより難しいものにしているもう一つのこと
残念ながら、現実社会においては先述した二つの原因を克服したとしても正当な対価が必ず得られるわけではない。
これまでの話は全て評価基準が定量的に測れるものであり、かつ評価者が職務に忠実公正であった場合の話である。現実には、評価基準がそもそも定まっていない場合や、曖昧かつ定性的かつ不透明な基準が設定されている場合、評価者の主観的な好き嫌いが大いに評価に反映される場合もある。むしろそういった環境の方が割合としては大きいだろう。
つまり、非常に悲しいことではあるが、僕が先程不必要だと切り捨てたはずの謙遜やセルフハンディキャッピング、虚栄や誇張というものが、処世のテクニックとして非常に有効なものになってしまう現実があるのだ。無能な人間が上司や評価者に気に入られているだけで高評価を得たり、実績の伴わない"やる気"や"向上心"を不必要な残業をもってして表現する人間が「あいつは頑張っている」と評判になることなんてザラにあることだ。これはこの社会を構築する一人の人間として悲しいことで、恥ずかしいことだ。
そして更に、僕が最も悲しく最も恥ずべきことは、今のところその状況を打破し得る考えを僕が持ち合わせていないことだ。
社員に「クリエイティビティ」,「イノベーション」を求める企業と支払う対価について
銀の弾丸、クリエイティビティ・イノベーション
クリエイティビティという言葉の功罪、またその陰にあるクリエイティブでない仕事の重要性についてはtechcrunchに良い記事があったのでそれを紹介する。
クリエイティビティの罠――実務的な業務の重要性 | TechCrunch Japan
クリエイティビティは今やクリエイティブ職にのみ求められるものではない。営業、エンジニア、ディレクター、デザイナー、マネージャー、経営者。様々な職種の人間が多方面でクリエイティビティを発揮し、日々の業務やはたまたビジネスそのものにドラスティックな転換、言い換えるならばイノベーションをもたらすことが求められる時代となった。社員のクリエイティビティを高める方法を書いた本が経営者に売れ、自身のクリエイティビティを高める生活習慣ノウハウを書いたコラムが当然のように読まれる時代、各個人が社会に対しインパクトのあるイノベーションを起こす時代。
率直に言って、本当にそんな時代が来てるのか疑問に思う。僕が知る限り、僕の身の回りで個々人がクリエイティビティを発揮して破壊的イノベーションを起こしまくるような社会や組織が構築されたことはない。体面上そういったことを推奨する組織に属していたことはあるけれども、それは具体的な計画や還元に基づくものではなく建前として掲げられたものであったし、悪く言えば先進的な言葉を表面上取り入れただけの古びた夢想を個々人に押し付けようとしているだけだった。これからはコミュニケーション能力の高い人間を採用するといいらしい、これからは高いクリエイティビティを持つ人間を採用するといいらしい。なんとなくそんなような採用目標が立てられ、大して給与も上げずにより時代にあった能力の高い人間を採ろうとする。それで本当にイノベーティブで高いクリエイティビティを持つ組織が出来ると思っているんだろうか。高いクリエイティビティでイノベーションを起こし続けられるような人間が何故今更、杜撰な理想を抱く組織を必要としていると思うのだろうか。
リーダーシップがあって、クリエイティビティもあって、努力を惜しまず会社に貢献してくれる人材。断言しよう、そんな人間はいない。万が一いたとして、常識の範囲内の安月給で御社だけに雇われる理由がない。僕は本格的な採用には関わったことのない人間だが、無知を承知で言わせてもらう。企業というものは人を採用する際何故か自分のことばかり考えてしまい相手の視点に立てなくなってしまう。どんな人材が欲しいか、その一点のみで採用活動を進めてしまう。企業というものは利益追求のための組織であるから、企業が欲しい人材を企業が出したい金額で募集をかけるのは当然のことのように思えるが、しかし自分が欲しがっているものを正当に評価出来ていない点は僕からはとても歪に見える。欲しいものがいくらするのか。それをまともな感性で調べることも、まともな頭で想像することも出来ないなんてそこらへんの子供にも劣る愚かさだ。欲しいものの値段、扱い方、どう使うと役に立つのか、自分にそれが扱えるのかくらい調べてから欲しいと言いなさい。
クリエイティブ、イノベーティブな人材というのは、それさえ有れば現状を打破し得る銀の弾丸かなにかと勘違いされている。それは確かに銀の弾丸になり得るものかもしれない。しかし果たして、あなた方にその弾丸を扱う度量、環境、技術、支払える対価、銀の弾丸を銀の弾丸足らしめそれを維持させる準備があるのか一度胸に問うてみるべきだ。