gotohayato.com

プログラマのためのフロー理論のすすめ

プログラミング技術向上

今回はプログラマの方向けに「フロー理論」の紹介をしてみたいと思います。

このブログではあまり長文を書きませんが、今回は長文です。

……

日々プログラムを書いたり読んだりしているとつくづく私は「プログラミングはスポーツや楽器の演奏に似ているなぁ」と思います。 プログラミングとスポーツや楽器の演奏には次のような共通点があります。

  • 概念や仕組みの理解は必要だがそれだけでは不十分で実践・反復をしないと上達しない
  • 一定の集中力を必要とし、他のことと並行で「ながら」でやるのは難しい
  • 頭と身体のさまざまな部分を協調させて行う必要がある
  • ひとつひとつの動作の結果がすぐに形になって見える
  • 単に「やれる」のと「うまくやれる」のとの間には大きな開きがある

フロー理論がスポーツや楽器演奏の世界でどれだけ認識・理解されているかは知りませんが、プログラミングの世界ではフロー理論をちゃんと知っている人は（プログラミングがフロー状態に入りやすい活動であるにもかかわらず）そう多くはないように思います。

プログラマがフロー理論を知ることのメリットはとても大きいので、今回はフロー理論について説明し、プログラミングを行う上でのポイントを紹介します。 最後にリファレンスも載せているで、興味が出た方はぜひ他の資料にもあたってみてください。

フローとは

フロー（ flow ）とは、人が作業に極度に没頭し夢中になった心理状態のことを指します。 スポーツの世界ではよく「ゾーン」と呼ばれますが、心理学の世界では「フロー」という呼び方が一般的なようです。 学術的な研究の歴史は 1970 年代にミハイ・チクセントミハイ（ Mihaly Csikszentmihalyi ）というアメリカの心理学者がこの現象に「フロー」という名前を付けて研究し始めたのが始まりです。

英語の Wikipedia の flow のページには次のように書かれています:

In positive psychology, flow, also known colloquially as being in the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does, and a resulting loss in one's sense of space and time.

Named by Mihály Csíkszentmihályi in 1975, the concept has been widely referred to across a variety of fields (and has an especially big recognition in occupational therapy), though the concept has existed for thousands of years under other names, notably in some Eastern religions.

意訳:

ポジティブ心理学では、フロー――口語では「ゾーンに入った状態」としても知られるもの――とは、何かの作業を行っている人が、その作業を行う過程の中で、強い意識の集中と没頭感、楽しみの感覚を感じていて、そこに完全に浸り切った心の活動状態を指します。 フローの本質は、行っている作業に人が完全に没入して、その結果、時間や場所に対する感覚がなくなることです。

フローの概念そのものは（特に東洋の宗教の中で）数千年の間他の名前で存在し続けてきましたが、フローという名前は 1975 年にミハイ・チクセントミハイが名付けました。 以後、フローの概念はさまざまな分野をまたいで幅広く言及されてきました（作業療法の領域で特に大きく認識されてきました）。

フローは、少し前から一般にも広く知られるようになった「マインドフルネス」（ mindfulness ）と同じく、「ポジティブ心理学」（ positive psychology ）と呼ばれる心理学の分野で研究が行われています。

日本には「没頭する」「夢中になる」「我を忘れる」「時を忘れる」といったようにフローの心理的状態を表す表現がたくさんあるので、フローの感覚や概念は多くの日本人にとってとても馴染み深いものだと思います。

……

フロー研究に関して私がおもしろいと感じるのは、この「没頭する」「夢中になる」という心理状態を単に「よくあること」として片付けず専門的に研究する人たちが 40 年以上も前からいて、一定の知見が溜まっているということです。

プログラミングにおいては「どれだけ集中できるか」が生産性や創造性に大きく影響するので、一流を目指すプログラマの方はフローについてひととおりの基礎を知っておいて損は無いと思います。

フローに至るための条件

実際にフロー状態に入るためにはどのような条件が揃っているとよいのでしょうか。

今も昔もフロー研究の第一人者であるミハイ・チクセントミハイによると、フローの特徴は 8 つのポイントで説明することができます。 ・・・のはずですが、 Wikipedia のページにその 8 つのポイントがあがっていなかったので、代わりに他のいくつかの部分を抜粋してご紹介します。

