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

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

2018年についての振り返り

Kururuのリリース

Kururu - テスト管理ツール

非常に時間がかかった。。結局、前年作っていたのはやめて再度企画も含めてやり直しをした。再度実装したことで遅くなっと指摘されることもあったが初回リリースまでは自分のエゴ(納得感)で進めることを優先した。結果的にはモチベーションが上がったので良かったと思う。詳しくは個人開発を支えるメンタルという記事でも書いている。 勿論、まだまだ足りていない機能は多く満足はしていないが、リリースによりマイルストーンを刻むことが出来た。
今後は大型機能の追加をいくつか予定している。

技術的な観点

2017年に引き続き技術力は向上した。主に向上したところは以下の点。

クライアントサイドは2017年の末から本格的に取り組み始めて、2018年においてはついにバックエンドよりもフロントエンドの方が書いたコード量は多かったと思う。これには理由があって、iOSの開発を業務委託の仕事で携われたことが一つ挙げられる。今年の目標の一つにモバイルアプリの開発に携わるというのがあったのだが無事目標は達成できた。特にRxSwiftなどの関数型に影響を受けたライブラリをがっつり経験出来たのは十分な成果である。もしiOS開発が今後発生したとしてもアレルギーがなく開発が出来る。
もう1点はKururuの開発でSPA(React)を使用して、むしろお腹いっぱいというほど書いたことである。もともと、業務委託先でも書いていたのだがKururuの個人開発でも沢山書いてたので十分すぎるぐらいである。 前年度にはVue.jsも書いていた。

関数型言語への取り組みも2017年の末からJavaScriptの勉強を通して大きく理解が進み、今年度はKururuのバックエンドでElixirを使用してみた。Elixirについては別記事でも書いたが非常に書きやすく、生産力も含めて今一番好きな言語である。恐らく、特に理由がない限りは個人開発においてはElixirを中心に書いていくと思う。また、完全な個人的な趣味でHaskellを通してモナドを学び、Rx系のObservableの理解の役に立った。

他にもCIについても知見が貯まったが代表的なのは上記の2つ。もともと、正社員の時は純粋なバックエンドエンジニアだったのに大分スキルセットが変わった。ただ、改めて正社員の時はレガシーな環境でモダンな技術に触れることは少なかったがドメイン駆動・クラス設計・プロジェクト管理などの基礎的な技術に力を入れてよかったと感じる。スキルのキャッチアップ、及び実務の仕事では基礎技術をやっていたことが大きく為になった。
お金に繋がりやすい技術もやるが、すぐにはお金にならない基礎的な技術もやっていくことに意義を体験から学んだ1年間だった。

2019年について

ビジネスで成果を出す

今年度はついにKururuをリリースすることが出来た。これを運用・改良していき売上を上げるところまで持っていきたい。勿論、かなり難しい挑戦になるが業務委託以外の売上を出すことは大きな経験となるはず。
まだ目玉となる機能の実装が終わっておらず、売上を立てられる機能の実装も終わっていないので、直近では大型機能追加作業がメインになる。ここについては業務委託の仕事をお休みして集中的に取り組んでいくことにした。直ぐに売上を目指すという方向性もあったが、これだけ小さなサービスの場合は圧倒的なクオリティが重要だと今の段階では感じている。

マーケティング活動を直ぐに力を入れない理由として以下の2点から判断した。

  • プロダクト・マーケット・フィットを確認しきれていない
  • 元々専門ではないマーケティングでは費用対効果が薄い

プロダクト・マーケット・フィットをまだ確認出来ていない状態でグロース施策を打つことは逆に費用対効果が悪いと判断した。売上がしっかり立つまではプロダクトのクオリティを上げることに力を注ぎたい。また、元々専門ではないマーケティングは費用対効果も薄いと感じた。


勿論、Kururuに力を注ぐことにリスクもあるがコツコツ準備はしてきたので当面生活で困ることはない。ただ、来年の景気についてどうも不景気になりそうなので柔軟に生活面の資金については対応はしていく。

技術面

最新の技術面のキャッチアップはフリーランスの2年間を通じて随分挽回できた。よって2019年はビジネス面を優先はさせる。
その上であえて技術な取り組みをするのであれば、去年土台を築いたiOSの開発を今年も継続出来たらと考えている。過去にAndroidの開発をしたこともあったが、すっかり忘れてしまい勿体無かったので折角のiOSの開発経験は残したい。本当は最初はビックデータ関連の技術をキャッチアップしていく予定を考えていたが、フロントエンドの開発と両立することと、独学で勉強することは難しいので今年は保留する。

ただ、長期的に考えるとビックデータ関連の技術はインターネットと同じくらい世の中にインパクトを与えるので隙間時間で学習はする。

まとめ

ビジネス面を頑張るというのは長期的な投資という意味もあるが、改めて全力で走るという意味がある。来月で30歳という節目において自分の経験したことの無い未知の領域に対して挑戦したいというのが本音である。今までエンジニアという専門性で守られていた部分があるので、来年は少しエンジニアの武器を手放して自分の力を試していきたい。

終わり。

サーバサイドの人間がiPhoneアプリ開発に入門した

今回は普段Web側で開発している私がiPhoneアプリ開発を経験した内容を書いていきたいと思います。

iPhoneについて知る

元々、AndroidユーザーということもあってiPhone自体の固有の動きが知識が不足してました。細かいことを言うとここをタップするとこういう動きになるよねという知見が少ないので困ったりしました。なので出来るだけ開発する前からiPhoneを使った方がギャップが少なくなります。

Swiftについて

Swift自体の言語の感想としてはクセが少なく素直な良い言語だなという印象を受けました。言語仕様としてここが書きづらいというのも少なかったです。
たぶんほとんど人が鬼門になるのはOptionalの使い方です。慣れといえば慣れで解決できるのですが、ScalaJavaにもOptionalは導入されているので自分の場合概念自体はすぐに理解できました。意外と苦戦したのが?の使い方で色々と使い方があったのでそこは混乱しました。
ただ、Optionalは頻繁に出現するのでここをきっちり理解しないと中々開発効率は上がらないと思います。また、SwiftにはHaskellのdo記法やScalaのfor式に相当する糖衣構文がないので入れ子になったOptionalをunwrapするのは少々手間取ります。 またバージョンアップが激しい言語なので、Swiftのバージョンアップをするとこのライブラリが動かないというのはよくありました。

デザインについて

一番苦戦したのがデザインです。Auto layoutの仕組みは今まで経験してこなかったので難しかったです。特に凝ったデザインだと複雑な組み方をして対応していることがありました。ここが一番経験者と入門者でのレベルがつきやすい箇所だと思います。

設計について

iPhoneアプリの設計についてMVVMやClean Architectureなど様々な設計方法があります。その中で私はReactorkitを使った開発をしました。RxSwiftを使ったFluxスタイルの設計になります。個人的にReduxを使ったことがあったので、このアーキテクチャの考え方はすぐに理解出来ました。RxSwiftも以前RxJsを使ったことがあったので大きく躓くことはなかったです。ただ、Subjectの使い方を今いち理解していなかったのでそこは理解出来るようになりました。

まとめ

全体的に既にフロントエンドを担当したことがある人ならアプリも理解しやすいです。
私の場合さらにRx系の経験もあったので躓きが少なかったです。さらに今まで直感的に理解していたWebアプリよりもネイティブアプリの方が時間がかかる理由も理解できました。WebでいうとフルスタックのSPAを作っている状態であり、考えることが明らかにシンプルなWebアプリよりも多いです。もし今後ネイティブアプリを作るのであれば、作る必要性を吟味してから開発はした方が良いです。