朝食はオニオンスライス

今日は昨日の題材を使ってオニオンスライス・パターンを考えてみたいと思います。
オニオンスライスは後ほど説明するとして、目指すのはモックアップの作成です。
こんなことを想定してみます。

・明日までに任意の日に食べた朝食の内容を画面に表示するようなプレゼンが見たい。
・ただし、データベースがまだ構築されていない。
・しかしながらサンプル画面を作るのではなく、そのまま本番に流用できる精度が欲しい。
・なぜなら時間がないし、手戻りを生み出したくないから。

本当に勝手なものです。
この程度のことであれば、サクッと画面を作ってボタンか何かを押したタイミングで画面に情報が表示されるような「サンプル画面」の実装を作ってしまえるでしょう。
そこを、ほぼ同じような手軽さで、ある程度の構造を持ち、すぐに本番に流用できるようなメカニズムを考えてみましょう。
パラメータやデータベースのアクセスレイヤーは、今回の本質ではないので割愛します。
それでは、思い出す意味で、ボタンを押して画面に展開するデータは昨日提示したオブジェクトを使用します。

<朝食>
     <食べたものリスト>
          <食べたもの>トースト</食べたもの>
          <食べたもの>ハムエッグ</食べたもの>
          <食べたもの>ひよこ豆とレタスとトマトのサラダ</食べたもの>
     </食べたものリスト>
     <飲み物>コーヒー</飲み物>
</朝食>

こんな感じです。
このオブジェクトは本番用に使うとしてモックアップのデータオブジェクトのクラスを考えます。

class 朝食モックアップ extends 朝食 { … }
こんな感じです。
ついでに、朝食クラスはこんな風に定義します。

class 朝食 implements I朝食

モックアップは、本番用の朝食クラスを継承して同じ構成の朝食モックアップを定義します。
当然ながらコンストラクタはこのようになります。

public 朝食モックアップ() { super() }
つまり、実態は本番と同じということになります。
これを返却用のオブジェクトとして使用することにします。

次にビヘイビア（ふるまい）を表す検索用オブジェクトを考えてみます。
まず、本番用はこのようになります。

class ある朝に食べた朝食()  implements I食事 { … }

そして、こんな検索メソッドを持ちます。

public virtual I朝食 Find() { return 本来はデータベースから取り出すのだ！ }

次にモックアップ用のビヘイビアを定義します。

class ある朝に食べた朝食モックアップ() extends ある朝に食べた朝食() { … }

本番用のビヘイビアを継承するわけです。
したがって、検索メソッドはオーバーライドされ、朝食を表すモックアップエンティティを返すように定義します。

public overrides I朝食 Find() {
     return new 朝食モックアップ()
}

この部分で、つまり、朝食モックアップのコンストラクタの中で、画面にプレゼン用として表示すべきデータを与えて初期化します。
ここまでで本番用とモックアップ用の2種類の検索メカニズムを定義しました。
2種類とはいえ、構造的にはまったく同様のことを表現しています。
これを比喩的なメタファーとして、オニオンスライスと言います。
または、ちょうど鏡を挟んで線対称として捉えることができることから、ヘキサゴナル・アーキテクチャと呼ばれたりもします。
本質は、モックアップは本番の鏡影として表します。

さて、最終段階として画面に結果として表示するコンテキスト（文脈）の部分を定義します。

class I朝食 朝食Repository(I食事 behavior) { … }

このコンテキストはこんな風に使います。
まずは、モックアップを使う場合。

var context = new 朝食Repository( new ある朝に食べた朝食モックアップ() );
var 結果 = context.Find();

これで、モックアップの朝食を表すエンティティが返されるので、それを使って画面に描きます。これで明日のプレゼンは乗り切ることができますね。
本番に切り替えるときは、以下のようになります。

var context = new 朝食Repository( new ある朝に食べた朝食() );
var 結果 = context.Find();

