Laravel10:Vueの親子コンポーネント

親子コンポーネントについて

見本ソースを参照している

親子間のデータ連携

子供のコンポーネント

<template>

  <p>{{ foo }}</p> <!-- hoge -->

</template>

<script>

export default {

  props: [

    'foo'

  ]

}

</script>

親コンポーネント

<template>

  <child-component v-bind:foo="var" />

</template>

<script>

export default {

  data() {

    return {

      var: "hoge"

    }

  }

}

</script>

props 経由で受け取った foo の中身はリテラルではななく、親で定義されたオブジェクトのため、foo の値として hoge が出力される。

v-bindはリアクティブのために親子間で連携していることを意味します
下記も同様です。

<child-component :foo="var" />

子コンポーネントから親のイベントを呼出

親のコンポーネント

<template>

  <div>

    ボタンA<child-component v-on:call-parent="parentFunc" foo="1" bar="A" />

    ボタンB<child-component v-on:call-parent="parentFunc" foo="2" bar="B" />

  </div>

</template>

<script>

export default {

  methods: {

    parentFunc(foo, bar) {

      console.log(foo)

      console.log(bar)

    }

  }

}

</script>

子供のコンポーネント

<template>

  <button v-on:click="childFunc(foo, bar)" type="button">Button</button>

</template>

<script>

export default {

  props: [

    'foo',

    'bar'

  ],

  methods: {

    childFunc(foo, bar) {

      this.$emit('call-parent', foo, bar)

    },

  },

}

</script>

子コンポーネントから親のメソッドを実行するためには、子から $emit でイベントを発火させるのがポイントです。

template から直接イベントを発生させることができないため、クリックイベントを一旦 子コンポーネントのメソッド ( ここでは childFunc ) で受け取り、そのメソッド内でイベントを処理します。

親子間でデータ量が増えた場合はVUEXを使うのが最善。

今、思案しているところでした・・・

蒸し暑い日が続く

毎日、蒸し暑い、それも高温多湿、寝ていると室温が23度、湿度が80%近く

窓を開けようとしても南風が強く、閉め切りになってしまう。

油断していると水回りでは黒カビが発生、要注意の時期、まだ5月の下旬になろうとしているのに、1か月ぐらい季節が早い。

高温多湿の影響なのだろうか、我が家の猫2匹、ブラッシングをすると、よく抜ける。
これほど抜けるのは初めて。毎日ブラッシングに大変です。
ブラッシングの後は猫は良く寝る。

外出をして帰宅すると、汗まみれ、べっとりしているのでシャワーを浴びると爽快な気分になる。よく汗をかくので、これからの時期、大変です。
タオル型のハンカチを2枚以上、持って出ています。

といって不要不急の外出はしておりません。
人の多いところには出かけないです。

先日、田村正和さんの死亡が報道された。1か月以上前に亡くなっていたとは・・・
色々なドラマなどで楽しませてもらいました。
ご冥福をお祈りいたします。

花の美術館で撮影した花の写真

ビジネス：電子契約について

昨年から新型コロナウィルスに伴う無印をうけて電子契約の状況を調査しました。

要は紙の契約書とネット上の契約書が同一の法律関係にならないといけないという意味があります。

法的にはややこしいことがあります。

1. 電子契約の証拠力

2020 年における新型コロナウィルス感染症拡大を受けて、内閣府規制改革会議を中心に押印廃止及び電子署名活用に関する議論が加速した。当初から、電子契約の成立の真正に関する推定効を定める電子署名及び認証業務に関する法律（以下「電子署名法」という。）第3 条の活用に関する議論がなされ、電子契約の証拠力を裏付ける施策が立て続けに公表された。

後述2．のとおり、法人間の契約実務において当該契約の有効性を確保する手段は様々あり、押印又は電子署名の利用はその一手段に過ぎない。しかし、これまでの契約書に押印をする契約実務については、いわゆる「二段の推定」に基づき、当該契約書の証拠力が明確であったため、特に法人間の重要な契約については契約当事者それぞれの代表印（登録印）を捺印する実務が定着してきた。

押印廃止を実現し契約電子化を実現するためには、電子契約の証拠力についても押印の場合と同等又は類似の証拠力が認められることが望ましい

(1) 電子契約に関する証拠力の重要性

ア. 証拠力とは

