mixiの運営方針は面白い

何の警告もなくサクサクとユーザーのアカウントを削除する上場企業mixi。
当然、日記やプロフィールなどのデータは全て消えてしまいます。

私は純粋にこの運営方針を面白いと感じました。

株主の利益に反するユーザーや広告収入に繋がらないユーザーは、どんどん切り捨てた方が企業価値が向上するというのは、１つの経営方針としてアリだと思います。
※mixiの場合は、活発なコミュニケーションがないと判断したら無警告でアカウントを削除するようです。

通常は、そのようなユーザーがいた場合、アカウントを削除するという結果が既に決まっていたとしても、名目的に警告を発するケースが多いです。

しかし、mixiはそんなまどろっこしいことはしません。

サクッっと消します。

消しても「私が悪いことしたのかな？」と逆に恐縮してしまうネット初心者ばかりだから、それほど大きな騒動にも発展しないという幸運も合わさって、mixiは今日も安泰です。

失敗しないシステム開発の結論。そして検証編へ

[数ヶ月の放浪から帰ってまいりました…]

システム開発会社の中で仕事をしてきたわけでもない（非システムエンジニアという意味において）単なる一般人である私が、システム開発について失敗しない方法として最終的に落ち着きつつある結論は

『システム開発準備段階のシステム設計書（要求仕様書）を完璧な状態にする』

ということです。
（薄々分かっていたことではありますが…）

完璧な状態とは、「開発着手後から納品まで一切の仕様変更をしない」という前提で記載した書類（ドキュメント）のことです。
つまり、開発依頼者にとっては「要求仕様書＝納品物」ともいえる状態に持って行くわけです。

さて、そうなると準備段階（書類作成段階）において、システム開発依頼者には驚異的な負担とプレッシャーが掛かってきます。

なぜなら、開発前段階であるが故に相談できるシステムエンジニアやプログラマーがいないという状態を覚悟する必要があるからです。


そこで、「システムについての知識が無くてもシステムの設計を可能にする方法」を確立しなければなりません。
少なくとも、システムエンジニアが見て「これなら●●の工期で費用は■■円くらいかなぁ」と、見積もりの概算を弾き出せるレベルに仕上げる必要があります。

まず、開発言語やデータベース、サーバーやネットワーク構造などをどうするかという部分は完全に無視します。
すでに制約がある場合は別ですが、普通はいきなり「開発言語は何にします？」と聞かれても「ハァ？？？いや…別に…決まっていませんが？」です。

楽天ビジネスの見積もりサービスなどでは、開発条件について詳しく記載する部分がありますが、正直なところ「何を書けばよいのか」すら分かりません。
システムエンジニアの側にすれば、そんなことも決まっていないのに見積もり取らせようとするなよ！という感じなのでしょうが、分からないものは分からないのですから仕方ありません。

仕方ありませんので、技術的な部分は敢えて空欄にしておきます。

その代わり、別の情報で補います。

それが

【Why：目的】
　…　システムや機能の目的
【Who：利用者】
　…　システムや機能のユーザー（人だけでなく別の機能がユーザーになることもあります）
【What：扱う情報・データ】
　…　商品・メールアドレス・名前・住所・ID情報など
【How：機能】
　…　どんな処理をするのか。データを表示する、メールを送信する等
【When：利用時間】
　…　WEBシステムなら365日24時間が普通でしょうか。機能なら、どんな場合にその機能が起動するのか等
【Where：利用場所】
　…　WEBシステムならインターネットに接続された場所。機能なら、ログインした状態、こういう場合など制約条件になると思われます。
【How many：利用頻度】
　…　WEBシステムなら、１日どれくらいのアクセスがあるか。会員サイトであれば利用人数など。機能なら１時間に１回、１年に１回など。
　　　具体的に数字で表現することが重要。ちょっと少なめ等のあいまいな表現は出来る限り使わないように心がけること。

の5W2Hの７項目で記述された機能・システムの説明です。

