モデリング

2021/05/08

astah*の因果ループプラグインがいいね

astah*の因果ループプラグインを教えてもらったのでメモ。
使ってみるとなかなか良いです。

【参考】
snytng/inga astah*の因果ループプラグイン

思考力と注意力のトレードオフを因果ループ図で描いてみた: プログラマの思索

因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける: プログラマの思索

astah*の因果ループプラグインのメリットは、因果ループ図からロジックをリバースしてくれること。
要因Xが増えれば、要因Yが増えるのか、要因Yが減るのか、表示してくれる。
ロジックを見直す時に役立ちそう。

【1】教員希望者が減っているニュースを見て、その背景にあるロジックを書いてみた。

教員の過酷な労働実態相次ぐ投稿でオンライン上の報告会開催 | 教育 | NHKニュース

小学校教員倍率、過去最低2.7倍 質の確保急務: 日本経済新聞

Photo_20210508114201

ニュースでは、下記のロジックが読み取れる。

「教師希望者」が増えれば、「教師の質」が増える: 1 (自己強化=1, バランス=0)
→「教師の質」が増えれば、「モンスターペアレント」が減る: 1 (自己強化=1, バランス=0)
→「モンスターペアレント」が減れば、「教師の作業負荷」が減る: 1 (自己強化=1, バランス=0)
→「教師の作業負荷」が減れば、「教師希望者」が増える: 1 (自己強化=1, バランス=0)

そこで、教師希望者を増やすために、教師増加キャンペーンを実施したわけだが、本当に効果があるのか?
レバレッジポイントはそこなのか?
他の要因を増減させるような施策の方が優先ではないか?

他にも隠れたロジックがないか?
色々考えが思いつく。

astah*の因果ループプラグインの他の機能では、下部欄の因果関係をクリックすると、因果ループ図の線にフォーカスしてくれる。
ただし、Same(+)は実線、Opposite(ー)は破線なので注意。

| | コメント (0)

2021/04/29

デジタル庁で応募中のアイデンティティアーキテクトは昔のDAと同じ役割か?

デジタル庁でアイデンティティアーキテクト、データアーキテクトを応募しているツイートを見つけたのでメモ。
ラフなメモ書き。

【参考】
yoshi sanさんはTwitterを使っています 「アイデンティティアーキテクトなる独立したポジションがあるんだ。」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクトってなんだよと思ったけどめちゃまともな内容だった」 / Twitter

Yoshikazu NojimaさんはTwitterを使っています 「デジタル庁のアイデンティティアーキテクト、超重要かつ超高難易度な仕事にしか見えないのだけど、どんなキャリアパスを積んで、どれほどの研鑽を積めば担えるのか想像もつかない。 https://t.co/2iU02v4WLr」 / Twitter

akipiiさんはTwitterを使っています 「アイデンティティアーキテクトとは、昔のDAと同じ役割か?」 / Twitter

からくりさんはTwitterを使っています 「アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト https://t.co/raIDjeGhb9 めちゃくちゃ楽しそう(発狂しそうなほど大変だと思うけど)」 / Twitter

ミジンコOLさんはTwitterを使っています 「アイデンティティアーキテクト、あの先輩しか思い浮かばない。 ・行政証明書コンビニ交付サービスの開発経験有 ・某メディア企業の大型サービス利用ID統合経験 ・プラポリにも詳しい ・認証・認可詳しい ・IPA上級資格9割持ってる ・泥臭いPJTの中でも爽やか #デ https://t.co/Ue6JVxsyLh」 / Twitter

【参考】
中途採用|デジタル庁創設に向けた準備サイト

『アイデンティティ管理技術解説』システムアーキテクトを志す方のために IPA

【参考1】
アイデンティティアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
デジタル庁(仮称)においては、行政サービスのデジタル化・ワンストップ化を推進するにあたって、利便性が高く安全な識別・認証の仕組みを構築することにより、多種多様なシステムにまたがった円滑なデータ連携を実現していくことが求められます。

アイデンティティアーキテクトは、各省庁の担当者や専門家と連携して、デジタルガバメントのサービス高度化に必要な、アイデンティティ管理、データ連携の枠組みを構想し、その整備を推進する役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

政府情報システムに関わるアイデンティティ管理の計画策定全般

