大血管転位症(TGA)と前置胎盤

このブログでは完全プライベートのことを書くことはしてこなかったが今回は例外的に書いていきたいと思う。

先月産まれた息子は大血管転位症(TGA)という難病を抱えて産まれた。正確に言うと息子の場合は完全大血管転位症である。病気の定義はもっと専門のサイトや医師に聞く方がいいが、簡単に言うと心臓の大動脈と肺動脈が先天的に入れ違っており結果的に全身に十分な酸素を含んだ血液が流れないためチアノーゼ状態になる病気である。

今回はこの病気の体験記を書いていこと思う。

診断

初めて分かったのは20週頃だった。妻の検診日で今日ひょっとしたら性別が分かるかもというのんきな会話していて病院に送り出した。お昼頃に妻から連絡がありどうやら心臓の血流の流れに反対になっているという、そして後日詳細に調べるという連絡だった。

その連絡を受けた時の衝撃は人生で最大だった。

ともあれ大血管転位症を調べている人はここで意外と早期に気づいたんだと印象を受ける人は多いと思う。実際、私達が通院していた病院は大学病院で胎児心エコー検査していたので早期に見つかった(大学病院に通っていたのはそもそも別の理由)。

決断

良くも悪くも中絶が出来る22週未満で見つかった。子どもがTGAであるだけで中絶をするとはならないのだが運悪く別の悪い情報も受け取った。それが前置胎盤の兆候である。結果を書くと全前置胎盤に最終的になった。簡単に言うと胎盤が産むための経路のところに出来てしまったので通常の分娩で出産することが出来ない。基本的に前置胎盤と診断された場合は帝王切開になるケースが多い。そして前置胎盤は一般的に早産になりやすい、というよりも出血の危険性があるため早期に帝王切開で産むことが多い。

ここで再度TGAの話になるのだが、TGAは産まれた後に何もしないまま1ヶ月経つと9割方亡くなってしまう。そのため産まれてすぐに酸素をより供給するために出産直後にカテーテル手術を実施し、大体1週間後ぐらいを目処に大動脈スイッチ手術(ジャテーン手術)という大手術行うのが今は一般的である。その手術を行うために出来るだけ手術に耐えられる体が必要なので、子どもを出来るだけ胎内で成長させなければいけない。

つまり前置胎盤という母体を考えた時は早期の出産が望ましいが、胎児にとっては限界まで胎内で成長させる方がよいため相反する方針となる。また前置胎盤の中でも癒着胎盤を併発すると子宮摘出になるため、子宮摘出(実際は母体もかなり危険)かつ子どもも助からないという最悪のケースをなる可能性があった。

中絶するための残期間は約1週間程あったので夫婦でとにかく話し合いとまた後悔したくないため情報収集に専念した。

結果的には産む決断を夫婦でした。実際のところその1週間の中で胎動が始まり、またその時点で胎児は非常に元気に育っていたのも理由だ。
ただ誤解して欲しくないのは私達は産む決断したのであって他の人にも産むことを勧める、同様に中絶を勧めることはしない。誰かがどうとか、情報がこうだからではなく自分達はどうしたいのかで最終的に決断をして欲しい。

ただ当時参考になった情報として以下を共有したい。

  • スイッチ術の成功率は9割以上。死亡率は3%。
  • スイッチ術の手術時間は5~6時間。ただし準備やその後の検査も含めると12時間は覚悟した方がいい。
  • 手術後の1ヶ月の経過は重要。
  • 無事成功した場合は普通の子と同じように運動や体育が出来る子が多い。
  • この病気は別の遺伝性疾患と併発することは少ない。

出産までの期間

産むと決断した後は心が前向きになれた。とはいえ、早産は避けたいため妻は自主的に制限をかけた。 まず会社に相談して22週以降はリモートワークに特別に切り替え・産休も1ヶ月ほど前倒しで取得した。 妊娠高血圧腎症を避けるために減塩弁当を主体とした食事を行い、通院はバス・タクシーを使って出来るだけ歩くのを避けた。これらを遂行してくれた妻には非常に感謝している。

夫として重要な役割の一つとして妻を精神的に支えることがかなり重要だった。とくに妻は自分の行動によって早産(=死のリスク)になることのストレスを長期間に渡って感じる。そのためかなり弱気になってしまうことがあった。ただそのタイミングで夫も弱気になってしまうと妻のストレスの逃げ場がなくなるので、とにかく元気で振る舞おうと気をつけた。

病院選び

病院選びは生命がかかっているので非常に重要である。とはいえ妊婦であるため色々な病院にセカンドオピニオンとして受診するのは現実的に不可能だった。

以下は今だから思う病院選びのポイントだ。

  • 産科と小児科が強く、関係性が良い。
  • NICUは絶対。出来ればPICUがあれば尚可。
  • 子どもの心臓手術の件数を多く実施している実績がある。
    • スイッチ術を多く実施している病院でも年間5件未満であるので、0件はキツいけどあっても1~2件ぐらいの比較しか出来なかった。
  • 家から比較的近い。
  • 管理入院に対応している。
  • 輸血が大量にある(これは前置胎盤を考慮)。

