スティーブン・ウルフラムが自社の業務をライブ配信することにした理由

公の場で考える

私は30年以上もWolfram ResearchのCEOを務めています。しかし、実際にはどのような仕事なのでしょうか？普段はどんなことをしているのでしょうか？もちろん、一生懸命働いています。しかし、私と同じような規模のテクノロジー企業のCEOとしては、特に典型的なタイプではないと思っています。なぜなら、私の時間の大部分は、製品の設計やアーキテクチャ、そして製品の機能について検討する最前線で費やされているからです。

30年前は、ほとんど一人で仕事をしていました。しかし今では、ほぼ常に800人ほどの従業員からなるグループと仕事をしています。私は物事をインタラクティブに進めるのが好きです。実際、ここ15年ほどは、私がよく「公の場で考える」と呼んでいる、他の人たちとの会議の中で問題を解決し、意思決定を行うことに多くの時間を費やしてきました。

よく、これがどのように機能するのか、会議では実際に何が行われているのかと聞かれます。そして最近、気づいたのです。実際の会議をライブ配信する以上に、人々に見て（そしておそらくは知ってもらうために）良い方法はないのではないか、と。そこで、ここ数ヶ月、社内会議を40時間近くライブ配信してきました。これは、私が何をしているのか、そして製品がどのように作られているのかを、舞台裏で皆に見せることにつながっています。（もちろん、ライブ配信はアーカイブ化されています。）

意思決定を見る

世の中では「会議では何も進まない」とよく不満を言う人がいます。しかし、私の会議はそうではありません。実際、私が関わる製品設計会議では必ず重要なことが決まり、少なくともいくつかの重要な決定が下されていると言っても過言ではありません。例えば、今年はWolfram言語に250以上の全く新しい関数を追加しました。これらはすべて私の会議で決定されました。そして、関数の設計、名前、あるいはアイデアそのものが、会議の中でその場で決定されることも少なくありません。

私たちの会議には常にある種の知的な緊張感があります。1時間ほどの会議で、しばしば複雑な問題に取り組み、ある分野への深い理解を要します。そして最終的に、非常に長期的な影響を及ぼすようなアイデアや決定を導き出します。

過去30年以上にわたり、Wolfram言語の統一性と一貫性を維持するために、私は懸命に努力してきました。しかし、毎日、言語に追加する新しい機能について決定する会議に出席しています。私たちが設定した基準を維持し、今日の決定が将来にわたって役立つようにすることは、常に大きな挑戦であり、大きな責任でもあります。

ニューラルネットの記号フレームワークに関するものかもしれません。あるいはデータベースとの統合に関するものかもしれません。あるいは複雑なエンジニアリングシステムの表現方法。あるいは関数型プログラミングのための新しいプリミティブ。あるいは新しい形式の地理可視化。あるいは量子コンピューティング。あるいはメールサーバーとのプログラムによるインタラクション。あるいは分子の記号表現。あるいは、Wolfram言語が現在カバーしている、あるいは将来カバーするであろう無数のトピック。

特定の領域における重要な機能は何でしょうか？それらは他の機能とどのように関連しているでしょうか？適切な名前が付けられているでしょうか？一見相容れないデザインの制約にどう対処すればよいでしょうか？人々はこれらの機能を理解できるでしょうか？関連するグラフィックやアイコンは、可能な限りわかりやすく、洗練されたものになっているでしょうか？

今では、こうした問題解決に40年近く携わってきました。一緒に仕事をする人たちの多くも、非常に経験豊富です。通常、会議は、物事がどのように機能すべきかについての提案から始まります。時には、提案内容を理解し、じっくり考え、そして確認するだけのこともあります。しかし、多くの場合、私たちが設定した基準を維持するために、解決しなければならない現実的な問題がまだ残っています。そして、会議は何度も行き来し、何らかの問題に取り組みます。

アイデアは出てきますが、たいていは却下されます。時には完全に行き詰まったように感じることもあります。しかし、会議の参加者全員が、これは単なる演習ではなく、真の答えを出さなければならないことを理解しています。時には類推を試みることもあります。似たような問題を過去に解決した事例を探すのです。あるいは、根本原理、つまり問題の核心に立ち返り、すべてを最初から理解しようと主張することもあります。参加者は詳細な学術的または技術的な知識を山ほど持ち出しますが、私は通常、その知識が私たちに伝えるべき本質を抽出しようと努めます。

基準がもっと低ければ、確かにずっと楽になるでしょう。しかし、委員会の妥協案のような結果を求めているわけではありません。私たちが求めているのは、時の試練に耐えうる、真に正しい答えです。そして、そのためにはしばしば真に新しいアイデアが必要になります。しかし、最終的には、通常、非常に大きな満足感が得られます。私たちは多くの労力と思考を注ぎ込み、最終的に解決策を導き出します。それは本当に優れた解決策であり、真の知的達成と言えるでしょう。