住民制度、公的個人認証、マイナンバー制度に関わる個人のアイデンティティ管理もしくはGビズID、商業登記電子証明書等に関わる法人等のアイデンティティ管理

行政事務と住民・事業者向けシステム、住民・事業者向けシステム間をつなぐ国のシステムを理解した上での、業務プロセスの見直し、移行計画の立案、変革の推進

国民・事業者向けサービスや各省庁のシステムにおける利便性の高い安全な識別・認証の仕組みづくり

各省庁や地方公共団体の専門家と連携した横断的なプロジェクトの推進
(引用終了)

【参考2】
データアーキテクト?- 中途採用|デジタル庁創設に向けた準備サイト

(引用開始)
募集背景・業務内容
データアーキテクトは、デジタル庁(仮称)において、社会全体のデータの現状と将来像を俯瞰し、データ戦略の策定を主導するとともに、標準やルールに加え基礎データ、プラットフォームなどを整備し、その活用を推進していくことが求められます。また、多数のステークホルダーとの調整を進めながら、デジタル時代の新たなスタンダードを構築していくための強いリーダーシップが求められます。

政府は、多量のデータを保有するデータホルダーとして、またデータプラットフォーマーとして、先導的な振る舞いを期待される立場です。本ポジションは、あらゆる社会・経済活動に不可欠なデータを、国の競争力の源泉とするために、また、豊かな生活を実現する上で不可欠な基盤とするために、中心的な役割を担っていただきます。

具体的な業務内容は、以下のとおりです。

体系的なデータ整備に係る中長期戦略・計画の策定

データ標準・データ連携プラットフォームの整備

政府内におけるデータサイエンスやAIの活用の推進

デジタル庁(仮称)内外のデータに関する人材育成

データに基づいたEBPM(Evidence-Based Policy Making、証拠に基づく政策立案)の推進

国際機関や関係各国との交渉
(引用終了)

【感想1】
デジタル庁でアイデンティティアーキテクト、データアーキテクトの募集背景・業務内容を読むと、本当にガチの内容だ。
個人的には、一昔前のデータアーキテクトの業務を連想する。

その頃は、テーブルを新規追加したり、カラム1個を追加するのに、わざわざデータアーキテクトに申請して、内容の詳細や対応期限を説明して、開発環境にやっと反映される、みたいな牧歌的な時代だった。
データアーキテクトは、ER図やデータディクショナリの保守担当者みたいなイメージを持っていたので、あまりカッコイイ職種には感じなかった。

しかし、実際の業務システムの要件定義では、データモデリングの技量の違いがその後の設計、開発の室に直結する。
業務フローのようなプロセスばかり書いても、フワフワしていて、テストでデスマーチになりがち。
データ基盤がしっかりしていれば、そこから業務の制約条件をプログラマも読み取れるし、テストデータを作ったり、保守していくのもかなり楽になる。

さらに、データアーキテクトの職種だけでなく、アイデンティティアーキテクトという職種まで応募しているのはとても興味深い。
単に、公共サービスのデータ基盤、データディクショナリを揃えるだけでなく、その根本となる一意な主キーを見出し、それを維持管理していく重要性を認識しているのだろう。
もちろん、マイナンバー制度という国民をユニークに識別する仕組みにも直結する。
国民を一意に識別してデータを管理できる基盤があれば、今のコロナワクチン予防接種の履歴管理に使えるし、今後のワクチンパスポートの発行にも発展できる。
他にも、収入や資産の追跡、税の徴収だけでなく、本当に困っている人たちを特定して補助金を直接届ける、という仕組みも作れるはず。

また、アイデンティファイアの整備は、認証基盤にも直結する。
政府の膨大な公共システムを利用する場合に、利用者の国民が安全に利用できるだけでなく、バックエンドの事務に携わる公務員や保健所の人たちが安全にログインできて、その操作履歴をきちんと管理できる仕組みも必要。
さらには多種多様な利用権限の制御まで考える必要もあるだろう。

つまり、価値ある公共サービスを提供するためにデータ基盤のアイデンティファイアは必須要件だが、人権やプライバシーの保護の観点からアイデンティファイアの認証・認可・アカウンティングの機能要件も必須という、高度なハードルがある。
想像するだけでも、アイデンティティアーキテクトという職種は非常にタフで難儀な内容であるのは間違いない。