民事訴訟における文書の証拠力には、形式的証拠力と実質的証拠力の2 つの局面がある。

① 形式的証拠力とは、作成名義人（その文書の作成者とされている者）により作成されたものかどうかという問題である。その文書を事実認定の際に利用して良いか、という入口の問題といえる。

② 実質的証拠力とは、その文書が事実認定にどこまで役立つかの問題である。形式的証拠力の問題がクリアされた上で、その文書の証拠としての価値（たとえば、その文書と矛盾する証拠（文書や証言等）がある場合に、どちらを信用するか）の評価の問題といえる。

イ. 二段の推定とは

民事訴訟法第228 条第4 項は、形式的証拠力についてのみ定めていると考えられる。これを踏まえ、紙の契約書については、判例法理により以下の「二段の推定」が認められている。

① 当事者本人の印章によって顕出された印影があれば、本人による押印がなされたものと推定される（事実上の推定）

② 本人による押印があれば、文書の成立の真正が推定される（民事訴訟法第228 条第4 項に基づく推定）

ウ. 電子契約について

電子契約についても、形式的証拠力が認められなければ、そもそも民事訴訟の証拠として利用できない（実質的証拠力を検討するまでもない）。形式的証拠力が認められても、実質的証拠力が乏しければ、契約内容（当事者の合意内容）の立証ができない。

したがって、電子契約についても、形式的証拠力と実質的証拠力の両方を確保することが重要であり、入り口の問題である形式的証拠力について電子署名法第3 条の推定効が認められることが望ましい。

エ. 電子署名の形態について

現在利用されている電子署名の形態については様々なものがあり、各形態について法律上は厳密な定義はないが、一般的には以下のように類型化できる。

① 当事者型電子署名（ローカル型）：契約当事者自身の署名鍵により暗号化等を行う電子署名サービスのうち、電子署名の秘密鍵等をIC カードやユーザーのパソコン等で管理し、ユーザーの手元で電子署名を付す形式をいう。

② 当事者型電子署名（リモート型）：契約当事者自身の署名鍵により暗号化等を行う電子署名サービスのうち、電子署名の秘密鍵等を電子署名業者等のサーバー上で管理し、当該サーバー上で電子署名を付す形式をいう。

③ 事業者型又は立会人型電子署名（クラウド型）（以下単に「事業者型電子署名」という）：契約当事者の指示に基づき、電子署名業者の署名鍵により暗号化等を行う電子署名サービスであり、クラウドサービス上で電子署名の管理及び電子署名の付与を行う形式をいう。下記の2 条Q&A や3 条Q&A において議論の対象となっているものは、主にこの形態の電子署名である。

(2) 押印に関するQ&A

2020 年6 月19 日、法務省等は「押印に関するQ&A」2（以下「押印Q&A」という）を公表した。以下の2 点が重要なポイントと考えられる。

① 「押印」の効果（「二段の推定」により証明の負担が軽減される程度）が限定的であること。

② 文書の成立の真正を証明する手段について、多様な手段がありうること（例えば、契約締結前段階での本人確認情報、契約交渉過程における電子メール等のやりとり、契約締結における電子署名等の活用）。

この考え方は、後述2．の契約に関連する事象を総合的に証拠化することにより有効な契約の成立を立証することに備えるという考え方につながる。

(3) 電子署名法第2 条についてのQ＆A

電子署名法第2 条は「電子署名」の定義を定め、具体的には以下の二要件を充足する必要がある（電子署名法第２条第１項）。

(i) 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。

(ii) 当該情報について改変が行われていないかどうかを確認することができるものであること。

電子署名法第2 条が適用される電子署名（以下「2 条電子署名」という）の範囲は電子署名法第3 条が適用される電子署名（以下「3 条電子署名」という）の範囲よりも広いと解されてきたが、現在利用が広がっている事業者型電子署名に電子署名法第2 条が適用されるか否かは必ずしも明らかではなかった。

そこで、2020 年7 月17 日、法務省等が電子署名法第2 条に関するQ&A3（以下「2 条Q&A」という）を公表した。以下の2 点が重要なポイントと考えられる。

① 電子署名法第2 条第１項第１号の「当該措置を行った者」について、電子署名業者自身の署名鍵により暗号化を行うこと等により当該文書の成立の真正性及びその後の非かいざん性を担保するサービスでも、電子署名業者の意思が介在せずユーザーの意思のみに基づいて機械的に暗号化されることが担保されている場合には、ユーザーが「当該措置を行った者」に該当すると評価できる。