通常、これらはすべて社内で非公開で行われます。しかし、ライブストリーミングでは、誰でもその様子を見ることができます。関数の名前が決まったり、問題が解決したりする瞬間を見ることができるのです。

会議はどのようなものですか?

ライブストリームを視聴すると、実際に何が起きているのでしょうか？実に多岐にわたります。Wolfram言語の新しい関数が試されている様子（多​​くの場合、数日、あるいは数時間前に作成されたコードに基づいています）を目にするかもしれません。ソフトウェアエンジニアリング、機械学習のトレンド、科学哲学、ポップカルチャーの問題への対処法、概念上のバグを修正するには何が必要かといった議論を目にするかもしれません。新しい分野が始まったり、Wolfram言語のドキュメントの特定の部分が完成したり、最終的なビジュアルデザインが完成したりするのを目にするかもしれません。

私たちの会議には、アクセントも経歴も専門分野も実に多様な人が集まります。そのため、当初必要だとは思っていなかった特定の専門知識を持つ人を追加で招聘する必要が生じることも珍しくありません。（会議に呼ばれて、これまで当社に関係があるとは全く知らなかった珍しいトピックの詳細について質問されても、誰も驚かないという当社の社風は、少し魅力的だと思います。）

当社は地理的に非常に分散した企業です（私は1991年からリモートCEOを務めています）。そのため、基本的にすべての会議はウェブ会議で行っています。（音声と画面共有は使用していますが、モバイルデバイスや本、紙に描いた絵を見る場合を除いて、ビデオ会議はあまり役に立ちません。）

ほとんどの場合、私の画面を見ていますが、時には他の人の画面を見ることもあります。（他の人の画面を見る最も一般的な理由は、今のところその人のマシンでしか動作していないものを確認するためです。）ほとんどの場合、私はWolframノートブックを使って作業します。通常、ノートブックには最初のアジェンダと実行可能なWolfram言語コードが入っています。そこから作業を開始しますが、その後、ノートブックを修正したり、新しいノートブックを作成したりします。デザインのアイデアを試していることもよくあります。他の人からコードの一部を送ってもらって実行したり、自分でコードを作成したりします。メインのドキュメントをライブ編集したり、グラフィックデザインがリアルタイムで行われているのを見たりすることもあります。

私たちの会議の目標は、可能な限り物事を終わらせることです。必要な意見を持っているすべての人とリアルタイムで相談し、何かに関するすべてのアイデアや問題を解決することです。確かに、後になって誰か（時には私自身）が、私たちが理解したと思っていたことが間違っていたり、うまく機能しなかったりすることに気づくこともあります。しかし、幸いなことに、それはかなり稀です。おそらく、私たちの会議の運営方法のおかげで、リアルタイムで物事がうまく議論されるからです。

私たちの会議に参加する人たちは、とても率直な意見を言う傾向があります。何かに同意できない場合は、必ずそう言います。私は、会議の参加者全員が自分にとって重要なことは何でも理解していることを強く望んでいます。そうすることで、参加者の考えや判断から得られるメリットを享受できるからです。（そのため、私は「分かりましたか？」「私の言っていることは分かりますか？」といった言葉を多用しがちです。）

もちろん、物事を理解するのが早い、非常に優秀な人材がいることは、本当に助かります。それに、会​​議の主要議題が一つであっても、話を進めるためには全く別の話題に飛び込まなければならない可能性が非常に高いことは、今では誰もが理解しています。これに対応するには、ある程度の知的敏捷性が必要ですが、少なくとも、それ自体が実践し、培うべき素晴らしいことだと思います。

私にとって、これほど多くの異なるトピックに取り組むことは、非常に刺激的です。一日の中でも、数時間ごとに大きく異なるテーマに取り組むことも少なくありません。大変な仕事ですが、同時に楽しいことでもあります。そして、もちろん、ユーモアもたっぷりあります。特に、最終的に議論する具体的な例（たくさんの象やカメ、そして奇妙な使用シナリオ）には、ユーモアを感じます。

会議の規模は2、3人から20人程度まで様々です。議論の内容が変化するにつれ、会議の途中で参加者が増減することもあります。特に、複数のグループにまたがるプロジェクトに関する大規模な会議では、通常1人以上のプロジェクトマネージャー（私たちは「PM」と呼んでいます）が出席します。PMはプロジェクト全体の流れ、特に貢献が必要な複数のグループ間の調整を担当します。

