アナログ金木犀

つれづれなるまままにつれづれする

プログミラング中にフロー状態になるには

kgmyshinです。今年はまだ一度もブログ書いていことに気付き、久しぶりに書いてみました。

今回の記事は、そういえば最近いわゆるフロー状態になることがないなとふと思い、そもそもフロー状態とは何?というところから始め、現状の課題と打ち手を考えてみました。

早速。

フローとは

wikiより。

フローとは、人間がそのときしていることに、完全に浸り、精力的に集中している感覚に特徴付けられ、完全にのめりこんでいて、その過程が活発さにおいて成功しているような活動における、精神的な状態をいう。ZONE、ピークエクスペリエンスとも呼ばれる。
チクセントミハイが見たところによれば、明確に列挙することができるフロー体験の構成要素が存在する。彼は8つ挙げている

1. 明確な目的(予想と法則が認識できる)
2. 専念と集中、注意力の限定された分野への高度な集中。(活動に従事する人が、それに深く集中し探求する機会を持つ)
3. 自己に対する意識の感覚の低下、活動と意識の融合。
4. 時間感覚のゆがみ - 時間への我々の主体的な経験の変更
5. 直接的で即座な反応(活動の過程における成功と失敗が明確で、行動が必要に応じて調節される)
6. 能力の水準と難易度とのバランス(活動が易しすぎず、難しすぎない)
7. 状況や活動を自分で制御している感覚。
8. 活動に本質的な価値がある、だから活動が苦にならない。

フローを経験するためにこれら要素のすべてが必要というわけではない。
フローに入るためのもう一つの重要な条件に、他者に妨害されない環境がある。

フロー状態に入るための条件

構成要素を見ると条件のようなものだったり、フロー状態に入ったあとの結果のようなものだったりが混じっているので、自分なりに条件だと思うものを抽出し、またなぜか別途重要とされているものも同列にしてみました。

  • 明確な目的を持っていること
  • 簡単すぎず難しくない事柄であること
  • 活動が苦にならないような事柄であること
  • 他者に妨害されない環境であること

いまの自分と照らし合わせてみる

「気付いたら数時間経っていた」という経験はそれなりにあります。高校の頃に数学の問題をひたすら解いていた時だったり、最近ではやっぱりプログミラングしている時だったり。

ただ、冒頭にも書きましたがここ数ヶ月はあまりそういうことがありませんでした。

集中がふっと切れたり、そもそものっけから集中できなかったりした時のことを思い出してみると、確かに上記の条件を満たせていないことに気づきます。

難しいなと感じることがある

「これはどうしよう、少し悩むな」という時、集中が途切れることがありました。悩み考えることは悪いことではないですが、途中に何度もそれに遭遇すると生産性が下がっていると感じます。

活動が苦になることがしばしばある

プログラミングしている最中に、すでにある品質の良くないコードにぶち当たった時に集中が途切れることがしばしばありました。 偶発的に不快になってしまったこと、それを自分が修正せねばならないということに苦痛を感じていました。

他者に妨害される環境にいる

やはり各種さまざまな通知によって、やっていることから意識が外れて集中が持続しないなということは実感していました。またこれは人に依るものではありませんが、ビルドに数分かかった時に意識がそれてしまい集中がもたないこともよくありました。

打ち手

「難しいなと感じることがある」に対する打ち手

  • 常日頃「難しい」と感じることがなくなるくらいに勉強する
  • 「難しいな」という感じることはあらかじめつぶしておく

常日頃の勉強はもちろんそうですが、限界はあります。そのため、作業を始める前に「難しそう」な所には当たりをつけて高い壁のみあらかじめ取り除いておくと良さそうです。そうすることで、集中がこまめに切れることはなくなるはず。

「活動が苦になることがしばしばある」に対する打ち手

  • 品質の良くないコードを書かない/書かせない
  • 作業前にあらかじめ当たりをつけておく

先の打ち手と似ています。理想を言えばそもそも「品質の良くないコード」に遭遇する状況をなくすことですが、チーム開発をしている以上全てをコントロールできないことがほとんどです。そのため、こちらも先と同様に作業前にあらかじめ当たりをつけておき偶発的な遭遇が作業中に起こらないようにします。

「他者に妨害される環境にいる」に対する打ち手

  • チャットツールなどの通知系を全て切る(緊急性のある通知はモバイルのみからにする)
  • 作業時は他者のいない環境で行う
  • コミュニケーションの必要な事柄は作業前にあらかじめつぶしておく

