サーバサイドエンジニアからiOSエンジニアへ転向した

そういえば最近WebからiOSの開発にシフトしたのでそのことについて記事を書いていく。
内容としては以下の2点を中心に書こうと思う。

  • なぜiOSエンジニアにシフトしたのか
  • どうやってiOSエンジニアにシフトしたのか

なぜiOSエンジニアにシフトしたのか

Web技術での能力向上が頭打ちだった

実はここ2〜3年サーバーサイドでの成長にマンネリ感があった。基本的にはサーバーサイドの役割といえばクライアントにHTMLかJSONを返すぐらいで、複雑なビジネスロジックがない限り非常に簡単な内容になる。また、複雑なビジネスロジックがあったとしてもRuby on Railsでの開発の場合凝った設計にすることも難しかった。ただ、Railsではなく経験があるDDDを元にした複雑なクラス設計をしたいかというと機会があればいいなくらいの温度感である。恐らく、Elixirを経験したことで凝ったクラス設計にしないと大規模なアプリを開発するのは難しいという思い込みが解けたのも理由があるのかもしれない。
フロントエンドの方もSPA関連は出来るようになっていた。もっとフロントエンドをがっつりやることも視野にあったが、大きく環境を変えた方が良いと思った。

サーバーサイドの技術が進化していない

インフラに関してはクラウドの影響もあり変化が大きいが、サーバーサイドの技術は自分がこの業界に入ってからさほど変化はしていない。むしろ、クライアント・クラウドSaaSの影響でサーバーサイドの守備範囲は狭くなっている。
1つ変わったと感じるのがRailsに一時の勢いが無くなり、型付き言語が再評価される流れになったぐらい。ただ、個人的には型付き言語に勢いがあるのではなく相対的にRailsの影響力が下がって色々な選択が出来るようになったと考えている。ここに関してはサーバーサイドがもっとマルチコアを活かす流れになると大きく変化するのではと期待している。

未経験からのサーバーサイドにエンジニアが増加

業界未経験からエンジニアなる場合、Rails or PHPから始めるケースを目にすることが多くなった。例えば、Qiitaで新人が「○○を作りました」という記事があるとすると、Railsだろうなと思って見てみると9割9分くらい案の定Railsだったりする。技術面の評価は置いといて、Railsとそれを含むサーバーサイドエンジニアのコモディティ化がかなり進んでいる印象がある。Railsの場合、ルールベースで覚えてしまえば何とかなってしまうのもその一因だろう。
そう考えるとかつてのWordPressのようにこの領域において近い将来単価の破壊が進むだろうと予測した。

iOSの未来

iOS自体の登場から何年も経っているので、旬の技術というわけではない。ただ、これからも伸びるとは感じている。理由として、Appleがバックにいること。オレがこの業界に入った時は技術の主体はコミュニティだった。ただ、最近はGAFAM主体で技術が伸びている。React・Kubernetes・TypeScriptなどなど本当に沢山あって、純粋にコミュニティ中心で人気が伸びているのはVue.jsぐらいかな?
つまり、毎年定期的に機能が追加される領域はGAFAM中心が多いのでその領域に関わる箇所に移動しようと思った。
他にも機械学習が今はB to B向けが多いが、今後はB to CやC to Cにも適用されていくと思う。そうなった時に位置情報やセンサーのデータ取得としてはまだまだiOSのネイティブの機能との連携に頼るだろうと考えている。

フロントエンドの複雑化

最近のフロントエンドの複雑化は激しい。その中で、iOSデファクトスタンダードフレームワークがないので設計についてはかなり自由になっている。
MVC, MVP, MVVMなどUIアーキテクチャでは様々である。また、ドメイン層をClean Architectureで構築するケースもある。そう考えるとシニアなエンジニアの技術力が今後反映されやすい領域になっていくのでは無いかと感じている。

クロスプラットフォームアプリについて

