研究開発(R&D)ノススメ

2011.12.08

お世話になっております。機敏なぽっちゃり江刺家です。

R&Dとか研究開発ってなによ。って方は下記をご覧ください、弊社営業が真面目に回答しております。

 

ラボ契約増えています

研究開発で重要な事 

 

最近『研究開発で重要な事』内で紹介されているプロジェクトリーダーを担当いたしました。

社内でもこういった研究開発的なプロジェクトを担当することが多いほうだと思います。

 

理由は「よくしゃべるから」です(照

 

R&Dプロジェクトを運営するにあたって大事なこと

こういったプロジェクトを運営するうえで重要な要素は「お客様の要望に合わせる」事と常に心がけています。

当たり前のことなのですが、なかなか奥が深い部分でもあります。

 

押されたら引く、引かれたら押す。ぐらいの関係で、執事のような関係が望ましいと思っています。

そういった意味では前職のフレンチレストランでサービスをしていた経験が役立っているのかなと。。。

 

具体的には

  • 「お客様の要望を吸出し、アイデアが溢れてくる方からは聞き役に徹し。なかなか出しずらい方へは仮説を基に提案を重ねる」
  • 「お客様との目線を合わせ、自分だったらこう思う。と繰り返し互いの理解を合わせていく」
  • 「広げすぎた風呂敷は適度に閉じる」

 

お客様のタイプによっては、「技術は詳しくないのでやりたいことだけ伝える。方法は任せる」という方もいらっしゃいますし、「技術レベルからがっちり相談して作業を進める」という方もいらっしゃいます。

どちらのタイプも誤りではりません、答え(ゴールビジョン)を持っているのはお客様自身なのですから自分はそのイメージに近づく方法を考えるだけです。

 

研究開発を成功に導く契約とは

前出のBlogにもあるように、要件が定まらない案件では準委任による契約を行わせていただいております。

その場合時間(工数)清算となりますので、ご契約いただいたお時間については目いっぱいお使い頂きたいと考えています。

 

限られた時間の中で「全要求を盛り込んだ完璧な製品(サービス)」を実現するには工数が足りないですが、事前に「最低限必要なレベル」について認識を合わさせていただき、まずはそこをクリアすることを目標とします。

あとは時間の許す限り追加対応を繰り返します。

 

研究開発=プロトタイピング=ってなに?

「プロトタイピングってようするにモック(紙芝居)でしょ?」という認識の方もいらっしゃると思いますが、

弊社の場合は「ある程度業務要求に沿ったプログラミング」を指します。

 

モックはモックであり、確かに作りますが「プロトタイピングの途中成果物」であると明確に分けています。。

もちろん画面デザイン(IA/ビジュアル)が重要な要素である場合、モックがゴールとなるプロジェクトもあります。

ご要望の規模によってはそれなりの(大規模)体制を提案させていただく内容のものもあります。

 

そこはご契約前に十分にヒアリングさせていただき「何に繋がるものなのか?」を十分にお伺いした上で作業に着手しますので、大きな齟齬は発生させずに運営することができています。

 

具体的な作成内容

プロトタイピングといいながら、内容と作業工数によってはDBの設計から構築連携まで実装してしまいます。

要件をヒアリングさせていただき、データモデリングからER図を書き、画面要素を反映したテーブルを設計し普通に登録・変更・削除を行えるアプリケーションぐらいは作ります。

 

今までお手伝いさせていただいた事案でいうと、

  • 要件のヒアリング
  • DB設計(簡易)
  • サーバーサイド設計/実装
  • 画面実装
  • クラウド環境での実働テスト
  • 管理画面の構築

 

サーバーサイドももちろん、本開発・追加開発を想定しますので出来る限り細部化されたオブジェクト設計を行います。

DBもT字構成にした設計を採用し、柔軟なテーブル設計が可能な対応を行います。

設計中に気付いた部分や、不足と思われる部分については積極的に確認・提案を行います。

作成ドキュメント・設計方法などはお客様ごとに文化がございますので指定に合わせ準拠し対応を行います。

 

最近はモバイル(iPhoneアプリ・androidアプリ)を組み合わせたご相談が増えてきています。

もちろんまとめて社内で対応させていただいております。

 

準委任だからこそできる柔軟な運営を最大限に生かし、一緒に悩み一緒に考えていただきながらアプリケーションを作っていきます。
(お許しいただければ、お任せも可能です♪むしろ大好物です。)

 

最後の〆が一番大事

R&D開発で大所帯を抱えて始めるプロジェクトはまれです。

2~3か月の間、2~3名体制で小回りを利かせながら作成する場合がほとんどです、そのため設計中からいくつかの懸念事項は後回しにして進める場合があります。

(DBテーブルの詳細なカラムサイズ設計など)

 

ご契約の後半には、こういった「課題・懸念事項」をまとめさせていただき、思いつく限りの「改善方法・今後の設計運営方針」をご提案書として提出させていたく事が多いです。

以降の本開発の際参考にしていただいても結構ですし、改めてご契約についてご相談いただいても結構です。

 

 悩む前に動く・・・

  • 「何から始めたらいいかわからない」
  • 「実現可否について曖昧だから誰も相談に乗ってくれない」

といった理由でお悩みの方がいらっしゃいましたら遠慮なくお問い合わせいただければと思います。