② 上記サービスにおいて、例えば、電子署名業者に対して電子文書の送信を行った利用者やその日時等の情報を付随情報として確認することができるものになっているなど、当該電子文書に付された当該情報を含めての全体を１つの措置と捉え直すことよって、電子文書について行われた当該措置が利用者の意思に基づいていることが明らかになる場合には，これらを全体として１つの措置と捉え直すことにより、「当該措置を行った者（＝当該利用者）の作成に係るものであることを示すためのものであること」という要件（電子署名法第２条第１項第１号）を満たすことになるものと考えられる。

これにより、いわゆる事業者型電子署名であっても、(i)電子署名業者自身の署名鍵により暗号化を行うこと等により文書の非改ざん性等が担保され、(ii)当該措置についてユーザーであるＢの意思のみに基づき、電子署名業者であるＡの意思が介在することなく当該措置が行われたものと認められる場合であれば、電子署名法第2 条の適用があることが明確化された。

この2 条Q&A の結果として、事業者型電子署名について、他の法令においても「電子署名」として認められることとなり、例えば商業登記申請の添付書類としての取締役会議事録等（印鑑登録証明書提出者以外の者が提出する書類）について、事業者型電子署名等のうち法務大臣が指定するもの（商業登記規則第102 条第5 項第2 号・第102 条第4 項第2 号）4の利用が認められる。

しかし、2 条Q&A のみでは電子署名を用いて作成された電子契約（電磁的記録）に関する成立の真正（形式的証拠力）に関する推定が認められることにはならないため、下記(4)の3 条Q&A の公表が待ち望まれていた。

(4) 電子署名法第3 条についてのQ＆A

ア. 概説

2020 年9 月4 日、法務省等は電子署名法第3 条についてのQ＆A5（以下「3 条Q&A」という）を公表した。3条Q&A の概要は以下のとおりである。

電子署名法第3 条は、第2 条で定義された電子署名のうち、「これを行うために必要な符号及び物件を適正に管理することにより、本人だけが行うことができるもの」に限り、当該電子署名を行った電磁的記録（電子契約）の成立の真正を推定すると定める。この「本人だけが」に関連して、電子署名法第2 条において定められる要件に加えて、「固有性の要件」が加重される。

「固有性の要件」とは、「暗号化等の措置を行うための符号について、他人が容易に同一のものを作成することができないとみとめられること」をいう。いわゆる事業者型電子署名については、以下の①及び②の双方について「固有性の要件」が充足される必要がある。

① 利用者と電子署名業者の間で行われるプロセス

② ①における利用者の行為を受けて電子署名事業者内部で行われるプロセス

最終的には、システムやサービス全体のセキュリティを評価して判断されるものであり、個別の事案における具体的な事情を踏まえた裁判所の判断に委ねられるが、一般論として、以下の事情があれば第3 条の適用が認められる。

(i) 利用者が二要素による認証を受けなければ措置を行うことができない仕組みが備わっている。
（その例として、予め登録された電子メールアドレス及びログインパスワードに加え、スマートフォンへのSMS 送信や手元にあるトークンの利用等当該メールアドレスの利用以外の手段により取得したワンタイムパスワードの入力を求めることが挙げられる。）

(ii) 電子署名業者が当該業者自身の署名鍵により暗号化等を行う措置について、暗号の強度や利用者毎の個別性を担保する仕組み（システム処理が当該利用者に紐づいて適切に行われること等）が確保されている。

イ. 本人確認について

3 条Q&A は、問１乃至問3 において上記ア．記載の「固有性の要件」について説明する一方、問4 においていわゆる「身元確認」の重要性について言及している。これに関連して、電子署名法第3 条の適用要件として、「本人確認」のレベルがどの程度求められるのかについて議論がある。

3 条Q&A において引用される2020 年4 月17 日付経済産業省公表の「オンラインサービスにおける身元確認手法の整理に関する検討報告書」7 5 頁によれば、「本人確認」は「身元確認」と「当人認証」に分類でき、それぞれ下記の意味を有するものとされている。

「身元確認」とは、「登録する氏名・住所・生年月日等が正しいことを証明又は確認すること」をいう。

