2019年の振り返りと2020年に向けて

毎年振り返り記事を書いているが今年も書こうと思う。

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

今年について

Kururuについて

残念ながらサービスで収益を上げるという目標は達成できていない。あれだけ、リソースを投入したが開発を行っていないからだ。Kururuの開発をしていない理由は色々とあるのだが、一言で言えば一人で運営するのは難しいと考えた。KururuはSaaSモデルとしての運営を将来的に考えていたが、SaaSというのはとにかく収益を上げるまでの時間がかかりまたユーザーへのサポートが重要になってくる。どこかの段階で自分一人では難しそうだと感じてはいたが、それよりも早く現実の方が先に来てしまった。もちろん、そんなことは開発を始める前から理解はしていたが完成後の燃え尽きと他の仕事による時間確保の難しさから時間を投入出来なくなった。
ごちゃごちゃ言っているが、情熱を保てなくなったそのことに尽きる。

iOSについて

今年からiOS開発をメインに転換した。去年までは自分で仮に一人でアプリを作るということに対して不安感があったが今であれば一人でも作りきる実力はついた。なぜ、転向したのかの詳しい記事の内容は以前書いた。 サーバサイドエンジニアからiOSエンジニアへ転向した - cassette

実は2年前にもやりたいという記事を書いていた。

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

iOSというかモバイルアプリ全般に言えるが、案件はWebに比べて多くはないが開発者の流入が増えないので需要がそこそこありWebから転向した。
とはいえ技術的に挑戦したといえる内容はiOS関連ぐらいでもあり、独立した2年間に比べると落ち着いた年になった。

来年について

フリーランスになって次で4年目になり、正社員で働いていた期間がついに同じになる。そのため、フリーランスで得る経験は一通りすんだ。そのため、何もしないとただの例年通りの焼き直しになりそうなので引き続き挑戦はしたい。
あとは別の視点としてもう少し交友関係を増やそうかと思っていて、それこそ別に開発者にこだわらないで幅広く接して自分の考えとは異なる人に会ってみたい。

お金について

2019年は投資と位置づけていたので収入自体は落ち込んだ。そのため2020年は2019年に比べて換金する年にしたい。請負い・常駐の仕事も適時調整して進めていこうと考えている。
もう少し経てばWEBかiOSアプリの仕事を募集します。理想を言うのであれば週3を常駐にして、それ以外を請負いみたいな比率が理想。ただ、来年の目標の中ではここが一番ウエイトが高い。

個人開発について

個人ではiOSアプリを現在開発している。内容は「予算管理」が出来るアプリで夫婦や友人でも特定の予算管理を共有出来ることを目的にしています。これはまた別途ブログに書こうと思っている。 進捗状況的には来年の前半にはリリース出来そうな見込み。

勉強について

個人では細々と英語の勉強は続けている。本当はTOEICを○点目指すみたいな目標を立ててやりたいが、優先順位が高くなく中々がっつり取り組めてない。
今年の前半に仕事をしていなくて分かったことだが、まったく新しい分野に乗り出す or 勉強するのであれば思い切って仕事を無くして取り組んだ方が効率が良いことに気づいた。例えば、機械学習分野について詳しくなりたいのであれば、日々の生活の細切れの時間に行うのではなくがっつり2ヶ月間集中した方がかなり自分の場合は進む。とはいえ、空白期間があると収入的には痛手なのでそれを支える収入は必要かなと思う難しい。。

脱線したが個人的な勉強で言うのであれば機械学習の入門ぐらいはやっておいて、スタートラインに立てればと思っている。ただ、英語も引き続き勉強したいしここは悩み中。

おわり。

Mac miniを購入した

ずっと6年前から購入したMacbook Airでがんばってきたが、さすがに家で開発するのがきつくなってきた。特に問題だったのは容量で約120GBしかなかったので自由に使える容量がかなり少なかった。ここ何年も常に容量を気にしてきたが、OSのバージョンアップやXcodeのバージョンアップが毎回きつかった。
最終的にとどめを刺しさのは自分がiOSアプリを開発するようになって自分のマシンでは恐ろしくコンパイル時間がかかってしまうことだった。そのため、最近の勉強についてはコンピュータサイエンスや英語の勉強に時間を取っていた。

