IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→法人化(今年))

Web・アプリサービス形態のパターン

改めて脳内にあるものを言語化するためにまとめます。
あまりまとめられている記事をみたことがない印象です。

 

 

サービスのライフサイクル

ざっくり大体こんな感じのイメージです。

f:id:otihateten3510:20210116195139p:plain

コンテンツというのは、色んな形態が考えられます

  • 物的商品
  • デジタル商品
  • 飲食
  • 旅行
  • 記事
  • ゲーム
  • ツール、機能
  • 株・為替
  • 仕事・人材
  • 美容院

などなど


枠に入りづらい形態にSNSやコミュニティのような人にまつわるものがあります。これは右に別途まとめています。繋がってるようで居て独立しています。

コンテンツは1個(1店)であるケース、1種(1ジャンル)であるケース、多種であるケースが考えられます。

このライフサイクルは営業方面でAIDMA・AISAS・SIPSみたいな概念で語られているのを参考にしていますが、それ以外は私のオリジナルです。もっと洗練できるかも。

 

AIDMA・AISAS・SIPS|マーケティングにおける購買行動モデルをおさらい | リクナビNEXTジャーナル

 

現実はもっと複雑ですが、考えやすいようにシンプルに体系立てています。

 

全てを担保するサービスはまだ無い

ユーザーにとって価値がある組み合わせができればサービスは成立します。

しかし、全ての要素を盛り込むと上手く行かないようです。これは色んな要因があると思います。例えば価値(=仕事)を企業間で奪い合うだとか、得手不得手があるだとか、権利の関係だとか。

商世界でも百貨店があったり専門店があったりと、多様な生態系を形作っていますよね。

 

コンテンツが主たる誘引体であり、各項目が副たる誘引体

ユーザーにとって非常に強いモチベーションである対象を誘引体という言葉で表現してみます。飯・金・人・仕事・コンテンツ・エンタメ・情報などが強い誘引体です。

コンテンツは主たる誘引体と定義しましょう。コンテンツはユーザーにとって最高に誘引されるものであり、そのためにユーザーは行動します。例えば旨い飯を食べたくて検索したり予約したりするわけです。そのために機能的なサービスが成立します。

誘引の強さはコンテンツによって差があります
非常に強力なコンテンツは多数のサービスプレイヤーが参画しています。
またコンテンツによって儲かる金額にも差があります。非常に高単価なコンテンツは営業部隊が形成されます。単価が安いが市場規模が大きいものほどITの出番です。

注意したいのは、コンテンツそのものが含まれないサービスというのは、ユーザーにとって中身のないガワでしかないので成立しづらいという事情があります。とはいえ全コンテンツホルダーをまとめ上げることは大抵は不可能なので、ガワだけでどう成立させるかという問題を、全サービスプレイヤーが解いているような状態です。

 

パターン:コンテンツホルダー

f:id:otihateten3510:20210116202010p:plain

コンテンツを持ってる人、作ってる人がこれにあたります。クリエイターでありIPホルダーであり権利者です。これのみで非常に大きな市場が形成されています。
飲食店であれば例えばラーメン屋もそうです。アニメで言えば製作委員会でしょうか。
彼らはしかしサービスを作りません。作ってもほとんど上手くいきません(例外あり)
理由は割愛します。

 

パターン:コンテンツ配信サービス

f:id:otihateten3510:20210116202427p:plain

例えばSpotifyNetflixTverみたいなコンテンツ配信サービスがこれにあたります。
コンテンツホルダーと違うのは、彼らはコンテンツを作っていないというところです(Netflixなど例外あり)

サービスプレイヤーとしては一番手堅く、支配的・天下を取れる形態ではありますが、そう簡単ではないというのは世の中のレッドオーシャン振りを見ると分かると思います。大きな資本と政治力が物を言います。

 

パターン:EC・モール(ジェネレート系含む)

 

f:id:otihateten3510:20210117005742p:plain

ECサービス全般はこんな感じ。
物販というのも基本的に同じですよね。商品の製造者と販売者は分かれていることが多いです。

 

パターン:決済システム

f:id:otihateten3510:20210117010307p:plain

