Category: Uncategorized

開発の現場で、「手法」を議論する機会が減ってきているように思う。もちろん、自分の身の回りのことが全てではないので、偶然かもしれないが、ブログ等での話題でも、あまり見られなくなっている気がする。以前だと、例えばMVCがどうとか言った話題が華やかだった記憶がある。そして、古くからのさまざまな手法のどれがいいのかと言った話題や、特定の手法をどのように理解すればいいのかといったことが議論された。サイエンス的に考えれば、原理原則があり、それに則った手法は、成功する確率が高くなるということから、以前は手法やアーキテクチャ中心的な考え方もあっただろうし、もちろん、今もそれはなくなってはいない。

現実はどうだろうか？ 色々な手法や原理原則は、１人１人がしっかり学習して現場適用するということも必要なことかもしれないが、「良い手法」はそのものが、すっかりパッケージ化されている。ソフトウェア開発で言えば、フレームワークやライブラリ、あるいは開発ツールで、そうした過去の蓄積が完全にパッケージされており、手法を深く理解しなくても開発を進める上ではあまり問題はない。ともかく、ある「やり方」を採用すれば、難しい原理原則はもちろん、手法の適用までができてしまうのである。Webのサーバーサイドフレームワークは典型的な例だろう。ほとんどのフレームワークはMVC（正確にはJavaEEでのMVC2パターン）であり、よほど変なことしない限りはMVCに基づく役割分担が自然に作り込まれるし、レイヤー化についても気がついたらそうなっているのが一般的だ。もちろん、実装の良し悪しはあるとしても、現場で働く側としては「○○フレームワークでよろしく」の一言で済んでしまう。

そうなると、現場でもっとも注目されるのは何だろうか？ システム開発の現場と、サービスアプリケーションでは色々違うとしても、結果的に、「問題点は何か」ということに注目することが常に行われているのではないだろうか。開発の枠組みは使用フレームワークをはじめとして、結果的に決まってしまうことが多い。要求工学では手段は後から決めるというのが基本ではあるが、現実にはそうでもない。そして、そこではどんな手法を採用するかも概ね決まっている。スタッフが持つ経験をベースに、進行の可能性を検討し、誰かが問題なく進められる部分は、特にフォーカスされない結果となる。一方、誰も作ったことがない仕組み、誰も経験したことがフレームワーク、ある領域で実現できそうにない非機能要求など、「できるかどうか分からない」所に開発タスクとしては目を向けることになる。

では、できないことを、原理原則からボトムアップして、手法を求めるかと言うと、そう言う側面が問題解決に集中しているときはあるかもしれないが、その結果、あるライブラリを使うことで十分に解決されるなら、「ライブラリを使います」と言うことで集約され、問題がさらに絞られる。「チーム全員で手法をまずは勉強します」という結果はかなりハードルが高い。結果的に、問題から始めて、パッケージ化された解決手段で概ね解決し、さらに違う問題にたどり着き、それを繰り返す。問題がほぼなくなれば、一定時間後に完成に進めるということだ。

問題点の解決が現場での主要な話題になり、系統的な手法が議論される素地はほぼない。もちろん、結局のところアジャイルということなのかもしれないが、小さなプロセスでも、大きなプロセスでも同様に言えることではないだろうか。良い悪いはあるとしても、そのように進んでいる。その中で、基本や原理を叫んでも、誰も耳を傾けない。問題を解決する糸口は、まさに原理原則に立ち返ることで手にできるとも言えるのだが、「良い素材はないだろうか」が糸口になってしまうのである。

普段は小規模な開発に関わる機会が多いので、仕様書が渡されないような発注は普通にある。もちろん、大きな会社の発注では仕様書があるものの、非常に高い割合で「仕様書書いている」と言う証拠のためだけの紙の塊でしかないようなことも感じる。設計に役に立たないわけではないが、中身が実装作業に遠いのである。わかり切ったことは簡単に書き、問題点を記述して共有すれば、仕様書はより役に立つのではないだろうか？ サイエンスなので、原理原則があって、それを踏まえた手法があるのは間違い無いのだが、いっそうのこと現実に合わせて「問題解決」にフォーカスした手法に目を向けるべきだと考える。とはいえ、そう言う「手法」を作っても意味はない。手法を否定する手法というのは存在に無理がある。その意味では、アジャイル宣言のように、どんなマインドで対峙すべきなのかをうまく表現しないといけないだろう。ということで、表題のように「手法よりも問題解決」と言ってみた次第だ。今やそういうやり方が一般的というスタンスで、メリットと注意点を検討すべきではないだろうか。

気がついたら全然記事を書いていませんでした。最後に書いたのは昨年の5月、ちょうどFileMaker 16がリリースされたのですが、新機能であるREAST APIのためのクラスを作るなど、そこそこコミットしたので、いくつか記事はありましたが、すっかりご無沙汰になりました。仕事を一生懸命していたのと、INTER-Mediatorの開発をがっつりやっていたのが理由です。