なんでMac miniにしたのか

正直、Mac miniにする気持ちは全然なかった。持ち運べるという点を考えると圧倒的にMac bookの方に気持ちは傾いていた。ただ以下の点が今回のMac bookのデメリットだ。

1. 価格が高すぎる
2. 完全に理想とするモデルではなかった

価格が高すぎる

iOSを開発するようになってビルド時間を気にするようになった。そうするとメモリ・CPUをWEB開発の時よりもスペックが高いのが欲しくなってきた。そうやって理想のカスタマイズをして価格を見積もると50万円近くなった。。
50万円。。Macbook Airの時は13万円で6年間持ったのだが。。
Apple信者でもなくiOSの開発さえしなければWindowsを検討してたぐらいなのでこの額にはさすがに悩んだ。

完全に理想とするモデルではなかった

理想とするスペックを実現しようとすると15インチのMacbook proしか選択がなかった。この時点で13インチを使用してきた自分には抵抗があった。13インチでさえ長時間の持ち運びには疲れるのに15インチはなあという気持ちだった。
また16インチや新しいキーボードのタイプをそろそろ発売するという噂を信じて待っていたが、結局いつまで経ってもスケージュールがわからず買うタイミングを逃し続けた。

Mac miniを選んだわけ

色々と調査してみたが、ビルドコスパ的にはMac miniが一番良かった。また、モニターや周辺機器もすでに持っているため純粋にMac miniさえ買えば良かったのも都合が良かった。
ビルド時間に直結するCPUのコアでもMacbook proでは8コアでMac miniでは6コアだがそこまで大きなアプリをビルドすることも自宅ではなさそうなので問題はなかった。ちなみに消費電力の関係からクロックはMac miniの方が性能が良かったりする。

最終的にMac miniを選んだ

結局、持ち運びできるかどうかが重要だったのだが、外でがっつり開発する予定もなかった。引き続きMacbook Airも開発面では物足りないが調べ物や文章を書くことは出来る。 開発面でもスクリプト言語であればそこまで開発に支障はない。(容量問題は以前としてあるが)

最終的に決断したのはどうしてもMacbookが必要になった時に買えば良いかなと考えた。開発用のノートパソコンがないと仕事が成り立たない状況になれば、恐らく即決して買うだろう。
今回ここまで悩んだのはMacbookにそこまで魅力を感じなかったのだろうな。

iOSアプリクラス設計の個人的見解

iOSアプリの仕事をしているとよくクラス設計の話になりやすい。基本的にモバイルアプリは設計が自由なためアプリごとにアーキテクチャが異なる。
そのためMVC, MVP, MVVMなどのUIアーキテクチャやClean Architectureなどのシステムアーキテクチャなどの選択肢が多い。選択肢が多いというのは曲者である意味正解がないため、メンバーで共通の認識を取ることが難しかったりする。

Clean Architectureを取り入れるべきか？

Clean Architectureというか、ドメイン駆動設計を取り入れるかどうかの問題だと思う。それが、Clean Architecture・ヘキサゴナル・オニオンなのかはそこまで重要じゃない。

それで、個人的な見解だがモバイルアプリにこれらのシステムアーキテクチャを入れるのオーバーエンジニアリングかなと考えている。モバイルアプリが担当するのはViewに関することが多いので、ドメイン駆動設計をそのまま取り入れるとドメイン貧血症になりやすい。そのため、Viewに関連することをドメインに引き上げようとするが、何のロジックを引き上げるのかということも問題になってくる。
そこでメンバーと認識を合わせようとするが結構な手間も同時にかかる。自分のなかでこれらのアーキテクチャを入れた方がいいと思うのは、Lineやメルカリのようなアプリで本来メーセージアプリだったのがゲームが入ったり、メルペイが入ったり複数の目的になったアプリはいいのであって、99%以上のアプリはほとんど不要だと考えている。