だからこそ、こういう職種が必要ときちんと公開して打ち出しているのは信頼が持てる。

【感想2】
最近はITコミュニティ以外にも、官公庁の関係者がオンライン勉強会で登壇して色々話してくれる場が多くなった。

直近で、農林水産省とウーオが語る!林業・水産業をITで変えるチャレンジ - connpassを聞いた時、今の官公庁で最もデジタル化が進んでいるのは、実は農林水産省なんです、という発言を聞いて驚いた時がある。
その時の事例では、ベンチャー企業が、漁港で取った魚と都市部の魚市場のマッチング処理のシステムを開発して、お互いの利益を向上させる、という話だった。
他にも林業で、日本産の木材が、今はコロナなので実は高く売れている、そういう市場をITの力で支援している、という話もあった。

おそらく、楽天、メルカリのビジネスモデルのように、生産者と消費者のマッチング処理を農業や水産業の市場に適用して、両者がWin-Winになるような方向を目指しているのだろうと思う。
そんな話を聞くと、単に業務システムを開発したり、ITビジネスでお金を儲けるだけでなく、IT技術を社会の問題解決に適用し、多くの人達のために社会貢献する方向に進化しているように感じた。

| | コメント (0)

思考力と注意力のトレードオフを因果ループ図で描いてみた

思考力と注意力のトレードオフを因果ループ図で描いてみた。
世の中の現象を因果ループ図で描く練習の一つ。
ラフなメモ。

【参考】
「情報」と「注意」のトレードオフ | 楠木建 ようするにこういうこと|DIAMOND ハーバード・ビジネス・レビュー

【ロジックの流れ】
知識が増える
→思考する時間が増える
→知識をより要求する

一方、
知識が増える
→記憶した知識を整理する注意力が増える
→注意力は限度があるので、知識量を抑える
→思考力は限界で伸び悩む

人間の脳の処理能力には一定の限界がある
→注意力・意志力は有限のリソースになる
→知識が増えすぎるほど、思考力も限界に達する

では、どこで解決策を考えるのか?
パターンは3つある。

思考力を強化して、思考力向上ループを強める。
注意力を弱めて、注意力散漫ループを弱める。
知識量を調整して、注意力散漫ループよりも思考力向上ループを高めるようにする。

トレードオフがテーマなので、思考力や注意力を強めても、他要素に悪影響がある。
システム原型「成長の限界」と同じ。

限られた有限リソースの注意力を思考の質向上に使う。
よって、注意力散漫ループの負のループを弱めるために、知識量を減らす。
知識量を減らすには、情報収集チャネルを減らし、インプットすべき知識量を減らす。
一般には、雑念を増やすような媒体、テレビやスマホ、無駄なSNS、無駄なネットサーフィンは避ける、みたいなロジックなのかな。

【気づき】
システム思考の重要性は、アジャイル開発やスクラムの書籍でよく言われている。
しかし、実際にシステム思考を使いこなすのは非常に難しい。

因果関係を見つけるのも大変。
そのフィードバックで元に戻る、というロジックを見つけるのが難しい。

その因果関係は本当に正しいのか?
漏れている因果関係はもっとあるのでは?
と考え出すときりがない。

システム思考の研修で聞いてみたら、書き方は何種類もあっていい。
正しい回答はない、ということだった。
つまり、因果関係はその人のマインド、固定観念を表す。
そこからメンタルモデルを見つけて、新たな観点の気づきを得る、みたいな対症療法みたい。

今後も色々書きなぐってみる。

| | コメント (1)

2021/04/10

SQLは画面や帳票のインターフェイス層に相当する

下記の記事で、データモデリングではSQLは画面や帳票のインターフェイス層に相当する、という点に気づいた。
ラフなメモ書き。

【参考】
顧客も技術者も不幸になる人海戦術に終止符を、実データで設計を吟味せよ | 日経クロステック(xTECH)

杉本啓さんはTwitterを使っています 「これを読むと、データ中心アプローチの人々がサロゲートキーを嫌う理由がよくわかるよね。サロゲートキーを使ったDBでは、ユーザーがこんな風に気軽にデータをいじれない。 サロゲートキーは、ユーザーを「データベース=帳簿」から隔離して、技術的な存在にしまう。」 / Twitter

