今回フォーカスする久乃木愛は後者です。後者のキャラクターにはいわゆる名前のないモブキャラも含まれてますが、彼女にはしっかりと名前が与えらています。前半には一回きりしかも静止画でのみの登場だった彼女が後半がっつりと存在感をあらわにしてきたのはなぜでしょうか。アリアに希望をもたらすためにルーシーというキャラクターが生まれたように、そこには彼女のキャラクターとして役割があったと思うのです。今回はそこを邪推してみようと思います。

その前に軽く紹介

まずは彼女について紹介していきましょう。

外見的には、SHIROBAKOでは数少ないアホ毛の持ち主です。感情に従ってアホ毛が動きます。

彼女が初めて登場したのは第十二話〈えくそだす・クリスマス〉でみんなが忘年会に行っているシーンでした。堂本さんと会話しているであろう静止画、声もなくBGMオンリーな初登場でした。

そして15話の〈こんな絵でいいんですか〉にて初めのて作打ちで絵麻が付き添っているところからはしっかり声も発しており、以降は頻繁に登場するようになります。

"初めての作打ち" という言葉からもわかるように、 彼女は第三飛行少女隊から原画マンになりました 。エクソダス時代では動画をやっております。

彼女の一番特徴的はやっぱり そのコミュ症っぷり でしょう。「あ！」や「う！」や「さっがっ！」など一文字二文字でしか言葉を発せず、視聴者によっては苦手な人もいたようです。

また設定資料集では 髪の毛を母親に切ってもらっている。 という一文が添えられています。おそらく実家暮らしなのでしょう。

久乃木愛の役割

前半の役割

彼女が登場してきてから初めの役割は「絵麻の成長の象徴」なのではないかと考えています。

去年のAdvent Calendarで述べてますが、前半12話での絵麻の焦りは尋常ではないです。

motida-japan.hatenablog.com

父親との期限付きの約束。そしてその期限を超えて数年経っても未だに食べていけると確信できない。そう言った中でのリテイク。

それもなんとか周りの協力や彼女自身の実力と成長のおかげで乗り越えることができました。

ここで考えて見ましょう。 もし久乃木愛がエクソダスの頃から原画マンだったら。

絵麻に久乃木愛の面倒をみる余裕があったでしょうか？

後輩の悩みに応える時間があったでしょうか？

後輩の作打ちに一緒に付きそっていたでしょうか？

食べていけるかどうかの瀬戸際で切り詰めて生活している彼女が、実家でぬくぬく暮らしていてコミュニケーションも取れない後輩の面倒をみる余裕なんてなかったはずです。もし面倒を見れたとしても、相当のストレスになったでしょう。

だからこそ久乃木愛は後半からの登場なのだと、自分は邪推します。

成長した後であるからこそ、久乃木愛の面倒を問題なくみることができる 。彼女がいることによって絵麻ちゃんのその成長っぷり、余裕っぷりが際立っていくんです。

絵のことについて、「人に教える余裕」もでてきました。

(天使の笑顔かよ...)

後半の役割

後半からは絵麻の手から離れていく自走するシーンが目立ちました。後半以降の彼女のアニメの中での役割は、宮森の最終回の言葉を体現するものではないかと考えています。

「細いロウソクの火みたいなかもしれないけれど、その小さな火が次々に受け継がれて、永遠に消えることのない炎となって世界を照らすものじゃないかって」

杉江さんから小笠原さん、小笠原さんから井口さん、井口さんから絵麻、そして絵麻から久乃木愛へ。

絵麻が井口さんからもらい、絵麻が久乃木愛に渡す という、バトンを絵麻が回していく様を表したかったのではないでしょうか。

それを表現するためには久乃木愛自身がただ頼るだけの後輩のままアニメが終わってしまってはダメで、しっかり手離れして成長していく必要があったはずです。

まさに、最後の方は久乃木愛自身の勉強熱心さ、そして彼女の成長にフォーカスされます。

初めの作打ちでは「あ」や「う」しか話すことができなかった彼女が、初めて一人で行った作打ちでは「これは下着...ですか？」という名言をたたきこみ、またその次の作打ちでは「風速何メートルですか？」となんだか絵に必要そうな良い質問をしています。

一番象徴的なシーン

最終話〈遠すぎた納品〉での一幕でした。

「このカット、誰？」