テストである程度担保できればいいのではないか

実装していて大変だなと感じるのが特定のView, ViewControllerにロジックががっつり書いてあってロジックの再利用が難しいパターン。また、これらのロジックは基本的にViewと密結合しているためテストも書きにくくなっている。なのでこれを分離してあげれば良い。そのため、Clean Architectureという大層なものを導入しなくてもモデルに分離してあげれば良い。

ただ、気をつけていないとView, ViewControllerにロジック書かれてしまうので、Rx系を導入してView, ViewControllerは値をバインドしているだけという状態でいいと考えている。

そして、モバイルアプリを作るということはtoCよりのアプリであるケースがほとんどなので大体は爆死する可能性が高い。そのため、やっぱりそこまで作り込む必要はないというのが感想。

まとめ

この記事を書いたきっかけは、モバイルエンジニアは設計論が多くて新規参入を除外しているという意見を目にしたからだ。この意見は半分当たって、半分当たってないというのが自分の意見だ。設計をやりすぎな面もあるが、反対にどこまで細かく設計するのかの境界を見定めるのも結局設計の知識がないと通用しないなと感じる。

とにかく言いたいのはまだ売上がさほど上がっていない状態なら設計云々の話は不要だし、売上が上がっていないのに設計がキツい場合はビジネスそのものがイケていない or 画面設計がミスっているのどちらか。

2019年度 iOSアプリの勉強方法

前回のサーバサイドエンジニアからiOSエンジニアへ転向したの記事に書いたとおり現在はiOSの開発を主にしている。その中でどのように勉強したのかを書いていく。

iOSエンジニアの状況について

勉強方法の前にiOSエンジニアがどのような状況なのかを説明したい。
まず、求人数を比べてみるとサーバーサイドやフロントエンド(JavaScriptを扱う)に比べて少ない。理由として、iOSアプリは少数精鋭で開発されることが多いので有名なアプリだとしても2~3人の規模で開発されていることもザラにある。そのため、未経験またはジュニアレベルのエンジニアをOJTを通して教育するというのが難しい状況だ。また、フロントエンド特有のイベント駆動や非同期処理の概念やさらにマルチスレッド処理も学ばないといけないため初学者には厳しい分野とも言える。
あと、他のエンジニアに比べるとあまり流動化はしていない傾向がある。理由として、プラットフォームに依存した言語を採用しているため、サーバーサイドのようにRubyやGoなどの選択肢がそもそもない。そのため、別の現場に行ったとしてもさほど大きく技術において変化が少ないのも理由だ(アーキテクチャの違いはあるがそれぐらい)。

ちなみに、Androidに比べるとエンジニアのiPhoneとMac所持率が高いためiOSの方がエンジニアの絶対数は多い。

学習について

今、iOSを勉強する絶好のタイミングか？と聞かれると微妙にはなるかもしれない。実はiOS13からSwiftUIというまったく新しいアーキテクチャが生まれるためだ。そのため、iOS13以降のベストプラクティスが全然固まっていない(恐らくApple自身も分かってない)。
ただ、既存アプリの対象バージョンをiOS13以上に引き上げるのも現実的ではないため、AutoLayoutなどの既存のやり方はやはりマスターした方が良いだろう。

勉強の流れとしては以下の順序で勉強するのが良いだろうと考えている

1. Swiftについて学ぶ
2. XcodeとAutoLayoutについて学ぶ
3. UIKitとHuman Interface Guidelinesについて学ぶ
4. UIアーキテクチャについて学ぶ

ただ、自分自身がそんなにブログを沢山書ける人ではないため、「Swiftについて学ぶ」だけ書いていく。

Swiftについて学ぶ

まず、個人的にSwiftという言語についての印象はモダンな言語でクセが無い優秀な言語というイメージ。ただ、言語仕様としては複雑に分類されるので初学者向きの言語とは言えない。習得できれば色々な概念が学べるかなりお得な言語ではあるが、裏を返せば沢山の概念を学ぶ必要がある。