実は以上のように絞り込みをかけていくと東京であっても対応できる病院は3~4病院ぐらいに限られる。 結局、最初から受診していた大学病院が条件に一致していたため別の病院に切り替えることをせずに済んだ。ここまで書けば鋭い人は分かるが私達は東大病院を受診していた。

胎児の体重について

TGAで胎児の体重は非常に重要であるためとにかく大きければ大きい程よい。そのため最後の出産日までずっと気にしていた。体重はどんなに少なくても2000gはまず必要である。これは産まれてすぐのカテーテル手術で実施するための目安の体重である。次の指標は2500gである。これはカテーテル手術で一般的な器具が使えるので。そして最後は2800gである。これはスイッチ術の時に確か中心静脈カテーテル(ここはうろ覚えなので医師に聞くように)を使えるのでリスクはあるが手術の正確性に繋がるらしい。要するに手術中にちゃんと大動脈と肺動脈がちゃんと機能しているか確認できるみたい。

私達の場合は結果的に34週4日の約2900gで産まれた。

管理入院

妻は2回管理入院をした。1回目は10日間。2回目は出産日までの1ヶ月間を入院した。行動が制限されるデメリットもあるがメリットが大きかった。やはり家に居て通院となるとそれなりに運動してしまうし、食事も病院のように完全に制限することは難しい。ただ、これは病院によると思うが管理入院したいですと言えば出来るものではなかったので病院の状況に大きく左右されると思う。 他にも毎朝心音チェックで定期的に胎児の確認が出来たり、心理的にも同じ境遇の妊婦も同室だったので打ち解けていて良かったみたいだった。とにかく何よりも急変があった場合に病院にいるので対処が出来るということはストレス軽減にはなっていた。

申請・手続き

妻はかなりの長期間を入院していでその分医療費が大きくかかる。そのため事前に限度額適用認定証を取得すること。また同時に加入している民間保険が適用されるかは早めにチェックしておいた方が良い。次に産まれた後の子どもの手続きだ。スイッチ術だけで費用は実費だと800万円以上かかるし、NICUに入院した場合は1日4万ぐらいかかるので出産後にすぐに手続きが必要。 ちなみに保険適用されるので実際には負担金はゼロである(今回ほど国民皆保険に感謝したことはない)。

生まれる前にやること

  • 自分のマイナンバーカードを取得。実際にはマイナンバーだけで行けるかもしれないけど、マイナンバーカードがある方が申請が簡単だったりとにかくメリットしかない。

以下が産まれた子どもに対して翌日行ったこと。以下はすぐにした方が良い

  • 出生届
  • マイナンバー入り住民票の取得(未熟児の養育医療で必要だった)
  • 健康保険に加入(自分の子どもは国民健康保険だったのですぐに役所で手続きした。ただし、会社員の場合は違うのでそこは各自が調べる必要あるので会社に相談すること)
  • 子供の限度額適用認定証取得
  • 乳幼児医療費助成制度(マル乳)の申請。事情を言えばその場で発行してくれた。
  • 育児手当

以下は医師から意見書を貰えば出来ること

  • 未熟児の養育医療

以上の申請をしたらすぐに病院に提出すること。また出生届をすぐに出すので子供の名前は事前に決めておくこと。

出産日

出産日は一応の生まれる1ヶ月前頃に仮の日程が決まっていた。TGAは胎児がすぐにチアノーゼになるため出産日は万全の体制で望むため完全計画分娩で行われる。しかし、結局最終確定したのは仮日程が近くなってからである。

そしてなんとか予定日を迎えることが自分達は出来た。

高リスクであったため当日の出産の順番は1番手だった。朝7時過ぎに病院に着いて、妻の貴重品を預かり7時半頃に分かれた。8時頃に処置室に妻は運ばれ9時過ぎ頃に子どもが産まれた。9時半に子どもが産まれたと報告があり、すぐに子どもはNICUに運ばれた。そして11時頃に子どもと初めての面会をして予想よりも酸素濃度は安定していた。ただし、今後ためにやはりバルーンカテーテルで卵円孔が閉じないようにするための手術を11時半頃から実施するとお話があった。

バルーンカテーテルは成功してその後血中酸素濃度も80台で安定することが出来た。子どもに関して言うとかなり順調だった。

時間を戻す。

実は裏で妻の方が生命危機レベルで状況に陥っていた。10時40分頃に病室に帰ってくる予定というのを報告があったがその後の連絡がぷっつりと途絶えていた。
なんとか看護師さんに話を聞いてみると出血が止まらないらしい。その時点でかなり嫌な予感がしていた。その後2度産科医の先生が待合室に来てやはり出血が止まらないらしいとのことで緊急で輸血の同意書を書いた。
合計で5500mlの輸血をしたらしいので体の血液をすべて入れ替えているレベルの出血だったが、ぎりぎり子宮摘出せずに済んだ。もしこれが東大病院ではない普通の総合病院であれば最低でも子宮摘出でもっと行けば生死の問題だった。

