radioc@?

レディオキャットハテナ

【読書メモ】マイクロソフト伝説マネジャーの世界No1プレゼン術

マイクロソフト伝説マネジャーの 世界№1プレゼン術

マイクロソフト伝説マネジャーの 世界№1プレゼン術

ビッグワードなタイトルなので少し敬遠していたところがありましたが、読んでみると著者が考えるプレゼンの基本が丁寧に解説され、後半には応用的なテクニックまで紹介されていて学びの多い内容でした。

時間と空間の共有

本書で終始言われているのは、プレゼンは「時間と空間の共有」ということです。発表者と聴き手の、「お互いにとって貴重な時間と空間」を共有する場という前提のもとで、お互いにとって価値の高い時間と空間を作ることにフォーカスした内容になっています。そう考えると冒頭で著者が述べている「プレゼンの3つのゴール」は非常に納得のできるゴールだと言えます。

プレゼンの3つのゴール

  • 聴いた人がハッピーになる
  • 聴いた人から行動(決断)を引き出す
  • 聴いた内容を他人に言いふらしたくなる

ビジョンと核

3つのゴールに向けてまず重要なのが「ビジョン」と「核」です。

ビジョン

ビジョンは当然、3つのゴールへ誘導するものでなければなりません。プレゼン資料を作るうえでまずこれをはっきりさせることが重要だと著者は述べています。

  • 相手から相手からどんな行動を引き出したいか
  • 相手にとってハッピーな未来とはどういうものか
  • 聴いている人たちがいかに「自分事」として捉えてくれるか

ビジョンが明確になると次に「核」を作ります。核は次のように述べています。

プレゼンの根幹をなすメッセージ

つまり、プレゼンの内容を一言で説明できるメッセージが核です。

1つの章を割いて核を作るための考え方やテクニックがいくつか紹介されています。個人的には「あるあるを集めて否定する」が参考になりました。

あるあるを集めて否定する

プレゼンのビジョンの沿って課題となる「あるある」を集めてそれを否定する言葉を考えて核にするテクニックです。

本書では例としてグローバル人材になれない人の課題として次のような「あるある」を集めています。

  • ダラダラ残業
  • 会議に遅れる
  • 成長のチャレンジしない
  • 問題を先延ばしする

この「あるある」をまとめると、「時間の意識が低い」ことが課題だと言えるので、それを否定する「時間は有限だと意識し続けること」を核となるメッセージにします。

ハッピーな未来

ビジョンと核をつくるうえで重要なのが「ハッピーな未来」という部分です。3つのゴールにも通じるもので本書でも何度も出てくる言葉であり一番のキモです。別の場所でも著者が語っていてネットに記事があがっているので合わせて読むと理解が深まります。

logmi.jp

www.strategic-presentation.com

構成&スライドづくり

他の書籍でも述べられているようなテクニックが著者の観点で紹介されていますが、印象に残っているものをいくつかピックアップします。

ロジックエラーによって聴衆の心は離れる

主食と言えばご飯か、パンですよね

例として述べられているのは上記のような論理です。プレゼン者にとってはそうかもしれませんが、聴いている人が麺類などの反論をイメージしてしまうとロジックが成立しなくなって聴き手が興味を失ってしまうというものです。これは私自身も失敗の経験があり、難しい部分だと思います。著者も「なかなかのくせ者」と表現していますが、「聴衆目線のロジックになっているか」が重要であると述べています。

アジェンダは必要ない

アジェンダをつけるメリットは理解できるものの、冒頭の通り「時間と空間の共有」が重要な価値なので、アジェンダ通り進めることよりもその時その場のライブ感が重要だと述べています。ただし、「ビジョン・核・話し方という3つの話をしますよ」というような聴き手のイメージを喚起する演出の一部であれば問題ないとのことです。

また、アジェンダと同じ理由で「起承転結」も1つのテクニックであるものの必須要件ではないと述べています。個人的にはアウトラインを作る時に意識することが多いので新鮮な視点でした。

話し方の極意

この章も著者の経験に基づくテクニックがたくさん紹介されていて参考になりますが、特に印象深かったものを1つピックアップします。

導入が命!アイスブレイク

導入部分がうまくいかず、なかなか一体感やプレゼン特有のライブ感を作れないと、聴いている人たちもなんとなく所在なげになりますし、いつまで経っても話に集中することができません

