データベースの生成とリレーションシップ1.3（後編）

土曜の夜である。そして書き手は日本が誇る世界の世界遺産こと小林である。
なぜなのかは分からないが、休日にこの小林は労働にいそしんでいる。
恋人は参考書ならぬ、彼女は仕事といったところか。

見てください上司のM氏。この小林のキラキラとした光り輝く汗を。
ここですよ、ここ。ほら、こんなに汗をしたたらせてまで小林は労働しているんですよ。
こんなに頑張っています。

・・・さて、アホはこのくらいにして、土曜の夜、特にすることもないのでトレーニングの続きでもしようではないか、諸君！

 前回までのトレーニングによって在庫と陳列商品のデータベースをリレーションシップ（連結）させることができた。

といってもOutSystemsの場合はほぼ自動でやってくれるため、開発者側としてやるべきことはどのように設計するのかという設計の業務がメインである。

次は商品購入時の重複を防ぐためにindexを設計する。トレーニング動画においてはこう！

日本語訳：お客様が同じ商品を複数回注文しようとすると

エラーを表示させ購入できないようにします。という意味です。

そのためにインデックスが必要になる、と

これは例えば銅の剣を3つ買う時に

　・銅の剣×1

　・銅の剣×1

　・銅の剣×1

という重複を防ぎ

　・銅の剣×3

と表示させるための機能です。
というか、これ最初っから実装しておけばいいのにと思う小林なのであった。

続けます

”インデックス名をアンクエプロダクトインオーダーと名付ける。”

なんか、ポリネシア語みたいですが、あんまり理解しなくていいと思います。
私も理解できてなくて、あ、いつものことねうふふっ！
みたいなノリで先へと進めています。不親切ですが、なんか日本市場なんてどうでもいいわ！みたいなノリが伝わってくるだけであって、別に私としてはどちらでもいいと思っています。

 “ユニクエパラメーターをトルゥーにセットします。”

たぶん、重複を防ぐための設定を行っているのだと思います。

全部英語なので、私もよく分かっていません。

で、indexが終わったため、速攻でデータベースの構築に入ります。

（ドラッグアンドドロップ1つでデータベースを構築している小林の開発画面）

はい。マッハでデータベースが出来上がりました。

デフォルトでOrderItem（注文商品）データベースとProduct（製品）データベースがリレーションシップ（連結）されているのが分かります。

非常に高度なのですが、たくさん作ってたら慣れました。

ここもトレーニング動画と同じ操作をしているのに、同じような設計にはなりませんでした。
ただ、前回もそうだったため自分で独学でいじってたらなんとかなりました。

通常、こういうところが挫折を招くのだと思います。
動画と同じ操作をしているのに、同じ画面にならない。すると、諦めてしまう人が出てきます。でも、私は諦める側の人間が悪いとは思いません。

なぜなら、トレーニング動画と同じ操作をしているのに同じ処理がなされないのはソフトが頻繁にバージョンアップされていることが問題であり、初心者エンジニア側が犯したミスではないためです。

初心者エンジニアはここで怒り狂い、ストレスを溜めることになるでしょう。
諦めるのは多少もったいないですが、同じことやっているのに画面と同じにならないのはトレーニング動画側に問題があるためで、面倒ならさっさと諦めるのも一つの手だと思っています。

これがUI（ユーザーインターフェース）とUX（ユーザーエクスペリエンス）の違いです。
どれほど素晴らしいUI（ボタン配置やデザイン、開発スピード）があろうとも、UX（使用体験上の挫折や辛い思い、お客様を喜ばせないトレーニング動画）があったのでは顧客満足度は高まりません。

つまり、包括的には意味がないということです。

ユーザーインターフェース（UI）とユーザーエクスペリエンス（UX）で
重要なのはユーザーエクスペリエンスのほうです。

そして、ソフトが使いやすいのに、トレーニング動画が分からなくて挫折してしまうということは、ソフトのユーザーインターフェースが使いやすくても、トレーニング動画というサービスが拙いため、嫌な思いという経験をしてしまう。
よって、結果的には企業側に損失が発生しているのであって、問題は企業側にあるということです。

なので、ガンガン動画を批判し、改善してもらい、お客様のUX（使用体験）を高めることが肝要だというのが私の自論です。つまるところ、顧客満足度は開発基盤（IDE）の性能や価格設定だけではなく、それら全体を通じてのUX（使用体験、この場合、ポルトガルのOutSystems社に関わったことで得られる体験のすべて）が重要なのです。

つまるところ、製品及びサービスを開発しているITエンジニアだけの問題ではないということですね。

さ、次へ行きます。次は検索バーの設置です。

 検索のコードはこれなのですが、意味がよく分かりませんでした。
でも何十本もアプリを作っていればだんだんわかってくると思います。そもそも検索バーの作成自体が初ですので、そういうものなんだー！
って感じで、突っ走ります。

次、TableRecords（表の挿入）で空の入れ物を作る

空の表に値を入れて画面設計を一気に完了させる

まさに神速！
こうして初心者エンジニアはまたしても業務アプリケーションをものの数分で開発してしまうのであった。

一応書いておくと私がすごいのではなく、開発基盤がすごいのであって、そのすごい開発基盤の操作をいま一生懸命に覚えているというのが正確な表現です。

 で、完成品

＜アプリを作り終えた感想＞
なんかあんまり感動がなかった。
前回みたいな喜びがないのです。その理由は、注文画面の商品欄は設計したものの商品が1つも存在しないことと、新規で商品を作成する機能がまだ付いてないためです。

後々、作っていくことになると思います。
このトレーニングはそんなに難しくなかったです。

（次のトレーニングに続く）