Flow theory postulates three conditions that have to be met to achieve a flow state:

  1. One must be involved in an activity with a clear set of goals and progress. This adds direction and structure to the task.
  2. The task at hand must have clear and immediate feedback. This helps the person negotiate any changing demands and allows them to adjust their performance to maintain the flow state.
  3. One must have a good balance between the perceived challenges of the task at hand and their own perceived skills. One must have confidence in one's ability to complete the task at hand.

意訳:

フロー理論では、フロー状態に至るには 3 つの条件が満たされる必要があるとされています。

  1. ゴールと進捗が明確な活動に取り組むこと。明確なゴールと進捗があることで、その作業に方向性と構造が生まれます。
  2. 目の前の作業には、明確で素早いフィードバックがあること。明確で素早いフィードバックがあることで、変更が必要な場合は対応し、パフォーマンスを調整して、フロー状態を維持しやすくなります。
  3. 目の前の作業の難易度と自身のスキルに対する認識の間にほどよいバランスが取れていること。自分の能力で目の前のタスクを完了できるという自信があること。

次の箇所は上のものよりもずっとシンプルなので、覚えることができます。

In order to achieve flow, Csikszentmihályi lays out the following three conditions:

  1. Goals are clear
  2. Feedback is immediate
  3. A balance between opportunity and capacity

意訳:

チクセントミハイは、フロー状態に入るための条件として 3 つを挙げています:

  1. ゴールが明確であること
  2. 即時のフィードバックがあること
  3. 機会と能力の間のバランスが取れていること

つまり、「やるべきことが明確」で、「ほどよい難易度」で、「結果がすぐにわかる」、この 3 つの条件が揃っていればフロー状態を得やすいとのことです。

調査でわかっている重要なポイントは、人が長い時間を費やしている活動の中でも「受け身で行う活動」よりも「能動的に行う活動」の方がフロー状態になりやすい傾向があるということです。 そのわかりやすい例は「テレビ鑑賞」です。 テレビ鑑賞は一般に心地よいものですが「テレビをただ見ているだけ」ではなかなかフローに入ることは少なくて、テレビゲーム等能動的に頭や体を動かしている作業の方が断然フローには入りやすいとのこと。

このあたりは、日頃からフロー状態を多く体験している方は違和感なく「そうそう！」と共感できる内容なのではないかと思います。

当然ですがこれらはあくまでも「傾向」の参考であり、絶対的な基準ではない点に注意してください。 「これらの条件が整えば必ずフローが得られる」「これらの条件が無いとフローは得られない」という絶対の基準があるわけではありません。

また、フロー状態に入りやすいかどうかは個人差もあるとのことです。

少し余談です。 2 番目の「即時のフィードバックがあること」というポイントに関しては、「行動分析（あるいは行動分析学）」（ Behavioral Analysis ）というこれまた心理学の一分野で多くの知見が得られています。 これは近年名前の広まった「ゲーミフィケーション」の源流です。 このあたりに興味のある方は「行動分析学」等で検索してみてください。

フローを妨げるもの

人がフロー状態に入りやすい条件とは逆に、フロー状態の妨害となるものもあります。 英語の Wikipedia を引用します:

There are, however, barriers to achieving flow in the workplace. In his chapter "Why Flow Doesn't Happen on the Job," Csikszentmihályi argues the first reason that flow does not occur is that the goals of one's job are not clear. He explains that while some tasks at work may fit into a larger, organization plan, the individual worker may not see where their individual task fits it. Second, limited feedback about one's work can reduce motivation and leaves the employee unaware of whether or not they did a good job. When there is little communication of feedback, an employee may not be assigned tasks that challenge them or seem important, which could potentially prevent an opportunity for flow.

意訳:

しかし、職場でフロー状態になることを妨げるものがあります。 チクセントミハイは「 Why Flow Doesn't Happen on the Job 」という章の中で、フローが起こらない第 1 の理由は「仕事のゴールが明確でないこと」だとしています。 彼は、仕事における作業はより大きな組織の計画の一部であるが、各スタッフは自分の作業が組織の計画にどう関係しているかがわかっていないことがあると説明しています。 2 つめの理由として、仕事に対するフィードバックが少ないことがモチベーションを減らし自分がよい仕事をしたのかどうかを認識できなくさせている可能性があると言います。 フィードバックのコミュニケーションが少ない場合は、スタッフはチャレンジングな作業や重要な作業に取り組むことができません。 そのことがフローを得る機会を減らしている可能性があると指摘しています。