パラメータとして渡すビヘイビアを変更するだけです。
画面の中も変更する必要もないし、ビジネスロジックも変更する必要はありません。
そもそも本番とモックアップを分岐させる If DEBUG のようなロジックさえ存在しません。
コンテキスト、ビヘイビア、エンティティの構造に置き換えられてしまったのです。
このように大局的な視点でロジックを構造に置き換える作業は、データベースシステムだけではなく、制御などの分野でも有効です。
ぜひ、試してみてください。

朝食は頭の体操

いきなりですが、あなたの今朝の朝食を教えてください。

冒頭から不躾な質問で申し訳ありませんが、これをオブジェクトとして表してみましょう。
参考までに自身の今朝の朝食はこんなふうに表現してみます。

<朝食>
     <食べたものリスト>
          <食べたもの>トースト</食べたもの>
          <食べたもの>ハムエッグ</食べたもの>
          <食べたもの>ひよこ豆とレタスとトマトのサラダ</食べたもの>
     </食べたものリスト>
     <飲み物>コーヒー</飲み物>
</朝食>

簡単ですね。
当然ながら、個々のセンスや捉え方によって表現はいろいろあると思います。
もちろん、それでよいわけです。
ここで示した表現は、食べたもの　という視点を集合で捉えて、すなわち、コレクションとして表してします。あえて何か特記するならそれだけです。

では、今度は、これをクラスに置き換えてみます。

class 朝食 { … }
これだけです。最小の構成です。

少し工夫を加えて汎用的にしてみます。

class 朝食 extends 食事 { … }

superクラスはこんな風に表してみます。

class 食事 implements I食事 { … }

こうすることによって昼食と夕食を表すことができますね。
もちろん、人によっては、上に提示した概念モデルに <時刻></時刻> のようなタイムスタンプを付与したり、<いつ></いつ> のような更なるオブジェクトの汎用表現を加えるかもしれません。もちろん、それもOKです。

今度は、もう少し視点を拡げてコンテキストを表現します。つまり、ふるまいの部分を与えます。たとえば、食べる、摂取する、という行為を概念モデルとして考えます。
こんな感じはどうでしょう？

class 食べるコンテキスト { … }

上記のクラスのコンストラクタで、さきほどの朝食クラスを生成してインジェクトします。

食べるコンテキスト c = new 食べるコンテキスト( new 朝食() );
c.Execute();

これにより、コンテキストに食事インタフェースの規約を実装したクラスを与えることにより、表現が汎用的になりました。

言ってみれば、これは頭の体操です。
いろいろなものをモデルに置き換えてみましょう。

毎朝の通勤ルート
今週末に観に行く予定の映画
今夏の長期的気象予想
などなど…

なんでもよいです。
ほんの少しの時間が出来たときにでも、頭の体操をしつつ柔軟な思考を持つべく練習をしましょう。

ポートフォリオマネージメント

システムやソフトウェアを作成するにあたり、最初にやるべきこととして要求の聞き取りがあると思います。お客様が目指したまだ形のないモノを作成するにあたり、この作業の実施はとても重要な期間でもあります。
この要求は、具体性と実現性を検証されて、やがて要件定義へと結実します。
この過程で私たちはいったいどんなことに注意をはらうでしょうか？
お客様の声に耳を傾け最大限聞き漏らすまいと努力をするでしょうか？
あるいは、なんとか抜けのない資料を作成するべく力を注ぐでしょうか？

どれも重要なことではありますが、固執すべきではありません。
ここで注意しなければならないのは形式ではなく「何か」を掬い上げるのにどのような仕事が効果を上げるのか？　というざまざまな改善ポイントが隠されていることを積極的に察知することだと思います。

果たして、ビジネスがどこに向かおうとしているのか？

これは極めて重要な命題です。もちろん、これはプロダクト・オーナーの目的であるわけですが、私たちモノ作りに従事する立場からも大きな関心ごとであるはずです。なぜなら 「見通し」 が重要だからです。見通しとは、つまり、計画であり、もっと正確に言うならばライフサイクルを大きく決定づける動機でもあります。
これらの材料から、私たちは優先順位の提案をし、開発を段階的に進めていくことに一定の価値を見つけることが出来るかもしれません。
これは、きっと方向性のミクロな視点なのだと思います。

