愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


モバツイの中の人
マインドスコープ(株)社長
人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイの2つのスマートフォン
アンドロイドアプリ!
アンドロイドアプリ モバツイtouch
全てのスマートフォンブラウザと、Nintendo3DSで! HTML5版Webアプリ「モバツイsmart」
本を書きました!
100万人から教わったウェブサービスの極意 ~「モバツイ」開発1268日の知恵と視点
Google Friend Connect
このカテゴリ[会社活動]の最新30件
バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有 モバツイ、2つのスマホへのチャレンジ「モバツイtouchとsmart」 あなたのシステム開発観は、「動けば良い派」?それとも「ロマン派」? サードパーティツイッタークライアントの生きる道 モノを作る人は、鵜飼いの鵜ではなく鵜飼いの人 ネットは儲かるか?〜1人1円を1億人からもらって1億円売り上げる仕事 映画「ソーシャルネットワーク」の興味深いポイント6点 自分のやりたいことを会社で実現する方法 日本の葛藤 日本をコントロールしているもの 「ぼくはこうしてプログラミングを覚えた」をどう読みましたか? 方向性はあっている、という言葉の危険性 バタラさんとの採用コンテンツ作成秘話 ネットサービス系企業における、積み上げ型タスク管理の危険性 その時、誰がモバツイを必要としたか? - 震災発生から1週間の状況 「ツイッターのおすすめユーザー欄に表示される垢が、同一のグローバルIPアドレスからチョイスされた件」を回避する方法 ツイッターapi利用規約を翻訳しました。 つぶやきから、ソーシャルコマースにならないかを考えています 仕様の決断と、想定外 モバツイのエイプリルフール機能「イマココ(uso)」で、1万ツイート/day突破 モバツイに今いる場所を適当に送信する「イマココ!(uso)」をリリース 仕事のペース 業務ののりしろ ネットビジネスで成功した人は無茶をやってきた人 映画「ソーシャル・ネットワーク」の感想 エンジニアのこだわりと、継続的開発、チャレンジについて。 2010年振り返り2011年これから。 あなたの選択は正社員?非正規雇用? 「このサイトいくらぐらいでできるよ!」のピュア
[このカテゴリをもっと見る]
Powered by
Movable Type

October 24, 2004

Web受託ビジネスの生産性の限界は、SE、ディレクターの数で決まる。いや、そこにビジネス上のボトルネックがあるべきである。

例えば、開発をオフショアするとする。

オフショアのリスクは、アウトプットのクオリティの予想がつかないことである。それはオフショア先のスキルの問題もあるが、何より受託案件という一品一様の仕様をいかに伝え、意識と仕様を共有し、適切な開発をすすめられるか?にかかってくる。

すると必然的にSEは、その案件に永続的に関わり、仕様を理解し、アウトプットを評価し、仕様通りの成果物ができているかをチェックしながら、コミュニケーションしていかねばならない。

オフショアを例に挙げたが、社内開発でも外注でも同じだ。単純に社内であれば甘えられる/頼れる度合いが変わるだけで、本質的にSEが永続的に案件を見ることが失敗しないプロジェクトにおいて重要なことは変わりない。

もしも一人のSEが複数の案件を抱えてしまったらどうなるか?

簡単である。心と時間の余裕がなくなったSEは、必然的に後工程に頼ることになる。
上に書いたとおり社内なら責任を共有しているから、「何とかなってしまう」ことが多いのでまだマシ。しかし、無責任に外注へ責任を委譲することは絶対に避けなくてはならない。

何故なら、相手はそんな責任を取るつもりはさらさらないからだ。ここで意識の乖離が生まれるためプロジェクトは失敗する可能性が高くなる。もし失敗しないとすれば、外注/オフショアの担当者が有能だった場合のみで、それはリスクマネジメントの観点から言うと、あくまでギャンブルに過ぎないことを認識するべきである。
(・・・誰が認識すべきか?というと、マネージャー以上の人々である。)

では、具体的にSEの「永続的な関わり合い」とは、

・設計はなるべく社内で行う、または設計を外注した場合は設計書をレビューし続けリアルタイムで設計内容をSEが把握する。
・開発中はソースコードを随時レビューし、実現していることを必ず理解する。道が外れさせないためには、SEが行くべき道を知ることは重要。
・受け入れ検査として、必ずテストケースを作成し、テストを行うこと。

まぁ至極当たり前のことであるが、SEの工数を単一案件にかなりの数を確保しなくてはいけないことは明らかであろう。

SE工数を割く目的は、

「成果物が道をそれるのを最短時間で気がつくため」

または、

「無能な開発者の存在に3日で気がつくため」

である。それを理解するための基準となる評価点こそが設計であり、評価に必要なアクションがソースコードのレビューである。

もし、設計やソースコードをチェックすることせず丸投げしてしまったら、SEは製品品質を評価することができなくなる。問題点に気がつくタイミングが遅れる。

「気がついたら、全然モノができていなかった」

というのは必然的に訪れる。何故なら、そうならないこと自体がギャンブルだからだ。

大事なのはモノ作りとは、どういう技術で作るか?ではなくて、どのように技術を生かすか?である。この「どのように」が、設計/仕様である。プログラマやデザイナ、コーダーという技術を実現する立場に仕様実現を完全に頼るのはお門違いも甚だしい。

さらに、Web受託は開発後のさらなる改造、機能追加、バージョンアップ、修正はつきものだ。社内の人間が、開発の内容、製品クオリティ、実現手段を理解していないで、まともな改造ができるはずがない。そして、瑕疵責任を実際に追うのは誰だ?

最も重要なことは、外注丸投げプロセスで製品品質が実現できないことに関して、もっとも嫌がるのは、その責任を負わされる立場である現場の社員である。社内のモチベーションをそぐようなことをしたくなければ、外注開発をするときのディレクションをSEがきっちりやっていかねばならない。

この話は、Webディレクターにも適用される話だ。ただ瑕疵責任、バージョンアップ時の精神的負担は開発の方が圧倒的に大きいことも付け加えておく。

そのため、一つの会社におけるWeb受託の生産性、ビジネス規模は、仕様/品質実現を永続的に管理するSEやディレクターの人数で決まるべきである。

以外とSE、ディレクションコストを甘く見ている会社は多いのではないか。場合によっては、手を動かしてないからと全然お金をとってないところもあると思うが、一番重要な役割の人間のお金を取ってないのは、きっと儲からないだろう。

しかし品質実現に、例えばSE一人一案件しかかけられないとしたら、儲からないと思う経営者もいるかもしれません。
でも、そういうものだと諦めてください。安易に効率化して、一人のSEに、本人が、きっちり、こなせないほど複数の案件を持たせようとしてはいけません。打線の要を潰すことで、必ずやデスマーチを招き入れることでしょう。
(本人ができると言っても、単純に信頼しないこと。それ自体がマネージャの責任逃れです。本人の性格も含め、マネージャの目で判断するべきです。)

---------------------
2004/10/30追記
このエントリ微妙に好評なんですが、僕としては否定されるとか、そんなの当たり前だよ、べらんめいとか言って欲しかったりするわけです。

じゃないと、どこ行っても同じなんですねーという悲しいことになってしまうわけですが。

■同じカテゴリ[会社活動]のエントリー
<<前の記事 逆起電力というネガティブな発想の仕組み
>>次の記事 Flash Conference(2004)
■このblogの書き込み最新3件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有