松田軽太の「ひとり情シスのすゝめ」、タイトルだけ見るとひとり情シスを推奨しているように思われるかも知れませんが、思いはまったくの”逆”。様々な事情によりやむなく”ひとり情シス/ゼロ情シス”という状況になってしまっても頑張っていらっしゃる皆様のお役に立つような記事をお届けしたいと思っております。

先日、Twitterで「現行システムから新システムにデータ移行を行うと要件漏れが炙り出される」とつぶやいてみました。
なにげなくつぶやいて内容ではありますが、大事なことだと感じたので忘れないうち書き出しておきます。

まずはTwitterでのやり取りをご覧いただきましょう。

さて、このTwitterでのやり取りで思い出したことがあります。

それは「システム開発を行うならデータ移行はなるべく早く行った方が良い」という話をでした。

 

要件定義時点での現場ヒアリングでは要件漏れを防げない

システム開発を行う場合、実際に業務で使ってる担当者へのヒアリングは必ず行うでしょう。どんな業務をするためにどんな業務システムが必要なのかを知るためにはヒアリングは欠かせません。

ですが「ヒアリングですべての要件が引き出せるか？」といえば、それがけっこう難しいのが現実です。
なぜなら業務を行っている担当者は、その業務を事細かに知ってはいますが、他の人に説明することが出来ないことが多いのです。
普段から業務内容を言語化する機会がないから、いきなり説明してくれと言われても抵抗があるのは仕方がないことではあります。
一時期、日本企業でブームとなったISO9001の業務分掌などが残っていればわかりやすいのでしょうが、例えば、数年に一回しか行わないような処理があった場合、ヒアリングでは出てこないことが多いのです。

数年に一回しかやらない作業だから、頻度が少ないので大した問題じゃないとは業務担当者も思っていないでしょうが、伝統継承のような”口伝”には限界もあります。
しかしながら、システムを組み上げる立場からすると、数年に1回だろうが2回だろうが、やる必要がある業務ならシステムの機能として考慮する必要があるのです。

では、これらのたまにしかやらない要件を見つけ出す方法はあるのでしょうか？

その方法の一つがデータ移行ではないかと思います。

 

データベースを設計できたら、早めにデータ移行してみる

業務システムを作り直したとき、データ移行を行うのって皆さんはどのタイミングでやっていらっしゃいますか？
実際のシステム開発の現場では、データ移行は最後の最後で行うことが多いのではないでしょうか？
現行システムのデータを新システムに移行するだけの作業なのですが、テーブル数の種類とデータ件数も多いので地味に大変な作業です。

しかし、データ移行を先に一回やっておくと、例外処理の痕跡が見つかることがあります。

例えば、あるフィールドがあって、要件定義では、その項目は「1、2、3」の3種類しかないハズなのに、そこに「0」や「9」が入ってる場合があります。それらはたいてい例外処理が発生して、SQLなどで無理やりデータを修整したのでしょう。（例外処理ってよく「9」が使われますね）
そして、アプリ側でも「9」だった時には例外処理を行うようにプログラミングされてたりします。
なので怪しいフィールドを見つけたら、そのフィールドを使っているプログラムを検索してみると、例外処理のロジックを見つけることができるでしょう。

そうです、データはウソをつかないのです。

 

要件漏れは担当者が悪いのか？開発者が悪いのか？

要件漏れが起こった場合、それはすべての作業内容を説明できない担当者が悪いのでしょうか？
それとも要件を引き出しきれない開発者が悪いのでしょうか？

担当者からすれば、「聞いてくれれば答えたのに。聞かないから悪い」と主張するでしょう。
一方で開発者からすれば、「すべての業務を教えてくれと言いましたよね？数年に一回しかやらない業務でも、やる必要があるなら業務システムにも機能として必要なのだから、言って下さい。こっちは実際に業務にかかわっているワケじゃないから言ってもらわないと分からないです！」と主張することでしょう。

実際、多くの現場では、このような”言った・言わない”の不毛な水掛け論で揉めることが多いのです。

そこには誰も勝者はおらず、お互いに疲弊するだけです。

 

水掛け論で消耗するくらいなら、データ移行を先にやってみるという手もある

こうした誰も得しない水掛け論に陥るのを防止するためにも、データ移行は最初の方で一回やってみると良いでしょう。
それこそ試験的に移行するだけなら、ACCESSみたいに手軽に使えるデータベースでも構わないでしょう。
エラーが見つかったら、しめたものです。そのデータはきっとワケアリですから。

 

上流工程入門を読んでみると良い

またシステム開発でよく迷走する場合というのは、必要な機能が明確でないのにとりあえず設計を始めるからです。
仮に自分のボートで航海に出ることを想像してみてください。航海には食料、燃料、気象情報など様々な要因が関係します。そして目的地が決まっていない航海は、半分、遭難しているといっても過言ではありません。

では上流工程を学習する方法はないのでしょうか？

まずは本で学習するのもありではないでしょうか。
世の中にデータモデリングの本は沢山ありますが、その手前の上流工程をテーマにした本はあまり見かけません。
内容が漠然しているから、書きにくいというのもあるでしょうね。
その中でも自分は渡辺幸三氏の著書「業務システムのための上流工程入門」という本が良かったです。

ウォーターフォールとアジャイル、どちらがいいのか？

システム開発というと「今どきウォーターフォールは時代遅れだからアジャイル開発すべき」といった手法の方に関心があつまりがちです。
先日も、「ここはウォーターフォール市、アジャイル町　ストーリーで学ぶアジャイルな組織の作り方」の発売イベントでもこの話題が出ました。

ウォーターフォールに向いているのは、あらかじめどういう業務システムが必要なのか明確になっているような場合です。
例えば在庫管理であったり、請求管理といったよう「どういう管理を行うのか明確になっている」場合です。

一方、アジャイルは仮設検証を積み重ねながら作り上げるので、新規事業向けのシステムのように試行錯誤を重ねながら作り上げる場合に向いてます。

ウォーターフォールにはウォーターフォールの良さがあり、アジャイルにはアジャイルの良さがあります。どっちが良いとか悪いではないのです。なのでどちらの開発手法も知っておくことが良いですよね。

 

※本記事は松田軽太氏許諾の元、「松田軽太のブロぐる」の記事をベースに再編集しております。

---

松田軽太（まつだ・けいた）

とある企業に勤務する現役情シス。会社の中では「何をしているのかナゾな職場」でもある情シス業務についてのTipsや基礎知識などを紹介する。

ブログ『松田軽太のブロぐる』を運営。