SWWDC 仙台iOS開発者勉強会#21 参加レポート

今年中にiOSアプリを一本リリースしたいと考えているんだけど、 ちょうど仙台iOS勉強会Swiftについての勉強会があったので参加してみた。
https://atnd.org/events/56274

ライブコーディング

仙台のホープ@ktanaka117さんによるHealthKitのライブコーディング。 デブなのでHealthには興味アリ。
ちょうどコードレビューを実施していたので、Objective-Cが詳しくないなりにも楽しかった。
blocks関連の循環参照のこととか、弱い参照、強い参照とか、勉強しないといけないんだなーと。
http://qiita.com/keroxp/items/68c80b9c9fa8da9147c3

そしてこのSwiftのサンプルサイト。 現時点でもこれは凄いし、さらに増えていくらしい。。。
https://sites.google.com/a/gclue.jp/swift-docs/home

SwiftとAzure

続きまして、MicrosoftのMVP様こと@nnasakiさんからSwiftとAzureの連携を教えてもらった。
http://www.slideshare.net/YamamotoMasaki/microsoft-azureswift

ダウンロードすると、簡単なサンプルもついているし、DBを意識しないでいいって楽ですね～ 開発時、テーブル意識しないでカラムを自動追加。 実際のサービスインのときには自動追加無しにしてリリース。 小さく早く出すためには良さそうです。

画面サイズ

続きまして、@totottiさんによる画面サイズ。 iPhone4、iPhone5、iPhone6、iPhone6Plusというキビシイ戦いを感じることが出来ました。

• 現状はiPhone5用のアプリはiPhone6や6Plusでは拡大モードで動作しているものが多い
• これからはAutoLayoutに対応していかないといけない

最後に参加者の皆さんと話してて、SwiftとObjective-Cについて以下の意見を貰った。

• Objective-Cは最悪Cなら動作するという安心感はある。
• Swiftは今風なので、これから始める人はいいんじゃないかな？
• Objective-CはC++との相性がいいので、C++のライブラリを作る人はObjective-Cの方がいいかも。
• SwiftからはC++コードをObjective-CでWrapすれば読み込める
• Swiftの方はまだコンパイラにバグがあるかもしれない

そして@CortYumingさんのTLから衝撃的事実が･･･

iPhone アプリ作るなら swift じやなくて Obectivej-C だなぁと思った。

— Takashi ITO (@CortYuming) 2014, 9月 27

さらに若手のホープ@ktanaka117さんからこんな言葉が･･･

まずはObjective-CでなくSwiftでも大丈夫だよ！というのを自らをもってして証明せねばぐぬぬ

— ダンボー田中 (@ktanaka117) 2014, 9月 27

忍者式テストを調べてみた！

10/4(土)に栃木で行われるとちぎテストの会議03（とてか）の参加申し込みをしました。 http://d.hatena.ne.jp/tochigitestnokaigi/ 今からイカしびりてぃを高めて行こうと思います。

ところで、招待講演の忍者式テストとはこれイカに･･･ パッと聞いたイメージでは、テストでバグ出たときに変わり身の術とか、徹夜のテストでおなか減ったときにスイトン食べるとかそういうイメージがありますね。 でも実際は分らない・・・ ということでちょっと調べてみました。ニンニン。

JaSST東京'04で関さんが発表した資料
http://jasst.jp/archives/jasst04/pdf/A7ah.pdf

忍者式テストをやってみた@ledsun
http://ledsun.hatenablog.com/entry/2014/07/16/073122

ledsunさんとm_sekiさんとの「忍者式テスト」についての対話
http://togetter.com/li/266752

どうやらこれは栃木のKentBeckこと関さん※1が発明したテスト手法のようです。
イカは関さんの資料より抜粋しました。

どんどん成長していく受け入れテストを忍者のジャンプの修行の木に例えた忍者式テスト！ 細かいところまで手が回らないと割り切ったときにどのようにアプローチしていくのか参考になります。 しかもこの方法間違いなくアジャイル/XPと相性がいいですよね！ 毎日ストーリーベースのテストを実施し、ストーリーを少しずつ増やしていく。 見方を変えるとSDD（Story Driven Development）ってところでしょうか？ しかし！そんな名前にせず"忍者式テスト"にした関さん、、、凄いっす。