このあたりもプログラマの方であれば「ふむふむ、確かに」と思うところではないでしょうか。

フローのメリット

続いて、フローのメリットについてです。 フロー状態には次のようなさまざまなメリットがあると言われています。

  • パフォーマンスの向上
  • より高難度の作業への意欲の向上
  • 技能の向上
  • 不安や心配の減少
  • 不適切な行動の減少
  • 幸福度の向上

このあたりは現代の科学的手法・ツールで測定できることの限界もあるので、どうも抽象的でふんわりしてしまうところがあります。 このあたりがフロー理論（広くはポジティブ心理学）の押しが弱くならざるを得ないところだと思います。 大多数の人間は「複雑だけど合理的な解決策」よりも「これだけ食べれば痩せる」というような「シンプルでわかりやすい解決策」を好むので、一定の洞察を必要とするフロー理論やポジティブ心理学はいつまでもメジャーにはならなさそうだなと思っています。

とはいえ、（ミハイ・チクセントミハイの著書の内容に関する私の記憶が正しければ）スポーツ等で高いパフォーマンスを発揮している人や人生の幸福度が高い人たちは、生活の中でより多くのフロー状態を感じている傾向がある（パフォーマンスや幸福度とフローの多寡に相関がある）とのことなので、（これは厳密な意味での因果関係の証明ではありませんが）フローに一定のメリットがあるらしいと言ってよいのではないかと思います。

ただ、このあたりはあくまでも主観によるところでもあるので、「フローはいいんだよ」と理屈で人から聞かされるよりも、自分自身で体験して感じてみることが一番ではないかなと思います。

フローの注意点

といったように、フローにはさまざまなメリットがありますが、万能かというとそういうわけではありません。 フローをのメカニズムを活用することには、例えば次のような落とし穴があります。

  • フローになりやすい特定の作業ばかり気持ちよくなってしまい、他の作業へのモチベーションが下がる
  • フローになりやすい比較的単純な（≒ゴールが明確な）作業ばかりを好み、不確実性のある作業を避けてしまう
  • フローが得やすい行動が、必ずしも個人的生活や社会的意義の面で見たときに望ましい行動とはかぎらない

例えば、うまく設計されたテレビゲームでは多くの人がフロー状態を体験できますが、テレビゲームにばかり熱中して生活の他の活動がおろそかになってしまうと、問題が出てきます。 これはテレビゲームにかぎらず、スポーツや読書、インターネット、仕事の業務等でも同じです。

また、フロー状態を得やすい活動のうち、反社会的なものもたくさんあるでしょう。

フローは確かに喜びに繋がりますが、フローを得られるその行動が望ましいものなのか、そして、適切な量はどれぐらいなのかを見極めて、「フローが得られないけれど大事な活動も人生にはたくさんある」ということ理解した上で正しく取り扱う必要があります。

プログラミングとフロー

（私はこれらのことばを使うプログラマに出会ったことはありませんが）いわゆるフロー状態のことを「ワイヤドイン」「ハックモード」と呼ぶソフトウェア開発者がいるそうです。

またまた Wikipedia から引用します:

Developers of computer software reference getting into a flow state as "wired in", or sometimes as The Zone, hack mode, or operating on software time when developing in an undistracted state.

意訳:

コンピュータ・ソフトウェアの開発者たちは、気が散るものがない状態で開発しているときにフロー状態に入ることを「ワイヤドイン」（ wired in ）と呼びます。ときには、「ゾーン」（ The Zone ）、「ハックモード」（ hack mode ）、「ソフトウェアタイムでの作業」（ software time ）と呼んだりします。

プログラマがフローのためにできること

かんたんにではありますが、以上で一通りフローについての説明をしました（といってもあくまでも表面的な説明なので、フローについてきちんと理解したい方はぜひ最後のリファレンスをチェックしてください）。

続いて、私が実際に心がけていることをもとに、プログラマがフロー状態を増やすためできる工夫について述べてみたいと思います。

  • 工夫 1: 作業のゴールを書き出す
  • 工夫 2: 遅いマシンやアプリは使わない
  • 工夫 3: 素早いレスポンスの得られるツールを使う
  • 工夫 4: 十分なディスプレイ領域を確保する
  • 工夫 5: タイピングやマウス操作を速くする
  • 工夫 6: ノイズを減らす
  • 工夫 7: 割り込みを減らす
  • 工夫 8: ポモドーロ・テクニックを使う

工夫 1: 作業のゴールを書き出す

