C-FRONT

エモくありたい

Spring Bootのキャッチアップにバージョンアップで理解を深めた話

最近Androidアプリ開発からサーバサイドの開発に移り、移って早々SpringBootのバージョンアップをする案件にアサインしてもらった。SpringBootはじめてです!の段階でプロジェクトのSpringのバージョン担当することもなかなかない話かと思うので、Spring Bootのキャッチアップという点からバージョンアップで対応する時に学んだことをここにまとめる。

前提

  • 業務で経験していたのはAndroid開発のみ
  • そういえば今まで業務でライブラリのバージョンアップを経験したことはなかった

要約

  • プロジェクトのSpringBootバージョンを1.2系から1.5系まであげた
  • SpringBoot始めたばかりで通常のエンハンス案件をやっているだけでは知らなかったと思える経験・感覚をつかめたので、学習の導入になった

バージョンアップを経験してよかったこと

SpringBootの導入には「はじめてのSpring Boot」でキャッチアップしていたが、そこでは知れなかったこと&もしこのままエンハンスをやっていたら知るのが遅くなってたであろうと思うことをいくつか。

ライブラリの依存関係について

バージョンアップ作業中に一番対応したのがライブラリの依存バージョンの解決だった。 //TODO:例えば AライブラリとBライブラリが中でCライブラリに依存してるが、AとBはバージョンによって依存するCのバージョンが違う、みたいなことが起こる。バージョンの違うライブラリに依存していると、順番はわからないがどちらかの依存versionしか参照できず、NoSuchMethodErrorで怒られる。この仕組みについて最初わかってないので困惑した。 mvn dependency:treeやpom.xmlDependency Hierarchyをみながら各ライブラリの依存ライブラリの整合性を修正していく作業が多かったかと思う。 ライブラリの依存関係を理解する過程で不要なdependencyなどを見つけたり、pom.xmlの整理の仕方も多少は身についたかと思う。

Android開発の時はライブラリのバージョンアップの経験がなくてライブラリ間の依存関係について意識することがなかったので勉強になった。

エラーログに向かう感覚の醸成

SpringBootを初めて触れた時、自分が書いたClassとは全く違うClassからエラーが吐き出されることにとても困惑した。今までは、基本的には自分の書いたコードからExceptionが吐かれることが多かったので、原因もわかりやすかった。 バージョンアップの対応にはたくさんのこうしたエラーに対応しなくてはいけないので、数をこなして慣れることができた。最初に感じていたゲッという気持ちはバージョンアップ経験後ではなくなったので非常によかったと思う。

参考にできるネット上のページの感覚

上にも関連することだが、たくさんエラーが出る中でわからないことを調べる時に参考になるページが集中的にインプットされる。最初はどうぐぐったらヒットするのか模索するのでとても効率が悪かったと思うので。 - Maven Repositoryの各ライブラリのDependency部分 - 公式ブログ - Release Note - Githubのissue - Javadoc - その他QiitaとかStackOverflowなどは普通に。。。 こう書いてみると当たり前なリソースな気がするが、これを経験する前はこれができなかったのである。

Springの各種プロジェクト間の関係性について

恥ずかしながら色々あるSpring系のFrameworkについて全く認識しないまま開発に入ってしまった。例えば以下などがバージョンアップを通して気づき経験した。 - starter系はversionが一緒になるのでそれを踏まえて依存関係を解決しなくてはいけない。 - Bootが依存しているSpring Frameworkのバージョンも変わるので、Spring Frameworkの変更点も確認しなくてはいけない。 - パッケージの変更などで新しくspring-securityをimportしなくてはいけなくなったり。 エンハンスだけしていたらあまり意識してなかったと思うので、いいきっかけにだった。まだ理解してないこともあるのだけど少しだけ。

バージョンアップするにあたり個別に対応したところ

どこで動かなくなったかがわからなくなるのが不安だったので、ひとつずつバージョンをあげて「ここまでは動く」を確認しながら進めた。 意外とボリュームが多かったので別記事にまとめる。うん。まとめる。

まとめ

キャッチアップ材料として「バージョンアップしてみる」選択肢としても考えてみるのも良いかもしれないと思った話。状況と必要性もあるが。 エラーのデバッグを集中的に数こなす意味ではSpring Bootの仕組みに慣れるのでよかった。エラー出ても少しは怖くない! プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。

JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3

JJUG CCC 2017 Springで登壇してきました。

JJUGについては以下。 www.java-users.jp

発表内容については以下を参照ください。 speakerdeck.com

ここからは忘れないうちに感想文。 外部イベントで2回目の発表でした。(1回目はこちら。)

chiiia12.hatenablog.jp

20分の発表は話の構成のしかたがすごく難しいなと思った。今回はストーリー作りもそうだし、スライドでの伝え方に結構苦戦して、結局最終的なストーリーに行き着くまでに何回か潰した気がする。20分のボリューム感、どこまで話広げるべきかがわからなくて、結局最後の練習まで17分で終わってしまうボリュームだった(本番はなぜかぴったり20分になった)。

