エンジニアリングマネージャーへのアドバイス: 開発者が(より)クリエイティブになれるようにすること

原文リンク(2024-02-29)

クリエイティブとは一体何なのか

ソフトウェアエンジニアとしてクリエイティブであるとは、具体的にどういうことなのだろうか。(1)独創的な仕事であり、(2)質が高く、(3)目の前のタスクに関連しているものをクリエイティブと呼ぶことができる。しかし、この見方は非常に不完全である。もし私が、若手のC#プログラマーとして初めてリフレクションを採用したとしたら、それは私にとっては独創的であっても、隣のベテラン開発者にとっては全く独創的ではないと見なされるかもしれない。

では、誰が品質を決めるのか、静的コード解析ツールか、同僚か、どれだろうか。関連性についても同じだ。このトピックだけで、技術的なコード・セッションにおける終わりのない口論が始まるかもしれない。このようなクリエイティビティの見方の最大の問題は、環境（チーム、［会社の］文化、社会、...）ではなく、クリエイティブな個人を明確に（そして部分的に間違って）強調していることだ。

幸いなことに、クリエイティビティを見るときには文脈も考慮に入れることができる。これはクリエイティビティを社会的評決へと発展させるもので、あなたのプログラミングの努力がクリエイティブと呼ばれるべきかどうかは、あなたの仲間が決めるのだ。

非常に漠然とした理論に聞こえるかもしれないが、これはソフトウェアエンジニアリングにとって具体的に何を意味するのだろうか。クリエイティビティに関しては、技術的知識、コラボレーション、制約、批判的思考、好奇心、創造的精神状態、特定の創造的テクニックの使用という7つのテーマが大きな役割を果たす。この記事では、これらのテーマのチームベースの文脈的特性に着目し、7つのテーマを促進するためにマネージャーができることを説明する。

さあ、飛び込もう。

クリエイティビティと技術性

まずは技術的知識である。いかにして知識を集め、内面化し、行動に移すか。増え続ける（誤った）情報の流れを管理するために、さまざまなパーソナル・ナレッジ・マネジメント（PKM）の手法が存在する。

という質問に対して、あるインタビュイーがこのテーマを完璧に要約した。「インプットがなければアウトプットもない。創造性とは、さまざまなインプットの積み重ねである」。

これらのテクニックの大半は、これらの「インプット」を効率的に収集し、最終的に知識に基づいて行動することでオリジナルの「アウトプット」を生み出すことを中心に展開される。では、これらを軌道に乗せるために、マネージャーは何ができるだろうか。最初のステップは、PKMツールの存在に注目させ、最近のプログラマーに要求される多くの技術的な習得を助けるために、これらがどのように使えるかを示すことだ。社内にWikiを設置したり、代替の情報源を探す手助けをしたり、ハッカソンや知識共有セッションの開催を通じてアイデアの相互交流を促進したりすることも、その一例である。

クリエイティブなコラボレーションを成功させる

コラボレーションはクリエイティビティにどのような影響を与えるのだろうか。今、私たちはマネジメントの領域にしっかりと足を踏み入れ始めている！ソフトウェアエンジニアリングはチームで行われるため、部分の総和を超えるような優れたチームをどのように構築するかが問題となる。いわゆる "ドリームチーム "を作るのに影響する要素は、ほんの少しではない。集団がなければ、各天才の創造性は遠くまで届かないのだから、「集団的クリエイティビティ」という言葉を使うこともできる。個人の創造力は、私たちがあえて認める以上に無視できるものなのだ。私たちは孤高のクリエイティブな天才を採用することを目指すのではなく、クリエイティビティを限界まで高めることができるような、異なる意見を持つ異質な集団の集合体を構築することに努めるべきである。クリエイティビティを促進し、惹きつける環境を構築すべきである。

言うは易く行うは難し。