開発プロセスの話も、2017年2月で以降に記載がありません。かなり詳細化したのですが、詳細化し過ぎかもしれません。INTER-Mediatorでアプリケーションを作る話に持ち込みたかったのですが、むしろフレームワークを作る上での分析の方向に行ってしまった感があります。とは言え、報告はしませんでいたが、色々な角度での検討は断続的に続けていました。古い書籍ですが Object Modeling and User Interface Design あたりで、オブジェクト指向的にユーザーインタフェースを設計する方法があり、モデリングの方法として参考になるものでした。加えて、データベースをどう設計するかということも問題点としてはあるわけですが、こちらもオブジェクト指向の世界での解決策は2000年前後に一定の成果を出しており、久しぶりにそのあたりの書籍を調べて、10月にINTER-Mediatorの勉強会でワークショップをやってみたりしました。さらに、最近はプロジェクトマネジメントの世界でも注目されてきたアジャイルということもあり、現在の開発における問題点を解決に向かわせる手法として注目されており、そうしたことを全てひっくるめての「開発手法」に行きつきたいということもあって、次の方針を模索中だったりします。

2017年度から、大学の非常勤の仕事を多めに入れたのですが、初年度はやっぱり教材の仕込みが大変でした。NIIの仕事が2017年から週に3日になったので、開発の仕事は大きなことができなくなることが予想されたので、細切れな仕事が中心になりましたが、それでも、断続的には開発の仕事も続けました。ということで、余裕のない忙しさがずっと続いていたので、研究を進めるのがかなり困難でした。もっとも、研究員としてNIIで雇用されているのですが、実際の仕事はトップエスイーのシステムや運営関連のことなのでNIIの業務時間内で研究をする時間は全くありません。今年、2018年は、もう少し余裕を持って色々なことに当たれるようになりたいなとは思っていますが、今年はまあそういう状況に持ち込めない感じです。とは言え、INTER-Mediatorの方は、最優先で進めているので、進行は色々あると思います。今年もよろしくお願いします。

INTER-Mediator Ver.5.4-devでは、クロステーブルの作成ができるようになっています。ここでのクロステーブルは、表があって、いちばん上の列と、いちばん左の列がラベルとなっており、そのラベルの交差するセルには、ラベルに関連するデータが表示されるというものです。例えば、いちばん上の列には自社の「支店」が並び、いちばん左の列には年月が並ぶとすると、その交差するセルには、特定の支店の特定の年月の売り上げが見えるというものです。サンプルファイルはSamples/Practice/crosstable.htmlおよびcrosstable.phpにあります。

まず、クロステーブルを作るには、3つの異なるコンテキストを定義します。1つは列見出し（以下のコードではitem）、1つは行見出し（以下のコードではcustomer）、そして交差するセルに設定されるデータのコンテキスト（同じくsalessummary）です。列見出し、行見出しのコンテキストについては通常と変わりありません。また、列か行かの区別も、定義ファイル内では設定しなくても構いません。行列の見出しのコンテキストでは、検索条件や並べ替えフィールドの指定などももちろん可能です。以下の例では、元のデータが多いこともあるので、意図的に絞り込んでいます。交差するセルのコンテキスト「salessummary」では、relationキーの指定を必ず2項目行います。1項目は列見出し、2項目目は行見出しとの関連付けになります。item、customerともに、主キーはidフィールドです。これに対応するsalessumarryコンテキストのフィールドはitem_idとcustomer_idです。すなわち、列見出し、行見出しの対応するレコードとのリレーションシップを利用して、交差するデータの配置を決めています。

 array(
   'name' => 'item',
   'table' => 'dummy',
   'view' => 'item_master',
   'records' => 100000,
   'maxrecords' => 100000,
   'key' => 'id',
   'query' => array(
     array('field' => 'id', 'value' => 25, 'operator' => '>='),
     array('field' => 'id', 'value' => 35, 'operator' => '<='),
 ),
 'sort' => array(array('field' => 'id', 'direction' => 'asc')),
 ),
 array(
   'name' => 'customer',
   'table' => 'dummy',
   'view' => 'customer',
   'records' => 100000,
   'maxrecords' => 100000,
   'key' => 'id',
   'query' => array(
     array('field' => 'id', 'value' => 250, 'operator' => '>='),
     array('field' => 'id', 'value' => 259, 'operator' => '<='),
   ),
   'sort' => array(array('field' => 'id', 'direction' => 'asc')),
 ),
 array(
   'name' => 'salessummary',
   'table' => 'dummy',
   'view' => 'saleslog',
   'records' => 100000,
   'key' => 'id',
   'relation' => array(
     array('foreign-key' => 'item_id', 'join-field' => 'id', 'operator' => '=',),
     array('foreign-key' => 'customer_id', 'join-field' => 'id', 'operator' => '=',),
   ),
 ),