出血が止まったのは夕方頃でその後ICUに妻は入ることになった(次の日にMFICUに移動になった)。
ただあくまで夫目線で今書いているので実際はもっとかなり壮絶な現場だったと妻は話ししている。

今となっては何が原因だったかはっきりと分からないのだが、恐らく前置胎盤の一部で癒着が起きていたのではないかと思う(ただし妻も私もだろうぐらいでしか分からない)

妻の状況を聞き20時頃に病院を後にした。

出産日から手術日まで

上に書いたように次の日の午前中から大急ぎで役所周りを私がした。

NICUの面会は毎日1時間することが出来た。ただし妻が入院中は感染対策として時間をズラして面会する必要があった。

子どもは予想以上に安定していたので、途中で抱っこが出来たり体を拭いてあげたりすることが出来た(本当に良かった)。この時点でこの先どうなろうと本当に産む決断を自分達がして良かったと心から感じた。

スイッチ術の手術日

出産日と同じく朝7時頃に病院に着いた。NICUで出陣式を行い手術室まで私が付き添った。さすがに手術室の前で子どもを見送った時は涙が出そうになった。

手術時間としては5~6時間の予想だった。TGAは大動脈と肺動脈を入れ替えるのが注目されるが、手術の難しさは実は冠動脈の入れ替えの方だ。この冠動脈は個々人によって伸び方が違うので万が一子どもが特殊な冠動脈の伸び方をしていると手術が難しくなる。出産日から手術日までの1週間でもこの冠動脈についての検査を元に計画を建てるらしい。しかし造影剤を使ったCTでも限界があるらしく最後は実際に開腹してみないと分からないという結果になった。ただ自分の子は事前に恐らくそこまで一般的な伸び方をしているらしいぐらいの情報は突き止めていたが。

手術は15時過ぎ頃に終わった。15時半頃に執刀医の先生がお見えになって無事成功したと。この時ほど嬉しかったことはなかった。ただ、その後の検査もあったので結局子どもに会えたのは19時過ぎ頃だった。 手術後のためNICUからPICUに移動になった。ちなみにPICUはNICUより厳しく一日に会えるのは両親合わせて15分程。しかも、別々に面会する必要があった。点滴もぐっと増えて16台がセットされていた。

人生で一番長かった日はこうして終わって、待機室に約12時間待っていた。とても、とても疲れたが成功して良かった。

退院まで

そろそろ書く量が多く辛くなってきたが、あともう少し。

子どもは驚異的な回復力を見せて、金曜日が手術日だったのにPICUからNICUへ次の週の水曜日には移動になった。本当にこれは驚異的だったみたいで通常であればもっともっと長い。事前にPICUから移動は1, 2週間で出ると思わないで下さいねと伝えられていたのでいい意味で肩透かしにあった。

その後NICUでも驚異的な回復力を見せて手術から3週間後にはGCUという退院間近のところに移されている。その間に点滴・胃管チューブなどは全て無くなった。体もかなりむくんでいたのが、かなりすっきりした。あまりにも驚異的な回復力だったため家での受け入れ準備を全くしていなかったので大急ぎでしている。

ただ、心臓手術をした子は感染性心内膜炎という病気に感染するリスクが生涯に渡っておきるらしい。そのため歯の治療やピアスなど細菌の侵入に注意する必要があるみたい。リスクがある場合は抗生剤を適切に処方して貰う必要がある。

最後に

なぜ産む決断を最後にしたのか。

それはどんな結果になろうとも受け入れると最終的に決めた。もし子どもに障害が残ったり、もしくはそれ以上の状況になったとしても受け入れると。もちろんその結果子どもがどう思うのかは別である。

最後に何度も書くがこの記事の内容を見て産む産まないの決断をして欲しくはない。

業務委託先を変えた

先月、業務委託先を変えるために営業活動をしたので感想をメモしていきたい。

業務委託先の変更理由

今はiOSエンジニアとして活動している。元々、WEBのバックエンド・フロントエンドをメインにしていたが3年ぐらい前にiOSに転向した。以下の記事がその内容。

developer-cassette.hatenablog.jp

業務委託先の変更理由は当時未経験のiOSの分野に挑戦するため単価を落としたので、そろそろ回復させたいのが理由。元の現場で交渉することも出来たが過去に交渉経験もあり、大幅な増加は見込めないと判断した。

先に結果を書いてしまうが、単価も上がり労働条件も前回の現場と変わらないので成功と言っていいだろう。

前回の記事の答え合わせ

