Develop with pleasure!

福岡でCloudとかBlockchainとか。

業務アプリケーションのシステム化

豆蔵の山岸さんの記事。
【インタビュー】業務領域は工学的手法で立ち向かえ! - 豆蔵代表取締役社長 山岸耕二氏 (2) 役立つシステムを作る「要求開発」 | エンタープライズ | マイナビニュース

「上流工程を工学的な手法で進めていく」というキーワードに興味を持った。別に記事にあるように要求開発アライアンスの定義する要求開発が最高という思いは無いが(あれをそのまままともにやると、案件になる前の価格競争で勝負するのが難しい=まぁ結局それはお客さんと要求開発の価値を共有できていないことに原因があるのかもしれないけど)、工学的手法でシステム化を進めるというのは確かだと思う。

当然、業務アプリケーションを構築する上で、我々は顧客以上に業務ドメインに詳しい訳ではない(コンサルとかだと別か?)し、我々の仕事は顧客の利益に繋がる業務アプリケーションを提供すること。=顧客の言うシステムをそのまま作ることではない。当然そこには、システム的な矛盾、サービスレベルを保障できるだけの仕様、本当にシステム化すべきものの判断等、顧客が顧客であるが故に気付かない部分も多い。そういった部分を解消するのがきっと我々の仕事。

ただ、その目的を実現するための手法というのは多種多様。最近は、インターフェースとなる画面をいち早く顧客に確認してもらって変更ありきでシステムを可能にするスピード開発、プログラミングファーストといった手法もある。これは確かにインタフェースが明確になることでより顧客に実感しやすい材料を提供する可能になり、システム開発のスピード化、認識の齟齬の解消に繋がるかもしれないけど、インターフェースが前面に出るが故に、どうしてもインターフェース中心の議論になりやすく、本質のビジネスロジックや仕様が埋もれたままになるって可能性も多いにあるんじゃないかと思う。

Railsのセールストーク等で変更ありきでインターフェースを早い段階で確認しようとする動きは盛んだけど、本質的な仕様をきちんと抑えていないと意味が無い。「工学的な手法」というキーワードで、そういった風潮をふと振り返る機会ができた。が、だからといってこれが解だってのは中々分からないのも事実…。