ページファイルのクロステーブルの部分は、2セルずつの2行の表として作ります。それよりも多い場合や少ない場合はダメで、要するに2行2列のテーブルを必ず用意します。そして、エンクロージャーになるtbodyタグのdata-im-control属性を「cross-table」とします。これら4つのセルと2つの行は取り除かれ、初期状態として、TRタグに左上のセルを入れた状態にします。この左上のセル内部は、ページファイル側での定義通りにレイアウトされます。

 <table>
 <tbody data-im-control="cross-table">
 <tr>
   <th></th>
   <th>
     <div data-im="item@id"></div>
     <div data-im="item@name"></div>
   </th>
 </tr>
 <tr>
   <th>
     <div data-im="customer@id"></div>
     <div data-im="customer@name"></div>
   </th>
   <td>
     <div data-im="salessummary@qty"></div>
     <div data-im="salessummary@total"></div>
   </td>
 </tr>
 </tbody>
 </table>

続いて、1行目のTRタグをエンクロージャーに、そしてページファイルにあった右上のセルをリピーターとして、ページ合成を行います。つまり、このBのセルには、列見出しになるコンテキストの名前と、データベースから得られるフィールド名をdata-im属性として持つターゲットノードを記述しておきます。その結果、データベースアクセスが発生し、この場合はitemテーブルから一部のレコードを取り出して、それらを列見出しとして並べます。

さらに行見出しの処理になります。今度は、TBODYタグをエンクロージャー、そしてTRタグにページファイルの左下のセルを入れたものをリピーターとして、ページ合成を行います。つまり、行見出しだけをまずは作成します。

ここまでは、エンクロージャーとリピーターの違いはありますが、通常のページ合成と同じです。クロステーブルでは、ここで、次の図のように、交差する部分のセルに、一旦、ページファイルのテーブルの右下のセルを全て並べます。そして、コンテキストに応じたデータベースアクセスを行い、交差する部分に入るデータがあれば、対応するセルに値を設定します。列見出しあるいは行見出しに登場しないレコードと対応するものは無視されます。

サンプルの出力結果は以下のようなものです。2つのセルにしかデータは入っていません。なお、ここでの交差するセルに対応したコンテキスト内に、同一のセルに対応するものが複数ある場合には、中途半端にマージされます。コンテキスト内は、例えばSQLのビュー等を使うなどして、1つのセルに対応するレコードは0ないしは1個になるようにしてください。

追加情報：社本さん、ありがとうございます。解決できました。ヘッダに「<meta http-equiv=’X-UA-Compatible’ content=’IE=Edge,chrome=1’/>」というタグを入れれば、Webビューア上でもflexの機能が動き出します。ということは、MS EdgeはこのmetaタグなくてもEdge動作をするのだけど、FileMakerはmetaタグがないとIE9互換動作をするという罠ってことですね。（以下の原稿公開後にこのパラグラフを追加しました）

最近、CSSのflexを理解したので、FileMakerのWebビューアでも使おうとしたら、思いがけない落とし穴がありました。Macは問題なくレイアウトされますが、Windows 10 + FileMaker 14.0.4では次の図のように、flexが機能しません。「ある記事」と「塚口…」の部分は、それぞれDIVタグ要素になっており、その2つのDIVをさらにまとめたDIVがあって、そこにdisplay: flexを記述してあります。上半分は、FileMaker 14のWebビューア、下半分はMicrosoft Edgeでの表示結果です。同じソースなのですが、このように、Edgeでは正しくflexの動作をしてDIV要素を横方向に並べますが、Webビューアでは、flex動作をしないで、単にDIVとして表示します。

FileMakerのWebビューアコンポーネントは、Internet Explorerのものと言われていますが、もしかして、FlexboxはVer.10から対応なので、Ver.9相当のコードで構築されたコンポーネントが入っているということでしょうか？何れにしても、IE/Edgeのバージョンとは連動しないということかと思われます。

HTMLのソースは、IEの画面のURLから取得できるはずですが、貼り付けておきます。

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<style>
.titlearea{font-size: 12pt; display: flex; display: -ms-flexbox;align-items: baseline; margin: 3px 0 3px 0;}
.title{font-weight: bold; flex: 10 0 auto;-ms-flex: 10;}
.credit{font-size: 10pt; flex: 1 1 auto;-ms-flex: 1;}
.content{font-size: 10pt; border-bottom: 1px dotted black;}
BODY{border: none;}
DIV{font-family: Arial, Roboto, “Droid Sans”, “游ゴシック”, YuGothic, “ヒラギノ角ゴ ProN W3”, “Hiragino Kaku Gothic ProN”, “メイリオ”, Meiryo, sans-serif;}
</style>
</head>
<body>
  <div class='titlearea'>
    <div class='title'>ある記事</div>
    <div class='credit'>塚口 三春[2015/12/15]</div>
  </div>
  <div class='content'>いいことばかりです。いいことばかりです。…いいことばかりです。いいことばかりです。いいことばかりです。いいことばかりです。いいことばかりです。</div>
</div></body></html>