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

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

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

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

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

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

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

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

デブサミ2021の感想～コミュニケーションスタイルがオフラインからオンラインに激変している

今年のデブサミはOLだったので、在宅勤務中でも、ラジオ番組みたいに流していた。
来年度以後もこういうスタイルであって欲しい。
思いつきをラフなメモ書き。

Developers Summit 2021（2021.02.18-19）

(1)動画を見るよりも、講演者の声がハッキリしているか、発言内容にキレがあるか、の方が印象の残り方がまるで違う。
最近、ClobuHouseが流行しているらしいけど、動画よりも音声の方が今後重視される気もする。

(2)沢渡さんのパネルディスカッションは聞いていてとても楽しい。

ファンを３つ作る。
技術のファン、プロダクトのファン、カルチャーのファン。
デベロッパーこそ、ファンを増やし、自己ブランディングしていくべき。

今はデベロッパーのルネサンス。
コロナ感染の現状では、アナログの環境よりもデジタルな対話が当たり前。

そして、先進的なデベロッパーが使っていたツールが当間になった。
Slack＋Zoomが一般的。
会社組織ではTeamsになるだろうか。

つまり、対面の対話が今は物理的に難しくなり、OLコミュニケーションが当たり前となった。
OLツールが使えない人は致命的。
誰とも会話できなくなる。

(3)日立の方の講演では、コロナ禍で社内・プライベートのコミュニケーションが全てデジタル化されたことにより、OSS開発者の価値が上がった、とか、コミュニティ活動の経験者がより上手く適応している、みたいな話があった。
社内の根回し、とか、顧客調整が得意であっても、今はTeamsでやり取りするしか無いから、こういうツールに慣れていないと能力を発揮できない。

一方、OSS開発者は以前から世界中の開発者とオンラインでやり取りしてきたので、何も変わらないし、彼らのやり方をSIも既存企業も真似ようとしている。
また、コミュニティ活動の経験者も、こういうツールに慣れている人も多いし、ノウハウを共有する場作りに長けているから、彼らもその能力を発揮しやすい。

今は、コミュニケーションのスタイルが完全に変わってしまった。

(4)コミュニケーションのスタイルがアナログからデジタルに変わった事態により、何が起きるのか？

年を取るほど、大企業の社内の人間関係をベースにした根回しが期待されてくるが、Teamsでしかやり取りできない現状では、全く無意味なスキルになってる。
新人の営業マンが訓練と称されて、１００枚の名刺を配って新規顧客をどぶ板で集める手法も、コロナ感染の現状では実現不可能。

オンラインのツールで他人と深く関わるやり方に早く慣れないといけない。
たぶん、多くの人が試行錯誤しながら、OLツール上で初対面の人と会った時、どうやって仲良くなって意思疎通できるようになるか、試しているはず。

(5)緊急事態宣言のもとでは、外食チェーンや居酒屋、個人料理店ですら、大人数で集まって会話することさえ禁止された。
ショッピングモールや百貨店、商店街などに行くことすら、緊急事態宣言のもとでは、ちょっとした罪悪感さえ感じさせられた。

デジタルネイティブ世代がコンシューマになって登場したら、現状のままでいると、おたくの会社の製品は買ってもらえないですよ、と言われているが、まさにそう。

オフラインで、街中でビラ配りしたり、イベントを開いて沢山の人を集める、というプロモーションは今は事実上禁止された。
つまり、今後は、オンラインのプロモーションが重要になるし、O2Oと言われるプロモーション、つまり、オンラインで集客してオフラインの店に来てもらう、というプロモーション手法がより一般的になるだろう。
以前は一部の企業しか試していなかったが、今は大企業だけでなく、中小企業や個人商店ですら、O2Oを実行しなければ生き残れないのだろう。

(6)オフラインからオンラインにコミュニケーションスタイルが激変した事態のもとで、従来の既存ビジネスをいかにIT化で売上を維持、拡大していくべきか、という問題にすり替えた。
この問題こそ、DXというのではないか。

TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか

TeamsとSlack、Zoomの違いについて、たまたま同一の日にツイートを見かけた。
TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【参考】
akipiiさんはTwitterを使っています 「TeamsとSlackの組織文化の違いが面白い。」 / Twitter

Dai Fujihara | ノーコードテスト自動化SaaS「mabl」 | アジャイルコーチさんはTwitterを使っています 「最近、Teams使うお客さんに出会うことが増えてきたけどSlackなら「やっほー」で済むのがTeamsだと「お世話になっております」になるのが面白い / Slack 対 Teams…スラックの成功がマイクロソフトのおかげというのは「見当違いで、馬鹿げている」 https://t.co/3Ds3uHAlei https://t.co/fWDPik2D1H」 / Twitter

akipiiさんはTwitterを使っています 「TeamsとSlackを使う組織文化の違いは、色んな所で話題になるね。個人的にはTeamsを使うのに慣れて割と便利だと思っていて、逆にGoogleChatやSlackは機能が限定されすぎていて痒い機能がなくて、使いにくく感じる。」 / Twitter

沢渡あまね新刊 #業務改善の問題地図 #ここアジャ #職場の科学さんはTwitterを使っています 「申し訳ないが（私の使い方に問題あるのかもしれないが）、Teamsは組織外との人たちとのコラボレーションまだまだしにくい。特に、私のように複数の組織に属する人間の場合、「顔」を切り替える必要があるのだがそれが出来ない（？）。『役割切替』機能欲しい。パラレルキャリアへの対応、プリーズ。」 / Twitter

コミュニティ活動では、SlackとZoomを一般に使っている。
オンラインの勉強会、打合せ、イベントは、今までの経験ではZoomだけだった。
Slackも、コミュニティの時系列チャットみたいに使っている。