では、もっと大きな視点で、パースペクティブを示すことができる点があるとすれば
それは、きっと 何を作るか？　ではく、何を解決するのか？　もっと言ってしまえばどんな悩みを解決するのか？　という観点に行き着くのだろうと思います。

エクセルの概念モデル

X軸とY軸の表現の集積は、誰にも直観的でわかりやすいものだと思います。
たまに、表現の枠組みを打開すべくセルを連結して、ひとつ下の階層を表してやることは誰にでも経験があることだろうと思います。
これは、つまり表の限界です。当然ながら表は二次元配列が基本なので、それよりも下の階層や、あるいは「Z軸」の要素を表そうと思えば、これは最早、表の限界を超えることになるでしょう。
しかし、我々エンジニアはエクセルを単なる表として捉えるのは少々乱暴すぎると思います。
もう少し本質に迫る必要がありそうに思えます。
では、表を分解して行の視点で捉えるとします。すると、行は1行のコレクションを表すことになります。

List<Row>
こんな感じです。

次に、行が保持する要素は？　というと…

同じように List<Column> という表現になると思います。
これでセルの集合を表すことができました。

セルまで行き着いたところで、このセルがどのようにして表になり得るのか？　を表します。

<Rows>
     <Row>
          <Columns>
               <Column>セルに格納するデータ</Column>
          </Columns>
     </Row>
</Rows>

ここまで到達すればオブジェクトに簡単にマッピングできますね。
つまり、これはノードとエレメント、親と子の関係でもあるわけです。
ここで思慮深く観察したいのは、あくまでも二次元配列のベクトルで捉えるのではなく、入れ子のイテレーションです。こうすることにより、より抽象度が高まることが実感できると思います。
良いデータ表現というのは、ノードの再帰的表現に他ならないのです。
もし、データの関連をオブジェクトで表そうと思えば、ルートノードは必ずひとつになるはずです。もし、そうならなかったならスコープを逸脱した設計になることがすぐにわかると思います。と、同時に人が頭脳で捉えられる臨界点を超えてしまうことにもなるでしょう。

テストエンジニア

残念なことに、我が国においてはテスト実施に従事する人は総じて地位が低く、エンジニアとして認識されない風潮さえ存在します。本来テストエンジニアとして高い能力を発揮する局面で、向上心や知識といった何ものにも代えがたい価値が削がれてしまっているのが現実だと言えます。
視点を変えて組織という単位で見てみると、こちらも同じような現象が起きていると言えます。評価や品質を考察するしくみが整備されていないために、必要な技術や経験知が整理されずに場当たり的に処理されているのが、また同じような現実だと言えます。
これらは、品質保証という観点から非常にかけ離れた遠い世界です。

ただ、この状況はあくまで私たちの所属する分野という世界での極端な例かもしれません。
では、産業という観点まで視座を拡げてみましょう。家電業界、自動車、重工業、交通、医療といった分野は、品質評価や信頼性評価、耐久試験などの知見がきちんと整備されています。おそらく、当たり前ではないかという感想が聞こえてくると思いますが、こと、ITの分野となるとやはりこの界隈での弱さを感じてしまう印象がぬぐえません。
これは、いったいどうしたことでしょうか？

ひとつには、私たちの分野はまだ歴史が浅いため、信頼性という高みにまでまだ熟成していないのかもしれません。
モノづくりは完成をもって完了というわけにはいきません。もっと言ってしまえば、世の中に出始めて、そこがスタート地点となるわけです。初期不良や使い勝手などが改善され、製品が熟成されていきます。
ここに重要なポイントが隠されています。
製品が熟成されるということは、つまり、生産ラインが改善され、作業手順が改善されます。常に振り返りながら、生産品質や作業品質を見直すのです。こうした地道な努力が安定した品質の製品を世の中に送り出す原動力となるのです。

