&Y CONCEPT
大きなシステム開発の案件を受けたときのことです。
プロジェクトの概要を整理し、どのようなシステムを作るのかも資料にまとめ、開発会社へ依頼しました。
自分としては、十分に分かりやすく整理したつもりでした。
しかし、開発会社からは確認事項が次々と出てきて、なかなか開発が始まりません。
「そんなに確認が必要なのだろうか？」
当時は、なぜそこまで細かく確認されるのか、十分に理解できていませんでした。
そんなとき、知り合いのプロジェクトマネージャーから、思いがけない指摘を受けました。
「このプロジェクトは、そのまま立ち上げると失敗しますよ」
今回は、この経験を通じて考えた、何かを作る前に確認しておきたいことについてお話しします。
プロジェクトマネージャーから指摘されたのは、システムの機能そのものではありませんでした。
問題は、そのシステムを利用する事業が、実際にどのように運営されるのかを十分に考えられていないことでした。
誰が、どのような状況で利用するのか。
利用する人には、どのようなメリットがあるのか。
反対に、利用することで負担が増える人はいないのか。
運営する側は、どのような仕事をする必要があるのか。
こうした部分を、実際の利用環境まで想像して設計できていなかったのです。
システムの概要を説明することはできても、そのシステムを使った事業が継続して成り立つかどうかは、十分に検討できていませんでした。
プロジェクトマネージャーからは、このままでは試験運用後に使われなくなる可能性があり、システムの概要そのものを見直した方がよいと指摘されました。
確かに、いくら便利な機能があっても、実際に利用する人がいなければ意味がありません。
また、利用者にとって便利でも、運営する側の負担が大きすぎれば、継続が難しくなることもあります。
システムとして成立することと、事業として成立することは別なのだと、改めて考えるきっかけになりました。
システム開発では、一般的に機能要件と非機能要件を整理します。
機能要件とは、システムに何をさせるのかという内容です。
例えば、利用者を登録する、情報を検索する、データを更新する、通知を送るといった機能が該当します。
一方、非機能要件は、システムをどのような品質や条件で動かすのかという内容です。
処理速度、セキュリティ、同時接続への対応、障害発生時の復旧などが該当します。
どちらも重要ですが、今回の経験から、もう一つ考えておかなければならないことに気付きました。
それが、事業を運営するための仕組みやルールです。
例えば、複数の種類の利用者が存在するシステムを考えてみます。
利用者が新しく登録するとき、誰が承認するのでしょうか。
登録した情報に誤りがあった場合、誰が修正できるのでしょうか。
利用者同士で意見が食い違った場合、誰が判断するのでしょうか。
システムに不具合が起きたとき、誰が対応するのでしょうか。
これらは一般的な検討例ですが、実際の開発では、こうした判断が必要になります。
運用ルールが決まらなければ、必要な機能や権限も決められません。
例えば「情報を編集できる」という機能一つを考えても、誰でも編集できるのか、管理者だけが編集できるのかによって、システムの設計は変わります。
つまり、機能を考える前に、事業としてのルールを決めなければならない場面があるのです。
今回、私が取り組んだのは、システムの機能を増やすことではありませんでした。
もし自分がこの事業を運営する立場だったら、どうするだろうか。
この視点で、仕組みやルールを考え直しました。
利用者はどのような順番でサービスを使うのか。
運営者は、どのタイミングで何を確認するのか。
それぞれの利用者に、どのようなメリットとデメリットがあるのか。
運用を続けるうえで、負担が集中する部分はないか。
システムを動かすための操作だけでなく、その前後に発生する仕事も含めて考えていきました。
その内容を整理し、クライアントへ提案しました。
もちろん、すべてが最初から一致したわけではありません。
こちらが想定した仕組みと、クライアントが考えていた内容には違いもありました。
しかし、その違いが明らかになったことで、こちらが懸念していたことや、検討が必要な部分を具体的に共有できました。
また、エンジニアが不安に感じていた点についても、確認することができました。
結果として、提案内容には改善が必要だったものの、将来的に不具合や設計上の問題につながりかねない部分に、開発前から気付くことができたのです。
今回の経験で、もう一つ考えさせられたことがあります。
それは、お客さんが欲しいと言ったものが、必ずしも本当に必要なものとは限らないということです。
例えば、お客さんから「この機能を追加してほしい」と依頼されたとします。
その機能を作ること自体は、技術的に可能かもしれません。
しかし、なぜその機能が必要なのでしょうか。
何かの仕事を簡単にしたいのでしょうか。
利用者を増やしたいのでしょうか。
それとも、現在の運用に問題があるのでしょうか。
目的が違えば、必要な解決方法も変わります。
場合によっては、新しい機能を作らずに、運用ルールを変更するだけで解決できるかもしれません。
もちろん、クライアントが持っている経験や業界知識は非常に重要です。
ただし、クライアントが事業のすべてを把握しているとは限りません。
同様に、エンジニアは技術に詳しくても、その事業の運営方法まで理解しているとは限りません。
デザイナーも、使いやすい画面を考えることはできますが、事業上のルールが決まっていなければ、適切な操作方法を設計できないことがあります。
それぞれの専門性だけでは、判断しきれない部分があるのです。
だからこそ、プロジェクト全体を見ながら、関係者の認識を整理する役割が必要なのだと思います。
以前は、プロジェクトマネージャーというと、スケジュールや進捗、予算を管理する人という印象が強くありました。
もちろん、それらも大切な仕事です。
しかし、今回の経験を通じて、それだけでは不十分だと感じました。
そもそも何を作るのか。
なぜ、それを作る必要があるのか。
どのような条件が整えば、開発を始められるのか。
誰が何を判断し、どこまで責任を持つのか。
こうした部分を整理しなければ、作業を進めるための的確な指示も出せません。
特に大切だと感じたのは、開発する人に、余計な仕事をさせないための準備です。
決まっていないことを決まっているように伝えれば、後から仕様を変更することになります。
関係者の認識が違ったまま開発すれば、完成したものを作り直す可能性もあります。
もちろん、開発を進めながら決めるべきこともあります。
ただ、その場合も、何が決まっていて、何が未確定なのかを明確にしておく必要があります。
開発会社から確認が続いたことについても、今振り返ると、必要な判断材料が不足していた可能性を考えています。
当時は開発が進まないことが気になっていましたが、確認には理由があったのだと思います。
現在は、AIを使えば、プロジェクトの概要や機能要件、非機能要件などを整理することもできます。
専門的な知識が十分になくても、考えるべき項目を洗い出す手助けになります。
私自身、こうした情報整理にAIを活用することは、有効だと考えています。
ただし、AIが整理した内容が、そのまま正しいとは限りません。
特に、実際の業務や利用環境については、クライアントや現場の担当者に確認しなければ分からないことがあります。
AIは考えるための補助として利用し、最終的な判断は関係者で行う必要があります。
今回の経験を踏まえると、開発前には少なくとも次の内容を整理しておくとよいと考えています。
これらを最初から完璧にまとめる必要はありません。
重要なのは、情報を整理しながら、まだ分かっていないことに気付ける状態を作ることです。
そして、確認が必要な部分を一つずつ解消し、開発する人が判断に迷わない状態へ近づけていくことだと考えています。
今回、クライアントへ改善を提案した際には、認識の違いもありました。
クライアントが考えている内容と、こちらが必要だと考えている内容が異なれば、当然ながら意見が分かれます。
しかし、私はそれでもよかったと考えています。
なぜなら、開発が進んでから問題が見つかる方が、影響が大きくなる場合があるからです。
開発前であれば、仕組みやルールを見直すことができます。
ところが、すでにシステムが完成していたらどうでしょうか。
場合によっては、設計をやり直し、多くの費用や時間を使うことになります。
新規事業やモノづくりでは、一度の失敗が致命的な損害につながることもあります。
だからこそ、最初から意見が一致することだけを目指す必要はないと思います。
もちろん、自分の意見を押し通すことが目的ではありません。
なぜ問題だと考えているのか。
どのようなリスクがあるのか。
ほかにどのような方法が考えられるのか。
こうしたことを丁寧に説明し、クライアントと一緒に判断することが大切です。
将来の大きな衝突を避けるために、開発前の小さな衝突を恐れない。
今回の経験から、そのように考えるようになりました。
プロジェクトマネージャーが、必ずしも事業の成功そのものに責任を負うわけではありません。
契約や役割によって、責任の範囲は異なります。
それでも、関わった以上は、その事業に失敗してほしくありません。
せっかく時間と費用をかけて開発するのであれば、長く利用されるものになってほしいと思っています。
そして、それはシステム開発に限った話ではありません。
新しい商品を作るときも、Webサイトを制作するときも、デザインを考えるときも同じです。
何を作るのかを考える前に、なぜそれが必要なのかを考える。
どのように作るかを考える前に、誰がどのように使うのかを考える。
そのために必要な仕組みやルールを整理し、一つずつ確認していく。
地道な作業ですが、こうした積み重ねが、結果として無駄な工数や大きな失敗を減らすことにつながるのだと思います。
今回の経験を通じて、私は「何を作るか」だけでなく、「なぜ作るのか」「どのように使われるのか」を、以前より深く考えるようになりました。
目の前の依頼を実現することは大切です。
しかし、依頼された内容をそのまま形にするだけでは、解決できない問題もあります。
なぜ、その仕事が存在するのか。
どうして、そのような方法で取り組んでいるのか。
普段の仕事でも、こうしたことを改めて考えてみると、これまで気付いていなかった仕事の本質が見えてくるかもしれません。
株式会社アンドワイコンセプトでは、システムや商品を作ること自体を目的にせず、事業の仕組みや運用まで考えながら、必要な手段を一緒に整理することを大切にしています。
失敗を完全になくすことはできません。
それでも、一つずつ考え、確認し、納得しながら進めることで、より長く使われるものづくりにつなげていきたいと思っています。
Document
こちらのページから、資料をダウンロードいただけます。
Contact Us
こちらのページから、お問い合わせいただけます。
