今回のブログはシステム開発時におけるデータモデリングの最も新しい進め方をご紹したい。最近、アジャイル開発の世界でMob Programming という新たなプログラム開発手法が密かに脚光を浴びている。従来のペアプログラミングからさらに進化して、複数人で大きなスクリーンに向かってコーディングするスタイルは、極度な分業におけるコミュニュケーション問題を早期に解決し、品質と生産性を向上させようというものだ。今回のプログでは、Mob Programmingの話はそちらの専門家にお任せするとし、データモデリングへのモブの適用(Mob Data-Modeling:筆者の造語)についてお話したい。
最近、とあるシステムの上流設計の仕事で、お客様に「そのデータモデルが正しい事を証明して欲しい」と言われて、どう答えたら良いものかと少し悩んだ事があった。画面、帳票などからリバースエンジしたデータモデルは、通常その次なるプロセス設計工程にて検証される。しかし、それ以前の論理データモデル段階での正しさをどう保証したら良いか?という質問である。
この質問に対する答えとして、「ペアプログラミングならぬ”ペアモデリング”を行なっています。生い立ちの違う二人のデータモデラーの視点からお互いにモデルをチェックする事で、その品質を担保しています」と答えた記憶がある。もっとも、データモデルがシステムの内部構造であるが故に、画面設計のようにアジャイル手法を用いたユーザビリティーの検証とは行かないのが歯がゆいが。
二人のデータモデラーがユーザ業務ヒアリングによる同じ知識のもとで、1つの対象システムのデータモデリングを行えば、少なくともお互いが持つ経験的セオリーを補完し合い、1人のモデリングより高い品質が得られることになる。そして、後工程の物理設計では、出来上がった論理モデルに対して同じ知識を共有する二人のモデラーの下で、さらなる分業が可能になる。最近、私自身もモデリングの現場で、大型の液晶ディスプレイを前に、一人のドライバー(若手)と一人のナビゲーター(私)とで、ああだこうだとコミュニュケーションしながら、モデルの品質を高める作業を行っている。このスタイルの立役者は他ならぬ大型の液晶ディスプレイとモデリングツールである。かつてはかなり高価だった液晶モニターも今では手軽に手に入るので、ぜひ導入をお薦めしたい。
それでは、上記のナビゲーターの人数を3人、4人と増加させ、メンバー間の知識の総和をモデルに組み込み、メンバー間のナレッジ共有が出来ないものだろうか。私はこれが可能であると断言したい。なぜなら、かつて液晶ディスプレイもない前職時代(今から20年程前)に、データ中心でシステム設計を行う際、エンドユーザを含む5,6人でのモデリング合宿を度々行っていたからだ。そこでは大型ディスプレイの代わりに模造紙、モデリングツールの代わりにポストイットカードとボールペンであったが、参加メンバー全員がお互いにコミュニュケーションし、2,3日でデータモデルの骨格が完成していた(もちろんリファクタリングに相当するモデルのさらなる汎化や例外事象への検証は後工程に続くが)。このようなローテクでも出来たのだから、これがIT仕掛けの大型スクリーン、高速なPC、気の利いたGUIのモデリングツール、そしてGOOGLE博士の力を借りれば、さらに高い品質と生産性を狙えるはずである。
ところで、大型スクリーン、メンバー全員を収容できる会議室といった環境が整うだけでは勿論だめである。ここで、”Mob Data-Modeling”を実施する為の3つの前提条件を揚げておきたい。⇒1つ目はデータモデルのノーテーション(記述様式)の統一とメンバーの理解である。ER図の様式は単にIE表記かIDEF1X表記かといった表面的なものではなく、バックナンバー2017.1.22にあるようにエンティティ配置の一定の規則に則る事が重要である。即ち参加者全員がモデルを見て瞬時に同一の認識を持てる必要がある。
⇒2つ目は参画メンバー各人が交代でドライバーを務めるのに必要なPCの巧みな操作(モデリングツールも含む)ができる事である。これは若い世代であれば当たり前だが、高齢のモデラーにはちょいとキツい。その場合は、高齢者はナビゲーターに徹するのもアリだろう。メンバーの意見を即刻反映できる素早いPC操作ができなければメンバーの思考中断の原因になる。
⇒3つ目はメンバーのモデリングに関するノウハウの共有である。これはメンバー間で格差があってもしょうがないところだが、最低限2〜3日間のモデリング研修を受けておく事をお薦めしたい。たとえエンドユーザでも、基礎的なノーテーションを学べば、業務知識に長けているので話にはついて行けるハズだ。モデリングは専門家のものと決めつけてはいけない。そして応用形は実践で学べばよい。
どうであろうか。時にはいつものやり方を変えてみることが、イノベーションのきっかけになるのではなかろうか。現代のITでは変われないことはリスクである。企業システムは未だコモディティには程遠いにもかかわらず、表面的な開発生産性向上を狙って過度な分業を図る事は、かえって品質の劣化を招いていないだろうか。今再び、共同作業のメリットを見直してみることも必要かも知れない。