自分の場合は以下の本を読んだら大体理解できた。

[改訂新版]Swift実践入門 ── 直感的な文法と安全性を兼ね備えた言語 (WEB+DB PRESS plus)

上の本が難しい場合は以下の本が良いらしい。自分は読んでことはないので自信はないが。

詳解 Swift 第4版

この段階で気をつけたいのはiOSの知識とごっちゃになって勉強してしまわないようにする。そのため純粋にSwiftの知識だけで構築できるアプリを作ることが望ましい。個人的にはCLIアプリが良いと思う。例えば、無料のAPIから情報取得してきて、ターミナル上に標準出力するというくらいの単純なアプリでちょうどいい。 下では個人的に重要な箇所をいくつかピックアップした。

classとstructの使い分け

最初に勉強した時、個人的に使い分けに困った。classは参照型でstructは値型ということだけで理解できる人は飛ばしていい。
基本的にはstructで実装できないかを考えて、難しいならclassで考えるざっくりとした方針でいいと思う。分かりやすく言うと、structは不変オブジェクトで使うのが良い。structには自身の値を書き換えできるmutatingキーワードがあるが、あれはよっぽどのことがない限り使う必要はない。使う場合は設計がイケていない可能性が高い。
反対にclassは複数のオブジェクトで共有して使いたい場合やUIViewControllerなどの特定の場面で使うと良いと思う。classの何がめんどくさいのかというと、メモリリークの可能性を引き起こすからだ。そのため、参照カウントの管理もしないといけないためシンプルではない。個人的にclassを使いたい場合はなぜ使うのかコメントに書くレベルで使うのが良いと思う。

enumを使いこなす

Swiftで強力な機能といえば、Optionalと双璧をなすのがこのenumの機能だ。enumはパターン網羅をしたい処理の時にちゃんと型付け処理できるのが非常に使いやすい。このenumは使いこなせておける必要はある。

マルチスレッド

この段階で書くかどうか迷ったが、実際の現場で起こるバグの原因にもなりやすく、かつ解消が難しいので書いておく。単純にSwiftのマルチスレッドが難しいというよりも、マルチスレッド自体が難しいため別にSwiftの問題というわけではない。 ここに関しては現役のエンジニアでさえ、得意ではない人もいる。 本としては古いが以下の本が役にたつ。

Java並行処理プログラミング ―その「基盤」と「最新API」を究める―

既に絶版みたいだが、この本ではいかにマルチスレッドが難しいのかと、どのように設計していくのが正しのかの指針があるので読む価値はあると思う。 個人的にはマルチスレッドを自分で書くよりもRxSwiftなどのライブラリ経由で扱う方が好きだが、そこは結局現場次第になってしまうのでSwiftでのマルチスレッドは勉強しておくと良い。
SwiftでマルチスレッドをやるといかにElixirで並行処理をするのが楽だったのか思い知らされる。

まとめ

ここまで書いてきてなんだが、アプリエンジニアになるには結構難しいとは思う。技術的というよりも市場的に難しいという意味だ。Webのフロントエンドなどはサーバーサイドと兼務してやる機会があるので移ることも可能だが、よっぽどの小さい企業でもない限りアプリエンジニアと兼務することは稀だ。 王道で言うなら、学生時代にアプリを作っていてそのまま就職するのが一番良いがそうじゃないなら一時的な給与が下がるのを受け止める必要がある。

あと、学習環境もWebに比べてそこまで整っていない。理由は毎年OSのバージョンが上がるため、本の内容が陳腐化しやすい。そのため、参考になる記事もそのまま使えることが少なくて現在の最新のAPIを調べる必要がある。

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

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

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

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

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

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

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

インフラに関してはクラウドの影響もあり変化が大きいが、サーバーサイドの技術は自分がこの業界に入ってからさほど変化はしていない。むしろ、クライアント・クラウド・SaaSの影響でサーバーサイドの守備範囲は狭くなっている。
１つ変わったと感じるのが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:以前はメール認証だった