まずクロスプラットフォームアプリについて書いていきたい。上の記事では今後流行るかもぐらいの温度感だったが、今後の新規アプリの5割はクロスプラットフォームで開発されるぐらい伸びそうな勢い。ただし単価については予想通りでクロスプラットフォームだからといって上昇はしていない。

ただフルリモートなど労働条件が柔軟な現場が気持ち多そう?なので総合的に判断した方がいいだろう。あと自分の予想としてネイティブアプリエンジニアの単価は上昇していくだろうとしていたが、クロスプラットフォーム技術の進歩のおかげで上がることはなかったので予想を外した。

脱線するがFlutterかReact Nativeかについてに言うと、Flutter一択だと考えている。RNはそもそもエンジニアの確保が難しいし、描画処理についてもFlutterの方が速い。クロスプラットフォームとは言えネイティブの知識がゼロで最後まで完成させるのが難しい上に、ネイティブエンジニアでRNを支持している人はいないので確保が難しいというのが理由だ。

RNだとReactの知識が活かせるからという理由も分からんでもないが、そもそもフロントエンドエンジニアの数が潤沢にいるわけでもないので兼務させる場合、フロントエンドのエンジニアが本当にやりたいのかも疑問である。

ただ個人開発でどちらを選択するのかは自由だと思う。

営業活動について

今回もエージェントを通さず直接営業した。8社ぐらいに連絡して面談までたどり着いたのが2社だったので、正社員採用に比べて業務委託先を見つけるのは比較的難しい。 とくにiOSエンジニアの場合は必要とする頭数が少ないのでバックエンドエンジニアに比べて苦戦する。

反面、面談では自分の経歴が評価されたのかiOSエンジニアの場合だらかなのか分からないがあまり技術的なことを突っ込まれることはなかった。iOSエンジニアの場合、使用している技術の幅がバックエンドに比べて狭いのでお互いに技術的な質問は少ないのと、Swiftという言語仕様が複雑な言語を使っているので絶望的にプログラミングが出来ない人というのが少ないのも理由だと思う。反対にバックエンドはすごい人もいるが、レベルの低い人もいるので面談でのチェックが厳しくする必要がある。

その他ソフトスキルというか技術以外の部分についての質問が多かった。自分もそれは正しいと思っていて、30歳以上のエンジニアに細かい技術的な質問をするよりも、本人の得意不得意の領域やその人の仕事のスタンスを深堀りした方が実際に仕事する上では良い結果になる。

まとめ

昔は請負と準委任契約でより時間が縛られないメリットとして請負にメリットがあった。だけど最近のリモートワークの流れによって通勤時間が無くなり、場所に縛られないという請負のメリットが相対的になくなった。ただし、単価交渉や外注で再委託できるなど上手くやれば請負の方が爆発力はある。

2021年の振り返り

例年書いているので今年も書こうと思う。

2021年のプロジェクト

developer-cassette.hatenablog.jp

以前記事を書いた通り共同作業のプロジェクトは失敗した。前回はパートナーについて書いたが今回は開発面について書いていく。

総括として開発期間が長くなりすぎた。
当初の予想を超え十ヶ月ぐらいかかってしまった。

理由の1つ目にSaaS製品の見積もりが甘かった。toC向けと違い最初の方にマルチテナント設計など重要な設計・開発が序盤に存在するため土台部分の構築に時間がかかった(Chrome拡張や動画周りの知識も含めしょうがない部分はあるが)。SaaStoC向けよりも目に見える以外の機能部分に時間がかかることをもっと覚悟していれば良かった。

フロントエンドではフルSPAにしたのもミスったと思った。重要な機能以外であれば単純なフレームワークのテンプレートで作った方が時間は短く作れた。SPAにするとAPIの定義やフォームのバリデーションな一個一個は大したことはないけど積み重ねると時間がかかった。

根本的なところ言うと最初から製品レベルのクオリティではなく、検証用のマイルストーンを設定すべきだった。この辺は自分がもし業務委託で関わっていたらそう進言していたと思うけど自分のプロジェクトだと視野が狭くなるなと実感した。

自分が本当に欲しかったのか

ただ改めて上で書いた失敗内容を分析すると、失敗する要因だったとしても原因ではないなと。別に開発にミスっても上手くいっているプロジェクトは無数にある。

色々と違いを考えた時に「このサービスが解決したい課題に自分が共感していない」とシンプルに思った。振り返ると今まで作ったサービスは常に誰かの為に作ってきた。理由は単純にどうしても自分が解決したい・困っていることが無かったので色々と考えてアイデア出してきた。とはいえ想像以上に他人の課題についてしっかり理解するというのが大変だった。

例えば本当にお金払うまで課題と感じているのか・代替手段で満足しているのか・本音で喋っているのか・ヒアリング対象は正しかったのかというように実は課題把握はそんなに簡単な作業ではないし、むしろサービス作りよりも全然重要である。
しかも困ったことに自分は課題把握のヒアリングが得意でも好きでもない。

