torum

主に開発中のアプリにまつわる技術系の事。

要件定義という時代遅れの慣習

前エントリで、

これから新しいモノを作ろうという時に、特定のサービスや業務の構成要素と機能(つまりビジネスドメインビジネスロジック)を隅々まで初めから予見したり、全て理解している開発者なんていません。(業務システムの場合、SEが業務担当者に聞き取りをして要件定義だ、なんて言っていますが、しょせんITに疎い素人で全体像も見えていない担当者が業務内容に疎いSEつまりはその業務分野のド素人に教えるとかいう悪夢)

アプリは2度作り直して初めて使い物になる - torum

という文を書いていて改めて思った事ですが、この点、補足しておきたいと思います。

よくある間違い。

要件定義=システム設計である。

要件定義とは、システム開発を請け負う委託契約上、後々お互いに齟齬が起きないように、予め「どこまで何をどうやるか」を決めておく「契約上の取り決めの一部」に過ぎない、という事です。あくまでも契約上の「予防線から生まれたものです。

直近では、要件定義をしたのにも関わらず、契約違反で訴訟沙汰になった、などという野村HDの事件もありました。野村HDのケースは担当者側のサボタージュだったとかいう話しもあるので、それはそれでまた別問題でもありますが・・。

恐らくは発注側がそもそも要件を把握できていなかった、と思われる理由で、京都市での基幹システム刷新が2度も失敗するとかいう事態も起きています。こういうも「要件定義=システム設計」という勘違いから生まれていると思われます。

要件定義とは、請負契約上「どこまで何をどうやるか」を事前に決める話しであって、そんなものを元にシステムを開発設計しても当然のように碌なものが出来ません業務上使いやすいものが出来るとは限りません。なので「契約の仕様通りに作ったので使いにくくても知った事ありません」と言われて終わり、なんていう事になります・・・

システム設計とは、現実のドメインロジックに合わせて設計するもので、開発者自身に、対象となるドメインの業務知識や業務フローに関する幅広い全体的・俯瞰的な知識が必要です。そうでないと、使いやすいものは出来ませんし、そもそも野村HDのように担当者の一存で出来あがる前から滅茶苦茶になったりします。

ではどうするかというと、究極的には、開発者自身がその業務に実際に関わる、または、その分野でシステムを一度作ってみる、という二つの方法しかありません。

にも関わらず、これを、日本のITゼネコンとかが請け負って、プログラミングも出来ないSEとかいう職種を独自に作って「上流工程」だとか「要件定義」とか言って、実際に開発するのは下請け、孫請けの開発者達に丸投げしている構造があります。これじゃまともなものは作れません。すべてのやり取りが素人同士の伝言ゲームとなるので、悪夢以外の何ものでもありません。

 

NTT系列や国内大手ITベンダー(日立、NEC富士通)の三社、外資系ITベンダー(IBM、HP、Oracleなど)系列のSIerが大手の顧客を囲い込み、インフラ構築からコンピュータ機器の設置、納入後の運用メンテナンスに至るまでを一括受注して利益を得ており、実際のプログラミングやテスト作業を中小のSIerに丸投げしている状態となっている。

ITゼネコン - Wikipedia

 

日本とアメリカでは、エンジニアの勤め先から大きく異なっている。日本のエンジニアの多くはIT企業に勤めており、ユーザー企業から依頼を受けて開発を行う。そのため大手企業の運営するサービスであっても、実は全く名前が知られていないような会社が開発したということが起こるのだ。
一方アメリカでは、エンジニアの多くが勤めているのはユーザー企業だ。自社サービスの開発に力を入れており、成功失敗に左右されるというのも先ほど述べた通りである。
この違いは発注者・受注者の関係に大きな影響を及ぼす。アメリカでは発注者・受注者は共に同じ会社の人間だ。コミュニケーションはスムーズに取ることができ、遠慮なく意見交換を行えるだろう。

[中略]

柔軟性に欠ける開発手法

日本のソフトウェア産業では開発手法としてウォーターフォール型が一般的だ。1970年に提唱され今なお活用されている手法である。しかし、これもまたやや時代遅れの手法となっている。
この手法は、まず始めに要件定義、それから設計、プログラミング、テストという手順を踏んで納品に至る。

なぜ、日本のソフトウェア品質は悪いと言われるのか?https://blogs.techvan.co.jp/quality/quality-bad

 

しかしながら、大抵の顧客は、最初から自分の欲しいソフトウェアをはっきりと説明できないことが多く、出来上がったソフトウェアを見てから、自分の欲しいものではなかったと気づく。また、近年のビジネスは変化が非常に早く、要求が刻々と変化していく場面でそそれを固定するのは困難である。その影響から、結果的に無駄な作業が発生し、追加の作業によって納期が遅れることが多い。

非ウォータフォール型「アジャイル」の必要性

 

前述の野村HDのケースでは、ITゼネコンに開発を丸投げし、ITゼネコンは自社で開発するでもないどころか、そもそも出来合いの海外製システムを流用しようとしたとか(よくある話し)。ITゼネコンのパッケージ「ソリューション」なんて、大抵中身は名前を変えただけの海外製。そもそもそんなITゼネコンなんて存在意義はありません。

既製品を使うなら、野村HDが直接海外の開発元から購入するなり、カスタマイズを依頼すればよかった話しです。もし業務フローを既成システム側に合わせられないというのなら、外注するのではなく、自社開発するべきです。デジタルトランスフォーメーション(DX)とはそういうものです。