決済は決済単独でサービスたり得ます。
購入・決済・予約は特殊な機能ですね。1個でビジネスが成り立つ。

 

パターン:予約サービス

f:id:otihateten3510:20210116204037p:plain

こちらも分かりやすいサービスです。
予約という機能が非常に重いので、そこを中心としてコンテンツ不在でも成立しています。

 

パターン:レビューサービス

f:id:otihateten3510:20210116204816p:plain

コンテンツの感想サービスです。そこそこありますが、どうしても上場まで行っていないケースが多いですね。
コンテンツ感想サービスの難しいところはマネタイズにあると思います。

 

パターン:ニュースサービス、キュレーション

f:id:otihateten3510:20210116205637p:plain

ニュース、情報がコンテンツになります。
情報をコンテンツと見なせば2重のコンテンツとなり複雑になります。

 

パターン:比較サービス

f:id:otihateten3510:20210117004759p:plain

比較を売りにしたサービスです。価格.comが思いつきますね。

 

パターン:出会い系・コミュニケーション

f:id:otihateten3510:20210116211341p:plain

これは分かりやすいですが、コンテンツが主体となっていないので今回の考え方とは少し変わります。

 

パターン:出会い系+コンテンツ

 

f:id:otihateten3510:20210116211633p:plain

最近ちょいちょい目にするデートプラン追加系サービスです。ワークしてるのかは知らないですが。

こういうのを見ると成立するサービスパターンの模索が進んでいる感じがしますね。

 

パターン:SNS

f:id:otihateten3510:20210116211913p:plain

SNSは非常に複雑怪奇ですね。最初は右側のコミュニケーションが中心だったと思いますが、コンテンツ主体としても見れるようになりました。SNSSNSだけで別の生態系で考えたほうが良いかもしれません。

 

これ以外のパターンは成立しづらい

 

コンテンツがないという所からスタートしたら、どうしても誘引が弱くなりますので、成立するパターンは少ないです。他にもあるかもしれませんが。

 

考察:リボン型ビジネスモデル

リボン型ビジネスモデルは、例えばBtoBtoCの場合はB側、C側に対してそれぞれのパターンを持っているとみなすことができると思います。
マーケットプレイス型のビジネスモデルも同様です。

 

考察:他にもビジネスモデルは大量にある

念の為頭に置いておきたいですが、当然ビジネスモデルはもっと沢山あります。
ただ、Webやアプリでサービスを作ろうとする場合には上記のようなパターンが主に成立するパターンなってくるようです。

 

考察:新しい「コンテンツ」を作る旨味

例えば「飲食」という強力なコンテンツが存在することで、多岐に及ぶサービスが存在しえます。コンテンツによって大規模な市場が形成されるわけです。
近年登場し成長したコンテンツには「ゲーム」があるでしょう。

そのためこのコンテンツ作りという部分でチャレンジするベンチャーも沢山あります。ただしそれは非常に困難なものだと認識しておかなければなりません。未成熟なコンテンツだと成立するパターンはより少なくなります。

 

考察:新しいパターン探し

そういうことをしてる会社もありますが、これも新しいコンテンツ作りほどではないですが難解な作業です。
滅多に新しいパターンは見つかりません。
(機能として盛り込むことはできても、規模を持ってワークできない)

 

私が作りたい新しいパターン

これは蛇足ですが。私も作りたい新しいパターンがあります。

f:id:otihateten3510:20210116221441p:plain

コンテンツの前と後の両方を盛り込んで成立させるというのは難しく、工夫が必要になるんですが、そこをまだ世界は取りきれていない感じがするんですよね。

 

 

 

 

 

 

 

モバイルアプリエンジニアはFlutterに手を出すべきか? そこらへんの生存戦略

Flutter、伸びてきてます。
数はReactNativeとFlutterを比較しています。Flutterというのは普通に英単語のようなので、Flutterが登場する2017年を基準に補正しています。今年になってようやくReact Nativeを抜き去り、今は少し落ちつたようです。

これは国内でも似たような感じです。

 

f:id:otihateten3510:20201028001902p:plain

 

それでも「React Nativeくらい」レベル

