事業の特徴と基本方針

全工程対応の強みの発揮

私は現在までのウェブサイトやシステム構築では、大変ありがたいことに、多くの経営者の依頼者と直接のやりとりをさせてもらっています。
企画段階で経営者としての事業のお話をお伺いし、やりたいことの具現化、課題の解決のために全工程を対応してきました。

私が全工程の対応ができる理由は、下記の3つです。
1つ目は、私はビジネス・インテリジェンスをもち、日々社会や経済的な動向を注視しているからです。
2つ目は、私は今まで多くの案件に従事して、時として非常に難しい要件や制約に遭遇することがあっても、解決をしてきたからです。
3つ目は、「フロントエンド（画面側）とシステム側の両方が対応できないと、ウェブに従事する者としてやっていけない」と私は2000年から考え続け、いろいろな案件や役割を通して実践したからです。

日本のインターネット業界では、現在に至るまで、分業体制により職能の細分化が行われてきました。
結果、ウェブサイトやシステム開発全体の必要な知識、技能を持ち合わせていない個人や法人が増えました。
依頼者との商談では、依頼者の言わんとする話が理解できない、あるいはこちらが技術的なことしか言えないでは、まず相手にされません。

多くの案件の依頼者は、自分(自社)の事業や活動は話せますが、技術のことは分からない場合が殆どです。
ウェブサイトやウェブシステムの構築にて、全工程に対応できることが、私は顧客と商談ができる最低条件と考えます。
ビジネスではその場で判断を求められることも多いため、情報や知識があることで、案件の進行を早められます。
誰にでも得意なこと、不得意なことはありますが、何もわからないのとでは違います。

企画寄りの立ち位置

私は元々は開発を背景に持っていますが、現在では企画寄りの立ち位置にいます。
案件の要件をお伺いする時、私は是々非々主義となります。
案件が日本市場を狙いとする場合は、成熟した経済社会動向を踏まえて、私の考えをお伝えします。

「日本では、作れる人は多いが、企画できる人や事を興せる人が少ない」と言われて久しい現在です。
また、日本のインターネット業界では、開発ばかりに思考がある人が多く、企画よりの立ち位置の人は少ないのが現状です。

事業やビジネス展開で、ウェブサイトやシステムを活用したい場合、企画できる人や、企画を支援できる人はどうしても必要になります。
身近でITやインターネットに詳しい人で、誰に相談したらよいかがわからないことが多いものです。
開発側が自発的に歩み寄らないと、決して困っている人を助けられません。

長期に育てて行く姿勢

私は今まで多くの案件に関わってきた中で、結果として及第点に達していると私が考える顧客は少ないです。
うまく行かなかった顧客の多くは、最初はやる気があっても、途中で意欲を失うか、何らかの要因で挫折し、最後は自らウェブサイトやウェブシステムを閉じるか、放置しています。

ウェブサイトやウェブシステムは、一度運用を開始したから終わりではございません。
多くのウェブサイトやウェブシステムには、「完成状態」が存在しません。
一人でも多くの顧客を取り込むには、完成度が低くても市場に出して、後からバージョンアップするものです。
完成状態を待ってから運用開始をしていたのでは、機会損失を招きます。

Windows、macOS、Android、iOSのようなOSがまさに好例です。
半完成状態のデジタル製品として市場に投入し、顧客を取り込み、常にバージョンアップするのと同じ考え方です。

ウェブサイトやウェブシステムは、運用者が事業を続ける限りバージョンアップする必要があるので、長期的な視点で育てる必要がございます。
私は今までに多くの顧客と取引をした中で、ウェブサイトやシステムに対する熱度の差を感じてきました。
本当に本気の顧客は、戦略や修正点を考え、なんとかしようとします。

「ローマは一日にして成らず」で、いきなり成功する案件やプロジェクトはほぼ皆無です。
ビジネスは結局は結果が求められ、結果で見られることが多いです。
途中で一時休憩をしてでも、最後までやりきって何らかの結果を出さないことには、一定の評価は得られません。
何が何でも顧客に結果を出してもらいたいため、私は顧客と一緒になり、私が持っている考えや経験を助言や提案いたします。