「当人認証」とは、「顔や指紋などの生体、マイナンバーカードなどの所持又はパスワードなどの知識の3 要素のいずれかの照合で、その人が作業していることを示すこと」をいう。

このうち「当人認証」については、上記(i)記載の二要素認証（予め登録された電子メールアドレス及びログインパスワードに加え、ワンタイムパスワードの入力を求める等）により充足されるものと思われる。

電子署名法第3 条の適用要件として、この「当人認証」に加えて「身元確認」まで必要か否かについては見解が分かれるところである8が、3 条Q&A における問４では身元確認への言及があるものの、問１及び問２で解説されている「固有性の要件」としては「身元確認」について触れられていないため、3 条Q&A の立場としては、「身元確認」を電子署名法第3 条の適用要件とする見解を採用していないものと考えられる9。この点、2020 年11 月17 日に開催された内閣府規制改革推進会議第３回デジタルガバメント ワーキング・グループ10に提出された

「資料3－2－1 論点に対する回答（総務省・法務省・経済産業省提出資料）」11における「論点④に対する回答」において、「身元確認」が不要であることが確認された。

なお、近時のサイバーセキュリティの問題等を踏まえた今後の課題については、後述3．(1)参照。

(5) 電子契約の証拠力と二段の推定

以上の議論を踏まえると、事業者型電子署名が付された電子契約に対する二段の推定の適用関係については、下記のように整理できる。

これにより電子契約の形式的証拠力を肯定する方向性が見いだせるが、法人間契約については、形式的証拠力の問題以外にも注意すべき点があるので、以下の２.でこれを検討する。

2. 電子署名を用いて法人間契約を締結する場合の注意点

押印Q&A が示すとおり、押印又は電子署名の利用は当事者間の有効な契約の成立を示す一つの手段に過ぎないといえる。契約締結時における押印又は電子署名の締結行為のみならず、契約締結前の事情及び契約締結後の事情も含めて総合的に証拠化することで、契約の有効な成立に関する後日の紛争に備えるというアプローチが考えられる。

一方で、電子署名法第3 条の適用が認められたとしても法人そのものには適用がないため、法人を代表又は代理して電子署名を行う者の代表権又は代理権については別途確認する必要がある。

これらの視点を踏まえ、

例えば、X 社（自社）及びY 社（相手方）間の契約について電子署名を用いて締結することを前提に、その際の主な注意点について検討する。なお、以下はこれまで紙ベースの契約書に代表印による押印を要求してきたような契約類型への対応を念頭に置いており、
例えばこれまで認印による押印のみ（代表者からの委任状等の確認もなし）で対応してきたリスクの低い契約類型については、これまで同様の対応で問題ないと思われる。

ア. 契約締結前の注意点

まずは、X 社にとって最適な電子署名業者及び電子署名サービスを選定する必要がある。そのためには、X 社において過去に締結された契約書を類型化し、それらの契約書を当事者の代表印で締結していたか部長印等の認印で締結したかを洗い出し、当該リスク分析に即した電子署名サービスを選定する必要がある。その上で、X社の社内規程の見直し等、社内体制の整備が必要となる。

その上で、Y 社の電子署名対応の可否を確認し、可能であればX 社が選定した電子署名業者の電子署名サービスを利用可能かについて確認する必要がある。

X 社の管理の観点からは、相手方企業によって異なる電子署名業者を利用することは避けることが望ましい。そしてY 社について、具体的に誰の名義で電子署名アカウントを作成するかを決定する必要がある。例えば、Y 社の代表取締役名義、Y 社の代表印を押印する権限を有する者（法務部等の構成員、以下「代表印押印権限者」という）の名義、X 社とのやりとりの窓口となっている営業部署の構成員（以下「営業担当者」という）名義等が考えられる。この点は、他人名義の電子署名の代行が認められるか、にも関連するが、代表印を押印する場合のフローと類似するフローを確立することが望ましいといえる。Y 社の電子署名名義人が代表取締役以外（例えば代表印押印権限者又は営業担当者）の場合、それらの者の契

約締結権限等を商業登記電子署名や電子委任状等を活用することにより確認する必要がある。この点、代表印押印権限者又は営業担当者の身元確認をどこまで行うべきかは、今後の課題であろう（下記3．(1)参照）。