場所は紙のノートでもテキストエディタでも何でもいいので、今から行う、あるいは今行っている作業のゴールをメモ書きで書き出します。

これにはフローの観点から 2 つのメリットがあります。 ひとつは、そのままですが「ゴールを明確にできる」ということ（書き出そうとして書き出せなかったときにゴールがうやむやになっていることに気づけやすいこと）、もうひとつは「脳内の作業メモリを解放できる」ということです。 「マジカルナンバー 5 - 7 」ということばがあるように人間の作業メモリは私たちが直感的に感じているよりも少ないので、目の前の作業への集中度を高めるには作業メモリを消費してしまうものはできるだけ外部化してしまうのが有効です。

工夫 2: 遅いマシンやアプリは使わない

挙動の遅いマシンやアプリ（ソフトウェア）は使わないようにすることも、フロー状態を増やすのに有効です。

利用できるマシンのマシンパワーが不足している場合は特に、なるべく軽量なアプリを使うようにします。

私の過去の例でいえば、オープンソースの Atom エディタが便利で一時期使っていたのですが、当時私が使っていたマシンでは、必要なプラグインを有効にするとキーボードやマウスでの操作に対するレスポンスがどうしても一瞬遅くなってしまうので、使うのを辞めました。 OpenOffice や LibreOffice も私の環境では レスポンスが操作に追いついてくれず小さなラグがどうしても発生する場合が多く、フロー状態獲得の妨げになっていると感じます。 レスポンスが遅いアプリはどうしても必要なとき以外は使わないようにするのがよいでしょう。

ただ、他のポイントでも共通して言えることですが、自分が使うマシンやアプリをプログラマが自由に選べるとはかぎりません。 自由に選べるような職場は今でもむしろ少数派でしょう。

このあたりに注目し過ぎると「うちの職場はなぜこんなにイケてないんだ！」というので逆にストレスが溜まるので（笑）、注意が必要です。 コントロールできない部分は仕方ないと思って諦めるか、理解のある職場にさっさと転職する等するのがよいでしょう。

工夫 3: 素早いレスポンスの得られるツールを使う

行っている作業に対するレスポンスがなるべく速く得られるツールを導入するのも有効です。

具体的な例としては、テキストエディタでリンタ機能（シンタックスエラーやコーディング規約違反を教えてくれる機能）を提供するパッケージを導入したり、なるべく高速なタスクランナーやテスティングツールを使ったり、というのがあるでしょう。

行動分析学（ Applied Behvior Analytis ）でよく言われることですが、フィードバックは「なるべくこまめに」「なるべく速く」というのが原則です。

自動テストランナーを使ってテストファーストで開発することのメリットのひとつは、この「素早いフィードバックが得られるのでフローにプラスに働く点」でしょう。

工夫 4: 十分なディスプレイ領域を確保する

マルチディスプレイを好むプログラマは多そうなので改めて説明する必要は無いかもしれませんが、十分なディスプレイ領域を確保するということもフロー状態にとって重要です。

この点に関しては、「ディスプレイのサイズが○インチ」「ディプレイの枚数が○枚」といった絶対的な基準よりも、行う作業と利用する UI に対して十分な領域があるかどうかという点が重要です。

例えば、ウェブサイト制作でプログラミングを行う場合は、大体 3 〜 6 つほどのウィンドウを立ち上げておく必要があります。 これらを互いに重ねずに常時表示しておけるスペースはできれば確保したいところです。

「操作スペース」と呼ばれるデスクトップ（仮想ディスプレイ）を複数持てる OS がありますが、これらを切り替えるには 0.x 秒の時間がかかります。 個人的には、操作スペースの切り替えは表示されているウィンドウ間を視線で移動するよりも遅いと感じるで、私は環境が許すかぎり常時表示する方を選びます。

私の経験では、ウェブサイト制作や物理シミュレーションの仕事の場合、 1 ディスプレイが 20 数インチならディスプレイ 3 枚までは領域が増えるのに伴って生産性が向上する感じがします（あくまでも主観です）。 ただ、「 MacBook の小さなディスプレイでも十分効率的に作業できる」という話も聞くので、このあたりは個人差が大きいのかもしれません。

工夫 5: タイピングやマウス操作を速くする

タイピングやマウス（タッチパッド）による操作をできるだけ速く・間違いなくできるようにするということも有効です。