本番は小さい部屋でしたが、満員で部屋に入れなくなるほど人が来てくれたり、発表後に質問に来てくれた方もいた。発表してよかった。。。 ちょっと今後気をつけようとおもったのは、新しいmacとアダプター経由でのプロジェクターへの接続が悪くてヒヤッとした。やっぱりしばらく旧macも一緒にもってないと怖いかも。

あとは他のイベントと比べてtwitter実況が少ないイメージ。どんなところが刺さったんだろう?ちゃんと伝わってたかな、心配です。

また登壇後、コーディングスキルアップの仕方について後輩と話したりして、結局今回レビューしてくれていた先輩がすごかった&かなり恵まれてたんだなぁということに気づく。 多分若手にとってもどんな知らない世界があるのかわからない、先輩にとっても若手がどこまで知らないのかわからない、このお互いの状態をつきあわす機会があって、うまく知識を整理してインプットしてくれる先輩がいて今回の内容に繋がったんだとおもった。 恵まれてる環境だったのは確かなんだが、より横展開しやすい形にできたらもっと良かったなと感じた。

あとは初めてはてなホッテントリに入って感動!準備してる時は地獄だとおもったけど、こういうアウトプットにできて今回CfP出してみてよかった。

ちなみに2017年の目標は「社外のイベントで登壇する」にしていて、これで叶ってしまったのでまた新しい目標を立てるとする。 自分のアウトプットに反応が返ってくる意味で登壇するのすごくよかったので、これからも機会あったらどんどん出してこ!

Node学園25時限目でLTしました〜初めての社外LTの振り返り〜 #tng25

Node学園というイベントでLTをしてきました。

nodejs.connpass.com

内容はこんな内容になります。

speakerdeck.com

ちょこちょこ社外のイベントには出てきましたが、自分でLTをするのは初めてだったので、振り返り&感想を書いておこうと思います。

準備編

スライドのトンマナ

社外でしゃべるのが初めてということもあって自分のパワポテンプレートを作りたいなーと思っていた。できることなら、スライドであっこの人だ!とブランディングできたら理想だなーと思っていた。 例えばtwadaさんはtwitterでslideのリンクが流れて来た時に、サムネイルだけでtwadaさんのスライドだとわかるので、ちょっとそういうのに憧れている。 なので、多少今後も改良はしていくだろうけど、ある程度今後も使うぞっていう前提でスライドのベースを作ってみた。

話を組み立てる順番

自分はイラレを使ってスライドを作っているので、あんまり話が固まってないままスライドのdetailを作り始めちゃうと結局時間が足りないだの、喋ってみたらちょっと違った、みたいなdiffが出てきてせっかく作ったスライドが無駄になるという知見を聞いていたので以下の順番で進めてみた。

  • だいたいのストーリーを組む
  • パワポで雑にスライド作る
  • スクリプトを組む
  • 時間におさまるか、ストーリーに合わないスライドは修正していく
  • 最後に詳細なデザイン

トーリー組むのって結構憂鬱なのではやく詳細なデザイン作り込みたくなってしまうのだけど、そこはぐっと我慢で最初にスクリプトまで決めてしまうのが一番無駄がなさそう。できればデザインに入る前に人にみてもらってストーリーラインを壁打ちするのがGoodだと感じた。

初心者向けでも楽しんでもらうために

Node学園というイベントは結構内容がギーク向けで、その中で初心者が初心者向けの発表をする時に、どうやったら聞いてよかったなーと思ってもらえるんだろうということは気にしていたきがする。 スライドシェアでスライドが見れるこの時代に生で聞けてよかったと思える発表は個人的にはストーリーの面白さ(笑えるポイントがあるとか)なんじゃないかなーと個人的に思っていて、ちょこちょこ笑えるポイント作れないかなーと思いながらストーリーは考えていたりしました。

  • 自己紹介で何か場がほぐれる掴み(ちょっとウケた)
  • 背景画像を地味に意味ありげな写真にしとく(誰にも気づかれずにすべった)
  • みんなが知ってる人のネタを仕込むとか(ちょっとウケた)

こんなかんじかしら。自分も笑いポイントってどういれていいかわからずLT経験豊富な同僚にアドバイスもらいながら最後仕込みました。 あとは、「初心者向けですよ」と最初に宣言することで期待値を調整するようには心がけたつもり。多分そこがズレていると厳しいまさかりが飛んできそう、お互いにとってよくない。

当日編

話している間はあっという間だったのであんまり覚えてない。けど楽しかった!!

拡散量がはんぱない

今までアウトプットのメインはブログだったけど、登壇&スライドの共有の拡散量はすごいなーと感じました。 あと当たり前だけどフィードバックの量が多い。どこらへんが共感してくれて、ほーと思ってくれたのかがわかるのはうれしいなと思ったり。自分が世に出したもので、はてぶ30とかはじめてもらった。あと内容が初心者向けでかつ想定読者層が広いといろんな人にひっかかるというのもあったのかも。