React Nativeの手を出さなかったモバイルアプリエンジニアは、Flutterに手を出す理由がさほどないと思います。
エージェントにも聞いてみましたが、やはりFlutter案件はまだ多くない上に安めらしいです。
ハイブリッドアプリを使うんですからそりゃそうですよね。

 

もちろん自社が採用したらやって良いと思う

一社に所属しているエンジニアと、何社とも取引するフリーランスエンジニアとでは状況がまるで違います。Flutterを採用して1案件あたりの単価を下げ数をさばくという営業方針を会社が取るのであればそれについて行って良いと思います。
まあ会社辞める時ちょっと大変ですけど。それ言ったらRxSwiftしかやってない人とかいましたし。

 

フリーランスの場合は少し慎重さが必要です。

 

おおよそのモバイル案件比率

大体こんな感じです。
iOS案件が100あったら、大体Android案件も100あります。日本特有ですねこれ。
そのうち20くらいがハイブリッド案件で、最近はFlutterが徐々に増えてきています。
残りの80のうち、15くらいが特殊な案件です。例えばRxSwiftを使ってるとか。何かこだわってるやつです。

f:id:otihateten3510:20201028002811p:plain

私が攻めてるのはメインボリュームである「普通のiOS案件」です。
特殊なiOS案件は単価が高いですが色々と無理だと悟りました(詳細は省く)

ハイブリッド案件を狙うのは基本的に悪手

上の図を見てほしいんですが、ハイブリッドの領域を取ろうとするのはAndroidエンジニアとiOSエンジニアの両方です。
注意が必要なのは、
普通のAndroid案件:普通のiOS案件:ハイブリッド案件=65:65:20
だということです。
ちょっと図があれですが、見かけでは大きいように見えて、狙うエンジニアの数からしたらめっちゃ少ないんです。
自ずと需要と供給の関係でエンジニア的には美味しくないですよね。

 

ハイブリッド案件を狙うメリット

それでも狙う理由があります。

  • 基本小規模 → ベンチャーや立ち上げフェーズ → リモート開発
  • Flutter案件が大きくなってきた時、iOSエンジニアは重宝されそう?
  • ハイブリッド卒業する時にネイティブ開発者として関われるかも?
  • 1案件が小さく、色んな案件に関われるかも?

これのどこらへんがメリットなんだろう?と我ながら思うんですが。

私は諸事情で現在フルリモート開発をしていまして、その関係でハイブリッドに手を出すべきなのかなぁと悩んでいます。
フルリモート可な案件にFlutter多いんですよね

また、いずれフルネイティブにしたいと考えてるような場合、おそらくそのままスライドで仕事を取れるでしょう。まあレアケースな気もしますけど。

 

iOS出身のFlutter使いって少なそう

あと私がFlutterに興味を持った理由の一つにこれがあります。

FlutterはGoogle由来ですから、自ずとAndroid出身者が多いと予想されます。プロジェクトでもAndroidファーストでアプリをリリースしたいという時にどうせならとFlutterを選択するケースがあるんじゃないでしょうか?iOSファーストの場合は普通にiOSファーストでやると思います。私が今やってる3つの案件のうち2つはiOSファーストです。Android版まだ出ません。

逆に考えれば、iOSの知識を持ってるFlutter使いってレアなんじゃないでしょうか?予想ですけど。ハイブリッドと言ってもSwift触るところも出てくるらしいですから、Flutter案件でFlutterエンジニアを2人3人抱えるというフェーズではiOS出身者が欲しくなると思います。

 

とりあえず

まあ全部予想だし勘なんですけどね

誰か情報交換しませんか?

 

とりあえず来年に向けて少し勉強してみようと思います。流石にiOS9年Android2年やってるんで理解できないなんて事ないと思うんですが・・・RxSwiftはダメでしたが・・・

 

ネガティブ思考でも努力はし続けられる、戦略的に自分を過小評価する話

今日気づいたんですが、どうやら自分の努力するときの思考パターンは独特なようです。
メモしておきます。

 

 

ポジティブ思考の努力