とてか03ではイカのことに注目して@ledsunさんの招待講演を聞きたいと思います。

• ストーリーの工夫
• エンジニアが飽きないような工夫
• ストーリーの履歴の管理
• 対象ソフトウェアの規模感
• 探索っぽい要素の有無

ということで、とてか03楽しみにしてます♪

※1 関さんはJaSST'14東北の基調講演でお話してもらいました！

とちぎテストの会議

JaSST'14北海道レポート①

早速、JaSST'14北海道のレポート①を書いてみた。

和田さんの基調講演

目指すものは「動作するきれいなコード」 by ロン・ジェフリーズ
これはTDDを実施している開発者もテストエンジニアも同じ思い。

テスト駆動開発とは？

和田さんによるテスト駆動開発の説明があった。
今回はTDDを全く知らない人も参加者にいるので、かなり丁寧な説明をしてくれたと感じた。

• コードを書かないとわからないことが多い
• 綺麗な設計をしてから！ではなく、動かしてからきれいにする
• 重要なのはテストがある状態でのリファクタリング。

FizzBuzz問題のデモ

実際にFizzBuzz問題をt_wadaさんがデモしながら、TDDの話をしてくれた。

• 仕様をToDoリストに変更する。→ 個人的にはポイントだと思う。
• テストクラスの名前にはTestxxx と xxxTestの2流派ある
• 日本語でテストのメソッド名を書く → 日本で開発している場合はかなり有用
• 初めての場合はテストコードはゴールから考えていく
• テストコードのテストは実装コード。お互いにテストしあう関係
• 実際にテストで値を入れることで気づくことがある
• 二つ目のデータが正しいコードを導く（三角測量）

三重ループ

Why 頻繁なリリースとデモ
What アクセプタンステスト
How ユニットテスト

TDDの導入効果

MSやIBMの論文の事例の紹介。

• TDDで欠陥は６割〜７割減る
• 実装時間は２割~３割増える

テスト駆動開発を導入することで、プログラミングレベルの
軽微なバグっていうのは無くなる。
TDDを実施した後で出るバグは本質的なバグ。それに対処する。

ユニットテスト自動化してれば品質大丈夫！っていう人が多いので、和田さんにズバっと言ってもらって嬉しいなぁ〜

テストは品質を上げない

体重計を買っただけでは痩せないように、
テストでは品質を上げることはできないので、
品質を上げるためにはコードを修正する必要がある。
テストはあくまでもキッカケに過ぎない。

これは…身をもって体験してるｗ
体重計に乗ってるだけじゃ全く減らないorz

改善を我慢しなくても良い

以前は動いてるコードは触らないということで品質を保っていた。  
今は自動テストがあるので改善（リファクタリング）を我慢しなくてもいい。  
対象のソフトウェアの動作が変わったら、テストが教えてくれる。

やっぱり「動作しているコードを触らない』という方針だけだと機能追加には耐えられないだろうなぁ。常にDRYを意識しながらコードを書いていきたい。。。

開発とテストの人はもっと一緒になろう

TDDだけやっていれば品質があがるかというとそうではない。  
やはり第三者の視点というのが必ず必要になる。  
開発の人とテストの人が一緒にやることでもっと良いものを作ることができる。

本来、開発者とテストエンジニアは共通の目標があるはずなのに、いがみ合っていることが多い。でもそんなんじゃいいもの作れないよね。

感想

今回のJaSST北海道は基調講演に和田さんをお呼びしたことで、開発者からみた品質、テストの話を聞くことができた。JaSST東北でも関さんに来ていただいたので、JaSST東北〜JaSST北海道は開発者視点のテストという流れが繋がった感があってちょっと嬉しい。
和田さんの最後のメッセージにもあるように、開発者はテストの方へ、テストエンジニアは開発者に近づいていく必要があると思う。そしてお互いが交流することで知識の移転が行われるんだろうなぁ。
TDDだけで品質を担保することはできないし、テストだけで品質を上げることはできないから。

