一人社長の「裏方」業務日誌
きれいなDX論よりも、明日使える泥臭い工夫を。タスクの「管理」と「圧縮」に向き合う中で見つけた、気づきや技術メモを更新しています。
-
複雑なAIシステムを削ぎ落としたら、むしろ強くなった。Notion特化で見えたシンプル設計の威力
Twitterで見た全保存型システム、別の人のNotion AIシステム、スタッフDB…試行錯誤の末に辿り着いたのは「極限まで削る」設計。シンプルにしたら反応も精度も上がった理由とは。
READ → -
在庫管理、紙からデータへ。「完璧な仕組み」より「今日から回る仕組み」を選んだ理由
在庫管理をもっと精密にやろうと思えば、画像認識やQRコードで構築できる。でも、現場で今すぐ回せる形を作るなら、写真を撮るだけで在庫切れリストが出力される仕組みの方が早い。Dify×GASで作った在庫管理自動化の設計思想。
READ → -
最初から100点は目指さない。システムを50点で作って、実践しながら育てる理由
ブログ記事を1本書くのに3日かけていた頃がある。完璧を目指すほど、時間がかかり、需要があるかも分からない。システムも同じだ。50点で作って、すぐに使い始める。実践しながら60点、70点、80点に育てていく。完璧主義より、実践主義。
READ → -
研修の本題に入る前に、半分が脱落する。AI研修で見えた「ツールの壁」
AI研修を運営していて気づいたことがある。技術的な内容を教える前に、マイク設定や画面共有、資料の場所といった「ツールの基本操作」で時間を取られ、本題に入る前に参加者の半数が疲弊している。研修を企画するなら、技術以前の壁を下げる工夫が必要だ。
READ → -
「月8万文字」を回すライターが、スプレッドシートを手放した理由
月6〜8万文字の執筆業務を、外部委託で作ったスプレッドシートで管理していた。文字数カウントは手作業、請求書は別フォルダ、仲介サイトごとの手数料計算も手入力。GASと関数を組み合わせた複雑な構造で、本人も修正できない状態に。2度目の改修依頼を機に、Notionへの移行を提案した記録。
READ → -
「OCR代行、高すぎる」を解決した話。AIツール3つを比較検証した記録
物理の問題集105ページをデジタル化したい。OCR代行の見積もりは高額だった。そこで、既に契約していたAIツールを活用する方向に切り替え。GenSpark、Gemini、NotebookLMを比較検証。プロンプト最適化と裁断機の活用で、精度を高める設計を提案した記録。
READ → -
「まず、誰が何を見るかを決めましょう」。Notion構築で、最初に確認すること
Notion導入支援の現場で、最初に確認したこと。担当者AとBでは、業務内容が違う。見るべき情報も違う。だから、全員に同じ画面を見せる必要はない。構築前に「誰が何を見るか」を決めることで、後から迷わない構造が生まれる。
READ → -
80%の精度で十分だった。趣味の売買管理で学んだ「スピード重視」のAI設計
趣味の購入・売買管理をAIで効率化した結果、全自動化から必要最小限の半自動化に舵を切った経緯。請求書処理の事例も交えながら、スピード重視で小さく始める設計思想を解説します。
READ → -
1週間で7つのシステムを作った。効率化狂いの私が、人生で一番楽しい理由
2026年のある1週間、Chrome拡張、メルカリシステム、SNS投稿システムなど、7つの自動化プロジェクトに没頭した。深夜2時まで作業しても苦痛じゃない。効率化を「悪」とされた過去から、今は好きなだけやれる環境へ。時間が遅く感じる理由を語ります。
READ → -
「誰も触れないシステム」の末路。完全自動化より大切なメンテナンス設計
複雑なマクロと関数で構築された「ブラックボックス化」したシステムは、誰も触れない負債になる。完全自動化を目指すより、メンテナンス可能性を重視した設計の重要性を実例から解説します。
READ →