【1】僕はSQLは好きだ。
下手にExcelでデータをこねくり回すくらいなら、RDBに入れたデータをSQLで自由自在に抽出したり集計する方が楽だから。
一方、データモデラーではSQLは重視しない点にちょっと違和感があった。
しかし、上記の記事で、SQLは画面や帳票のユーザインタフェースに相当する事に気づいて納得した。

実際、正規化されたテーブルがあれば、欲しいデータはSQLで取ればいい。
その欲しいデータは、画面にあらわれているデータであり、帳票として印刷されるデータそのものだから。

よって、モデラーが業務の制約条件を上手くテーブル設計に反映しておけば、ユーザはSQLで好きなようにデータを抽出できるはず。

一方、訓練された設計者であれば、ER図を眺めれば、そこから業務フローや帳票、画面をイメージできるだろうが、外部設計フェーズで画面設計や帳票設計に注力してしまい、DB設計は単にデータベース定義書を作るだけ、という考えでいると、複雑なシステムになってしまい、失敗しやすいのだろう。

【2】サロゲートキーで統一されたテーブルでは、Webシステムは作りやすい。
Railsが典型的な例。
URLとメソッド、テーブルが1対1に関連付けられるので、URLベースで設計すれば、そのままプログラミングできる。

一方、DOAでモデル駆動開発を推進したい時、サロゲートキー中心のデータモデルでは、テーブル間の関係が判別しにくい。
テーブルを結合したり、入力データの制約がすぐに見えないからだ。
よって、業務を知るユーザがSQLを駆使して、テーブルを結合して、欲しい帳票を得る手法が取りづらくなる。
だから、データモデリング主導の開発では、サロゲートキーは廃止して、明示的にテーブル間の関数従属性を可視化できるようにしておきたい欲望がある。

【3】業務フローからテーブル設計するのはPOA。
本来のデータモデリングでは、AsIsの業務で手元にある帳票からER図を洗い出せる。
これは「楽々ERDレッスン」と同じ考え方。
やはり、既存の帳票はデータモデルの源泉になるから。

他方、あるべきデータモデルから、業務フローや画面構成を想像することはできるか?
これができれば、業務の要件定義がやりやすくなる。
これをやるには、個人的には、T字型ERの手法がやりやすいと思っている。
なぜなら、リソースやイベントのテーブル同士のリレーションシップは一定の法則で決定づけられる、という方針なので、初心者には使いやすいから。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

| | コメント (0)

2021/04/01

統計学と機械学習の違いは、データの説明かデータの予測か

統計学と機械学習の違いについて、明確な回答があったのでメモ。
統計学は「データの説明」、機械学習は「データの予測」に目的がある。

【参考1】
統計学と機械学習はどう違いますか?一方にできてもう一方にできないことは何ですか? - Quora

「統計学と機械学習の違い」はどう論じたら良いのか - 渋谷駅前で働くデータサイエンティストのブログ

(引用開始)
記事中では「統計学は『説明』するためのもの、機械学習は『予測』するためのもの」という表現をしています。
(引用終了)

【参考2】
データ分析の事始め~統計学と機械学習の違い~ | 株式会社豆蔵

(引用開始)
統計学は「データの説明」に、機械学習は「データの予測」に重きを置いていると言えます。
この違いはデータ分析を行う側にとって大きな違いであり、使い方を間違ってしまうと、データから有用な知識を得られない可能性があります。
(引用終了)

【参考3】
「統計」と「機械学習」の違いの整理で多くの事業会社で「機械学習」が使えない理由が視えてきた! - Qiita

(引用開始)
「機械学習」は予測や判断は行うもののなぜそうなったのかは一般的にはブラックボックスだ。
「統計」で行う予測や判断は、なぜそういう結論になったのかの理由付けが重要になり(理由付けを行うための学問であり)、理由はホワイトボックスとなっている。

なぜ多くの事業会社が「機械学習のアプローチを使えない」のか?
要因の整理に力を入れることが目的の「統計」は社会科学の課題解決に向いており、「機械学習」は自然科学の予測やロボットでの自動処理に向いている。と、
(引用終了)

【参考4】
【図解】コレ1枚でわかる統計学と機械学習の関係:ITソリューション塾:オルタナティブ・ブログ

(引用開始)
「データを使って問題を解決する」という方法論において、「統計学」も「機械学習」も違いはありません。両者の違いは、方法論、すなわちアルゴリズムやテクノロジーにあるというよりも、その目的にあると言えるでしょう。