もちろん原体験が本人に無くても成功するサービスはあるんだけど、個人開発(主語がデカいので自分)においては原体験が本人に無いと難しいと考えるようになった。それは単純にやる気の面もあるし、上に書いたようにヒアリングするリソースが少ないというのも理由にあると思う。

そう考える今さらだけど原点に戻って自分が解決したい課題や情熱を注ぎたいことに注力することが遠回りになるかもしれないがいいのかなと思うようになった。

何故フリーランスを続けているのか

今年自分はなぜ会社員に戻らず・受託企業も作らずの中途半端なフリーランスを続けているのか考えた時があった。ずっと考えがまとまらずモヤモヤしていたのだがきっと30代は情熱を注ぎたい分野を見つけて注力したいのが理由なんじゃないかと最近思うようになった。

脱線するがここ1年間ある40代のエンジニアの人のブログを読んでる。その人は自分よりも圧倒的にスキルも高く、金銭面においても一生困らない、余暇で色々なところに旅している。まあ端的にフリーランスエンジニアの最終形態みたいな人である。ただ別に悲壮感があるわけではないが、自分が心血を注いだ代表作が無いので少し後悔しているようにも見える。

その影響?もあってか30代のうちに改めて特定のことに注力したい。
10年後、20年後に自分がどうなっているのかは分からない。けど上手く言えないが30代の時に情熱があることに力を注がなかったら後悔しそうである。もちろんスキルアップや売上で逃げ道を作り保険をかけたい気持ちももちろんあるが、そこはある程度リスクを取らないといけない。

それをやらずに別の道に進むのがなんだか問題を先送りしているように思うし、時間が経つほどやらない理由や出来ない理由が増える。

2022年について

実は自分が解決したい課題とアイデアは見つかっていて、それに向けて開発している。今回はシンプルに自分が欲しいものにした。3月までに正式リリースするのが目標。

出すぞ!出すぞ!

おわり

フリーランスの単価についての考察

実はエンジニアのフリーランスは単価についてのマウントが多い。単価は売上に直結するので結果的にそのフリーランスの実力と見なされるので自然とマウントになる。

ただ基本的には自分の得意な技術を切り売りするのが時間効率も含めて最大化しやすいので、つまらないけど簡単に出来る仕事を沢山こなすほうが良い。つまり単価とエンジニアスキルというのは一定レベルまでは連動するが、あるラインを超えると必ずしも連動しないと考えている。

という前提はありつつも取引先は重要だと自分も考えている。そこで今までの経験の中で最初考えていた変化した考えを書いていきたい。

儲かってるサービスは単価が高い説

昔はこの仮説を持っていた。この仮説はあながち間違いでもないが正確ではない。大手企業に所属した人なら分かると思うが事業部(サービス)によって予算が決まっているので、必ずしも儲かってるイコール単価が高いことに繋がらないことを説明したい。

最初に説明するとサービスが高い利益を出していたとしても投資フェーズなのか安定フェーズなのかで事情が変わる。例えば利益は高く出ているが実は成長率が鈍化していればもっと効率的な人員で仕事を回そうという意識が高まり、結果的に経費の支出が抑えられる。 逆に投資フェーズであれば多少の経費の誤差よりも売上・シャアの独占を目指す。つまり儲かってるサービスでも投資フェーズの方が予算が多く単価は高くなりやすい。

なぜこういうことが起きるのかと言うと、企業というのは新規領域に資本の投下を集中的に行いまずはシェアの独占、つまり売上の拡大を目指す。シェアを最大までを広げて成長率に陰りが見え始めたら、効率化を行い利益重視になる。もちろん最初から高収益なビジネスもあるので全てに通用しないが、スタートアップはこの理論で進めている企業が多いので、赤字先行のビジネスになっている。

安定フェーズはダメなのか

このフェーズはどっちが良い悪いというわけではない。不況であれば安定フェーズにいて嵐が過ぎ去るのを待つ方が良かったりするし、別のことに集中したいのであれば稼働が高くなりやすい投資フェーズのサービスよりも安定フェーズにいた方が良かったりする。 ただ今このサービスはどのフェーズにいるのかは意識しないと見当違いな不満を貯めることになる。

フェーズの分類

f:id:developer-cassette:20210916125528p:plain
製品ライフサイクル理論とは?段階ごとに事例やマーケティング手法を解説

上記図の引用サイト:
製品ライフサイクル理論とは?段階ごとに事例やマーケティング手法を解説 | YOBICOM

上の製品ライフサイクル理論と先ほど書いた投資フェーズと安定フェーズは話は似ている。成長期に取引すれば単価は高くなる。そして成長期を見分ける簡単な方法としては資金の大型調達をしたタイミングが外部から計測しやすいタイミングである。
大型資金調達の目的は一気に成長をドライブさせたいことが多いので、このタイミングで参画する方が変に大手企業のサービスと取引するよりも単価面ではよい条件になりやすい。また資金調達ではなくても新規事業に進出の場合でも予算枠を多めに確保するのでその場合でも期待値は高い。重要なのは分野で判断するのではなく、ちゃんと企業ごとに調査した方が良い。