一般に、Y 社の然るべき権限者が契約条項をX 社と交渉した上で当該契約を締結した場合、後日においてY 社による契約締結を否定することは難しい。したがって、X 社としては、Y 社との契約交渉過程においてY 社の営業担当者のみならず代表印押印権限者や営業担当者の部署の責任者等を交えて交渉し、その交渉結果を電子メールや議事録等の方法で証拠化することが望ましい。

イ. 契約締結時の注意点

上記ア．により両当事者合意に至った電子契約について、Y 社内部の必要な手続が完了したことを確認した上で、当該契約に最適な電子署名を利用して電子契約を締結することになる。この点、当該契約が重要な契約であれば、電子契約において、Y 社の電子署名名義人の実在や権限、Y 社の必要な手続が全て完了したこと等についてY 社の表明保証を徴求し、かつこれらを証する書面を前提条件書類として提出させることが考えられる。

また、電子契約への移行の過渡期においては、上記表明保証等を含む基本契約書について両当事者の代表印を押印することにより締結しつつ、個別の契約を電子契約で締結する方法もありうる。

なお事業者型電子署名を利用する場合、契約当事者の指示を受け電子署名業者名義の電子署名を付すことになるので、契約締結時において、契約当事者から電子署名業者への署名指示がどのようになされ、当該署名指示がどのように証拠化されるかを確認する必要がある。

ウ. 契約締結後の注意点

完全な電子化を実現する観点からは、締結済み電子契約はデータのみで保存することが望ましい。

一方で、下記3．(1)のとおりサイバーセキュリティ対応の必要性等、データ特有の論点もあるため、電子署名業者と入念に打ち合わせの上で、締結済み電子契約を誰のサーバーでどのように保存することが貴社にとって最適かを事前に検証し、その方法のとおりに保存する必要がある。また、電子署名に関連する暗号化技術の陳腐化リスクに対応するため、電子署名後に新たなタイムスタンプを付与するいわゆる長期署名サービスにも対応していることが望ましい。

また、電子契約が両当事者によって締結された後、その締結済み契約の内容に異議なくY 社が契約上の義務（例えば、ポストサイニング・ポストクロージング事項、支払行為等）を履行したのであれば、その後においてY 社が当該契約の有効な成立を争うことは難しくなる。したがって、電子署名によって締結した契約をY 社の電子署名名義人のみならずその上司を含めて広く共有した上で、Y 社により契約履行行為を証拠化することも有用である。

3. 契約電子化を含めたDX に残る課題

(1) 成りすましリスク等のサイバーセキュリティに関する問題

サイバーセキュリティは、近時、金融分野を中心に論じられることが多いが、フィッシング詐欺によるID・パスワード・ワンタイムパスワードの詐取等による被害が拡大している。金融分野においても従前の対策が機能しなくなりつつあるとの指摘もあり、今後の議論の進展に注目する必要がある。

この点、上記１．(4)イ．記載のとおり、3 条Q&A の検討を踏まえると、電子署名法第3 条の適用要件としては身元確認までは不要と考えられる。

一方、事業者型電子署名の利用に限らず、いわゆるクラウドサービスを利用する場合の一般的問題として、成りすまし等のサイバーセキュリティにどのように対処するかは別途検討する必要がある。この成りすまし防止策については、例えばマネーロンダリング対策としての犯罪収益移転防止法に基づく本人確認等、既存の本人確認の枠組みも存在するため、それらの既存の本人確認の枠組みを電子署名の世界にどのように接合するかについて今後議論を深める必要がある。企業間取引でいえば、リモートワーク拡大の過程で企業に属する従業員の身元確認は一定程度進んできたともいえ、企業の従業員が所属企業のアカウントに正規にアクセスした上で当該企業から指定された固有の電子メールアドレスを利用する限り、成りすましリスクはその段階で一定程度防止できるとも評価できる。

この「成りすましリスクをいかに防ぐか」の問題については、「仮に全ての契約をオンラインかつ非対面で行った場合の本人確認はどこまで行うべきか」という問題設定にすると、「厳格な身元確認を行ったほうが安全」という結論になる可能性はある。しかし、実際の法人間契約においては、既に過去に対面等で担当者レベルを含めてお互いを熟知しているケースもあり、また相手方との既存の信頼関係の有無や契約金額等によって法的リスクは異なるので、契約類型に応じた対応が有用と考えられる。