具体的には次のような感じになります。

開発すべきシステムは、【Why：目的】の為に【Who：システム利用者】が【What：システムで扱う情報・データ】を【How：機能】するものです。
このシステムは【When：利用時間】【Where：利用場所】において【How many：利用頻度】使われます。

このシステムで必要になる機能は、【Why：目的】の為に【Who：システム利用者】が【What：システムで扱う情報・データ】を【How：機能】するものです。
この機能は【When：利用時間】【Where：利用場所】において【How many：利用頻度】使われます。


複雑なシステムになるほど構成要素としての機能も増えますが、単純な機能に分解して考えることでシステムエンジニアではなくても複雑なシステムを設計できます。
一言でいえば『5W2Hで説明される機能の集合体によって5W2Hで説明されるシステムを作る』ということです。

実際には、まだ理論に過ぎません。本当にこの方法で上手くいくのか検証を行う必要があります。
理論的には、この方法を使えば、"紙"の状態で銀行のオンラインシステムの設計も可能な筈です。


次からは検証編に入っていきます。
（最終的には銀行のオンラインシステムの要求定義書を公開するところまで行きたいですね）

失敗から何を学ぶ？

WEBシステム開発になぜ失敗するのか？

「勉強不足」「事前の準備不足」が全ての原因でした。オシマイ！

…では、全く進歩がないので、こういう状況を回避するにはどうすればよいのかを考えます。
そもそも、勉強不足・準備不足などという原因は、一度失敗といえるような経験をすれば誰でも分かることでして、そこに原因があること自体はあまり重要ではありません。

失敗を経験することなく、失敗要因を潰すことが出来れば、発注者・開発者・ユーザー全てがハッピーになれるはずです。少なくとも、今よりは良い方向へ進むと考えます。

とはいうものの、発注者がエンジニアレベルの知識を身につけたり、逆にエンジニア側が発注者側の業界や業務内容について精通するように持って行くのは、理想ではありますが現実的ではありません。

http://itpro.nikkeibp.co.jp/article/OPINION/20060515/238003/

営業から開発そしてサポートまでオールマイティなスーパーエンジニアでさえ、見つけるのが難しい現状では、それに加えて客先の業務にまで精通しろ、とは言えませんし、時間の無駄です。
SEはS（セールス？システム？サポート？）についてのE（エンジニア）なのですから、あまり余計な仕事を押しつけるのは酷でしょう。
故に発注者としてもそこまでは望みません。もし、スーパーエンジニアに巡り会えたらラッキーくらいに考えています、今では。


システム開発の発注者と開発者の歩み寄りは、必要ですが、厳然たる限界がある現実を考えると、どうしても別の方法による解決策を見いださなければなりません。

その一つが、前にも書いたエージェントの存在です。
完全に独立した、システムコンサルタント・システムアナリスト・開発アドバイザーです。
当然、数千万～億円規模の開発案件であれば、存在するでしょうが、小中規模の案件でエージェント的に働く人はあまり聞きません。

需要は非常に高いと思われます。
問題は、仕事としてカネになるのか？という部分でしょう。

仕様書やプログラム設計書の作成代行、顧問契約を締結した上での技術指導やアドバイスが主な仕事内容になると思われますので、税理士や弁護士が契約書作成や相手方との交渉を代行する場合に似ていることを考えると、顧問料収入をベースとし、個別の書類作成案件でプラスアルファに持って行くのがエージェントの一般的な収入体系となりそうです。

誰か、カリスマエージェントとでも呼ばれるような人が出てきたり、テレビで注目されれば一気にメジャーになる可能性を秘めている仕事ではないかと思っています。


まあ、中小規模案件対応型エージェントは、あくまで個人的なアイディアの域を出ていません。ただ、野球の契約更改にエージェント（代理人）が当たり前に出てくるような昨今、例え小規模でもシステム開発でエージェントが登場しないのは、むしろ不自然な気がしませんか？