寄付窓口はこちら

魔法の法則 | try! Swift Tokyo 2019 2-1

SFとファンタジー小説にインスパイアされたルールに従って、知的で没入型の体験を開発することを学びます。ソフトウェアと同様に、複雑で魅力的な魔法のシステムもガイドラインを使用して具体的なユーザー体験を構築します。この講演では、架空の世界構築をサポートするいくつかの思索的な法則を探り、これらの教訓を日々のアプリとコード開発に組み込んで同じ結果を生み出す方法を説明します。

f:id:niwatako:20190322100956j:plain

魔法について話すにあたってこの人を紹介したいと思います。ブランドン・サンダースン

時の車輪という本が有名。著者が亡くなった後に完成させた。自身の本でも著名。

47以上の作品

少なくとも40冊認める予定とのこと

f:id:niwatako:20190322101200j:plain

私の家の数マイル先に住んでいます。

実際この本の中には日本語になっているものもあります、ぜひ読んでみてください

f:id:niwatako:20190322101229j:plain

かれは3つの法則を発表した

f:id:niwatako:20190322101234j:plain

読者に面白くあり続けるために常に従っている

でもなぜ魔法の話?

f:id:niwatako:20190322101257j:plain

十分に高度な技術は魔法と区別がつかない

f:id:niwatako:20190322101311j:plain

スマホも魔法です。iPhoneはシリコンと金属とミネラルを適切にまとめることで出来ています。

魔法です

f:id:niwatako:20190322101349j:plain

我々が各コードもそうです。

f:id:niwatako:20190322101355j:plain

CPUは石。内部でいろいろな刺激を与えることでロジックを入れ込んでいる

我々がフレームワークを書くと、他のデベロッパーへの魔法を入れ込んでいる。

アプリケーションを作るとユーザーにとっての魔法に成る

f:id:niwatako:20190322101438j:plain

第一法則から見ていきましょう

f:id:niwatako:20190322101442j:plain

f:id:niwatako:20190322101456j:plain

長く複雑な文章ですがよく理解すると、もし魔法を使うなら、そしてその魔法で問題を解決するなら、ユーザーも同機能するか理解しないと、皆さんの解決策ではハッピーにならない、ということを行っている。

ユーザーにハッピーになってもらうには、何が起きているか理解できる必要がある。

作者として責任がある。何が起きているのか伝える必要がある。その一部として我々は、ユーザーがどんな仕事を実行したいと思っているのか、どんな質問を掲げているか想定する必要があり、われわれはフレームワーク、アプリにガイドとしてそれを組み込んでいく。

f:id:niwatako:20190322101629j:plain

もし過ちを犯したらそれを許すことも必要。

Swiftには型システムがあり、型安全を担保する。然るべき方法で使ってもらうことを担保する。馴染みのあるパターンを使っていく。ユーザーは魔法を理解する上でそんなにたくさんのことを教育される必要はない。理解する上で診断やエラーメッセージも使える

f:id:niwatako:20190322101728j:plain

完全なるドキュメンテーションユニットテストでよりたくさんの方法でユーザーは学べる。

ライブラリを書くときは我々としてユーザーがどうやって、一見正しそうな方法で間違って使うことも想定しなければなりません。

f:id:niwatako:20190322101859j:plain

エラーでこういうやり方ではダメだと伝えることもあるかと思います。そこから学ぶには、実際に動かしてクラッシュさせる必要がある。

f:id:niwatako:20190322101908j:plain

そこまでではなくて、利用可とか書いて、ユーザーが書いている最中に、これは利用不能とマーキングすることで、知らせる、コンパイラが阻止することができる

f:id:niwatako:20190322101918j:plain

Xcodeではこうです

f:id:niwatako:20190322101928j:plain

変わりの変更を申し出ることができる。エラーメッセージで利用者を教育することができる。

同様に

f:id:niwatako:20190322101949j:plain

包括的で完璧なドキュメンテーションを提供することで理解できるようにする

f:id:niwatako:20190322101955j:plain

第二法則

f:id:niwatako:20190322102019j:plain

制限は権力より重要

f:id:niwatako:20190322102026j:plain

通常は何が出来ないかを知ったほうが、何ができるかを知るよりも面白い。もし本当に楽しい、素晴らしい物語をフィクションの世界で見ると、ほとんどの葛藤は、ストーリーの中では、どういう登場人物の制約があるかということに集中するものです。

スーパーマンは、彼が空を飛んだり目からレーザーが出るとか体力があることで面白いのではない。

クリプトナイト?というものがある、彼は脆弱で弱い、それが面白い。ストーリーはその制限に集中して取り上げる。

f:id:niwatako:20190322102155j:plain

制約は創造性を掻き立てる。

そしてアプリケーションを角にあたって様々な種類の制約に直面します。時間、人数、能力、どういうフィーチャーを実現しなければならないか。こういうような制約をもとに選択をしなければならない。コードは我々の能力そのものよりも制約を反映したものになっている。

コードを書くにあたって自問自答しなければならないのはどういう制約でパターンに従い、どのようなフィーチャーを省かなくてはならないのか。

問題につまずいた際には、創造性を発揮して人工的に制約を加えることで乗り越えられる。場合によっては考えられなかった選択肢が浮上したりする。

f:id:niwatako:20190322102345j:plain

第三法則

f:id:niwatako:20190322102350j:plain

いろいろなものに対してワクワクするのは、我々がもっと発見するものが多いということをわかった際です。だからこそこのような会議が存在しています。

そのようなワクワク感は他の人達が絶対見つけていないだろうものを自分が見つけ出すことが出来、全体像の中ではうまく適用できるものを見つけられるわけです。一見単純に見えるものが、実は非常に深く、複雑性があり、ニュアンスの多いものだということを発見して、美しさ、喜びを見出すことができる。一見単純で奥深いものを発見して面白いものです。

ブランドン・サンダースンの中で面白いのは、「常に別の秘密があります」と行っています。

フレームワークを構築する際に気をつけなくてはいけないのは、より多くのものを発見するようにすることで、ユーザーにより楽しい体験を提供できる

f:id:niwatako:20190322102553j:plain

簡単に実現できるものではなく、時間とともに実現できる。リファクタリングや整理で実現する。

どういうしなりおを検討していなかったか、同検討できるか。フィーチャーとしてサポートしていないものがあり、今後サポートしうるものがあるかどうか。常に奥行きを加えることで、確実にユーザーを喜ばせることができる。

f:id:niwatako:20190322102653j:plain

以下が3つの法則です

f:id:niwatako:20190322102717j:plain

すべては0から始まるものです。3つの法則に従って行動すれば偶然に、魔法の0番目の法則にたどり着きます、すなわち、素晴らしいものにするということです。

f:id:niwatako:20190322102812j:plain

f:id:niwatako:20190322102816j:plain