先日、Twitterで「現行システムから新システムにデータ移行を行うと要件漏れが炙り出される」とつぶやいてみました。
こんにちは！ 松田軽太です。
Twitterでのやりとりはこんな感じです。
遠い目ww😂
— しるる (@sirururun) 2020年11月5日
ほんとに…品目レコード数見ただけで震えてますよ…😇管理を楽にしたいはずなのに外部要因で管理が煩雑になるのほんともう…😇ちゃんと管理の手間とかもコストに反映されてるといいんですけどねー…そこはお前らが改善しないから！なんて言われるのがオチなの見えてるのがまた辛い😂w
まぁ、マスタ管理の手間なんてタダだと思ってるでしょうね…｡:ﾟ(;´∩`;)ﾟ:｡
— 松田軽太 (@matudakta) 2020年11月5日
営業は強し、管理は弱し…
ﾍｰｼｬの基幹システムを入れ替えする時、品目マスターだけで数十万レコードありました。
— mas@Excel職人 (@keitai_kai) 2020年11月5日
システム構想にコンサルを招いて5年。
内、マスターの準備で2年。
マスターの移管テスト4回くらい。
データ移行テストも並行して実行。
本番導入に徹夜を数回しました。
それくらい大変。
とても大事。システム開発において、ユーザーからのヒアリングを盲信しない。例外時効を話してくれなかったり、時々しかない作業をとても大変だと強調してきたりする。だから必ず生データにもあたる。
— 甕星@Perfect Brown Lunchbox (@mikahosi) 2020年11月6日
ユーザーが悪いのではなく、求められる視点が違うし、そういう訓練を受けてないから仕方ない。 https://t.co/iFYk1HYszh
なにげなくつぶやいて内容ではありますが、大事なことだと感じたので忘れないうちにブログに記して行うと思ったのです。
さて、このTwitterでのやり取りで思い出したことがあります。
それは「システム開発を行うならデータ移行はなるべく早く行った方が良い」という話をでした。
要件定義での現場ヒアリングでは要件漏れを防げない
システム開発を行う場合、実際に作業で使ってる担当者にヒアリングを行いますね。
どんな業務をするためにどんな業務システムが必要なのかを知るためにはヒアリングは欠かせません。
ですが「ヒアリングですべての要件が引き出せるか？」といえば、それがけっこう難しいのが現実です。
なぜなら業務を行っている担当者は、その業務を知ってはいますが、他の人に説明することが出来ないことが多いのです。
まぁ、普段から業務内容を言語化する機会がないから、いきなり説明してくれと言われても抵抗があるのは仕方がないことではあります。
例えば数年に一回しか行わないような処理があった場合、ヒアリングでは出てこないことが多いのです。
業務担当者からしたら、数年に一回しかやらない作業だから、頻度が少ないのでたいした問題じゃないと考えがちです。
ですが、システムを組み上げる立場からすると、数年に1回だろうが2回だろうが、やる必要がある業務ならシステムの機能として考慮する必要があります。
では、これらのたまにしかやらない要件を見つけ出す方法はあるのでしょうか？
その方法の一つがデータ移行なのです。
データベースを設計できたら、早めにデータ移行してみる
業務システムを作り直したとき、データ移行を行うのって皆さんはどのタイミングでやってますか？
実際のシステム開発の現場ではデータ移行は最後ので行うことが多いと思います。
現行システムのデータを新システムに移行するだけの作業なのですが、テーブル数の種類とデータ件数も多いので地味に大変です。
しかし、データ移行を先に一回やっておくと、例外処理の痕跡が見つかることがあります。
例えばあるフィールドがあって、要件定義では、その項目は「1、2、3」の3種類しかないハズなのに、そこに「0」や「9」が入ってる場合があります。
それらはたいてい例外処理が発生して、SQLなどで無理やりデータを修整したのでしょう。（例外処理ってよく「9」が使われますね）
で、アプリ側でも「9」だった時には例外処理を行うようにプログラミングされてたりします。
なので怪しいフィールドを見つけたら、そのフィールドを使っているプログラムを検索してみると、例外処理のロジックを見つけることができるでしょう。
そうです、データはウソをつかないのです。
要件漏れは担当者が悪いのか？開発者が悪いのか？
要件漏れが起こった場合、それはすべての作業内容を説明できない担当者が悪いのでしょうか？
それとも要件を引き出しきれない開発者が悪いのでしょうか？
担当者からすれば「聞いてくれれば答えたのに。聞かないから悪い」と主張するでしょう。
開発者からすれば「すべての業務を教えてくれと言いましたよね？数年に一回しかやらない業務でも、やる必要があるなら業務システムにも機能として必要なのだから、言って下さい。こっちは業務をやってるワケじゃないから言わないと分からないです！」と主張するでしょう。
多くの現場では、このような言った・言わないの不毛な水掛け論で揉めることが多いのです。
そこには誰も勝者はおらず、お互いに疲弊するだけです。
水掛け論で消耗するくらいなら、データ移行を先にやってみるという手もある
こうした誰も得しない水掛け論に陥るのを防止するためにも、データ移行は最初の方で一回やってみると良いでしょう。
それこそ試験的に移行するだけなら、ACCESSみたいに手軽に使えるデータベースでも構わないでしょう。
エラーが見つかったら、しめたものです。そのデータはきっとワケアリですから。
上流工程入門を読んでみると良い
システム開発でよく迷走する場合というのは、必要な機能が明確でないのにとりあえず設計を始めるからです。
目的地が決まっていない船旅は、半分、遭難しているともいえます。
では上流工程を学習する方法はないのでしょうか？
僕は渡辺幸三氏の著書「業務システムのための上流工程入門」という本で学習しました。
データモデリングの本は沢山ありますが、その手前の上流工程をテーマにした本はあまり見かけません。内容が漠然しているから、書きにくいというのもあるでしょうね。
ウォーターフォールとアジャイル、どちらがいいのか？
システム開発というと「今どきウォーターフォールは時代遅れだからアジャイル開発すべき」といった手法の方に関心があつまりがちです。
先日、「ここはウォーターフォール市、アジャイル町 ストーリーで学ぶアジャイルな組織の作り方」の発売イベントでもこの話題が出ました。
まもなくはじまります
— 新井 剛／カイゼンジャーニー／いちばんやさしいアジャイル／ここはウォーターフォール市アジャイル町 (@araratakeshi) 2020年11月5日
#ここアジャ pic.twitter.com/VIMBmgpmkg
ウォーターフォールに向いているのは、あらかじめどういう業務システムが必要なのか明確になっているような場合です。
例えば在庫管理であったり、請求管理といったよう「どういう管理を行うのか明確になっている」場合です。
一方、アジャイルは仮設検証を積み重ねながら作り上げるので、新規事業向けのシステムのように試行錯誤を重ねながら作り上げる場合に向いてます。
ウォーターフォールにはウォーターフォールの良さがあり、アジャイルにはアジャイルの良さがあります。どっちが良いとか悪いではないのです。
なのでどちらの開発手法も知っておくと良いと思います。