LTレベルの勉強会では、アイスブレイクまできっちりやるのはなかなか難しいかもしれませんが、それでも導入部分の重要性は改めて感じました。最適なのは自己紹介にプラスアルファで1つぐらいネタを作っておくのがおすすめだと述べています。

最初から大きな笑いを狙いに行くと却って変な空気になり、プレゼンの進行に支障を来たします

これは私も感じたことがあります。アイスブレイクで意図せずウケてしまうとその後のスライドの説明のペースを乱してしまうことがあります。「ジョークは軽くで良い」とのことです。

人に教えることほど、勉強になることはない

巻末ではどうやって人に教えるかを考えることでプレゼンは上達できると述べています。上記のドラッカーの言葉が紹介されていますが、これはプレゼンに限らず理解を深めるために重要なことだと思います。

冒頭では誰かに話したくなることがプレゼンのゴールの1つだと述べられていました。つまりプレゼンは学びを提供するものであり、聴き手が理解を深めるために誰かに説明したくなるような意欲をもたせて終わることが1つのゴールと言えるのかもしれません。

【読書メモ】OKR

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKRは目標の設定・管理手法の1つです。現在Googleの取締役に就任しているジョン・ドーア氏がインテルに勤めていた頃に導入し、その後Googleに移ってGoogleにも取り入れ、現在ではシリコンバレーだけでなく日本の企業でも事例が増えているようです。Googleは働き方に関する取り組みを「re:Work」というサイトで公開していますが、そのサイトでもOKRについて詳しく紹介されています。

rework.withgoogle.com

目標と成果指標

OKRはObjectives and Key Resultsの頭文字を取ったもので、ObjectivesとKey Resultsで構成されます。基本的にはこのOとKRがOKRの全てです。

O:Objectives

  • 定性的なゴール
  • 1つだけ決める

以下の条件を満たすひとつの文にする

  • 定性的で人を鼓舞する内容にする
  • 時間的な縛りをつくる
  • 各チームが独立して実行できるようにする

KR:Key Results

  • Oを達成できたかどうか判定する定量的な指標
  • 3つぐらい決める

例えば以下のような測れるもの

  • 成長率
  • エンゲージメント
  • 売上
  • 性能
  • 品質

難しいが不可能ではないKRを設定する

自信度を1〜10としたときに5になる(できるかできないかは半々)ようなKRを設定するのが良いとされている。

OとKRで成果にフォーカスして短期サイクルでPDCAを回す

本書は2部構成になっていて、1部はあるシリコンバレーのスタートアップがOKRを導入する架空の物語で、2部がOKRの基礎知識の解説と、具体的な実装事例のコラムです。基本的には前述の通りOとKRが全てであり、いかにうまくOとKRに集中して取り組むがカギですが、その実装は使う側に委ねられています。そのために第1部の物語も含めて大半が事例の紹介にあてられているのだと思います。

やり遂げれない5つの理由

冒頭では「やりたいことがなぜ実現できないのか?」という問いから始まり、次の5つの理由があると述べています。OKRをうまく運用するためにはこの5つを意識してやり遂げるためのOとKRを設定しなければなりません。ここでつまずくと導入してもうまくいかないと思われます。

  1. ゴールに優先順位を付けていない
  2. 熱意を持って漏れなくゴールを伝えていない
  3. やり遂げるがめのプランがない
  4. 重要事項のための時間を空けていない
  5. 繰り返さずにやめてしまう

1週間サイクルでの実行例

OKRの実装の一例として毎週月曜にチェックイン・ミーティングを行い、金曜日に目標達成に向けた成果を確認するウィン・セッションを行うことが紹介されています。

チェックイン・ミーティング

4つの四角形に以下の項目を入れて毎週確認する方法が紹介されています。

  • 今週の優先事項
    • 目標達成に向けて直近でやる最も重要な仕事の内容をあげる
  • 今後4週間の予定
    • チームで共有しておく今後の予定を確認する
  • OKR自信度状況
    • 10段階の自信度が5になる目標を設定して、それがどう変化しているかを確認する
  • 健康・健全性指標
    • 目標に向けて取り組む中でもチームが守りたい健全性の指標(例えばテストコードのカバレッジを何%以上にするなど)を確認する

スクラムとOKR

文中でも少し触れられていますが、OKRという手法の根底にあるものはスクラム開発と似ています。チェックイン・ミーティングはスプリントプランニング、ウィン・セッションはスプリントレビューと同じ位置づけのイベントで、優先順位を付けて価値にフォーカスする点、シンプルなルールで実装が使う側に委ねられている点なども似ています。本文中でOKRは必ず1回は失敗すると書かれていますが、スクラムも慣れるまでは成果がでないとよく言われます。どちらも、競争の激しいシリコンバレーでビジネスの成果にフォーカスしてPDCAを回す試行錯誤の中で確立されてきた手法であることが覗えます。