監督や脚本が唸るほどカットを書いたのは我らが久乃木愛でした。

ここなにがすごいかというと 動物のカット なんです。

井口さんにとってのもぐら、絵麻ちゃんにとっての猫と、 この師弟筋にとって初めての動物は鬼門 のように描かれてました。

(もしかしたら作中描かれてないだけで初めてでないかもですが、とはいえ第三飛行書状態で動物カットはそうそうないはず。)

その鬼門を物ともせず、むしろ監督陣営を唸らせるほどのクオリティ。天才なのかもしれません。

このシーンは普通に考えたら、ずかちゃんがようやく抜擢されて、そのシーンを友達の絵麻が他にも十分に作業があるにもかかわらず自ら立候補してルーシーのシーンを書いたという流れだったので、絵麻がクオリティ高いものを書いて監督陣営から絶賛されるというのが自然な流れじゃないですか？それなのにその流れをぶった切って久乃木愛は全てを持って行くわけです。最高ですね。

考えてみると、久乃木愛は絵麻と対比的な設定が多くあります。〈実家暮らし〉と〈つめつめな一人暮らし〉、〈初めての動物シーンで監督陣営に大絶賛〉と〈初めてのシーンで作監から「これはない」と言われる〉などなど...

そんな対比を物ともせずに、多少の嫉妬くらいあってもいいはずなのに

「褒められてるよ、久乃木さん」

と、我が子のように接する絵麻の成長っぷりよ。

その二つ〈絵麻の成長〉〈久乃木愛の成長でなりたつ次の世代への伝授〉がしっかり表現されたいいシーンでした。

まとめ

もしかしたらこれから先に、鬼門をものともしなかった久乃木愛ですし〈下からどんどん成長する久乃木愛によって焦る絵麻〉とう未来がありえそうです。

しかし、それでも〈久乃木愛が絵で迷い、例の公園に絵麻が連れていく〉シーンを想像しながらニヤニヤしておきます。

長文にお付き合いいただきありがとうございました。

2017-12-10

Rxなインスタンスを返却するメソッドを実装する時の注意点

そういえばよくレビューで指摘してたなぁと思い出したのでメモ書き。

例えばこういうコード。

fun findContent(): Maybe<Content> {
    val connectivityManager = application.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    return if (connectivityManager.activeNetworkInfo.isConnected) {
        apiRepository.find()
    } else {
        localRepository.find()
    }
}

Content を取得したい時に、オンラインだったら apiRepository を使って、オフラインだったら localRepository を使うというコード。

このコードにはいくつか問題があって、 as じゃなくて as? を使った方が安全とかは間違いなくそうなんだけど、それよりも オンラインかオフラインか の判定ロジックが Rxな世界に包まれていないところが問題だと思っている。

オンラインかオフラインか の場所で Throwable が投げられる可能性がある場合、これを使っている側がしっかり onError を実装していたとしてもで落ちてしまう。それも、悪質なのは subscribe している箇所ではなく findContent を呼んでいる箇所で、だ。 いうまでもなく subscribe されなくてもこの判定ロジックは処理されてしまう。

もし Throwable が投げられる可能性がないとしても、判定に時間がかかったりすることもあり、想定と違うものになりかねない。

なので、最終的に返すもの以外のロジックすべてをちゃんとRxな世界で包んであげましょう。

自分の場合だと下記みたいに書くと思う。

fun findContent(): Maybe<Content> =
    isConnected().flatMapMaybe { isConnected ->
                    if (isConnected) {
                        apiRepository.find()
                    } else {
                        localRepository.find()
                    }
                }

private fun isConnected(): Single<Boolean> = Single.create { emitter ->
    val connectivityManager = application.getSystemService(Context.CONNECTIVITY_SERVICE) as? ConnectivityManager
    if (connectivityManager != null) {
        emitter.onSuccess(connectivityManager.activeNetworkInfo.isConnected)
    } else {
        emitter.onError(RuntimeException("cannot get connectivity"))
    }
}

2017-12-03

Android Gradle Plugin3系におけるマルチモジュール時のconfigurationの解決について

こんにちは。釘宮です。

マルチモジュールなプロジェクトをやって行く上で、以前は下記のような記述をよく書いていました。

devCompile project(path: 'library', configuration: 'dev')

Android Gradle Plugin3系(gradle4系)から compile(など)ではなく implementation(など)を使っていきましょうともろもろ変わりました。

