すべてのカテゴリ

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

アプリ開発のプロジェクトを成功させるためには、開発に着手する前の段階で「何を作るのか」を明確にする必要があります。その中心となる工程が 要件定義 です。要件定義は、アプリの目的や機能、使う人、利用環境、スケジュールなどを整理し、関係者全員が同じゴールを共有するための設計図のような役割を持ちます。要件定義の役割開発の方向性を決めるどんなアプリを作るのか、どのような価値を提供するのかを明確にすることで、開発の進め方や優先順位がぶれにくくなります。関係者間の共通認識を作る発注者・開発者・デザイナーなど多くの人が関わるため、認識のずれがあると後々大きな修正が発生します。要件定義はそのズレを防ぐ役割を持ちます。コストや納期の見積もりの基礎になる機能や画面構成、使用する技術を事前に整理しておくことで、開発期間や必要な人員、費用の見積もりが現実的になります。要件定義で整理する主な内容目的・課題の明確化なぜこのアプリを作るのかどんな課題を解決するのかどのような価値をユーザーに提供するのかターゲットユーザー想定する利用者層ユーザーが利用するシーンや端末ユーザーが求める体験や課題機能要件実装すべき具体的な機能画面の構成や動作の流れデータの入力・保存・取得の仕組み非機能要件セキュリティやパフォーマンス利用するプラットフォーム（iOS・Android・Webなど）保守や運用の方法、バックアップ体制開発体制とスケジュール担当者や役割分担開発・テスト・リリースまでの工程と期限進行管理やレビューのルール要件定義をきちんと行うメリット仕様変更による手戻りを減らし、開発コストを削減できるチーム全員が目指す完成形

このテーマを考えるとき、私はいつも、ジェリド・メサがライラ・ミラ・ライラがジェリド・メサに言った言葉を思いだします。「装甲越しに殺気を感じろってんだろ？」 すいません。ガンダムネタです。可能であるなら、募集内容やヒアリングシートの向こうの気配を感たい。その向こうにはリアルな世界がある。 リアルな世界の、リアルな悩みがある。 もはや妄想に近いですが、それでも業種やその文章表現から推測されることはある。 今回はそんなヒアリングについての話を書いてみます。 これはノウハウの話ではなく、私はそのように楽しんでいますという話です。ヒアリングはお客様との初めての共同作業♥ 皆様は「デザイン思考」をご存じでしょうか？ ざっくり言いますと、デザイナーの思考を一般的な課題解決のためにフレームワーク化したものです。 詳細気になる方はググってみてください。 とにかく、デザイン思考というフレームワークがあります。 このフレームワークの１段階目が「共感」となっています。 ヒアリングして、お客様などの意見を聞いて、まず課題意識を「共感」する、ということになっています。 実際私も、まずはどういう課題を認識しているのかを探ります。 デザインのはじめの一歩は「共感」と言っていいともいます。 共感というからには、デザイナーだけでは成り立ちません。 その元にあるのはお客様の認識です。 想いであったり、客観的な情報であったりです。 それはココナラの募集内容であったり、ヒアリングシートであったりします。この段階でどれくらい想像できるかは色々限界はあります。ですが、これはお客様と私たちデザイナーとの初めての共同作業なんで

こんにちは。大藏(大蔵)陽平と申します。フリーランスとして10年システム開発に携わってきてプロジェクトの成否を分ける最大のポイントは「要件定義の精度」だと確信しています。どれだけ実装技術が高くても、最初の認識がずれていると完成物がクライアントの期待と噛み合わない。その経験を何度か経て、ヒアリングの質を上げることに真剣に向き合うようになりました。今回は、私が実際に使っているヒアリング時の質問テクニックを3つご紹介します。①「それが実現したとき、何が変わりますか？」クライアントが「こういう機能が欲しい」と言ったときその機能自体ではなく、その先にある変化を聞く質問です。「作業時間が減る」「担当者の負担がなくなる」など具体的なゴールが見えてくると、本当に必要な機能の輪郭が明確になります。②「現在、どのように対応していますか？」現状の運用フローを把握することで、システムが「置き換えるもの」と「新しく作るもの」の区別がつきます。既存の業務フローを無視した設計は、現場に馴染まないシステムになりがち。現状を丁寧に聞くことで、現実に即した提案ができます。③「誰が、どのくらいの頻度で使いますか？」利用者像と使用頻度が明確になると、UIの複雑さやパフォーマンス要件の優先度が自然と決まってきます。「全社員が毎日使う」のか「管理者が月1回使う」のかで作るべきものはまったく変わります。質問の目的は情報収集だけではありません。クライアントが言語化できていなかった課題を、対話の中で一緒に整理していくプロセスそのものが、信頼関係の土台になると感じています。ご相談はお気軽にどうぞ。