統計学は、データを「説明」することを目的としており、記述統計(descriptive statistics)と推測統計(inferential statistics)に分けることができます。
(中略)
一方、機械学習は、データから「予測」して、分類・識別・判断を最適におこなえるようにすることを目的としています。

予測とは、まだ分かっていない答えを知るためのモデル(推論モデル)をデータから作り、これをいまのデータに照らし合わせて、将来何が起こるのかを予測する、この対象をどのグループに分類するのが適切なのかを決める、いま目の前にあるのは何かを識別するなどを行います。つまり、データを与えれば、推論モデルに照らし合わせて、分類・識別・判断を自動化することを目指しています。
(引用終了)

【1】Pythonで機械学習や深層学習のプログラムを写経したり、真似て書いていると、まだ分かってないな、という気持ちになる。
その気持になった原因を探ってみると、データをモデル化して構造を見たいのか、データをモデル化して予測に使いたいのか、を混同しているような気がした。

たとえば、統計学とは~という中身の本は、データをモデル化して構造を見るためのアルゴリズムだけを紹介している。
だから、昨今の機械学習や深層学習ではどうなの?という疑問があった。

統計学は「データの説明」、機械学習は「データの予測」、という基準で使い分ければ、ちょっとは迷子になりにくいだろう。

【2】しかし、統計学でも、機械学習でも、利用シーンに応じてアルゴリズムを使い分ける必要があるが、アルゴリズムの数が膨大なので、どの場面にどのアルゴリズムが有効に利用できるのか、なかなか分からない。

現実世界では、データをモデル化した時、モデルの数は星の数ほどあるだろうから、それぞれのモデルに合った統計アルゴリズムも星の数ほどある。
それらを逐一覚えるような気は正直起きない。

scikit-learn「アルゴリズム・チートシート」のリンク: プログラマの思索

でも、何らかの基準は欲しい。
結局、それぞれの事象に対して、そのモデルに見合ったアルゴリズムを見つけては、新規性がある!と叫んで、どんどん発見していき、植物学や動物学みたいに、数多くのアルゴリズムという標本集めをやっているだけなのかだろうか?
この辺りはもうちょっと考えてみる。

| | コメント (0)

2021/03/26

ITの技術や知識はツールの習得と表裏一体である

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。
とても当たり前の内容かもしれない。

【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。
でも何か分かったような気がしなかった。
何か真似事しているだけのような気がした。
なぜだろうか?
いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。

【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。
具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。

理由は、2つある。

【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。

たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。
昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。

今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。
実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。
PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。
ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。

たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。
特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。
それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。
ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。

たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。
実際にモデルを描いてみると、数多くのモデル管の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。

特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。
ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。
だから、データモデリングの考え方自体も普及していない。

【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。

たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。
RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。
しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。
つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。
もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。

たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。
しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。

実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。
IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。
100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。
そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。
そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう

たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。

たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。
すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。
また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。
つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。
Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。

逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。
Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。
たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力もあったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。
「ツールがプロセスを改善していく」という発想が僕は好き。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索

ツールがサポートすれば考え方も変わる: プログラマの思索

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

開発プロセスの型をツールで構築する #tidd: プログラマの思索

【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。
換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。

それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。

だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。
そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。

最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。
いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。
視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。

昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。
そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。

| | コメント (0)

2021/03/21

「データモデル大全」は良い本だ

渡辺さんの本「データモデル大全」を読んだ。
いろんな気づきがあるので、ラフなメモ書き。

【参考】
業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

渡辺式データモデリングの復習: プログラマの思索

第39回IT勉強宴会の感想~花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談: プログラマの思索

第66回IT勉強宴会の感想~データモデリングに数多くの流派が発生している理由: プログラマの思索

関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング: プログラマの思索

【1】「データモデル大全」のデータモデリングは多分かなり高度なので一般でないと思うけど、後で、なるほどと気づく。

たとえば、動的参照関係で、複数のテーブルのビューがあれば、外部キーの参照関係が生じるが、普通のER図では表現できない。