課題第一、技術第二

最初は依頼者が抱える問題や課題ありきとして、依頼者で企画内容や要件内容を決めていたとしても、必ずお伺いします。

全ての依頼者が、インターネットやITに詳しくはありません。
しかし、依頼者は自分の事業や活動については話すことができます。
問題や課題、依頼者の状況を知らなければ、案件の方向性、骨組みは見えません。
何が問題や課題であるか、最初に明確に把握しない案件は、目的を必ず見失います。

人間とは、何か問題や課題が発生すると、とかくすぐに使える技術やノウハウに頼りたがります。
ウェブサイトやシステム構築では尚更です。

ウェブサイトやシステム構築の技術的なことは、ネットで調べればなんとかなります。
問題や課題解決をどうやるかは、ネット検索をしても載っていません。
依頼者ともに、問題や課題の解決方法を考えるしかありません。

問題や課題を明確にすることで、その解決に向けた戦略、あるいは解決方法を探ります。
問題や課題の内容次第では、ウェブサイトやシステム以外の手段になるかもしれません。

最小限

コンテンツ、意匠、機能などにおいて、可能な限り無駄を削ぎ落とし、シンプルを目指します。
最初からいきなり多くを投入することは、依頼者からの特段の要望や要件がない限り、私からは提案しません。
無意味なことや機能はやらないことを提案し、本当に必要なことや機能だけを実現するようにお伝えします。

ウェブサイトやシステムは、運営者ないし利用者がいろんなことをやりたいがゆえに、あれもこれもと付け足したがるものです。
コンテンツ、意匠、機能などが多くなればなるほど、運営者及び利用者の双方が訳がわからなくなります。

結果として内容が肥大化し、なぜ追加されたのかわからない機能や情報が残り、誰の手にも負えなくなる事態になります。
やりたいことや目的がわからなくなった場合、利用者からは利用されなくなります。
死んだウェブサイトやシステムは、運営者にとってお荷物となり、遅かれ早かれ運営や維持が立ち行かなくなります。
依頼者にとって最悪なことであるのは明白です。

明快な戦略や方針とシンプルなウェブサイトやシステムにより、依頼者が見通しを立てやすくなります。
利用者の要望や意見の反映、事業環境の変化を反映したい場合、ウェブサイトやシステムにて追加や変更するべき箇所を特定しやすくします。

最小限で機能するコンテンツ、意匠、機能を構成することは、いつも難しいことです。
複雑で人々を困惑させるコンテンツ、意匠、機能の提供とどちらが建設的か、どうやって運営者と利用者の双方がWin-Winの関係になるか、いつも考える必要があります。

より良いものを構築すること

私は依頼者に、新規構築あるいは刷新の開始から、継続的な取り組みの中で、状況に応じた助言、対応を行います。

より良いものを構築することと、一番のものを構築することとは意味が違うと私は考えます。
一番のものを構築して終わりでは、状況の変化にも対応できず、遅かれ早かれウェブサイトやシステムは終わります。
ウェブサイトやシステムは一度構築したら終わりではなく、継続可能な限り運用を続けることが必要です。
運用する中で、当然取り巻く環境も日々変化します。
運用を続ける中で、変化する状況を観察し、どうしたら改善できるか、何が改善に必要なのかという気持ちが大事になります。

依頼者が新規立ち上げであれば、実績、顧客の嗜好、顧客の動向の情報は一切ない状態です。
依頼者として、事業の方向や顧客の動向を模索することが求められます。
模索する中で得られたことを次の企画や展開として活かせれば、依頼者の事業は次に進みます。
このときほど、運用の中で得られる全ての反応、教訓、意見が貴重になります。
これらを元に、より良いウェブサイトやシステムを構築できれば、次に進めます。

結果が出ているウェブサイトやシステムは、長期に渡る試行錯誤を繰り返し、目には見えない地道な努力と対応を行っているものです。

試作品開発

依頼者はとかく早く実物を見たいものです。
実物を見なければ、依頼者が判断ができないことが多々ございます。