いずれにせよ、電子署名を利用する各企業が、取り扱う電子契約の金額や当該電子契約に含まれる情報（個人情報や企業の機密情報を含む）の重要性に応じて、自助努力として電子契約の世界でもサイバーセキュリティ対策を講じることは有用と考えられる。例えば、企業の法務部長やコンプライアンス部長等のしかるべき責任者が当該企業の電子署名アカウント保有者の身元確認を厳格に行った上で、後日当該企業の役職員等の身元確認に問題が発覚した場合には当該法人が対外的な責任を負うというアプローチや、事前に紙ベースの基本契約書を代表印で締結し、当該基本契約書の中で各企業の契約締結権限者及びその者の電子メールアドレス等の真正性に関する表明保証等を定めるアプローチもありうる。また、厳格な身元確認が必要と判断されるケースについては、オンラインで完結する本人確認（いわゆるeKYC）の活用が期待される。

不正を防止しつつ契約電子化を進めるためにはその時々の社会状況や技術の進展に応じて、利便性と安全性のバランスを考慮しつつ、例えば電子メールアドレス及びワンタイムパスワードの確認といった二要素認証が必要にして十分であるかを確認しつつ、契約類型に応じた各企業の自助努力として新たな本人確認手段についても柔軟に対応する必要があると思われる。

(2) 電子契約関連

① 3 条適用範囲の明確化

② 異なる電子署名サービスの互換性の問題

③ クロスボーダー取引における準拠法の問題

④ 書面要件の見直し

例えば、連帯保証については、書面要件が要求されるものの電磁的記録でも足りるとされている。この点、第8 回規制改革推進会議で方針が決定された通り、不動産や金融分野に関する押印要件の見直しが進められており、

例えば、宅建業法に基づく重要事項説明書の電子化等が議論されている。2020 年10 月12 日開催の規制改革推進会議第１回成長政略ワーキング・グループでは、各種書面規制を見直す必要性が再確認されている。借地借家法等を含め、現在公正証書等の紙ベースの契約書が要求されている契約類型についても、電子公証制度を活用する等により、例えば契約両当事者が自由意思で同意した場合には電磁的記録での契約締結を認める等の見直しも必要と思われる。

(3) 契約以外の業務関連

① 請求書等の電子化

② 取締役会議事録作成等の会社内部書類の電子化

(4) 行政司法手続等の電子化

① 電子政府において利用可能な電子署名の拡大

② 登記申請手続において利用できる電子署名の拡大

③ 司法手続の電子化

蒸し暑い

関東の梅雨入りはまだのようだ。それにしても蒸し暑い。最低気温が20度近く、夜が寝苦しい。南西の風で生暖かい空気。涼しくなってほしいものです。

世の中、何か、人が見ていなければ許される風潮が強い。
なぜ、人が見ていないと思うと悪いことをしたがるのか？
心の愚かさを感じる。

猫達も気温が上がり、ブラッシングをすると、毎日よく抜ける。
日々ブラッシング中。

歳を重ねると、古いものや利用しないものを整理中、メルカリに売れればよいのですが売れないものばかりなので、廃棄をしています。
利用価値のないものばかりが多すぎる。

昨年から新型コロナウィルスの影響でテレビなどが面白くなくなった。
古い演歌をよく聴くようになった。

八代亜紀さんの「雨の慕情」
岩崎宏美さんの「聖母たちのララバイ」

この2曲は良く聴いております

ドラマではチャングムの誓い、これは動がすべて観る。
韓国ドラマではこれだけがはまる。
韓国語に親しみがわきます。
このドラマ、この時代には・・・時代考証を無視しても面白い。
悪役の人もこのドラマでは好きです。
なぜかはまった。

写真は花の美術館

本人確認とは

キャッシュレスになると、すべて本人確認もWebで行われる
ということで何をしているのか

免許書などの画像の確認
　１．正当な免許の形式を備えているか否か
　２．氏名・住所などの間違いがないか否か
　３．画像は正面と斜め方向から撮影
　　正面は2の確認でもある
　　斜め方向は厚みを見ている、ようはペーパーに写真などを貼っていないかなどの確認
　　　(不正確認である)

銀行などの確認
　これは銀行名、支店名と口座番号とカタカナの氏名で確認ができる
　要は口座が実在するか否かをチェックしている

銀行などの窓口ならばしっかり確認できるが、WEBはすべて画像確認である
一部は銀行などに照会が可能である