なので、単純に下記のように implementation と書き直してみます。

devImplementation project(path: 'library', configuration: 'dev')

これでビルドをして見ると、がっつりエラーが出てきます。

解決方法などをまとめたので今回記事として見ました。

ここに書いていあることは公式ページに書いてあることの一部 + αでdす。

結論から言うと implementation project('library') で良い (条件付き)

app/build.gradle

library/build.gradle

android {
  :
  flavorDimensions 'api'
  productFlavors {
    dev {
      dimension 'api'
    }
    stg {
      dimension 'api'
    }
    prod {
      dimension 'api'
    }
  }
  :
}
dependencies {
  :
  implementation project(":library")
  :
}

android {
  :
  flavorDimensions 'api'
  productFlavors {
    dev {
      dimension 'api'
    }
    stg {
      dimension 'api'
    }
    prod {
      dimension 'api'
    }
  }
  :
}

このようになっている場合、appではlibraryで同じ名前のflavorのものを選択してbuildされます。

いままでは

devCompile project(path: ':library', configuration: 'dev')
stgCompile project(path: ':library', configuration: 'stg')
prodCompile project(path: ':library', configuration: 'prod')

などと書いてましたが、下記一行で済むようになりました。便利ですね。

implementation project(":library")

ただこれに関しては app側にある api-dimension に所属する dev, stg, prod をlibrary側も同じものを持っているという条件を満たしている時に限ります。

そのため、library側が余計に dev1 というflavorを持っていても使われないだけでビルドは問題なく通ります。

以下から簡略化のため、 api-dimensionに所属する dev, stg, prod のflavorがある状態を [api => (dev, stg, prod)] と書くようにしますね。

例1. appでは[api => (dev, stg, qa, prod)]、libraryでは[ api => (dev, stg, prod)]となっている時

app側に qa があるけど library側にそれがない場合です。

appの qa 時には library では stg を選択したいとします。

こう言う時は matchingFallbacks を使用します。

app/build.gradle

library/build.gradle

android {
  :
  flavorDimensions 'api'
  productFlavors {
    dev {
      dimension 'api'
    }
    stg {
      dimension 'api'
    }
    qa {
      dimension 'api'
      matchingFallbacks = ["stg"]
    }
    prod {
      dimension 'api'
    }
  }
  :
}
dependencies {
  :
  implementation project(":library")
  :
}

android {
  :
  flavorDimensions 'api'
  productFlavors {
    dev {
      dimension 'api'
    }
    stg {
      dimension 'api'
    }
    prod {
      dimension 'api'
    }
  }
  :
}

依存先に対象flavorが見つからない場合に matchingFallbacks によって優先順位を指定できます。上記の例では stg のみ指定しいます。 (なお、 flavor dimention が一致していないと、matchingFallbacks に指定しても動きません)。加えてこのmatchingFallbacks は下記のようにbuildTypeでも同様の使い方ができます。

app/build.gradle

library/build.gradle

android {
  :
  buildTypes {
    debug {
    }
    stg {
    }
    qa {
      matchingFallbacks = ["stg"]
    }
    release {
    }
  }
  :
}
dependencies {
  :
  implementation project(":library")
  :
}

android {
  :
  buildTypes {
    debug {
    }
    stg {
    }
    release {
    }
  }
  :
}

例2. library側に知らないdimensionがある時

そもそもdimensionとは

あえて触れてこなかったんですが flavorDimensions 'api' のところの話です。

~~Android Gradle Plugin3.0.0より前ではなかったものです。~~ いままでもありましたが、3系からは指定が必須になったようです。

いままでは productFlavors とはフラットなものでして、あるflavorと他のflavorを組み合わせるということはできませんでした。これを可能にするのが flavorDimension です。

言葉だと難しいので実際に設定して見ましょう。

productFlavors {
    buildTypes {
      debug
      release
    }
    flavorDimensions 'api', 'persistence'
    dev {
        dimension 'api'
    }
    stg {
        dimension 'api'
    }
    prod {
        dimension 'api'
    }
    local {
        dimension 'persistence'
    }
    cloud {
        dimension 'persistence'
    }
}

flavorDimension を指定しない場合、 buildVariant は (dev, stg, prod, local, cloud) × (debug, release) の 5×2 = 10通りのconfigurationがとなっていました。