タイピングの速度が上がると、頭の中のアイデアをコードとして表現するスピードが上がり、結果として、「アイデア」と「検証」の間の時間的距離が縮まります。 そしてこれは「フィードバックの速さ向上」に直結します。

タッチタイピングができない（その結果タイピングが遅い）プログラマの人をたまに見かけますが、とてももったいないと感じます。 タッチタイピングはきちんと練習をすれば個人差はあってもさほど時間をかけずに習得できるので、一生モノだと思ってさっさと修得してしまうのがよいかと思います。

注意点として、「文章を打つときのタイピングの速さ」と「プログラミングにおける操作の速さ」にはおそらく正の相関はあるものの必ずしも正比例はしないという点には気をつけておく必要があります。 プログラミングで行うキーボード操作には、「文章を打つ」以外の操作――ファイル編集時のファイル内の移動や一括操作、ファイル間の移動、検索、ウィンドウフォーカスの切り替え等ももろもろ含まれるので、文章の打ち込みとは異なります。

Vim や Emacs のコマンド操作に慣れていない人は、それらを一通りできるようになるだけで、フロー状態への入りやすさが大きく変わるのを感じられるでしょう。

工夫 6: ノイズを減らす

フロー状態の妨げを少しでも少なくするためには、ノイズを減らすということも有効です。 ここで「ノイズ」ということばは「プログラマの意識に影響するすべての不要な刺激」の意味で使っています。

切り口としては、聴覚・視覚・触覚・味覚・嗅覚の五感プラスアルファの視点で見るのがおすすめです。 こちらに関しては、具体例が無いとわかりづらいのですが、奥が深いというか細かくあげていくとキリが無いところもあるので、いくつかだけ例をあげることにします。

  • 聴覚
    • イヤホンや耳栓をして、話し声等の外の会話が聞こえないようにする。外部のノイズをキャンセルするために音楽を聞くときは、歌詞が無い音楽を選ぶ（歌詞が聞こえると脳が勝手に処理をしてしまうので）。
  • 視覚
    • ディスプレイ以外の部分で、気を散らすものが視界に入らないようにする。具体的には、デスク上を整頓する、余計なロゴがベゼルに付いていないマシンやディスプレイを選ぶ、等。
    • ディスプレイ内で、気を散らしたり作業メモリを無闇に消費したりするものを置かない。具体的には、デスクトップの壁紙を簡素なものにする、ディストラクションフリーモードのあるエディタやブラウザ拡張を使う、等。
    • 目に入る光の量や質を快適な範囲内に調整する。具体的には、窓からの外光、部屋の照明器具、ディスプレイの光を、明るすぎず暗すぎずで、体と目に負担の少ない状態にする。
  • 触覚
    • 身に付けるものに、肌刺激の少ないものを選ぶ。具体的には、縫い目がごろつかないシームレス肌着を選ぶ、肌環境が快適な化繊系やウール系の肌着・靴下を選ぶ、余計な締め付けの無い服を選ぶ等。
    • 体への負担の少ないオフィス家具を使う。具体的には、長時間使っても疲れが出づらい体に合ったデスクやチェアを使う、キーボードやマウスの機種や使い方・角度を工夫する、等。
  • 味覚
    • ノイズとなるような味が口の中に無いようにする。具体的には、味の濃い食事を摂った後は歯を磨く、口の中が不快な場合は口を濯ぐ、等。
  • 嗅覚
    • 不快な臭いがある場合は元を断つ等してそれをなくす。
  • プラスアルファ
    • 温度・湿度: 体が快適に感じるほどよい温度・湿度にする。
    • 呼吸: 呼吸を整える。鼻づまり等で呼吸がしづらい場合は解消するための対策を取る。
    • 食事: 血糖値が急激に変化して集中力を阻害するような食事は避ける。

工夫 7: 割り込みを減らす

人からの声がけや通知による割り込みを減らすのも有効です。 これはどちらかというと、「フロー状態に入る」のを助けるというよりも「一度入ったフロー状態を台無しにされる可能性を減らす」という面で有効な対策です。

声がけを減らすという視点でいうと、声をかけられても無視をするというのは人として無しなので（笑）、事前に周りの人たちの理解を得るために働きかける必要があります。 特に、異なる職種の人やフロー状態を日頃あまり経験していない人たちには、プログラマにとってフロー状態がどれだけ重要なものなのか直感的に理解しづらいところもあるので、「理解が無い」で片付けてしまうのではなく積極的に説明して働きかける必要があるものと思います。

