すべてのブログから「#システム開発」タグの検索結果

1) Web アプリケーションのテストには、Web サイトを公開する前にその妥当性や機能性を検証するための様々な種類があります。テストを実施する担当者は、その種類を把握した上で、当該Webサイトに最適なものを選択する必要があります。本記事では、Webアプリケーションテストの種類とそれぞれのメリット・デメリットの概要を説明します。2) ユニットテストは、Webサイトで最初に行われるべきテストのタイプです。このテストは、個々の関数やメソッドのような、コードの個々のユニットに対して行われます。ユニットテストの目的は、コードの個々のユニットでバグを見つけることです。ユニットテストは通常、コードがメインコードベースに統合される前に、開発者によって行われます。3）統合テストは、Webサイト上で行われるべきテストの第二のタイプです。このテストは、コードの結合されたユニットに対して行われ、それらが意図したとおりに一緒に動作するかどうかをチェックするために行われます。統合テストの目的は、異なるコードのユニット間の相互作用のバグを見つけることです。統合テストは通常、コードがメインコードベースに統合された後、開発者によって行われます。4）システムテストは、Webサイト上で行われるべきテストの第三のタイプです。このテストは、システム全体に対して行われ、意図したとおりに動作するかどうかをチェックします。システムテストの目的は、システムの異なる部分間の相互作用のバグを見つけることです。システムテストは、通常、コードがメインコードベースに統合された後に、テスターによって行われます。5）ユーザー受入テストは、

Accessで作成したロケーション管理ツールです。Accessには見えないと評判です。ちょっと見づらいですが真ん中に入力用のテキストボックスがあります。それだけです。商品コードをバーコードリーダーでスキャンすると、ロケーション（商品を保管している棚の番地）が判明します。ここで棚のロケーションバーコードをピッとスキャンすると番地を変更できます。それだけです。タブレットで使用する場合は、右上の電卓アイコンを押すとこのように切り替わります。ロケーションを登録、確認するためのツール。それだけなのでこのようなインターフェイスになります。システムらしい見た目は必要ありません。システム屋などをやっていると忘れがちになるのですが、キーボード入力は人差し指二本で、という方もかなりいらっしゃいます。そういう方の場合、いろいろ画面に表示されているだけで「わからない」となります。マニュアルを読め、という話ではもちろんありませんね。なにもできないシステムであれば、使用者はなにもしなくて済みます（理想的！）。しかしそれでは意味がないのでなんらかの目的のためになんらかの操作を要求します。選択肢が1個だったら、それをやるより他ありません。こちらのツール、パートさんに使い方を説明したのは1分。その後の質問もなくさくさく利用していただいております（いまもたぶん）。もう一つのユーザビリティー。検索結果画面にスピーカーアイコンがありますね。ロケーションを登録・変更できなかった、ヘンなコードをまちがって打った、などの場合は音で知らせます。実際使用してみるとわかることなのですが、ロケーションに貼りつけたバーコード（本棚の

こんにちは。 小規模事業・個人事業主に向けたITサービス利用のご支援をしています！ ITコーディネータさとよです。システムを構築する際に要件定義フェーズというのがあります。このフェーズは突き詰めれば実に難しく、数々の失敗プロジェクトの原因を生み出す根源となっています。まず、一人で開発するシステムづくりについてはこのようなことはないと思います。自分でどんな要件が必要なシステムかを自分で考えて構築する点で齟齬が生まれる余地がないからです。問題が発生するのは構築を担当する受注者側と発注側のユーザが分かれるときに発生します。その発生する問題が、要件定義の見方が一緒ではないということに起因します。要件定義の認識相違はなぜ生まれるのかどういうことかというと、SEはモノづくりを考えるので、システムにどのような機能を持たせるかというのを考えます。どのような技術でどのような機能を実装させるかを考えます。システムに必要な要件は全部ユーザが提示するべきと考えています。どのような機能を盛り込むかで見積もりを行います。一方ユーザは業務からシステムを考えています。自分たちの業務に必要な要件を出していきます。細かいことはSEさんが汲んでくれると思って、具体的に提示しないことも多いです。ベテランSEであればそんなことは百も承知で、具体的な要件を確認してくれるSEもいます。しかし、やはり業務を行っていない分多少の漏れが発生してしまうこともあります。本来であれば、業務要件からシステム要件を抽出して構築するための要件定義をまとめていきます。一般的に要件定義フェーズというのは本来構築サイドで仕上げるというよりは、ユー

はじめに皆さんも使っているかもしれませんが・・・最近、WordPressでWebページを作成しているときに気づいてしまいました。Web制作会社でエンジニアをしている者です。日々、クライアント向けにWordPressサイトの構築・カスタマイズを行っています。今回は、新規案件のたびに発生していた「環境構築の手間」を、バックアッププラグインの使い方を工夫することで大きく減らせた話を書きます。抱えていた課題新しいWordPress案件が始まるたびに、以下を毎回ゼロから行っていました。・必要なプラグインの選定・インストール・投稿用カスタムフィールド(ACF)の項目をイチから記述・カスタム投稿タイプの登録コードの再作成案件の性質が近くても、これらを都度手作業でやり直していたため、環境構築だけで半日〜1日かかることが常態化していました。制作そのものより前段の準備に時間を取られてしまうのが悩みでした。こだわりポイント今回意識したのは「データベースは含めない」という点です。過去案件の投稿データや設定値をそのまま新規サイトに持ち込むのではなく、プラグイン構成・テーマ・投稿タイプ定義・カスタムフィールド設定といった「仕組み」の部分だけを再利用できる形にしたい、という狙いがありました。やったこと① WPvivid Backup Pluginでのファイル書き出しデータベースを含めない設定でバックアップを取得。これにより、プラグイン一式・テーマ・カスタム投稿タイプ定義・ACFの設定など、「仕組み」に関わるファイルだけを持ち出せます。② 新規WordPressへのリストア同じくWPvividのリストア機能を

はじめまして システムエンジニアのCLOVERと申します。 現在、事業者向けのオリジナルの業務システム開発や、 業務システム（予約管理システム等）のパッケージを自ら開発し、導入・保守をしています。 システム開発・導入において、すべての工程を1人でできますが、どのような経歴でここまでになれたかを少し紹介したいと思います。 大学卒業後の経歴を簡単にまとめてみました。 ―――――― 【１】＜2年間ほど＞ 大手通信系のIT企業で、一通りのシステム開発（要件定義、設計、実装、試験、リリース、保守）を経験 【２】＜5年間ほど＞ 地方のIT企業で、より幅広い範囲のシステム開発（見積、進捗管理、設計、製造、試験、運用）を経験し プロジェクトマネージャーや複数プロジェクトの管理も担当 【３】＜2年間ほど＞ 社内システムがない建設系の会社に入り、1人で社内システムの要望ヒアリング、企画、設計、開発、導入、サポートを実施 【４】＜4年間ほど＞ 事業者のオリジナル業務システム開発や、業務システム（予約管理システム等）のパッケージを自ら開発し、導入・保守 ―――――― 社会人になるまでは、プログラミング経験があったわけでもなく、PCに特別詳しいとも言えない単なる若者でした。 そんな状態から就職し、社会とプロジェクトの波に揉まれつつ、おそらく社会人5～6年目あたりにようやく1人でもシステム開発ができるかなという技術がついたような気がします。 それまでの期間は仕事から帰っても、資格の勉強や、技術関連の本を読んだり、自分のPCでコードを書いたりなど、自己研磨に励んでいた気がします。大変すぎて記憶があいまいです

ある日、妻から何気なく、「会社からこんなメール来たよ」と、スマホを見せられました。内容は、地震発生時の安否確認メール。「地震が発生しました。あなたの安否状況を回答してください」そんな感じのメールでした。そのときは、「へぇ、こういう仕組みがあるんだ」くらいにしか思っていませんでした。でも、しばらくしてふと思ったんです。これ、自分でも作れるんじゃない？ここから、今回の安否確認システム作りが始まりました。まずはGoogleフォームでいいんじゃない？最初に考えたのは、とても単純でした。安否確認って、「無事です」「負傷しています」「連絡がつきません」みたいな回答を集めるだけなら、Googleフォームでできるんじゃないか？回答結果はスプレッドシートに自動で入る。じゃあ、Googleフォーム＋スプレッドシート＋GASでいけるのでは？ということで、さっそく作り始めました。……ところが、ここからが長かった。「地震が起きたらメールを送る」って意外と難しい安否確認の肝は、地震が起きたら自動的にメールを送ること。これができなければ、ただの「Googleフォーム」です。そこで、気象庁の地震情報を取得して、「一定以上の地震が発生したら安否確認を開始する」という仕組みに挑戦しました。気象庁の公開データを取得して、地震情報を読み込んで、震度を判定して、条件に当てはまったらメールを送る。文字にすると簡単そうです。でも実際にやってみると、「これ、ちゃんと動いてるのか？」「同じ地震で何回もメール送られない？」「設定を間違えたらどうなる？」「社員が100人いたらどうする？」……と、次から次へと疑問が出てきます。プログ

「こんなシステムがあったら、もっと仕事が楽になるのに」仕事をしていると、そんなことを思う場面はありませんか？毎回同じ内容をExcelに入力している。紙とExcelを見比べながら転記している。何人ものスタッフが同じ情報を別々に管理している。予約や顧客情報の管理が大変になってきた。「これ、システムにできないかな？」そう思っても、次に困るのが、「でも、誰に何を頼めばいいんだろう？」ということです。専門的なことが分からなくても大丈夫システム会社に相談するなら、「仕様書を作らないといけない？」「どんな機能が必要か全部決めないといけない？」「データベースとかサーバーとか聞かれても分からない……」そんな不安を感じる方もいると思います。でも最初から専門的な説明ができる必要はありません。まず必要なのは、「今、何に困っているのか」を整理することだと思います。たとえば、「毎月この作業に3時間かかっている」「同じ内容を何度も入力している」「担当者によってやり方が違う」「入力ミスが多くて確認が大変」こうした普段の言葉の中に、システム化を考えるための大切な情報があります。そもそも、本当にシステムを作る必要がある？ここでもう一つ考えておきたいことがあります。それは、「新しいシステムを作ることが、本当に一番いい方法なのか？」ということです。新しく開発すれば、当然コストがかかります。もしかすると、すでにあるサービスを使えば十分かもしれません。今使っているExcelを少し改善するだけで解決するかもしれません。仕事の流れそのものを少し変えれば、システムを作らなくても済むかもしれません。逆に、毎月たくさんの時間を手作

