Singleton Class/遅延学習

先週、アプリ開発中にシングルトンクラスを生成する機会があったので、そのメモと参考にしたサイトを記録に残してみようかと。(開発中のコードは公開できませんが)

Code

static id _instance = nil;

+ (id)instance
{
    @synchronized(self) {
        if (!_instance) {
            [[self alloc] init];
        }
    }
    return _instance;
}

+ (id)allocWithZone:(NSZone*)zone
{
    @synchronized(self) {
        if (!_instance) {
            _instance = [super allocWithZone:zone];
            return _instance;
        }
    }
    return nil;
}

- (id)copyWithZone:(NSZone*)zone
{
    return self;
}

- (id)retain
{
    return self;
}

- (unsigned)retainCount
{
    return UINT_MAX;
}

- (void)release
{
}

- (id)autorelease
{
    return self;
}

遅延学習

プログラムを始めたときに、詳解 Objective-C 2.0 改訂版の古いバージョンのものを読みましたが、アプリを実際に作るようになってから読み直すと、そのありがたみがわかるものですね。


遅延学習法の限界

をたまたま拝読したのですが、受験など、「答えがあるもの」に対してアプローチするときは、遅延学習が一番効率がよいそうです。


一方、答えがあるかどうかわからないことにチャレンジするときには、試行錯誤することが欠かせない。

遅延学習法では「そこに至る過程がはっきりとした」「すでにうまく行くことがわかっていること」しか学べないのだ。そのどちらかが欠けてもダメである。

例えばワイルズの証明以前には、フェルマーの大定理(当時は大予想)を遅延学習法で学ぶことは、証明がないので当然不可能である。

また、「うまく行く」という証明があっても、過程がはっきりとわかっていないものもダメである。
例えば自転車が操縦可能であることは誰もが知っているが、どうやって自転車に乗れるようになったのか筋道だって説明できるものはまだいない。

自転車の乗り方を遅延学習できるのであれば、転ばずに自転車に乗れるようになるはずだが、残念ながらそうは行かない。

遅延学習できないものはいくらでもあり、そして遅延学習できるものより多いのである。

遅延学習できないものを学ぶには、試行錯誤が欠かせない。そして試行錯誤というのは、遥かに手間暇がかかるのである。


そのことは、遅延学習の価値を下げるものでは全くない。むしろ遅延学習が効くものごとは積極的に遅延学習すれば、試行錯誤が必要な問題を解くための時間も増えるのだから。
僕の今いる会社で求められているのは後者だと思っています。


最近、不器用かもしれないけれども、試行錯誤する時間や課程が成長する瞬間なのかもしれません。(iOS系アプリをAndroidに移行しようとしたときとか)


今まで生きてきたシーンでは明らかに遅延学習的な要素をもつものがほとんどすべてでした。(受験や、単位取得のためのテストなど)


しかし、会社で求められるような成果って、たぶん試行錯誤しなければ得られないものばかりだと思うので、そっちに重点をおきつつ、遅延学習が効果的なときは効果的にそちらを使用していけるくらい臨機応変になりたいものです。


何よりも、とりあえずやってみないとわからない。つくって→修正し、よりよいものを作る。その試行錯誤する課程が成長するための第一歩かなと思いました。


「失敗は成功のもと」のような考え方を実践していかねば!

これだけ変化の激しい中、エンジニアはどう動くべき?


井口
失敗を恐れないことですね。成功より失敗からの方が学ぶことが多い。特にベンチャー企業は失敗にポジティブでないと。と言うか、積極的に失敗しないとダメ。


柳澤
おっしゃる通りですね。僕たちも過去にさまざまなサービスを開発してきた中で改めて思うのは、失敗しないと成功も見えてこないこと。社員には、むしろ失敗してもらうぐらいでないと、危なっかしくて見ていられないし、大きな仕事も頼めない。「どんどん失敗してください」と言っています。


井口
日本人の多くは失敗にネガティブな印象を抱くのは“失敗”という言葉にあるかもしれない。失敗ではなく、“エクスペリエンス”とか言い換えた方がいい。「失敗奨励制度」を設けてもいいぐらい(笑)。


柳澤
カヤックには、半年に一度行う人事評価の中で「どんな失敗をしたか?」を記入する項目があります。意識的に失敗しないってことは、挑戦していないも同義という考えからです。
話は変わりますが、僕の好きな言葉に「欲も大欲になれば、無欲なり」があります。エンジニアも大欲を持ってほしい。自分のためだけの欲でもいいけど、それだとつまらない。大欲を描いて挑戦してほしいですね。


井口
その意味でもグリーとDeNAには頑張ってほしいですね。大きくなってもベンチャースピリットを失っていないし、世界に真剣勝負を挑もうとしている。


頓智.井口CEO×面白法人カヤック柳澤社長の業界予測/Tech総研 より。