徹底的に必要なコミュニケーションはコントロールできる限り作業前にやっておきます。そうすることで集中は阻害されなくなります。

残課題

他者に妨害される環境の一因であるビルドの遅さ

これに関してはまだ課題としてあり、良い打ち手をまだ思いついておりません。何か良い方法あれば教えてください。。

最後に

打ち手をまとめると、作業前に入る前にいかに「集中を阻害するものを取り除くか」ということにかかっていました。

ひとまずはこれでやってみて、また課題が出てきそうであれば定期的に見直していきたいと思います。残課題に関しても良い打ち手が見つかれば紹介します。

総集編はもういやだ

こんにちは、kgmyshinです。

この記事は SHIROBAKO Advent Calendar 2015 - Adventar 24日目の記事です。

本来であれば「渡辺隼という男」というタイトルで記事を書く予定だったのですが、気づけば前日でしかも内容が全く決まっておらず、納品に間に合いませんでした。

ということで、非常に残念ですが 総集編 のお時間です。

今回のSHIROBAKOアドベントカレンダーを総集編という形で、それぞれの記事にどんなことが書いてあったかを振り返ってみたいと思います。20記事以上あるので一言くらい僕の感想をば。

1日目 「ロロの何が俺の心を震わせるのか」 by konifarさん

「ロロ」が大好きなkonifarさんの、そもそも「どこが好きなんだっけ?」を深堀りした記事でした。MADを見てキャラ設定は重要ではないという切り分けと結論の仕方がなるほどなと思いました。あとロロの見た目についてのくだりの細かさのところでは吹いてしました。愛に溢れた記事でしたね。

2日目 「マスクとエマと私と」 by kgmyshin(私)

これは私の記事です。マスクをかける絵麻ちゃんのシーンにフォーカスした記事でした。絵麻ちゃんは天使そのものでしたね。

3日目 「SHIROBAKOの公式イベントに参加して誓ったこと」 byMinori Takechiさん

アニメのイベントという視点の記事です。「SHIROBAKOオールナイト上映会」と「SHIROBAKO秋祭り」に出ての感想、メリットなどを書かれております。そして、その後の意識の変化があったのも面白かったです。

4日目 「ものづくりへの強いこだわりを持つエンジニアが見たSHIROBAKO」 by Yota Ishidaさん

エンジニアなら誰もが思うだろう「アニメーターとエンジニアの類似性」。体験談を交えつつ、またSHIROBAKOをみてどういう影響を受けて仕事への姿勢が変わったかについての記事でした。仕事へいい影響を与えるアニメって最高じゃないですか。

5日目 「りーちゃんの強さと魅力について!!!」 by shanonimさん

ひたすらりーちゃんの魅力についての記事でした。〈夢が叶わないことに対する焦りや恐怖が、前向きな行動の一番のモチベーションになっている〉というのは確かにそうかもしれないとうなづいてしまいました。

6日目 「2つの視点から見える井口祐未と安原絵麻の関係について」 by mizukmbさん

SHIROBAKOではいろんな人間関係を描いていますが、この記事では「井口祐未と安原絵麻の先輩後輩関係」をピックアップしています。関係をみて『尊い…』 というのセリフがでるの新しい。

7日目 「みーちゃんから学ぶ新人ソフトウェアエンジニアの心得」 by khrtzさん

みーちゃんに焦点を当て、みーちゃんと筆者との共通点についての記事でした。「僕は才能というのは、まずチャンスを掴む握力と失敗から学べる冷静さだと思う。」という名言最高です。

8日目 「SHIROBAKOに学ぶ『なぜステークホルダーを巻き込むべきなのか?』」 by 原田敦さん

SHIROBAKO内でのステークホルダーを巻き込んだことによってどう生産性が変わるのか?というお話でした。mofmofさん、マジで頑張って欲しいです。

9日目 「SHIROBAKOで気になったことを書く」 by bakuonboogieさん

SHIROBAKOの良さの一つ「声」にフォーカスした記事でした。たくさん生まれるベテラン勢や先輩たちの名台詞を支える声優さん、最高でしたね。

10日目 「Web系の会社に新卒入社する直前に見たSHIROBAKOが僕にもたらした影響」 by stefafafanさん

SHIROBAKOでの仕事の前向きさの記事でした。夢がかなったら、そこで終わりではなく始まりなんですよね。

11日目 「みんなの心の中のミムジー & ロロ」 by tomzohさん

自分の中にミムジーとロロいるかい?といった少し他にはない視点の記事でした。ロロ好きは視点が奇抜です面白いですね。