『牛タンとビールとアジャイルとプログラマの幸せ』

昨日はソニックガーデンの倉貫さんをお招きしての、『牛タンとビールとアジャイルとプログラマの幸せ』のイベントでした。

会場は楽天さんです♪
利休の牛タンを買ってきて全員で乾杯から始まる勉強会。これめっちゃいいわ。

倉貫さんの話はいつも刺激的だし、生き方自体がカッコイイなぁと思います。今回も凄いなぁと思ったことは沢山あったけど、自分の心に残ったことを書き留めておきます。

これから生き残る仕事は
０から１を作る仕事
 もしくは
何かの問題を解決をする仕事

日本は人口が減少していくので、頭数の勝負は新興国に分があるということも言ってて、それは本当にそうだと思う。

プロフェッショナルとは…
毎日自分のスキルを研ぐこと
前の日のコードよりカッコイイコードを書くのがプロフェッショナル

常に意識してないとダメだと思う。
毎日コード書かないとダメだ！！ ダメだ！！

信頼とは貯金のようなもの。積み重ねである。
毎週キチンと成果を届けると信頼はドンドン溜まっていく。
みんなは飲み会に頼り過ぎ（笑

確かにSkypeで毎週顔を会わせて話をして、毎週確実に成果を届けるのがやはり本質なんだろうな〜 継続的に価値を提供するというのが遠回りのようで、一番の近道だと思う。 ２次会でこっそり話してもらった『コードで女を泣かせるエンジニア』の話なんてまさにそれ！！

アジャイルとは結果である

自分がどうしても聞いてみたかったアジャイルとは何ですか？という質問に対しての倉貫さんの答え。ソニックガーデンとしてはアジャイルを特別意識していることはないけど、顧客の満足のためにを追求していったら、結果としてアジャイルになっていたとのこと。この話に付随して倉貫さんとアジャイルの出会い〜ソニックガーデンの立ち上げの苦悩の話もめっちゃ面白かった！！

ソニックガーデンでのレビューは二つ
・コードレビュー
・ワークレビュー

ワークレビューは師匠が弟子のKPTに対して行うレビューとのことです。KPTをレビューするというやり方は自分も新人教育のときに何回か実施したことあったが結構難しかった記憶がある。
早く本にならないかな〜とwktk。
http://kuranuki.sonicgarden.jp/2013/10/%E3%83%AF%E3%83%BC%E3%82%AF%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC.html
他人に指摘されずとも、息をするようにふりかえりを行うのが師匠とのこと。

3年後を見据えてソフトウェアを作ってはいけない

これは参加者からの「エンジニアが３年後を見据えたコードを書いた場合はどうしますか？」という質問の回答。自分も賛成でやっぱり未来を完全に見通すことはできないので、今の時点のベストがいいんだろうな〜って思う。

ER図みたいなものは書くが、モデル自体は書かない。

モデルは一体どうなんだろう？って思ってたので質問してみた。ほとんどはコードで担保しているということ。モデル自体の妥当性とかは見ていない。ただ関連の間違いなどは動作させれば分かると言っていた。

あるスレッシュホールドを超えると、バグが頻発するので、
そこまで行かないようにコードをコントロールする

これは本当にそうだよなぁ・・・
テストだけを見てるとなかなかコードの方に頭が行かないことがあるけど、コードをしっかり書くことで不要になるテストもあるんだろうな〜 デグレもありませんって言ってたし（笑

ソニックガーデンのコードレビューの原則はDRYであること

やっぱり『動作しているところは触らないで品質を保つ』という方針は、その瞬間はいいかもしれないけど継続的ではないんだろうな〜。そういう方針の場合は、コピーコードが増えていき、メンテナンスがキツくなり、テストも条件が増えていく。。。

会社の拡大と社員の幸せを天秤にかけるともちろん社員の幸せを取る

これ本当に実践しているのが凄いな〜
ここまで知行一致している人ってなかなかいないな〜って思う。