たとえば、「データモデル大全」のデータモデリングでは、ツリー構造のモデルが特殊。
ヘッダーと明細のテーブル二つに親子階層を持たせて、親テーブルにLLCという階層最小値を持たせて、ツリー構造を表現する。
再帰構造ではない。
たぶんこのデータモデルであれば、PLSQLのバッチ処理が書きやすいのだろうと想像する。
他方、Redmine ならば、チケットの階層構造は、入れ子構造のデータモデルで実現できてる。
こっちの方がプログラマは書きやすいだろう。

【2】「データモデル大全」のデータモデリングで最も特徴的なのは、2次識別子を使って、参照関係や連関テーブルを表現してる事。
製品の入出荷履歴などの沢山のテーブルは、受払履歴テーブルに集約させるが、その時に、取引管理番号を各テーブルで2次識別子に持たせる。
そうすれば、最初はNull値でも、後からデータ更新できるので、一意制約を持たせられる。

データモデル大全」全では、他に、逆に、入出荷指示明細テーブルから受払予定、受払履歴、売上履歴などのテーブルへばらすモデルを作り、指示を出したら、売掛金の履歴や在庫の履歴が見れるテーブルを用意してる。
この辺りは本当にすごいなと思う。

【3】惜しむらくは、データモデルしか記載がないので、どんな業務フローになるのか、どんな画面遷移になるのか、が分かりにくい事。
せっかくなので、このデータモデルからRailsで画面を自動生成して、簡単な画面遷移が作れると良かったのに、と思う。
そうすれば、データモデルの威力が分かるはず。

たとえば、データモデルからイメージできるのは、注文ヘッダ・注文明細の親子関係タイプと注文明細・商品情報の参照関係タイプがあれば、それらは一つの帳票を表す。
よって、データモデルから、本質的な帳票がいくつあるのか、を見抜けば、帳票を保守する画面数やバッチ処理本数を算出できる。

たとえば、データモデルから時系列の順序を導くのは、T字型ERの考え方を使って、トランザクション系テーブル同士に参照関係があれば、1:Nの関係があるので、先トランザクションテーブル:後トランザクションテーブル=1:Nとみなすことで、導ける。
よって、時系列に帳票が作成される順序を考えれば、業務フローが描けるはず。

この辺りのイメージはまたまとめてみる。


| | コメント (0)

2021/02/25

関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング

関西IT勉強宴会で、コロナワクチン接種管理システムのデータモデリングを解説されていたので、聞いていた。
ラフなメモ。

実際のデータモデリングは、Youtubeの動画を是非見て欲しい。
ITエンジニアであれば、解説の内容や説明の意図はすぐに理解できるはず。

【参考】
緊急開催「新型コロナワクチン接種管理システム」をローコード開発してみた - connpass

「新型コロナワクチン接種管理システム」をローコード開発してみた<第82回IT勉強宴会inZoom> | IT勉強宴会blog

「新型コロナワクチン接種管理システム」のデータモデル公開: 設計者の発言

(1)やっぱりデータモデリングができる人は要件定義に強い。
業務をヒヤリングしただけで、どんなデータモデルが必要なのか、どんな業務フローになるのか、業務のどこにボトルネックが発生するのか、をデータモデルから推測しているし、その根拠を明確に説明している点がすごい。

(2)渡辺さんがメーリングリストで、エンジニアであるならば、要件を聞いて実際にプロトタイプを作って、見せることで理解するよりも、データモデルを作っただけで理解して欲しい。
それがプロでしょ、という意見が本当に切れ味が鋭い。
データモデルが描ければ、データモデル上の制約条件から、業務フローも画面内容も画面遷移もほぼ一意に決まるし、それくらいの内容はエンジニアなら連想して欲しい、と。

| | コメント (0)

2021/02/12

Astah C4 model pluginが公開された

Astah C4 model pluginが公開されたと聞いたのでメモ。

GitHub - ChangeVision/astah-c4model-plugin

複雑なUMLの代わりにC4モデルが提案されている: プログラマの思索

ソフトウェアアーキテクチャのためのC4モデル

ソフトウェアアーキテクチャのためのC4モデル - 雪泥鴻爪--IT技術者の随筆

C4 Model - albatrosary's blog

(引用開始)
C4 Model は
コンテキスト(context)
コンテナ(containers)
コンポーネント(components)
コード(code)
の略です。
(引用終了)

C4モデルは、クラウド上のWebシステム構築に特化したモデリング技法とみなした方がいいのだろう。
astahでもC4modelが描けるプラグインが出たので今度試してみる。

