けけずん積読消化記録

1.1

• P.5 帳簿の説明わかりやすい
• P.6 SoR、記録のシステム。基幹系システムは記録自体が目的ではなく、活動を的確に指示・制御する手段として記録を用いている

1.2

• P.13 データモデリングにおいてリバースエンジニアリング的整理はある程度で打ち止めにして、今後の事業活動のために帳簿をどのように仕組むかという工夫、帳簿デザインに目を向けることが重要

1.3

• P.16 異なるソフトウェアを組み合わせながらユーザ視点に立って整合性ある帳簿システムをデザインするデータモデリングの素養が重要になる

2.1

• P.23 関心の分離。内容と表現の分離、意思決定と実行の分離、仕様と実装の分離
• P.24 「分離できる」は、どちらか一方に関心を持っていれば十分という意味ではなく、それぞれを別の知的関心事として分析し検討することができるという意味

2.2

• P.25 業務機能と機能別組織。業務プロセスは業務機能を横断する。
• P.27 基幹系業務が第一に追求すべきは、現場の活動自体の改善や効率化ではなく、さまざまな現場活動をどのように調整すれば事業活動として調和がとれ、最高のパフォーマンスを発揮できるか、という点
• P.28 ある特定の残の発生消滅まで管理する仕事というくくりが、SoAの業務機能の最小単位
• P.29 伝統的な基幹系システムは自主財産が主な管理対象。新たなビジネスでは、自主財産ではない残を的確に管理することが焦点となる（クリーニングサービスの場合、配送の状態など）
• P.30 責任区分が明確なため、残視点（業務機能）での分割をし、処理の流れに沿って統合するのが合理

2.3

• P.33 仕入れ単価を決めるルールを会計基準と呼ぶ
• P.34 情報システムの設計において、異なる要因で変化する仕様、安定的な仕様と不安定な仕様は切り離すべき
• P.34 SoA業務の遂行に際して判定が必要になるルール = ビジネスルール

2.4

• P.38 基幹系システムは事業組織のためのシステムであって、ここのユーザを支援してるわけではない。SoEはその点を補完するシステム
• P.39 ひとつのシステムが、SoA/SoM的な基本性格と、SoE的な特性を併せ持つことはあり得る

2.5

• P.43 業務責任の線引き重視と効率重視。これらの文化の違いが基幹系システムの根本に横たわる

2.6

• 伝統的なビジネスにおいても、求められるのは技術をテコに新しい業務のあり方を生み出すことで、古いままの業務モデルに新しい技術を適用することではない

3.1

• P.49 帳簿デザインの手法は3つあり、UI設計を通じた手法、DB設計を通じた手法、データモデルを用いた手法
• P.53 データモデリング、すなわちデータモデルの設計は「外部設計」。UIや処理機能はそれに依存する
• P.56 残に対する管理責任の所在の明確化と、残管理にまつわる業務要件は業務プロセスとそれに依存するユースケースより安定的、というのが残を中心に帳簿をデザインする根拠

3.3

• P.59 受注データと得意先データを結びつけるために、得意先コードを用いるか得意先IDを用いるかは技術的関心事であり、データモデルが扱うべき問題ではない

3.4

• P.63 データモデリングは、UI設計やDB設計に紛れてしまうと輪郭がぼやけがちな、より基本的で枝葉を払った帳簿システム

4.1

• P.67 アジャイル開発手法のバックログアイテムもいわゆる残であり、バックログは残を管理する帳簿
• P.68 残は活動と活動の間に置かれたバッファー

4.2

• P.68 基幹系業務の活動フローとてもわかりやすい
• P.70 業務を駆動する残、残を発生させるイベント、残を解消するイベント、この3つの組がデータモデルの核心
• P71 解消イベントを発生イベントに紐付けることを消し込みと呼ぶ。残が確実に処理されたことを立証し、処理の重複を防ぐための重要なテクニック
• P.71 発生イベントは取引先や他の担当に対する約束。相手との約束内容（5W1H）を表す項目を過不足なく保持すべき
• P.72 業務のあり方を踏まえて各項目の要否や別のデータ項目での代替を検討し、項目を決定することがデータモデリング
• P.75 データモデルは、ビジネスを制御するための帳簿の構造であり、実世界を写しとる解像度が高ければ高いほどよいというわけではない

4.3

• P.78 残の管理方式
  • 件別残管理は件別に消し込みが完了し残が解消する方式で、売掛金や手形など
  • 継続残管理は残が消し込みされず増減しながら持続する方式で、当座預金や普通預金、在庫など
• P.79 理論残と実残
  • 理論残は帳簿上はこれだけはあるはずという残
  • 実残は倉庫などにある現物を実際にカウントして把握した残
• P.80 帳簿による制御をうまく機能させるには、理論残と実残を一致させることが重要

4.4

• P.85 基幹系システムでは、正常ケースで、処理されている限り何も問題ないが、イレギュラーが生じると対応が難しいという話がよくある。これは履歴の不備が隠れている場合が多い
• P.90 残という概念は、伝統的ビジネスと新ビジネスに通底する共通項となり得る
• P.90 ビジネス活動に参加するプレイヤーを識別し、プレイヤーいずれか二者の間での業務依頼とその遂行という関係を識別していけば、そこに必ず業務の残がある。残を見つけたら、その発生と解消はどう起きるのかを検討すればよい
• P.90 残の発生と解消という視点は、ビジネスにおける責任分担と、責任分担を支えるために必要な帳簿のデザインに示唆を与えてくれる

4.6

• P.94 従来のデータモデリングではイベントとリソースという二分法を手がかりとすることが多かった
• P.94 残志向のデータモデルでは、残の発生と解消はイベント
• P.95 SoAの領域でデータモデルを検討するときには、まずはリソースデータの存在を前提とせず、業務を完結させるためにはどんなデータが必要か考える
  • 表4-6-1の観点は参考になる
• P.95 リソースの各項目の必要性はリソース自体に内在するわけではなく、個々の業務のニーズから決まってくる

5.1

• P.99 SoMの三階層
  • 上位層 財務的な計画管理
  • 中位層 業務分野別の計画管理
  • 下位層 現場に近い計画管理

5.2

• 上位層
  • 財務的な観点に軸足を起き、ビジネス全体の活動の総合的な調整を担う
  • 主眼はカネ
  • 責務は企業全体の活動の調整と資源配分
• 中位層
  • ステークホルダーに対する活動報告と、修正行動を促す
  • 主眼はモノやヒト