概要AI受託開発の費用相場は、PoCで数十万〜300万円、中規模システムで300万〜1,000万円が一般的。でも2026年、AIを使った開発なら25万円〜・最短2〜4週間で"いきなり商用レベル"が作れる時代になりました。ただし「安いから」で選ぶと本番で苦労します。この記事では費用相場・なぜ安くなったのか・失敗しないAI開発会社の選び方を、自社でSaaSを運用する立場から正直に解説します。「AIを活用した業務システムを作りたいが、費用がどのくらいかかるのか、どの会社に依頼すべきか分からない」── 近年、こうしたご相談が急速に増えています。本記事では、AI受託開発の費用相場と、開発会社を選ぶ際の判断基準を整理してお伝えします。AI受託開発の費用相場【2026年・規模別】AI受託開発の費用は、開発するシステムの難易度、対象業務の範囲、既存システムとの連携の有無によって大きく変動します。一般的な目安は以下の通りです。PoC（概念実証）：数十万円〜300万円中規模のAIシステム・業務システム：300万円〜1,000万円全社導入を前提とした大規模開発：1,000万円以上これらは、従来型の開発を前提とした相場です。多くの比較記事でも、同程度の数字が示されています。しかし、この相場は近年大きく変わりつつあります。AI活用によって費用が下がっている背景要件整理から実装、検証までの各工程にAIを組み込むことで、開発コストは大幅に低下しています。当社の場合、最短2〜4週間・25万円〜での開発が可能になりました。従来の受託開発（300万〜1,000万円規模）と比較すると、最大97.5%のコスト削減に相

ChatGPT、Claude Code、Cursorでコードは作れます。でも「動いた」と「公開して大丈夫」は、まったく別です。画面が開いた。ボタンも押せた。だから本番へ出す。ここを一気に進むと、利用者が増えた瞬間に問題が出ます。私も生成AIを使って実装やコードレビューを進めますが、最後に見るのはコードのきれいさだけではありません。データ、権限、同時利用、再実行、ログ、画面操作、更新後の確認まで見ます。生成されたコードが悪いという話ではないんですよね。確認せず公開する流れが危ない、という話です。1人の動作確認では見えない、本番の条件ローカル環境で1人が使うと正常でも、サーバーで複数人が使うと状況は変わります。実際、結果画面を開いている間、同じAPIへ何度もアクセスしているように見えるケースがありました。1回の処理は軽くても、複数人が同時に使えば呼び出しは積み上がります。ほかにも、ブラウザ操作のE2Eテストでは、対象が見えているのにクリックがタイムアウトすることがあります。画面上の重なり、読み込み中の状態、対象要素の揺れ。コードだけ眺めても分からない問題です。はい。「自分のPCでは動きました」は、公開許可証ではありません。公開前に残す7つのチェック1つ目は、入力値。空欄、長すぎる文字、想定外の記号、0件、最大件数を試します。正常なサンプル1件だけで通すと、現場のデータに負けます。2つ目は、権限。ログインしていない人が画面やAPIへ直接アクセスできないか。一般ユーザーが管理機能を実行できないか。画面上でボタンを隠すだけでは足りません。3つ目は、機密情報。APIキー、パスワード、接続先

共通していたのは「道具は正しく動いていた」という一点でした。壊れたのはAIではなく、AIを載せる土台のほうです。この記事はかなり専門的な内容です。エンジニア・技術職の方向けに書いています。用語をかみ砕かずにそのまま扱いますので、読みにくければ遠慮なく閉じてください。「業務でAIに何ができるのか」を平易に知りたい方には、別の記事のほうがお役に立てると思います。2026年に入ってから、英語圏で「Why AI agents fail in production（AIエージェントはなぜ本番で壊れるのか）」というテーマの記事が急増しています。3月から7月にかけて、ベンダー、実践者、インフラ企業が相次いで自分たちの失敗を公開しました。面白いのは、それらがほとんどモデルの話をしていないことです。「GPTが賢くないから失敗した」「もっと良いモデルを待つべきだ」といった論調は、ほぼ見当たりません。代わりに書かれているのは、リトライ、権限、記録、そして「何を渡すか」の話です。この記事では、公開されている事故報告をいくつか読み解きながら、2026年の議論がどこに移ったのかを整理します。日本語圏ではまだあまり紹介されていない領域だと思うので、原典の媒体名と公開日は本文中に明記します。議論の中心は、モデルから運用層へ移った2024年ごろ、エージェントがうまく動かないときの対処法は、ほぼプロンプトの改善に集約されていました。指示文を書き直す。例を足す。トークンを削る。ここを詰めれば、たいていの問題は改善しました。2026年の記事を読んでいると、その前提が明確に崩れています。ある技術記事（DEV Commu

はじめまして！ 大手企業で現役のプロダクトマネージャー（PdM）をしながら、ご相談者様のビジネスの「要件整理・上流設計」をサポートしている近藤と申します。私は元料理人という少し変わった経歴があり、「相手に寄り添い、最高の一皿（プロダクト）を一緒に作り上げる」ことを何よりのモットーに活動しています。今回は、最近のシステム開発やWEBアプリ制作において非常に急増している「ある悲しい失敗パターン」と、それを防ぎ開発予算と時間を最小化するための秘訣をお伝えしたく、この記事を書きました。これから「アプリを作りたい」「WEBシステムを開発したい」とお考えの非エンジニア・事業責任者様にとって、数十万円〜数百万円を節約できる決定的なヒントになれば幸いです。1. 「AIで誰でも早く作れる時代」なのに、なぜ開発トラブルが急増しているのか？昨今、生成AIの急速な進化によって、エンジニアがコードを書くスピードは飛躍的に向上しました。 「AIを使えば、今まで3ヶ月かかった開発が1ヶ月でできる！」 そんな声を耳にしたことがある方も多いのではないでしょうか。しかし実は今、現場では「早く出来上がったのに、結局全く使えないシステムになってしまった」「仕様が違って手戻りになり、追加費用を請求されて炎上した」というトラブルがかつてないほど急増しています。なぜでしょうか？ 理由は非常にシンプルです。『何を作るか（要件設計）』が曖昧なまま、AIとエンジニアの力で「高速に間違ったものを作成してしまっている」からです。2. エンジニアは「作るプロ」であって、「要件を整理するプロ」ではないここが多くのご依頼者様が誤解されがち

一度操作を見せる。Codexが覚える。次から自動でやってくれる。ここまで聞くと、業務自動化が急に簡単になったように見えます。実際、2026年6月にOpenAIが追加したRecord & Replayは、Mac上で操作を記録し、繰り返し使えるスキルへ変換できる機能です。文章で長い手順を書くより、実際の操作を見せたほうが早い業務は多いんですよね。ただし、一度見せたら運用まで完成するわけではありません。見せるだけのスキル化たとえば、毎朝次の作業をしているとします。・管理画面へログイン・前日のCSVをダウンロード・Excelで不要な行を削除・別のシステムへ登録・完了メールを送信この操作をCodexへ見せて再利用できるなら、手順書を一から書く負担は減ります。クリックする場所、入力する内容、ファイルを保存する場所など、言葉にすると長くなる部分を操作から覚えさせられるからです。社内業務では、「説明するより一回見たほうが早い」が本当に多いです。私もシステム開発の相談で、文章だけでは分からないときは、現在のExcelや画面、実際の操作順を見せてもらいます。担当者にとって当たり前すぎて、手順書へ書かれていない処理が出てくるからです。正常系という一本道一度見せられるのは、基本的にそのとき成功した操作です。CSVが正しく出力され、画面もいつも通りで、ログインにも成功し、登録対象にも問題がない。これは正常系と呼ばれる一本道です。実務でクッッッソ厄介なのは、その道から外れたときです。・CSVが出力されていない・列の順番が変わっている・空欄のデータが入っている・同じデータが昨日も登録されている・ログ

ChatGPT、Claude Code、Cursor、kintone系のAI機能など、業務に使える選択肢はどんどん増えています。ココナラでも生成AI関連のカテゴリが目立つようになってきて、「うちもAIを入れたほうがいいのかな」と考える方は増えているはずです。ただ、現役SEとして業務改善や自動化の相談を受けていると、かなり強く思うことがあります。AIを入れても、散らかった仕事は勝手には片づきません。むしろ、散らかった仕事にそのままChatGPTや自動化ツールを入れると、散らかったまま高速化します。はい。地味に一番怖いやつです。（部屋が汚いまま、掃除ロボットだけ走らせる感じです）私はココナラで、Excel、GAS、Python、Webアプリ、スクレイピングなどを使った業務改善・自動化の相談を受けています。販売実績は227件、評価は5.0です。数字だけ見るとちゃんとしてそうですが、正直に言うと、私も最初から全部きれいに進められたわけではありません。処理だけ先に作って、あとから例外が増えて、修正で苦しんだこともあります。普通に終わってます。だからこそ、今はツールを作る前に「業務の入口と出口」をかなり見ます。AIを入れても、散らかった仕事は片づかないAI導入で最初にやりがちな失敗は、「どのAIを使うか」から考えることです。ChatGPTがいいのか。Claude Codeがいいのか。Cursorがいいのか。Excel VBAでいいのか。GASでいいのか。Pythonで作るべきか。もちろん、ツール選びは大事です。でも、その前に見ないといけないものがあります。それが、今の業務の流れです。どこか

１ChatGPTやClaude Code、Cursorを使えば、かなり多くの作業を任せられるようになってきました。文章の下書き、コード修正、CSVの整理、メール文の作成、Excelの確認、Web上の情報整理。ここだけ見ると、もう全部任せればいい気がします。ただ、現役SEとして業務自動化の相談を受けていると、いつも思うんですよね。AIエージェント化で大事なのは、どこまで任せるかより、どこで止めるかです。はい。ここを決めないまま自動化すると、便利になる前に普通に怖い仕組みになります。（便利な顔をした暴走族、みたいなやつです）私はココナラで、Excel、GAS、Python、Webアプリ、スクレイピングなどの業務改善相談を受けています。販売実績は227件、評価は5.0です。数字だけ見ると良さそうに見えますけど、実際の相談では、最初から仕様がきれいに整理されていることはほとんどありません。むしろ、ざっくりした困りごとから始まることのほうが多いです。それで毎回感じるのが、ツール名より先に、確認する場所の設計が必要だということです。AIエージェント化の相談で、最初に見る場所AIエージェント化の相談で最初に見るのは、ChatGPTを使うか、Claude Codeを使うか、Cursorを使うかではありません。最初に見るのは、その業務の中で「人が確認しないと危ない場所」です。たとえば、次のような処理です。・金額を確定する・外部にメッセージを送る・データを削除する・既存ファイルを上書きする・顧客情報を扱う・注文内容を変更する・請求書や見積書を作成するこのあたりは、いきなり全自動にすると怖いです。も