導入期は技術的には先端分野というケースがよくある。個人的には今のVR・ARはまだ導入期だと考えている。もちろんVR・AR関係者は既に成長期だからという反論もあるかもしれないが、過去のソシャゲブームやスマホブームに比べるとブームというレベルかどうかは微妙であると個人的には考えている。

一番難しいのは成熟期でこれが安定フェーズに入る。難しいと表現したのは成熟期だけどその分野のニッチな箇所では成長が続いているパターンもあるので難しい理由だ。ただニッチなのは外から判断するのが難しいし、単価も相場通りに落ち着く可能性もあるので成長期と比べてメリットは少ないと思う。

まとめ

以上がフリーランスになりたての時と考えが変わったことだ。もちろん、そんな難しいことを考えなくてもっと簡単な方法あるのかもしれないし、もっと色々な面で検討した方が良い。ただ単価に関しては予想より違ったというのは出来るだけ避けた方がお互い良いだろうし、変に相場にこだわる必要もない。

最後に個人的に単価が低いフリーランスエンジニアも企業もダメとは思わない。外から見えていない計画があるかもしれないし成長スピードも異なるので比較することにあまり意味がない。

パートナーを解消した

以前から友人と2人でサービスを作っていたがその関係を解消した。
最終的なきっかけはクローズドβを通してサービスの需要が無さそうだなということが分かって、次の構想をあれこれ考えたがなかなか進まず解消することになった。

この過程の失敗で色々と経験したことがあるが、あくまで2人で一緒にサービス作る経験で得た考えを書き残したい。

前提としてお互い現在の仕事をしつつ、業務後や週末を利用してサービスの開発をしていく流れだった。相手は営業などビジネス分野が強く、自分は開発側を担当していて全体の作業としては自分の作業が9割以上だった。
ビジネス分野と開発分野それぞれに強みがあるのは合理的ではあったが、今考えると仕事をする上での性格面は違っていた。そしてその違いが根本的な部分で足をひっぱっていたと思う。

意見がまとまらない

お互いにどちらが立場が上というのは最後までなかった。ただ意見としてはコミット量・開発経験も含めて自分の方が経験があり結果的に採用されることは多かった。ただ、自分としては最終的には相手に代表になって欲しいという願望もあったので相手の意見に合わせ強引に進めることもなかった。

その結果、上記の性格面での違いもあり話がまとまらないことが多かった。とくに2つ目のサービス企画段階で起きた。お互い意見は確かにどちらも筋が通っている、ただし方向性が違うので意見がまとめるのが難しい。別にこれでどちらかが立場が上であればもうひとりが合わせればいいのだが、変に2人の意見の妥協点を探そうとするから話が進まなかった。ユーザーが求めているサービスかつお互いの強みを活かせかつお互いがやりたいと思う分野となると次の案がなかなか見つからなかった。

2人しかいなくても独裁者がいるべき

実は法人化した際には株式比率に上下を持たせて立場を作る予定だった。それ自体は間違っていないと思う。今でも貢献度や将来的な役割も含めて法人化のタイミングで株式比率は決めるのが良いと思っている。ただし、今の段階で上下の立場を作るべきだった。2人の関係が対等だと意見がまとまりにくいし、強引に引っ張っていく人もいないので小さい組織の最大の武器であるスピードの強みが活かせない。そういう意味では相手にその役割をして欲しかったが以下の点で難しそうだなと感じていた。

  1. 会社の看板が無くても一人で売上を上げられる
  2. 情熱とコミット量が高い

あまり相手を批判はしたくないのだが、この2点を相手から強く感じられなかった。そのため心の中では自分が引っ張らねばとは考えていたが、代表の役割と開発の役割を両方実行することにずっと悩んでいた。 結果的にリーダーが不在のまま解消することになった。

相手の意見について聞く必要はあると思う。しかし、最終的な判断・決断をするのは常に誰がと決めといた方が良い。もちろんフェーズや内容にもよるが小さい組織であれば権限をとにかく集中した方が良い。判断・決断も常に100%当てる必要はない。7割合っている、最低6割合っているぐらいでいい。それよりも手数を多くする方が重要だ、致命的でなければそれでいい。そういう意味で経営者はリーダーでもなく独裁者であるべきだ。独裁者ではないなら、その役割を放棄している。ワンマン経営というのは悪い意味に取られがちだが、初期の自分たちの場合はワンマン経営の方がスピードが出せると思う。

自分の反省点

結局自分も他力本願のところがあった。自分が弱いビジネス面や経営面をだれかに負って欲しいと考えていたし、自分一人でやる勇気がなく徒党を組もうしていただけであった。今なら分かるが強烈なトップがいない5~6人のチームよりも強烈なワンマンチームの方が上手くいく。成長がすべてを癒すという言葉があるが、まさにチーム云々よりもまずは売上の成長を目指すべきであり、チームを組むとかは目的ではなく手段だったと思う。