12日目 「杉江さんと私 」 by KeithYokomaさん

SHIROBAKOには多くのかっこいいベテランが出てくるのですがその中でも杉江さんフォーカスの記事。経験があるから一つ一つのセリフの重みがすごいんですよね。愛に溢れた記事でした。

13日目 「どんどんLED」 bymika.fukushige.9さん

ArduinoとLEDで"ドンドン"と表示させようとしたが...!という記事でした。インフルエンザで大変だったのに記事を仕上げるなんて、、愛ですね。

14日目 「エンジニアとデザイナーみんなでSHIROBAKO鑑賞会したよ。IT業界(SIer)とアニメ業界の構造の類似点をふりかえり」 by 柿本匡章@karamage

鑑賞会をおこなったよ!という記事でした。見ただけでなく、その後に類似点などをみんなで感想を言い合う会を開いてて羨ましい限りや。

15日目 「Don-Don-Donuts! Let's go nuts!」 by shaunkawanoさん

自分にインタビューをするという自問自答のおしゃれにした感じの記事でした。Don-Don Donuts Let's go nuts!!

16日目 「影の主役・平岡くん」 by seisonshiさん

平岡くんにフォーカスを当てた記事でした。誰か一人は書いて欲しいなと思ってたのですごく満足しています。彼の登場でアニメがよりリアルになりましたよね。

17日目 「SHIROBAKOみてアニメーション作る人たちに感動したので各職種の給料をみて俺らで支えていこう」 by hahirusanさん

年収グラフが面白かった。が、えまちゃん...俺が養いたい!!!!...取り乱しました。好きなアニメーターさんの同人誌とか買おうぜ!ってのはすごくよく分かる。これからは声優さんだけじゃなくて、アニメーターさんにフォーカス当ててくのも良さそうです。

18日目 「何を伝えたかったんだと思う?」 by shihochandesuさん

筆者さんの印象に残ったセリフ・シーンのピックアップな記事でした。他のアニメだとセリフピックアップって結構被るんですが、SHIROBAKOだと多すぎて「あぁ、そういうの確かにあった!確かにすごいよかった!」となって結構他の方のピックアップは発見があります。

19日目 「何に救われたんだと思う?」 by chocodoughnutさん

仕事へのスタンスの記事でした。 SHIROBAKOにはたくさんの仕事への向き合い方がありました。それを見ての筆者さんの心境の変化のお話です。

20日目 「松亭活動報告2015」 by jitsuzonさん

SHIROBAKO内ではずかちゃんが働いていることになっている、実在するお店「松亭」の記事でした。自分もこれでもかと通い詰めてるのですが、記事見ると「なるほどな」という発見もありました。しかし、女子がいるなってところに目がいきますね。

21日目 「タイヤ職人に姿を重ねるコンテンツを作るとは」 by okb_mさん

ものづくりや職場に何をもとめるかというお話。みーちゃんの葛藤からの転職という話は、転職を体験した多くの人にささるのかもしれないですね。

22日目 「やりたいことが見つかっちゃうと悩むよねっていう話」 by Takafumi Harimaさん

やりたいこととそれに対する各主要キャラのスタンスについてまとまったお話でした。図がわかりやすすぎる。

23日目 「松亭のおすすめグルメ」 by shanonimさん

shanonimさんとkonifarさんとよく松亭に行くのですが、その際に美味しかったものをまとめてくれました。みただけでもう松亭行きたくなるわ。エビフライ食いたい。美少年飲みたい。

まとめ

ということで以上総集編でした。どれもこれも正直重いくらいの愛に溢れた記事でした! このアドベントカレンダー、はじめは完走できるかどうか不安だったけど、ついにここまできましたね!明日はとうとう最終回!楽しみです!

Kotlinでjarを作って逆コンパイルしてみて、どんなjavaになるのか見てみた

こんにちは、@kgmyshinです。

この記事はKotlin Advent Calendar 2015の15日目の記事です。

早速。

KotlinにはExtensionという機能があります。

fun String.foo() { println("foooooooooooooooooooo") }

こう定義すると、本来Stringクラスにないfoo()という関数を追加することができます。

"kgmyshin ".foo()
// foooooooooooooooooooo

これは本来のJavaにはない機能ですが、jvmで動いている以上はjvmのオペコードに落ちているはずです。 落ちているはずなのですが、それがどのようになっているのか、Javaにはない機能をコンパイラがどう解釈しているのかということがが少し気になっていました。