通知という点でいうと、フロー状態に入りたいときには、問題の無い範囲で、マシン上の一切の通知を一時的にオフにしてしまうことも有効です。

ときどき仕事中にメールの受信箱を常時監視している人がいますが、それが業務上のルールや文化として仕方ない場合は別として、必要無いのにそれをしているのはとても非効率だと思います。

工夫 8: ポモドーロ・テクニックを使う

少し前に一部の人たちの間で小さなブームになりましたが、キッチンタイマーを使って時間を区切る「ポモドーロ・テクニック」（ Pomodoro Technique ）を使うのも有効です。

ポモドーロ・テクニックとは何ぞやというところについて乱暴に一言でいうと、

  • 作業時間を「 25 分の作業 + 5 分の休憩（ときどき長い休憩）」という小さなチャンクに区切って、
  • メリハリをつけてテキパキ仕事がしやすい環境を作る

というものなのですが、ポモドーロ・テクニックのポイントはこれだけではありません。 細かく説明する余力とスペースが今回は無いので、興味のある方は「ポモドーロ・テクニック」で検索するか次の Wikipedia のページ等をご覧になってみてください。

人間の特性はおもしろくて、「やることを決めて、時間を区切る」というこの単純なことがさまざまなメリットをもたらします。

まだ試したことの無い方は「なんだ、そんなことか」とバカにせずに一度 1 週間ほど実践してみてください。 ポモドーロ・テクニックのためのポモドーロタイマーアプリもたくさん出ているので、とても気軽に試すことができます。

工夫ポイントについては以上です。

例としてあげた各ポイントについても参考にしていただきたいのですが、それ以上に「いろんなやり方でフロー状態を促進できる」「工夫の余地はたくさんある」ということを知って「ひとつ取り入れてみようかな」と思っていただけなら幸いです。

プログラマがフローのために注意すべきこと

工夫できるポイントはいろいろありますが、逆に、注意点もあります。

私の経験談としてのいちばんの注意点は、これらの工夫ができない環境に置かれたときに逆にストレスが増えてしまうという点です。

「こうすれば改善できる」ということがわかっていて、何のデメリットもなく誰にも迷惑をかけずにそれができるのに、環境がそれを許さないことがあります。 レスポンスの速いマシンやアプリに馴れきってしまうと、 0.1 秒以下の小さなラグでも小さなプチイライラが起こります。 そんなプチイライラが雪のように積もる夜には 孤独で 君のからっぽの そのグラスを 満たさないで と口ずさんでしまうことになります。

また、人の感覚はおもしろいもので、ノイズを減らした環境が続くとそれに五感が適応してしまって、ノイズへの耐性が下がってしまいます。 ノイズの少ない状態にあまりに馴れてしまうと小さな刺激にも注意が向いてしまうようになるので、ちょっとしたセルフ減感作治療が必要になる場合もあるかもしれません。

追求し過ぎず、ほどほどに、がよいと思います。

リファレンス

最後にフロー理論・フロー研究の参考文献等をご紹介します。年は原著の出版年です。

書籍

ミハイ・チクセントミハイによるフロー理論本です。

  • モノの意味―大切な物の心理学
    • Amazon.co.jp
    • The Meaning of Things: Domestic Symbols and the Self
    • 1981 年
  • フロー体験 喜びの現象学
    • Amazon.co.jp
    • Flow: The Psychology of Optimal Experience
    • 1990 年
  • クリエイティヴィティ―フロー体験と創造性の心理学
    • Amazon.co.jp
    • Creativity: Flow and the Psychology of Discovery and Invention
    • 1996 年
  • フロー体験入門―楽しみと創造の心理学
    • Amazon.co.jp
    • Finding Flow: The Psychology of Engagement with Everyday Life
    • 1998 年
  • グッドワークとフロー体験―最高の仕事で社会に貢献する方法
    • Amazon.co.jp
    • Good Work: When Excellence and Ethics Meet
    • 2008 年

英語はそれぞれ原著のタイトルで、年は原著の出版年です。 並び順は、原著出版の時系列順です。

私の記憶が正しければ、最初の 2 冊でフローの一般論的なお話が、その後の書籍では領域を絞ったお話がされています。 「クリエイティヴィティ」では「創造性」を、「グッドワーク」では「仕事」と「職場」をテーマにしたお話が展開されています。 「グッドワーク」はどちらかというと経営者やマネージャ向けのお話がメインになっていました。 1998 年出版の「フロー体験入門」はフロー研究やポジティブ心理学が有名になったことを受けて改めて広い層に向けて書き直した入門書でした。