意外とtwitterの通知気づかない

結構どうでもいい話な気もするけど、今回まで気づかなかったので。 自分へのリプライ全然気づかず、あやうくとりこぼすところだったので注意深くみておかないと・・・。

あとは自分のスライドをシェアしてくれているツイートについては、短縮URLになっちゃったりのでタイトルも一緒でつぶやいてくれている人以外は検索にもひっかからない。自分の知らないところでつぶやいてくれてたりすることも多々あり、たまたま見つけたもののできれば全部拾いたいなーと。自分は登壇内容タイトルで検索かけてニヤニヤしていたのですがなんかもっといいエゴサの方法あるのかしら。

次に繋がる

Node女子学園でこの内容話してほしい。みたいに言ってもらったりして、次の機会につながった。 初心者向けって誰が参考になるんだろうかと思ってたけど、初心者向けの発表も新しい人が入って来やすく、学びやすい環境を作る意味で大事ですよと言ってもらえて本当発表してよかったなーと。今までJava/Android界隈の勉強会にしか行かなかったので新しい世界で知り合いが増えたのもすごく楽しかった。

LTの形にまとめることで知識の整理に

今回一つテーマを切って人に伝えられるレベルに色々組み直してLTと言う形にするプロセスがすごくやってきたことの整理にいいなと思った。意外とスライドにしてみたら、ここって本当はどうなんだっけとか間違ってること言ってないよね?の確認をする過程でも知識を深められたり。 これはブログでもできると思うけど結構自己満でいつも書きなぐっちゃうので、直で目の前に人がいて自分の言葉で喋らなくてはいけないLTのレベルまで思考を整理するのは大事だなと。

おわりに

今回初めてLTをしてみてこれはエンターテイメントだなとえもくなってしまった。個人的な話だが、昔ダンスで舞台に立っていた時、このイベントにはこのネタをやろうとかコンテストだからこういうネタにしようとか次はどのネタやる?みたいな感じで次はなんのネタを踊るか決めていた。それと同じことがこういう技術的なイベントに立つ時でも起きているなと思っていて、イベントに合わせてネタ変える感じとか自分のネタがどんどん増えていく感じとか、ちょっと昔を思い出した気がした。ダンスで舞台に立つのが好きだった時と同じ感覚が、もしかしてイベントで登壇することで味わえるんだとしたらこの世界には自分はすごくはまるし相当楽しめると思った。

こういうのを後押ししてくれる会社だったり、今の環境最高である。

次はこれに出ます!準備がんばります

www.java-users.jp

社会人2年目をエモめに振り返る

エンジニアとして2年めが終わったので振り返り。今思うことは今書いておかないと忘れちゃう。あと根がネガティブなので記しておかないと「私1年何やってたんだろう・・・」とすぐなっちゃうので。

ちなみに1年目の振り返りエントリは以下。

chiiia12.hatenablog.jp

今年度の主なトピックは以下。

  • Androidアプリエンハンス&その中で学んだ諸々。
  • スクラムチームの再立ち上げ
  • プライベートでのアプリ開発
  • 外部イベントの参加

が大きな出来事だったかと思います。

Androidアプリのエンハンス

1年目は新規アプリの開発がメイン&かなり短いスパンでチームを移動していたので、同じチームで一つのプロダクトを開発し続けるという経験は初めて。新規ではなくエンハンスをする中でただAndroidの実装スキル以上のことを学ぶきっかけになった気がする。

ライブラリの導入

今までのチームはモダンなライブラリをいれよう!という話があまりなかったので、今のチームに異動してきてから同じチームの先輩にはすごく刺激をもらった。

Realm、ActiveAndroid、Retrofit、などまだ使ったことなかったライブラリなどを、今年初めて触ったり。導入を進める先輩にライブラリの特徴・思想を聞いたり、何が便利なんだっけ?を考えたりするきっかけになった。特に先輩がRetrofitにプルリク送っているところを隣で見れたりして、すごく刺激になった。 その後、自分でチームにLightStreamAPIを導入したりできて、ちょっとだけチームのプロダクトどういう風にしていきたい?という気持ちが芽生えてきた気がする。 ライブラリを導入すると、何をどうやって便利にするライブラリなの?を考えるようになるので、自分で設計を考えるときにも参考になるなーと感じる。リスクの方が語られがちだったり学習コストなども考えるとライブラリの導入などはハードルが高かったりするけど、設計方針などのインプットにもなるのを考えるともっと導入すべきだなーとも思うようになった。

変更に強い・バグを生みにくい設計