最近、ネイティブアプリよりもReact NativeやFlutterなどのクロスプラットフォーム開発が活発である。確かに、Webで作っていたものをそのままアプリ化するのであればクロスプラットフォームアプリを作成した方が効率が良いのかもしれない。
ただ、エンジニア視点で見るとネイティブアプリの能力がある上でクロスプラットフォーム開発が出来る方が信頼感は高い。 また、単価という面で見てもクロスプラットフォームアプリを作成する動機はコストを下げたい理由が強いためクロスプラットフォームアプリを作成できるスキルが高くても、あまり単価には反映されないだろうと考えた。
まあ、Reactの経験もあるのでむしろ流行った方が自分的には都合が良い面もあるので、流行ったらその時流に乗ればいいやと考えている。

どうやってiOSエンジニアにシフトしたのか

実は日記を読み返すと2年ぐらい前からこちらの方向にシフトしたかったんだなと思われる。

2017年度の振り返りと2018年度に向けて - cassette
2018年の振り返りと2019年に向けて - cassette

こうやって考えるとなりたい方向性に関して文章にして公開するのは意味があるのかなと改めて思う。

どのようにスキルをつけたのか

業務委託で仕事する上でポテンシャルを評価してもらえることはないので、どうしてもスキルが必要になる。オレの場合、前回の業務委託先で4ヶ月間実務で携わったことの影響が大きい。その中でiOS特有の技術に触れることが出来たので非常に運が良かった。もちろん、携わる前に予習もしていてSwiftについては事前に書けるようになっていた。Rx系の知識については誰よりも詳しかったと思う。ただ、iOS特有のUIKitの知識は実務でしか経験できないことも多いのでその箇所は必死に学んだ。
それともう一つ実は3月に自作アプリを作っていたので、これも武器になった。ソースコードは公開している。
GitHub - nobezawa/TaskBase: Simple Task Management

iOS関連のアーキテクチャの本はこの本が本当に良かった。今年一番何度も読み返している本

peaks.cc

どのようなことをアピールしたのか

AutoLayoutやView周りについては経験の差が出やすいと思う。なので、そこの分野は普通に出来るぐらいを目指した。逆に、設計の知識は活かせたので再度学習をした。例えば、MVVM, Redux, クリーンアーキテクチャ, TDDを改めて勉強した。 別にそこまでする必要も結果的に無かったかもしれないが、これが詳しいですというポイントは作っておいた。また、他にもサーバーサイド・フロントエンド・チームビルディングも出来ますと総合力でアピールした。

どう活動したのか

以下の方法で活動していた。

  • 営業活動
  • エージェント経由

まず、そもそもフリーランスなのに営業活動をしていないことに危機感があった。なので、今から営業活動に関して抵抗感を無くそうと考えたので、基本的には営業活動を中心に探した。 別に営業活動といっても大したことはしていない、自分が気になる企業に関してお問い合わせフォームから問い合わせるだけだ。内容も単純にどういう能力があって、どうやって貢献できるかだけ意識した。合計4社に問い合わせて、全てアポイントまで取れたので感触は良かった。

営業活動とエージェントの比較

営業活動のメリット

  • 自分が興味のある企業に直接交渉出来る
  • エージェントによる手数料が発生しない
  • ライバルがいない

エージェントのメリット

  • 複数の企業に効率良く応募できる
  • 面接管の情報をもらえることがある
  • 事前に契約内容を把握できる
  • 直接交渉しなくてよい
  • ある程度大きな企業がクライアント

どちらもメリデメがあるので、どちらが優れているというわけではない。営業活動のメリットはやはり興味のある企業に直接応募出来る点と手数料が発生しないのでその分の単価が反映しやすいがいい。あと、エージェントを利用すると他のエンジニアと案件が競合する可能性があるが営業活動の場合はその可能性が低い。
エージェントの良いところは条件さえ提出すれば効率良く応募出来るので企業にこだわりがないのなら便利。また、契約書がよく分からなくてもエージェントを通せばそこまで不利な契約内容になることはまずない。えっそんな変な契約あるのと思われるが、残業についての支払いが書かれていない契約書も過去にあった。
また、エージェントを利用するぐらいなので事前に資金力が乏しい企業は除外されるので安心である。