「最初から完璧なシステムが欲しい」と言われることがあります。でも、クライアントさん固有の業務のすみずみまではわかりませんし、クライアントさんの考える「完璧」がどの様なものなのかもわかりません。なので、Hot Linuxでは「まずは使って頂ける」状態を最速で目指して開発します。その後、ミーティングを重ねながら調整していきます。この様に進めることで、クライアントさんはイメージしやすくなり、伝え忘れていたことや見落としていたことが見えてきます。それらに柔軟に対応していきます。（かかる費用はまた別のお話です）#hotlinux#WEBシステム開発https://coconala.com/services/1860090

人間、ひとつのことに集中しつづけられるのは3週間くらいが限度なんだそうです。実際一日16時間もひとつのシステム構築に没頭していると、本当に3週間くらいでガクッときます。頭は真っ白。ひたすら眠い。そして無性にソリティアをやりたくなります笑。小説執筆では燃え尽きた経験がないんだがなあ、というオチなのですが笑。まあ2年も書きつづけたりしますので、とにかく習慣づけて展開を楽しみながら書く、という方法しかないようです（少なくともわたしは）。とにかく今回も頑張りました。ご褒美にココナラさんで癒やしを見つける旅に出ます笑。追記：ココナラさんでのビデオチャットや電話のサービス、とりあえずインカムを買えばいいのでしょうか？　Zoomなど苦手なのですが、癒やし系ならちょっと経験してみたい笑。