今後について

何も決まっていないが、開発したサービスを一般公開するまではしたい。

クラス設計の観点はテストが書きやすいかだけで良いと思う

クラス設計の観点はテストが書きやすいかだけで良いと思う。以下のその理由を書いていく。

テストコードが無い洗練された設計よりも、汚いコードでもテストコードがあった方が良い

よくテストコードが無いのにこのコードがキレイだと言う人もいるが、これってすごく主観的だよなと思う。実際にキレイだったとしても、後の人が意図を汲み取れず変な建て増しをすることもあるし、その当時は最適だったのかもしれないが、後にアーキテクチャの方針転換から微妙になったりすることはある。

またコードがキレイかの判断軸はかなりエンジニアの力量にも左右されるので判断が難しい。自分は関数型に影響されているので、副作用の無いコードに対して良いと判断しがちであるが、そもそも関数型に対して興味が無ければそういう判断にはならない。他にもDDDをよく勉強している人は恐らくDDDの観点からこのコードはキレイかどうかを判断しがちである。

つまり、どのコードが保守性や拡張性があるというのはそれぞれのエンジニアのバックグラウンドにも影響されるので絶対的なものが存在しないし、あったとしても現場で統一するのは難しいと思う。

その点テストコードがあるかどうかというのはすごく分かりやすい。テストコードが無くてこのコードは良いか悪いかという判断は実際によく読まないと分からないが、テストコード有無は一発で分かる。また、テストコードが書きにくいコードというのは何かしら問題があるので、必然的にコードの質は担保される。

というよりも自分の中でDDDもClean Architectureも関数型言語を採用する理由も結局テストコードを書きやすくするかの手段のような気がしている。なぜかというとDDDを採用しているけど、テストコードが書きにくいというのはあまり成り立たない。

結局テストコードさえあれば多少の設計のミスはリカバリできるが、テストコードのない設計ミスを後から修復するのは難しいので最初から用意しておけば良い。

テスト導入を阻むもの

色々な現場を見てきたがテスト導入を阻むもの障害は9割以下である。

開発工数が余計にかかるからやりたくない

これは本当によく聞く。ただこのパターンはハッキリ言えばその本人のスキル不足である。実際にテストコードをよく書く人なら分かるがテストコードを書く時間は慣れればそこまで多くない。コードのキレイさよりも網羅性が重要であるため、例えばコードの共通化が必要ないからキレイにそこまで書く必要ない。
テストコードは書けるけど、開発工数がかかるからやりたくない人は経験上いなかった。単純に経験なくて自信が無いからやりたく無い人が多く、その理由を開発工数にしているだけである。そもそもテストコードを書くも含めて開発工数の見積もりをするわけで別に考えているのがそもそもおかしい。

この手のタイプに対して論理的にテストコードのメリットを話しても無駄であるし、論破したところで解決するわけでもない。 結局テストコードのメリットを言葉や文字で説明してもしょうがないので、地道に書くことを指導する。 テストコードはただの慣れなので量を書けば、後に質は担保されていく。だから初期は細かい指摘をするのではなく、ただ単純に書いてあることを褒める方が良い。

また実際のサービスではテストコード前提の設計になっていないため、そもそも適用しずらい可能性がある。そのため、すぐに実践するのが難しいかもしれない。なので、そういう時はハンズオンを開いて地道に簡単なコードで試すのが良いと思う。強制的にやるのであれば、実際に外部から人を招聘してやるのも良いと思う。

テストコードを重視する文化

とにかくテストコードをきっちり書きましょうという文化を作ることが大変だ。確かにまだサービスにユーザーがいない段階においてきっちり書くことに対しては否定的だ。ただし、利益を生み出すフェーズに入ったならばテスト主体の設計方針に切り替えた方が良い。

React Nativeはメリット・デメリットがハッキリしている

少し前にReact Nativeの案件に携わったので感じたことを書いていきたい。
結論から言うとタイトル通り「React Nativeはメリット・デメリットがハッキリしている」というのを感じた。

自分について

自分はここ何年かはiOSのネイティブ開発を専門にしているので、どうしてもネイティブエンジニアとしてのバイヤスはかかることを承知して欲しい。また案件自体も直接React部分を構築したというよりも、ネイティブ部分との連携をしていたのがメインだ。ただ、React・TypeScriptの開発経験があるのでソースコードはよく読んだりしていた。

メリット

iOSAndroid対応のアプリを高速で作れる

具体的なアプリの機能については言及できないが、2.5人ぐらい人数で4ヶ月でアプリの大半の機能の構築が出来ていた。作業者の技能にも左右されるが、iOSAndroidのネイティブ開発者がそれぞれ別にいたとしてもこの期間で仕上げるのは可能だろうか言われると難しそうである。とくにアプリのViewのレイアウトに関してはHot ReloadがあるReact Native側の方が高速に開発できる。

