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次識別子を使ったデータモデリング: プログラマの思索

テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA

@t_wadaさんがテスト駆動開発のライブコーディングをやっていて、歩きながら聞いていた。
@t_wadaさんがブツブツつぶやいてくれているので、画面を見なくても、聞くだけで想像できる。
まるで、テスト駆動開発のラジオドラマみたいな感じだ。

Developer eXperience Day CTO/VPoE Conference 2021 - connpass

akipiiさんはTwitterを使っています 「#dxd2021 #streamA @t_wada さんのライブコーディングを歩きながら聞いていて、低い声質が良いし、テスト駆動のコメントや呟きがDJみたいて聞きやすい。バグ修正とリファクタリングは分けましょうね、とか、独り言みたいな呟きが自分事でリアルに感じる」 / Twitter

@t_wadaさんの呟きで面白かった点を記録しておく。

テストプログラムを書いていると、バグ修正とリファクタリングが混じってしまう時がある。
お勧めは、バグ修正だけに注力するか、リファクタリングだけに注力するか、モードを意識的に切り替えること。
思い通りの動きにならない時に、バグ修正とリファクタリングが入り交じるのはお勧めしない。

テストプログラムを書いていくと、テストプログラムがドキュメントそのものになる。
すると、状況の下に機能を置くか、機能の下に状況ごとに書いていくか、どちらかの方針がある。
どちらも正しい。

テストプログラムの観点では、状況の下に機能を書く方が、書きやすい。
状況はグローバル変数として共通化されるので、ソースコードは短くなるので保守性は高くなる。
しかし、機能が直感的に分からないから可読性は低くなる。

一方、機能の下に状況ごとにツリー構造にロジックを書いていくと、テスト仕様書のようになるので読みやすい。
機能のツリー構造は、業務システムアプリとかWebアプリのメニューみたいなものだから、どこに機能があるのか探しやすい。
しかし、状況があちこちに散らばるので、重複したソースコードが多くなり、保守性は下がる。

つまり、テストプログラムの可読性と保守性はトレードオフになる。
どちらが正しい、というわけではない。
テストプログラムを書く人の永遠の問題。

そこで、このトレードオフを緩和するために、パラメトライズド・テストプログラミングのテクニックがある。
つまり、テストメソッドやテストプログラムをパラメータで増やすやり方がある。
これにより、テストプログラムを機能別に書いたとしても、状況をパラメータとして増やすことができて、テストプログラムの可読性を保持するとともに、保守性も高める。

テスト駆動開発がXPで出てきてからもう20年も経つ。
改めて聞いて、色々気づきがあってよかった。

プロジェクトのリスクはコストの増減で管理する

「プロジェクトのリスクはコストの増減で管理する」のであり、「コスト管理と課題管理は同じではない」。

【参考】
コストマネジメント（コストコントロール体系） | イノベーションマネジメント株式会社

プロジェクトリーダーのレベルではなく、事業部長や複数プロジェクトを取りまとめる組織の長の観点では、各プロジェクトのリスクをどのように軽減したり、回避したりするか、に注力するようになる。
リスクを完全にゼロにすることは、お金もリソースも使い過ぎるので、現実的ではない。

各プロジェクトでは、計画時にプロジェクト特性に応じて、リスクを洗い出す。
プロジェクトリーダーは、プロジェクトのキックオフ後、実行中では、リスクがどのように変化して、増大して手に負えなくなるか、事前に防げるか、に注力していく。

一方、事業部長や部課長の観点では、どこかのプロジェクトで火を噴くリスクがあると考えて、事前に各プロジェクトのリスクをコストで予算化しておく。
そういう予算は、プロジェクト外費用ならコンティンジェンシー予備費だし、プロジェクト内費用であればマネジメントリザーブ（マネジメント予備費）になる。
そして、実際に火を噴いたら、マネジメント予備費を使うし、更に足りなければ、コンティンジェンシー予備費を投入してでも、火を消すようにする。

一般に、マネジメント予備費を使う権限は、プロジェクトリーダーの采配と組織の最末端の管理職である課長の采配の２つで決まるだろう。
マネジメント予備費は契約時に、利益やコストを見込んで、契約金額に上乗せして積まれている。
マネジメント予備費を使うほど、利益は落ちるので、プロジェクトリーダーの権限ですべてを使っていいわけではなく、最低限の利益ラインを超える場合は、課長の承認が必要になるだろう。
普通は、一旦プロジェクトが火を噴けば、際限なくコストは膨らんでいく。