結果的に営業活動した企業で決まった。単価はiOSエンジニアとして再出発するので落とした。 営業活動では4社にアプローチをして4社とも面談まで行ったので、メール営業としてはかなりの成果なんじゃないかと思う。

営業活動の振り返り

いきなりお金のことは言いにくいかもしれないが、単価は初回から伝えた方が良かった。どんなにお互いの印象が良くても想定している金額が2倍も離れると現実的に契約するのが不可能。そもそも交渉自体もそんなに得意でもないし、交渉に時間をさくなら他の企業に活動した方が効率が良いと思う。
また、面談中に少しでも違和感を感じたなら止めといた方が良いと感じた。きっと働きはじめてからその違和感はどんどん大きくなっていく。個人的にはもし面談が2回以上あるなら1回目はスカイプ面談にしてくれると助かるなあと感じた。
あと、エンジニアの技術力が高いかどうかよりも儲かっている企業と取引をした方が単価が高いということを改めて実感した。儲かっているかの指標は以下の通り。

  • 上場企業
  • スタートアップであれば大型の資金調達をした
  • 既に稼いでる事業がある
  • 面談にCEO(出来ればCTO)が参加しない

この項目に全くかすっていない企業の単価は期待しない方が良い。個人的にCEOが面談に参加しないというのは業務委託の単価ぐらいではCEOがわざわざ細かく判断しないという意味であり金払いが良い証拠である。結局書いてみる大企業の特徴になってくる。まあ、せっかく働くのだから単価以外にも総合的に判断した方が良い。

まとめ

長々と書いてきたが結局は興味がある方向に向かっただけのような気がする。Webの方も個人サービスでは開発が続くので全くやらなくなるわけではない(Elixirも書きたいし)

おわり。

要件定義・設計・実装の全部が必要です

結論

  • 上流工程がプログラミングよりも価値がある時代は終わった
  • 要件定義・設計・実装を全て出来るようにならないといけない

アジャイルが主流に

tech.nikkeibp.co.jp

上の記事にもあるようにアジャイル開発が大手SIerでも採用されるようになってきた。これは大きなパラダイムシフトが起きようとしている。なぜならウォータフォールからアジャイルに開発手法が変わったというプロセスだけの問題ではない。エンジニアの能力として価値が変わることを意味する。
実際にアジャイルで開発したことがある人ならば分かるが、ウォータフォールとの大きな違いとしてアジャイルでは要件定義・設計・実装を一人でこなす必要がある。もちろん苦手なところに関しては誰かに手伝ってもらうことは可能だが前提として一人で全て出来ることが望ましい。反対に今までのウォータフォールでは要件定義・設計・実装が企業もしくは別々の担当者であっても分業が可能であった。そうなると顧客に一番近いところである上流工程がお金を一番生みやすくなり、上流工程にいくことが価値があることだと考えられてきた。そのため、プログラミング自体に大した価値はなく軽視されてきた。
しかし、アジャイルになると要件定義・設計・実装の作業は密結合するため分業するよりも各人が一気通貫で開発するほうが効率が良くなる。

ウォーターフォールがリスクに

また別の記事がある

this.kiji.is

要するに外部環境が急激に変化する可能性があるため中止したという内容だ。ビッグバンでシステムを入れ替えすることがリスクになることを示唆する重要な記事である。ただ、今までユーザー企業にもウォーターフォールで開発するメリットが大きかった。それはユーザー企業が解雇規制があるためエンジニアを常時持つことにリスクがあったのだ。そこで、ベンダーがエンジニアを一定期間貸し出すことでそのリスクを回避することが出来た。しかし、上記の記事にもあるように外部環境の変化によってシステムが使い物にならないリスクよりもアジャイルで開発していく方がリスクが低い時代になる。