私はこの依頼者の傾向を踏まえ、試作品開発を徹底しています。
最初の試作品の完成度は低く、MVP(最小限の価値ある製品)を私が作り依頼者に見せることで、依頼者と私の考え違いを防ぎます。

私は、ブラウザで動かない、実現できない、表現できないものは、開発しません。
実現するかどうかもわからない静止画のヴィジュアルデザインを依頼者が見て、結局後になってその通りにならなかったでは、何のためにその静止画を見せたのか、無意味となります。

もし依頼者から、ウェブサイトのビジュアルデザインのサンプルを求められた時、私はHTMLとCSSとJavaScriptによるモックアップを作成して提出いたします。

最初から完璧は目指さない

私は最初から完璧は目指しません。
いきなり100％のものを目指して、必ずうまく行くことはまずありえません。
何らかの修正や変更はつきまといます。

私は修正をかさねて、後から追い込みで完成度を上げていきます。
修正回数は多くなることもありますが、依頼者との認識相違を解消し、確実に進めていきます。

うまく行かないことが成功の母

いろいろと悩んだ結果、何もしないか何もできずに時間が経過するのは、最悪です。
１つの仮説を持ち、完成度が低くてもMVPを早く開発し、社会や組織内に出して利用者の反応を見る行為が大切だと私は考えます。
社会や組織内に出したウェブサイト、ウェブシステム、ウェブアプリケーションに対し、利用者の反応が最悪だったとしても、開発時には得られなかったこと、想定していなかったことが得られることが多いです。

成功するためには、うまく行かないことを多く経験しないことには成立しません。

アジャイル開発

私は今まで、ウォーターフォール開発の経験はございますので、ウォーターフォール開発での対応は可能です。
基本的に私は、ウォーターフォール開発で素早く開発できない欠点を何度も経験し、素早く開発するためにアジャイル開発を行っています。

実機による表示の重視

特にレスポンシブデザインは、利用者が使用しうる、あらゆる端末や機器に搭載のブラウザで表示確認を行うことで、完全なる品質保証となります。
擬似的な表示ツールや開発環境が揃っていますが、擬似的な表示ツールで表示した内容が、実際の端末やブラウザで表示されるとは限りません。
表示が違っていたために、案件の依頼者と不要な揉め事が起きかねません。
私は実機ありきで開発を行います。

要件定義の徹底

ウェブサイト、ウェブシステム、ウェブアプリケーションの構築で、いずれも私は要件定義の工程は行います。

要件定義を飛ばしたがる依頼者が世の中にはいます。
要件定義を飛ばすことは、見積金額や構築日程の検討及び予測たてを難しくします。
全体が見えない状態で、金額や構築日程がわかるわけがございません。
要件定義飛ばしが原因で、案件の破綻は容易に発生します。

要件定義はやることとやらないことを決めます。
依頼者はその時々にある方針、予算、時間で、やる必要があること、やる必要のないことがあります。
やらないことを決めて、やることで優先順位付けが必要になります。

依頼者が結果を出すには、目的と目標を明確にして、目標とする数字の設定が必要です。
運用をする中で、定期的にどのような目標に達していたいか、マイルストーンを決めるのが要件定義です。

レスポンシブデザインの案件では、「スマートフォンとパソコンの表示に対応すればいい」としか言わない依頼者が存在します。
実際、この要望だけでは必ず揉め事の種になります。

スマートフォンには、今から数年前に発売されたモデルもあれば、iPhone Xのような癖のある表示をするものまで多種多様です。要件定義で検証対象を決定していれば、依頼者と開発者が合意しているため、後で揉め事は起きにくいものです。要件定義をしっかりと行わないから、依頼者と開発者が後で「あの時に言った、言わない」の応酬になります。

多種多様な端末やブラウザにて検証を行う場合、検証の手間が増え、開発料金が上がります。
少ない予算で多種多様な端末やブラウザの表示検証を行うのは、予算、品質、納期の観点から、無理なことです。
依頼者の予算の中でできる開発が何か、要件定義で依頼者と開発者が協議を行い、決定することが必要です。