| | コメント (0)

2021/01/05

yWriterは映画の脚本を作るためのアプリだったのではないか

小説分析ツールyWriterに似たようなソフトとして、ストーリー作成ソフト『StorYBook』があるらしく、その記事を読んでいたら、こういうストーリー分析ツールは映画の脚本を作るためのアプリだったのではないか、と気づいた。

【参考】
ストーリー作成ソフト『StorYBook』を使ってみた: はまログ

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

【1】実際に、yWriterは映画の脚本を作るのに最適だ。
理由は2つある。

【2】一つは、場面ごとに、人物・場所・アイテムという貴重なリソースを割り当てることが明確になるからだ。
映画では、一つの場面ごとに、高額な俳優に来てもらい、海辺やビルなどの場所を確保して、衣装や車などの道具(アイテム)を準備して望む。
1つの場面がたとえ5分であっても、人物・場所・アイテムという貴重なリソースをたった一つの場面に割り当てる必要がある。

一方、ある俳優の撮影期間が限定される場合、彼が出演する場面をすべて抜き出して、あらかじめ撮影すれば良い。
そのために、映画を数百本の場面にバラしておき、特定の俳優がアサインされる場面だけを抽出して、全体ストーリーとは無関係に個別にシーンを撮影するように、人物ごとの撮影スケジュールを作ればいい。

つまり、場面の観点ではなく、人物の観点で場面を抜粋しているわけだ。
あるいは、夕焼けの海辺のシーンのように、この一瞬しか場面を撮影できないとなれば、場所の観点で撮影スケジュールを作ればいい。

つまり、人物一覧・場所一覧・アイテム一覧のビューで、場面数が集計表示されるのは、そういう意味があったわけだ。

【3】もう一つは、ストーリーボードで時系列に場面を簡単に入れ替えたり、追加・変更・削除できることにより、映画のストーリーを柔軟に変更しやすくなることだ。

映画は2時間という制約があるので、場面数には上限がある。
よって、脚本家が数多くの場面を細切れに作った後で、まるでブロックを組み立てるように、場面を時系列に並べると映画が完成する。
名作と言われるレベルまで練り上げるために、場面を入れ替えたり、削ったり、場面を書き直したり、何度も推敲すればいい。
そういう推敲作業をツールが支援してくれるわけだ。

yWriterにはストーリーボードなど数多くのビューがあるけれど、その他の米国製のストーリー作成アプリを調べてみると、登場人物の家系図や関係図を表示したり、場面・人物ごとのカレンダーを表示したり、場所を集めた地図を表示するような機能もあるらしい。

確かに、歴史小説や推理小説であれば、人物の家系図や時代表はあると理解しやすい。

【4】こういう小説分析ツール・ストーリー作成ソフト・映画の脚本作成ツールは、なぜか日本製のツールがなくて、ほとんどが米国製だったりする。

たぶん、ハリウッド映画のように大量に映画を作成するには、こういう脚本作成ツールでロジカルかつ大量な場面を管理するツールが必要なのだろう。
また、欧州では小説を論理的に場面を意味あるもので組み合わせて構成するようなので、場面を管理して分析できるツールは必要なのだろう。

一方、日本ではこういうツールがない事実があるので、小説や映画、テレビ番組の脚本は、小説家や脚本家の個人的能力だけに依存しているか、アナログの京大式カードなどで場面を管理するとか、そういうレベルに過ぎないのかもしれない。
あくまでも推測に過ぎないが。

【5】yWriterをモデリングの観点で分析してみることで、アジャイル開発に出てくるストーリーのニュアンスや役割が何となくイメージできた気もする。
たぶん、欧米人がシステム要件をユーザーストーリーと呼んで扱っている場合、日本人の想像を遥かに上回って、もっとロジカルなレベルで考えているのだろうと思う。
つまり、ユーザーストーリーには、目的・対立・結論の構造と、人物・場所・アイテムの構成要素を持ち、英雄伝説の構造に沿って、世界中の人が誰でも親しみのある物語形式のロジックに組み込むように、彼らは作り込んでいるのだろう。

この考え方を使って、ユーザストーリーマッピング、カスタマー・ジャーニー・マップ、ナレーティブ・ジャーニー・マップなどの要件定義手法を考えてみたいと思う。

| | コメント (0)

より以前の記事一覧