ポジティブな人が何かを頑張ろうとする時というのは、ジャンプの主人公のような思考形態を取ると思います。「海賊王に俺はなる!!(ドン!!)」みたな感じです。
これは初手で大きな目標(ポジティブイメージ)を持ちます。
この方法の肝は

  • どれだけ大きな目標を掲げられるか
  • どれだけ困難に直面しても萎えずに目標を持ち続けられるか
  • 萎える前に目標達成できるか

です。
我々はルフィではないので、困難や現実を見るとどんどん萎えます。
下図のように。

 

f:id:otihateten3510:20201026223602p:plain

 

ネガティブ思考の努力

私の思考形態は圧倒的にネガティブです。
大きな目標は持ちますが、できない理由をあげつらって「こんなの絶対できない」と言い出します。
でも誤解してほしくないんですが、私はそこから一個ずつできない理由を潰していく行動を取ります。

無意識でやってました。

この方法の肝は

  • できない理由をどれだけ潰せるか
  • ストレスが行動の源
  • ストレスに潰されずに行動し続ける
  • 「できそう」と思わない
  • できそうになった時に最後の踏ん張りが必要

 

ポジティブ努力のメリット・デメリット

  • 夢に向かってる時はとにかく楽しい
  • エネルギーが不足すると飽きて終わる
  • 現実との乖離が大きすぎると具体的な行動につなげにくい
  • 達成できない時は落差で落ち込む
  • 大きな目標を持てれば、及第点に達しても更に努力ができる
  • 上手くいくと自慢ばかりになる(「俺はこんなもんじゃない」)

 

ネガティブ努力のメリット・デメリット

  • 楽しくない
  • 長期戦に向いている
  • 自尊心がどんどん傷つく
  • 夢はない、あるのは課題
  • 課題が無くなると行動できなくなるから、目標が及第点止まり
  • 上手くいくと嫌味な人になる(「俺なんて大したことない」)

 

ポジティブ努力もどき、ネガティブ努力もどき

大きな目標を持って気持ちよくなって行動しないのはポジティブ努力もどきです。
悪いところをあげつらって憂鬱になって行動しないのはネガティブ努力もどきです。

 

ポジティブ努力もネガティブ努力も誤解される

ポジティブ努力は「口だけだろ」と思われがちですね。
ネガティブ努力は「また愚痴言ってる」と思われがちです。

 

ポジティブ努力を上手くやるポイント

頭のネジを外す

 

ネガティブ努力を上手くやるポイント

自分よりすごい人に会いまくって劣等感をたくさん得る

 

思考形態をチェンジできるか?

相当難しいのではないかと思います。
だって例えば「俺は大企業の社長になる!」とか大真面目に思い込んだ上できちんと行動できると思いますか?私は無理です。

 

 

 

また何か考えたらまとめたいと思います。

なぜ遅刻をしてはいけないの?ちゃんと考える(IT業界)

遅刻すると怒られたり怒られなかったりします。
IT業界では結構怒られないこともあります。
何故だろうと考えると、遅刻してはいけない理由が複数あるからだと思い至りました。

 

1.ルールだから(よくあるやつ)

規律、規則、契約みたいなやつです。
IT業界ではこういうのは合理性の前では弱いですね。
「やることやってんだから遅れてもいいだろ」って人も居ますね。

 

2.労働時間が減るから

毎日2時間遅れて定時で帰ったら、160時間のところ120時間しか働いていないことになります。
そんな人いる??と思うかもしれませんが、IT業界には居ます。

これはプロジェクトの納期に影響が出るので大変です。

あとは、朝しかやっていない作業などがあると、もっと影響が大きいですよね。

 

3.退社時間が遅くなるから

会社が24時間営業になってしまいます。

 

4.他の人の待ちが発生するから

例えばAさんが作業をしないとBさんとCさんとDさんが動けない、みたいなケースでは、1人の1時間の遅刻が大きな損失になります。
そしてプロジェクトの納期に影響が出ます

 

5.ミーティングが始められない、ミーティング可能時間が減る

ルーズな人が複数人居るようなプロジェクトでは、大体ミーティングに誰かが居ないみたいな歯抜けで開始します。
これは情報伝達に問題が発生します。
遅刻は怒られないけどミーティングに遅れると怒られることとかありますよね。

 

 

対策して遅刻しよう!

合理的に対策すれば遅刻できるのでは?

 

 