また、解雇規制も緩和されるのではないかと考えている。
news.tv-asahi.co.jp

今後、賃金は高いが解雇しやすい正社員が増えれば上記の問題も解決する。それは派遣や業務委託と何が違うのというのもあるが。。

上流工程だけでは危険

以上のようなことを考えていくと特定の会社・業界の業務知識に特化するというのはかなりハイリスクな選択となる。また、プログラミングは東南アジアなどの賃金が安いエンジニアと競合するという反論もあるが今いちピンとこない。これは、明らかに要件定義・設計・実装を疎結合に考えている発想だ。実際、その仮説が正しいのであればシリコンバレーで賃金の高いエンジニアを雇うのではなく、インドのエンジニアに外注した方が安いのにそうはなっていない。つまり、同じ英語圏であっても外注してスピードを保ったまま開発するのは難しいことがわかる。

まとめ

正直、アジャイルウォーターフォールのどちらが優れているという議論にあまり興味はない。*1
ただ、どちらの開発手法が主流になってどのように変化するというのは気をつけた方が良い。上流工程がプログラミングよりも大事だと力説する人は大抵おっさんだし、それを信じてしまうとやばくなるよという記事でした。

*1:実際にアジャイルも万能ではなく、週2日と週4日しか働けないメンバーがいた場合はアジャイルでスプリントを回すのが大変になってくる。その場合は、ある一定のタスクを渡してウォーターフォールで進めていく方が互いに楽だったりする。

Kururu - テスト管理ツールをリニューアルした

今年に入ってからずっと開発していたKururuのリニューアルを昨日リリースした。 この記事ではリニューアルした意図と内容を書いていく。

リニューアルのきっかけ

去年の12月の段階で既にリリースはしていたが、自分の中でまだ人に勧められるものではないなと感じていた。以下が勧められる点では無かった点。

  • エクセル・スプレッドシートを超えるメリットを感じない
  • 一言で何が解決するのか答えられない

うん、サービスとしては致命的である。今までサービスを一言で説明できないとダメだと良く聞いていたが見事に自分も地雷を踏んでしまった。その結果、ユーザーに対して提供する価値というのがあいまいになった。そこで、12月から再度企画のやり直しを進めていった。

Kururuの提供する価値

GitHubをベースとしたテスト管理」をコアな機能として再度実装した。そのため、GitHub連携が必須となっている。*1
なので人に説明する時は「GitHubのissue機能と連携してテストが管理ができる」ということになる。もちろんそれにあわせてUIをゼロから実装を直しているのでかなり使いやすくした。

なぜ、GitHubをベースとしたテスト管理にしたのか

実はかつて公開しなかったがKururuは1年以上前にプロトタイプが存在した。公開しなかった理由は方向性が明確にズレたから。
テスト合宿に参加した - cassette

上の記事のテスト合宿に行った時にQAエンジニアと開発エンジニアはテストについての考え方が違うんだなと感じたからだ。
テストにおいてQAエンジニアはバグを見つけることが目的だが、開発エンジニアはバグを解決しリリースすることが目的である。これは似ているようで違う目的である。乱暴な言い方をすれば開発エンジニアは致命的なバグさえ解決し、サービスの価値を提供できればそれで良いのである。

その違いを実感したため今自分が作っているものを公開しても、自分でさえ使わない微妙なサービスになることが予想できた。また、今まで既にあるテスト管理ツールを試しに使ってみたがしっくりこないのも納得ができた。それはQAエンジニア向けに作られているのでこの機能いるのか?ということが気になって使いこなせなかったから。

そうした中でQAエンジニア向けではなくて、開発エンジニア向けのシンプルなテスト管理ツールが欲しかった。

