「DXだって基幹系だって大丈夫！」生き延びるための要点定義よ、こんにちは
以下は、前回に続き９月に日経クロステックに掲載された記事の元原稿を校正したものになります。全二回の二回目分になります。実際掲載された記事とは内容が異なる部分がかえって面白いかと（勝手に思っています）！
■要件定義、その実際
前回の最後に実際の要件定義の現場でよく見かける状況について書いた。
実際の作業を下の階層に所属する下請け技術者がやる場合は、様々なところから寄せ集められたメンバーなので当然のことながらレベルもまちまちでまさに玉石混交である。
またベンダー企業が頼りにならずユーザーの担当者が上から命じられて大した知識もないのにやらざるをえない場合もある
・要件定義という工程にアサインされた二次、三次（四次）請け技術者
・いきなり要件定義はお前の担当と命じられたユーザー企業の担当者
あなたが上記の立場のいずれかでエンタープライズ系の業務システムの要件定義をやり遂げなくてはならないとしたらどうすべきだろうか？
要件定義がうまくいかない原因は、超上流の不備、つまりそもそもの要求が明らかでないことが多い。何がしたいのかわからないのにどうすべきかわからない。確実に迷走していく。
PMの段取り不足もよくある話だ。
WBS上に要件定義という工程が記載されているものの、何をする工程なのか曖昧でユーザー、ベンダーそれぞれの役割について合意がとれていないことがある。
何をするのかよくわかっていないユーザーは的外れの要望を出してくる。そして方向性を失い要件は膨れ上がっていく。
要望、要求、要件を混同していることも多い。
要望とは、やりたいことの元ネタである意見、考え等を指す。思いつきのレベルであることが多い。要望同士は相反したり矛盾しているものが混在している。
要求とは、やりたいこと,目指すべきことを指す。「目指すべき姿」である。当然、要求同士の整合性が取れていなくてはならない。
要件とは、実現すべきことを指す。「実現すべき姿」である。要求同様整合性の確保は必須である。
声の大きいステークホルダーの単なるわがままな要望をそのまま要件とみなすようなことはNGだ。だが現実にはやってしまう技術者が多い。結果として役に立たないシステムもどきができあがることになる。
■多重下請け、その実際
多重下請けはDXブーム？もあって二次請け、三次請け含め業績が好調らしく、新規参入が増加していると聞く。業界として活況、ということになる。
ただ、現場で働く人間にとって今も昔も環境がいいとはいえない。痛みを伴うことすらある。長くやっていると精神的に疲弊していく。
「働く人間が我慢すればいいんだよ」「嫌ならやめれば」
昔、私は先輩からよくそう言われた。
「代わりはいくらでもいるよ。」
今はわからないが30数年前の私は消耗品扱いだったのだろう。
ただ、私が元ホームレス寸前から社会復帰する足掛かりをつくってくれたのは紛れもない事実であり、この多重下請けという生態系に生息する最下層のIT技術者という仕事がなければ今ごろ野垂れ死にしていたかもしれない。私なりに多少なりとも恩返しはしたい。
https://xtech.nikkei.com/atcl/nxt/info/18/00037/122700098/
要件定義をやらされる下請けには色んな人がいたようだ。
スキルシート上では豊富なスキルを持っていることになっているものの、実際には時間稼ぎして金を稼ぐことに慣れてしまった下請け根性丸出しのベテランがいた。
片や、キャリアは長くないものの今まで経験した現場でなんとかやってきたことに対する自負を持っている若手がいた。彼らはたとえ技術は素人まがいであっても成果物を形にしようと頑張っていたようだ。
彼らのやる気をつぶしたくなかった、と知人は力説していた。
「どんな人がいいかな？」 新規にアサインする技術者のスキルを聞いたところ
「真面目な人」「朝会社に来る人」「その日のうちに何らかの連絡くれる人」という回答が返ってきた、という。それを聞いて少し泣けてきたそうだ。
「スキル以前の話じゃないか・・・」
せめて彼らが生き延びることができるようにアドバイスしたい、と切に思ったとのことだ。
■ユーザー、その実際
突然ユーザー企業のシステム部門に所属する若手が要件定義をやるように命じられたことがあった。命じた上司に聞いてみると器用そうなのでやらせてみようと思った、とのことだった。実際にはノーコード開発ツールでUIに項目を張りつけたり、HTMLを少しいじった経験くらいしかなかったらしい。
最近システムに対する基本的な知識を習得することなく小手先だけの作業しかやったことがないのに一人前とみなされる風潮がある。彼もそうだったのだろう。
やる気がないわけではないのだが何をどうしていいかわからないので、頭を抱えることになる。
当然、主体性を発揮するなんて話は夢物語になってしまう。
■データ中心、その実際
システム開発現場ではユーザーの主体性のなさ、ユーザーとベンダーの関係性、ベンダーの多重下請け構造 等の大きな問題を抱えつつ、かたやユーザー企業は生き残るためにデータ（ドリブン）経営の実践を求められている。
データ、AIの活用こそが企業の命運を握るとまでいう人もいる。
ただこれらはデータをかき集めて、こねくり回してAIにかますためにどうするかといった話が多いようだ。
これから発生するデータの源からなんとかしようといった議論が希薄であるようにも思える。
何故、基幹系、DX問わずシステムが生成、参照、更新、削除するデータに着目しないのだろうか。何故、そこからデータドリブン、データ中心でやろう！という話がでてこないのか。
突き詰めてシンプルに考えてみよう。
経営がデータを重要視するのであればその根幹を支えるシステムを開発する際にはシステムの目的、方向性を定める超上流、上流工程からデータ中心でやった方がいいのではないだろうか。実装に近いところはそれぞれのやり方でやればいい。
もちろん、データの発生源はスクラッチ開発したシステムのみで発生するわけではなく、ERP、SaaSサービス等多様である。それも上流工程からやればデータ中心で包含できる。
そして可能であればデータ中心という魂を開発現場まで継承することだ。要件定義も例外ではない。
経営と開発現場はあまりに遠い。別世界でもある。でも魂を継承することができれば少しは近づくはずだ、と私は信じている。夢想家なのかもしれない。勘弁願いたい。
■解決策、その実際
要件定義をうまくやって生き延びるためにはどうすればよいだろうか。
私なりの見解を３つほど提案したい。
・解決策1： コミュニケーション
階層や立場はさておき、多くの人に会い、目を見て話をしてみる。
まずはそこから始めてみよう。目を見て話せばお互いのことがわかってくるはずだ。嫌な奴だと思い込んでいた人が一番の協力者だったなんてことに気づくこともある。
「でも直接人と話すの苦手なんだよな・・・」
一度、覚悟決めてやってみることだ。
どうしても駄目なら他のコミュニケーションを考えればいい。今ならいろいろある。びくびくすることはない。自分の軸をしっかり持つことだ。
「タングル」とはいう言葉をご存じだろうか。もつれる、絡み合う、混乱、ごたごた、といった意味だ。
自分にできないこと、どうしようもないことを一人で抱えて悩む必要はない。落ち込む必要もない。
困ったらタングルをとにかく、なるべく上へ放り投げるのだ。ベンダーの下請け技術者であれば三次から一次二次へ、ユーザー担当者であれば幹部へエスカレーションしていくことになる。
手に負えなかったらさらに上に渡してもらう。
また、回りを見回してみて、まず近いところにタングルを手渡そう。同じような立場の人間と情報共有するのも手だ。
もっと責任をとらなければいけないはずの人、自分よりもう少しこの現場のことをわかっている人にどんどん託そう。いろんな立場の人が受け取れば動いてくれる人が出てくるはずだ。
最終的にはユーザーの上層部とベンダーの元請けに委ねるのが理想だ。
・解決策2：ドキュメンテーション
要件定義の成果物は、様々なステークホルダーの同意、プロジェクトとして求められるレベルの見積が可能であり、設計のインプットとして有用である必要がある。
同意が必要となるステークホルダーは幅広い。ビジネス、業務、システム担当、開発者等、様々である。どんな人間が関わってくるかなんてわかったものではない。それならば不特定多数がわかりやすい表現を使った方がリスク回避になる。「立場の違いを超えたわかりやすさ」を目指すべきであり、そのためには言葉だけではなく図式を使った方がいい。
「4点の図を描く」
これはJUAS高度化プロジェクトで提唱したDxBA、通称DOBAの実践方法の一つでもある。昨年noteでも記事に書いた。DOBAとはデータ中心型ビジネスアプローチを意味する。
成果物を決められるのであれば4点の図から「目指すべき姿」「実現すべき姿」を明らかにするのが要件定義を成功に導く近道だ。
でも残念ながら、工程に入る前には成果物がすでに決められていることの方が多い。
そういった場合は、4つの図の視点で内容を見直してみて、決められた成果物のフォーマットに落とし込めばよい。
その際、要件定義はユーザーとベンダーの共同作業である、という基本原則は忘れてはいけない。主体性はユーザーが持たないといけないのは間違いない。やりたいことなんてベンダーにわかるわけがない。
ただ、ユーザーだけでは要件を明確にするのは難しい。実現性の可否判断には技術的な側面を伴うからだ。アーキテクチャは昨今どんどん複雑になっている。ここはベンダーの出番だ。
ユーザーとベンダーの間で「目指すべき姿」について両者が腹落ちするレベルまで具体的なイメージに落とし込まれていれば「実現すべき姿」は明らかにしやすい。それを可能にするのが4点の図なのである。
■解決策3：要求を明らかにする
要求とは「目指すべき姿」であり、要件定義とは、要求に現状、制約、前提を加味して「実現すべき姿」を明らかにすることである。
そもそも、この「目指すべき姿の明確化」＝要求分析／定義が軽視されているように思えてならない。
本来は企画自体が明確な要求を基に策定すべきである。RFPを作成する際には明確な要求が反映されているべきだ。ところがこのあたりがふわふわしたまま要件定義に突入するプロジェクトが多い。
こうなると、曖昧な要求もどきを基に要件定義やり遂げなくてはならなくなる。
「何を参考にすればいいのか・・・」
アサインされた技術者は当然のように戸惑う。
インプットが明確でなければ、よりどころがないところから「実現すべき姿」を導き出すという作業が必要になるが、これはとても困難である。
システム開発の失敗の多くが要件定義に起因するのはこのあたりにある。
つまり要件定義自体がうまくいかなかったというより、その前工程がまともにできてなかったことがほとんどである。
必要なインプットとは「目指すべき姿」、現状、制約、前提であり、不足していれば補う必要がある。
つまりなんちゃって要件定義もどきを少しでも良い方向に持っていくには限られた時間の中で要求まで遡ることだ。少しでも明らかになってくれば見える景色も変わってくるはずだ。
■自分の身を守ろう
エスカレーションを実際に行う際には、いろいろと難しい局面にぶち当たることがある。
「面倒くさいからいいや・・・」
諦めてはいけない、
是非ともトライすべきだ。
可能な限り他の人の立場は尊重したいものだ。ただ、なにを最優先すべきかといえば自分の身と心だ。放り投げるのは逃げではない。
とてもエスカレーションできるような環境ではなかったら？
放り投げたタングルを誰も受け取ってくれなかったら？
そんな状況なら自分が壊れる前に早くその現場から逃げた方がいい。
責任を感じる必要は全くない。
どうせ誰がやろうとそんなプロジェクトはうまくいかない。
ただ、そうならないために是非ともＤＯＢＡおよび4点の図を活用してほしい。
⇒DOBA（DxBA）については以前の記事を参照ください。
「自分には権限がない」「そんな立場にない」「工程にアサインされただけなので」
でも4点の図の視点で見直しくらいはできるし、その必要性を進言することくらいしてみよう。
「全体像」「ありかた」（データ）「流れ」（プロセス）「実践すべき行為」（データとプロセスの関係性）という４つの視点で見直してみる。欠けているようであればどうやって補強すればよいか皆で考える。
もちろん他のやり方であっても全然構わない。
もし技術者としてプライドがあるならば投げ出す前に最後の悪あがきをしてみてもいいかもしれない。