Mogicはかんがえる

少人数＋ソフトウェア＋サーバやロボットの組み合わせで
新しい時代の会社経営を進めています。
そのプロセスの一部をこのコーナーでお伝えできればと思っています｡

代表取締役　山根陽一

2025.03.11

桃栗3年、柿8年という体感

桃栗3年、柿8年とはよくいったもので、ごく小さな種から芽が出て根を張り花が咲いて実をつけるまでたっぷりと時間がかかります。

そう、3年というのはこのスピーディなご時世になんとも想像のつかない「古めかしい単位」に見えることでしょう。

IT企業なら3ヶ月もしくは1ヶ月単位でPDCA（Plan /Do /Check /Action）を回す、そんなイメージがあるかもしれませんが、Mogicではこの3年という単位を素知らぬ顔でよく使っています。

新しいことを勢いよくバタバタとはじめるも、半年や1年ぐらいでは微塵も振り返らず、2年経っても我慢して、3年過ぎてからようやく品定めする。

ただ、その3年すら最初の一歩目としか見ていない。

3年を5ターンほどつなげた15年目に向かってきちんとつながっているか、いろんな角度から思案してみる。

こう書いてるとなんとも気長すぎて大丈夫かなと思えますが、この間尺にはなんとなく数字的な裏付けが存在しています。

端折りながら、ちょっと長くなりますがおつきあいください。

はじめに3年後を評価するとして1日に積み上げるべき量を試算する。

話を簡単にするため、一次式の積算としています。

365日×3年＝1095日、1095日を100ポイントとするなら1日あたり0.09ポイントほど足していけばいい。

もし半年後での評価なら、1年365日の半分182日が100ポイントとなり、1日あたり0.5ポイントを加えることになる。

プロジェクトが順調にいくなら、積み上げるポイントの差はそこまで大きくないように見えます。

ですがもし、最初の60日目までうまく進まないプロジェクトが多いとするならどうでしょうか？

序盤に進みが遅いなら、残りの日数でどのぐらいの強度でビハインドを追いかけないといけないのでしょうか？

最初の60日に1日あたり半分の成果しか出せないとすると、半年プロジェクトなら（0.5÷2）×60日=15ポイントの進捗となり、残り85ポイントを182日 - 60日＝122日でこなさねばならず1日あたり0.7ポイントに上昇します。

3年プロジェクトなら（0.09÷2）×60日=2.7ポイントの進捗で残り97.3を1095日 - 60日＝1035日でこなすとすれば、ほぼ変わらず0.09ポイントのままで済みます。

やや面倒な数字を連ねましたが、つまるところ3年単位でみた方が「プロジェクトの最初で発生しがちな停滞バイアス」を消すことができて、ビジネスや仕事の社会的な価値をより純粋に見定められるのではないかと考えているのです。

複数人でプロジェクトをするなら、当初はコミュニケーションが手探りで、課題への理解がまちまちで、これまでの経験もバラバラで、やる気もあったりなかったりする。

個人でも似たようなもので、最初に思ったほど楽しくなくて、壁に突き当たって止めてしまって、制約がないからつい先延ばしにして、違うものに手を出したりする。

そういうものを差し引いて、3年ほど続けられるのであれば一つの意味が定まってくるはず。

と、ここで具体例を出してみます。

Mogicが3年前にリリースしたものを沿革より抜き出しますと

2022年4月 授業支援システムPhollyが業界最安値帯で提供開始リリース
2022年4月 フレックス制度を導入
2022年9月 情報セキュリティの国際規格ISMS認証を取得リリース
2022年11月 eラーニングシステムLearnOが10周年記念で管理画面のリブランディングリリース

これらが今日までどういう風に進化してきたかと思い巡らせば、うん、7割がいい感じで、3割が改善必要。

だから、“これらの方向性には社会的に意味がある”とすることができる。

なんて考えています。

まあ、そうはいってもこういう一般的じゃないモノサシを導入するのはいいことばかりではありません。

それはそれでネガティブなインパクトにも気を配らねばならないのです。

その一つが、1日に割り振れる認知量というリソース問題です。

これも少し簡単な計算で表現してみます。

1人の人間が使える認知量を100%とする。

この認知量を超えると「つかれた〜」といいはじめて翌日以降のパフォーマンスが低下する閾値。

もし半年後に評価されるプロジェクトを進めるにあたり、1人が1日あたり使う認知量を20％とする。

半年で結果出すとなると、リソースを多めに投下するからです。

となると、1人が切り盛りできる最大プロジェクト数は100％÷20％＝5個の並列稼働。

これが3年後に評価されるプロジェクトなら1日にかける認知量は、半年後のプロジェクトの成果量との比較から割り戻して、（1プロジェクトあたり20％）×0.09ポイント÷0.5ポイント＝3.6％ぐらい。

だから、100％÷3.6％＝最大28個のプロジェクトを並列稼働できる計算。

ただし、同時に動かすプロジェクト数に比例して素早く切り替えるために追加の認知量を求められるのでそこまで多くのプロジェクトを並列化できず、むしろマネジメントの仕組みや技量が高く求められる。

そうですね、結局のところ「数の少ないプロジェクトに多めの認知量を充填させるのか、膨大なプロジェクトにわずかの認知量をうまく分散させるのか」という問題に変換されてきます。

どちらを選ぶのが最適か？

そう問いかけるなら、やっぱり判断軸ははたらく人たちが何を望むか。

彼らがずっとのんびりとマイペースに暮らしていきたいと望むのなら、長期において全体の負荷量とそのブレ幅を予測してうまく平準化させる方法が最適のはず。

なので、少量の認知量での多重切り替えという負荷リスクは理解しながらも3年間という最低単位でたくさんの薄いプロジェクトを同時に稼働させてるんですよね。

なかなかそういう背景は入り組んでいて話しづらいから「Mogicにいると、なんだか違う感じで頭がフル回転してつかれます」と言われても説明しにくかったり。

だからじゃないですけど、分かりやすいモチーフとして”たっぷり手間と暇がかかる果物”を取り寄せてみんなでワイワイと味わっているんですけど、でもなあ、あれじゃなあ、どうにもこうにも100％口下手すぎるよなあ。

最新記事

代表インタビュー

月別アーカイブ