そこで今回考えたのがGitHubをベースとしたテスト管理である。きっかけはZenHubでプロジェクト管理した体験がすごく良かったから。なぜ楽なのかというとコードが中心になってタスク管理がされているので後でタスクを見返してみても修正したコードと紐づけられているので追いやすかった。
この体験からテスト管理にも応用できるのではないかと仮説して、失敗したテストケース・修正したコード・タスクを紐付ければ管理しやすいのではと考えた。
もちろん今まで手動でやれば紐づけられるが手間がかかったのでKururuで解決したかった。

今後の方針

開発では機能追加よりもコア機能の磨き込みを中心にしていく。理由として色々なことができるよりも、コア機能がめちゃくちゃ使いやすい方が初期の段階では分析も含めて重要だからと考えている。

良かったら試しにぜひ使ってみて下さい。フィードバックを募集してます!!!

www.kururu.io

*1:以前はメール認証だった

Kururu - テスト管理ツールをなぜ作ったのか【後編】

前編の記事は以下です。
Kururu - テスト管理ツールをなぜ作ったのか【前編】 - cassette

いきなり結論から書いてしまうと、今までのテストの実施方法がアジャイルに適していないと考えているからだ。

アジャイルでのテストについて

アジャイルについて全てを書こうとすると長くなるので、一部テスト管理と関係ある箇所のみ書いていく。

アジャイルソフトウェア開発宣言の一部引用

包括的なドキュメントよりも動くソフトウェアを

そのまま受け取るとキレイなドキュメントを書くよりも、実際のコードを書いていきましょうということになる。これをテストの観点から見ると重厚なテスト計画を立て実行するよりもTDDを実施してテストコードで担保をしようということになる。

しかし、ここで大きく誤解が生じているのがTDDをちゃんとしているから手動テストは必要がないという主張である。実はTDDで担保できるのはチェッキングのみであるためテスティングは担保出来ないのである。

[チェッキング]
仕様を満たしているか

[テスティング]
仕様以外のテスト。品質を満たしているか
ユーザーにとって使いやすいかどうか

分かりやすくいうと負荷テスト等はテスティングのカテゴリに入る。仕様を満たしているが動作がめちゃくちゃ遅いというのはサービスとして価値を提供していないのである。
私の経験的にもテストコードで全て担保が出来たわけではなく、最終的に手動テストすることでいくつもの致命的なバグを発見出来た経緯が多い。もちろん、E2Eテストでも担保できるがデメリットもあるので、やはり手動での確認は必要と考えている。

テスト管理の必要性

手動でのテストの確認は必要と書いたが、そのままだと作業者の主観による属人性の高いテストとなってしまう。そのため一定の品質とスピードを保つためにテスト管理ツールの導入が必要だと感じている。 よくあるのが多くの組織ではExcelスプレッドシート・ドキュメントツールを駆使してテストケースを網羅的に書いているところが多い。しかし、以上のツールは大きく2つの問題点がある

1. バグのチケット管理が煩雑

テストケースとバグ報告が増えるにしたがって管理が煩雑になる。例えば、だれがどのバグの修正をしていて・どのような状態であるのかが分かりづらい。そのため、結局誰か一人がテスト管理する必要が生じてしまう。大手企業であれば問題ないかもしれないが人数の少ないスタートアップであれば貴重な戦力を消費してしまう。

2. 再利用性がうすい

今までExcelなどのツールでテストケースを作ってきたが再利用したことがない。理由は色々あるが再利用するためのテストケースの抽出に手間がかかる。そして抽出したテストケースをまた管理する手間が生じる。
結果、再利用しないため時間が経つと再度テストケースの作成すること多くあった。

以上のツールはバグを網羅的に見つけるのが得意であっても、チケットの管理・ドキュメントとしての機能が薄い。

テストでスピード感が失われる

以上のようにテスト管理をしっかり行わないと以下のような状況に陥る。

  • バグを混入したままリリースされ、障害が発生する
  • テスト管理・コミュニケーションのコストが増大する
  • 毎回テストケースを作るコストが発生する
  • テストケースのクオリティに差が出てしまう
  • etc