Webサイト制作、アプリ開発、業務システム構築──。どんなプロジェクトにも必ず存在するのが 「要件定義」 という工程です。名前だけは聞いたことがあっても、「実際に何をするの？」「仕様書を作ること？」といったイメージのまま進むケースも少なくありません。しかし、要件定義は プロジェクトの成功率を大きく左右する“最重要フェーズ” です。この記事では、要件定義とは何か、どこまで決めればよいのか、そしてなぜ重要なのかをわかりやすく解説します。■ 要件定義とは “何を作るか” を明確にする作業要件定義とは、プロジェクトの目的・ゴール・必要な機能・制約条件などを整理し、「最終的に何を作るのか」 を明確にする工程です。簡単にいえば、「お客さんの“やりたいこと”を、作る側が形にできるレベルまで言語化・整理する」そのための話し合いと資料作成のこと。やることが曖昧なまま制作に入ると、・作ったけど使われない機能・追加修正によるコストの増大・スケジュール遅延など、後から大きな問題が発生しがちです。■ 要件定義で決める主な項目要件定義で扱う内容は多岐にわたりますが、代表的な項目は次のとおりです。◎ 1. プロジェクトの目的（Why）なぜ作るのかどんな課題を解決したいのか成果のイメージ（売上アップ、業務効率化、問い合わせ数増加など）目的が曖昧だと、どんな機能が必要か判断しづらくなります。◎ 2. 対象ユーザー（Who）誰が使うサービスなのか年齢層・行動・ニーズどんなシーンで触れるかユーザー像は機能設計・UI設計の基盤になります。◎ 3. 提供したい価値・機能（What）必須の機能（Must）あれば嬉しい機能

ココナラでは誰でも一度は経験すると思います。ご依頼された方が明確なビジョンや、仕様を考えていないケースを。みなさん、わからないから、出来ないからココナラで頼みに来ているのだと思いますが途中でやりたい事を増やされるとカオスです。その防止の為に、予め今回の依頼はこれですよね？と、きちんと箇条書きにする事（要件定義書の作成）が必要ですが、なかなか難しい。困っている人の力になりたいけど、力になろうとするとカウンターをくらってしまうと言う。。。。。何をやりたいのか、その為に何が必要なのか、きちんと決めるのも仕事のうちだとすればココナラの最低価格3000円は妥当なのでしょうか？個人的には5000円くらいが妥当だと思います。（お客様のフトコロに余裕があればですが。）

１．趣旨祝・成人の日。ご成人おめでとうございます。みなさんがこれから活躍できるよう応援し、ご多幸を願っています。さて、今日からゲーム作りに挑戦してみます。プログラミング上達のコツは、理屈から入らず、自分で作ってみることです。作ったプログラムを動かしてみて、思った通りに動かなかったら原因を調べて・・・の繰り返しでスキルは磨かれていきます。本を読むだけでは、プログラミング言語を「使いこなす」ことはできませんので、今回のような挑戦がみなさんのプログラミングのきっかけになっていただけると嬉しいです。まずはどんなゲームを作るか決めます。ソフトウェアの機能や仕様をまとめたものを要件定義といい、ゲームに限らず情報システムやソフトウェアの開発で最初に行う作業です。これまでに紹介したJavaの開発技法であれば、CUIのゲームを作れると思ったので、下記に要件をまとめました。また、今回は日本の利用者向けのゲームを作りますので、日本語のみでブログを書いていきます。２．要件定義① 1 〜 13の中でランダムな数字が表示される。その数字を除いた1 〜 13の中で、次に出てくる数字がそれよりも大きいか小さいかを予想するゲーム。大きいと予想する場合は「b」を入力し、小さいと予想する場合は「s」を入力。他の文字を入力した場合は、メッセージで警告された後に再入力する。② 10 Goldを所持した状態でゲームスタート。0 Goldからbetできる。betするGoldが所持Goldよりも多い場合は、メッセージで警告された後に再入力する。0未満や数字以外を入力された場合も、警告された後に再入力する。③ 予想が当たれば、

