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


人の良いジョンカビラと言われます。
AMN sponsor rolls
モバツイッター
Google Friend Connect
Sinap Christmas Project
F's Garage関連
このカテゴリ[会社活動]の最新30件
結局、この年になっても尾崎に学ぶか。。。 リアルビジネスのネット化のキープレーヤーとは?! ネットがきっかけで既存ビジネスの価値が失われるってどんな時だろう。 ネットで発言するユーザーの意見はどこまで尊重可能か やる夫と、安倍礼司と矢沢栄吉 ベンチャーのウェブサービスの初期コストにアイディア料は入ってませんよ。 cronの読み方 それおかしくね?「ますます遠のく海外旅行」 多重下請け構造の何が悪なのかが全然わかりません。 企画でもエンジニアでもどっちでも良いです。 グローバルとガラパゴス 10年後のコンピュータ excel2007の近似曲線の数式の桁表示が足らなくて困ってる人の数 → Dr.HOUSEに見られるスモールチームマネジメント 受託のメリット、Webサービスのメリット リーマン潰れたとか。 数字は借りるものじゃなく作るもの エンジニアの未来サミットのログ見てみた。 企業の目的は金儲けではありません キャッシュしないQRコードメーカー ライセンスビジネスとオープンビジネス ホウレンソウに罪はない! 点検商法 AmazonのkindleとiTunes Store 何故、Linuxはデスクトップで普及していないのか?を読んで。 ソフトウエアエンジニアの底力は時間外活動で培われる、けどね。 オトナ買い的にミニ四駆を作った 大学生が言う「コミュニケーション能力」の過剰さ 技術力とタレント性 新卒採用は人材投資枠だから利用しなきゃ損損
[このカテゴリをもっと見る]
thatsPing
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件
リアルとネットの融合を進めるために。 twitterのタイムラインは一期一会で良い 【本日20:00より】「WebSig New New分科会」をセミッターで放映しますー。