愛車:マツダアテンザ
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

March 19, 2008

…あくまで「僕の場合」という前置きをつけておきます。

普段、プロデューサーという肩書で、サービスでうまくお金をいただけるように考えて実行する仕事が僕の会社での役割ですが(多分、はてなで言うサービスディレクターかな)、その流れで、たまに新しい何かを実現するためにシステム設計をしたりします。

ずっと開発担当者と並行してソースコードはずっといじっていたのですが、開発とプロデューサーは似て非なる仕事だということに気がついたので、開発は努めて移譲するようにしました。

でも、たまにプロデューサー的思想(「おもてなし」的なのや、もっとビジネスライクなのもある。)を実装に落とすにあたって、さまざまな理由で思いついたことを伝えるのが難しいなーと思う場合は、自分で詳細仕様を書いて、プロトタイプを作ってみたりします。

こういう時につくづく思うのが、昨日まで覚えていたことをシステム設計するとすっぽり忘れてしまうことがあるんですね。

次の日の朝にヌケがあったことに気がついたりする。何故かなーって通勤しながら考えてみたんですが、

「自分が目の前に責任を持たなきゃいけないパラメータがあると、それについて漏れなく対処することを考えるだけで気持ちが一杯になってしまう」

…んだなと。

なんだろ唯心論?と唯物論?の違いみたいなイメージ。

wikipediaより引用
唯心論(ゆいしんろん)とは、人間社会において、心、もしくはその働きこそは至上の要因であるとする哲学の立場。

唯物論(ゆいぶつろん)とは、事物の本質ないし原理は物質や物理現象であるとする考え方や概念。

あくまでもイメージなので意味が伝わらないと思うけど。

プロデューサー的アプローチと、開発者的アプローチは視点の置き場所が違う。

この気持ちを切り替えて両立するのは難しいですね。そもそも作ってみないとわからないところがあるし。

また同様にチームの開発者にモノ作りを移譲しすぎると、人をまたいで同じことになるわけです。

それこそ「おもてなし」の精神を実装に変換する際に必要なのは、実現したい仕様に対する確固たる理念かもしれません。仕様書の最初に、何故それをやるのか?常に忘れてはいけない理念はなんなのか?を書いておく。

それでも具体的な実装(戦略とも言う)に落とし込む際には忘れてしまいます。

後から忘れずに精査して後戻りを許容するプロセスも必要ですね。

仕様書から目をそらして、それが実現するものをじっくり考えるプロセス。
仕様書ドリブンの開発プロセスではないですね。そこまで設計するの無理。

納期の兼ね合いがあるけど、土壇場での改善重要。

その施策を考える動機は、自分の立場、視点から来る考える時間の長さがあってこそなのかもしれないので、これを100%他人と共有するのは結構難しいのです。

そこを伝えるのがコミュニケーション力だろ!ってのは理屈上は理解してるますが、まぁ、なかなか難しい。(放棄してるわけじゃない)

さらに言えば、そこは直感の世界だったりして、必要なのか否かはやってみなきゃわからないというか、全体のバランス感の問題なので、そこだけを議論して理論的に良し悪しを解決するのは難しいのです。

なのでアジャイルが開発プロセスとしては近いけど、もっと外側の世界に動機があるような気がする。

この部分での妥協を許さない調整力は、ジョブスは天才らしいですね。

要はジョブスや子ジョブスの人たちの経験とエゴが今のアップル製品を作ってると考えれば、理論的に解決できることが全てじゃないと思うので、それが実際の開発タスクに関わるときには、それこそ「スーツとギークの調整力」というあたりが重要なのかもしれませんね。

と、何の解決法もない話で申し訳ないですが、いやーなかなか難しいですねぇという話でした。

■同じカテゴリ[会社活動]のエントリー
<<前の記事 lifehacksはツールでしかない。
>>次の記事 融通を利かせることのリスク
■このblogの書き込み最新3件
インターネットの可能性を信じて〜本を書きました。 バルスのツイート機能に関する謝罪を書いたら沢山反応があった件 モバツイの広告の取り組みについて、発表資料の共有
この記事への提案、提言一覧
この記事への提案、提言









あなたの情報を保存しますか?