そもそも、建設業や製造業といったハードウェアの産業構造である日本特有の旧態たるゼネコン体質をそのままITの世界に持ち込んだのが間違いだったのです。

例え出来上がっても、「完成形」の要件イメージ自体が間違っており、実際には使い物にならず、結局また一から作り直し、なんて事になるのがオチです。この手の失敗例は日本の大規模開発でも有名な失敗例は幾つもあります。そもそもハードウェアの製造業とは違い、ソフトウェアに「完成形」など存在しない、という考え方もあるのです。

ITの世界では、ソフトウェアやサービスはベータの段階などで早めにリリースして、フィードバックを得て改良、アップデートしていくのが正攻法であって、一度リリースしたら変更できないいわゆる製造業の製品サイクルとは大きな違いがあるのです。ハードウェアと比較すると、ソフトウェアは「生き物」だ、という言い方も出来ます。

アプリは2度作り直して初めて使い物になる - torum

 

これを根本的に理解できていない為に、自社のシステムをITゼネコンに丸投げしてしまう日本企業の経営陣の問題もあるのでしょう。

 

「サービスをリリースしたら終わりではなく、リリースしてからが勝負だ」と話した。そのためにも、デジタル化のプロセスについて「アジャイルで小さくつくるように変えていく必要がある。小さくつくってから発展させること、失敗をある程度許容していくこと、時にはやめることも大事だと考えている」(津脇企画官)

https://xtech.nikkei.com/atcl/nxt/column/18/01651/062500011/

 

コロナ禍と共に、デジタルトランスフォーメーション(DX)だ、なんて話しが出てくると、すわっとばかりにITゼネコンが飛びついてきて、バズワードを散りばめた中身空っぽの売り文句で広告や営業を掛けてきます。本来のDXは、そういうITゼネコン依存から脱却することから始まるのですけれどもね。

 

日本企業のIT化が進まない理由として挙げられるのが、諸外国とは異なる「日本特有のSI業界の産業構造」だ。国内のIT人材をSIerが一手に抱え、ユーザー企業はそのSIerにITシステムの企画・構築・運用を発注する――。日本ではすっかり常態化したこの産業構造だが、実は海外ではこのようなやり方は必ずしも多くはない。そしてこの産業構造は、過去には有効に働いていた時期もあったが、現在では非効率な面が目立つようになってきている。

日本企業のIT化はなぜ進まないのか――日本特有のSI構造とエンタープライズITの在り方から探ってみると – データのじかん

 

つまり、本来、発注側が主体的に開発するか、開発経験のある開発者達がその経験を生かしてパッケージ製品的なものを開発し、販売導入サポートをする、といった形が当たり前のやりかたなのだと思います。請負契約時の要件定義というのは、どうしてもの際に、必要悪として存在しているようなものです。

 

追記:日経が面白い記事を出した。

www.nikkei.com

 

日本企業におけるIT(情報技術)人材の不足は、平成バブル崩壊後の1990年代に情報システム部門が本体から切り離された影響が大きい。当時「ノウハウ集約」「専門性の向上」といった大義名分で設立された情報子会社の多くは、コスト削減目的のアウトソーシング(外部委託)が実態だった。システムを受託開発する大手の「システムインテグレーター」の下請けからエンジニアを出向で派遣してもらい、依存が強まった。

60~70年代に大型汎用機(メインフレーム)を導入した当時の「電算部」から蓄積してきた「情シス」のノウハウと人材が途絶え、IT投資はシステム業界への丸投げが常態になった。自社業務に都合よく独自仕様で導入したERPは継ぎはぎ改修を繰り返し、設計にかかわったシステム会社しか触れない「ベンダーロックイン」にはまっていく。


この間、欧米では汎用パッケージソフトが広がったが、日本企業は身動きがとれずにいた。経営トップにDXが競争力を左右するという意識が薄く、システム会社もベンダーロックインで稼いでいたからだ。ある大手ソフトウエア会社の経営者は「情報システム担当者は業者との蜜月関係を守ってきただけ。ある種の怠慢があった」と日本企業の不作為を嘆く。

 

米ガートナーによると、日本企業の売上高に対するIT予算の割合は20年に推定1.0%。北米の3.3%、欧州・中東の2.6%に水をあけられている。しかもIT予算のうち外部委託費の比率が34%と高く、ユーザー企業のシステム内製化が進む北米の20%と比べると丸投げ体質が透ける。

 

DXの出遅れを取り戻す解のひとつが内製化だ。ホームセンター大手のカインズは19年にデジタル戦略本部を設け、自社エンジニアやデジタルマーケティング担当者を約150人に増やした。店員向けの在庫確認アプリなどを矢継ぎ早に実用化した。米マイクロソフト出身の池照直樹本部長は「80点の出来でもいいからまずスタートさせ、現場の意見を聞いて走りながら改善する」という。

 

しかし、米国の同業、ホーム・デポは1000人規模でエンジニアを採用するなどケタが違う。同国では情報システムのプロがCIO、CDO(最高デジタル責任者)、CTO(最高技術責任者)といった肩書で業界の垣根を越えて移籍するのが一般的。

 

バブル崩壊をきっかけに、外部丸投げが始まり。以降、慣れ合いで、ITゼネコンつまり「システムインテグレーターSIer)」にベンダーロックインされたままきてしまった。

というお寒い状況。