シニシズム(cynicism、皮肉)、懐疑主義、楽観主義といった態度は、プロダクトを開発する方法に影響する。開発を阻害したり、あるいは誤ったプロダクトの構築に導く可能性があるため、態度を認識することは重要だ。
Gwen Diagram氏はLean Agile Exchange 2020で、"Cynicism Doesn't Build Products"と題した講演を行う予定である。このカンファレンスはオンラインで、9月10～11日に開催される。
Diagram氏によると、シニシズム、懐疑主義、楽観主義は、いずれも過剰な場合には危険なものである。シニシズムは優れたプロダクトの開発を阻害し、懐疑論的な疑問はビジョンを持った人を諦めるまで問い詰め、楽観主義は誤ったリーダの後を追うことになるからだ。優れたプロダクトを構築するためには、これらの考え方を部分的に具現化することが必要だ、とDiagram氏は指摘する。
文化はソフトウェア構築における大きな部分であり、～性(テスト性、可観測性、アクセス可能性など、挙げれば膨大なリストになる)の欠如や、人々が恐ろしくて疑問を持てないような選択肢といったものの有無において、ソフトウェアを開発する方法を決定的に変えるものだ、とDiagram氏は考えている。チームメンバがひとつの価値観に偏り過ぎていることは、プラットフォームの品質や成功に負の影響を及ぼす可能性がある。
世界中で動作するソフトウェアを構築することで、開発者は世界を変えることができるのだ、とDiagram氏は説明する。
私たちは現代的なビルディングを建築しているのです。ただしそれは物理的なエンティティではありません。オンラインのビルディングなのです。私たちには、私たちが何を建築しているのかを問い、それが社会にとってベストなものであることを確認する能力があります — しかしながら、一切の疑問を持たない、という選択肢もあるのです。可能な限り倫理的なソフトウェアを求め、構築することを通じて、私たちは間違いなく、世界を形作る機会を得ることになります。
Gwen Diagram氏に、シニシズム、懐疑主義、楽観主義と、開発者が与え得る影響、チームにおける態度への対応などについてインタビューした。
InfoQ: シニシズムをどのように定義しますか？懐疑主義についてはどうでしょう？
Gwen Diagram: シニシズムの定義は、過去2,000年の間に大きく変わりました。固有名詞としてのシニシズム(Cynicism)は、もともとはアンティステネス(Antisthenes)によるものですが、明確にしたのは弟子であるディオゲネス(Diogenes)です。現代のサイニクス(Cynics — アンティステネスの学派)と位置付けられるであろう人々もいます。興味深い(と同時に恐ろしい)現代のサイニクスとして挙げられるのが、80年代のパンクシーンにおいて、あまりにもシニカルなために当時のニューヨークのパンクシーンの多くから拒絶されたGG Allinです。固有名詞としてのシニシズムとは、美徳とともに生きることであり、普通名詞のシニシズム(cynicism)は、自分のもの以外の思想を拒絶することです。仕事をする上で、ギリシャ的定義の固有名詞のシニシズムにお目にかかることはめったにありませんが、普通名詞のシニシズムはいくらでもあります。
シニシズムによる疑問がクローズドマインドであるのに対して、懐疑主義的な疑問はオープンマインドです。強固な意見を持つでも、大雑把な決り文句がある訳でもない懐疑主義者は、好奇心を持ち、自身の考えを変えることにもオープンです — ただし、証拠を見せられた場合に限ります。
シニシズムも無視することはできません。プロダクトを開発すべきではない — 例えば、ソーシャルメディアを見れば十分だ、という場合もあるのですから！
InfoQ: アプリケーションの書き直しに着手した時、懐疑主義がどのように役立つのでしょうか？
Diagram: 以前に開発したものを完全に無視するのではなく、オープンマインドにコードを見る上で有用です。何が書かれているのかを疑問視し、前回の開発から教訓を得ることにより、既存機能を部分的に取り込んで、その上に構築する方法が可能になります。アプリケーション開発には長い時間を要します。レガシシステムをスクラップ・アンド・リビルドすれば、リビルドの開発中は金を稼ぐことができません。ほとんどの場合、レガシシステムがあなたの給与を払っているのですから、これは見過ごせない問題です！ただし、再開発を始める前に、レガシソフトウェアの基礎部分は理解しておいてください。不安定な砂の上に構築すれば、不安定なシステムが容易に出来上がってしまいます。
InfoQ: 楽観主義によるソフトウェア開発は、どのようなものになるのでしょう？
Diagram: 楽観主義によるソフトウェア開発で私が見た最悪のケースは、カスタマへの確認や可観測性を考えずに、自分たちの開発しているものに問題がないと盲目的に信じ込む、というものです。それよりも多い、楽観主義でよく見られる失敗のほとんどは、管理やログをほとんど、あるいはまったく用意していなかったり、リリース計画がビッグバン形式であったり、ステークホルダが少しねじれた事実に乗せられているような場合です。
自分自身の作業に疑いを持って、確認し、監視した、少しずつ頻繁にリリースするべきでしょう。
InfiQ: チームメンバの態度に原因のあるような問題がチームに起きている場合は、どうすればよいのでしょう？何かアドバイスがありますか？
Diagram: チームの成功の妨げとなるような態度を特定するには、率直な会話を交わして、チームメンバに発言する機会を与えることが非常に有効です。ただし、チームメンバの態度には、常に注意すべき価値があります — あなた自身がこうあってはならないというものを、彼らが示しているかも知れないからです！
しかし、その態度が一種のいじめであって、他の人たちのアイデアを妨害したり、他のチームメンバにとってよくないものである場合には、文化をチェックするべきです。そのような人物が雇用されたのは、どのような経緯によるものなのでしょうか？組織の文化がそのような振る舞いを助長するようなものであるならば、自分にあったもっとよい場所を探した方がよいかも知れません。あなたが文化を変えることは可能でしょうか？そうならば、多様性と包括性によって変革を起こしましょう。ひとりが大声を上げて他の人たちを黙らせるのではなく、全員が声を上げることが大切です。