ふたつめに文化の熟成があげられます。
見える化やQC、あるいはルールの強化、そして 作業者の自主的な改善活動。これらはすべて文化という地平に存在する事象だと思います。

こういった技術の裏側の部分（とは言え、これらもまぎれもない技術である）に目を向けてみるのも興味深いことだと思います。

問題意識とイノベーション

問題を解決するより、問題を察知するほうが遥かに難しい。
とはよく言われる言葉だが、
もっと正確に言ってしまえば、「問題を解決するより、問題を察知するほうが高い能力が必要だ。」と表すこともできると思う。
しかしながら、人は問題を察知する能力を潜在的に持っているようにも思う。このことをいかに表面に導出してやるか、あるいは、顕在化するように促すか？　というのは個々やチームの特性に左右される部分が大きいようにも思う。

我が国は儒学の文化がしっかりと根付いているので、それはそれで素晴らしいことではあるけれど、上に示したナイーブな類の取り扱いがことさらに難しい。
人は誰でもいやな話は聞きたくないし、いやなことが起こりうることさえ目を背けてしまいがちだ。
もっと悪いことに、このような問題の発露は人間関係にも影響を及ぼす。

問題意識という言葉がある。
簡単な言葉だ。しかし、常にこのことを意識しながら仕事に取り組むには、かなりの集中力が必要だ。と同時に強い信念が必要だ。

少し視点を移動してみる。
イノベーションと言えば、誰でも耳を傾ける気にもなるし、画期的なことのようにも思えてくる。しかしこれは錯覚ではない。おろらくは正しい認識なのだと思う。
では、再び問題意識という言葉を持ち出してみる。とたんに気持ちが沈み重々しい雰囲気になってくるだろう。そして、これもおそらくは正しい認識なのだろう。
さて、両者を比較してみると実は目指している方向には大差がないことが見えてこないだろうか？
気持ちの持ちようなのだろうか？

自身はそれほど単純なものではないと考えている。

プロジェクトが死ぬとき

「とりあえず…」
この言葉が使われたときは、注意信号である。
とりあえず、仮の実装でもしておけばよいとでも言うのだろうか？
明確な方針が存在しないときに、この表現が使用される頻度が高くなる。マネージャクラスがこのような言い回しを多用する場合、十中八九、全体を把握するのが困難な状況に陥っている証拠である。それならまだしも、口癖にまで「昇華」している場合があるので、そうなったら改善するのは非常に困難だ。注意されたし。

ルールが明確でない。
ドキュメントの体裁から、保管場所、変更管理、エビデンス。
これらはビジネスの問題だ。軽く考えてはいけない。
にわか体質のチームは、まずこの問題を克服しなければ何も始まらないと考えてもよい。
わかればよいと言う人が少なからず存在するが、課題に直面しているであろう刹那だからわかることであり、半年後、一年後、あるいはまだ見ぬ人々がメンテナンスにあたることを想像したときに、今と同じように理解し得るだろうか？

誰が何をしているのかわからない。
誰が何を担当しているか？を把握していればよいのは管理者だけの「特権」ではない。
コードの競合は事前に察知したいと誰でも考えるし、実際に手がけた人に確認したいこともあるだろう。進捗管理と言いながらも言い値で見積もったグラフを描いているだけで、実際の状況を何ら反映していない不正確な代物だ。

コミュニケーション不足
ここまで来ると最早末期的症状を呈し始める。あちらこちらに問題が山積し、深く結びつき、絡みついた糸をほぐすのは困難だ。まして、実際に手を動かすメンバーが口を閉ざし始めると、どこにどんな問題があるのかさえ見えなくなる。
かなりの高確率で休日がつぶされるようになる段階だろう。

逆の見方をすれば、これらの事柄は貴重な経験になる。
経験した人でしかわからない重要な問題の息吹と戦いの歴史だ。
それにめげずに改善を続けよう。