企業でのOKR導入事例

日本でも実際にOKRを導入している企業の事例がいくつか見つかりますが、特にアジャイル開発プロセスと組み合わせて導入している企業が目に付きます。それぞれの現場で試行錯誤している状況も感じられます。

medium.com

logmi.jp

seleck.cc

goodpatch.com

個人からスタートする

企業の目標設定手法としてのOKRは手軽に実践できるものではありませんが、アジャイルなプラクティスと同様にまずは個人の取り組みに一部を取り入れてみる事例もいくつかみつかります。

note.mu

kths.hatenablog.com

巻末に及川卓也さんが解説を書かれていますが、その中でも個人的な目標達成にも大きな効果があることに触れられています。特に以下の2点でOKRが役立つと書かれています。

  • タスクの優先度が明確になる
  • 継続するためのモチベーションが維持できる

これらは近年よく見かけるPDCA系の本でも共通して重点が置かれていポイントだと思います。まずは個人からやってみるのも良いかもしれません。

Scrum Fest Osaka 2019 であきらめないスクラムの話をしました

www.scrumosaka.org

Scrum Fest Osaka 2019で登壇の機会を頂いて『あきらめないスクラム』というタイトルで発表してきました。「あきらめない」という、圧が強めのワードをタイトルに入れましたが、話したかったことは「スクラム失敗あるある」と「それでもあきらめずにちゃんとスクラムやってみよう」という2点だけです。

登壇の1ヶ月ほど前に別の勉強会でしーばさんにお会いする機会があったので、登壇までの準備の進め方を聞いてみたところ、当日までに何回も練習するし、スライドも何度か作り直すという話を聞いて、これはとんでもないところに登壇しようとしているな、と危機感を抱いたのを覚えています。実際に私も最初はもう少しライトに失敗あるあるを紹介する構成にしていましたが、2週間前に社内のメンバーに向けて練習してみたところ全然しっくり来なくてほぼ作り直しました。最終的に少しエモさを押し出しすぎたかなという反省はありますが、発表をエモくしたかったというよりは、スクラムを始めて我々と同じように悩んでいる人たちが自分たちの経験に置き換えてこのスライドを見た時に、最後には勇気を持ってもらえればという思いで作りました。基調公演で勇気と元気という言葉がキーワードとして出ていたので、イベントに向けて目指した方向性は間違っていなかったと思います(ちなみに基調公演はピアノの生演奏などもあり講演じゃなくて公演とのこと)。

その場で生まれるフェス感

今回のイベントはScrum Festという名前のとおり、独特のフェス感があって他のイベントでは得られない特別な経験ができました。

参加者ひとりひとりのフェス

懇親会で少しだけきょんさんと話をする機会があって、基調公演は「何が一番印象に残っていますか?」に答えられないようなものにしたかったという事を言われていました。基調公演にタイトルが無いのもそのためだと思います。参加者ひとりひとりがそれぞれの思いで作り上げるフェスにしたかったんだなと感じました。

その流れもあってか、自分自身の登壇でも不思議と気持ちを乗せすぎないようなブレーキがかかりました。前述のようにスクラムに挑戦している人たちそれぞれの経験に置き換えてほしいので、自分自身の経験発表会になってしまわないように、気持ちを込めすぎないように気をつけました。基調公演で会場の空気が自然とそういう流れになったようにも思いました。

説教というもう一つのフェス感

一方で1日目からアトラクタのコーチのみなさんによる「説教」というキーワードがもう一つの流れを生み出していました。特に説教を受けたわけではないのですが、コーチのみなさんそれぞれの本質を捉えたセッションが心にグサッときて説教を受けているように感じてしまう空気になっていました。これもまたフェス独特の空気感ではないでしょうか。

私の登壇の1つ前に登壇されたryuzeeさんには月に1回コーチに来ていただいていて、登壇直前でそわそわしながらryuzeeさんのセッションを聞いていました。

私も自然と説教というキーワードの流れに乗ってしまい、急遽以下のスライドを挟み込んでしまいました。

f:id:radiocat:20190224124648p:plain

ちなみに、「Rコーチ」にしたのもネタにしたかったからではなく、スクラムに挑戦している人たちそれぞれの経験に置き換えてほしいからです。