なんとか、Dockerでnuxt.js バージョン2を起動することができましたこれで、Ruby on Rails + Nuxt.js の環境がローカルで作れました！せっかくなので、Ruby on Railsの学習を始めます。今回もいろいろつまづきました。１．これを参考にでもこの通りにやってもできない。nuxt.jsコンテナがビルドでエラー zenn.dev/hibriiiiidge/books/49ee4063b10cec1df1a2/viewer/2ac314f5633e674d4b0c２．これをベースにDockerfileを作り直しwww.y-techmemo.work/entry/create-nuxt-app-using-docker-composeこれを参考に、実行コマンドを変更 --overwrite-dir オプションを追加zenn.dev/uta_mory/articles/f8bad2ffa86d99実行コマンドdocker-compose run frontend npx create-nuxt-app --overwrite-dir３．ブラウザでアクセスできないdocker-compose up で起動した後、localhost:3000にアクセスしても以下となるcurlでアクセスするも、 curl(52) empty reply　となり通信不可。これを参考に、nuxt.config.jsで待ち受けhostを明示的に指定qiita.com/amuyikam/items/01a8c16e3ddbcc734a46   server: {    host: '0

ホームページや会員サイト、予約・顧客管理などを作るとき、「WordPressとLaravelのどちらを選べばよいか」で迷うことがあります。結論からいうと、優劣ではなく、誰が何を更新し、どの業務をどこまで仕組み化するかで選ぶのが安全です。この記事では、制作前に整理したい7つの判断基準を、専門用語をできるだけ避けてまとめます。【まず知っておきたい違い】WordPressは、投稿・固定ページ・画像・ユーザー管理など、情報を公開して更新するための機能が最初からそろったCMSです。管理画面を使って、運営者自身が文章や画像を更新しやすい点が強みです。プラグインを追加すれば、フォーム、予約、会員機能なども拡張できます。Laravelは、Webアプリケーションを個別に設計・開発するためのフレームワークです。画面、データ、権限、処理の流れを目的に合わせて組み立てやすく、複雑な業務ルールや外部サービス連携を実装する場合に向いています。一方、記事を更新する管理画面なども必要に応じて設計するため、初期開発と継続保守の体制が重要です。【1. サイトの中心は情報発信か、業務処理か】会社案内、サービス紹介、ブログ、実績、採用情報など、公開コンテンツが中心ならWordPressが有力です。ページを増やす、担当者が文章を修正する、といった日常運用を始めやすいからです。一方、顧客ごとに処理を変える、申請を承認する、案件の状態を段階的に管理するなど、業務フローそのものが中心ならLaravelを検討しやすくなります。【2. 誰が日々更新するか】非エンジニアが記事、画像、固定ページを頻繁に更新するなら、WordPres

以前、仕事でExcelのシートを一つ受け取ったことがあります。開いてみて最初に思ったのは、これはどこを打てばいいんだろう、でした。数字がびっしり並んでいます。合計らしき欄もあります。ただ、そのどれが自分で入れる数字で、どれが勝手に出てくる数字なのか、見ただけでは分かりませんでした。適当なところをクリックすると、上のバーに長い式が表示されます。ああ、ここは触ってはいけないところなんだな、と分かる。でもそれは、クリックしてみて初めて分かることです。全部のセルを一つずつ確かめていくわけにもいきません。そもそも私はExcelに慣れていません。だから、ちょっとしたはずみで数字を打ち間違えます。指が滑って、一桁多く入ってしまう。問題は、そのあとでした。打ち間違えた数字が、どこに響いているのかが分かりません。自分で作ったシートではないので、その欄がどこにつながっているのかを知らないんです。合計が変わったのかもしれないし、変わっていないのかもしれない。そもそも、ちゃんと反映されているのかどうかも分からない。慌てて打ち直します。でも今度は、元に戻ったのかどうかが分かりません。見た目は打つ前と同じに見えます。でも同じに見えるだけで、本当に戻っているのかは確かめようがない。どこか自分の見ていない場所が、ずれたままかもしれない。一番こわかったのはこれでした。間違えたこと自体ではなくて、間違いが直ったのかどうかを自分で確認できないことです。数式を消してしまっていたら、たぶんその場では気づきません。合計が少しずれたまま、そのまま出してしまう。だから、手が止まりました。そして、聞けませんでした。どこを打てば

はじめまして！ 大手企業で現役のプロダクトマネージャー（PdM）を務めながら、発注者様の「システム要件設計・コスト最適化」を伴走支援している近藤と申します。私は元料理人という異色の経歴を持ち、「相手に寄り添い、無駄なく美味しい最高の一皿（プロダクト）を仕立てる」ホスピタリティを何より大切にしています。前回の記事では「なぜいきなりエンジニアに開発を発注すると失敗するのか？」についてお伝えしました。 今回はそこからさらに一歩踏み込み、「開発見積もりを高騰させず、初期費用を半分以下に抑えながら、本当に使えるシステムを手に入れる『発注前の3つの鉄則』」をお伝えします。「開発会社から出てきた見積もりが数百万円と言われて絶望している…」 「どこを削ればいいのか、非エンジニアだから判断できない…」 そんなお悩みを一発で解決する実践ノウハウをお届けします！1. なぜ、システム開発の見積もりはあっという間に高騰するのか？システムやアプリの構築を考える際、多くの事業主様がやってしまいがちなのが「あれもこれも、とりあえず機能を入れておこう」という全方位型のオーダーです。たとえば、 「ユーザーの会員登録はメールだけじゃなく、LINEもApple認証もつけよう」 「管理画面には複雑なグラフの自動集計レポート機能も最初から入れよう」 といった具合です。しかし、エンジニアに「これら全部入れられますか？」と聞けば、当然「入れられますよ（その分、開発費と期間が3倍になりますが）」という返答になり、結果として数百万円〜数千万円規模の膨大な見積もり書が出現してしまいます。実は、ビジネスを成功させる上で本当に必要な機

ココナラでアプリやツールの開発を依頼して、「完成しました。テスト済みです」と納品の連絡が来たとします。コードが読めない依頼者には、品質を確認する方法がない。「テスト済み」という言葉を信じるしかない——そう思うかもしれません。コードを読めなくても、納品を受け取るか判断するための材料は確認できます。大切なのは、開発者を疑うことではなく、双方で「何をもって完成とするか」を揃えることです。私は普段、AIや外注で作られたアプリの検証・診断をしています。その立場から、納品時に確認したいものを5つご紹介します。最も確実なのは、見積もりや購入の段階で、これらを納品物に含めると合意しておくことです。開発終盤になってから追加で依頼すると、資料作成の費用や日数が必要になる場合があります。■すべての案件で確認したい3つ1. 何をテストし、どうなったかが分かる一覧「テストしました」という言葉や、成功件数だけでは、何を確認したのか分かりません。次の内容が分かる一覧を見せてもらいます。・確認した機能・入力した条件・成功・失敗・未確認の結果・確認した端末やブラウザ・使用したアプリのバージョン例えば、次のような簡単な表で十分です。・ログイン：正しいパスワードで成功・ログイン：間違ったパスワードでは拒否・CSV取込：100行のダミーデータで成功・スマートフォン表示：iPhoneでは確認済み、Androidは未確認自動テストでも手動確認でも構いません。重要なのは、何を確認し、何が未確認なのかが残っていることです。2. 実際の利用に近い条件での画面録画サンプルデータを1件入力しただけでなく、実際に使う流れに近い操作を

自動化を頼みたい気持ちはあるのに、相談文が書けないまま1ヶ月経ってしまう。見積り依頼では、これがいちばんよくある足止めです。この記事では、見積りが早く正確になる8項目と、そのままコピーして使える相談文のテンプレートを用意しました。見積りが早く正確になる8項目この8項目は、見積りを受ける側が最初に確認することの多い内容です。先に書いてあれば確認の往復を減らしやすく、見積りの前提をそろえやすくなります。1. 対象のサイト・ソフト：どのモール・管理画面・ソフトが関係するか。名前が分かるだけで、受ける側は規約やAPIの有無に当たりをつけられます。2. 現在の手順：いま人がどんな順番で何をしているか。箇条書きでも話し言葉でも構いません。ここが具体的だと、見積りの精度が最も上がります。3. 入力データ：作業の元になるデータは何か。CSV、Excel、管理画面の表示、紙の伝票など。4. 出力・完成形：最終的に何がどうなっていれば成功か。「この形の表ができる」「通知が届く」のように状態で書きます。5. 件数と頻度：1回あたり何件を、どのくらいの頻度で処理するか。10件と1万件では向く手段が変わります。6. 例外パターン：たまに起きるイレギュラーな処理。例外の量は、費用を左右する大きな要素です。7. 実行環境：使っているPCの種類（WindowsかMacか）、作業に使うアカウントの権限など。会社のPCなら、ソフトの導入に許可が必要かも書き添えます。8. 希望納期と予算感：目安で構いません。「未定」と書くのも立派な回答です。上限があれば、その範囲でできる案から提案できます。このほかに、個人情報を除

はじめまして。業務効率化のためのWindowsアプリを作っています。今回は、自分で設計・開発した「顧客管理システム」を紹介します。どんなものが作れるか、参考にしていただければと思います。---■ 作った背景「Excelで顧客情報を管理しているけど、だんだん使いにくくなってきた」そういう声をよく聞きます。シートが増える、数式が壊れる、検索しづらい。そこを解決するシンプルなツールが欲しくて作りました。---■ できること・顧客情報の登録・編集・削除（氏名・電話・メール・住所・メモなど）・来店履歴の記録（日付・サービス内容・金額・担当者）・名前・よみがなでの検索・CSV出力・バックアップ・集計・レポート機能（月別売上、誕生日リスト、長期未来店者など）インターネット不要、インストール不要、Windows10/11で動きます。データはすべてローカルに保存されるので、外部に情報が漏れる心配もありません。---■ 設計で意識したことITに詳しくない方でも迷わず使えるように、画面はシンプルに作っています。ボタンの数を絞り、操作の流れが自然になるよう設計しました。「難しそう」と思わせないことが、業務ツールで一番大事だと思っています。---■ カスタマイズについて今回紹介したのは汎用版ですが、・項目を増やしたい（担当部署、会員番号など）・自分の業種に合わせた画面にしたい・他のシステムと連携したいといったご要望にも対応しています。ご相談はサービスページからどうぞ。

システム開発の前に、まず業務フローと要件を整理した方がよい理由システム開発や業務自動化の相談で、最初につまずきやすいのは技術そのものではありません。多くの場合、問題になるのは「何を作るのか」「どの業務を対象にするのか」「どこまで自動化するのか」が曖昧なまま進んでしまうことです。開発がうまく進まない原因たとえば、次のような状態です。- 今の業務手順が担当者の頭の中にある- ExcelやCSVの加工手順が人によって違う- 受注、出荷、請求、在庫管理の流れが整理されていない- どの作業をシステム化したいのか決まっていない- 開発会社に何を依頼すればよいかわからないこの状態で開発や自動化に入ると、途中で「やっぱりこの機能も必要だった」「この帳票も出したい」「この例外処理を考えていなかった」という話が増え、手戻りが起きやすくなります。業務フローを整理する意味業務フロー図を作る目的は、きれいな図を作ることだけではありません。本来の目的は、業務の流れを見える化し、どこでミスや手戻りが起きているのか、どの作業が属人化しているのか、どの範囲を改善すべきかを確認することです。たとえば、ECサイトの受注処理であれば、注文確認、入金確認、出荷指示、送り状作成、在庫確認、請求処理、顧客連絡など、複数の作業がつながっています。この流れを整理しないまま一部だけ自動化すると、別の場所に手作業や確認漏れが残ることがあります。要件定義で決めておきたいこと開発前の要件定義では、少なくとも次のような内容を整理しておくと、相談が進めやすくなります。- 対象にする業務- 現在の業務手順- 困っていること- 入力データ-

「相談したいけど、何を渡せばいいか分からない」これは、業務自動化の相談でかなり多い悩みです。自分では情報が足りない気がして、相談を後回しにしてしまう方もいます。ただ、実際には最初から完璧に整理されている必要はありません。この記事では、自動化相談の前にどんな資料があると進めやすいのか、そして全部そろっていなくても相談してよい理由を整理します。【この記事で分かること】・相談前にあると分かりやすい資料・伝えておくと進めやすい内容・資料が不足していても相談できる理由### まずは何があればよいのか代表的なのは次の4つです。・現在使っているExcel・CSVのサンプル・画面キャプチャ・手順メモこの4つがあると、今どんな流れで作業しているのかイメージしやすくなります。たとえば、Excelを見ると列構成や集計方法が分かります。CSVを見ると入力元のデータ形式が分かります。画面キャプチャがあると、どこを見てどのように操作しているかが伝わりやすくなります。手順メモがあると、作業の順番や判断ポイントが見えます。### 相談時に整理しておくとよい内容資料そのものに加えて、次の内容があるとさらに進めやすいです。・今の流れ・困っている点・自動化したい範囲・希望する納品形たとえば、「CSVを貼って請求書を作るところまでを自動化したい」「毎朝の確認メールだけ自動化したい」「最終的にはWebアプリ化も視野に入れている」このようにざっくりでも方向性があると、提案がしやすくなります。### 全部そろっていなくても大丈夫な理由ここが一番大事です。相談の初期段階では、資料が全部そろっていないことの方が普通です。・Ex

前回、AIの正体を「正解っぽいものを出す変換器」だとお話ししました。今回は、その性質がいちばん現実的に効いてくる場面。AIによる「開発」の話です。「AIってすごい」の中身を、正しく知る前回の記事で、AIをこう定義しました。AIとは、「正解そのもの」ではなく「正解っぽいもの」を、超大規模・超高速で出力するのが得意な、巨大な変換器である。この性質は、文章や画像だけの話ではありません。AIは今や、プログラムのコードも生成できます。「こういうアプリを作って」と言葉で頼めば、それらしいコードを出てくれる。だから最近は「AIが開発してくれる時代が来た」とも言われます。SaaS is Dead（SaaSの死）最近では、「SaaS is Dead（SaaSの死）」という言葉まで耳にするようになりました。「専用のソフトを契約しなくても、AIに頼めば自分専用のアプリがその場で作れる。だから、出来合いのソフトを売るSaaSビジネスは終わる」そんな主張です。確かに、これは大きな変化です。かつてエンジニアが何ヶ月もかけて書いていたコードが、3日間で形になる。開発のスピードは、間違いなく劇的に上がりました。でも、ここで前回の言葉を思い出してください。AIが出すのは「正解」ではなく、「正解っぽいもの」でした。では、AIが出した"正解っぽいコード"を、そのままお客様に納品したら、何が起きるのでしょうか。「動くコード」と「正しいコード」は、まったく別物AIが生成したコードは、たいてい、ちゃんと動きます。画面も表示されるし、ボタンも押せる。一見、完成しているように見えます。ここに、最大の落とし穴があります。「動い

システムやプログラムをちょっと調整したい時や調子が悪い時に、色々自分で試される方がいらっしゃいます。ご自身で色々試されてから、どうにもできなくてご相談を受けることがあります。これはいい面悪い面があって、いい面：こちらからお聞きすれば現在の状況がある程度わかる。悪い面：色々試された結果、事態が深刻化してしまう事がある。2つめがなかなか厄介で、色々触った後で見てもそれが「元々のエラーになっていた部分」なのか「後から書き換えて更にエラーを引き起こしている部分」のかがわかりません。ご相談を受けると、かなりの高確率で後者の状態になっています。こうなると、直すまでの時間がかかり、最悪は元に戻せない状態になることもあります。簡単なことだから自分で出来そう！と下手にいじらず、簡単そうなこともプロにご相談ください。https://coconala.com/services/1689980

こんにちは、henithです。なかなか筆が進まないですがぼちぼち書いていきます。Roadieを召喚するrbenvを使用していてバージョン管理しており、rubyは3.0.0でrailsは6.1.3でRoadieを召喚します。①現在指定しているRubyバージョンの確認。-------------------------------- ターミナル --------------------------------henith:Rails henith$ rbenv versions  system  2.4.3  2.5.1  2.6.6* 3.0.0 (set by /Users/taisuke/.rbenv/version)--------------------------------------------------------------------------------②現在所持してるRailsバージョンの確認。-------------------------------- ターミナル --------------------------------henith:Rails henith$ gem list rails*** LOCAL GEMS ***jquery-rails (4.4.0)pry-rails (0.3.9)rails (6.1.3, 6.1.2.1, 6.1.1, 6.0.3.5, 6.0.3.4) ←コレrails-dom-testing (2.0.3)-----------------------------------------------

「こんなの作れる？」からで大丈夫です｜オリジナル業務ツールが完成するまでの相談・設計・開発の流れ「こういうツールが欲しいんですけど、説明の仕方が分かりません」オリジナルツールの相談で、最初にここを心配する必要はありません。仕様書。画面設計書。データベース設計。API仕様。最初からそんなものを用意できる人のほうが少ないです。むしろ、「今これが面倒」「こんな画面があれば楽そう」「Excelでは限界を感じている」ここから始まるほうが自然です。僕が新しいツールを考えるときも、いきなりコードは書きません。まず見るのは、誰が使うのか。今はどうしているのか。どこが面倒なのか。何ができたら成功なのか。ここです。この記事では「こんなの作れる？」という状態から、オリジナル業務ツールが形になるまでを、できるだけ専門用語なしで整理します。最初に必要なのは仕様書ではなく「今のやり方」相談するときに一番助かるのは、完成された仕様書ではありません。今の業務が分かるものです。例えば、・今使っているExcel・Googleスプレッドシート・手書きのメモ・画面のスクリーンショット・入力している項目・完成後に出したい帳票・作業の順番を書いた箇条書きこのくらい。「毎朝このファイルを開く」「ここをコピーする」「この条件だけ残す」「最後にメールする」これだけでも、かなり情報があります。むしろ開発側からすると、今どう動いているかが見えれば、「ここは自動化できそう」「ここは人の確認を残したほうがいい」「ここは既存ツールを使えばいい」と整理できます。きれいな資料より、普段の作業そのもののほうが役に立つことがあります。1段階目は

「欲しい機能があるツールが見つからない」なら作れます｜既製品に仕事を合わせる前に考えたい“専用ツール”という選択肢「探せば何かあると思ったんですけど、ちょうどいいツールがないんですよね」業務改善の話をしていると、珍しくない悩みです。勤怠、顧客管理、在庫管理、日報、予約、見積、進捗管理。世の中には便利なサービスがたくさんあります。それでも実際に使おうとすると、「この項目だけ足りない」「この画面はいらない」「ここだけExcelに戻る」「結局、最後は手入力」「会社のやり方をツール側に合わせないといけない」となることがあります。既製品が悪いわけではありません。むしろ、条件が合うなら既製品を使ったほうが早いです。ただ、仕事のほうを無理に変えてまでツールへ合わせ始めたら、一度だけ別の選択肢も考えていいと思っています。自分たちの業務に合わせて、必要な機能だけを持った専用ツールを作る。今回は、既製品を使い続けるケースと、専用ツールを考えたほうがいいケースを分けてみます。「あと1個だけ足りない」が意外と重い既製品を探していると、最初はかなり良さそうに見えます。一覧がある。検索できる。CSVも出せる。スマホにも対応している。ここまで見ると「これでいけそう」です。でも運用を始めると、「登録した後にこの帳票も出したい」「この条件のときだけ担当者へメールしたい」「A部署にはここまで見せたい」「入力した内容を別の一覧にも反映したい」みたいな、自社固有の部分が出てきます。その1個を補うためにExcelを横へ置く。ツールからCSVを出す。Excelへ貼る。関数で加工する。メールへ添付する。はい。気づくと、新し

「GASなら無料で自動化できるから、全部それで作ればいいですよね」これ、半分は正しいです。Googleスプレッドシート、Gmail、Googleドライブとの相性はかなりいいですし、小さな業務改善なら僕もGASを選ぶことがあります。ただし、「無料で作れる」と「長く安定して運用できる」は別の話なんですよね。2026年8月時点のGoogle公式ドキュメントを見ると、Apps Scriptには1回の実行時間、トリガー、メール送信、URL Fetch、同時実行などに明確な上限があります。なお、Google公式でもクォータや制限は変更される可能性があるため、運用前には最新値の確認が必要です。ここを知らないまま作り始めると、「テストでは動いたのに本番で止まった」「少量なら平気だったのに件数を増やしたら終わらない」「朝の自動実行だけ失敗している」みたいなことが起きます。はい。GAS、便利なんですけど万能ではありません。この記事では「GASをやめましょう」という話ではなく、どこまでGASでやると気持ちよく使えて、どこから別の構成を考えたほうがいいのかを整理します。■ 無料の裏にある「上限」まず一番分かりやすいのが実行時間です。Google公式では、通常のApps Scriptは1回の実行につき6分が上限です。6分。短い処理なら十分です。スプレッドシートを読んで、数十行を加工して、Gmailの下書きを作る。このくらいなら設計次第でかなり使えます。問題は、処理量が増えたときです。数千行を1行ずつ読み書きする。外部APIを何百回も呼ぶ。複数ファイルを順番に処理する。画像を大量に扱う。こうなると、急に6

AIツール、アプリ、API連携、既存ツールの改善などのご相談では、資料、既存コード、業務データ、アカウント情報などを確認する場合があります。これらは、実現方法を検討し、必要な設計・導入・保守を行うための重要な情報です。一方で、必要のない情報や権限まで共有する必要はありません。本記事では、当方がデジタル技術サービスを提供する際の、情報・認証情報の基本的な取扱方針をまとめます。案件ごとの対象、権限、保管方法、対応範囲は、お見積りおよびトークルームで確認します。1. この方針の対象本記事で扱う情報には、たとえば次のようなものがあります。・ご相談時に共有いただく資料、画像、文章、業務フロー・既存のソースコード、設定内容、ログ、データ構造・外部サービス、クラウド、ドメイン、VPSなどのアカウント情報・APIキー、アクセストークン、パスワードなどの認証情報・開発・導入・保守のために必要な接続先や権限個人情報、営業情報、未公開の事業情報など、取り扱いに注意が必要な情報についても、案件遂行に必要な範囲で扱います。2. 共有いただく情報は、必要な範囲で扱いますご共有いただく資料、データ、既存コード、ロゴ、画像などは、相談、見積り、設計、導入、保守に必要な範囲でのみ使用します。ご相談・お見積りの段階では、まず状況を把握するために必要な最小限の情報から確認します。実作業に進む前に、どの環境・データ・サービスを対象とするかを整理します。お客様からご共有いただく情報の権利は、お客様または正当な権利者に帰属します。当方が、案件と関係のない目的で利用、公開、第三者提供することはありません。3. 認証情報は、

打つ画面を作ったあと、必ず一度立ち止まるところがあります。これをどうやって渡すか、です。前に、ある自治体の業務で使われている積算シートを、打つ画面にしたことがあります。動くものができて、計算も元のシートと合っている。そこまでは良かったのですが、では実際にどうやって相手の手元に届けるのか、というところで手が止まりました。渡し方は、大きく3つあります。一つめは、ファイルをそのまま渡す方法です。ひとつのファイルにまとめて送る。相手はそれを開くだけで使えます。インターネットにつながっていなくても動きます。一番手軽で、一番早い。ただしこれは、渡した瞬間にこちらの手を離れます。コピーされても分かりません。中を書き換えられても分かりません。合言葉をかけることはできますが、本気で中を見ようとする人には通用しません。抑止にはなる、という程度のものです。二つめは、URLにする方法です。ネット上に置いて、リンクを送る。相手はそのリンクを開くだけです。良いところは、こちらの手元に残ることです。直したいところが出てきたら、こちらで直せば、次に開いた人には直った版が出ます。配り直す必要がありません。弱点は、リンクを知っている人なら誰でも開けることです。中の作りも、その気になればブラウザから覗けます。三つめは、計算そのものを向こう側でやる方法です。打った数字だけを送って、答えだけが返ってくる。計算の中身は相手の手元に降りてきません。ここまでやると、鍵をかけられます。この人にはこのコード、と決めて配って、ひとつのコードは1台でしか使えないようにする。外に漏れたら、そのコードだけ止められます。意外に思われるかも

こんにちは。Rekushiaといいます。予約システムと、Excelまわりの仕事をしています。前回、使いにくいExcelの正体は1枚に全部入っていることだ、という話を書きました。今回はその続きで、そこから起きる困りごとについて書きます。■ 少し申し訳なさそうに言われるExcelの相談をいただくとき、途中でこう言われることがあります。「このシート、私しか触れないんです」たいてい、少し申し訳なさそうな言い方です。自分の作ったものが、人に渡せる形になっていない。そのことを本人が一番気にしている、という感じがします。でも、これは怒られるような話ではないと思っています。■ そうなるのは、ちゃんと使ってきたから最初から複雑なシートを作る人はいません。必要になった項目を足して、条件が増えたから式を伸ばして、去年の様式が変わったから列を差し込んで。そうやって少しずつ育てていくと、自然とそうなります。つまり、複雑になったのは、それだけ長く実務に耐えてきたということです。使われていないシートは複雑になりません。■ ただ、休めなくなる問題はそこから先です。有給を取った日に限って、その計算が必要になる。異動の話が出たときに、引き継ぎ資料が書けない。辞めたあとに誰も開けられなくなる。まわりの人も困りますが、いちばん重いのは本人だと思います。「あの人にしか分からない」は、頼りにされているようでいて、その人を縛ります。■ 触れないのは、能力ではなく見た目の問題ここが大事なところだと思っています。ほかの人がそのシートを触れないのは、Excelが苦手だからではありません。どこを打っていい場所で、どこが触ってはいけ

こんにちは。個人サロン向けの予約システムを作っている、Rekushiaといいます。今回は予約の話ではありません。もう一つやっている、Excelまわりの仕事について書きます。新しく出した出品の話でもあるのですが、売り込みというより、やってみて分かったことの記録です。■ 現場のExcelは、たいてい1枚に全部入っている去年、ある自治体の業務で使われている積算シートを預かりました。開いて驚いたのは、1枚のシートに全部入っていたことです。打ち込む欄も、計算式も、出来上がりの表も、同じ面の上に並んでいる。どこが入力欄で、どこが触ってはいけない場所なのか、見た目では分かりません。作った方が悪いわけではありません。必要に迫られて少しずつ足していくと、自然にこうなります。むしろ、それでちゃんと仕事が回っていたことのほうがすごいと思いました。■ 困りごとは、いつも同じ形をしているこういうシートを使っている方から出てくる話は、だいたい似ています。うっかり数式を消してしまって、毎回どこかから直してくる。印刷すると1枚に収まらず、毎回手で調整する。人が代わるたびに、また一から教える。そして「自分しか触れない」状態になっていく。つまり困っているのは計算ではなく、その周りです。計算はちゃんと合っている。合っているのに、扱いづらい。■ 直すのではなく、分ける最初は、そのシートを整えることを考えました。色を変える、保護をかける、順番を入れ替える。でも途中でやめました。1枚のままだと、どこまで整えても「触ってはいけない場所」が消えないからです。そこで、打つ画面と、出来上がる画面を分けました。入力する人が見るのは

「仕様書がないので、まだ依頼できません」これ、実際には逆なんですよね。仕様書を作れるところまで整理できているなら、もう半分くらい設計が終わっています。本当に困っている人ほど、「今はExcelでやっています」「毎月この作業が面倒です」「途中まで作ったけど動きません」「やりたいことはあるけど、うまく説明できません」という状態で相談に来ます。僕はSEとして16年目になります。ココナラでも220件を超える取引を経験してきましたが、最初から完璧な仕様書が出てくる案件ばかりではありません。むしろ、最初に見るのはコードより「今の作業」です。■ 仕様書より先に確認しているものまず確認するのは、だいたい次のようなものです。・今使っているExcelやGoogleスプレッドシート・実際の作業手順・入力しているデータ・最終的に作りたい帳票や画面・どこで「面倒」と感じているか・誰が使うのか・複数人で同時に触るのか・失敗したときに元へ戻せる必要があるか・データをどのくらい残したいか画面だけを見ると簡単そうでも、運用条件を聞くと設計が変わることは普通にあります。たとえば「ExcelをWeb化したい」という相談。一見すると、Excelの項目をそのままWeb画面へ移せば終わりに見えます。でも実際には、「3人で同時に編集したい」「担当者ごとに見せるデータを変えたい」「履歴を残したい」「PDFで印刷したい」「スマホからも使いたい」といった条件が後から出てきます。はい。このへんから急に「ExcelをWebにしただけ」ではなくなります。■ 僕が先にコードを書かない理由ChatGPTやClaude Code、Cursor

情報サービス業166件倒産。生成AIで「簡単な開発」が売れなくなった今、16年目SEが残す仕事2026年上半期、情報サービス業の倒産は166件。前年同期より18.5％増え、2017年以降の上半期では過去10年で最多になりました。しかも東京商工リサーチは、その背景の一つとして、ノーコード・ローコード・生成AIによって「簡易な制作・開発業務の内製化が進んでいる」と指摘しています。これ、システム屋としては結構重い数字なんですよね。僕はSEを16年やっていますが、ChatGPTやClaude Codeが数十秒でコードのたたき台を出してくるのを見ると、たまに「俺の16年、いったん机の下に置いとく？」みたいな気持ちになります。はい。ただ、現場で仕事をしていると別の景色も見えます。生成AIで「作る」ハードルは確実に下がりました。でも、仕事として最後まで使える状態にする難しさは、ほとんど下がっていません。むしろ、そこが今まで以上に目立つようになりました。 「作れる」だけなら、本当に差がつきにくくなった少し前までなら、Excelマクロを作れる、GASでメールを送れる、Pythonでスクレイピングできる、それだけでも十分に価値がありました。今はChatGPTやClaude Codeに要件を渡せば、かなりのところまでコードが出ます。簡単なCRUD画面、CSV加工、定型メール、集計処理、スクレイピングの試作品。このあたりは、以前よりクッッッソ速く形になります。だから「コードを書けます」だけを商品にすると、価格で比較されやすくなるのは自然です。実際、僕が受ける相談も変わってきました。「ExcelをWeb

「導入はしたけれど、使っているのは一部のメンバーだけ」AIコーディングツールを導入したものの、一部のメンバーしか使っていない。これはツールの問題ではなく、導入の進め方の問題です。この記事では、開発チームにAIツールを定着させるために、どこから手をつけ、何をルール化するべきかを整理します。定着しないチームに共通すること使われないチームには、「どこに使えばいいか分からない」「レビューの基準がない」「社内規約で使っていいのか不明」という共通点があります。いずれも技術力ではなく、合意の問題です。逆に、使ってよい場面とダメな場面が明確なチームは、放っておいても使い始めます。まずは線引きを文書にすることが先です。最初に適用すべき領域いきなり本番コードの実装に使うと、レビュー負荷が増えて反発を招きます。最初は、テストコードの作成、既存コードの説明、ログの解析、ドキュメント作成といった周辺領域が適しています。この領域は効果が分かりやすく、失敗しても損害が小さい。成功体験を先に作ってから、実装領域に広げていくと抵抗が少なくなります。ルールは3つだけ決める細かいガイドラインを作っても読まれません。決めるべきは3つです。入力してよい情報の範囲、生成物のレビュー方針、トラブル時の相談先。この3つが1枚にまとまっていれば十分です。特に入力範囲は大事です。顧客データ、認証情報、未公開の仕様をどう扱うかを明記しない限り、慎重なメンバーほど使わなくなります。定着を測る導入の効果は、利用率ではなく実務の変化で見ます。レビュー待ち時間、テストの網羅率、ドキュメントの更新頻度。このあたりの数字が動いていれば、導入は

システム開発が完了したからといって、すべてが終わるわけではありません。むしろ本当に重要なのは、その後の「運用」です。サーバーの監視、障害対応、バックアップ、セキュリティアップデート、問い合わせ対応など、システムは日々の運用によって初めて安定して稼働します。そのため、システム運用を外部事業者へ委託する場合には、**システム運用契約書**を適切に作成しておくことが非常に重要です。システム運用契約とはシステム運用契約とは、システムを安定して稼働させるための業務を委託する契約です。例えば、* サーバー監視* 障害発生時の一次対応* バックアップ取得* セキュリティパッチの適用* ログ管理* ヘルプデスク対応* 定期メンテナンスなどが対象になります。開発契約とは異なり、成果物を完成させる契約ではなく、継続的な業務を行う契約であるため、多くの場合は**準委任契約**として締結されます。業務範囲は具体的に定める実務で最も多いトラブルは、「そこまでやる契約だと思っていた」という認識の違いです。例えば、* 障害対応は24時間なのか営業時間内のみなのか* 電話対応は含まれるのか* 現地対応は別料金なのか* バージョンアップまで含まれるのか* セキュリティ対策はどこまで行うのかこのあたりが曖昧な契約は非常に危険です。業務内容はできる限り具体的に記載しておくことが重要になります。SLA（サービスレベル）を決めるシステム運用契約では、**SLA（Service Level Agreement）**を定めるケースが少なくありません。例えば、* 稼働率99.9％* 障害受付時間* 初動対応時間* 復旧目標時

自動化したはずなのに、担当者が休むと処理が止まる。しかも、止まった理由を説明できるのも、その担当者だけ。それは自動化ではなく「担当者の作業を見えない場所へ移しただけ」かもしれません。私はExcel、GAS、Python、Webアプリを使った業務改善に関わっていますが、作る処理よりも後から困るのは運用なんですよね。ボタンを押せば終わる。毎朝勝手に動く。見た目はきれいです。でも、担当者がいない日にエラーが出た瞬間、全員が固まります。はい。機械より先に人が止まります。「動く」と「回る」の間にある大きな穴以前、定期処理が外部サービスの利用制限で止まった案件がありました。制限が解除されても、自動では再開しない。画面上では処理待ちなのか、停止中なのかも分かりにくい状態でした。作った直後は「自動で動いて便利」ですけど、本当に必要なのは次の状態です。・誰が見ても稼働中か分かる・止まった理由が画面に出る・安全に再開できる・担当者が不在でも代わりの人が判断できるここまで揃って、ようやく業務として回り始めます。その人しか分からない運用、6つのサイン1つ目は、実行条件が担当者の頭の中だけにあること。「月末はこのファイルを先に入れる」「この取引先だけ手で直す」のような例外です。仕様書にない例外は、担当者が休んだ日に初めて仕様として発見されます（遅いんですよね）。2つ目は、止まったことを担当者しか確認できないこと。自動処理は、成功通知より失敗通知のほうが重要です。ログを開かないと失敗が分からない設計では、実質的に毎日見張る仕事が残ります。3つ目は、再実行の手順が決まっていないこと。途中まで登録されたのか、

ChatGPTやClaudeを使えば、実際に動くアプリは作れます。ただ、動くことと、人に使わせてよいことは同じではありません。「自分の環境では動いた。でも、これを渡して問題が起きないか分からない」この不安、正体を分解すると、だいたい次の3つのどれかです。アプリの種類によって必要な確認は変わりますが、ここでは多くの小規模なアプリに共通する3つに絞ります。■不安①「たまたま動いているだけかもしれない」AIが書いたコードは、たいてい見た目はとても整っています。しかもAIはよく「テストも書きました。すべて通っています」と報告してきます。この「テスト」は、コードを自動で点検する仕組みのことです。ただ、私がAI生成コードを実際に動かして検証してきた経験では、「テストは通るのに、計算結果が間違っている」というケースが確かに存在します。テストが通ることと、答えが正しいことは、別なのです。たとえば「四捨五入のつもりが切り捨てになっていた」ようなズレは、テストが値をきちんと検証していないと、AIの「確認済みです」という報告の裏で生き続けます。確認のしかた: 金額・集計・日数など、計算をするアプリなら、手計算で答えが分かる例を3つ用意して、アプリの出す答えと突き合わせてみてください。3つは、次の内訳にすると効きます。・ごく普通の例・割り算や税率計算など、端数が出る例・0件、上限ちょうど、月末など、境界になる例3つとも合えば、代表的な入力では計算が合っていることを確認できます。ただし、これで「完全に正しい」とは判断できません。試していない条件でのズレは残ります。計算をしないアプリの場合は、次の不安③の

「貴社にお願いして、本当によかったです」納品からしばらく経って、発注元の方からこう言ってもらえることがあります。この一言が、なぜこんなに嬉しいのか。それは、出来栄えが良かったとか、納期が早かったとか、そういうことではありません。「この会社に本当に任せてよかった」と、心から思ってもらえたからだと思っています。AIがなんでも作れるようになった今だからこそ、私はこの一言に、人間の価値のほとんどが詰まっている気がしています。発注が決まるとき、人の心では何が起きているか誰かに仕事を頼もうと決める瞬間、発注者側の心の中では何が起きているでしょうか。「この会社になら、任せられる」「この人にお願いすれば、大丈夫」「この会社だったら、間違いない」おそらく多くの場合、最後に背中を押しているのは、こうした安心感です。もちろん金額も実績も見るのですが、最終的に「お願いします」と言わせるのは、数字よりも、この人ならちゃんと最後まで責任を持ってくれそうだ、という信頼だと思います。人は、その気持ちが生まれてはじめて、頼む相手を決めるのだと思います。だとすると、逆のことも言えます。その安心感や信頼が生まれないなら、わざわざあなたにお願いする理由はない、ということです。もっと身近に対応してくれる人もいるでしょうし、もっと安く対応してくれる人もいるでしょう。それに、任せて大丈夫だと思えない相手にお金を払うくらいなら、いまはAIを使って自分で進めてしまった方が、早くて安く済む、という選択肢も出てきました。では、その安心感や信頼は、どこから生まれるのか。それは実際の仕事の場面で、その人が何をするか。そこにしか宿らない

「システム化したい」「業務を改善したい」「Excel作業を減らしたい」「専門家に相談したい」そう思っても、いざ相談しようとすると、何をどう説明すればよいかわからないことがあります。相談を受ける側から見ると、最初に知りたいのは、難しい専門用語ではありません。大切なのは、今の状況が整理されていることです。たとえば、相談前に整理しておきたいのは次のようなことです。・今はどのような流れで業務を行っているか・どこで時間がかかっているか・どの作業でミスや手戻りが起きているか・Excel、紙、メール、システムなど何を使っているか・何を改善したいのか・どのような成果物がほしいのかこれらが整理されていないまま相談すると、話が抽象的になりやすくなります。「便利にしたい」「効率化したい」「システムを作りたい」という希望はあっても、現状の業務の流れが見えていないと、どこから手をつけるべきか判断しにくくなります。逆に、相談前に少しだけ整理しておくと、見積相談や初回相談がかなり進めやすくなります。完璧な資料を作る必要はありません。まずは、現在の流れ、困っていること、使っている資料、希望する結果を箇条書きでまとめるだけでも十分です。特に、開発会社、業務改善の相談先、士業、管理会社、専門家などに相談する前は、こちら側の状況を整理しておくことで、相手からも具体的な提案を受けやすくなります。私は、業務フロー図作成、開発前の要件整理、Excel・EC受注業務の改善整理、管理規約見直し前の論点整理などを出品しています。その前段階として、「まず自分の状況を整理したい」「何を相談すればよいかわからない」「見積相談前に確認

「業務を改善したい」「システム化したい」「Excel作業を減らしたい」そう思ったとき、すぐにツール導入やシステム開発を考えたくなります。しかし、実際にはその前にやるべきことがあります。それは、今の業務の流れを見える化することです。業務の流れが見えていないまま改善を始めると、次のような問題が起きやすくなります。・どこで時間がかかっているのかわからない・誰が何をしているのか説明できない・Excelや紙の転記がどこで発生しているかわからない・システム化すべき範囲が決められない・開発会社に相談しても、説明が曖昧になる業務フロー図を作ると、作業の順番、担当者、使っている資料、判断ポイント、手戻りが見えるようになります。特に中小企業や小規模チームでは、業務が「人の経験」や「いつものやり方」に埋もれていることが多くあります。その状態で改善を進めると、問題の本体ではなく、目についた作業だけを変えてしまうことがあります。先に業務フローを整理しておくと、・なくせる作業・まとめられる作業・自動化できる作業・人が判断すべき作業・システム化しない方がよい作業を分けて考えやすくなります。つまり、業務フロー図は単なる図ではなく、改善やIT化の地図になります。「何から整理すればよいかわからない」「今の業務を一度見える化したい」「開発や自動化の前に、現状を整理したい」そのような場合は、まず業務フロー図を作るところから始めるのが安全です。現在の業務の流れを一度見える化したい場合は、出品中の「業務フロー図作成」サービスで整理できます。───────────────「読んだら、自分の業務フローも見てみたくなった」方へ

Future Sync K 代表の小湊茂雄です。私のプロフィールを見て、「AIエンジニアなのになぜ『経営コンサルティング』までできるのか？」と疑問に思う方もいらっしゃるかもしれません。実は、私はシステムエンジニアとしてキャリアをスタートさせたわけではありません。不用品回収や遺品整理といった、泥臭い「実業」の最前線で、20年間にわたり会社経営を行ってきました。ゼロから事業を立ち上げ、年商3億円規模まで拡大させる中で、幾度となく地獄のような苦労を経験しました。そして、世界中を襲った未曾有のコロナ禍。この時、私は「迅速な事業縮小（撤退戦）」という、拡大以上に難しい経営判断を迫られました。従業員の生活を守るため、全員を独立させて事業を譲渡し、私自身は身一つで再スタートを切る決断をしました。だからこそ、私には経営者の皆様が抱える「血を流すような痛み」が痛いほどわかります。毎月の固定費の重圧、集客の悩み、人手不足、そして「無駄な投資をしてしまった」ときの後悔。世の中には、「お客様に言われた通りのシステム」を思考停止で作る開発者がたくさんいます。しかし、それが本当に経営課題の解決（売上向上やコスト削減）に繋がらなければ、ただの「高額なおもちゃ」に過ぎません。経営者だった私からすれば、そんなものに1円も払わせたくないのです。私がシステム開発において「売上」や「利益」に異常なほどこだわる理由はここにあります。最先端のAI技術も、RPAも、Webサイトも、すべては「ビジネスを成功させるための手段」でしかありません。私は、単なる外注業者としてではなく、「どうすればこの会社の利益を最大化できるか」を共

前回に続いて、私が実際に手がけた事例をお話しします。今回は、お客様クレームの原因になっていた「査定金額のバラつき」を、システムで解決したときの話です。(守秘のため、具体的な社名や数字の詳細はぼかしています)⚪︎きっかけは、お客様アンケートの指摘だったその業務を見直すきっかけになったのは、お客様アンケートでした。集計してみると、金額に関する指摘が想像以上に多かったんです。「人によって金額が違う」「説明と最終的な金額が合わない」そうした声が、いくつも寄せられていました。業務は回っているつもりでも、お客様の側ではしっかり不満が溜まっていた。アンケートが、その事実を突きつけてくれました。⚪︎原因は「合計金額が見えないまま進む」流れにあったなぜ金額のバラつきやクレームが起きるのか。業務の流れを追っていくと、原因がはっきりしました。当時、査定は手書きの伝票で行われていました。そのため、査定の時点では合計金額が分からない。項目をひとつずつ書いていって、最終的な合計は、会計の段階で初めて判明する、という流れだったんです。つまり、お客様は合計金額を知らないまま査定を終え、会計で初めて総額を見せられる。そこで「思っていたより高い」「さっきの説明と違う」となり、クレームにつながっていました。さらに手書きゆえに、担当者によって金額の付け方にもバラつきが出ていました。⚪︎その会社専用の査定アプリを作ったそこで、その会社の査定業務に合わせた専用のアプリを開発しました。ポイントは、査定をしながら、その場で合計金額が自動的に表示されることです。これによって、流れが大きく変わりました。査定が終わった時点で合計金

こんにちは！高倉友彰です。フリーランスのシステムエンジニアとしてスタートアップの現場で仕事をしていると、日々多くのクライアントから新しいWebシステムやAI活用の相談をいただきます。変化が早くて真っ白な未来のキャンバスに、新しく何かを描いていくような仕事は、いつも私に大きなワクワクを与えてくれます。そんな開発の現場で、私はいつも日本の伝統的な遊びである折り紙のことを思い浮かべています。今回は、私が日頃から心がけているシステム設計のこだわりについて、少し変わった角度からお話しさせてください。折り紙は、最初はただの平らで四角い一枚の紙にすぎません。しかし、角と角をきれいに合わせ、丁寧にしるしをつけて折っていくことで、美しい鶴や様々な形へと姿を変えていきます。このときに最も大切なのは、最初の土台となる折り目をいかに正確につけるかということです。最初の数手が少しでもズレてしまうと、後からどれだけ綺麗に折ろうとしても、最終的な形が歪んでしまいます。システム開発もこれと全く同じです。新しくサービスを立ち上げるとき、要件定義やデータベースの設計といった初期の段階で、どれだけ丁寧で強固な土台を作れるかが、その後のシステムの運命を左右します。特に私が得意としているバックエンドの開発やAPI設計は、まさに折り紙の最初の一手のようなものです。目に見える派手なデザインではありませんが、後から新しい機能を追加したり、ユーザーが急増したりしたときにも、柔軟に対応できる美しい構造をあらかじめ仕込んでおくことが、エンジニアの腕の見せ所だと思っています。近年、ココナラでもご相談をいただくことが増えた生成AIとの

みなさん、こんにちは！AIシステム開発エンジニアの白川です。今、SNS（TikTokやInstagram）の副業ジャンルで、圧倒的にバズりやすく稼ぎやすいと言われているのが「占いビジネス」であることをご存知でしょうか？「顔出し不要で始められる」「定年後のストック型ビジネスに最適」と、参入する方が非常に増えています。しかし、実際に始めた方の多くが、ある「2つの大きな壁」にぶつかって挫折してしまっているのが現実です。その壁とは……毎日のショート動画のネタ切れと、編集作業の大変させっかく依頼が来ても、数千文字の鑑定書をイチから書くのに数時間かかる負担集客のための動画作りに追われ、売れたら売れたで鑑定書の作成に夜通し追われる……。これでは「自由な時間を手に入れるための副業」のはずが、ただの重労働になってしまいますよね。そこで、プログラミングやAIの知識が全くない方でも、ボタンを1クリックするだけで「集客動画の台本」と「プロ級の鑑定書PDF」を同時に爆速生成できる【あなた専用の自動化Webアプリ】を開発しました！🔮 この自動化ツールでできること使い方はとてもシンプルです。あなた専用のWeb画面を開き、相談者の「名前」「生年月日」「お悩み」「占いたいテーマ（恋愛・仕事など）」を入力してボタンを押すだけ。たったこれだけで、最新のAIが裏側で働き、以下の2つを同時に作り出します。① バズる構成の「TikTokショート動画台本」冒頭3秒で視聴者を強烈に惹きつけるフックから、プロフィール欄への誘導まで、TikTokのアルゴリズムを徹底的に研究した「黄金構成」の台本を自動生成します。あとはこれをコピ

「業務システムを作りたいけど、いくらかかるのか見当がつかない」「見積もりを取ったら高すぎて、そっと閉じた」システム化を考える方が最初にぶつかるのが、この費用の問題です。私は事業会社で複数の業務システムを作ってきて、さらに外部の見積もりも数多く見てきました。今日は、ベンダーに頼む前に知っておくと損しない「費用の考え方」をお話しします。⚪︎なぜ見積もりは数百万円〜になるのか業務システムを業者に頼むと、小規模でも数百万円、規模によっては1000万円を超える見積もりが出てくることがあります。高く感じるかもしれませんが、理由はあります。要件定義、設計、開発、テスト、それぞれに専門の人が関わり、人件費が積み上がるからです。さらに、納品後の保守として月額数万円が継続的にかかるケースも多いです。つまり、従来のシステム開発は「人手をかけて作る」前提なので、どうしても高額になりやすい構造でした。⚪︎費用を左右する3つの要素見積もりの金額は、主に次の3つで決まります。ひとつ目は、機能の多さです。あれもこれもと盛り込むほど、当然ながら金額は上がります。ふたつ目は、連携の複雑さです。既存の会計ソフトや他システムとつなぐ場合、その分の手間が加算されます。みっつ目は、作り方です。完全オーダーメイドで一から作るのか、既存の仕組みやAIツールを活用するのかで、費用は大きく変わります。逆に言えば、この3つを抑えれば、費用はコントロールできます。⚪︎「全部入り」を避けるだけで費用は下がる費用が膨らむ最大の原因は、「念のため、あれもこれも」と機能を盛り込むことです。実際には、最初から全機能を使うことはほとんどありませ

情報システムの活用は、企業活動のスピードや業務効率に直結する重要な要素です。現在では多くの企業がさまざまな場面で多種多様なシステムを導入しており、その規模や開発費用も年々拡大しています。場合によっては、システム開発の成否が企業の将来を大きく左右することもあります。しかしながら、こうした重要性にもかかわらず、システム開発の現場では依然として多くのトラブルが発生しています。トラブルを未然に防止するためのガイドライン等も整備されていますが、それでもなお、トラブルを十分に回避できているとは言い難いのが実情です。システム開発委託契約とはシステム開発委託契約とは、企業（ユーザ）がベンダに対し、業務用システムやアプリケーションの開発を依頼する契約です。法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点を中心に論じられることが多いといえます。契約類型により報酬請求権や責任範囲が異なるため、業務内容、仕様、納期、検収方法、知的財産権の帰属、損害賠償の範囲などを具体的かつ明確に定めることが重要です。Webシステムを開発対象とする場合には、プログラミングの問題だけではなくクラウドサービスの提供のあり方を踏まえた総合的な開発契約を考える必要があります。システム開発契約の法的性質システム開発委託契約の法的性質については、通常、請負契約か、それとも準委任契約に当たるのかという点から論じられることが多いといえます。 これは、ユーザを委託者とし、ベンダを受託者とするシステム開発委託契約において、その契約の趣旨が、システムを完成させることであれば請負契約、開発作業を遂行することであれば

こんにちは。今回は、最近手掛けた「AI音声を用いた英単語学習Webアプリ」の開発プロジェクトを通じて、技術的に工夫した点や、エンジニアとして大きく成長できたと感じたエピソードを共有したいと思います。これからWebアプリ開発をご検討されている方や、同じように要件定義や技術選定で悩んでいるエンジニアの方の参考になれば幸いです。プロジェクトの概要と技術スタック今回のプロジェクトは、学習塾向けに「生徒がスキマ時間で効率よく英単語を記憶できるアプリ」を開発するというものでした。【採用した技術スタック】・フロントエンド: React, Tailwind CSS・バックエンド/データベース: Firebase (Firestore, Storage, Authentication, Hosting)・外部API: Google Cloud Text-to-Speech API (Neural2モデル)特にこだわったのは「音声の品質」です。単なる機械音声ではなく、Google Cloudの最新AIモデル（Neural2）の女性ボイスを採用し、さらに少し早めの再生速度（1.2倍速）に設定することで、単語帳アプリに最適な「キビキビとしたネイティブに近い発音」を実現しました。システム構成としては、管理者画面から英単語をExcelで一括登録した際、未生成の音声データをGoogle Cloud APIにリクエストし、生成された音声ファイル（mp3）をFirebase Storageに保存。そのダウンロードURLをFirestoreの各単語データに紐付ける、というフルスタックな処理を実装しています。直面し

業界のリアルを深く知ることから始まるDX。屋根工事業者様との二人三脚で得た「真の業務効率化」とシステム開発の裏側皆様、こんにちは。フリーランスのITコンサルタント・システムエンジニアとして活動しております、「EFFORK SYSTEMS」の前田と申します。私がEFFORK SYSTEMSとして掲げている最大のミッションは、単に「言われた通りの仕様書通りにシステムを作る」ことではありません。お客様の現場に日々潜み、業務効率化の妨げとなっている「根底のボトルネック」を的確に見つけ出し、システムやアプリ開発という形を通じて根本から課題を解決すること。そして、その先のビジネスの飛躍へと繋げ、多くの方々に貢献していくことです。本日は、先日無事に完全納品を迎えた、ある屋根・外壁リフォーム業者様との「提案シミュレーション・見積りアプリ開発」のプロジェクトを通じて、私自身が強く感じたこと、そしてシステム開発において本当に大切なことについてお話しさせていただきます。■ システム屋が「屋根工事のプロ」の思考を学ぶ理由現場で「本当に使える」システムを作るためには、プログラミングやITの知識だけでは全く不十分です。お客様が日々どのような業務を行い、どのような視点でお客様（施主様）と向き合っているのか。その業界の「リアル」を深く理解しなければ、真に役立つツールは絶対に生まれません。今回の開発にあたり、私は屋根工事という専門的な業界の実情について、お客様から非常に多くのことを学ばせてもらいました。例えば、スレートやガルバリウム鋼板、日本瓦といった「屋根の素材ごとの特徴や耐用年数、メンテナンスの周期」。そし

お店を運営する上で欠かせないのが予約管理世の中には数多くの予約システムがありますが、正直に言って「高すぎる」と感じたことはありませんか？ 便利な機能がついているのはわかりますが、毎月数万円の固定費は、個人経営や小規模店舗にとってはかなりの痛手。売上の数％をシステム利用料として払い続けるのは、まるで終わりのない「月謝」を払っているようなものです。 「DM予約」の限界。お客様は意外とシビアです 「じゃあ、インスタのDMやLINEで直接やり取りすればいいのでは？」と思うかもしれません。 確かにコストはゼロですが、そこには大きな落とし穴があります。 返信待ちのタイムラグ：「今すぐ予約したい」お客様にとって、数時間の返信待ちはストレスです。 ダブルブッキングの恐怖： 手動管理はミスがつきもの。 予約のハードル：「わざわざメッセージを送るのは面倒…」と、検討段階で離脱してしまうお客様は意外と多いのです。 いっそ、あなただけの「自作システム」を持ちませんか？ 月額費用に悩み、手動管理に疲弊しているなら、**「自分の店専用の予約システム」を構築する**という選択肢があります。 「システムを作るなんてプロにしか無理」と思われるかもしれませんが、今はノーコードツールや特定のプラットフォームを活用することで、以前よりもずっと身近に、そして自由に作れる時代です。 独自システムがもたらす「3つの解放」 1. ランニングコストからの解放一度作ってしまえば、毎月高い利用料を払い続ける必要はありません。維持費を最小限に抑えられます。 2. 「痒いところに手が届く」機能性一般的なシステムでは「ここがこうだったら

こんにちは。大藏(大蔵)陽平と申します。システム開発という仕事を10年続けてきて、技術以外に自分の中で育ったものがあります。それが「論理的思考」と「柔軟な対応力」です。この二つは、一見すると相反するように聞こえるかもしれません。でも実際の開発現場では、この両方が同時に求められる場面が何度もありました。論理的思考は、要件定義の段階から鍛えられます。クライアントの要望を整理し、何が本当に必要で、何が優先されるべきかを構造的に考える。感情や思い込みを排除して、課題の本質を見極める力はコードを書く以前に必要なものです。システム開発は、論理の積み重ねで成り立っています。一方で、開発が進む中では必ず想定外が起きます。仕様の変更、環境の違い、予期せぬバグ。そのたびに「こうあるべき」という固定観念を手放し、状況に合わせて最善策を考え直す柔軟さが求められます。論理だけでは解けない局面を、何度も経験してきました。この二つの力は、開発の仕事を通じて自然と身についたものです。そして今では、仕事の外でも活きていると感じています。物事を整理して考えること、状況が変わっても落ち着いて対応すること。システム開発が、思考の土台をつくってくれました。ご依頼いただく案件には、この10年で培った論理と柔軟さの両方を持って臨みます。技術的な課題でお困りの際は、お気軽にご相談ください。

「予約システムほしいけど、月額が高い…」 サロンや教室を運営していると、予約管理は避けて通れない問題です。 電話やLINEのメッセージで予約を受けて、手書きでカレンダーに書き込んで…。 正直、めんどくさいですよね。 かといって、ホットペッパーは月額が高い。Reservaやクービックも、予約件数が増えると有料プランに切り替えなきゃいけない。 実は、LINE公式アカウントとGoogleの無料ツールを組み合わせれば、月額0円で予約システムが作れます。 この記事では、その仕組みと導入方法をざっくり解説します。 使うもの（全部無料）・LINE公式アカウント → お客様との窓口（月200通まで無料）・Google Apps Script (GAS) → 予約処理の自動化（無料） ・Googleカレンダー → 予約枠の管理（無料） ・Googleスプレッドシート → 予約データの記録（無料） サーバー代もかかりません。全部Googleの無料枠内で動きます。 仕組み（ざっくり）お客様がLINEで「予約する」をタップすると、こんな流れで自動処理されます。① LINEで「予約する」ボタンをタップ ② 予約フォームが開く（カレンダーから日付・時間を選ぶだけ） ③ GASが自動でGoogleカレンダーに予定を登録 ④ 同時にスプレッドシートにも予約データを記録 ⑤ LINEにお客様への確認メッセージを自動送信 ポイントは、空いてる時間だけが選択肢に出ること。 Googleカレンダーの予定を見て、埋まってる枠は自動で非表示になるので、ダブルブッキングが起きません。 月額制の予約システムとの比較「無料って

「全カテゴリランキング１位」＆「AIカテゴリランキング１位」を頂いた記念に、その記録を残して置きたいと思います！（閲覧数の変化なども、記録していけたらなと思います！）納品の内容の概要や金額については、下記URLのブログに記載しています！https://coconala.com/blogs/4162706/568012📊 ランキング記録メモ2025年5月8日・全カテゴリランキング：19位・AIカテゴリランキング：1位2025年5月9日・全カテゴリランキング：1位（全944,483件中）・AIカテゴリランキング：1位（全2,679件中）2025年5月10日・全カテゴリランキング：1位（未確認）・AIカテゴリランキング：1位（未確認）2025年5月11日・全カテゴリランキング：1位（全945,371件中）・AIカテゴリランキング：1位（全2,703件中）2025年5月12日・全カテゴリランキング：2位（全945,575件中）・AIカテゴリランキング：1位（全2,706件中）2025年5月13日・全カテゴリランキング：2位（全946,152件中）・AIカテゴリランキング：1位（全2,716件中）2025年5月14日・全カテゴリランキング：1位（全946,491件中）・AIカテゴリランキング：1位（全2,727件中）2025年5月15日・全カテゴリランキング：18位（全946,905件中）・全カテゴリおすすめ：101位（全674,143件中）・AIカテゴリランキング：1位（全2,738件中）・AIカテゴリおすすめ：1位（全2,256件中）2025年5月15日・全カテゴリランキング：---

先週から業務合理化を狙ってGoogleのアプリケーションで仕様とフローを考えつつプログラムをセコセコ作ってた。会社に提案したけどいろいろと社内ルール上の影響があり提案内容は結局ボツになった。しかしそれは想定範囲内だったので社内ネットワークだけで利用できるシステムを作る方にシフト。しかし残念なことにワイにそれを作るスキルがない・・・というか時間がかかるので社外のエンジニアに頼むことにした。ということは、ここまで考えたことを仕様書にまとめあげる必要が出てきたのであった。要は頭の中にあるイメージを言語化＆図式化しなきゃならん。なのでソッコー要件定義書を作り上げた。（突貫だったので1日で仕上げた）昨日無事にエンジニアの人と話して案件のボール投げることができたので少し安心できたかな。前の職場でシステム部の仕事に携わってて良かったと思えた瞬間である。何事も経験って活かせるよねwww

これくらいなら簡単にできるでしょ？と言われることがあります。特に、見た目が少ししか変わらなかったり、短時間で完了するとそう感じるかたもいらっしゃるかと思います。もちろん、表記の変更の様な実際に簡単なものもあります。でも、システムの修正の場合は高確率で見た目よりは工数がかかる場合が多いです。Hot Linux でお引き受けする仕事でも、爆速で完了するケースがあります。これは、Hot Linuxの技術力が高いからなんです。過去の経験と知識をフルパワーで投入するから爆速で完了することがあるのです。なので、本職じゃない人が自分で修正しないでください。時間ばっかりかかります。プロに任せて、クライアント様自身は本業に専念してください。https://coconala.com/services/1689980

比較的多いご相談に「何かのアクションを起こした（アクションが起きた）時にメールで通知したい」というものがあります。よくあるケースだと・アンケートや問い合わせフォームが入力された時に担当者にメール通知したい・申し込みがあった時に、申し込みしてくれた人にメール通知したい・データ入力が完了したタイミングで、次の担当者にメールで通知したい昔からある仕組みなのですが、近年セキュリティが強化されてきて以前のプログラムだとうまく送信できないケースがあります。コンピューターに迷惑メールと判断されてしまうのです。言うまでもありませんが、Hot Linuxでは、迷惑メール判定されにくいプログラムで実装しています。#hotlinuxhttps://coconala.com/services/1689980

こんにちは。大藏(大蔵)陽平と申します。フリーランスのWebシステム開発者として、今年でキャリア10年目を迎えます。要件定義からインフラ構築、そして運用保守に至るまで、システム開発の全工程を一貫して経験してまいりました。ココナラをはじめとする場所でも、日々多くのクライアント様から「新しいシステムを作りたい」「既存の仕組みを改善したい」といった様々なご相談をいただきます。その一つひとつの案件に向き合う中で、私が何よりも大切にしていることがあります。それが「誠実と責任感」という姿勢です。システム開発は、単にコードを書いて動かせば終わりというものではありません。お客様が抱えている事業上の課題の本質を見極め、それを技術の力でどう解決し、ビジネスの成長にどう貢献できるか。そこまで深く寄り添って初めて、本当の意味での価値が生まれます。時には複雑な要件や予期せぬトラブルに直面することもありますが、だからこそ逃げずに原因を突き詰め、最後までやり抜く。その誠実な姿勢と強い責任感こそが、クライアント様からの本当の信頼を生み、長く愛されるシステムを創り上げる原動力になると信じています。「大蔵さんに頼んで本当に良かった」そう言って安心していただける瞬間が、エンジニアとして何よりも嬉しい瞬間です。技術的な課題をクリアし、お客様のビジネスの未来を共に創り上げていくこと。それが、私の譲れない使命です。システム開発でお困りのことがございましたら、ぜひ安心してお任せください。最高のかたちでプロジェクトを成功へと導きます。