そして、コンティンジェンシー予備費は、事業部のトップである事業部長の承認で決まる時が多いだろう。
コンティンジェンシー予備費を使う段階まで来ると、経営陣にもその使途理由を問われるので、社内では相当な噂になりやすいだろう。

駄目なプロジェクトでは、プロジェクト計画時にリスクをそもそも洗い出せておらず、単なる課題一覧に過ぎない。
適当に解決するだろう、という期待を含めた課題管理に陥っている。
だから、リスクが顕在化して手に負えなくなると、肝心の予算がなく、単なるデスマーチ案件となってしまって、会社のお金や人員を無尽蔵に浪費していってしまう。
元々、リスクに対する予算などの手当がないので、何の戦略もなく、ズルズルと状況に押し流されるだけになる。

本来は、リスクの内容に応じて、影響度や深刻度、重要度に応じて、そのリスクが発生した場合にかかる費用を見積もり、それらの合算をコストとして予算として見込む。
もちろん、全てのリスクを洗い出して合算したら、途方もない金額になるから、ある程度のリスクは許容することで予算化しないことになる。
あるいは、コストが掛からない対策があれば一番良いが。

PMOの仕事をしていると、プロジェクト運営という観点だけでなく、プロジェクトの採算やコスト管理まで見るようになってきた。
その時に、駄目な会社では、ISO9001を運用していると標榜しながらも、プロジェクト計画書に記載されたリスク一覧が単なる課題一覧に貶められている風景を何度も見てきた。
本来、リスク管理とは何だろうか？という疑問があったが、リスクはコストの増減で管理するという発想が必要と分かり、ようやく腑に落ちた。

沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね

沢渡さんの資料「テレワークに役立つ8つのスキル」が参考になるので、メモしておく。

【参考】
経営課題解決のためのテレワーク導入・活用Webセミナーレポート｜トピックス｜ハマリモ！ 浜松テレワーク推進プロジェクト

テレワークが主体になった仕事では、以前とは違ったスキルが必要になっていると感じる。
特に、周囲に誰も居ないので、自分自身でスケジュールや仕事の内容をコントロールすることが重要になったし、それがさらにシビアに厳しくなった感じだ。
テレワークによって、正社員であっても、個人事業主が請負契約で仕事しているイメージに近い。

なぜなら、テレワークの成果物としてアピールすべきものは、目に見える成果として出さなければ、存在しないのと同じだから。
よって、より高いアウトプットを定期的に出すためのスキルが別途必要になっている、と考える。

「テレワークに役立つ8つのスキル」では、下記がある。
・ロジカル・コミュニケーション
・セルフマネジメント
・ヘルプシーキング
・クリティカル・シンキング
・チームビルディング
・プロジェクトマネジメント
・ファシリテーション
・ITスキル/リテラシー

「テレワークに役立つ8つのスキル」を分類すると、2つのカテゴリに分類できるだろう。
他者とやり取りする技術、そして、自分自身を律する技術。

テレワークでは、他者とやり取りする手段がチャットやTV会議に限られるため、対面よりも情報量が圧倒的に少ない。
だから、いかに濃い情報をやり取りできるか、が鍵を握ると考える。

そのために、論点を明確に手短に話したり、議論している内容から課題を抽出して構造化・言語化したり、お互いに率直に話せる環境を醸し出したり、などのスキルがいる。

また、テレワークでは、自分一人で成果物を作り出す能力がより求められるので、自己管理がより重要になる。
問題を整理し、ゴールを定め、ゴールまでのプロセスを作り、作業に分解して、作業しながら自分の立ち位置を自己測定する。
つまり、プロジェクトマネジメント力がかなり求められる。

また、集中して仕事できる環境を整備し、時にはモチベーションを奮い立たせたり、リラックスできる環境もいる。
もちろん、オンライン会議ツール、チャットツール、チケット管理ツール、オンラインスケジュール、オンラインファイル共有などのツールを使いこなすことも大事。
つまり、セルフマネジメントの環境を整備するのも大事。

無理ならば、アラートをあげて他者にヘルプを求めたり、専門家に頼れるルートもいるだろう。

自分でリモートワークしていて、こういう考え方が必要だな、と色々思いつくものの、整理できていなかったので、こういう図で言語化できて、とてもありがたい。
他人に話す時にも使えるので有用と思う。

Clubhouseは路上ライブや朗読のためのツールかもしれない

Clubhouseの使い方は正直良く分かってない。
主張のないラフなメモ書き。

【参考】
Clubhouse (アプリケーション) - Wikipedia

Twitterは最速のメディア: プログラマの思索

Facebookはセルフブランディングの最強ツール: プログラマの思索

