【例題】SNS構築な仕事頼まれました!

人気の記事:

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

コメント

  1. みゃ より:

    まず営業さんが頼まれたのは見積りなのでそこから。

    システムの簡単な案からそれに見合ったハードウェア構成や

    回線設備の提案、開発費用などがあればいいのですかね。

  2. こぉせぇ より:

    難しいお題ですねぇ・・・。

    とりあえず、私の経験から。

    不特定多数の人間が使うものであるから

    ユーザー・インターフェイスを

    大事にしないといけないと思います。

    ドギツイ色遣いで疲労感を増大させたり

    面倒な操作で疲れないように

    その部分のデザインに金を掛けます。

    それからハード構成やら何やらって事を

    決めていったほうが良いんじゃないかなぁと。

    きちんと設計して、拡張時に対応できるように。

  3. こぉせぇ より:

    企業向けのシステムしか作ったことがないけど、

    一番最初は、ユーザーのニーズを把握することから!

    ?現存するSNSを徹底的に調査。

    ?ユーザのニーズを徹底的に調査。

    ?コマーシャル費を取り分けておく。

     ※他のサイトにリンク貼ってもらったり

    をするかな。。。

    いくらシステムを完璧に仕上げてもユーザが付かなかったら無用の長物になるし。

    >だいじんさん

    拡張性は大事ですね。

    まずユーザーをつけて、次にバックボーンの強化!

  4. cancel より:

    10万人登録で100人同時使用というのは見積もりが甘いと思います。同時利用者数は1%程度が適当かと思いますが・・・そこらへんのデータってどっかにないかな?

    バックボーン整備は面倒なので既存で十分に太い回線がない場合はホスティングしてしまうのが手っ取り早いと思います。

  5. Simon より:

    私ならシステムの要件抽出よりも先に、リサーチとコンサルティングをしますが、実際にこういう場面に出会った場合、リサーチとコンサルティングの必要性が分かってもらえないことが多いですね。

    なので、お客さんに「SNSで何をしたいのか? 既存のものと同等ならいいのか? 何か特徴を出したいのか?」というところだけは明らかにしてもらいます。

    とりあえず、この条件からだけで見積もりを出すと、GOになってから「あれがやりたい、これがやりたい」とか言い出されてデスマーチの予感。

  6. Simon より:

    をぉー。勉強になりますです。

    さすがですね。

    前回の書き込み、経験の前段部分は

    私がネットで趣味のホームページを作った時に

    強く思った事ですので。

    リサーチとコンサルは同じ趣味の友人の

    BBSへの書き込みに頼ってましたから(苦笑)

  7. Simon より:

    趣味ならそれでいいんですけど、よほど親しくなければ仕事でそれをやると顰蹙物ですしね。

    余談ですが、たまに技術系MLで仕事の内容丸投げな質問してるのとか見ると、「アホかこいつわ」と思いますが、殆どの場合黙ってます。たまに仏心で答えてやったりすると、図々しく聞いてきたりするので、その時は「仕事なら金払ってちゃんとわかる人雇った方がいいよ」と答えます。

    先ほどの投稿での目的の明確化ができた時点からは、その内容によって説得なり調査なりに入ります。

    儲け第一主義でやるなら、いきなり見積もり出していきなり開発して、後はしらねえとトンズラします。でもそれやると先がないので、常に顧客開発しなきゃならない罠。

    # そういうビジネスモデルの会社、結構知ってますけどね。(苦笑)

  8. みゃ より:

    それじゃ、この場合は「SNSを作りたい」って言って来た所が

    どうやって儲けを出すか? まで考えているのかを知っておかないという事なんでしょうか?

    図々しい質問かもしれませんが、思い切って質問してみました。

  9. みゃ より:

    脱字:「と」が一個抜けてました。訂正します。

    それじゃ、この場合は「SNSを作りたい」って言って来た所が

    どうやって儲けを出すか? まで考えているのかを知っておかないと

    という事なんでしょうか?

    図々しい質問かもしれませんが、思い切って質問してみました。

  10. みゃ より:

    まず、客先が何を思ったのか何種類かあると思います。

    1.とりあえず流行り物だから先に作ってみようと思った

    2.何らかのビジネスモデルを作り出したい為にやってみようと思った

    1では話題的に面白くないので、SNS を利用したビジネスモデルを画策する為にまずはコア部分を構築したい、という話が聞けた事にしては如何でしょうか。

    更に求められる用件として更に以下を追加された感じかな。

    ・機能拡張が時間掛からないで作れるようにしてよ。

    ・何かこう、ワークフロー的なものが追加できると良いな。

    どうでしょう?

  11. Simon より:

    とりあえず、確実に言える事。

    それは、ルールを守ってもらわないとって事です。

    できれば、マナーを守って欲しいと思います。

    それが出来ないと、デスマーチになってしまいますから。

    例えば、このコミュニティでは「オハツの挨拶」が有ります。

    確かに、発言者の名前をクリックすれば、その方の何がしかの

    バックグラウンドは見えるかもしれません。

    でも、管理人さんがわざわざ作ってくれたトピックで

    挨拶をする事もせず、いきなり核心に迫る発言をされても

    場が荒れるだけだと思います。

    これは、職場でも一緒だと思います。

    管理人さんは、優しそうな雰囲気ですので、雑談用にも

    トピックを作ったりと上手く進めるには?と考えているみたいです。

    それに応える事なく(汲み取る事もなく)このコミュニティが進んだ場合

    管理人さんばかりに負荷が掛かってしまいます。<デスマーチ

    下手したら、トピックも潰れかねないと思います。<赤を出す?

    技術系MLは参加した事は有りません。過去ログを漁れば雰囲気掴めますし。

    やれ、過去ログ読め!だのFAQ見ろ!だの。

    参加する気も無くなりますし。

    私は、このコミュニティが自分の仕事に活かせれば良いなと思って参加しました。

    できれば自分から退会する事はしたくないと思ってます。

    もちろん、管理人さんからメンバー削除されたら仕方の無い事ですし

    発言の削除をされる事を覚悟しています。

    もちろん、スレッドキラーになる可能性も有るのですが(苦笑)

  12. Simon より:

    ビジネス的には、どこかでコスト回収したいはずだし、儲けに全く繋がらないのに先行投資する会社があったら、ちょっと怖いですね。

    当然そういうことは考慮にいれてシステム設計もやらなきゃいけないし、プロジェクトマネジメントとしては絶対に必要なことです。顧客が何を目指しているのか、何を求めているのか。

    技術屋として要件抽出して、システム組み上げるだけでいいというならそれはそれですが、私の場合はシステム開発の場合はプロジェクトマネージャー的立場に立つことが多いですし、コンサルティングとセットになっていることも多々ありますから、そうなってくると顧客のターゲットとするものと、それに伴うニーズというのは把握せねばならないものリストの上位に来ます。

    後はケースバイケースです。

    で…、私非難されてます?

    ここって挨拶必須だったんですか?

    私もコミュニティいくつか作っていて、挨拶用スレッドは必ず作ってますけど、そっちに発言しないで、盛り上がってるスレッドにいきなり書き込む人なんて沢山いますし、そんなこと気にもしませんが。

    ルールとかマナーとか言われてしまうとねえ…。

    挨拶必須ってコミュニティの説明に書いてあるならまだしも。

    ルール違反だってんなら消えます。

    だってそんな「暗黙のルール」知らないですもの。

    「空気読め」とかそういう奴ですか? 顔も合わせてないのに。

    過去ログやFAQ読んで雰囲気掴めるMLの方がよほどマシです。

    場が荒れました? 私荒らしですか?

    ああ、こういうこと言うと荒らし認定されるわけでしょうが。

  13. みゃ より:

    ま、落ち着いてくださいまし。

    挨拶は無くても構わないですし、コスト感覚は普通に必須だと思うので、あの様な形での展開は普通だと思いますよ。

    客は儲け話になりそうだから案件を出してみる、ただ感覚的なものでしか無いからそこからどうコンサルしていくか、と言う事もシステム構築で大切になってくる要素ですからね。

    で、個人的に先行投資の件ですが5000万円クラスの先行投資なら実際にやっているプロジェクトはあったりします。

    (5000万って規模小さいし・・)

    実際にコスト計算して貰えると解るかと思いますが、実際に要員4名程度で半年間やれば 5000 万円くらい掛かるカナと思います。

    自分の意見を言う際に、理由を言った上で議論展開するのでしたら荒らしでも何でもないですよね。

    個人的に、今回の件は自分の意見を言った上で展開しているわけですから荒らしでも何でもないと思います。

    逆にそう言う考えもあるのだと再認識出来るのではないですかねぇ。

  14. Simon より:

    トピックを止める事が無かったので良かったです。

    Simonさん、ありがとうございます。

    的確な発言内容を読み、消えられると困ると思いました。

    過激な発言になった事も申し訳無いと思っています。

    馴れ合いも嫌いなので真剣に考えようとしましたが

    ちょっと眠たいので勘弁してください。

    取り急ぎ、これだけは書いておこうと思いましたので。

  15. Simon より:

    えーっと、管理人さんが書いてくれた事の中で

    「要員4名程度で半年間やれば」とありますが

    単純に4名程度居れば、と考えるのは危険かな?

    といつも思っています。

    この手の話は、物・金・技術ばかりに目を向けがちで

    システムを構築する人の事が疎かになりがちだと思います。

    そういった意味で、11の発言になった事をご理解頂ければ

    有り難く思います。

    なんと言っても、自分の生活に大きく関わる事ですから

    私も真剣に議論して行きたいと思っていますので。

  16. Simon より:

    いやあ、先行投資というのは儲けに繋がるかも?と思うから先行投資するわけで、直接的ではないにせよ儲けのことは考えてるわけですよね。

    ですから、その儲けとして想定する額が大きければ大きいほど、先行投資に投入できる額も増えていくわけで。

    そういう点で、儲けに「全く繋がらない」先行投資などないのかもしれないのですが、クライアントの強みと全く関係がないことにいきなり手を出すようであれば、「何故、何を、どうやって、どうしたいんですか?」という情報は集めておかないと後でヤバイことになる可能性は高いですね、という主旨でした。

    ちょっと略しすぎたかもしれませんね。

    で、非難云々についてはちょっとヒートアップしすぎましたが、普通に話題に参加したつもりで、やり取りをしていたらいきなりああ言われたらちょっとねえ。朝っぱらから気分を害しました。

    まあ、私が余計な技術系MLの話など持ち出したので、何か逆鱗に触れたのかもしれませんが。

    9番までの投稿に対して、「顧客のビジネスモデルについては知らなくてもいい場合もあるけれども、情報はできるだけ収集しておくポリシーなので云々」という返事を昨日書きかけていたのですが、途中でIMEが固まって吹っ飛んでしまったので、続きを書くかなと思ってきてみればいきなりこれだったので、ついヒートアップしてしまいました。

    お見苦しい様を晒しまして失礼しました。

  17. Simon より:

    書いてる間に投稿が…。

    ええと、常にリアルタイムで出てくるわけじゃないので…。というかそんなの無理です。

    当然仕事優先ですし、さっき書いたようなこともあります。

    ですから、数時間返事がない時点で「トピックが止まった」とか言われてしまうと困ります。そういうことなら気軽に書けないじゃないですか。

    基本的に、みんな好意なり好きでやってるわけで、相手が返事するしないも含めて全部自由だと思います。それは技術系だろうがそうでないMLだろうが、Web掲示板だろうがSNSだろうが同じです。

    これが仕事の依頼で金もらってやっているなら、返事しないことに対して非難が出ても仕方ないですが、お互い金銭関係も約束もないわけですから、12時間程度返事がないくらいどうってことないと思いますけれどね。むしろビジネスだって遅くはない方だと思いますが。

    その辺は理解しておいて頂かないと、書くに書けません。

  18. Simon より:

    関わる人間の観点は常に必要ですし、だからこそ人月はあてにならないとも言われているわけですが、かといって人数を挙げることに意味がないわけではありますまい。

    システムの規模にもよりますが、4人程度使って半年色々動かしたら5000万くらいは掛かります。で、その情報自体は何と言うことはない話です。そこに噛み付くほどのことでしょうか。

    関わる人の観点を忘れている人なんて誰もいないと思いますよ。で、それがどう11の発言に関わるのかもさっぱりわかりません。人間の質を語ることと、いきなり人を非難することと何の関係がありましょうか。

    真剣に議論したいのはわかるのですが、かといって自分と同じ熱意を相手に求めるのも筋違いですし、自分と同じ理解をすることを求めるのも筋違いです。

    お互い、相手の立場や考え、事情を尊重しつつ議論を交わすことができなければ、実のある議論にはなり得ませんよ。

  19. みゃ より:

    噛み付いたワケではありません・・・・。

    そこまで言われるとちょっと。

  20. みゃ より:

    いやほんと、わかってますので。わかってますよ。

  21. みゃ より:

    個人的には、全然動かなかったトピックが動き始めて嬉しいぐらいです。

    本当にありがとうございます。

    お願いですから、ゆっくり眠らせてもらえませんか?

  22. みゃ より:

    ま、気を取り直して先に行きましょ〜

  23. Simon より:

    いつでも好きに寝てくださいって。(笑)

    好きなときに見て好きなときに書いて。それでいいじゃありませんか。お互いそういうことです。忙しいときもそうでないときもある。しばらく書き込みがなかったら「忙しいのかなー」でいいわけです。

    というわけでこの話は終わり。

  24. Simon より:

    Simonさん、ほんとありがとう。

    雑談もしましょうよ、お互いに。

    色々と溜まってそうですし(笑)

    あと10分ぐらいなら私は大丈夫ですから。

  25. Simon より:

    でもって本題。

    SNS構築の話は難しいですねぇ。

    というのも、SNSって結局サービスなので人が付かないとどうしようもないわけですよね。

    で、既にいろんなSNSがあって、そのそれぞれにいろんな機能があって、今から引っくり返せるような優位性を持ったものが作れるか、と考えてしまうととても難しい。

    下請け仕事で単にシステム組むだけならともかく、ビジネスコンサルティング的な部分を考えてしまうと、唸ってしまいます。

    なんかブレストみたいになってしまいますが…ちょっと思いついたキーワード列挙してみます。ネタになれば幸い。

    FOAFとか取り込むと面白い…のかなあ?

    機能をモジュール化するとか?

    コアシステム+モジュール?

    RDBMS使わないといけないけど、どうする?

    ビジネスユースに特化してみるとか

    帯域の問題は?→UIに関わるぞ

    システムスペックの策定

    機能追加に柔軟に対応できるようにするには?

    うーむ。問題山積。

    脈絡なくてすみません。

  26. tateisu より:

    逆にblog+IM+chanserv,nickservみたいな寄せ集めLAMPアプローチも面白そうですけどね。いかに既存製品の流用で作るか、みたいな。

  27. Simon より:

    実験的要素が強いものだったらそれもいいでしょうね。

    はらはらしながらやる、みたいな(ぉ

    このお題だと、そんなにコンピュータに強くないクライアントがメンテ引き受けるって話なので、それやると自分がサポートで死ぬ羽目になりそうですが。(笑)

  28. tateisu より:

    いや、むしろ保守的なアプローチだと思いますが…?

    各要素の機能面で悩むことは減るわけですから。

    連携する部分とアクセス保護の部分を作りこむことになるわけで。

  29. Simon より:

    各製品にできることしかしない、というアプローチならそれでいいのではないかと。

    クライアントからあれ直してくれ、これ直してくれとか言われて、いろいろいじる羽目になるかなーと思ったので、不安定化しそうだなと思ってああ書いたのですが、説明不足でしたね。

  30. tateisu より:

    簡単な機能追加なら、モジュール化されたblog製品が得意とする部分ですよね。

    大掛かりなのならまとめてリニュするでしょ、普通。

    そのときに既存製品から抜けるかどうするか決めるんじゃないかと。

  31. みゃ より:

    LAMP って不慣れな人だと保守工数が掛かると思っているのですが如何でしょう?

    Linux、Apache な部分は然程でも無いと思いますが、特に RDBMS の運用をやるにはその辺りの知識が必要になりますよね。

    例えばそこに商用ベンダのものを適用してしまい、RDBMS 的な保守を投げてしまうと言う案もあるんじゃないかな、と思うわけですよね。

    そうする事でトータル的な保守工数を落とす手法もあるわけで。

    逆に運用する人が不慣れでは無い場合は LAMP は効果的に働く事も考えられます。

    今回のケースの場合はどちらが最良と思われますかね。

  32. tateisu より:

    個人的にはPの部分はPHPは選びたくないですねー。

    Mの部分は正直何でもいいですわ。

    そういえば機能追加の頻度と既製品の利用は独立した事柄なんじゃ。リサーチをしっかりした上で既製品の改造というのも勿論可能でしょうし。

  33. tateisu より:

    メンテナンスはたいていの製品では管理画面が用意されてるので、ユーザがそれを読めるか、読めないならそこを翻訳する手間をかけるか、などの選択がありますね。

  34. tateisu より:

    ひとつ強調しときたいのは、

    コストを圧縮するために既存blogではなくて

    運用実績や機能熟成を評価して既製品ベースに改造という点です。

    ここを間違うと意味ありません。

    どちらがユーザにフィットさせやすいかという問題は

    勿論残りますが、機能に関しては既製品には

    「ありがちな要望が出尽くしている」利点があります。

  35. みゃ より:

    すいません、ちょっと私が混乱してしまったので教えて下さい。

    既成 blog 製品を改造して SNS で必要と思われる機能を付加していく、と言う形が良いのではないかなという意見ですかね?

    個人的に MovableType のソースなら眺めた事はあるのですが、

    ちょっと SNS 的な機能を付加する接点を見つけられなかったのです。

    blog は記事を書く事をベースに作成されていますよね。

    SNS はモノを繋げていく事をベースに考える必要があるかと思っています。

    何処の部分がベースに出来るとお考えなのでしょうか。

    #nickserv/chanserv/IM の連携って繋がって喋るだけです・・よね?

    #そこの認識が間違ってる?? (^^;

  36. tateisu より:

    一例を挙げたつもりがだいぶ長くなってしまってますね。

    既存のものをなるべく利用しましょうと言ってるだけのはずなんですが。

    私の認識ではSNSはアカウント管理とアクセス制限の中にマルチユーザ対応の日記や掲示板などのサービスを詰め込んだものだと思っています。個別のサービスには特別な点はあまりありません。

    nickservはアカウント管理を行うサービス、chanservはチャンネル(コミュニティに相当?)を管理するサービスです。blogの方からそれらに対して何かクエリを出すような拡張があればとりあえずそういう体裁にはなるでしょう。(そこで止まるかどうかは別として。)

  37. みゃ より:

    あぁ、なるほどです。

    その繋がりが見えない状態だったから「??」という状態になっていたんです。

    nickserv/chanserv の説明をちょっと見ても ircd の拡張としか思えなかったので余計に混乱してたという感じですね。。。

    どうも説明有難う御座います。

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です