倉貫さん、本当にどうもありがとうございました！
また仙台で牛タン用意してお待ちしております♪　

ぐるぐるDDD/Scrum復習編

ぐるぐるDDD/Scrum復習編に参加してきた。 講師は原田騎郎さん。めちゃめちゃ面白い人です。

チームビルディング

知識があってもプロジェクトが止まらないということを身をもって体験するプチ演習。
中身は言えないけど、これはスゴい！！
全てのマネージャにやってもらいたいプチ演習ｗ

ぐるぐるDDD

お題は勉強会の支援システム。
最小の機能でリリースすべく、シナリオを決める。
プロダクトオーナーの井上さんに色々話しを聞いて、何が問題点なのかを聞き出す。
どうやらドタキャンされるとお菓子の分だけ赤字になることがあるらしい。。。あるある。
その後、チームのみんなでシナリオとモデルとコードで一回しする。
正直モデリングっていうのが本当に面白いなぁ〜って思った。

これは会社のみんなと共有したい！！
９月に原田さん来てくれるみたいなので絶対やるよっ！！

分かったこと

• どこまで考えるかによって、モデルが結構簡単に変わる
• シナリオで説明できないプロパティは入れない
• フル/レス/フル/レス/フルのようにステートレスを挟むとテストが発散しない
• モデルとシナリオとコードは常に３味一体
• プロジェクトが失敗したのは何かをヤリすぎたから。それを明確にしてないとふりかえりの意味はない。
• 作るもの、プロセス、人、新しくしていいのは１つだけ。いっぺんに新しくすると失敗する。
• 設計は何かに縛られている。最初はCPUやメモリなど。最近は人間の頭の中のキャッシュ！
• ビールを入れるとぐるぐるが止まる。（頭はぐるぐるｗ）

ということで、今日はモデリングやプロジェクトに関して沢山考えた・・・ これは縁だな・・・８月のSCRUM研修に行くのを決めた！

そしてジャンケンではSoftware in 30 Daysをゲット！ 近頃ジャンケンが強い（笑

ファシリテーショングラフィック（FG）の練習会

ファシリテーショングラフィック（FG）の練習会に参加してきた。 色々気づいたことがあったのでまとめておく。

そもそもの動機

そもそもは会社での会議がどうしても空中戦が多かった。ただ、そのときにホワイトボードを使って書くようにすると、明らかに効果があると実感していた。ということで、もう少しスキルをあげることができないかな～と思ってたところに、会社の友達からこんなイベントあるよ～ということで参加を決めた。

色は少ないほうが好き

ファシリテーショングラフィックには作例として色々な色づかいのグラフィックが載っているが、ごちゃごちゃしてイマイチ好きじゃない。個人的には色は少ない方が好き。でも自分の演習のときに色を変えたほうが絶対良いっていうところが見つかったので、そういうところは意識していく必要があるなぁ～って思った。

議論の納得感 ＞ 後での見やすさ

これも参加するまではあまり意識できてなかったけど、やっぱり自分がFGに求めている一番の目的は議論のときの納得感が重要なんだろうな。後で見たときにイイネーって思うのと議論のときに納得感があったわ～っていうのは違うんだと思う。 これは泡の会という飲み会の振り返りでも聞いてみたけど、みんな意見が違って面白かった。

FとFGを同時にすることは結構難しい

スキルが足りないのかもしれないけど、話ながら書くというのは結構難しい。 ワークのときはゆっくり話しているけど、本当に喧々諤々の議論を聞いているのをまとめるのはちょっと無理だろうな～。やっぱりグラフィッカーの存在をみんなが意識しながら進めていく必要があるんだろうな。

その場でフレームワークを考えることは無理！！

その場で新しい図を生み出すのは無理なので、事前に自分が使える図を増やしていく必要がある。マトリクス/マインドマップ/親和図/連関図とかが使える感じ。もう少しこのレパートリーを増やしてみたい。

短時間の中でイラストは難しい