f:id:radiocat:20190224120121p:plain

スライドの中でコーチから受けた指摘を紹介しましたが、これは我々チームの未熟さ故のものです。コーチをされている別の人にも「あれはみんな指摘する」と言われましたが、今となってはまさにその通りだと思います。

なので、「とあるコーチからの指摘」という説明で充分で、知っている人だけryuzeeさんのことだと分かれば良いと思い、絵の趣味を持つ後輩にryuzeeさんの似顔絵を書いてもらってさり気なく載せるつもりでしたが、結果的には似すぎてバレバレでした(笑)。しかも事前にこの絵をryuzeeさんにお見せしたところ気に入って頂いてご本人のスライドにも載せて頂いてびっくりしました。

f:id:radiocat:20190224121314p:plain

そういう流れで急遽スライドを挟み込むことにしました。当初の目論見とは変わってしまいましたが、公開している資料は当初の目論見のまま挟み込んだスライドは載せていません。これもフェスっぽくて良かったのではと思います。

なお、コーチに来てしていただいているryuzeeさんは普段は何でも親身に相談に乗ってくださる気さくなかたです。我々が未熟なために本質的な部分でよくご指摘をいただきますが、決していつも説教を受けているわけではありません(笑)

最高のフェスでした!

個人的にはまず、スクラム1年目という二度と訪れることのないチームの経験を登壇に活かせたことが最高でした。そのうえで登壇前にそわそわしながらもたくさんの貴重なセッションを聞き、参加者の人たちと交流し、フェスの場でしか得られない学びをたくさん得られました。自分がこの規模の登壇が初めてだったので緊張しすぎて心に余裕がなく、もうひとりの基調公演スピーカーの及部さんや他の登壇者のかたなど、一部の人と話ができなかったことが心残りですが、これはまた次の機会のTryにしたいと思います。

【勉強会メモ】心理的安全性ゲームを体験してみる

devlove-kansai.doorkeeper.jp

いつもお世話になっているDevLove関西で心理的安全性ゲームを体験する勉強会が開催されました。SFO2019 開催前日で私も登壇準備でそわそわしていましたが、考案者のやっとむさんを招いて開催されるとのことだったので参加してきました。

心理的安全性ゲームとは?

チームでまずい状況が起きた時のメンバーの反応をシュミレーションするカードゲームです。

心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

ゲームの進め方

スライドが公開されていますので詳細はそちらを確認。

docs.google.com

実際にやってみた流れをざっとまとめておきます。

チームを作る

4,5人のチームを作ります。仕事上のチームと仮定して仕事のテーマを決めます。

f:id:radiocat:20190222005719p:plain

カードの準備

2種類のカードがあります。どちらも事前にシャッフルしておきます。発言カードの中にはさらに発言とOptionの2種類のカードがありますが混ぜてシャッフルします。

  • 発言カード
    • 1人にチームの人数分のカードを配る(4人のチームであれば1人4枚)
    • 余ったカードは山を作ってテーブルに置く
  • 状況カード
    • 山を作ってテーブルに置く

まずい状況を発生させる

  • 「平和を乱す役」の担当を決めて状況カードを1枚引く
  • 引いたカードをその状況の人になりきって読み上げる

まずい状況に反応する

  • 残りのメンバーが自分の手持ちの発言カードの中から1枚のカードを選んで反応する
  • 手持ちのカードの中にOptionカードがある場合は発言と一緒に出すことができる
    • Optionには態度が書いてあり、発言に合わせた態度をとりながら反応する
  • Optionカードを使った場合は残っている発言カードの山から1枚取って手持ちに追加する

未来のチームのすがたを想像する

  • 「平和を乱す役」の人は全員の反応を聞いたうえで自分がどう感じたかを共有する
  • 「平和を乱す役」の人は自分が感じた「未来のチームのすがた」の該当する場所に石を置く(該当するものすべてに石を置いて良い)

隣の人に担当を交代して繰り返す

  • 「平和を乱す役」の担当を隣の人に交代して同じことを行う
  • 時計回りで1周するまで続ける

やってみた

私は「大事なアポをすっ飛ばしちゃった!」という状況カードを引きました。なかなかひどい反応を頂きました。。

f:id:radiocat:20190222010444p:plain

交代して進めていくと徐々に気の利いた反応が返せるようになりました。しかし、手持ちの発言カードは限られているのでいつでも良い反応が返せるわけでもありませんでした。一見、良さそうな発言カードを持っていても起きた状況によっては出しにくい場合もあります。