つまり、何が言いたいかと言うとテストの失敗でスピード感が失われ、結果的に素早いリリースが達成できなくなることである。スクラムやCIによる自動化などを実施していてもテストが遅すぎると、まさに底が空いたバケツである。折角自動化が進んでいるのにリリーススピードは一向に速くならないジレンマに陥る。
反対にテストの分野というのは実はかなり経験則が活かせる箇所であり、上手く運用すればプロジェクトの期間を1週間ぐらい圧縮できるのである。*1

テストケースの再利用性がない

個人としてはこの点がかなり重要だと考えている。自分は今まで多くのサービスの開発に携わってきたが技術的に大変だったという機会はむしろ少なく、ドキュメントがほぼ存在せず仕様の把握が難しかったケースが多い。そもそも一度もこのサービスはしっかりとドキュメントが揃っていたという経験がない。

エンジニアが社内・社外問わず非常に流動的である現在において仕様の把握はものすごいコストがかかっている。どんなに優秀なエンジニアが入社しても仕様の把握が覚束なければ価値を提供することは難しいのだ。

その中でテストケースを再利用出来るのであれば、完璧ではないにしろ仕様書として利用できるのである。かつて知人のエンジニアは「仕様書が無くても、テストがきちんとあれば仕様を把握することが出来る」と言っていたがその通りだと思う。

Kururu - テスト管理ツールを何故作ったのか

以上のように仕事経験の中で本当に必要だと感じてテスト管理ツールを作っている。そして、テスト管理ツールを有効に使うことでもっと開発を楽にしたいのが動機だ。

が、ここまできてやっぱり思ったのはそもそも自分はこの業界にサービスを作りにわざわざ入ってきたのに真剣に自分のためのサービス作りに取り組んだことがなかったなと。
30歳になってどんどん自分ための時間が少なくなる中でこのままじゃ後悔しそうだなと考えたのも動機です。 今は他の仕事を断って全てサービス作りに費やしているので、またリニューアルしたらブログ書きます。

*1:QAエンジニアという専門のエンジニアがいるぐらいなので、大きいプロジェクトほど圧縮は大きい

知っていることと経験してみることは違う

今回は技術とか何も関係のない普通の記事です。

最近改めて知っていることと、経験してみることは違うと実感する。
例えば、最近Twitterで正社員とフリーランスどっちがいいかという議論が活発に行われていた。実際はそれぞれメリデメあるよねというのが真実だがTwitterという文字数が少ない空間では「あるべき」だという強い意見が目立ってしまうのではたから見ると何とも言えない気分になった。

そもそも自分の場合は、正社員とフリーランスについてメリデメで決めるのがそもそも微妙な問題であると考えている。例えば、フリーランスのメリットが2つ勝っていたらそれを選ぶかというとそんなので選ぶ人はいないんじゃないかと。つまり生き方の問題であるのにメリデメで比較してもというのが正直な感想。

じゃあ何故こういう論争が起きたのかと言うと、知っていることだけで議論しているからと考えていて。実際に自分はフリーランスになってみて考え方は変わった。具体的に言うと今までは正社員の場合、月給ベースで多い少ないみたいな考え方であったが、フリーランスになってからは長期的に見てどのくらい投資したらどのくらいのリターンが返ってくるんだろうという考え方になった。こういうのは知識ではなく経験で知ることなんだと知った。

つまりフリーランスになってみないと分からなかったし、本に書いてあっても理解は出来なかっただろうと思う。 正社員・フリーランスみたいな大きなことじゃなくても、大体のことはとりあえずやってみてなんか違うと思ったら辞めればいい。なんか違うと思ったのなら向いていない可能性が高いし向いていないことに時間を使うのはもったいない。選択することに時間をかけすぎていて止まってしまう方がもったいないなと感じる。

もちろん、経験することで戻れなくなるということはある。
そういう時は小さく判断をする。例えば自分もよくフリーランスなったねと言われるが、大きな決断をしていない。小さな判断の積み重ねをしていき、リスクを出来るだけ最小化してきた。

