ガイド
設計書から動くコードへ
d-bye の考え方と仕組みを、エンジニア向けに解説します。
「ちゃんと動く」AIコード生成 ― しかもコードは自分のものになる
AIアプリビルダーは速いが、生成コードは壊れがちで持ち出せないことが多い。d-bye のAIは生コードではなく構造化された設計書を書き、生成のたびに型検証＋コンパイルチェックを通す。出力は所有できる本物のソースコード一式（画面・API・DB）。
読む →社内ツールを内製（自作）する方法 ― コードは資産として残す
スプレッドシートは限界が来て、SaaS はロックインする。社内ツールの手作りは大半が反復的な CRUD です。コードを自社の資産として残しつつ、社内ツールを速く内製する方法を解説します。
読む →人手が足りなくても業務システムを内製する方法
採用できない、情シスが1人以下。それでも業務システムを内製したいチームへ。設計・開発・テストの工程をどう圧縮すれば、少人数でも内製できるのかを解説します。
読む →設計書駆動開発とは ― 先に設計し、コードを生成する
設計書駆動開発とは、設計書を主とし、そこからコードを生成する進め方です。その意味、なぜ設計書を「起点」にするのか、どうスタック全体の一貫性を保つのかを解説します。
読む →Web設計書とは？ なぜ「起点」にするのか
Web設計書は、アプリを構造化して機械可読にした記述です。d-bye が生成コードではなくWeb設計書を「起点」として扱う理由を解説します。
読む →ロックインしないノーコードとは：本物のコードを出力する意味
多くのノーコードはアプリをそのランタイムに閉じ込めます。d-bye は動くソースコード一式（画面・API・DB）を出力し、読んで・直して・どこでもデプロイできます。エンジニアにとってこの差が重要な理由を解説します。
読む →設計書から動くコードへ：d-bye の仕組み
作りたいアプリを言葉で説明し、構造化された設計書として磨き、動くアプリ（ソースコード一式：画面・API・DB）を出力する。意図からデプロイ可能なコードまでのパイプラインを解説します。
読む →稟議申請の承認フローをシステム化する ― Excelとメールの決裁から卒業する
購入・出張・契約の稟議が、メールの承認依頼とExcelの進捗管理表で回っていると、誰が止めているか見えず、ルール変更にも弱い。承認ルートをデータで解決する多段承認の仕組みに置き換える方法。
読む →在庫管理をスプレッドシートから卒業する ― 入出庫と発注を1つの仕組みで管理する
Excelの在庫表は現物と数が合わなくなりがちで、発注は別の文書で管理されて紐付かない。入出庫の実績から在庫数を算出する台帳と、ダッシュボードで解決する方法。
読む →受注・販売管理をシステム化する ― 見積から請求までを1つの仕組みで追う
受注が電話・FAXとExcelの伝票管理で回っていると、今どの段階かが電話しないと分からない。ヘッダ＋明細の伝票モデルと状態管理で、見積から請求までを一元管理する方法。
読む →お問い合わせ対応を、一人のメールボックスから解放する
お客様からの問い合わせと対応履歴が担当者個人のメールボックスに閉じていると、その人が不在・退職した瞬間に見えなくなる。問い合わせ・対応・区分を共有データとして残す仕組みに置き換える方法。
読む →案件の工数・原価・粗利をExcelから卒業する ― 入力したそばから収支が見える仕組みへ
受託・エージェンシー業で工数と経費をExcelで集計していると、案件の実際の粗利は月末の突き合わせ作業をしないと分からない。原価単価・請求単価を持つ工数台帳で、入力の時点から可視化する方法。
読む →勤怠管理をタイムカードとExcelから卒業する ― 打刻から月次集計まで1つの仕組みへ
紙のタイムカードとExcelの月次集計は、月末に誰かが転記するまでデータとして使えない。休暇申請も別の書類で管理され、勤怠記録と紐付かない。共有の打刻システムで両方を解決する方法。
読む →クライアントに渡せるコードで納品する
クライアントの業務システムがツールの中だけで完結していると、別ベンダーへの乗り換えや自社保守への切り替え時に引き継ぎが破綻する。設計書からコードを生成し、ソースコード一式をエクスポートする方法なら、そこを避けられる。
読む →業務システムを短納期でクライアント納品する
クライアントの業務システムを白紙から設計すると、案件ごとに同じような画面・データ構造・業務フローの形を毎回決め直すことになる。すでにその形をカバーしたテンプレートから始めれば、発明ではなく調整の作業になる。
読む →