ライブストリームをお聴きいただくと、ある程度の専門用語が出てくることにお気づきいただけると思います。その中には、ソフトウェア業界ではよくある用語（UX = ユーザーエクスペリエンス、SQA = ソフトウェア品質保証）もあります。また、当社特有の用語、例えば部門の略語（DQA = ドキュメント品質保証、WPE = ウェブプロダクトエンジニアリング）や社内用語（XKernel = Wolfram言語のプロトタイプビルド、pods = Wolfram|Alphaの出力要素、pinkboxing = 表示できない出力を示す、knitting = ドキュメントの相互リンク要素）なども出てきます。もちろん、会議中に新しい専門用語や新しい名称が生まれることもあります。

私たちの会議は通常、かなりテンポが速いです。アイデアが出てくると、すぐに皆がそれに反応します。そして何かが決まるとすぐに、人々はその決定に基づいてさらに発展させ、さらに深く考え始めます。これは非常に生産的で、見ていてとても興味深いプロセスだと思います。会議の参加者が持つ経験の基盤がなければ、アイデアが飛び交いすぎて何が起こっているのか把握できないように見える場面もあるでしょう。

ライブストリーミングのプロセス

社内会議をライブストリーミングするというアイデアは新しいものです。しかし、私はこれまで何年もの間、他の目的でライブストリーミングをかなり行ってきました。

2009年にWolfram|Alphaを立ち上げた際、サイト公開のプロセスをライブ配信しました。（何か問題が起きた場合、「サイトが利用できません」というメッセージを表示するのではなく、実際に何が問題だったのかを皆さんに見せる方がよいと考えました。）

リリースした新しいソフトウェアのデモや探索をライブ配信しました。コードを書いたり、「計算論的エッセイ」を書いたりといった作業もライブ配信しました。（息子のクリストファーは間違いなく私よりもWolfram言語のプログラマーとして速く、彼も自分のコーディングの様子をライブ配信しました。）また、WolframサマースクールやWolframサマーキャンプでのライブ実験もライブ配信しました。

しかし、最近までライブ配信は基本的に一人で行っていました。他の人をライブ配信に招くことはありませんでした。しかし、社内のデザインレビュー会議は以前からとても興味深いと思っていたので、「他の人にも聴いてもらえるようにしたらどうだろう？」と考えました。正直に言うと、最初は少し不安でした。というのも、これらの会議は会社の業務の中核を成すものであり、何があっても足を引っ張られるわけにはいかないからです。

だから私は、会議はライブ配信であろうとなかろうと、同じ内容でなければならないと主張してきました。ライブ配信の場合、私がすぐに譲歩するのは、会議の大まかな内容を数行の導入文で説明することです。そして嬉しいことに、会議が始まると、参加者（私も含めて）はライブ配信であることをすぐに忘れてしまい、会議で進行している（たいていはかなり緊迫した）内容に集中するようになります。

会議をライブ配信すると面白いことが起こります。それは、視聴者とリアルタイムでテキストチャットができることです。多くの場合、質問や一般的な議論が行われますが、時には私たちの行動や発言に関する興味深いコメントや提案が寄せられることもあります。まるで、即席のアドバイザーやフォーカスグループが、私たちの決定についてリアルタイムで意見やフィードバックをくれるかのようです。

実際のところ、会議の主要メンバーは会議自体に集中しすぎていて、テキストチャットの対応に時間をかけられません。そこで、テキストチャットの対応を別の担当者に任せ、最も関連性の高いコメントや提案を少数提示するようにしています。この方法はうまく機能しており、実際、ほとんどの会議で視聴者から少なくとも1つか2つの良いアイデアが生まれ、すぐに私たちの思考に取り入れることができます。

ライブストリーミングは、リアリティ番組のようなものだと考えることができます。ただし、ライブでリアルタイムである点が異なります。録画された素材については、体系的な「放送時間」を設定する予定です。しかし、ライブ配信には、会議が実際に行われている時間帯に配信しなければならないという制約があります。私は様々な業務を抱えており、スケジュールが非常にぎっしりと詰まっていて複雑です。そのため、特定の設計レビュー会議をいつ開催できるかは、特定のコードや設計作業がいつ完了するかによって決まることがよくあります。

また、会議に参加する他の様々な人々の都合にも左右されます。彼らはそれぞれに制約があり、多くの場合、様々なタイムゾーンに住んでいるからです。他の方法も試してみましたが、現在最も一般的なのは、設計レビュー会議は実際に開催される直前、通常は1～2日前にスケジュールすることです。私自身は日中だけでなく夜間も仕事をしていますが、設計レビューは米国（東海岸）の就業時間中にスケジュールされることが多いです。なぜなら、会議に出席しなければならない全員、そして専門知識が必要な場合に呼び出される可能性のある人々の手配が最も容易な時間帯だからです。

ライブストリーミングの観点から言えば、関連する会議のスケジュールをより予測可能にできればよいのですが、会議はそれ自体で最大限の生産性を実現するように設定されており、ライブストリーミングは単なる追加機能にすぎません。

