1. >
  2. >
  3. >

標準化にこだわり抜くことがその他大勢から抜け出す唯一の戦略


最初だけ気合。後は全て標準化

APOLLO11では仕事を標準化することを大事にします。

しかしながら物事は最初ブラックボックスから始まります。

この最初だけは気合で乗り切ります。この為に残業したり徹夜することは「良し」とします。

一時的なことだからです。

しかし2回目以降は禁止です。

2回目以降は必ず標準化してチームでことに当たります。

  • 標準化
  • 新規受注(急ぎ案件)

では標準化の優先度を高くします。新規受注は可能な限りスケジュール調整しますが、難しければ標準化を重視します。そのくらい標準化は大事なものだと考えます。

実験と標準化のバランス

新規事業は70%くらいの完成度でドンドン市場に展開することが重要です。

という話を聞いたことがありませんか?

私は過去この話を盲信していました。

ドンドンやってみると、集客は出来ても、サービス提供がグッチャグチャになって事業が回らないなどの失敗を山程体験してきました。

実験は70%でOK

今言えることは、確かに実験フェーズでは、70%程度で良いと思います。

サービスを100%標準化して市場に投入しても

  • 市場の反応に対して商品や提供方法の修正が入ることがある
  • そもそもニーズがない可能性もある

などのケースがある為、まず実験する時は70%くらいの温度感でOKです。

標準化は100%こだわる

ただし、標準化は別です。実験が終わり、ニーズが確認でき、本格導入する前にはサービスを100%作り上げ標準化します。結果的に100%の完成度になることはなく、常に改善を続けますが、標準化は100%を目指してようやく実用に耐えうるクオリティを備えると考える為です。

システム化による標準化は難易度が高いので、要件定義で必ずペーパープロトタイプ実験を行う

要件定義が甘いことが最大の問題

  • そもそもアナログな運用フロー明確になっていない
  • 要件定義をビジュアライズ出来ておらず齟齬が生じる

ことが大きな問題で、中小企業がシステム導入する時はほぼパッケージソフトしか導入できず、自社システムの開発に失敗しているのは、上記の理由による所が大きいです。

ペーパープロトタイプで実験

いくら営業マンが甘い言葉を囁いてきても、要件定義に手を抜いてはいけません。またそのことで後で起きるシステムへの不満は、開発会社の責任ではありません。発注主の責任です。

そこで重要なのがペーパープロトタイピングという手法です。

残念ながら箇条書きの要件定義だけだと、発注側と受注側の認識はズレます。

この手法を使うと要件定義でのズレを限りなくなくすことができます。

ちなみに私はエストニアのタリン大学で、ペーパープロトタイピングに関する単位を取得しています。

システム化による標準化はそもそも大変。胆力を持って取り組む

そもそも自社でのシステム開発は大変です。要件定義をしっかりしたとしても、必ず漏れはありますし、開発後バグは出るのが当たり前です。デバッグは胆力を持って進めることが重要です。

標準化できる人材求む

私は標準化が苦手です。苦手なのでパフォーマンスも上がりません。この大事な仕事は周囲の皆様にお任せします。新しいことを実験したり、新しい企画を作ることは得意ですが、ついつい自分にしかわからない領域を作ってしまいます。

私は、

  • 標準化に関する勉強もします
  • 会社として標準化が大事だという方向性も示します

しかし、

  • ただし標準化に関連する作業は一切行いません

標準化が出来ると、人材がボトルネックにならずに拡大ができます。APOLLO11は標準化人材を求めています。是非そういった方の求人応募お待ちしております。

一生に一度でいいから体験してみたいこと

知らないうちに勝手に事業が立ち上がっており、

勝手にすごい成果を出している状態。

内部統制上大きな問題ではあるが、一生に一度は味わってみたい感覚です。