最近はエンドユーザーと会話してシステム開発するような仕事から遠ざかっているのだけど、開発フェーズで要件定義という作業は今でも行っているのだろうか。
何をするかというと、IT導入の契機として流行というのも大きな要因の一つだけどコストを下げるのが今でも最大の要件定義だろうと思っている。
一般的にはIT化で人減らしをして経費削減するのだと思われがちだが、そんな考え方は人件費が一番高いと言い続けて、給与を上げてこなかった日本企業全体の罠でしかない。
人件費が高いと言うよりも、結局1番コントロールしやすいのが人件費なので、そんなふうに言っているだけだ。システム導入の要件で人件費を下げたいと言ったことはあまり聞かない。
そんな要件を経営者が出したところで担当者が自分の仕事を減らすようなことをする訳が無い。
結局システム導入しても、その仕事のルーティンがトータルで複雑で属人化したものが出来上がることになる。
システム開発側にしても、提案するのは利用者が見やすいとかその程度のことで、トータルコストがこれだけ下げられるからこうしたものにしよう、今これだけ費用が発生するけれど、年間これだけコストが減り付加価値がこれだけ発生して何年で費用回収してそれ以降はプラスの上積みですと言ったことを言える企業はどのくらいあるだろう。
だとすると、今までの要件定義と言うのは一体何だったのだと思うのだ。
だが、IT企業の中にはプラットフォーマーと呼ばれる化け物が存在する。
彼らは自社製品の要件定義を使いやすさにだけ特化させる。
それはユーザインタフェースだったり、処理速度だったりで明確だ。
これを使ってこうしましょうとかいうのは、プラットフォーム上で動くシステム開発の仕事なのだから当然だ。
大昔にはユーザの業務を理解してコンピューター導入で業務の効率化を提案するのがシステムエンジニアと捉えられていた。
彼らが要件定義を行い、ユーザ承認を経て、開発チームの作業ベースとなる基本設計書に落としていく。
それを開発側の上流工程担当者が機能設計、詳細設計へと落としこんでプログラマが製造、テストをするというドロップダウンが王道だった。
いつの間にか、要件を製造工程にまず適用して、製造速度を上げる動きもある。
それの究極がノーコードツールだろう。
何だか理想の開発手法に見えるが、それこそ要件定義がハッキリしていないなと思うのだけど。