先輩にココらへんの話のインプットはすごくしてもらった。あまり今まで設計のことを考えたことがなかった。正確にいうと、既にあるアーキテクチャに従う練習はちょっとしてきたけど、アーキテクチャを選択する練習をしてこなかった。なんでこういうアーキテクチャになっていてなぜそれを選ぶ?という観点がなかったので、そこを養えたのはよかった。デザパタとかクリーンアーキテクチャの話とかなどなど。 以下の記事は色々インプットしてた時で整理してた頃。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

あーちょっと恥ずかしくて見たくないエントリ…

テスト自動化

スクラムを再立ち上げした頃にユニットテストコードを書いていこうというルールになって初めてテストコードというのを書くことになった。 社内のアプリチームではテストコードを書いているチームがあまりなかったので良い経験になった。色々社内の先輩などに相談できる機会があったりなど、ただテスト自動化すごい!じゃなくてメリットやデメリット考えつつどう進めていったらよい?なことは考えるようになったかも。最初はデグレをなくしましょうという話からテスト自動化の話が始まった気がするけど、設計やリファクタの話につながっていくところまで考えられるようになった。 かなりここの分野も楽しくてこれからももっと知りたいなーと思ってる。

chiiia12.hatenablog.jp

スクラムチームの再立ち上げ

スクラムチームをどう立ち上げてどうなったかはこちらのエントリで。

chiiia12.hatenablog.jp

上のエントリに書いたとおりスクラムチームの再立ち上げを2回経験していて。2回やってようやくスクラムの良さみたいのを感じれた気がする。すごく今はアジャイルの考え方の虜になっていてここの分野ももっと知りたいなと思っている。 元がコミュ障で人の言うことをすごく気にしてしまうので、チームの環境によって自分のキャラを出せなかったりパフォーマンスも左右されてしまうんですよね。そういうところをスクラムとかのアジャイルフレームワークは多少でもカバーしてくれる気がしている。なので自分にはすごく合っていたのかも?と思ってる。

コーチの人に言われたことで印象に残っているのは 「問題解決は簡単だ、解決方法はいろんなひとが試しているからそこらじゅうに転がってる。大事なのは問題発見する能力。ここが長けている方が価値の高いことなんだよ」 というようなことを言われたこと。問題発見したからやばい、もうダメなチームだ、じゃなくて問題が見つかったってことは今まで見つからなかったことが問題として見つかったのは良いこととポジティブに言われたことが自分の中でも改善に対する捉え方が変わった出来事だったと思う。

プライベートでのアプリ開発

2年目になって1年目のように資格勉強に時間取られることもなくなったので、プライベートでサービス開発しているチームにjoinしました。Androidアプリ作りたいけどちょうど人がいないという時に誘ってもらって、タイミング良かった。 これまで社外でこういったコミュニティがなかったので、違う会社の話を聞けたり視野も広がったり。

www.service-safari.com

play.google.com

業務で試せてないライブラリやツールを試せる機会になったり、業務とプライベート複数同時にプロジェクトを進められる良さを知れた。一つ自分が作ったプロダクトができたのもうれしい。 その後自分一人でもう一個アプリ作ってみたのも勉強になった。CI自分で回したり自分でストアにあげたり。アイコンも自分で作ったり。自分が作ると他のアプリも注意深く見るようになるなー。自分だけでやってるので放置になりがちなのが反省点。

外部イベントへの参加

これも2年目になって業務都合をつけやすくなったので、ちょこちょこ外部のイベントにも参加するように。同じ年代の人がLT登壇とかしていてやばい!!!と良い刺激にも。

chiiia12.hatenablog.jp

去年も行きたかったけど行けなかったDroidKaigiにも今年初参加! 他の会社がどんなことに取り組んでいるのか、最新技術等やっぱり行かないとわからないことがたくさんでとてもよかった。登壇にも挑戦してみたいなぁ。

今年はDroidKaigiの公式アプリにもコントリビュートすることを目標にしていて、本当にちっっちゃなBugFixだけど英語でプルリク出してみたり。いつもtwitterで見るアイコンの人がコード見てくれて当日のContributersスライドにアイコンが載ったり。かなりうれしかった出来事。

今年度の最後にはJJUG CCCの登壇も決まり準備をそろそろ始めなきゃという感じ。去年はおっかなくて周りの人に投票なんてお願いできなかったけど、背中を押してくれる先輩もできて、いろんなコミュニティに投票をお願いできたり、良い関係のコミュニティが増えたんだなぁと感じて、前向きに色々がんばれてるなと思う。

その他

そういえば応用取ったし次は高度受けるかっつってネスペを受けたけど午後で落ちた。情報処理試験はいつも勉強がつらい。

後はちょっとしたクリエイティブ。

chiiia12.hatenablog.jp

chiiia12.hatenablog.jp

後は会社でOSS勉強会なるものに参加したり(先輩のコードでnodeにプルリク送ってみたり)、外部の会社のエンジニアとTDD的な勉強会でGo触ったり。 刺激!な1年だったのかも。

まとめ

会社の先輩にこんなこと言われたのが印象的でそう信じてる言葉。