マネージャーは、その壮大な目標に向かって簡単な行動を始めることができる。例えば、チーム内でのコミュニケーションがうまくいかなくなると、クリエイティブな流れが著しく阻害されるため、意思決定を促進する手助けをすることだ。研究者の Damian Tamburri氏は、この問題を "社会的負債 "と呼んでいる。技術的負債と同じように、社会的負債が多ければ、クリエイティブなことが起こるとは期待できない。マネージャーはコミュニティの羊飼いとして、負債を減らす手助けをすべきである。

Tamburri氏と彼のチームは、いくつかの素敵なコミュニティの傾向を発見した。「プリッギッシュ・メンバー」とは要求が多く、無意味に几帳面な人々で、不必要な遅れやフラストレーションを引き起こす。「ハイパーコミュニティ」とは、すべてが絶えず変化する、あまりに不安定な思考環境のことである。"新人のフリーライド "とは、新人が完全に独り占めされ、苛立ちや仕事のプレッシャーを引き起こすことである。社会的負債を低く抑えることで、開発者とチームは幸せになり、幸せな開発者はよりクリエイティブな開発者であることが研究で証明されている！

制約に基づく批判的クリエイティブ思考

次のクリエイティブテーマは、制約に基づく思考の利点である。一般に信じられていることとは逆に、適切な量の制約はクリエイティビティを妨げるものではなく、むしろそれを促進する！もちろん、適切な量に重点を置いている。

制約が少なすぎると、ほとんど何もできない。（気にしないで、決断する前にもう少しフレームワークで遊んでみよう。）

• 制約が多すぎると、ほとんど何もできない。（ハードウェアや既存のレガシーソフトウェアの制約とともに、非常に厳しい納期がプロジェクトの首を絞め、開発者を精神的に疲弊させてしまう。）

ここでのマネージャーの役割は明確である。自由度が高すぎる場合は、クリエイティブなスイートスポットに到達するために、開発者が自分で課した制約を活用できるように導き、制約が多すぎる場合は、制約を減らしたり曲げたりする手助けをすることである。確かに、簡単に曲げたり（部分的に）無視したりできる制約は多くない。

そして、典型的なクリエイティブプロセスの5つのステップに不可欠なものとして、クリティカルシンキングがある。参加する（あなたの90％の作業の蒸散）、インキュベートする（距離をとることでプロセスを中断する）、照らす（残りの10％の作業）、検証する（うまくいくか）、そして最後に提示する／受け入れる。

マネージャーの仕事は、この終わりのないフィードバックのループの中でプログラマーを導くことである。例えば、時々休憩を入れたり、必要な自己反省を促すために適切な批判的質問をしたりすることである。もうひとつ重要なのは、分散型思考モードと集中思考モードの違いだ。リファクタリング、再設計......など、開発時にさまざまな帽子をかぶることを考えてみればいい。しかし、すべての人があなたと同じように速く考えたり遅く考えたりするわけではないし、すべての人があなたと同じ集中モードに固定されているわけでもない。仲間（そしてチーム全体）の思考モードを警戒し、それらをうまく調整し合うことで、よりクリエイティブな結果が得られる可能性が高くなる。マネージャーは、この精神的な振動に特に注意を払い、全員が時間通りにギアを切り替えられるようにするべきだ。集中した思考を長時間続けると、クリエイティブなアイデアが増えるのではなく、疲れてしまう。開発者に休息を与えよう！

クリエイティブなマインドセットを育てるには

休憩といえば、次は好奇心旺盛なマインドセットを養うことだ。退屈な灰色のコンクリート板しかないオフィス環境では、このマインドは刺激されないだろう。快適な環境から抜け出すことは、（クリエイティブな）マインドセットにとって素晴らしいことだ。例えば、デスクを離れて散歩に出かけ、その嫌な問題について明確に考えないようにすれば、戻ってからその問題を解決できる可能性は2倍になるだろう。