1.ルールを変える

つまり裁量労働制です。

 

2.労働時間をきちんと確保する

2時間遅れたら2時間遅くまで仕事すればいいですね(裁量労働制?)

もし退社時間を揃えたいなら、ちゃんと朝来ましょう。

 

3.退社時間が遅くなる

→ 対応不可?リモートワーク?

 

4.前日に準備して、他の人の待ちを産まない

不可抗力で遅れることもありますから、できれば前日に用意しておきたいですね。

 

5.ミーティングは遅刻しない

これはしょうがない。

サービス・事業・活動の考え方まとめ:誰をどこまでアップデートするか

メモです。

 

サービスや事業を考える時に「どういう人をどういう状態まで改善するのか」という観点があると思いますがここについてまとめている情報を見たことが有りません。
ちょっと何言ってるかわからないですね。具体的に書いていきます。

 

 

1.「困ってる人を助ける」というモチベーション

 

援助、介助

恵まれない人を、通常状態にするというモチベーション。
「恵まれない人に救いの手を」というやつです。非常にわかりやすいです。

 

救助

助けを求めている人を助けるというモチベーションです。

 

互助を促す

コミュニティを作って互助を促そうというモチベーションです。

 

2.「誰かの助けにある機能の1つを提供する」というモチベーション

これは「誰をどこまで」ではなくなります。
ドメインを絞らないので安定性があります。

3.「マスに対する改善」というモチベーション

これが一番多いのではないでしょうか。
特に日本は一億総中流などと言われていたこともありほとんどこれでしょうね。

 

4.「成功者・専門家に対して新しい価値を提供する」というモチベーション

こういうのは都内・都市部に多いです。
インフルエンサーに好まれるような新しい何か、と言えばイメージつくでしょうか。売上を求めるならどうしても3のマスにアプローチしていかなければなりませんが、そうではなく、ひたすらより良いものを追求するという観点ではこちらになります。

5.「新しい価値・考え方の提供」というモチベーション

これまでとは新機軸の革新的な価値を提供しようという考え方です。

 

f:id:otihateten3510:20200920203300p:plain



 

アイディアを考えても大抵1〜5のどれかに偏る

世の中を見てみるとわかりやすいですが、大体どれかに偏っていますし、同じような考えの人が固まっています。
ゼロベースで色んなアイディアを考えているようでいて、やっぱり価値観が固定されていることが多いです。

 

私はずっと5のタイプでした。ということに最近自覚できたと思います。
どうしてもそれ以外に目を向けられませんでした。何故かと言えば・・・ちょっと毒吐きになるので書きませんが。
少し反省して、今後目を向けるのも有りじゃないかと思っています。
中々同じ業界にばかり居ると1〜5のどれかに捕らわれてしまうので、よりフラットになるように色んな価値観に触れるべきですね。

ITスタートアップ/ベンチャー企業に就職したい人向け!調達から会社の状況を推測する

一般的に就職するときには、その会社を不変のものと捉えることが多いのではないかと思います。
特に大企業であれば、入った時と10年後でそこまで大きな変化は無いのかもしれません。
しかしスタートアップやベンチャーは非常に早いスピードで変化が生じます。わずか1,2年で別物になり取り組む課題や組織が変わっていきます。
なのでそこに就職したり参画する場合は「今どういう状態か」「近い将来どうなっていくか」を予測する必要があります。会社の成功に賭けるようなものです。

とは言え、外から見てるだけで会社がどうなるかなんてわからなさそうですよね。
そこで重要になるのが資金調達です。
上場や会社売却を考えているようなスタートアップ・ベンチャー企業は似た課題にぶつかり、似たように資金調達をして乗り越えていきます。裏を返せば資金調達から会社の状況がある程度推測できるわけです。

 

基本の知識

ざっくり書きます。詳しくは別途調べてもらったほうが良いと思います。

 

出資と融資の違い

融資は銀行などからお金を借りることです。返す必要があります。
出資は株式の一部を売ることでお金を得ます。もちろん返す必要はありません。
上場すると基本的に株価が何倍にも膨れ上がるので、出資者はそれを狙います。
(なので出資者は当然上場を迫ってきます)

 

投資ラウンド