「エンジニアはやればやる程知らない事が増えていく。知らない事が減るってことは成長していないということだから、知らないことが増えていくことは良いことだと思って!」

この1年も色々新しい世界を知れて楽しかった!特に周りの人には恵まれていたなと思っていて、良いまさかりをたくさんもらえたなー。相談できる人も増えたしかなりのびのびやらせてもらえたと思っている。まだまだ技術力は低いと言われているのが悔しいところで、そこはこれからも伸ばしていきたいところ。

今年は取り組んできたことをブログなりなんなりにアウトプットすることを重視してきた気がする。ちょっとブログを読んでくれる人が増えたりして、自分のことを知ってくれる人がいるのはうれしいなーと思ったり。あと精神安定的にも◎。 今年は、ブログだけじゃなくてもっとコード書いてアウトプットしなきゃな。

次はどんな1年になるんだろう!3年目もがんばるぞー!

テストについて相談しにいった内容をまとめる

チームのテストについての進め方についてアドバイスをもらう機会があり、これからの進め方についても参考になったのでまとめる。

前提・背景

  • アプリ開発チーム。
  • Model,Controllerは必須で単体テストを書くというルールで開発している。
  • 振る舞いテストも一部コード化してリリース前に自動で回している。

今のチームでの課題

  • 単体テスト書いてきたが、なかなかメリットが享受できていない気がする
  • ふるまいテスト書いてみたはいいが、この先どう展開していくのが良いのだろう?
  • viewにビジネスロジックが積まれていてなかなかテストが書けない。構造見直ししたいがアーキテクチャの指針なくできない。

viewにビジネスロジック問題

viewにビジネスロジックが書かれていてテスト書きづらい。 どうにかしたいが、リファクタするにはテストがいる。 じゃあテスト書きたいけど書きづらい!の堂々めぐりになってしまう問題。

実装の構造に依存する・実装に近いテスト(例:ユニットテスト)は書きづらいので、実装から遠いテスト(例:ふるまいテスト)を書いてリファクタする準備をまずしましょう、というのが次のアクション。なるほど!

振る舞いテストで安心してリファクタできるようになれるのか

たしかに、怖くてリファクタできない!けど構造変えなくては!の打ちてに対して実装に依存しないようなシステムの外からのテストを書けばよい!というところには納得。 現状、今のチームではアプリをリリースする前に毎回行っているアプリの根幹の機能(主に遷移周り)のテストを書いている。でも、粒度もすごく大きいテストケースなので、それで安心してリファクタできるイメージが湧きません!

それに対してのアクションは、まずカバレッジをとりましょう。まずどこがカバーされているテストがあるのか、どこのコードが通っているテストがあるのかを可視化する必要がある。テストが通っているところから構造変えていくようにすればよい。

この話をふまえると、これから構造よくしていきたいところにユニットテストを書いていくより、ふるまいテストの拡充を優先度を上げた方がいいのだろうな。まずは外から、だんだん中に入っていってカバレッジなどをあげていく。 今までカバレッジなどは気にしないで「書けるところを書いていこう」の指針でずっと来てしまったので、きちんと数値とっていかないとダメですね。

振る舞いテスト(≒スモークテスト)の運用

今チームの中で振る舞いテストと言ってるものは「スモークテスト」と呼ばれる「このテストが落ちると、リリースしてはいけないというレベルのもの」になる。 このスモークテストを今までリリース前に最後のチェックとして行ってきた。本当はリリース前に煙が出てもしょうがないので、普段から本当は回すべき。プルリクがマージされた時などに自動でテストが回るような仕組みにしておくと早めに重大な問題に気づくことができてGood!

アーキテクチャ決まってない問題

アーキテクチャに関しては最初は「王道なもの」を採用してやってみると良い。同じ挑戦している人の人数も多いし、ぶつかった人も多いので、導入もしやすいだろう。MVPならMVPと決めてやってみると処理を書く場所があらかじめ決まっているのでテスト書かなきゃいけない処理も決まってくる。一回入れてみて問題が出てきたらまた考えても遅くなさそう。

[おまけ]テスト自体は品質をあげるものではない

テストコードを書くこと自体は 品質をあげるものではない。 テストコードを書くことで、プロダクションコードに影響を与える(リファクタできれいになる、使いやすいように引数の種類変えてみようかとか)ことで品質があがっていく。なので、テストコード書いてプロダクションコードが変わらないのは別に品質あげてないよ。もちろんデグレを防ぐみたいな役割もあるかもしれないけど、品質はあがってないよね、下げるのを防いではいるけど。 という思想があるので、テストファーストに越したことはないが、テストファーストをするためにはプロダクトの実装の仕方(構造が悪いとか)にも寄るしある程度のスキルが必要なので、テストファーストにこだわらなくてもよい。大事なのはプロダクションコードにプラスの影響を与えられているか。

[おまけ]mock使う派?使わない派?