これが、現状は上記のようにdimensionを使い分けることで (dev, stg, prod) × (local, cloud) × (debug, release) の 3×2×2 = 12通りconfigurationが作られるようになったと言うことです。

何が便利かと言うと、観点ごとにコードを分けれることでしょうか。上記の場合だと api は (dev, stg, prod) のどの環境を使うか、永続化(persistence)はローカルなのかクラウドなのかという例になっています。

ざっくりここまでがdimensionの説明です。

appは [api => (dev, stg, prod)]、 libraryが [api => (dev, stg, prod), persistence => (local, cloud)] の時

appの知らない persistence dimension がlibraryにある場合を考えます。

appで、例えば stg をbuildしたい時に、 library側では stg と言っても stgLocal と stgCloud の組み合わせがあるのでどっちを使えば良いのかわからないと言う状況です。；

この場合は missingDimensionStrategy を使用します

missingDimensionStrategy (dimension名) (flavor名), (flavor名),...

と言うふうに知らないdimensionがきた時に、どのflavorを優先的に採用するかということを決めることができます。

missingDimensionStrategy 'persistence' 'local' 'cloud'

この場合は persistence dimensionがきたら local, cloud の順で採用すると言うことになります。

これを踏まえると下記のようになりました。

app/build.gradle

library/build.gradle

android {
  :
  defaultConfig {
    :
    missingDimensionStrategy 'persistence', 'local', 'cloud'
    :
  }
  flavorDimensions 'api'
  productFlavors {
      dev {
          dimension 'api'
          missingDimensionStrategy 'persistence', 'local'
      }
      stg {
          dimension 'api'
          missingDimensionStrategy 'persistence', 'cloud'
      }
      prod {
          dimension 'api'
          missingDimensionStrategy 'persistence', 'cloud'
      }
  }
  :
}
dependencies {
  :
  implementation project(":library")
  :
}

android {
  :
  flavorDimensions 'api', 'persistence'
  productFlavors {
      dev {
          dimension 'api'
      }
      stg {
          dimension 'api'
      }
      prod {
          dimension 'api'
      }
      local {
          dimension 'persistence'
      }
      cloud {
          dimension 'persistence'
      }
  }
  :
}

上記のように各Flavorごとに missingDimensionStrategy を設定することができます。

まとめ

これからは configuration の解決は dependencies のところではなく flavor名、 matchingFallbacks や missingDimensionStrategy で頑張りましょう。

2017-12-02

キャリアパスどうするねん問題

釘宮です。こんにちは。

この記事は SHIROBAKO Advent Calendar 2017 の二日目の記事です。昨日のkonifarさんの武蔵野アニメーション総務興津由佳の左眼についてという記事からスタートしました。 ベスト・オブ・興津 はあれ一択ですよね。さすが、わかってらっしゃる。

さて。

キャリアパス悩む
— 有象無象 (@kgmyshin) 2017年11月28日

キャリアパス悩みますよね。

なのでSHIROBAKOを見てみました。

なぜかというと、SHIROBAKOの主題を一言で表すと(浅はかかもですが)、 みゃーもりのキャリアパスどうするねん問題 に尽きるからです。1話から最後の方までのほとんど全ての要素がみゃーもりの「私って何をしていきたいんだっけ？」のヒントや刺激となっていて、最終話でみゃーもりが結論をだすいうのがSHIROBAKOの大きな流れなんです。

改めてSHIROBAKOを見ることで何かしら自分もヒントを見つけられないかなと感じて見直した次第です。

「飛ぶ意味ってなんなのかな？」

〈20話 - がんばりマスタング〉での会議での出来事でした。

この時みゃーもりの務める武蔵野アニメーションでは第三飛行少女隊というアニメを制作しております。

最終回が近づくにつれ、あるトラウマ的な事件をきっかけに主人公のパイロットであるアリアは飛ぶことをやめてしまいます。

しかし監督はじめ制作スタッフ一同はアニメの最終回では、なんとかそのトラウマを乗り越えてなんとか飛んでもらいたい。だけど原作ではまだアリアはそれを克服していない上、作者に連絡も取れない。その中でみゃーもりがぽつりと

宮森　　「飛ぶ意味ってなんなのかな？」

と漏らし、そこから話が広がっていきます。

宮森　　「飛ぶ意味ってなんなのかな？」

：

舞茸　　「それは我々にとってなんでアニメを作るのか？ みたいなことじゃないの？」