Twitterを使ってライブ配信の事前告知をしようとしていますが、結局のところ、ライブ配信の開始時刻を最もよく知らせてくれるのは、私たちが利用しているライブ配信プラットフォームTwitchからの通知です。（確かにTwitchは現在主にeスポーツに利用されていますが、私たち（そしてTwitch）は他の用途にも活用されることを期待しています。eスポーツに注力していることで、画面共有技術は非常に向上しています。不思議なことに、私はTwitchのことをずっと前から知っていました。2005年の最初のY Combinator Demo DayでTwitchの創設者たちと出会い、その前身であるjustin.tvを使ってWolfram|Alphaのローンチをライブ配信しました。）

仕事のスタイル

私の仕事の全てがライブストリーミングに適しているわけではありません。会議などで「公の場で考える」だけでなく、「私的に考える」時間も費やしています。例えば、ただ文章を書いたりするなどです。（実際、著書『A New Kind of Science』の執筆中は、10年以上もの間、ほぼ「私的に考える」ことしかしていませんでした。）

ある週のカレンダーを見ると、色々な予定が混在しています。毎日、ライブ配信しているようなデザインレビューが少なくとも1、2件は入っています。また、様々なプロジェクトの進捗に貢献するため、プロジェクトレビューもかなりの数あります。さらに、戦略や経営に関する議論や、ごくたまに社外とのミーティングもあります。

当社は研究開発に非常に力を入れており、最高の製品を作ることに尽力しています。それは私の時間の使い方、そして商業的価値よりも知的価値を重視していることにも反映されています。長年勤めてきた私が、ライブストリーミングで配信している設計レビューに見られるような詳細なレベルにまで関与しているはずがないと思う人もいるかもしれません。

でも、肝心なのは、Wolfram言語を長期的に見て最良の方法で設計しようと懸命に努力しているということです。40年間ソフトウェア設計に携わってきたので、かなりの経験があります。ですから、作業は速く、ミスもほとんどしません。もちろん、今では社内には他にも優秀なソフトウェア設計者が大勢います。しかし、Wolfram言語の設計において最も経験豊富で、システム全体を最も包括的に捉えているのは、やはり私です（だからこそ、設計レビュー会議では、関連する様々な設計作業を繋ぎ合わせることに時間を費やしてしまうのです）。

はい、もちろん、細かいことにも関わります。あのオプションの名前は何にすべきか？あのアイコンは何色にすべきか？特定の特殊なケースでこの関数は何をすべきか？もちろん、これらの問題はどれも私がいなくても何らかの方法で解決できるものです。しかし、かなり短い時間で、私たちが持っているものが、今後何年にもわたって築き上げ、誇りに思えるものになるよう、確実に貢献することができます。そして、これは私にとって、良い、そして価値のある時間の使い方だと考えています。

会議の様子をライブストリーミング配信することで、このプロセスを皆さんに公開できるのは楽しいですね。Wolfram言語の開発過程について、少しでも理解を深めていただければと思っています（確かに、ソフトウェア設計は世間からあまり注目されず、失敗に終わった時に初めて気づかれることが多いので、実際に何が行われているのかを見せられるのは嬉しいですね）。

ある意味、Wolfram言語の設計は、計算的思考の非常に凝縮された、高度な例と言えるでしょう。私たちの会議を視聴することで、人々が計算的思考を自ら実践する方法をより深く理解してくれることを願っています。

現在ライブストリーミング配信している会議は、現在開発中のWolfram言語などの機能に関するものです。しかし、私たちはソフトウェアのリリースを積極的に進めているため、ここでお話ししている内容が実際に動作する製品としてリリースされる日もそう遠くないはずです。そして、そうなった時には、非常にユニークな体験ができるはずです。なぜなら、これまでで初めて、参加者は何が完成したかを確認できるだけでなく、録画されたライブストリーミングを視聴して、どのようにしてそれが実現されたのかを見ることができるようになるからです。

これは、強力な知的活動の形態を記録した、興味深くユニークな記録です。しかし、私にとっては、毎日参加する魅力的な会話の一部を共有できること自体が、すでに素晴らしいことです。そして、非常に実践的なCEOとして過ごす時間は、Wolfram言語やその他の開発中のものを発展させるだけでなく、世界中のより多くの人々を教育し、そしておそらく楽しませることにも直接貢献できると感じています。

スティーブン・ウルフラムは、Mathematica、Wolfram|Alpha、そしてWolfram言語の開発者であり、『A New Kind of Science』の著者であり、Wolfram Researchの創設者兼CEOです。40年近くにわたり、彼は計算思考の開発と応用における先駆者として、科学、技術、ビジネスにおける数多くの発見、発明、そして革新に貢献してきました。この記事は元々、スティーブン・ウルフラムのブログに掲載されたものです。