データ項目の整合性を取り易くす工夫

iPadにBluetoothのキーボードをつけてみたんです。ケースにiPadをはめ込んでパタンと閉じれるのに。やっぱり、キーボードの方がソフトウェアキーボードより打ちなれているから打つのが早いでしょ、と思ったし、ソフトウェアキーボードが画面の半分も占めてしまうのがもったいないなぁ、と。で、実際に打ち始めてみると戸惑ったんです。どうしてかというと、だってiPadだからキーボードもマックのキーレイアウトですよね。いままでWindowsばっかりだったので、もーちょー戸惑う。頭の中で「(えっとコピペはcommand＋C/Vかな」とかツィートしながらやっておりますがなかなか慣れなくて。まだ、1日2日程度ですから。そうそう、Windowsでいうescキーってmacだとどれにあたるんですか。

データ項目定義は上流工程で
システム作りでは、まだまだドキュメントを作ってシステムを開発するという流れを変える技術は出てきていないので、業務要件からシステム要件を抜き出してシステムに実装するまでに様々なドキュメントを作ります。
＃作っていますよね？

どうして様々なドキュメントを作っているかと言えば、要件からシステムとして実装するためのプログラムに翻訳することが直接にはできないからです。要件を直接プログラムに変換できるような手法が実現できればシステム開発の現場は革命が起きるでしょうね。だって、その要件からプラムに変換する間を多くのプロセスとアウトプット、特にドキュメントが生産されているから。そのプロセスとアウトプットを飛び越してプログラムになってしまったら中間層の仕事をしているエンジニアは不要になりますから。いろいろと波及も影響も大きいでしょう。

そんな環境は今の時点では実現されていないので旧来のプロセスとアウトプットを作ります。特にドキュメントは、依頼する側はたくさん作りたがります。一方、ドキュメントやプログラムを作る側はドキュメントを作りたがりません。必要だとは思っていても作りたがらないのは、なぜ必要なのか腹落ちしていないからだとは思うのですが、単純に面倒くさいからのままなら「代替案をだせよ」くらいは言いたいところです。

なんだかんだで作っているたくさんのドキュメントがあると、同じデータ項目があちらこちらに出てくることになります。そうすると何が起きるかというと、ドキュメントによってデータ項目の定義がばらついてしまったり、データの意味が微妙にちがったりしてくるんですね。

いや、そんなの上流で、要件定義でデータ項目定義をしてしまえば、それがリファレンスになるのでそんなことはなくなるんですが、なにせ、データ項目定義なんて肯定が進むと成長したり、意味がバージョンアップしたりしてしまいますから。

そうした時間とともに変遷してしまう、変化してしまう可能性のあるものを扱うときに、そうした減あkするものの管理方針は決めておいたほうがいいでしょう。たとえば、どの文書をリファレンスにするのか、問いことだけでも決めておくことは有効です。データ項目定義のような定義ものはドキュメントの本編に入れておくより、別紙で変化を取り入れやすくしておく方がそれを最新に維持しておく側としてはハンドリングがしやすいので実際に運用するときは一度検討したほうがよいでしょう。

あと、データ項目定義のリファレンスはできるだけ上流こう工程のドキュメントの位置づけがいいです。想像つくと思いますが、後工程のドキュメントだとその工程が終わるまでfixしないし、いつまでたってもメンテが終わりませんから。