宮森　　「あ、そっか！それだったらわかります！」

舞茸　　「え、宮森さんはなんで作ってんの？」

宮森　　「いや、質問の意味はわかるってだけで。作る意味とかは全然。」

:

宮森　　「監督はなんでアニメ作ってるんですか？」

監督　　「なんとなく？でも、やめられないんだよね。なんでかな」

舞茸　　「僕だって、意味とかたいそうなことを考えてないよ。明日の締め切りだけこなしてたら何十年も経っちゃっただけでさ」

なべP 　「なんでこんな仕事についちゃったかなぁ」

葛城　　「僕は刺激かな。みる人に刺激を与えたいし、作ることで自分も刺激を受けたい」

この議題は、会議が終わった後も各所で広がっていきます。

りー　　「自分にはやっぱり物語が必要なんだなって思うんす」

矢野　　「面白いじゃないじゃないですか？」

安藤　　「好きだから、以外にないっすね」

山田　　「自分がここにいるっていうのを確認するため」

円　　　「次の作品をつくりたいから、今の作品を作ってるのかな」

佐藤　　「(一丸となって完成を目指す会社の雰囲気が)好きだからかもしれません」

ここで終わると思いきや、次話〈21話 - クオリティを人質にすんな〉のアバンにて各キャラクターの アニメを作り続ける理由 が一気に流れます。

木佐　　「んー自己表現ってやつ？」

落合　　「最終的におれがみたいものをつくりたいんだよ」

富ヶ谷　「ペクサーみたいな会社を日本に作りたいんだよ。いつか独立してやる」

荒川　　「こどものころから塗り絵とかすきだったんだよね」

堂本　　「好きなこと続けてるだけ」

河野　　「だんだん面白くなってやめられなくなっちゃったんだよな」

大倉　　「10才の少年がずぅっと俺の心のなかに住んでんダヨォ(酔いながら)」

久乃木　「さっがっ！」

f:id:kgmyshin:20171201141230j:plain

出典: http://ponpokonwes.blog.jp/archives/24023907.html

こんなにあるのかってくらいたくさんありますね。

ベテランか新人によっての偏りはあんまりなさそうでしたが、パターン分けはできそうです。

なんとなく (なんで続けてるかはわからない)
好きだから
自己実現
性

(何気に久乃木の性が渋かっこいい)

これをエンジニアである自分自身に落とし込んでみると、 今までは〈なんとなく〉〈好きだから〉続けてられていたように思います 。それが、いつのまにか徐々にそれだけではモチベーションが保てなくなってきているようになってしまった。そしてそれゆえに「キャリアパス悩む」問題に直面しているのかなぁと思うわけです。

「安原さんはなんでアニメーターになろうと思ったの?」

〈8話 - 責めてるんじゃないからね〉にて我らが杉江大先生と僕の絵麻の会話にてドンピシャな会話をしています。

杉江　　「安原さんはなんでアニメーターになろうと思ったの?」

絵麻　　「絵を描くのが好きだからです」

絵麻　　「それだけじゃいけませんか」

杉江　　「好きな事をして食べていけるのは幸せなことだ。だけどそのうち描くだけじゃ物足りなくなってくる」

杉江　　「何か新しい目標が必要になってくるんだ」

絵麻　　「目標……」

杉江　　「世界中の子供たちが笑顔になってくれたら……僕はそう思いながら描いている」

絵麻　　「私はそんな大それたこと全然思えません」

f:id:kgmyshin:20171201143514j:plain

出典: http://kagano443.blog.fc2.com/?no=792

擦れた絵麻も可愛いですがそこは飲みの席で語るとして、自分もまさに 物足りなくなってきてるのかなぁ と。

そういえば先の「なんでアニメを作り続けているのか？」の回答に、ちゃんと新しい目標を持ってる回答がいくつかありました。

逆に〈好き〉だけで長年やれてる人もいるので、やっぱり 物足りなくなるのかどうかは人による 、そして 僕は物足りなくなってしまった側の人なんだな と思いました。

「目先のことばかり考えてる時期はもう終わりだよ」

SHIROBAKO主人公みゃーもりは、初めから悩んでるのもあって 新しい目標を見つけないといけない側 だと考えられます。それを後回し後回しとしてきた結果とうとう最終回にて、、