テスト駆動開発界には流派が2つあるらしく、mock使う派(テストは分離した方がよい)と使わない派(本物のデータを使う方がよい)とがいるらしい。

mockする派

テストしたいクラスを狭めることができる。mockしていなかったら依存しているクラスの中もテストしていることになるけど、mockすると純粋にそのクラスのロジックをテストできる

mockしない派

自作自演のテストになる可能性がある。mockしている実体が変わったら意味がなくなっちゃうから。テストは通るけど結合したらうまくいきませんーみたいなことが起きてしまう。 最近のmockライブラリは強力なので、なんでもできてしまう。そもそもmockが必要になるというのは設計としていかがなものか?を気づく基準にもなるけど、強いmockライブラリがいるとスルーしてしまう可能性。この話は先輩からも聞かされたなぁ〜。

さいごに

今までどう打ちてを打っていいかわからないところをアドバイスもらえて次の一手が見つかった気がする。テストの世界では当たり前の考え方なのかもしれないけど、ぺーぺーの自分にとってはすごく有益なアドバイスをいただける機会でした。

#droidkaigiに行ってきて思ったことをダラダラ書いてみる

初めてDroidKaigi参加したので、ちょっとまとめるのが遅くなってしまったが記憶が新鮮なうちに考えていたことを残しておきます。 https://droidkaigi.github.io/2017/timetable.html

参加したセッション

参考までに参加したセッションは以下。

How to apply DDD to Android Application Development
リリース自動化と効率のよいリリースフローを求めて
インスペクションとAndroid Lint Custome Ruleによる、単一責任実装の実践
Data Bindingで開発を気持ちよくしよう
Android Resources Refactoring
オフラインファーストなアプリケーション開発
How to remodel current testing environment
What's New in RxJava 2.0
Android ORMの選び方
How to implement material design animation
Kotlin + RxJava + Dagger2 + Orma + Retrofit で作るAndroidアプリ
2つのアプリ、1つの設計のデザイン指針
エンジニアが武器にするMaterial Design
LayoutManagerをつくろう

特に強く印象に残ったこと

特に印象に残ったテーマを以下に記していきます

オフラインファーストなアプリケーション開発

https://speakerdeck.com/zaki50/ohurainhuasutonaapurikesiyonkai-fa Realmすごい…。今のチームでもRealmいれてるけどバージョンが昔すぎて全然キャッチアップできてないことがわかった。 オフラインの時の体験を考えるってアプリならではの観点だから新鮮&そこにも踏み込んで考えていけるのがアプリのいいところ。

実際今のアプリってどれくらいオフラインファーストにされているんだろう

すごくこのセッションの内容に刺激を受けたので、オフライン状態で今のアプリがどれくらい使えるのか触ってみた。

  • Facebookinstagramgoogleフォト、メッセンジャーGoogle Play Musicはオフラインでもだいたい使える
  • instaは前に読み込んでいた10件くらいはオフラインでも見えるようになってる。追加読み込みだけできない。
  • twitterは微妙。ツイートはできる(iphoneのみ)けどタイムラインは見れない
  • Google Play Musicはすごくて、自分の評価した曲はオフラインでも聞けるようになってる。おかげで端末が圏外であることに気づかなかった。

今のチームのプロダクトはどうなんだっけ

アプリの業務仕様上最新の情報を常にリクエスト投げて確認しなくてはいけないので、通信エラーにすごく厳しいアプリになってる(オフライン時は通信エラーダイアログが出てで画面遷移できない)。オフライン時にアプリを立ち上げるとマジでなにもすることができないアプリになってた。

今まで「通信状況の悪さ」はアプリでは担保せず、ユーザーの状況が悪いんだよというふうに伝えてきた。けどこういう簡単に実装できるプラットフォームが出てきたりすると、通信状況というのはユーザーの責任ではなくアプリの責任になっていくのではないか?本当は通信エラーで画面遷移できないとかは、こっちの勝手な仕様のためにユーザビリティ落としているってことになるんだよなぁ。

なのでこれからはより通信状況に依存しないアプリの操作体験を作っていかなきゃいけなさそう、作っていきたい。 実際有名なトップレベルのアプリはオフラインでもある程度操作できるようになっているし、通信状況がないこともとても控えめに伝えるようになってる。気づきそうで普段意識してない観点を考えるきっかけになってよかった。

エンジニアが武器にするMaterial Design

https://speakerdeck.com/seto_hi/enziniagawu-qi-nisurumaterial-design webと比較してアプリのデザインてグラフィカルなスキルだけでなくOSの標準の挙動とかOSが推奨しているデザインも把握していなきゃいけないよね→かなり負担なのでは?というところからアプリのユーザー体験みたいなところにエンジニアがもっと関わっていこうよ、というお話。特に、Androidは「iOSのデザイン、これAndroidにして」事件が多発しているし同じ課題を持っている人は多そう。

KPIの置き方のはなし