ところで、このような確認は素人がやっているのが実情。
銀行などの照会もそうである。
これがキャッシュレス時代になった本人確認の方法
銀行の預金の動きや、借入金なども調べられているのが実情。
信用できますか？

＊＊＊＊＊

16日も蒸し暑い日が続く。
なぜこのように暑いのだろうか。昨年の新型コロナウィルスを含めて自然が人間を懲らしめようとしているようだ。
自然を大切にしないとよくない。

また人も我先に自己優先
ワクチンも権力者が先に接種する世の中。
全く、人間の心のないものが多い。

アジサイが一部咲きだす。
今年は速すぎ、梅雨も早そう

散歩には気持ちの良い15日でした

1週間ほど、Laravelについて一苦労。
単純なことに悩みすぎてしまったが、どのおかげで従来よりも問題が解決して、作りやすくなる。苦労するほうが報われる。

15日は久々に稲毛海浜公園に出て、撮影を楽しむ。
海辺は人が多いが、撮影にはよい環境。風景写真を楽しむ。
自転車族が増えすぎ、どこに行くにも電車よりは良いかもしれないがグループで動くときは周りに気を付けてほしい。

花の美術館に行けば、バラの撮影に楽しむ人など、人が多いので撮影が一苦労する。
周りに気を付けないと、他の人の撮影に邪魔になりそう。

大人がうろうろしているので中高生たちもうろうろしている。
油断をすると感染するので気を付けましょう。

遠景がきれいです。

バラもきれいです

Laravel：migrationで複数テーブルの共通カラム定義を1か所に共通化する

migrationで作成日などの情報がいろいろなテーブルに定義する。

この場合、いちいち書くのは面倒であるし、間違いやすい。

共通に書く方法

macroとは、Laravelフレームワーク自体が提供しているクラスに好きなメソッドを追加することができる機能です。

例えば、

Requestクラスにユーザーエージェントを判定するメソッドを追加してみたり、

Carbonクラスに特定のフォーマットに変換するメソッドを追加してみたり、

Laravelのクラスに自由にメソッドを追加できます。

migrationで利用されているBlueprintクラスにこのmacroで機能追加することによって

共通カラムのコード共通化を行います。

Blueprintにmacro追加

Blueprintのmacroを定義するためにサービスプロバイダを新しく作ります。

makeコマンド実行。

php artisan make:provider BlueprintServiceProvider

app/Providers/BlueprintServiceProvider.php

    public function boot()

    {   // 共通カラム

        Blueprint::macro('systemColumns', function () {

            $this->boolean('isactive')

                ->comment('アクティブ区分')->default(true);            

            $this->timestamp('created_at')->comment('作成日')->nullable();

            $this->unsignedBigInteger('created_by')

                ->comment('作成ユーザ')->nullable();

            $this->timestamp('updated_at')->comment('更新日')->nullable();

            $this->unsignedBigInteger('updated_by')

                ->comment('更新ユーザ')->nullable();

            $this->timestamp('deleted_at')->comment('削除日')->nullable();

            $this->unsignedBigInteger('deleted_by')

                ->comment('削除ユーザ')->nullable();

        });

    }

config/app.php

    'providers' => [

       中略

        App\Providers\BlueprintServiceProvider::class,

    ],

migrationでmacroを利用

    public function up()

    {

        Schema::create('clients', function (Blueprint $table) {

            // base

            $table->uuid('id')->comment('id')->primary();

            $table->string('value', 100)->comment('略称');

            $table->string('name', 150)->comment('名前');

            $table->string('description', 255)->comment('説明')->nullable();

            // 管理者：1社なら使わない

            // その他情報はinfoへ

            // 共通カラム定義

            $table->systemColumns(); 

            // 外部キー

            $table->foreign('created_by')->references('id')->on('users');

            $table->foreign('updated_by')->references('id')->on('users');

            $table->foreign('deleted_by')->references('id')->on('users');

        });

    }

アジャイル型開発

アジャイル型開発について

宣言などを読むと、本来、当然のことを言っているだけ

特別に難しいことは何もない。ところがドキュメント中心のＩＴ技術者を名乗るものがいるが、この人たちには特別のようだ。

何しろ、技術者を名乗っているが、動いたものを作っていない。
ドキュメントを作るだけで、コンサルタントでも動くものを作らないものは技術者ではない