ロロ　　「これからどうしたいのか決まった？このままアニメを作りたいのか。作りたいとしたらなぜなのか？」

宮森　　「んと、これからゆっくり考える」

ロロ　　「あまったれんなー！」

ロロ　　「目先のことばかり考えてる時期はもう終わりだよ」

ロロ　　「そろそろ少し高いところから遠くを見る時がきたんだよ」

f:id:kgmyshin:20171201153717j:plain

出典: http://anicobin.ldblog.jp/archives/43988621.html

そして宮森は結論を出すわけですが、気になる方はぜひ1話から見てみてくださいませ！！！！！！

また自分の話に戻すのですが 目先のことばかり考えてる時期はもう終わりだよ というセリフにはぐさっと心臓を刺されました。。。

ということで自分も後回しにせずにじっくり考えて見ました。

いきなり過程をすっ飛ばしますと、自分はやっぱり ものづくり をしたいんだなぁと。それもただ作っていたいわけでなく、売り上げがどうこうとかじゃなくて、ひたすらユーザーへの価値を第一に考えて、ほぼほぼそれのみKGI・KPIにおいて磨いてたら、売り上げもついてきたみたいなものづくりをしてサービスを育てたい。それをいくつも。というのが本当にやっていきたいことだなぁと。

もちろん、ただの夢、理想かもしれません。でも、 これを実現したいがゆえにエンジニアしてるんだなぁと思うわけです。僕の場合は。

以下、所信表明です。

会社でそういうことをやるのが難しいし、いきなり起業だ！！って気は全くなく、こじんまりと少人数でそういう開発をやっていけたらと考えています。

まずは12月中にアイデアだしからこつこつやって1月からは早速開発を。

デザイン力だけ自分にはないので、上記のようなものづくりに共感できる人いたらこそっと言ってもらえるとすごくありがたいです！！！！

結論をまとめるとキャリアパスとしては、 自分が作りたい環境で作ってそのやり方でサービスが育つことを確認したい。(そしてそれを何回も繰り返したい。再現性あるものにしたい。) となります。

ただ、完全に会社で働く意味性が完全に抜けてるのでここはまた考えます。

「たどり着きたい場所がはっきりすると、やるべきことが見えてくるんだなぁ」

f:id:kgmyshin:20171201160627j:plain

やってくぞ！！！

まとめ

キャリアパスに悩むなら SHIROBAKO を見てみよう。至言がそこにたくさんある。
ユーザーファーストなこじんまりとした開発をやってくぞ
デザイナーさん、やってきましょう？

それでも見つからないあなたへ

SHIROBAKOの舞台である、ずかちゃんのバイト先の「柗亭」。この居酒屋は実在しており、月1ペースで言っているのですが、そこのトイレ飾られている生きるのが楽になるまいにち蛭子さん(日めくり) , (日めくり)まいにち、修造! も結構な至言に溢れているので、柗亭に行くかカレンダーを買うのをオススメします。

真理すぎて笑った pic.twitter.com/UvFgdivwaA
— 有象無象 (@kgmyshin) 2017年11月22日

アナログ金木犀

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

2017年買ってよかったもの、行ってよかったところなど

Nine Parchments

ドラクエ11

深山桜庵への宿泊

家計簿アプリ・家計簿ソフト「マネーフォワード」

L字デスク

あぐらチェア

柗亭

天才アニメーター？久乃木愛

久乃木愛の役割

その前に軽く紹介

久乃木愛の役割

前半の役割

後半の役割

一番象徴的なシーン

まとめ

Rxなインスタンスを返却するメソッドを実装する時の注意点

Android Gradle Plugin3系におけるマルチモジュール時のconfigurationの解決について

結論から言うと implementation project('library') で良い (条件付き)

例1. appでは[api => (dev, stg, qa, prod)]、libraryでは[ api => (dev, stg, prod)]となっている時

例2. library側に知らないdimensionがある時

そもそもdimensionとは

appは [api => (dev, stg, prod)]、 libraryが [api => (dev, stg, prod), persistence => (local, cloud)] の時

まとめ

キャリアパスどうするねん問題

「飛ぶ意味ってなんなのかな？」

「安原さんはなんでアニメーターになろうと思ったの?」

「目先のことばかり考えてる時期はもう終わりだよ」

「たどり着きたい場所がはっきりすると、やるべきことが見えてくるんだなぁ」

まとめ

それでも見つからないあなたへ