企画の人にとってはKPIに直つながる案件をしたいというのは当たり前なんだけど、時たま「ユーザビリティを多少落としてでも」アクションがあがる施策をやる判断になってしまうことがある。そういう時にわかってはいるんだけどもやもやするという経験があって、そういう時に「いやいや、ユーザビリティ落とすのはダメでしょ、なぜなら」を言えるエンジニアになりたい、けど言えない&うまく説明できない自分。この答えの一つが「エンジニアが武器にするMaterialDesign」なんだと思っている。本当はユーザビリティがKPIにつながっていること&重要さを証明できればいいのだが、現状難しいのかも。

キャリア戦略として

自分の会社はいわゆるグラフィカルデザイナーとUXデザイナーが別職種としているので、エンジニアがUXのところまで踏み込む武器のつけかたを見たことがなかったので、すごく刺激的だった。自分も興味がある分野だったので、これからどこ武器にしていくんだっけ?の参考にとてもなった。もうすごくステキな話で本当に聞きに行ってよかったと思った。

その他

他の会社の開発環境が聞けるの、すてき

なかなか会社内にいると開発環境も似たり寄ったりなので、他の会社の開発環境が聞けてとても刺激的だった。世の中のプロダクトがこんなにRxJavaやDaggerなどの今時のライブラリを使って開発してるとは…。ライブラリを入れる入れないはちゃんと判断が必要だけど、若干の悔しさを感じて帰ってきた。

企業ブース、すてき

CyberAgentのブースで看板サービスのbuild.gradleを公開します!という企画をやっていて、開発イケてます!ということがよく伝わってうまいプロモーションだと思った。転職考えてたら絶対候補にはいると思う笑

他にもいっぱいノベルティもらってとにかくはしゃいできた。

アプリのOSS化、すてき

あとは今年はDroidKaigiのアプリにコントリビュートするぞ!と決めていて、なかなかレベル高くてひよっていたけどちっちゃいバグフィックスでコントリビュート達成した。いつもネットで見ているアイコンの人たちにコメントしてもらえたり、コントリビューター一覧に名前が載ったり、はかなりモチベーションあがった(マージされた夜は興奮してしまって眠れなかった)。ただの参加者からDroidkaigiに自分も関わってるんだぞ!と思える感じ、最高。

まとめ

DroidKaigiのセッションはスライドも動画も後で見れるのだがやっぱり当日行って全部の時間なにかしらセッションを聞きに行くのがすごく良いことだよなと思っている。後で動画で〜だったら自分の知っている範囲で課題感持っているところしか見ないと思うので、新しい分野を聞きに行く点で生で参加するメリットはあると思う。アフターパーティに出れなかったのが残念。

ということですごく良い経験をしました。来年も参加したい。今後は登壇にもチャレンジしていきたい!

スクラムごっこからガチスクラムになって変わったこと

自分のチームは以前からスクラム体制を取り入れていましたが、今年同じスクラム体制でもやり方をガラッと変えたことで感じたこと・変わったことをまとめてみたいと思います。ちょっとタイトルはキャッチーに書いちゃったけど当時は本気でやってたよ!

プロセス改善前の状態

  • アプリの開発チーム
  • iOS 4Android 4人 スクラムマスター1人の体制
  • 2週間スプリント 自分がジョインする前から「スクラム」で開発を進めていた。「スクラム」で開発するのが初めてだったので、元からあるやり方で先輩に聞きながら開発を進めていた。

プロセス改善

転機は有名なアジャイルコーチの方がアドバイザーの形で入ってくれることになったこと。その時色々選択肢はあったのだが、色々あってスクラムで続けていきたいとなって、もう一回スクラムをやり直すことになった。

チームの再立ち上げ

新しくスクラムチームを立ち上げる時にやったことが以下。

開発チームできめたこと

それまでのプロセスとは変わったところ

1週間スプリントになった

今まで月曜はじまりの2週間スプリントだったけど火曜始まりの1週間スプリントにした。 火曜日始まりの理由は月曜は休みが多いから。水曜始まりでもよい。 火曜日の予定は 午前中にスプリントレビュー、レトロスペクティブ。 午後にスプリントプランニング。 火曜日にスプリント切り替えを全部行う。火曜日は一日会議になる。会議の日と実装の日が完全にぱきっと分かれる。最初はうげーとなるけど結構よい。

タスク分解の仕方

案件を実装タスクに落とす際は0.5~1hになるまで粒度を細かくする。 「調査」というタスクは入れない。影響調査などはすべてプランニング中に終わらせる。 プランニングの時に徹底的なプランニングをすることで、あとの日は徹底的に計画されたタスクをこなすだけという狙い。これも最初むりでしょーて思うけどできるようになるしそれがとても良いことだと気づく。

要件を受け入れ基準として定義する