そしてアジャイルがわかっていない

厳しい言い方ですが、本来、ソフトウェアはユーザが求めるものを作り、満足させるものです。
技術者が納得するものではありません。

そのため、ドキュメントを作っても、それがユーザが理解できるものであるならば、良いのです。ですが、ユーザにはわからないものを作るコンサルタント会社があります。

専門用語を並べても、技術用語を並べようが、それはユーザが理解できるものではない。

それが原因で、ドキュメントを含めてユーザが理解できるものが必要です。
アジャイル型開発ができたのは当然の出来事です。

テスト駆動を中心としてユーザにソフトを見せることが必要です。
技術者も、専門を作る必要もありますが、広く浅く、ソフト、ハード、ネットワークを知ることが必要です。

プログラムだけで満足してはいけません。

ではアジャイル型でもスクラムが中心です。

これまでと違い、PMが、立場を変えることになり、技術者はいろいろな分野に進出する必要があります。

それに開発スピードが速くなります。途中で止まることはないです。

少し基本用語を紹介

基本的なことを先ず抑えましょう。

スクラムは反復（イテレーション）を繰り返す開発プロセスです。この反復の単位を「スプリント」と呼びます。スプリントの中身は、「スプリントプランニング」「デイリースクラム」「スプリントレビュー」「スプリントレトロスペクティブ（ふりかえり）」、そして実際の「開発作業」です。

「スプリント」は 1 4 週間の時間枠（タイムボックス）であり、予定されている機能が完成できなくても延長されることはありません。この期間内で開発チームはスプリントバックログの開発に集中し、リリース判断可能なインクリメント（プロダクト）を作り出します。

「スプリントバックログ」は、プロダクトバックログから抜き出された、今回のスプリントで追加する機能のリストを言います。スプリントプランニングでプロダクトオーナーの決めた順位と開発チームが決めた見積りの両方の情報を合わせて抜き出されます。このリストは一回のスプリントにだけ使用されます。

「リリース判断可能なインクリメント」とは、一回のスプリントにおける成果を指します。スプリント終了時にはプロダクトが動く状態であることが必要となり、これをレビューして、プロダクトオーナーが実際にリリースするかどうかを決定します。すなわち、スプリント終了時には「リリース判断可能」になっている必要があります。

連休

連休といっても、自宅に閉じこもっています。

外出は買物と散歩ぐらい、今年になって都内にも出ないし、乗り鉄も控えています。
変異ウィルスが拡大しているので、従来の対策では追いつかない。

5月中旬以降、全国的にはさらに感染者が増加する可能性が高い。
自分の身は自分で守るのが鉄則です。

遊び歩いて、感染しても自己責任です。

陽射しが暑すぎる、ベランダの遮光を考えているので、連休中に遮光したいものです。
準備はしているので、あとは実行のみ。

今年は寒気が南下し、1日と2日はお天気が急変、急な雷雨となり、その後は虹、2日連続見れたのはラッキー。
虹を見ると心が弾むが、お天気の急変は勘弁してほしい。

SDGsとは何だろう。

環境問題？、ちがった。

色々なことがあり、簡単にまとめてみました。

新型コロナウィルスのこともあり、今後、進捗度合いが進むのかは未定
世界的には中国がどのように動かによって変わります。
環境問題などを産業化することによって日本と中国はライバル関係になりそう。

SDGsとは

SDGsとは「Sustainable Development Goals（持続可能な開発目標）」の略称です。そもそもどう発音するかというと、SDGs（エス・ディー・ジーズ）です。時々エス・ディー・ジー・エスと読まれる方がいらっしゃるのですが、最後はGoals（ゴールズ）の略です。

SDGsは2015年9月の国連サミットで採択されたもので、国連加盟193か国が2016年から2030年の15年間で達成するために掲げた目標です。

SDGsの17の目標

貧困や飢餓、健康や教育、さらには安全な水など開発途上国に対する支援に見えますが、日本においても、貧困やジェンダー平等に関してもお粗末です。

そのため、日本でも運動が広がっています。

エネルギーの話、働きがいや経済成長の話も出てくれば、まちづくりの話まで出てきます。これらは生活にかかわっています。

行政もこの辺りが中心人になって進められていますが・・・




気候変動の話、海の話や陸の話まで出てきますので、世界的な問題になります。
進みそうで進まない話がでてきます。