ワークの時間が20分ということもあったが、やっぱり緊張の糸がずっと張っている感じ。その中でFとFGをやりながら絵を描くっていうのは難しかった。まあ誰かが意見を言ってるときにイラスト書いてたら、「聞いてよ！」ってなりそう（笑
もう少し時間に余裕があって緩むときがあればイラストかけるかも･･･

KPTの話でイベントに少し貢献できた（かな？）

ふりかえりのフォーマットでKPTを使っていたんだけど、他の人のチームを見るとTryの出し方が上手くできていないようだった。全体のふりかえりのときに話できる機会をもらえたのでKPTの書き方を参加者のみんなに伝えることができた。 せっかくなのでふりかえりのフォーマットに使ってもらいたいしね。 この前書いた論文が上手くつながっているような気がして、ちょっと嬉しかった♪

人が良かった

参加者も運営の人も色々な人がいたけど、みんな個性的で面白かった。運営に関わっているヨッシーさんの後輩ということもあるけど、初めて会った自分の意見をきちんと聞いてくれるっていうのはとっても凄いなぁ～と感じた。
自分は･･･できないかも（笑

ファシリテーショングラフィック読了

ファシリテーション・グラフィック―議論を「見える化」する技法 (ファシリテーション・スキルズ)

会社のミーティングが空中戦になることが多いので、ファシリテーショングラフィックの練習会に参加することにした。
事前に読んできてください指定されたので、会社の友人に借りて読んでみた。
個人的にはファシリテーションっていうのはあんまり好きじゃなかったけど、本を読むといいなぁとか使ってるなぁっていうのはある感じ。 ファシリテーション、ファシリテーションって言ってる人が嫌いだったんだろうな〜と過去を振り返ってみる（笑

気になったところ

P44
前もって議論の展開を考え、使えそうなツールを思い描いて…（略
それを会議が始まるなり押し付けるのは、あまり感心しません。
参加者のやらされ感が募る上に、「何か落としどころがあるな」と
勘ぐられ、抵抗力が生まれるからです。

これは本当にそう感じる。自由に意見をだしてくださいって言っておきながら、最後は自分の方向になんとか持っていこうとするのは本当に辞めてほしい。自分もそうならないように気をつけないと。。。

P79
気に入ったイラストがあったら、何度も練習してみてください。
使えそうなイラストを頭の中にストックしておいて、
これを使おうと決めたらスラスラと手が勝手に動くのが理想です。

せっかくの手書きなので、イラストは使わないとだね。
ちょっと練習しておこう。。。

P81
縦の論理と横の論理を意識しながら、話を聴きます。
縦の論理：前提〜根拠〜結論
横の論理：あるテーマに対する切り口

自分の中で何点か観点を用意すればいいということだ。マトリックスだとそれが横軸に表現されるので、マトリックス型の絵は書きやすいかも。

P86 
話し合いの進め方が気に食わなくて、反論ばかりする人もいれば、
自分の存在を認めて欲しくて過去の経験を語る人もいます。

確かにその通り。この一文がこの本で一番ズギュンと来た！
意見をする人の性格や欲求を考えることが１つの近道かもしれない。。。

P89
パーキングロットを使おう！
（テーマから外れた意見のときは）ホワイトボードや
模造紙の端などにスペースを取って、メモしておきます。

変なところで盛り上がるというのはあるので、こういうことを覚えておけばいいのかも。

感想

全体を通して見ると理論のところから、実際のやり方、そしてファシリテーターの思考の流れを書いた具体例もあって、分かりやすい本だと思う。
付箋を使ったり、A4用紙を使ったりと実践的なテクニックも乗っているので自分のやる気次第で明日から使えるはず。

自分がファシリテーターを好きじゃない理由

感想を書いていて、ファシリテーターがあまり好きじゃない理由がなんとなく分かった！今まで会った人の中には自分は知っているんだぞオーラを出したり、自分の落としどころに持っていこうというのが見え見えの人がいたからだと思う。
例えば上に書いたパーキングロットも名前を出さないで、ただ端に書けばいいのに、「これはパーキングロットと言って…」と説明を始める人がいたりする。正直ウザい。。。
反面教師としてそういう変な人にならないようにしようと強く誓った（笑