好奇心を養うもうひとつの方法は、くだらないことを楽しくプログラミングすることだ。体験やセレンディピティ（偶然の発見）に対してオープンになることで、仕事上の問題を解決するために必要なつながりが生まれるかもしれない。（もちろん、コードの中で）ふざけることは、しばしば上司の顰蹙を買い、時間の浪費とみなされるが、実際にはチームのモチベーションを維持し、好奇心を刺激する、それはクリエイティブなプログラマーにとってとても必要なものだ。それはクリエイティブなプログラマーにとってとても必要なものだ。もうひとつ考慮すべきなのは、古典的なスペシャリスト対ジェネラリストの議論だ。もちろんどちらにも利点はあるが、マネージャーとしてのあなたの仕事は、専門化しすぎ（あるいは疲弊しすぎ）の兆候に注意することだ。その場合、開発者に別のスキルを身につけさせるよう、理想的にはペアプログラミングを通じて刺激することができるかもしれない。好奇心を持ち続けるよう、チームのモチベーションを高め続けよう。

次のテーマは、独創的で持続可能な解決策を導き出すために、クリエイティブな精神状態を活用することだ。人気のある「フロー」状態、クリエイティブな気分になる方法、深い作業と浅い作業の比較、中断への対処、クリエイティブな洞察の引き金となる方法などだ。

マネージャーとしては、正しい精神状態を促進する手助けをすることが重要だ。これは、チームメンバーが不必要な中断から多かれ少なかれ保護されていることを確認することを意味する。外部と内部の両方（あなた自身を含む！）これを支援するために、「邪魔をしない」時間の導入や、オープンな景観のオフィスからの移行など、中断の準備と対処のためのいくつかの実用的なツールを展開ができる。また、クリエイティブな洞察のきっかけについて考えるとき、これは一人でやるものなのか、それとも二人でやるものなのか。いつものように、これは文脈や状況による。

創造的な精神状態を奨励し、クリエイティブな精神状態を奨励し、クリエイティブが刺激されるような企業文化も、間違いなく助けになるだろう。ところで、オープンな職場はクリエイティビティにとって有害だが、閉鎖的な小さなデスクも同様だ。その代わり、オフィスは閉鎖的なサブ環境のクラスターのように設計されるべきで、そこで人とぶつかったり、アイデアを交換したりすることが、常にお互いの邪魔にならないようにする必要がある。マサチューセッツ工科大学（MIT）の20号館は、その端正な建築例である。

クリエイティブなツールボックスの構築を支援する

最後になるが、マネージャーは開発者が、行き詰まったときにズームアウトやズームインをしたり、問題の最初ではなく最後から始めるなど、特定のクリエイティブテクニックのツールセットを構築するのを助けることができる。ここでの最良の候補は、他の領域から借用したツールである。例えば、作家が創造性を高めるために使う様々な文章術のように、プログラミングの世界にも応用できるものである。アイデアの借用に関しては、Austin Kleon氏の言う「良い盗用」と「悪い盗用」がある。

タンブーリのコミュニティ・シェパードのように、マネージャーは以下のようなことに注意すべきである。特にChatGPTやGitHub CopilotのようなAI支援によるコード生成ツールの台頭により、ソフトウェアエンジニアリングにおいて倫理的配慮がますます重要な役割を果たすようになっている。

まとめ

この記事では、クリエイティブなプログラマーの7つの中心的なテーマである「クリエイティビティと技術性」「クリエイティブなコラボレーションを成功させる」「制約に基づく批判的クリエイティブ思考」「クリエイティブなマインドセットを育てるには」「クリエイティブなツールボックスの構築を支援する」を促進するためにマネージャーができることをまとめた。

もっとも重要なことがひとつある。他の筋肉と同じように、クリエイティビティは訓練し、学ぶことができるスキルであることを同僚に認識させることだ！

多くの若手プログラマーは、自分がクリエイティブかそうでないかのどちらかだと思っているが、実際はまだクリエイティブではないかもしれない。マネージャーにできることがあるとすれば、クリエイティビティは忍耐によって、培うことのできる達成可能なスキルとして認めさせることである！もちろん、クリエイティビティのレベルはプロジェクトや人によって異なるだろう。その上、クリエイティビティは常に進化し、文脈に左右される。しかし、ひとつだけ持ち帰る必要があることは、それは誰もがクリエイティブなプログラマーになれるということだ。