特に、Zoomは日々Updateしている感じで、ブレイクアウトルームやいろんな機能が使えるようになっているので、使っていて楽しい。
音声もクリアだし、利用しているだけなら支障はない。

一方、Teamsは会社の業務で使うのが一般的。
Office365を採用している企業であれば、Teamsがそのまま付属してくるので、そこから使ってくるのではないか。
Teamsの使い心地は割と良い。

チャットはSlackみたいに普通にできるし、Zoomみたいにテレビ会議も普通にできるし、Sharepointもバンドルされているので、Excelやパワポも普通に開いて保存もできる。
OutlookもTeamsの一機能になっているので、予定表でカレンダーを見れるし、Plannerも使えば、タスクかんばんみたいなタスク管理もできる。
一昔前のMicrosoft製品のように、ゴチャゴチャした感じではなく、今風なUIなので便利だと思っている。

しかし、Teamsのせいなのかどうか分からないが、@daipresentsさんの指摘の通り、Teamsではチャットに敬語を使う。
業務で使っているせいかもしれないが、そういう組織文化が出てくるのかもしれない。

また、@amane_sawatariさんの指摘通り、Teamsでは組織というグループ管理が強固なので、グループ外の人は入れない。
会社の業務のように、内部統制やIT全般統制、情報セキュリティを厳しく管理する場合はそういう使い方が必要なのかもしれないが、縦割り文化を助長している面もある。

ツールの機能の違いが組織文化を助長しているのかもしれないし、逆に、組織文化が、組織に合った機能を持つツールを選択しているのかもしれない。
いくら優れているツールであっても、ツールの利用者が使いこなせなければ意味がないから。

トランザクティブ・メモリーを使え～「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog

【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか？

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意＝クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか？

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

信頼度成長曲線の落とし穴

@MadoWindaheadさんの信頼度成長曲線の記事を読み直して、色々感じたことがあったのでメモ。

【参考】
信頼度成長曲線を語る夕べに参加 | マドびっ！ Madosan's View

信頼度成長曲線については、過去に、SRATSのようなツールを試していた時もあって、色々考えていた。
個人的には、信頼度成長曲線は品質管理の中で華のような技術の印象を持っていた。
なぜなら、その他の品質管理の技法よりも、見た目は美しいが実際の中身は統計処理が含まれて割と複雑なので、研究するのにお手頃だから。

また、テストの収束傾向やテストの終了条件の判定に最終的に使うので、リリース判定というタイミングで使われるから、品質管理の中ではかなり重要な位置を占める。

いつテストを終わらせるか？: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

アジャイル開発はメトリクスが取りやすい: プログラマの思索

忘れ去られた日本のIT技術～DOAと品質管理: プログラマの思索

しかし、上記の記事の書いてある通り、信頼度成長曲線は前提条件がある。
前提条件とは「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」こと。

信頼度成長曲線は別名、バグ収束曲線でもあるから、バグの発生傾向やバグの発生頻度が重要な観点になる。

僕の理解では、信頼度成長曲線の前提では、テスト作業プロセスそのものにバラツキはないと想定する。
つまり、「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」。

一方、システムの機能に依存したバグ数にばらつきがあっても良い。
実際、システムの機能に関係なくバグが機能毎に全て一定の割合で埋め込まれていたら、S字型曲線にはならず、直線になるはずだから。

具体的には、システムテストでバグ出ししていくと、最初はテストは順調に進んでバグもあまり出ないが、途中からバグが出る機能にぶち当たって、大量のバグを検出するフェーズになる。
そして、何とかバグを全て解決して、最後は、全ての機能をテストし終える頃には、潜在バグも残存バグも抽出しきって、バグも収束傾向になって落ち着く、というイメージ。
すなわち、バグ収束曲線はS字型曲線、イメージとしてはロジスティック曲線みたいな感じになる。

そういう経験則が成り立つ状況であれば、開発規模や過去のバグ密度の経験値、システム特性などを元に、信頼度成長曲線の予定曲線をゴンペルツ曲線とか、S字型曲線に似た曲線で予定しておく。
そして、システムテストでのバグ管理の実績を取ることで、信頼度成長曲線の予実管理を行って、バグの収束傾向を見て、残存バグが出し尽くしたか否か、を判定するわけだ。

しかし、実際のシステム開発の経験では、そもそもバグ累積件数はS字型にならない。
むしろ、一直線に発散する感じの場合が多い。
特に新規加入した開発者が多いチーム、過去のシステム保守の経験がないチーム、新しい技術を使った案件などでは、試行錯誤して、ハンドルが荒れた車の運転みたいな感じになるから。

また、横軸にテスト実施日を取ると、テストしない日とか、テストケースの実績が少なければ、信頼度成長曲線は自然に横向きになるが、それはバグが収束した傾向を示すとは限らない。
横軸には、テスト工数を引くとか、テスト作業そのもののバラツキをなくすように、正規化する必要がある。

こういう処理をExcelでやるのはとても面倒。
信頼度成長曲線はBTSがあればデータをExcelにプロットするだけで実現できるのがメリットの一つだが、実際に正確なグラフを描き出すのは面倒。

結局、信頼度成長曲線にせよ、ソフトウェアメトリクスは、安定したプロセスで初めて有意義な意味を持つ。
そういう意味では、一発限りの請負型案件ではとても使いづらい。

Redmineのようなチケット管理ツールは、最終的にはソフトウェアメトリクスを集計・出力するプロセス基盤であると僕は思っている。
しかし、安定したチームで長期間活動するのは、日本のSIではとても実現が難しいので、ソフトウェアメトリクスを効果的に使えた経験は正直少ない。
パッケージ製品の自社開発、長期間の自社の基幹システム保守のように、長期間のPJでは当てはめやすいかもしれない。