出資を受ける前 シードラウンド
1回目の出資 シリーズA
2回目の出資 シリーズB
3回目の出資 シリーズC

 

なぜ出資を数回に分けるのか?というと、会社資産=全株式の総額のうち、どのくらいの株を放出できるかという問題があるからです。上場していないくても徐々に株価の評価額は上がります。徐々に調達しなければなりません(そうしないと大半の株を他社に取られてしまいます)
また、会社の成長は突然起きるわけではないので、いきなり大金を受け取っても使いきれなかったりします。

 

出資の金額と目的

もちろんこれは会社や事業次第なんですが、ITサービス運営の場合はかなり似てきます。

 

シードラウンド
貯金・身内に借金・エンジェル投資家など
100万〜1000万円くらい とりあえず事業開始するところまで

 

シリーズA
1000万円〜3000万円が多く、ほとんどは人件費に費やす
ただ広告費が必要な場合は数億円になることもある

 

シリーズB
5000万円〜15億円くらいが多く、人材獲得と事業拡大に費やす

 

シリーズC・シリーズD
2億円〜数十億円くらいが多く、事業の多角化に費やすことが多い

 

調達は良い兆候?悪い兆候?

当然事業をしているわけですから、そこですこぶる儲かっていたら調達する必要性ってあまりないんですよね。
例えばシリーズAだけ調達して数年沈黙っていうところ結構あります。
3000万円でそんな何年も会社が持つわけないので、事業でちゃんと儲けているということでしょう。

じゃあシリーズBの会社はまずいのかと言えばそうでもなく、好調な事業を更に大きくするために調達して加速する会社はたくさんあります。個人的にはシリーズBはやって当たり前なのかなーと思えるくらいにどこもやってるイメージあります。

ではシリーズC・Dはどうなの?というと、少し事情が変わってきます。
シリーズBの後に上場するケースがよくあるので、上場せずにシリーズC・Dとなると、何か理由がありそうです。
これが戦略的な理由であればいいですが、単純に上手く行ってない場合は調達おかわりということなので、注意が必要でしょう。
(上場せずにひたすらデカくなる会社もありますから、そこらへんは何故上場しないのか分析する必要があると思います)

ここらへんは一個人が知れる情報なんてたかが知れてるんですが、資金調達のプレスリリースで出ている調達理由がどれほど納得できるものなのかで判断すると良いと思います。

 

各フェーズでの会社の状況

シードラウンド

とにかく金が無い短期決戦の状態です。基本的に近づくメリットは薄いんですが、やろうとしていることに共感できるとか、0→1を体験したいなら良いと思います。
ここらへんは要件定義力・コミュ力がかなり問われるので注意しましょう。
私も複数案件で経験があります。どんな感じなのか聞きたければ直接聞いてください。

 

シリーズA

このフェーズもあまり資金に余裕がありませんが、従業員人数も5人〜20人程度とそれなりの規模になってくるためちゃんと組織だってきます。
個人的には一番おもしろいフェーズだと思いますが、まだまだ安定とは程遠いためカオスとの戦いになります。
シリーズBまでに明確に売上を立てて行く必要があり、上手く行かない場合は辛いことになるでしょう。人の入れ替わりも激しいです。

 

シリーズB

ベンチャーを狙うならシリーズB直後が一番良いでしょう。キャッシュにある程度余裕があり、このまま上場まで突っ走るべく準備するフェーズです。従業員数は15人〜40人程度でしょうか。徐々に中小企業じみてきます。
優秀な人もバンバン入ってくると思います。色んな業界業種から入ってくるので面白みもあると思います。事業も世間的に認知され、面白い時期です。
ただここで停滞する会社も多いです。
あと、前任者がやっつけで書いたコードを修正するはめになることが多いです。

 

シリーズC・D・上場直後

優秀な人達が寄ってたかってもがくフェーズだと思います。事業設計が複雑になってきて、より普通の企業に近づいていきます。
ベンチャーとしてのプライオリティはさほどありません。
コードも複雑になっていることでしょう。
ただし安定はしています。10年後も会社は存続しているはずです。

 

その会社のフェーズを知るには?

