「できるかどうかは別」としないWebサービスの企画

  • このエントリーをはてなブックマークに追加

こんにちは。株式会社8bitの高本です。

会社でWebサービスを企画する際によく、「できるかどうかは別として(技術論は抜きにして)」という前提で物事を進める場合がないでしょうか?
個人的には結構ありました。

最近、なるべく注意しようと心がけているのですが、「できるかどうかを別にする」と、技術的な問題と開発の時間的な問題で、絵に描いていた企画の8割程度もしくはそれ以下しか実現できない、もしくは結局実現できない、という場合が多いように思います。

当社でも敢えて自由な企画と発想で考えようということで、そのように企画を進めたりもしました。

進め方が悪かったんでしょうけど、結果アイデア帳にアイデアばっかり集まって、想像していたものの劣化版しかできていない、そんな経験もかなりあります。

それで、後で揉めましたり、会社としても結構苦い思い出もあります。

最近はアイデア以降の段階、実現するための企画の段階でなるべくエンジニアにも参加してもらうようにしています。
あんまり企画のアウトラインの部分からだと、開発に支障が出るので、もう少し具体的になってからにしてもらうこともありますが。。。

コンテンツありきのサービスなどは違うかも知れませんが、「技術論は後回し」で進めると、Webサービスの場合はかなりの確立でよろしくないかと思います。

もちろん技術論だけではなく、ユーザー目線で考えるというのはすごく大事だと思いますし、本来そうあるべきなのかも知れません。
ですが、せっかく考えた企画やアイデアは実現しなくては、何の意味もありません。

こういった意味で企画へエンジニアの参加を推奨するのですが、ではなぜ、この「できるかどうかは別として」という前置きで企画を進めることになってしまうのか今回は考えてみました。
(かなりエンジニア寄りかも知れませんので、予めご了承ください。)

もちろんうまくやっている会社もたくさんあると思いますので、あくまで参考までに!

どうして「出来るかどうかを別として」企画するということになるのか?

まずは、技術力もかなり重要なWebサービスで、エンジニアを企画に入れないで進めようとする理由を考えてみました。

1. エンジニアにはどちらかというと開発に力を入れてもらいたい。

これは別に良いのかなと思います。
作業分担というものがあるので、極力開発に専念してもらいたいですよね。

だからエンジニアも仲間はずれにされたとは思わないようにしたいものです!

2. エンジニアは機能の減算から始まることがあり、企画自体が進まない。。

すべての人がそうではありませんが、基本的にエンジニア(プログラマー)は業務においては自分の工数を削ることを優先します。
いかに効率よくプログラムを書くか、いかに面倒な作業(データ作成など)を効率化するかを常に考えています。

工数についても予期せぬバグの修正や開発段階でのトラブルなど様々な要因を考えます。
慎重なんです。

ですので、やったことないことや、できるかどうかわからないことについては、エンジニアはかなり工数を多めに言ってくるものです。

でも、これは優秀なエンジニアでもある証拠です。
出来るかどうかも分からないものに安請負して結局できないよりは、確実な工数と確実な技術的な知見により自分の意見を出しているのですから。

でもWebサービスはスピード勝負というところもあるので、企画している側にとっては早くリリースしたいと思います。
ここでちょっとしたすれ違いが起こるのではないでしょうか。

この間でのやきもきした感じが技術者不在のまま企画を進める原因になっていたりします。

よくあるエンジニアと企画者の認識のずれ。


エンジニアのすべてが万能にプログラミングできるわけではありません。

PHPは出来てもPerlはほとんどしらない、C言語は触ったことない、などプログラムも色々な種類がありますので、ネットサービスといっても人によって出来る範囲はあります。

技術的なことを詳しくない方に、ここにすごく勘違いをする方が多いように思います。
(エンジニアならなんでもできると思っている方。)

最近はiPhoneやスマホアプリも出てきて、インターネットをつないで出来ることが、誰にでもわかるほど発達しています。
インストールするアプリだから出来ること、Webサービスだから出来ること、この違いがよく分からないで進めると、自社のエンジニアで対応できない場合があります。

アプリとWebサービスの違いも良く分からないで「あったらいいな」だけを優先していくと、かなりすばらしい企画・アイデアが出来ると思いますが、実際に工数を出してもらったら実現に1年かかるとか、そういうことにもなりかねません。