もう一つネイティブ側の問題としてiOSAndroidで担当者がいるため、単純にコミュニケーションコストがかかるからである。そのためマルチプラットフォームの環境であればかなりそのコストを削減できるから

Expoが良さそう

ExpoとはReact Native上のフレームワークであり、SaaSとしてのプラットフォームでもある。メリットとしてはJavaScriptのみで開発出来て、面倒なビルド・配布・申請をExpo上でよしなにやってくれるらしい。
実はiOSの鬼門の一つはアプリのビルドだと思う。それはXcodeの学習や証明書など複合的に絡んでいるので、ネイティブエンジニアでも苦手な人がいる。その面倒なことをExpoがラップしてくれているので確かにこれは楽そうだなと感じた。

Xcodeを極力使わない

普段使っているテキストエディタを使えるのは地味にメリットな気がしている。Xcodeは容量でかい・重い・機能が多すぎるのでWeb側出身のエンジニアからしたら不評だと思う。自分も正直あまり使いたくないので基本はAppCodeを使って、要所要所でXcodeを使っている。結局Xcodeはアプリを作るためのアプリであるので、ソースコードの編集はより専門のIDEテキストエディタの方が機能としては優れている。

デメリット

Expoから外れると大変

これが結局最大のデメリットであると思う。メリットにも書いたExpoはいわゆるJavaScriptというWebに閉じた技術で完結するため非常に優れているが、逆に言うとExpoのサポート外の機能を使用すると大変になる。Expoをejectすると言われており例えばネイティブの機能をそのまま利用したい場合はejectする必要がある。その他にもマーケティング用のSDKを使用したいがそのSDKがネイティブしかサポートしていないためejectする必要があるなど。

こう書くとネイティブの機能を一切使わない様にすれば良いと思われるが、実行するのは難易度が高い。ビジネス側の事情もあるし、そもそもネイティブ機能を使わないと何でアプリに作ったんだっけとなる。初回リリースは大丈夫かもしれないが、サービスを継続すると必ずその判断は迫られと思う。

さらにメリットにあったアプリのビルド・配布・申請を自分たちで解決する必要になる。実際に難しいビルドのエラーが発生した場合Web中心に開発してきたメンバーで自力で解決するのは大変である。

Webとアプリの違い

直接React Nativeの問題ではないが、React Nativeを導入するWebメインの中心メンバーで引き起こされがちである。
例えば、誤解しがち一つにiPhoneiPadの開発は全然別である。Webでは現在レスポンシブデザインが中心にあるため、そのままの考えをアプリにもあてはめてレイアウト調整ぐらいの認識を持ってしまうことだ。 Appleもその誤解が生じているのを認識していてわざわざiPadOSというのを出して分離させている。そもそも、iPhoneiPadは画面サイズも違うのでそれにあったページデザインも必要で、ユーザーもiPhoneiPadでは求める機能が違う。

他にもアプリ化する目的の一つにPush通知もあるが個人的な経験から言うと初期リリースでは外した方が良い。ただ、理由を書くとそれ一つでかなりの文量になってしまうが、一言で言うならPush通知に夢を持ちすぎである。

ネイティブ連携が意外と大変

これは直接自分が担当して感じたのだが、React Nativeからネイティブの機能を呼び出そうとするとObjective-Cで連携箇所を書く必要がある。Objective-Cしかマクロに対応していないからという理由だったみたいだがとにかくObjective-Cを書く必要がある。Objective-Cが悪い言語とは別に思わないが現在のiOSの開発における主流ではないのは確かだ。Objective-CからSwiftのコードを呼びだすことも可能であるが、そうなると開発者はJavaScript(TypeScript)・Objective-C・Swiftの3つを覚える必要が出てくるのでかなり大変であるのであまりこの方法は取りたくない。そのため今回自分はObjective-Cだけでコードを完結させた。

また、TypeScriptからネイティブのコードを呼び出そうとすると型情報が失われるのでコンパイル時点でエラーを発見できない。そのためネイティブの機能に関しては実際に動かすまでは分からない。

React Nativeの採用はアリかナシか?

デメリットを結構書いてしまったが別に自分自身はReact Nativeの導入に否定的ではない。当たるかどうか分からないアプリをExpoのフレームワークに乗った上でサクッとリリースして検証するのはアリ。

ただし検証フェーズを終えたなら改めてReact Nativeで続行するかネイティブに切り替えるのかは判断した方が良い。恐らく継続的に開発するアプリでExpoでずっと要件を満たし続けるのは難しい。 結局、アプリの目的・機能・将来性のバランスを見ながら採用をジャッジするのが正しいと感じる。

そしてReact Nativeを導入するのであればネイティブエンジニアをコンサル要員で確保しとくのが良い。ビルド周りのエラーなどは頑張って自分で解決しようとするとかなり時間がかかるのもあるので。