そして、先日会社のブログで

[Java]〈Hello World〉をバイナリエディタだけで使って出力させてみた – NET BIZ DIV. TECH BLOG

を執筆して以降、コンパイラの理解への欲が高まり、その気持ちはさらに強くなりました。

ということで、早速 コンパイラのソースを見てみたけど時間かかりそうだったのでそれはやめてコンパイルしてできたjarファイルをjavaファイルに逆コンパイルしてみました。

手順

この手順でktファイルをjavaファイルにします。

  1. コンパイルする kotlinc hello.kt -include-runtime -d hello.jar
  2. できたhello.jarからclassファイルを取り出す jar -xvf hello.jar
  3. classファイルを逆コンパイルする。jad -s java -d src -r **/*.class

.kt -> .jar -> .class -> .java という流れ

オペコードが見れれば良いじゃん、javapコマンドの出力見るだけで良いじゃんって意見が聞こえてきそうで、またそれは確かに正しいのですが、こちらの方が多くの人が見やすいと思うのでこの手順を選びました。

あと、kotlinc-jvm hello.ktでそのままclassファイルでもよかったのですが、-include-runtimeの挙動もみたかったのでこの手順で実行しました。

検証

Hello, World!

まずは簡単なところから。

fun main(args: Array<String>) {
    println("Hello, World!")
}

これをjavaにすると該当部分はこうなります。

import kotlin.io.ConsoleKt;
import kotlin.jvm.internal.Intrinsics;

public final class HelloKt
{

    public static final void main(String args[])
    {
        Intrinsics.checkParameterIsNotNull(args, "args");
        ConsoleKt.println("Hello, World!");
    }
}

そして、このクラスだけではなくjar内にはkotlinのruntimeも含まれています。これが-include-runtimeの結果っぽいですね。

f:id:kgmyshin:20151123163323p:plain

javaで同じコードを書いてjarにすると760Bとなるのに対して、上記のKotlinで作ったjarが895Kなので基本的にKotlinを使うと + 900K弱くらい(runtime分)のサイズになるってのは把握しておいたほうがよさそうです。

Extension

適当にこういう感じのコードを書いてみます。


class C

fun C.foo() { println("Fooooooooooooooooooooooo") }

fun String.hoo() { println("Hooooooooooooooooooooo") }

fun main(args: Array<String>) {
    C().foo()
    "fuuuuu".hoo()
}

自分で作ったCというクラスにメソッドを追加した場合と、もともとあるStringクラスにメソッドを追加した場合をみたかったのでこういう形にしました。

早速javaファイルをみてみます。結果は、C.javaとHelloKt.javaが生成されました。

C.java

public final class C
{
    public C()
    {
    }
}

HelloKt.java

import kotlin.io.ConsoleKt;
import kotlin.jvm.internal.Intrinsics;

public final class HelloKt
{

    public static final void foo(C $receiver)
    {
        Intrinsics.checkParameterIsNotNull($receiver, "$receiver");
        ConsoleKt.println("Fooooooooooooooooooooooo");
    }

    public static final void hoo(String $receiver)
    {
        Intrinsics.checkParameterIsNotNull($receiver, "$receiver");
        ConsoleKt.println("Hooooooooooooooooooooo");
    }

    public static final void main(String args[])
    {
        Intrinsics.checkParameterIsNotNull(args, "args");
        foo(new C());
        hoo("fuuuuu");
    }
}

肝心の拡張されたメソッドはstatic関数になることが確認できました

    public static final void foo(C $receiver)
    {
        Intrinsics.checkParameterIsNotNull($receiver, "$receiver");
        ConsoleKt.println("Fooooooooooooooooooooooo");
    }

    public static final void hoo(String $receiver)
    {
        Intrinsics.checkParameterIsNotNull($receiver, "$receiver");
        ConsoleKt.println("Hooooooooooooooooooooo");
    }

実装場所についてはMainクラスにできているように見えるけど、どうなのか。

ということで試してみます。下記の二つのktファイルをjavaファイルにしてみます。

hello.kt

fun main(args: Array<String>) {
    "fuuuuu".poyo()
}

extension.kt

fun String.poyo() { println("poyo") }

結果はこうなりました。

HelloKt.java

import kotlin.jvm.internal.Intrinsics;

public final class HelloKt
{

    public static final void main(String args[])
    {
        Intrinsics.checkParameterIsNotNull(args, "args");
        ExtensionKt.poyo("fuuuuu");
    }
}

ExtensionKt.java

import kotlin.io.ConsoleKt;
import kotlin.jvm.internal.Intrinsics;

public final class ExtensionKt
{

    public static final void poyo(String $receiver)
    {
        Intrinsics.checkParameterIsNotNull($receiver, "$receiver");
        ConsoleKt.println("poyo");
    }
}

つまるところ、メソッドを拡張した場合は

  • メソッドを拡張した場所にある ファイル名 + "Kt.java" というクラスができる
  • そのクラスにstatic関数ができる

ということらしいです。

所感

やってみると単純な形なんだなぁという印象でした、変な話。

おまけ

コンパイルのコマンドあたりの処理が下記あたり。

https://github.com/JetBrains/kotlin/tree/master/compiler/cli/src/org/jetbrains/kotlin/cli/jvm

でコード生成らへんは下記あたりを見ればよさそう。

https://github.com/JetBrains/kotlin/tree/master/compiler/backend/src/org/jetbrains/kotlin/codegen

マスクとエマと私と

SHIROBAKOアドベントカレンダー 2日目の記事です。

こんにちは、担当のkgmyshinです。

SHIROBAKO最高でしたね。

特に仕事におけるチームワーク、その中の個人の葛藤や振る舞い。またベテラン勢や若手の各立場から出てくる名言。物を作る仕事をしている、特にチームで作っている人たちは見るべきアニメだったなと感じております。

ただ、今回は以上のことは一切話しません。

では何を話すのか。その前に、突然ですが一つ質問です。

「SHIROBAKO内で、セリフではなく一番好きなシーンはどこですか?」

私の答えはダントツでこのシーンです。

今日はこのシーンをどうして一番好きなのかただただつらつら語ってみたいと思います。

ただマスクをかけてるだけのシーンなのに何がいいのか

自分がなぜこのシーンが一番好きなのか考えてみました!考えたところ5つの理由がありましたので一つ一つ説明したいと思います。

彼女が安原えまだから

はい。

作画が最高だから

改めてじっくり見ると作画さんってすごいですよね。

以前にもこの記事で言及してます。

motida-japan.hatenablog.com

すごいなと思ったポイントをいくつか紹介します。

まずは顔の角度と手の動きの連動具合です。これ僕らプログラマーだったら「人類にはまだ早い」とか言って逃げ出しそう。

次に指先。マスクをかける時からマスクをかけ終わるまでの一連の指の動き。指の細部までに「あぁこれは安原えまの指だ」とわかるレベルです。

そしてマスクをかける時と外す時の髪の感じです。僕はうなじフェチではないのですが、うなじフェチの気持ちが少し理解できる気がします。

そしてそして最後は目です。笑顔から、ポケットの方に目線が逸れての、目をつぶりながらマスクをかけて、ちょっとウインクになっての、最後に微妙な上から目線。まぎれもない職人技ですね。

この数秒のシーンだけで数多の匠の技が詰まってましたね!作画さん最高です。

印象的だったから

実はこのシーンが印象的だと感じたのはこの質問に答えた時です。 つまり記憶にすごく残ってることから逆算的に印象的だと感じたわけです。

ではなぜ記憶に強く残ったのかという疑問が浮かんできますが、これにはすぐに答えることができます。

それは違和感です。

どういう違和感かというと、気付いている人もいるかもしれないですが、マスクの掛け方です。

というのも、普通はマスクをかけるのって両手じゃないですか

どうして片手なのか?

その答えはその前後のシーンを見ればすぐにわかる(後述します)のですが、 この見慣れないけれど、だのに自然にも見えるこのギャップが強烈で僕の海馬に強く刷り込まれたのだと思います。

さらにいうと、片手でマスクをかけることによっていわゆるクロスの法則(もしかして死語?)も発動しています。

このエマ様の腕の曲線美マジで最高です。エマだからこそ。

暖かかったから

このシーンの背景のお話です。

このシーンについて説明していなかったので、いまさらですが説明します。 ここは後輩の久乃木ちゃんがエマちゃんの家にきて、芋を渡して走り去っていくところを引き止めるシーンです。

まず初めの笑顔です。緊張しいでなかなか日本語がおぼつかない久乃木ちゃんの不安もこの笑顔で吹き飛びました。 そしてさりげなく自分の風邪をうつさないためにマスクをかけているのです。(芋を片手で持ってるので、片手でマスクを掛けざるを得なかった)

さりげなく後輩を気遣う暖かさにほっこりしますね。

エロスを感じるから

パンチラという言葉があります。

下着がチラッと見えてしまう現象のことですね。

多くの男性はこの現象にエロスを感じます。

さらに少しレイヤーがずれますが、先にも出てきた「うなじフェチ」。これはうなじにエロスを感じてしまう現象ですね。

二つの共通点は何でしょうか?

私は「普段隠されているものが見えてしまった」というのがポイントだと思うのです。

想像することしかできなかったその答えが見えてしまった、そこにエロスの本質があるのではないでしょうか?

さらにいうと見えてしまったその対象にではなく、隠れていたものが見えてしまったという事実にこそ本質があるのではないかと考えています。

つまり、エロスを感じる条件は「隠されているものを見てしまった事実があること」なのです。と強引に結論付けしておきます。

何を書いてるのかよくわからなくなってきましたがこのまま行きます。

今回は「マスクをかける」シーンです。

ここのどこにエロスがあるのか。

マスクをかけたことによって隠れてしまいました。ですが、隠される前の状態を僕らは知っています。

口元が隠されている。だが口元が隠れていない状態を見ている。

つまり「隠されているものを見てしまった事実がある」。

はい、条件クリアですね。まぎれもないエロスです。ただ順番が通常と違うので変則的エロスとでも名付けておきましょう。

ここからは蛇足ですが、エロスという言葉に嫌悪感を示す人がいます。

「エロスはほどほどにな」という有名なセリフもあるほどです。

しかし言葉の意味を調べると嫌悪するべきものではないことがわかります。

まずエロスとは性愛を司る神様です。そしてエロスには別名があります。その別名は皆さんご存知「キューピッド」です。そしてキューピッドは愛を司る神様です!

以上からエロスとはすなわち愛そのものなんですね

エロス===愛はtrueだったんです。「愛は地球は救う」は「エロスは地球を救う」だったんですね。

24時間テレビで「おっぱい募金」をやっているのはそういうことだったんです。

何を言いたいかというとこのマスクをつけるシーンにエロスを感じたということは、すなわち安原えまを愛してるとも言えるんだぜ!ということを言いたかったわけです。

はい。

まとめられない

変な話、後悔はしてません。

やりたいことやれてないから、どうやったらやるように自分を仕向けれるか考えてみた

最近、やることが増えてきて忙しさにかまけてやりたいことができてなかったなと思った。

やれよ!って話なんですが、忙しさに疲れてくると、どうしてもモチベーションが下がってきてしまう。

根っこが怠け者なのでしょうがないというのもあるのだが。

どうすればその時間を取ることができるようになるのか考えてみた。

その時間を取るように仕向ける

自分はこの日はこれをやる時間みたいに計画立ててやるのが性格的に向いてない。

仕事ではなんとかできるけど、私生活だともうなんというか、無残。

計画を立てる行為自体は好きだけど、計画通り遂行するということが苦手で仕方ない

じゃぁどうするかって考えると「結局やりたいことをやらなければ!」と思うように仕向けないといけないと思った。

今まで自分が「やらなければ!」って思ったのっていつか思い出してみる

だいたい4パターン。

あるアニメを見た時

これはちょっと特殊な事例なのだけど、中高一緒だったある友達が結構有名な声優だったりする。

その人が出演しているアニメを見ると、すごく高まる。

おれも頑張るぞ!!!ってなる。

なので、気が向いたらこれを見るようにって思っていれば、自分がやらなければって思うタイミングは増えそう。

すでに自分がやりたいことを実現している人と話す

そういう知り合いがそこそこいる。

で、一緒に飲み行ったりして話を聞くと、これまた

おれも早くやるぞ!!!ってなる。

なので、定期的にそういう知り合いに会う時間を作るようにすると良さそう。

自分と同じように思ってる人と話す

上とほぼ同じなんだけど、そういう人と話すと、

よしおれら頑張るぞ!!!ってなる。

なんかやばいって思った時

これはとくにきっかけはなく定期的にやってくる。

「やらなければ!」と思う頻度を増やす環境にする

結局自分は計画的にやることができない人間なので、「あのアニメみるぞ!」とか「知り合いにあうぞ!」と思ってもこれ自体が計画なので、思っても遂行できないのではないかという疑惑が湧いてくる。

じゃぁどうするか。

定期的に「やばい」って思った時に「あるアニメを見て」、「そういうことをやってる知り合い」や「同じ志の知り合い」に連絡を取るようにしようと思った。

BoradcastReceiver作って、3つのタスクを実行する感じ。

とうぶんこれでやっていきます。