調達情報はプレスリリースが出るため、「会社名 調達」でニュース検索すればすぐ出てきます。
これで現在どのフェーズかがわかります。

ベテラン+初級者の組み合わせは案外パフォーマンスが良いという話

f:id:otihateten3510:20200910230408p:plain

 

システム開発というのは非常に時間コストが掛かる作業ですが、何にそんなに時間がかかっているかといえば、試行錯誤や手戻りに時間がかかっているんですよね。
最初に見積もりする時はだいたい一本道の正解ルートを辿った時のコストで考えてしまいます。
しかし僅かな仕様の差やバージョン差などで、Aという方法で上手く行かないということがあります。それでBという方法やCという方法を試したりして時間が掛かってしまうわけです。

 

体感ですが、すんなり正解の方法をとった場合のコストを80だとすると、見積もりで100を提示します。予想から漏れていたタスクが30増えて、試行錯誤で30増えます。結果160くらいで60%くらい上振れることが昔は多かったです。

最初に思い切って80の2倍の160と見積もればよかったんですけど、中々難しいですよね。頭の中では正解のルートを選択している想定なので。

 

実際は、Aルート、Bルート、Cルート・・・とあって、どれかを選択し、やってみて、だめなら他のルートを試すわけです。もしこの正解が予めわかっていたら、つまり登るべきタスクと言う名の山のルートが分かっていたら、かなり時間コストは抑えられるわけです。

だから、ルートを分かっているベテランが初級者をフォローすると、思ったよりパフォーマンスが出ます。

 

もちろんこれはタスクの種類に依るでしょう。
試行錯誤するための時間コスト、正解を引き当てるまでの確率、ベテランと初級者の作業のスピード差などによって状況は変わってきます。
ただアプリ開発やWeb開発においては、あまりにも選択の連続であるため、ルートを知っている者と知らない者で大きな乖離が出てきます。
初級者はベテランからの指示を仰ぐことでサクサク進むことができるはずです。

 

ただこの方法をずっと続けて良いのかという疑問は少しあります。
試行錯誤して、ダメなルートで何度も痛い目を見ないと、初級者がベテランになることはできないのではないか?と思います。
でもだからと言って無駄なルート取りをして苦しでもしょうがないですよね。
試行錯誤がそもそも好きな初級者ならいいでしょうけど。

 

これはその初級者がどの組織やどのプロジェクトでやっていくかに依ると思いました。
例えば正解ルートの1つだけ選んで行けばいいプロジェクトや組織なら他のルートについて知る必要はありません。
例えば事業会社なんかではこうなるかもしれません。リードエンジニアがしっかり居る受託会社でもこうなるかもしれません。

一方で、誰かが書いたコードを読むためには、正解ルートは全部しる必要があるし、ダメなルートも網羅的に覚えていかなければなりません。自分が普段使用しているAという方法以外に、BやCでも解決可能ならば誰かがそれを使ってコードを書いているでしょうし。そうなるとルートについてかなり深くまで知らなければなりません。

 

  1. リードエンジニアが居て、フォローしてもらえる状態
  2. 組織の規模が大きく、ベテランが容易に見つかる
  3. 組織内でコードの書き方の規格が統一されている
  4. 組織は大きいが、プロジェクトによって書き方がまちまち
  5. 組織の規模が小さく、ベテランが見つからない
  6. フリーランスなど自力が要求される状況

1、2、3なら初級者はルートについて詳しくなくてもどうにかなります。
ただしベテランが抜けたらどうなるかはわかりません。あと3は初級者には判断がつかないかもしれません。
4はよく見かける状況です。初級者でも試行錯誤が必要になると思いますが、前任者へのアプローチが容易なのでヒントはもらえるでしょう。
5は試行錯誤が必要ですが、1個の正解ルートを見つけたらそれだけ使えばいいのでコストはそれほど多いわけでは有りません。
6は試行錯誤が必要なうえ、全部の正解ルートやダメルートも知る必要があるので、ルートについて網羅的に知る必要があります。

 

だからこれはその人が今後どういうキャリアにするかに依るんです。まずそこを考えないといけないですよね。

そんなことを最近思いました。

その人が攻める山のドメインを適切に絞るのが大事なのではないかと。