自分はサービスを作っているが、上手くいくかどうかは分からない。。
上手くいくかどうかは分からないけど、上手くいくかどうか分からないことに挑戦している自分が好きだからやってる。

Kururu - テスト管理ツールをなぜ作ったのか【前編】

自分が実はテスト管理ツールを作っているというと、多くの人の反応は「そうなんだふーん」というリアクションが多い。もちろん、個人開発をしている人の多くがこういう反応をされる。
正直こういう反応は慣れていてとくに問題があるわけではないが、エンジニアであっても9割方の人はそもそもテスト管理ツール自体を知らないケースが多い。例えば、OSSで言うとTestLinkが有名ですよと説明してもあまりピンと来てない人が多い。*1テスト管理ツールを知っているのはSIer出身の方が多くWeb系の知らないこと人が多い印象を持っている。なので今回は何故自分がテスト管理ツールを作ろうとした動機を書いていく。長くなってしまったので前編となる。

サブスクリプションモデルの浸透

いきなりテスト管理ツールの重要性を書いてもピンとこないので背景にあるビジネス的な面から説明していく。

まず、サブスクリプションモデルの浸透*2について。サブスクリプションモデルの代表的な業界でSaaS業界を挙げると、国内では15%・海外では20%の成長率となっている。またtoCの分野でも最近ZOZOが有料会員を打ち出したりしてSaaSの枠にとらわれない代表的なモデルになっている。エンジニア・デザイナーでわかりやすい例でいうとAdobeも何年か前に買い切りからサブスクリプションモデルに移行している。今後も非常に市場規模が大きいライドシェア市場においてもサブスクリプションモデルが採用されるため、より今後もサブスクリプションモデルの浸透は増していく。

サブスクリプションモデルのビジネスインパクトについてはこの記事の趣旨と違うので省くが、開発面においてもサブスクリプションモデルの影響は受ける形となったと自分は考えている。

サブスクリプションモデルが開発にどういう影響を与えたかと言うと、アジャイルとの相性が非常に良い。というよりもサブスクリプションモデルを継続するのにはアジャイルでないと継続するのは不可能でさえ思う。
サブスクリプションモデルでもっとも重要なのは継続的な改善である。売り切りではないため継続的にユーザーの行動・要望を分析しサービスの改善に活かないとユーザーは別のサービスに乗り換えや解約に繋がってしまう。この継続的な改善がないとサブスクリプションモデルは、それただの月額制ですよね?となってしまうのでここの違いはきっちり認識する必要がある。
そして継続的な改善を実施するにはウォーターフォールでは対応出来ないのだ。顧客の要望を迅速に取り入れるには要件をしっかり定義している時間がない。70%ぐらいの確度でリリースしていく方がメリットが大きい。*3

後編の記事ではアジャイルテスト管理ツールの関係性について解説していく。

Kururu - テスト管理ツールをなぜ作ったのか【後編】 - cassette

*1:これは別に悪いことでは全然ない

*2:https://boxil.jp/mag/a4946/

*3:余談になるが、エンジニア同士でウォーターフォールアジャイルによるプロジェクト管理の論争が巻き起こるがこういうビジネス観点が抜けているケースが多い。また、新規開発・大規模なシステム更新というプロジェクトではウォーターフォールで実施した方が経験的に失敗しにくかった。

TypeScriptとevent.persist()

備忘録

ReactとTypescriptの組み合わせで、event.persist()を型付けをしたい場合。
以下のように書けばコンパイルが通った。

const handleChange = (event: React.SyntheticEvent<EventTarget>) => {
    event.persist();
    ~~~
};

取り急ぎ細かい理由はわからんが。。 理由はこれかな?

簡単に説明すると、eventオブジェクトはReactによってSyntheticEventオブジェクトとしてラップされていて、パフォーマンスのために使いまわしてますよ。

参照先:

stackoverflow.com