エンジニアが「できない」と言う場合は正確には「やったことがないので時間がかかる」という意味も含まれています。
やったことのない言語であれば1から習得する必要がありますし、1から言語を覚えるということはそんなに簡単なことではないのです。
(たまに「面倒くさい」も含まれていたりしますが。。)

少なくとも会社でWebサービスを開発しようとしているなら、自社のエンジニアがどういうスキルがあるのかを理解しておくべきです。
自分でプログラミングまでできなくても基本的な概念を企画者も知っておくべきかと思います。

エンジニアと企画者が一緒に進めることのメリット。

知らない間に企画だけが進んで、いざ開発の時点で「これをつくって欲しい」といわれると、ちょっとした疎外感を覚える方も少なくないと思います。
(なんとなく仲間はずれにされたという感じ)

人間は感情の生き物なので、ちょっとしたコミュニケーションでぎくしゃくしたりします。
一緒に進めることによって、まずはコミュニケーションは取りやすくなるのかな、と。

あと、一緒に企画を進めることのメリットとして、納得のうえで作ることで品質が上がる。
これはエンジニアも一緒に参加して何をしたいか、どういう目的で作るのか?などを共有することで納得のうえ開発するので、品質が上がります。

作らされている」より「納得して作っている」方が断然品質が上がります。

ですから企画者がエンジニアにきちんと「何の目的で」「どんなことを実現したい」ということをきちんと説明しないといけません。
そうすることで、出来ないことがあっても、代替案を出して一緒に作り上げていくことが可能になります。

——–

そう考えていくとエンジニアに企画力が付いたらすべて一人で完結して効率良いのではないか?という感じがしてきます。
個人サービスなんかがそうなんでしょう。

長々と書きましたが、なかなか思ったようにはうまくいかないものです。

執筆者:高本

株式会社8bit 取締役の高本です。 社内のWebサービス企画、プログラミングや、売上・請求管理にいたるまで幅広く担当しております。

関連記事

プログラミング

【PHP】ソーシャルログインに対応したお話(LINEログイン編) ②

前回はLINE Developersでチャネル登録までを行いました。 今回は実際にPHPでログインを実装していきます。 目次1 初期設定を定数にする2 LINE ログインのURLを作成する3 コールバック時の処理4 最後に 初期設定を定数にする 最初にdefineでチャネル登録した情報やAPIのURLを定義します。 メールアドレスを取得したい場合はLINE_SCOPEに「email」を追記してください。 LINE ログインのURLを作成する LINEログインに利用するログイン […]

Webサービス

【PHP】ソーシャルログインに対応したお話(LINEログイン編) ①

今回はLINEログインです。 LINEログインは他のソーシャルログインと違って、電話番号必須なので、ユーザーがアカウントを無限に発行するということがなく、しかもOSに関係なくアカウントを使用できるので、特にB2Cサービスを考える場合には是非導入を進めたいと思います。 逆に法人サービスで使う場合、法人担当者が個人のLINEアカウントを使用することはないと思うので、あくまで個人向けサービスがよいかなと思います。 LINEログインについての概要はこちらに詳しく書いています。 htt […]

プログラミング

【PHP】ソーシャルログインに対応したお話(Apple ID編) ②

目次1 前回のおさらい2 実装に必要な情報3 PHPで実装してみる4 戻り先の処理4.1 composerでライブラリのインストール4.2 処理の説明4.3 実際のソース5 最後に 前回のおさらい 前回は「Appleでサインイン」を実装する前の下準備をまとめました。 今回は実際にPHPで実装をしたいと思います。 なお、ソーシャルログインについて実はFirebase上でできるぽいのですが、今回はそれを使わずに実装したいと思います。 実装に必要な情報 前回Apple Develo […]

株式会社8bit (エイトビット)

東京都目黒区でWebサイト制作、Webシステム開発などを行っております。
コーポレートサイトやWebサービスの企画・提案を得意としており、自社での経験を元にアイデアをカタチにするお手伝いをさせていただいております。

Web制作に関するご相談はお気軽にどうぞ

弊社に制作をご依頼いただく際の費用感をご確認いただける、
見積りシミュレーションをご用意いたしました。