プログラマがこの中から絞って読むなら 2 冊読むことをおすすめします。 1 冊は「フロー体験入門」で、もう 1 冊は、専門職キャリアのプログラマなら「クリエイティビティ」、マネジメント寄りなら「グッドワーク」がおすすめです。

トーク

ミハイ・チクセントミハイ自身が 2004 年に TED で話している動画があります。

他のトークにも興味がある方は次の動画を見てみてもよいかもしれません。

次の動画は Biohacker Summit UK というイベントで 2016 年に行われたフローをテーマとしたトークを撮影したものです。 映像がきれいでとてもわかりやすいです。

ショートフィルム

私は今回この記事を書くまで知りませんでしたが、 2010 年にフローをテーマにしたショートフィルムが制作されていました。

リンク集

英語の Wikipedia の Flow のページのリファレンスが充実しています。

英語がよくて日本語が悪いというわけではありませんが、英語はこういった研究・学術的な情報が、ウェブ上できれいに整理されて公開されているのがよいですね。

記事 / ページ

次のページではフローをコンパクトに説明してあります。

プログラミング関連だと次のページ等がおもしろいです。

プログラミング歴の長い方であれば、最後の「 12 Steps to Better Code 」で「フロー」ということばを知ったという人も多いかもしれません。

プログラミングはフロー状態に入りやすい活動であり、フロー状態に入ることのメリットが大きい活動でもあります。 そういう背景から「プログラマのためのフローの説明」はいつか書きたいと思っていて、十分な時間とチャンスが無いまま数年が経ってしまいましたが、今回ようやく書くことができました。 よりよいプログラマになりたいと考えるプログラマの方々のご参考になれば幸いです :)

ということで、「プログラマのためのフロー理論のすすめ」でした。

追記 2018/08/13

Uncle Bob こと Robert C. Martin 氏は『 The Clean Coder 』の中で「フローはむしろ望ましい状態ではない」と語っています。

Here’s a little hint from someone whose been there and back: Avoid the Zone. This state of consciousness is not really hyper-productive and is certainly not infallible. It’s really just a mild meditative state in which certain rational faculties are diminished in favor of a sense of speed.

Let me be clear about this. You will write more code in the Zone. If you are practicing TDD, you will go around the red/green/refactor loop more quickly. And you will feel a mild euphoria or a sense of conquest. The problem is that you lose some of the big picture while you are in the Zone, so you will likely make decisions that you will later have to go back and reverse. Code written in the Zone may come out faster, but you’ll be going back to visit it more.

「フローは一見生産的に見えるけれど、フロー中はビッグピクチャー（俯瞰的な目）が失われたりするので、必ずしも生産的とはいえない」とのことです。 私はフロー推奨派ですが、この考えにも一理あると思います。

追記 2020/12/05

「フロー状態」と「ゾーン」の違い

ここで説明した「フロー状態」と「ゾーン」の違いについて間違った説明をしている記事が Google 検索で上位にひっかかるようです。 信じてしまう人もいると思うので、嘘が広まるのを防ぐため両者の違いについてここで説明しておきます。

「フロー状態」と「ゾーン」、この 2 つの言葉に大きな意味の違いはありません。 上の フローとは の説明のとおりどちらも同じ心理状態を指します。

厳密に言うなら、「フロー状態」というのは、旧来からスポーツの世界で「 in the zone 」と呼ばれてきた心理状態を、心理学者のミハイ・チクセントミハイ氏が心理学的に議論しやすいように定義した言葉です。 他方、「ゾーン」は「フロー状態」よりも前からある言葉で、スポーツの世界においてアスリートの意識が極度に集中した状態を表します。 「ゾーン」の方の起源は不明です（日本語の「没頭」「無我夢中」といった言葉の起源を辿るのが難しいのと同じように「ゾーン」の起源を特定するのは難しいのではないかと思います）。

少なくとも「フロー状態」を提唱したミハイ・チクセントミハイ氏自身は「フロー状態とゾーンはここが違う」といった説明はしていないはずなので、間違った情報に惑わされないように気をつけてください。

アバター
後藤隼人 ( ごとうはやと )

ソフトウェア開発やマーケティング支援などをしています。詳しくはこちら。