プログラマってこんなかんじ??

アプリ作ったり歌ったりしてます

フリーランスや起業家を目指すエンジニアを支える技術たち 第一回「見積もりを支える技術」

エンジニアカフェ で行われた素敵なイベント。今回のゲストは自分の友人でもある、グルー株式会社 代表取締役 迫田孝太 (@cohtan) 氏。

engineercafe.connpass.com www.youtube.com

議論も活発で非常に盛りあがったイベントだった。自分は配信参加組なので聞こえた部分だけの議事メモ (本人許可済)。

見積もりプラン

  • 松竹梅 用意する
  • サンプル料金表があるとよい
    • 過去の事例
    • 金額がないとこわいよね (例えばお寿司屋)
  • 納品して終わりではなく伴走する
    • 一緒に使えるようになるまで伴走する
    • よりお客さんからも信頼していただける
    • ビジネスネタにもなる

システムの納期とは確率分布

www.publickey1.jp

  • 「この日にリリースする」という「点」で考えない
  • ある日付をピークとした確率分布で考えるほうが現実的
  • 実際には読めない何かしらが起きることが多い
    • 例えばメンバーが病気や怪我をするかもしれないし、担当者が変わったりなど

「締め切りは絶対に守るもの」と考えると世界が変わる

gihyo.jp

  • スタートダッシュ型でいく
    • リスクが早めにわかる
  • なぜラストスパート型になりがちか?
    • 人間は自身の実力を過信しがち
    • 謙虚にやりましょう

値決めは経営

www.kyocera.co.jp

  • 値決めは「誰もが得をするように」決める
    • 自分だけでなく相手の利益も出るポイントを考える

人月計算

  • 定量的に測るものが他にない
  • お客さんがそれに納得しているかどうかが大事
    • 納得してもらえてない場合は一緒に考えませんか?
  • 人月計算自体をお客さんとのコミュニケーションにする ★
    • お客さんにも考えてもらいたい、関わってもらいたい
    • 「相手を喜ばせる段取りを考える作業」が見積もり

初めての相手との仕事

  • まずはミニマムな作業を一緒にやってお互いの相性を測る
  • どこで事故が起こりやすいか
  • スピード感
  • 最初からコミュニケーションの手を抜かない
  • 大きな依頼が来た場合にも小さな作業をできればやる

発注スキル

  • 発注だけしていると身につかない気がする
  • 受注経験が必要
  • 相手の立場を一度経験する

危険フラグな案件

  • ふわっとした思いつきから話す人に多い
  • ふわっとしたメリットしか考えていない (宝くじみたいな発想)
  • 必ずビジネス的に考える
    • このくらいの収入が出てるときはこのくらいの支出になる・・と計算できるはず

非ITな方からの発注

別業界に参入する場合

  • まずは自分で手を動かしてみる
    • 別に専門家がいるとしても自分で何かしらあたりがつけれるようになっておく
  • 最低限の知識は必ず勉強
    • 業界のビジネスモデルはどうなっているのか
  • 得意な人にすべておまかせはダメ
    • 会計も含めて
  • どんどん自分で失敗してみる
    • 失敗してもケガしないレベルで

自身のキャパより大きい案件を発注された場合に断るかどうか

  • 直接的なリスクは少ないけど規模が大きい、は請けたい
    • 人命にかかわるなどは難しい
    • 自分たちで何とかできるレベルなら・・
  • リスクが算出できない場合は請けない
    • そういう案件はまだ自分たちが請ける段階ではないのかもね

規模大きいけどまわりと協力してやって・・と発注された場合

  • 再委託できる会社が信頼できるのが最前提
  • 自分たちだけで「やろうと思えば最悪できる」なら請けたい

はじめてのお客さんからの発注

  • 料金表を作っておくのがやはり良いかも

そのほかいろいろ

あと参考になったのが、@cohtan の話し方。 議論がヒートアップすると自分は早口になりがちなのが悩みで。それが理由でお互いどんどんスピードが上がっていくことが多いのだが、

  • 自分のターンでゆっくり話して場のスピードを調整する
  • やわらかい物腰でゆっくり話す

長丁場なのにこれを実現していて見事だなぁと感じた。

自分自身も立場上よく見積もりすることが多いのだけど、「見積もり」という行動を言語化するのはなかなか難しい。次回はオフラインで議論にぜひ参加したいところ🙃