2010年10月25日

開発にあたっての個人的備忘録

開発のポイント

その1
エンドユーザーの提示する解決策、提案よりも、エンドユーザーがどういう操作を行っているか、どこで問題が生じているかを把握することが大事。

「○○をやって欲しいのですが」と言われたら、「なるほど、それはなぜですか?」と聞いてみる。改善策ではなく、抱えている問題を聞く。

「風邪をひいたので、風邪薬をください」といわれたときに、「まず、どんな症状なのかをお聞かせください」と質問するということ。

時にはエンドユーザーの提案が正鵠を射ている場合もあるが、そのケースは少ない。それができるから、開発者はお金を取れる。


その2
何か新しいことにチャレンジするときは、新しいこと以外の部分は極力標準にあわせる。標準でないことをやるというのはただでさえリスクを抱えている。それが新しい標準を提案する野心的なものであれば別だが、何が狙いで、何が狙いではないのか、その整理をきちんとする。狙いではない部分でリスクを冒してはならない。

開発にあたって何か問題が生じた場合は、極力既存の代替手段を使うのが基本方針。


その3
開発は仮説を立て、検証し、改善していくのが基本。このシステムを崩すと開発が属人的になる。属人的な開発は継続的な成功を保証しないし、開発組織の劣化を招く。

検証が難しい開発には手を出さないほうが良い。

特に、新規の開発はポイントが他者との差別化等にあるので、本質ではない部分には注力すべきでない。


その4
判断に迷ったときに立ち返るべき基本方針があるなら、それに従う。逆に言えば、この基本方針は開発初期に明確にしておくべきである。基本方針が開発に対して大きな悪影響を及ぼすときのみ、この基本方針を変更することを考える。

自社開発では、悩むのは時間の無駄。どんどん決定していくことが大切。

この記事へのトラックバックURL

http://trackback.blogsys.jp/livedoor/buu2/51088621
この記事へのコメント
このエントリ「開発」→「研究」としても、そのまま成り立ちますね。「エンドユーザー」は「学生」とか「研究員」に置き換えると感覚的に言いたいことがよくわかります。
とても興味深いです。
Posted by Kita at 2010年10月27日 08:13
> このエントリ「開発」→「研究」としても、そのまま成り立ちますね。「エンドユーザー」は「学生」とか「研究員」に置き換えると感覚的に言いたいことがよくわかります。
> とても興味深いです。

ただ、この手のことは、自分の経験とかをベースにして、きちんと考えないと身につかないんです。ツイッターとかでRTしたり、はてぶに登録したりしても全く意味がない。大事なことは、自分の頭できっちり考えることです。僕はきっちり考えていますが、それでも忘れることがあるので、だから備忘録。あくまでも個人的なものです。凄く大事なことではありますが、おそらくこれを読んでもほとんどの人の役には立ちません。なぜなら、どうせちゃんと考えないから。
Posted by buu* at 2010年10月27日 14:52