ここは開発チームだけでなく企画側にもお願いするお話。要件をもらうときにAcceptance Criteria(受け入れ条件)を決めてもらいこれを元にエンジニア側で設計・実装をするし、このA.Cをもとに受け入れをしてもらう。なんとなくの案でもらうと、受け入れる人によっても基準が変わってしまう。開発側はA.Cに書いてあることだけ実装する(それ以外の挙動は変えないが前提)。そこに漏れた要件は企画側の責任になる。ここで今まであいまいになっていた責任分解点ができた。

結果変わったこと

チームの中でプロセス変えてどうだった?という話をだべったのでその内容を。

常に緊張感が出る

2週間スプリントの時は前半だれていた、後半がんばる、というサイクルに自然となっていたみたい。 1週間スプリントは緊張感がある。提出まで中4日しかないので、ちゃんと時間通りタスクを消化していかないと終わらない。例えば1日何かがあって遅れてたら、2週間スプリントだと最大8日かけてリカバリできるけど、1週間スプリントだと最大でも3日しかリカバリにかけられない。

開発の奴隷化の解消

どうしても企画側の企画があってから開発があるので、以前は開発工程で出た問題は開発の問題になりがちで責められがち。本当は開発の問題じゃなくても。 案件を受け入れ基準駆動で行うことで、企画側と開発側どっちの責任かがはっきり分かれ、全部開発の責任になるということが減ったと思う。 どこまでがどちらの責任と決めたこと、決めたことに対して公平な立場で厳しく言ってくれる人がいたことで、開発側も「悪いって言っていいんや!」と、ちょっと安心した面はあったと思う。企画側にも物言える開発チームに変わりつつある。 実際に仕様が詰められていない案件については企画側の責任範囲になるので、開発側が詰められていない案件のカバー&実装みたいなことはなくなって開発は幸せになったと思う

問題発見フレームワーク

スクラムというプロセスは何かの問題を解決するプロセスというより「問題を発見するためのフレームワーク」と習った。これをやってみるまではあまり実感できなかったが、計画スプリント内に行うタスクを0.5~1hまでの粒度まで落とすという作業は、細かく指定する分計画と違いが出たときにわかりやすい。 今までは「実装4h」などとざっくり見積もりでよかったのかもしれない。けど本当は問題が隠れていたのかもしれない。 また、ここまでタスクを切るということはプロジェクト内の影響調査のしやすさにも関係があると気づいた。この方法をしてから「簡単にタスク分解しやすい」案件と「どこをどう直せばいいかをつきとめるのに時間がかかる」案件に分かれる。じゃあ後者ってこれあんまり良いコードじゃないのでは?と問題を問題と気づくきっかけをくれた気がする。

その他

以下はスクラムをいれたからというより今のチームの状況で得たものも参考までに書いておく。

スクラムマスターの不在

スクラムマスターの不在というとちょっと意味が違うのだが、スクラムマスターの方が異動になり、チーム内でスクラムマスターという肩書を持った人がいなくなってしまった。事実上、アジャイルコーチの方がスクラムマスターのような役割をしてくれていたのだが、週に1度程度の頻度でしかコーチングに来れないため、セレモニーのファシリテーションやレトロで出た施策の管理などはチームメンバーがやっていた。 今考えると当たり前だと感じる点もあるのだが、前の体制は全部スクラムマスターにお願いしてしまっていたのだ。あとは他のコミュニティで「ファシリがうまいね」と言われたことがあって、それはここでの経験だと思っている。

QAの不在

これは自分の会社であるあるなのかもしれないが、だいたい開発チームはQAの方がいて、テストを担当してくださる。うちのチームはなぜか(スクラム導入時にそのような体制にしたと話は聞いた気がする)QAが不在のチームだった。従って当たり前に自分達でテストをすべて行う。 自分たちで開発→テストを行うので、テスト工程まで見越した考え方ができるようになったと思う。 QAがいてくれる安心感からは、「不具合を出しにくい設計とは?」という観点が出てこない気がする。QAがいて不具合を見つけてくれることで大変なのはQAだから。テストの中だけの改善、開発の中だけの改善だけでなくて、テストの改善のために開発を改善するみたいなことが起きる、考えられるようになる。自分にとっては考え方がかなり変わったところだ。

まとめ

結局事業には貢献したの?と言われるとなんといっていいかわからない。この体制にしてからプランニング時間内にで1つの案件しかプランニングできてなかったチームが今はだいたい20この案件をプランニングしそれを実装までこなせるようになったのは設計・開発スピードが改善したのだと思うけど、厳密に見れば色々他にも要因はあるからね。 個人的には、アジャイルの考え方やプロセス改善の方法を学べたことはとても成長になったと思う。 新卒1年目ウォーターフォール→新卒2年目スクラムとやって、もうウォーターフォールのチームには戻りたくない。なかなか大きい会社でスクラムをやることは難しいけど、気合や残業で解決することなく、人じゃなくて問題に目を向けるという意識が根付く。この意識が根付くことだけでも開発者が幸せになるフレームワークになるんじゃなかろうかと思っている。実際今年一年楽しかった。という振り返り。