技術戦略
哲学は判断の軸、事業はそれを形にする箱。
技術は、事業を成立させ、敗けぬ構造で価値を届け続けるための道具です。
DataLinerにおける技術戦略の位置づけ
「敗けぬ構造」とは、判断と配分が壊れず、退場せずに運び続けられる状態です。
技術戦略は、その状態を現実の制約下で成立させ続けるための実装として位置づけます。
技術戦略は、事業戦略を具現化する役割を担う
技術戦略は、技術を選ぶための方針ではありません。
事業戦略で定めた判断と配分を、
現実の制約の中で成立させ続けるための設計です。
何を作れるかではなく、どうすれば壊さずに運び続けられるか。
その問いに答えるのが、DataLinerにおける技術戦略の役割です。
技術は、事業を成立させ続けるための道具である
技術は、目的ではありません。
事業が一度成立することではなく、
成立し続けることを支えるための道具です。
DataLinerでは、事業の判断や配分を壊さずに運び続けるために、
技術を「使うもの」ではなく、「支えるもの」として位置づけています。
この役割から、技術に課す条件が決まる
技術戦略の役割を「事業戦略の具現化」と定める以上、
技術選定は好みや流行で行うものではありません。
運び続けること、壊さないこと、撤退できること。
その役割を果たすために、技術には満たすべき条件が生まれます。
技術戦略の基本原則（判断の軸）
採用技術は目的ではなく、事業を壊さず運ぶための選択の結果です。
DataLinerにおいてその選択を導くための判断の軸を本セクションで明らかにします。
運用が壊れない（運用までを責任範囲とする）
DataLinerでは、実装して動くことをゴールとは考えません。
実際の運用の中で、負荷や変更が重なっても、
判断と配分が壊れずに運び続けられることを重視します。
そのため、運用・変更・障害対応まで含めて扱えない技術は選びません。
変更に耐える（前提の変化を織り込む）
DataLinerでは、事業の前提は運用の途中で変化すると捉えています。
前提が変わっても、判断と配分を保ったまま構造を更新できることを
重視します。
変更に耐えない技術は、事業の持続性を静かに削っていきます。
撤退できる（判断を固定化しない）
DataLinerでは、始めることと同じくらい、撤退できることを重視します。
前提や配分が合わなくなったとき、
判断を技術的な制約で縛られない構造を選びません。
撤退できるとは、失敗を前提にすることではなく、
判断を最後まで自分たちの手に残しておくことだと考えています。
可観測である（原因と影響を追跡できる）
DataLinerでは、「何が起きているか分からない」状態を
運用上の大きなリスクだと考えます。
障害や性能、コストの変化を後から追跡できることを前提にします。
可観測であるとは、
運用の失敗を判断の材料に変換できる状態を保つことだと考えています。
生成と配布の経路を把握できる
DataLinerでは、仕組みがどこで生成され、
どの経路を通ってユーザーに届けられるかを重視します。
その流れを追えず、制御が難しい構造は選定しません。
経路を把握できることは、技術の安全性ではなく、
判断の自律性を守る条件と考えています。
小さく強く始められる（初期配分を壊さない）
DataLinerでは、最初から大きな構成や完成形を前提にしません。
初期段階は、仮説検証・運用・修正を無理なく回せる大きさで始めます。
小さく始められることは、
撤退・変更・継続すべての自由度を残すための前提条件と考えています。
選定の方法（どう決めるか）
導入コストや流行ではなく、運用と失敗の形を先に見ることから判断します。
判断がブレないよう、DataLinerでは「決め方」そのものを固定します。
先に“使わないもの”を決める
DataLinerでは、何を採用するかよりも、何を採用しないかを先に決めます。
短期的に便利でも、運用・変更・撤退の自由度を下げる技術は除外します。
やらない選択を固定することで、
判断が状況や感情に流されることを防ぎます。
PoCではなく“運用”で評価する
DataLinerでは、動くかどうかよりも、
運用し続けられるかを評価基準に置きます。
検証段階での成功は、
本番運用における安定性や判断のしやすさを保証しません。
PoCでの見え方よりも、運用で判断を歪めないかを重視します。
変更・移行のコストを見積もる
どの技術も、いつかは前提が変わります。
そのとき、どれだけのコストで変更・移行できるかを事前に見積もります。
移行が困難であることは、
技術的な問題ではなく、判断の自由度を奪う構造です。
DataLinerでは、始めるときと同じ重さで、終わらせられるかを問い続けます。
依存関係の前提を点検する（供給元リスクを織り込む）
DataLinerでは、技術そのものだけでなく、
供給元や依存関係も判断の対象に含めます。
依存関係は、将来の選択肢を狭めないかという観点で評価します。
切り離しが困難な構造は、判断の自由度を下げます。
セキュリティは“面”で見る（アタックサーフェース最小化）
セキュリティを単体の対策としては捉えず、
攻撃対象になりにくい構造になっているかを重視します。
目的は防御の強さではなく、
運用と判断を壊さない状態を保つことです。
現在の技術スタック（一例）
以下は、DataLinerが現在進行形で運用している技術スタックの一例です。
前段で示した判断の軸に照らし、現時点の前提と制約のもとで選ばれている実装例です。
将来や案件によって構成が変わることも前提にしています。
フロントエンド：Astro + React（Islands）
役割：静的生成を前提に、必要な箇所だけを動的に構成します。
判断軸との対応
- 実行面を最小化できる
- 配信構造が単純になる
- 変更・撤退の自由度を保ちやすい
ホスティング / 配信：AWS Amplify
役割：実行環境を持たず、生成物を配信する構造を採用しています。
判断軸との対応
- アタックサーフェスを小さくできる
- 運用負荷を構造的に抑えられる
- 小さく始め、必要に応じて拡張できる
Infrastructure as Code：Pulumi
役割：インフラ構成をコードとして管理し、変更の履歴と意図を残します。
判断軸との対応
- 変更が属人化しにくい
- 構成の差分を追跡できる
- 撤退・再構築の判断がしやすい
CI / CD：GitHub Actions
役割：生成から配信までの経路を自動化し、判断をコードに落とします。
判断軸との対応
- 生成と配布の経路を把握できる
- 権限を最小化できる
- 手作業による判断の歪みを減らせる
CMS：microCMS（ヘッドレスCMS）
役割：コンテンツと配信を分離し、責務を明確にします。
判断軸との対応
- 編集と配信の独立性を保てる
- 撤退・移行の判断がしやすい
- 運用を壊さずに改善を続けられる
セキュリティ：Trivy、GitGuardian 等
役割：供給経路とリポジトリ内の状態を点検し、脆弱性や資格情報の混入を早期に検知します。
判断軸との対応
- 可観測である
- 生成と配布の経路を把握できる
- 運用が壊れない
生成AI：ChatGPT / GitHub Copilot
役割： 思考・設計・実装・文章化を補助し、判断と作業の摩耗を減らします。
判断軸との対応
- 運用が壊れない
- 変更に耐える
- 可観測である
このスタックが事業戦略をどう支えるか
配分と順序、そして退場しない構造。事業戦略で定めた要件は、技術選定の中にそのまま落とし込まれています。
ここでは、選んだ技術スタックがどのように事業戦略を壊さず支えているかを示します。
壊れない運び方を成立させる
SSGを前提とし、実行面を極力持たない構成を選ぶことで、
運用中の負荷や不確実性を構造的に減らしています。
障害や性能劣化が事業判断に直結しにくい構造は、
短期的な成果よりも、退場しない運び方を優先する事業戦略と一致します。
攻めることよりも、壊れにくく続けられることを優先した選択です。
配分が崩れない状態を保つ
CI/CDやIaCにより、変更や修正にかかるコストと判断負荷を固定化しています。
人の手に依存した運用は、いつの間にか配分を歪め、戦略の前提を崩します。
変更を“特別な判断”にしないことで、
配分と順序を保ったまま改善を重ねられる状態をつくっています。
判断から逃げないための可視性を持つ
生成から配布までの経路や構成差分、
運用時の挙動を追跡できる状態を前提にします。
問題が起きたときに「なぜそうなったか」を説明できることが、
事業判断の自律性を守る条件です。
運用の中で思想が壊れない設計
CMS・配信・実行を分離し、責務を明確にすることで、
運用の都合が思想を侵食することを防ぎます。
属人的な調整に依存せず、
構造として判断を守り続けられる設計を採っています。
この技術戦略が成立するためのガードレール
外部制約の中で進める局面があることは前提にしています。
それでも、判断と運用の責任を曖昧にしないための境界だけは明確にします。
画面操作を中心に構築・運用したい場合
DataLinerの技術戦略に基づく構成では、変更や公開はGitを起点に管理します。
画面上の直接編集と即時反映を最優先にする運用とは前提が一致しません。
目的は編集自由度ではなく、判断の履歴と配布経路を保持することです。
意思決定を外部に委ねたい場合
技術選定や構成は、DataLiner側で判断し、その結果を引き受けます。
ただし、前提・制約・優先順位の合意がないまま、
一任と結果だけを求める形とは一致しません。
判断の責任が宙に浮かないことを、この戦略の前提とします。
短期的な量産や拡大を最優先したい場合
DataLinerの技術戦略に基づく構成は、
短期間での量産やスケールを最優先に設計されていません。
配分と順序を保ちながら進めるため、速度や規模を犠牲にする局面もあります。
短期成果を最大化する戦略とは、前提が異なります。
運用を持たず、作って終わりたい場合
実装された仕組みが、運用の中でどう振る舞うかまでを責任範囲とします。
作って終わる、納品して完了する前提とは一致しません。
運用を含めて判断を続けることが、この技術戦略の前提です。
哲学・戦略・技術を切り離さない
技術は、判断を実装するためのものと考えております。
実装と運用の結果を受けて、戦略と判断の軸を点検し続けます。
技術は、判断を実装する
技術は、思想を飾るためのものではありません。
哲学で定めた判断の軸を、運用できる形へ落とし込むための実装です。
選ぶ技術は結果であり、守りたいのは、事業の配分と順序が壊れないことです。
運用は、戦略を検証する
運用は、保守作業ではありません。
戦略が現実の制約の中で成立しているかを確かめる検証です。
運用で起きた歪みや摩耗は、
判断の材料として回収し、配分と順序へ反映します。
事業は、結果として現れる
事業は目的ではなく、哲学と戦略に基づく判断の積み重ねの結果です。
成果は追い求めるものではなく、構造の結果として受け取るものと考えます。
だからこそ、技術もまた、事業を壊さず運び続けるための道具として扱います。