こんにちは。大藏(大蔵)陽平と申します。システム開発において、プロジェクトの成否を大きく左右する工程の一つが「要件定義」です。実装やデザインに目が向きがちですが、実際にはこの初期段階でどれだけ認識を揃えられるかが、その後の進行を大きく左右します。要件定義で最も重要なのは、「何を作るか」だけでなく「なぜ作るのか」を明確にすることです。目的が曖昧なまま進めてしまうと、途中で方向性がぶれたり完成後に期待とのズレが生じたりするリスクが高まります。ビジネス背景や課題を丁寧にヒアリングし、本質的なニーズを言語化することが欠かせません。また関係者間での認識のズレを防ぐために、具体的なイメージ共有も重要です。画面イメージや簡単な仕様書を早い段階で用意しできるだけ解像度の高い状態で合意形成を図ることで後工程での手戻りを減らすことができます。進め方としては、一度で完璧を目指すのではなく段階的に精度を高めていくことを意識しています。初期段階では大枠を整理し、その後フィードバックを受けながら細部を詰めていくことで、現実的かつ柔軟な要件定義が可能になります。これまでの経験から要件定義は単なる作業ではなくプロジェクト全体の土台を築く重要なプロセスだと考えています。お客様のビジネスにしっかりと寄り添いながら、目的に沿った最適な形を一緒に作り上げていくことを大切にしています。誠実に対応いたしますので、ぜひ安心してご相談いただければと思います。

ご覧いただきありがとうございます。すごくざっくりした依頼を見かけることがあります。もちろん、やりとりの中で要件を整理していきますが、やりたいことが明確にならないと、やるべきことが見えてきませんよね。とあるアプリを使いこなせるように指南して欲しい、という依頼がありました。しかし、そのアプリでできることはとてもたくさんあります。言ってしまえば、ほぼ何でもできます。主観的・感覚的な目標は、あれもこれもと、やることが多くなりそうで、客観的な形で妥協点を決めないと、なんだか永遠に終わらない危険性があるなあと感じました。残念ながら、それをきちんと調整する能力が私にはないなあと思ったので、その件は提案を見送りました。壊れた羅針盤（曖昧な目標）では迷子になってしまいます。その案件に提案を提出している方は10人以上いらっしゃったので、まだまだ、私も未熟者ですね。（あくまでも個人の見解です）

— 質問のない記者会見では、広報や営業の文章は作りにくいAI に文章を書かせようとするとき、つい「うまい指示を書かなければ」と考えがちです。でも実際には、そこで詰まっているとは限りません。広報や営業の文章がぼやけるとき、問題は言い回しの下手さよりも前にあります。何を伝える文章なのか。誰のどんな疑問に答える文章なのか。どこまで説明し、どこからは今回扱わないのか。そこが整理されないまま AI に頼むと、長いだけで焦点の定まらない文章になりやすいです。このときに必要なのは、いきなり本文を書くことではありません。先に FAQ を作ることです。ここでいう FAQ は、公開用の想定問答集に限りません。AI と文章を作る前に、「何を問うべきか」を整理するための質問集です。なぜこの話題を扱うのか。誰が読むのか。何が詰まりなのか。反対意見が出るとしたらどこか。今回は何を扱わないのか。こうした問いを先に置くと、AI とのやり取りはかなり安定します。この感覚は、記者会見にたとえるとわかりやすいです。質問のない記者会見は、ほとんど成り立ちません。発表だけして終わるなら、それは一方向の告知です。記者会見になるのは、何を問われるのか、どこを確かめられるのか、何に答えなければならないのかがあるからです。広報や営業の文章も同じです。問いがないまま書くと、言いたいことの羅列になりやすいです。その結果、「何を見ている人なのか」が伝わらなかったり、最後だけ急に営業っぽくなったりします。特に、広報と営業は同じ質問では作りにくいです。広報の文章では、誰のどんな詰まりを扱うのか。その問題をどう見立てているのか。なぜその混

要件定義は、エンジニアリングの第一歩であり、プロジェクトの成功を左右する最も重要な工程のひとつです。私はこれまで、金融系の大規模システムからスタートアップのSaaS開発まで、数多くの要件定義に関わってきました。一見すると、要件定義とは「何を作るか」を決めるための作業。しかし実際は、それ以上の意味を持つ対話のプロセスです。クライアントの中にある言語化されていない課題や、未来の構想を丁寧にすくい取る。そこにこそ、この仕事の奥深さがあります。例えば、ヒアリングの中で「こういう機能がほしい」と言われたとき、それをそのまま受け取るのではなく、「なぜそれが必要なのか」「どんな課題を解決したいのか」と一歩踏み込む。この対話を積み重ねることで仕様書は単なる設計図ではなく、ビジネスの未来を映す戦略書に変わっていきます。仕様を決めるのではなく、意図を汲み取る。これが私が大切にしている姿勢です。ココナラでは、要件定義から技術選定、設計・開発・運用まで、ビジネスの本質に寄り添った支援を行っています。仕様書のその先へ。一緒に理想を形にしましょう。