【Schoo×CureApp】~教育系及び医療系のベンチャーのCTO/エンジニアが、ゼロから築くために試行錯誤したことについて語る~
が6月8日に行われました。
ベンチャー企業のCTO含むエンジニアと、とっても近い距離で現場の話が聞ける会でした。
本イベントの運営は、今や飛ぶ鳥を落とす勢いで成長する、アプリが治療する未来を創造する、医療系ベンチャー企業のCureAppさん、オンライン動画学習サービスを運営するSchooさんです。
(以下、CureApp開発者ブログ(
http://cureapp-dev.hatenablog.com/)からの転載となります。)
内容
いらっしゃったお客さんも合わせての座談会形式で行われまして、筋書きなしで進んでいきました。 ここではそのなかで面白かったテーマをピックアップしてみました。
1人のほうが、逆に判断が遅いケースもある
1人で全部決めるから意思決定が早い、というのは、ある意味では間違っている。 「壁打ち」「後押し」となるもう一人の視点があることで、意思決定がより早くなることもある。
全部捨てる覚悟で書け!(書くべきだった)
初期は、とにかくプロトタイプを作って事業を回すことが求められる。 初期と中期以降ではシステムに求められる内容も全然違ってくるのだから、 システムは総とっかえできるぐらいのものでいけばいいのかも。
広く浅く vs 狭く深く
大きな組織で働いていた時には、深くができる。 小さい組織だと、掘り下げる暇はなく、大きい組織に比べてクオリティには差がでてしまうかも。
大きな組織はなぜルールが多くなるのか
ルールというのは、言語化されていない規範の枠に収まってくれない人がいて、 はじめて言語化されるもの。 例えば「いろいろ更新」というコミットログをする人がいて、問題になって、 「やっぱりコミットログは丁寧に作ろう」となる。 そうやって、ルールがどんどんできていってしまう。
「社長には分かってもらえない」は違う!?
「社長はビジネスサイドで、開発サイドの事情など分からない」は、違う。 会社の利益のためにやるのであれば、お互いに会社のほうを向いて、説明しあえば分かるものだろう。
(とはいえ、そういう社長ばかりではない...との意見も...)
開発者は、なぜベンチャー企業で働くの?
事業への共感
影響範囲の大きさに対するチャレンジ精神
働きたい人と働ける
チームの粒度、どのぐらいがいい?
two pizza ruleといって、2枚のピザで足りるぐらいの人数がいいと。 それ以上大きかったら、分けたほうがいい、人を増やすと情報共有のコストがすごい。
など、様々な話題について意見交換が行われていました。
お越しいただいた皆様、ありがとうございました。
ASACでは、エンジニア向けMeetupを含めてスタートアップの皆様が集まるイベントを開催していきます。
引続きご注目ください!(D)