f:id:radiocat:20190222010704p:plain

アレンジしてやってみた

2回目はチームのメンバーそれぞれにキャラ設定をしてその人になりきってやってみました。「やり手の営業マン」とか「豪腕社長」とか何でもOKです。私は「陽気なおかあさん」キャラをやってみました。また、発言カードも意図的に気の利いた良さそうな発言ばかりを配ってみました。

おかあさんキャラだと意外とどんな発言カードでもなんとなく優しさを感じて発言だけでなくキャラによっても反応は変わってくることがわかりました。

一方、気の利いた良さそうな発言でも、キャラや状況によってはあまり良い反応にはならないこともわかりました。

f:id:radiocat:20190222011538p:plain

最後にふりかえり

最後にこのゲームを通しての心理的安全性についての学びを会場の全員で共有し合って終わりました。思いついたすべてを付箋に書いて壁に貼り、最後にその中から一番印象に残ったものを1つ選びました。私が選んだのは「母強し」です。

f:id:radiocat:20190222012741p:plain

補足:サイレントソーティング

最後に全員分の付箋を壁に貼った時に、類似のものはグルーピングして並び替えを行いました。この時に使った手法が「サイレントソーティング」と言うらしく、黙って一人ずつ交代で、1枚だけ付箋を選んで移動させていきました。みんなで同時にやると議論になって収集がつかなくなるのを避けるやりかたなのだと思います。わりとスムーズに並び替えが終わって、どこかで使えそうな手法だと感じました。

f:id:radiocat:20190222000945p:plain

【勉強会メモ】Mobile Act OSAKA #8

mobileact.connpass.com

  • 日時:2019/02/15(金) 18:40 〜 21:30
  • 場所:Osaka Innovation Hub (大阪イノベーションハブ)

いつもお世話になっているフェンリルさんのMobile Actです。懇親会でのビールのこだわりが最高です。

How I develop Sketch Native Plugin

griffin_stewie さん

speakerdeck.com

遅刻して聞けなかったので資料のみです。

ReactorKitでテストしやすくする

usami-k さん

speakerdeck.com

github.com

Testabilityに注目

  • Viewの責務
    • UI操作→ActionとしてReactorに渡す
  • Reactorの責務
    • Action→処理を行いStateを生成する
  • Viewの責務
    • State→UIに表示する

View

Reactorの処理

mutate()

  • Actionを受け取ってMutationを返す
  • 具体的な処理を行うObservableを生成
  • 実際に処理を行うかどうかの判断などはReactor
  • Viewがシンプルになる

reduce()

  • Mutaitonと前のStateを受け取ってStateを返す
  • View側では前の状態を考慮しなくて良い

Viewの単体テストを考える

「オブジェクトの責務を果たしているか」をテスト

  • UI操作⇒Action
  • State⇒UI表示

Actionのテスト

  • コードでUI操作を発生
  • ReactorにActionオブジェクトを渡されたことを確認
  • Reactorのスタブを用意
    • ReactorKitで用意されている

Stateのテスト

  • やはりReactorのスタブ

Viewのテストまとめ

  • Viewが責務を果たしている
  • Viewの実装としてはバインディングがちゃんとできている
  • Testability向上でシンプルになった結果単純すぎてテスト不要ではというレベル

Reactorの単体テスト

  • そのオブジェクトの責務を果たしているか
  • コードでActionを発生させてStateをテスト
  • Reactorの中でWebAPI実行
  • データベースアクセスなどがあると単体テストしにくい
  • Serviceとして外に切り出してスタブ化

まとめ

  • ReactorKitでViewとReactorの責務を分離
  • ViewやReactorのテストが可能

学生スタートアップがマイクロビューコントローラーを導入してみた話

nade さん

speakerdeck.com

背景

  • iOS開発2名、デザイナ1名
  • とにかくスピード感がほしい
  • 非同期作業
  • スクラップ&ビルド

数日後⇒大規模なリファクタリング

  • UIを追加しづらくなる
  • 勉強&教育コスト

Fat View Contorllerの闇に落ちていく

→巨人の方の上に乗る

MicroViewController

github.com

UIパーツそれぞれをViewControllerで作ってしまう

ViewControllerに3つのプロトコル

ContainerViewで実装

  • ライフサイクル・画面遷移コードが分割
  • レイアウト時間が短縮
  • クロスアーキテクチャで実装可能