【1】Clubhouseはアプリの機能がとても貧弱過ぎる。
痒い所に手が届いていない。
3つほど不満がある。

1つ目は、興味のあるルームを探しにくい。
カテゴリ、ジャンル、タグなどで探したいのに、なかなかヒットしない。
Twitterほど検索機能は優れていない用に思える。
だから、わざわざ別サイトで、人気ランキングから類推するしか無い。

Clubhouse 人気ランキング

2つ目は、スケジュールの機能がない。
だから、よく聞き逃すし、落胆する。
ルームは突然告知される理由かもしれないが、開始、終了の時間帯をスケジュールで入れておきたい。
今は、気づいた時に探したり、ルームで予告された話を聞いた記憶を頼りにしている。
しかもリマインダー機能もないので、よく忘れる。
本来は逐一記憶したくない。
GoogleCalendarのリマインダー機能が使いたい。

さらに、聞きたいルームがバッティングしやすいので、スケジュールを入れておきたい。
2つのルームを入れ替わり聞くこともできるはず。

3つ目は、聞いた履歴が見れない。
音声を録音できない設計思想なので、それは許すが、せめて、いつどのルームを聞いたのか、ぐらいの履歴は後で見たい。
履歴を見れば、思い出に浸ったり、後から考え事もできる。

そういう感じで、アプリはとても使いにくい。

【2】Clubhouseはどんな使い道があるのか？

僕はそんな不満を感じながらも、雨降る日曜午後に、Clubhouseを聞き流しラジオみたいに使っている。
僕が興味あるのは、朗読と音楽の聞き流し。

朗読しているルームは良かった。
たまたま、芥川龍之介の杜子春を朗読していたのを聞いた。
あらすじも知っているが、アナウンサー経験のある落ち着いて、キレのある声は聞きやすい。
高校生の頃にラジオドラマを聴いていた気分になった。

また、ジャズやピアノを練習代わりに垂れ流しているルームは良かった。
月の光、を聞いた時は、心が和んだ。

何となく、大阪駅前の路上ライブの演奏を聞いている感じだった。
その場での即興であり、Youtubeで後から聞くことも見ることもできないから。

割とうまい人でも、時々間違えたのか、音が外れている時に気づくが、むしろそれが気にならなかったりする。
練習の曲を弾いた後で、ちょっとしたコメントを話すのがとてもリアルに感じたりする。

他には、有名人が入って、個別テーマで議論しているルームも面白い時もある。
一方、井戸端会議に近いので、時間の無駄だな、と思う時も多い。
他方、有名人の顔はWebで見ているし、Youtubeなどで声や動作も知っているけれど、生の声を聞くと印象が変わる。

Clubhouse以外にも、TwitterライブやVoicyなどの音声ツールで有名人の声を聞く時がある。
中嶋聡さんは、Web記事やメルマガでキレのある内容を書いていて、割と研究者みたいな人なのかな、とか思っていたら、こんなに声が低くて太くて、すごく威厳のある人だな、とか。
ちきりんさんは、ブログでは現状の社会の問題点について切れのある意見を言う人なので性格もきついのかな、と思っていたら、生の声の配信を聞くと、こんなに女性らしい声なのか、となぜか印象が変わってしまったり。

コロナ禍でリモートワークが多くなり、パソコンやスマホに触れる時間が以前よりもかなり増えてしまって、目が疲れやすいと感じる。
眼を使わずに楽に聞きたい、という気持ちが強い。
よって、Clubhouseで聞きたいと思う時がある。

【3】Clubhouseは路上ライブや朗読のためのツールかもしれない、と思う。

Youtubeで流せば、その動画は一生残るので、ストックとして扱える。
広告料ももらえるから、マネタイズもしやすい。

しかし、Clubhouseは臨場感がある。
その時だけの音声、という希少さがある。
路上ライブがそんな感じ。

その人の声が、その人の顔、性格を連想させる。
朗読では、語る声に、その文学作品に対する、その人の思い入れが伝わってくる。

コロナ禍という時代でなければ、Clubhouseは見向きもされないツールだったかもしれない。
いつでも外出して、野外コンサートで聞いたり、舞台や劇場で見れるならば、わざわざ使う必要もないから。

Clubhouseはコロナ禍という時代だけに特化したアプリのような気もする。
コロナに罹患するリスクが高ければ外出できず、部屋に閉じこもるしかない。
YoutubeやNetflixを暇な時に見ればいいかもしれないが、飽きる時もある。
部屋に閉じこもっていれば、こういうツールでラジオの聞き流しみたいに聞きたくなる。