振られたタスクの粒度によって気をつけることは変わる
新人が振られるタスクって大小様々なんですが、その大小によって注意すべき点とか動きかたみたいなのって教えてくれないですよね。
というわけでサクッとまとめてみます。
バグを修正するタスク
おおよそ正常に動いているプログラムがあるが、一部にバグが有りそれを修正すると言うタスク。参画して最初に振られることが多いタスクです。
大事なのはバグを増やさないことです。なので今動いている部分は壊しちゃいけません。
と言っても最初にプロジェクトに参画した時は正常動作がどういう状態か、どうテストするのかがはっきりしていないことが多いのでかなり大変な作業です。
プロジェクトに慣れてれば1時間で終わるようなタスクが、10時間以上に膨れたりします。理解がない雇い主の場合はそれで一回揉めます。
プルリクエストを活用して責任の分散を図るのが良いと思います。またよくわからない部分については仕様書を探したり人に聞いたりしましょう。そこでそのプロジェクトの絶望度が見えてきます（誰も答えを知らないとか）
もちろん再現性も重要です。どの条件で再現して、どの条件で再現しないのかを詳らかにしなければスタートラインにすら立てません。バグを見つけた人は発見だけを報告しますが、修正者は全てのエラー条件を洗い出す必要があります。
洗い出せたら修正し、網羅性の有るテストにより修正できたことを確認すれば良いのですが、自分の修正が何かを壊していない確証を得るのは非常に大変です。むしろそちらのほうが神経をすり減らします。
これが未リリースのプロジェクトならそこまで気負う必要はないのかもしれません。テストする人もエンジニアがきちんと修正したなどと信用していないからです。
ただし、それがリリース済みのプロジェクトだったり、テスターが居ないプロジェクトでは非常に神経質になる必要があります。（具体的なテストの方法論については割愛）
少しだけ追加・変更するタスク
既に動いているプログラムに、わずかな改良や変更をするタスク。
概ねバグ修正に似ています。
追加変更する際に、同プロジェクトの他コードと足並みを揃えることが求められます。完璧に足並みを揃えるのは難しいかもしれませんが、既に作成されているUtilityがあったり、設計手法を合わせたり、用語を合わせたり、コードの流れやコメントの書き方を踏襲する努力は必要です。完璧にやる必要はありません、そこはユーザーに見せる場所ではないので、あくまで”作業場”として適切な状態に近ければOKです。
あまり作業場をこだわろうとするのはおすすめしません。それより有意義なタスクはあるからです。わずかな用語の差や構造の差は見て見ぬ振りをする我慢強さが必要になります。
追加・変更したために発生する影響範囲が漏れることが多いです。１つの画面を作ったとき、その画面に至る導線は１つではないかもしれません。思わぬところから画面遷移してきて、その際に必要なデータを用意できなくて設計を見直す必要があることもあります。
意外とそういう接続の部分が重かったりすると、「追加変更」のタスク分しか見積もっていなくて時間が足りなくなることがあります。
気軽に聞ける人が居たら聞いてみましょう、ただし完璧な回答が返ってこない可能性の方が高いことを留意して下さい。
１つのパーツを作るタスク
ある１機能を作るようなタスク。
影響範囲が色んな所に及びます。パーツそのものの工数も大きいですが、他との連携に多くの時間がかかるケースもあります。パーツが何を使うのか、何がパーツを使うのか、ヒエラルキーや文脈を理解する必要があります。
あるいはそういう設計部分を誰かに任せたほうが良いかもしれません。各々やるととっちらかります。
大変そうに見えますが、この粒度が一番安心度が高いと思います。プログラムの振る舞いは自分が書いたコードのコントロール下にあります。他人のコードを読む必要は少ないので、書いたとおりに動きます。
（ただし大きな枠組みで設計方針が決まっている場合もあります）
似たようなパーツが他にないか探し、真似ることも重要になります。これはコスト削減とコードを読みやすくするという２つの目的があります。
ただし真似た方のコードに問題があった場合、自分の方にも問題が出るので注意が必要です。また、新しく書いたコードはどこかで真似られる可能性があります。心して書きましょう。
過度な共通化はやめてください。人は同じ形のものがあるとグルーピングしたくなります。ただし最近のプログラミングは生き物のように変化します。同じ形だったはずの２つが別のものになろうとした時、妙な共通化がされていると事故が起きます。
共通化というのは高度な作業です。
どのような条件下でも使いやすく、不要になったらすぐに分離できるような慎重に共通化する必要があります。悩んだら聞いてみて下さい（できれば10年以上の人に聞いて下さい。プログラマーは3〜5年目あたりで共通化大好き病に罹ります）
試作を積極的に作りましょう。
何かと干渉し、そのプロジェクトでしか動かないケースなどあるはずです。試作で困ったことは大抵一般的な悩みなので検索すれば出てきます。
また作った試作は別の機会にも役に立つはずです。
１つのプロダクトをまるっと作る
長くなるので割愛しますが、プログラムよりも要件定義やテストやリリース、チーム体制の方が重要になります。
以上です
SwiftUI移行は2023年〜2025年？
前
iOSエンジニア SwiftUIへの移行戦略 - IT業界で気づいたことをこっそり書くブログ
私の観測範囲ですが、iOS15からSwiftUIが良い感じになるという噂を各所で数件見つけました。
実務に耐えられるようになるのがiOS15から、おそらくiOS16以降でスタンダードになる予感がしています。
ただし、最低バージョンがiOS15ですから。
実際には最新バージョンがiOS16,17,18の頃になると思っています。
Objective-CからSwiftへの移行や、AutoLayout移行、Storyboard移行などを見てきましたが、以下のスケジュールが凡人エンジニアとしては丁度いい気がしています。
iOS16が出る頃 勉強開始 → 2022年秋
iOS17が出る頃 移行開始 → 2023年秋
iOS19が出る頃 移行終了 → 2025年秋
以下、Storyboardがレガシー扱い
新規アプリに採用して良いのも多分2022年から。iOS14切るならOKみたいな。
既に何件かSwiftUIの仕事依頼をされましたが、ちょっと早いと思います。別にいいんですけど、徒労かつ負債になりそう。
ただ、何らかのSDKやライブラリのチュートリアルが徐々にSwiftUIで書かれ始めていたりするので、なんやかんや今年辺りから勉強せざるを得ない感じになるかもしれません。Amplifyの公式チュートリアルとかはSwiftUIで書かれてました。
ちなみに私の本音は「めんどくさいよー！！」です。Storyboard好きなので。
完全に無くなる感じもしてないんですよね。
というか2024年頃にまた別の何かを出してきそうですよねApple。
【定期】年収と成長率 2021 現状分析
去年
2020年と今年の見込み。
2020年はコロナやらなんやらでバタバタしてて微増でしたが、今年2021年は2000万が普通に見えてきました。なんなら2500万も見えてくるかも。
2020年、2021年で大きく変わったこと
営業しなくても直契約の仕事が来るように成りました。
流入経路を洗い出すと
しかもありがたいことに新規開発が多く、開発が安定しました。
こちらから営業（面接）受けると全然決まらないんですが、向こうから来る場合は非常に決まりやすいし質の高い案件が多い印象です。
驚くことにここ5案件は全て向こうからです。先週もう一件決まりました。年内ほぼ安泰です。
分析：１分野で実績を沢山重ねると仕事は向こうからくる
この実績解除にも似た状況って果たして狙えるんでしょうか？
私はiOS歴9年です。9年も同じ石の上に座ってようやくと考えると、再現性は薄いような気がします。IT業界で同じことを9年続けるのは運が必要でしょうし。
プロモーションを頑張れば同じ状況になるか？
私の場合、特に大人数のフォロワーが居るわけでもないし、プロモーションをがんばってるわけではないので、皆様なんとか探して見つけてきていただいている状況です。
これがもっと目立つ格好になると、よりよいクライアントも来るでしょうけど、そうではないクライアントからも見つかるので、玉石混交状態にはなると思います。
そこから選別できるスキルが有ればいいですが。
あまり進んでいない自社プロダクト開発
単価、時間ともに理論値に近づいています。
ここから先に売上的な成長は見込めないので、やり方を変える必要があるんですが。
どうにもプロダクトオーナーとしてはまだまだ未熟らしくうまくいきません。
最悪でも年内にある程度の形にしたいんですが。
このブログもお金の話よりユーザー数の話とかもっとしたいです。
グロースの話とかマーケの話とか。
客単価から考えるWebサービスの現実問題
客単価と人件費などの開発費用を考えると、選択肢ってかなり絞られるよねという話をします。
1万円／年という商売（高単価）
1人のお客さんが平均年間1万円使ってくれるようなサービスを考えてみましょう。（粗利と考えます）
1年で必要な開発費用が、ざっくり10人で1億円だとすれば、客単価1万円で1万人のお客さんが必要です。
1万人と考えればニッチなジャンルで行けます。
営業が動いても良いと思います。1人1日10人対応したら年間2000人くらい対応できますから。
しかし1年1万円という単価は結構でかいです。物販だったり、不動産や婚活や就職など、こういったものの特徴として「人生で発生回数が少ない」＝「リテンション（リピート）が見込みづらい」というのがあります。
なので高単価帯というのは「広告＝札束での殴り合い」になります。
大きな資本になかなか勝てません。
1000円／年という商売（低単価）
年間1000円、月100円程度と考えれば、例えば手数料ビジネスのような「ちょっとした中抜き」のようなビジネスモデルでもいけそうです。
しかしこの場合は年間1億円稼ぐためにお客さんが10万人必要です。
10万人を得るためには一朝一夕にはいけませんから、資金調達が必要になってきます。その場合Exit戦略を求められるわけですが、上場するなら年間10億円くらい稼ぐ必要が出てきます。
そうなると必要なお客さんは100万人です。
100万人のお客さんとなると、ニッチなジャンルでは無理かギリギリです。
例えば「食」とか「物販」とか「予約」とか、大きめのジャンルで戦うしか無いのですが、その場合既に競合が沢山居ます。ブルーオーシャンは基本的にありません。殴り合いです。「◯◯に限定した食」とか「◯◯に限定した物販」となるとニッチジャンルになるので厳しいです。
サービス開発者が取れる基本的な選択肢
１．高単価帯で、巨大資本と戦う（数万人のお客さんを狙う）
２．メジャージャンルで競合と戦う（100万人のお客さんを狙う）
まあどっちも凡人には無理ですよね。
天才が複数人集まってワンチャンどうかという感じです。
例外的な存在：ゲーム
これはちょっと例外です。現代のゲームは本当にうまいことやっています。
だから選択肢は３つですね。
現代のWebサービスは、それ以外を探す旅
無くはないです。
例えばWebオンリーのサービスとか、マルチデバイス対応のサービスを少人数で作ってバイアウトしてしまうとか。
卸業者のように、どこかの中間に入り込むことで生き残るとか。
シェアリングエコノミーでこれまでに不可能だったビジネスを成立させるだとか。
技術一本で金融系に手を出すとか。
もっと単純にtoBのサービスをやるなら話がぜんぜん変わります。こちらのほうが現実的ですね。コツコツやる感じ。toBの方がお金が動いてる説もありますしね。
私は最近「全国民をターゲットにできるジャンル」を模索しています。
大言壮語を言わないといけないのが辛いところですが、普通に戦略的に考えると普通に一つの選択肢だと思います。
思い付いたアイディアがイケてるのか確認する方法
１．それは札束で殴り合うタイプのものではないですか？（大量の広告が必要なジャンルではないですか？）
２．１ではない場合、それはニッチ過ぎませんか？100万人のユーザーを取れそうですか？
ここで解決できる新規サービスには中々出会う機会がありません。出会っても大抵失敗しますが。
技術的負債ならぬ、仕様的負債について
技術的負債っていう話、プログラマーは大好きです。
こいつらはコーディングの邪魔をし、プロジェクトを遅れさせ、残業を増やします。
だから皆嫌いなので技術的負債をどうにかしようと議論します。
ただし、概ね技術的負債を減らす術を身に着けてくると、それでもコードの複雑性が解消されないことに気づきます。
リーダブルに作っても、疎結合に作っても、SOLIDで作っても、どうしてもコードがぐちゃぐちゃになり、相当頭がいい人でないと全体を理解できない代物に成っていくでしょう。
あるいは新しく参画した、優秀なプログラマーたちによって作られたプロジェクトのコードが理解できずに悩むことで気づくかもしれません。
技術的負債の他に敵がいるということに。
その一つは仕様側の複雑性の問題です。
多くのプログラマーが気づくけど、中々手を出せず、それどころか議論にすら成りづらい仕様的負債について考えます。
仕様的負債がどのように発生するか
このテーマだけで論文が書けそうなくらい重い話ですが。
今回は単純に「なぜ仕様が複雑化するか」の話を考えたいと思います。
私の観測範囲から見えてくる原因は、大体次のとおりです。
- やろうとしてることがそもそも複雑
- 市場最適のし過ぎ
- 状態数を増やしすぎ
- 施策の取り下げができていない
- 環境の場合分け
- 例外の作りすぎ
ちょっとずつ説明していきます。
やろうとしていることがそもそも複雑
Webサービスだと例えばECだとか決済だとか予約とかSNSだとか、あるいは国内向けのEMSだとかCSMだとかCMSだとか金融システムだとか、ああいうのはそもそもどう足掻いても複雑です。
複雑だからこそそれだけで仕事として成り立っています。導入に何億円もかかったり、それだけの機能を持った単一サービスが生まれたり。
これらは一回関わってみるとわかりますが、どれだけ単純化しようにも限界があります。ちなみに似たようなことが複雑性保存の法則で言われているらしいです。
市場最適のし過ぎ
例えば会社向けに導入するシステム開発などでよく言われますけど、会社側が自分達の仕事のフローの変更をせず、システム側にその複雑性を要求するとシステムがとんでもなく複雑になり工数が多くなります。
別の例で、最初にシンプルに作っていたサービスでも、売上が伸び悩んできて個々のユーザーに最適になるようにあれこれやってるとどんどん複雑になってきます。
状態数を増やしすぎ
例えばUserが1Modelとして存在していればいいんですが、UserをCustomer、Providerのように2Modelとして扱うと複雑度がかなり増します。
リボン型ビジネスとかそうですね。例えば売り手と買い手が居るようなシステムとか。
これに更に売り手、買い手、仲介のように3Modelにするともっと複雑度が増して工数が爆発します。
別の例で、Userを初回ユーザー、未ログインユーザー、ログイン済みユーザー、お得意様、のように分けていくとどんどん複雑になっていきます。
もっと小さいトランザクションレベルのところでも、送信前、送信中、送信後で3状態ですが、2つのトランザクションを組み合わせると3状態x3状態で最大9状態になります（ここは少し仕様的負債よりも技術的負債に近い気がしますが、2つのトランザクションを同時にやらなきゃいけない状況というのは仕様的負債だと思います）
こういう一見小さな状態数の増加で実はシステムの複雑度は爆発します。
施策の取り下げができていない
サービスをもっとよくしようとしてあれこれ入れたもので、あまり効果がなかったものが取り下げられていないケースです。これは謎の機能として邪魔をし続けますが、リファクタリングなどで解決できるものではありません。
以前見かけたのが、AppleやGoogleに「新機能を入れたらアプリを目立たせてあげるよ」みたいな取引に応じた機能が放置されていたケースです。2,3社で見ました。
環境の場合分け
例えばiOSだと、iOSバージョン14,13,12,11,10,9で使えるみたいなアプリが有りましたがそこそこ地獄でした。
バージョンごとに書き方が異なるケースがあり、複雑度が上がっていました。
またはスマホだけじゃなくタブレットでも専用のレイアウトがあるだとか、小さい端末の時と大きい端末の時で処理を変えるとか、そういうケースがあります。
例外の作りすぎ
これは分かりやすいですよね。
実際のビジネスは例外のオンパレードです。ECサイトで「明日まで3000円以下の商品は送料無料」とか、状態数増やしてる上に例外を増やしています。
期限付きの例外とか注意しないと負債まっしぐらですよね。
仕様的負債が発生する理由（複雑度が上がる理由）
- ビジネスがそもそも複雑
- 構造が少し複雑になるとシステムは爆発的に複雑になるということに気づいていない
- 人間の思考はプログラム的ではない
- 工数が増えると嬉しい人達が居る
- 非エンジニアの複雑度に対する危機感の薄さ
こんなところでしょうか？
仕様的負債が事業に及ぼす影響
- どんな機能追加もひたすら遅くなる
- バグが増える
- バグかどうかの判断が付かない
- 仕様を全部把握できる人が居なくなる
- 優秀で高給な人しか改修できなくなる
どこでも起きてます。
仕様的負債を避ける方法
- 複雑な仕様を安易に受け入れない（技術者サイド）
- 単純な仕様を検討する
- 使ってない仕様を破棄する
まあほとんどできてる所無いんですけどね。
エンジニアができる仕様的負債に対するアプローチ
現実問題これってあり得るんでしょうか。
仕様的負債の解消というのは技術的負債の解消よりも影響範囲も大きくどうなるか分からない部分もあります。イメージとしては盆栽の剪定作業のような感じですが、コア事業のために何かを捨てるとか変えるわけですから、そこへの責任が発生しますし、非エンジニア組織への説明やユーザーへの説明も発生します。
世の中どちらかと言えば、とにかく気にせず複雑にしてしまい、誰も触れないくらいになるんだけど、最終的に東大卒のエンジニアが長い時間をかけてちょっとずつ変更できるカタツムリのようなスピードで何とかやっていく、みたいな企業が多い印象です。それができないところは停滞していくという。
ライブラリーの開発など見ると、結構スクラップ・アンド・ビルドを繰り返しているので、ああいう風にできたらいいのにと思う一方で、ユーザーとしては「前と全然仕様が違う！」と苛つくこともあるのでどっちが良いんだろうと未だに答えが出ていません。
あと、すごくシンプルにした結果自分らの仕事がなくなるというケースも、いやそれはないか。やることは沢山ありますからね。
自分がこれからPOになることがあったらそこらへんの課題感を持ってやってみたいと思います。
非機能性って大事だよねって話、あと反省
ここ1年は非機能性に触れる機会に多く恵まれました。
ファッションモデルさんと仕事したり、インスタ映えを目撃したり、ブランディングの仕事をしてる人と話したり、表参道やら青山やらをウロウロして、美意識高い人に出会ったり、ダイエットしたりエステしたり、紅茶飲んだりコーヒー飲んだりカフェ行ったり、花に囲まれて仕事したり、コミュニケーションを円滑化する仕事してる人と話したり。女子かな？
これまでだって色んな業界でシステム開発をしてきましたけど、これまでの人生とはダイブ毛色の違う１年で、色んな意味でエキサイティングでした。
これまでと価値観がだいぶ違う人が多く、まるで深海生物が浅瀬まで来てその生態系の差にカルチャーショックを受けてるような気分でした。
それで気づいたんですけど、我々エンジニアって相変わらず非機能性を軽視していますよね。いや我々とか言ったら主語がデカイと怒られるので「私」としておきたいですが。
エンジニアは機能的な生き物なのでしょうがないんです。酸素を吸って二酸化炭素を吐き出す生き物なのでしょうがないんです、というのと同じです。
そっちの方が得意だし、非機能性が不得意なので見たくないんです。
服とか見た目とかコミュニケーションとか人脈とか、デザインとか花とかマーケティングとかブランディングとか、そういうのって苦手なので「本質的じゃない」って言って目を背けたくなるんですが。もう昨今のエンジニアは「デザインの力」とか「非機能性の力」とかそういったもが死ぬほど重要だということを仕事を通じて百も承知なんですよね。
Viewの表示速度やボタンの触り心地や、色や優しいエラーコメントとかチュートリアルとか、そういうのが大事だってもう知ってます。
だけど未だにそういった非機能性の強いものを受け入れられない気持ちがある。そういう非機能性の高いものは機能的に劣っていて欲しいという気持ちもある。美男美女は性格がクズであって欲しいと願っている。コンプレックスなんだと思います。
一部の人は全然違うんですけど。私の中には多分ありましたし今でもきっとあります。
でも世の中のプロダクトをたくさん見ると、機能的にクソで見た目もクソなものもあれば、機能的に良くて見た目も良いみたいなものもあります。別にトレードオフではない。
そして今の世の中ってもう機能的には充足していて当たり前な時代ですから、非機能性を高めていかなきゃいけないんだと思います。言い方を変えればようやく非機能性に力を注げる時代に成ってきたんだと思います。サービスもそれ以外も。
だから私のような機能性の生態系の中に居る深海生物も、非機能性の世界に積極的に触れていかなきゃならないんだろうな、と思いました。
どっちも勉強していかなきゃならない。
そこでは私のような者が無意味と思っていたような「花」が、実は人の心にプラスの効果を与えていたり、コミュニケーションを生んでいるという「機能的存在」だったりします。そういうところを見にいって発見していかないといけない、特に機能性に強い人ほどその生態系から出たがらないと思いますが、今後それではジリ貧なんだと思いました。まあ死にはしないんですけどね。
あとこんだけ言っておいて、未だに仕事人間なので有言実行できていないですが。とりあえず気づきましたという段階。
そういえばこういう事象の分解みたいな話まえもしたな、と思ったんですがサブスクの話で書きましたね。
近況 2021/03/14
世間は今どんな感じなんでしょうか？ 私はここ1年大きな変化があったおかげで、周囲の変化が掴みづらいです。
先月1件仕事を失って、今月から2件仕事が増えて、もう1件増える余地もある、そんな状態です。
どうやらここ1年で新規アプリを3件リリースできそうで、ポートフォリオが更に充実してきそうです。こうなると案件は探すものというより向こうから来るようになってくるのですが、じゃあそれらの依頼をどこまで引き受け入れるかという線引きが更に難しくなってきそうです。
こういう状態って、もしその仕事を誰かに振れるような類のものなら人を増やしていくとどんどん儲かるというステージになると思うんですが、あいにく人に振れるような仕事ではないので限界があります。
不思議なことに引き合いが多くても単価の方は相場を脱さないので、どれだけポートフォリオが充実しようが年間2500万円を超えるのが厳しいと思います。普通に働くなら1200万円も超えません。フリーランスエンジニアの上限感があります。
もちろん優秀な若手を仲間に入れたら私も仕事を振れるようになるんでしょうけど、IT業界は会社間の人材の奪い合いが激しく、何かしらスペシャルな物を持っている会社でなければその奪い合いに負けると思います。私は余裕で負ける自信があります。
だから一番いい選択肢は「仕事が安定したのでこれからは私生活を充実させていこう」なんでしょうけど、そんな器用なことが自分にできるのか疑問です。いややっていかなきゃいけないんですけど。
結局やっぱり自社サービス持ちたいよね、という話になるのですが、ポートフォリオが充実したことによって目先の売上を取りに行った結果時間がなくなるという本末転倒な自体に陥ります。
ってこれ、多くの受託会社で起きてることを1人でやってるだけですよね。ここを脱せるかどうかが一個の試金石になるとは思います。
あとは大きな受託会社と仲良くする手もあると思うんですが、そんな良い会社あるんですかね？信じて任せられる会社、思いつかないです。
そう言えばFlutterがついにWebも対応したみたいですね。
ポジショントークをすれば、良いような悪いような微妙なところです。勉強していかないといけない気もするんですが、やはり時間がないので後回しになってしまいますね。
そもそもそれ言ったら英語勉強して外資と絡みたいというモチベーションもあるんですけど。英語は更に時間がかかる。