恩恵

  • 開発速度:体感3倍
  • 1ViewControllerのコード:500くらいまで
  • パフォーマンス向上

iOS/Androidでドキュメントスキャナーを作ってみた

itok さん

speakerdeck.com

PDFカメラ

  • カメラで書類を撮影
  • 撮影した写真から切り抜く範囲を調整
  • 必要があれば回転
  • 1〜3ページ分繰り返して最後に画質を指定してPDFとして書き出す

技術要素

  • 矩形認識
  • 矩形切り抜き
  • PDF書き出し

矩形認識

  • カメラプレビュー表示
  • リアルタイムで認識された矩形を重ねて表示
  • 検出された矩形の中で一番大きなものを採用
  • 撮影ボタン→画像

Android

iOS

  • AVKit framework
  • Vision framework

矩形切り抜き

  • ユーザー操作で切り抜き部分を調整
  • 切り抜き+台形補正

Android

iOS

  • CoreImage framework

PDF書き出し

  • 指定された画質で書き出す
  • A4orレターサイズに収まる感じのサイズに調整
    • 北米はレターサイズ
    • それ以外はA4

Android

  • Apache PDFBox
  • 標準のPDF APIは画像の圧縮が効かなかった

iOS

  • UIGraphicsBeginPDFContextToFile
  • UIGraphicsBeginPDFPageWi

雑感

  • 矩形認識はiOSVisionが圧倒的に楽で早い
  • カメラの向き変換が相変わらず面倒
  • カメラプレビュー、撮影画像、UI間の座標変換も相変わらず面倒

Material Themingを使ってみよう

Kazuki Watanabe さん

speakerdeck.com

Material Designとは

Material Theming

  • Material Designをカスタマイズしてアプリの個性や世界観を出す
  • 属性(Color,Shape,Typography)を決めることでプロジェクトのテーマが作れる

Color

Shape

  • 角を切ったり丸めたりした形

Typography

  • H1,H2,H3,H4...

Material Design

Color Themingの適用

  • <color>

Shape Themingの適用

  • Small Components
  • Medium COmponents
  • Large Components

Typography Themingの適用

  • フォントの適用

最後に

  • 表現できる幅が広がった
  • AndroidだけでなくiOS、Flutter、Webでも利用できる
  • たくさんのUI Componentsが利用できる

Managed App Configuration について 〜MDMiOSアプリ設定の配信〜

oishi さん

  • Managed App Configuration
  • MDM(Mobile Device Management)

クラウド型サービス

  • 設定を流せる
  • アプリを消しても入れ直す
  • アプリの中の設定は配信できなかった

App Storeのアプリやインハウスアプリを登録

暗号化されないのでパスワードなどは設定しないように

イテレーションとRustで見るSwiftの所有権

hokuron さん

speakerdeck.com

Ownership Manifest

  • 所有権に関する提案や考察
  • 実装の優先順位
  • 今後仕様が変わることもある

イテレーションにおける所有権

  1. 不変イテレーション
  2. 可変イテレーション
  3. 消費イテレーション

不変イテレーション

  • イテレーションの中で要素を変更しない
  • 要素の取り出しにコピーが発生しない
  • Arrayなど内部にストレージを持つ型はイテレーションの中でArrayそのものを変更できない

可変イテレーション

  • イテレーションの中で要素を変更可能
  • 要素の取り出しにコピー不要
  • Arrayの場合排他アクセスが発生
  • Arrayにアクセスができない
  • NSArrayなどの参照型Arrayには適用されない

Rustにおける共有参照・可変参照

  • 共有参照
    • 共有参照としての借用が終わるまで可変操作(借用)ができない
    • 参照中にもとの値が変更されないことを保証
    • 安全
  • 可変参照
    • 可変参照としての借用が終わるまで別の借用ができない
    • 変更中の値が使われないことの保証
    • 安全

消費イテレーション

  • for in →いつものイテレーション
  • non-copyable型から要素の所有権を得る
  • Sequence protocol
    • 破壊的な消費をしながらのイテレーション
    • 1度目とそれ以降が同じになるとは限らない

Rustにおける消費イテレーション

まとめ

不変イテレーション

  • 変数を shared で宣言
  • nonmutaiting な操作
  • 可変操作ができない
  • Rustは安全

可変イテレーション

  • inout で宣言
  • ループ中でコレクションにアクセスできない
  • Rustは安全

消費イテレーション

  • 変数をownedで宣言
  • Rustは安全

まとめ

  • Rustは安全