Debianプロジェクトの新リーダSam Hocevar氏に対する初インタビュー
Hocevar氏が選出された今回の選挙においては、Debianコミュニティにおけるユーザや開発者のUbuntuへの流出が懸念されており、活動効率の改善および組織的な分裂状態への対策が求められていた時期と重なっていたと表現できるかもしれない。Linux.comは先日、電子メールを介した形ではあるが、DPL選出後におけるHocevar氏への最初のインタビューとして、同氏がこれから直面するであろう各種の課題についてどう取り組むつもりであるのかを質問してみた。
Linux.com：Debian Project Leaderとして最優先すべき課題は何だとお考えですか？
Sam Hocevar：最初に行うべきは、共同作業を妨げているコミュニティ内部の意見対立の現状を把握することだと考えていますが、組織的な変更を施すとしても、意見交換をより重視した形で進める必要が最低限あると思っています。
私が掲げていた公約の中でも、当座は社会的側面の活動に集中するつもりですが、それはこの種の作業は時間を要するものだからです。公約の中には技術的側面の活動に関するものもありますが、その種の作業は選挙結果を待つことなく進められる性質のものですし、実際そうなっています。例えばバグトラッキングシステム用のWebインタフェースについては、Google Summer of Codeプロジェクトを利用した開発を行う予定ですが、現状でもデバッグ用インフラストラクチャで使うためのツールの1つは開発途上にありますし、Webサイトに対する改善案も色々と提出されています。
LC：選挙時の公約の中では、Debianが今日抱える問題点として「保守主義的な風潮」、「統制的な傾向を示す人々」、「ごく一部の人間に対する権限の過度の集中」などを指摘しておられました。この点を詳しくお聞きしたいのですが？
SH：一般論として、保守主義的な風潮が蔓延している状況で権限が過度に集中していると、プロジェクトの発展を大きく妨げる危険性が高くなります。Debianの場合はそれほど危機的な状況には置かれていませんが、これは優秀な人材の手に権限が委ねられており、そうした人々は“Debianにとって何がベストであるか”という意識で活動しているからに他なりません。ただし過去に何度も指摘されている通り、スケジュール的な遅延の慢性化や効率面での不備がしばしば顕在化しているのも事実です（より短期間で達成できた性質のタスクであったはずであるとか、提出したリクエストが無視されたなどの指摘です）。
またあまり公に論じられない性質の話題ですが、「開発者の1人が自動車事故にでも遭遇したらどうなるか」という問題もあります。実際、過去のDebian開発者の中には既に亡くなられた方もおられますし、現在残っている人間も歳を取っていくのは避けられませんから、関係者の人数が増えるほど不幸な出来事の到来には備えておく必要があるはずです。人間は誰でも歳を取るという話を続ければ、「開発者の1人がプロジェクトへの関心を無くしたり、フルタイムの職業に就いたり、家庭や子供を持ったりしたらどうするか」という場合も同じような問題が生じてきます。そうした観点から私は、新メンバの補充は常に必要だと主張しているのです。そうした人々には、パッケージのメンテナというだけではなく、コアスタッフとして活動してもらう必要があるでしょう。こうした問題は今から手を打っておかないと、いざとなった時に途方に暮れることに成りかねません。
LC：Debianプロジェクトの活動にはチームワークの育成が必要だというのは、どういう理由に基づいているのでしょうか？ また具体的な育成法として何を考えておられますか？
SH：あるタスクが手を付けられないまま長期間放置されている場合、その原因は往々にして担当者に時間を割く余裕がなかったためであって、それをこなせる別の人間が存在していたにもかかわらず、必要な権限がなかったために実施できなかったというケースが多々見られます。その種の問題は、チームとしてサポートをするように態勢を改めれば軽減されるはずです。結局のところ現状は、何らの対策も執られないまま、同様の事態が繰り返し起こり続けているのだと言えるでしょう。
選挙時の公約の中でも触れていたのですが、私からの要望として“パッケージは（担当メンテナの）所有物である”という意識を薄めていきたいと考えています。それを強制する権限が私にある訳ではありませんが、守備範囲外のパッケージであっても進んでバグフィックスをしたり、担当メンテナ以外の人間によるアップロードをすることを奨励することや、メンテナンス上の問題のあるパッケージに対する監視チームを組織することはできるはずです。メンテナの方々からすると、こうした行為は自分たちの能力を疑われるのに等しく、悪意に満ちた活動だと感じられるかもしれませんが、そう感じる背景にある意識そのものも変えていく必要があるでしょう。
またこうした提案に対する反論として、“チームの全体責任であれば、間違いをしでかしても誰かが始末を付けてくれるだろう”という態度でぞんざいな仕事をする人間を生み出すことになり、無責任な行為を助長する可能性がある、という意見がでてくるかと思います。私としてもそうした意見に異論はありませんが、そもそも誰でも好き勝手し放題にすることを提案するつもりはありません。チームに所属させる人員にある程度の配慮をしておけば、デメリットよりもメリットの方が遥かに大きくなるはずです。
パッケージ管理に関する問題の存在を意識してもらえるようになれば、チームとして管理することのメリットは即座に理解してもらえるでしょう。また、チームとしての活動は性に合わないという場合でも、そうした人々が単独で行うパッケージ管理が適切なものであれば、それはそれで問題ないとも考えています。
LC：新たにパッケージメンテナとなる人々をDebianプロジェクトに参加させるまでのプロセスとしては、どのようなものを想定しておられますか？ その構想を軌道に乗せるまでの具体的なステップは、どのようなものになるでしょうか？
SH：新しいメンテナの育成プロセスは、充分に時間をかけてメンテナの意欲を引き出すことを想定しているので、多くの方々からの指摘にある通り、このプロセスはかなりのスローペースで進捗することになるでしょう。
そうした中でも一番の長時間を要するステップの1つは、Debian Account Manager（DAM）による承認待ちの時間でしょう（Debian憲章の規定では、メンバのプロジェクトへの参加にはDAMの承認が必要とされています）。その意味で、DAMの要員ないしはDAMの作業時間をより多く割り当てる必要があると思っています。かつてのリーダ達もそうでしたが、こうしたプロセスの効率については様々な改善が試みられており、そうしたプロジェクトは私も引き継いでいくつもりです。
残念なことに新規のメンテナチームについては、順調な滑り出しを迎えているとは言い難い状況です。現状において大半の時間がApplication Manager（AM）の任命待ちに費やされているのが実際ですが（任命後AMはプロセス全体を通じて応募者のフォローアップを行います）、AMという役職をこなせる人材は一朝一夕に育つものではありませんから仕方ないのですが。彼らの負担を減らすには、現行の仕事の進め方をもっと調べる必要があると思っており、それには例えば、応募者の支援者サイドによる理解を深めて、応募者達には新規ソフトウェアのパッケージ管理に従事するよりも先に既存チームの支援に回ることを承知してもらわなければならないでしょう。
LC：先の公約では、アシスタントの増員にも触れておられました。それはどの分野についてのお話なのでしょうか？ その件に関して何らかの反発を招く危険性は想定しておられますか？ これは一般決議による裁可を必要とする役職なのでしょうか？
SH：この場合に主として想定しているのはコアチーム（FTPマスタ、Account Manager、System Administrator）に関するものですが、より一般的なメッセージとして私からお伝えしたいのは、Debianに貢献する意思はあるがそれだけの権限を与えられていないという方がおられたら、私どもに相談して頂くことで何か適切な貢献法を見つけられるかもしれないということです。
またこの構想に関しては、何らかの反発を招くだろう事は覚悟しています。むしろこうした“何らかの反発を招くだろう”という発言そのものが、また別の反発を招くこともあり得ます。既存のスタッフをすげ替える形で未経験の人材を充てるような事態を避けるには、人間関係に配慮した上でねばり強く意見交換を進める必要がありますが、そうした作業には必然的に時間がかかるものです。1つハッキリしているのは、私は何も小ぎれいなWebサイトの整備を呼びかけたおかげで選出されたのではなく、先に挙げた諸々の問題を解決するために選ばれたのであって、私自身としても現状を放置して悪化するに任せるつもりは無いということです。
LC：選挙時の公約では、テクニカルライタやアーティストなどメンテナ以外の人材をより多数Debianに参加させることも謳われておられました。この件に関しては、どのように進めていくおつもりでしょうか？
SH：そうした人々にはNew Maintainerのプロセスに進んでもらうつもりであり、その際にはTasks and Skillsのテストステップ（それ程時間のかかる課程ではありませんが）は免除させて、パッケージのアップロード（これは開発者の行う活動の中でも特に信頼を必要とするものです）にも従事させないということを構想していました。またこの件に関連して、当方のPGP Web of Trust（PGPの信頼性に関するWeb）をロールベースで運用するための新規ツールが開発中で、これが完成すれば、特定のロールが与えられた者についてはアップロードを禁止させるといった措置が比較的簡単に行えるようになるはずです。
LC：こうした構想の多くについては、多数のプロジェクトメンバによる協力態勢を整備する必要があるよう感じられます。そうした協力者としては、現状でどの程度の人員を募っておられるのでしょうか？ 人材を見つけるためには、どのような手法を採用しておられますか？
SH：そうしたサポート要員としては、非常に多数の人材が集まっています。選挙結果が公表されてから24時間もしないうちに、多数のプロジェクトメンバから協力の申し出を受けておりますが、その他にも、Web開発者、グラフィックデザイナ、Bugzillaのバグトラッキングシステムの関係者といった、プロジェクト外部の人々からも色々とアドバイスを頂いております。
私が思うに、必要な人材は既に手元に揃っているのであって、問題は彼らがフラストレーションを感じることなく作業できる環境を整備することであり、自分たちが行う仕事が無為に終わることなく実際に活用されると得心できるようにすることではないでしょうか。そうした環境を作り上げるには、単に作業に必要な人間を集めるだけではだめで、プロジェクト全体が過度に保守的な雰囲気に陥らないようにして、変化を受け入れる態勢を整える必要があるはずです。
LC：お話をお伺いしていると、特にUbuntuと比べた場合、Debianにはイメージ的な問題を抱えているよう感じられるのですがどうでしょう。そうした問題については、何か対処策を講じておられますか？
SH：Debianというオペレーティングシステムは、その安定性や技術的な完成度には定評がある一方で、非常に素っ気ない作りのインストーラしか装備されていない点などから、使い手を選ぶエリート主義に走っているというレッテルを以前から貼り付けられているようです。そうした悪評はSargeのリリース時点で陳腐化しつつあるもので、例えばEtchには機能と操作性に優れた実用的なグラフィカル系インストーラが装備されていることからも分かるように、常に改善は施されています。とは言うものの“ユーザフレンドリ性に欠けた無骨なディストリビューション”というイメージがいまだ払拭されていないのも確かな事実です。
これは私が過去に指摘しておいた主張ですが、こうしたイメージ問題を引き起こしている要因はDebianプロジェクトのWebサイトやバグトラッキングシステムといった部分にあるのであって、Ubuntuに転向した多数のエンドユーザにとっては訴えかける力が乏しかったのでしょう。実際、私どものWebサイトはダイナミック性に欠けており、様々なリンクは用意されているものの、それを積極的に利用してもらうためのサポートが不足しています。例えば、自分たちで作成したシステムのスクリーンショットでも配置しておけば、それだけでも印象はかなり違っていたはずです。こうしたWebサイトの再編を始めとした基本的なインフラストラクチャの整備は既に作業が進行し始めています。
またDebianに悪いイメージが付きまとっている原因としては、メーリングリストでの論争が炎上しやすいためだという指摘も出されています。私自身、それが真実であるのかを検証したことはないのですが。
LC：例のDunc-Tankという、Debianの主立った開発陣にフルタイムで作業を進めてもらうために資金を提供する構想が論争を巻き起こし、特に前DPLのAnthony Towns氏が関与していたことで大きな問題と化したことがありました。今後もDunc-Tank的な実験を踏襲する計画はありますか？
SH：その予定はありません。Debianの活動予算の使用法については既にいくつかのプランを提示していますが（新規ハードウェアの購入や、会議参加者への資金的サポートなど）、私自身がDunc-Tankについては明確に反対意見を表明していたこともあり、今後同様の計画を再開するつもりはありません。個人的な見解としては“Dunc-Tank的活動”と“何もしない”の中間地点に落としどころがあると考えてはいますが、DPLという立場にある人間がそれに関係するのは賢明な判断ではないと思っています。
LC：以前にDPLを務めていたMartin Michlmayr氏は、リリース管理の理論を構築しておられ、その中ではDebianもケーススタディの1つとして取り上げられています。そこで提案されている内容を何か採用される予定などはあるのでしょうか？
SH：現状でリリース管理のノウハウはそれなりの進歩を遂げており、Etchのリリースまでに要した期間は、Sargeのリリース当時と比べて1年間は短縮されています。Martin氏の理論の骨子は“リリースするのは準備が整ったら”という場当たり的な態勢からタイムベースのリリースプロセスに移行しろというもので、そうした意見には私も全面的に首肯するところです。もっとも残念なことに、リリースチームに作業形態をどうこうしろというのは、DPLの職分（および権限）を越えた話になるのですが。彼らが自主的にMartin氏の論文に目を通すことを期待するといったところですね。
将来的な展望
LC：DPLとしての成功を自分自身で判断するとしたら、何を基準にされますか？
SH：その点は何とも言えません。最大の理由は、実務上でどのような障害が待ちかまえているかをまだ確認していないからです。現状でどのような構想を抱いているにしろ、そのすべてが私の独創な訳はありませんからね。前任者達もいろいろな構想を持っていたはずですが、様々な障害に遭遇したために断念ないし妥協をしたという経緯があるはずです。
プロジェクトの技術的な構想に関してならば、その成否を測る指標を挙げることも可能であり、それ自体は別段難しい話ではありません。プロジェクトの社会的側面の方はそれ程単純な評価はできないでしょうが、アシスタントのコアチームへの配置が実現してその活動が順調に進むとすれば、私としては大いに満足できるところだと言えます。
LC：様々な構想を抱いておられるようですが、それらは1期間の任期中に達成できるものでしょうか？ 必要であれば再選に出馬するというお考えはどうでしょう？
SH：任期中にすべての構想が実現できる可能性は低いでしょうが、多くの活動はDPLの権限を必要としなかったり、最初に若干の準備さえ整えておけばいいという性質のものですから、任期終了後にその成果を見届けるということもできると思っています。
実際のところ、再選に打って出るという考えは持っていません。私個人のライフプランも構築する必要がありますし、人間集団に対する社会学的な探求やプロジェクト管理に興味がない訳ではありませんが、何よりもプログラマやハッカーとしての生き方を捨てたくはないですしね。仮に誰か他の人物が魅力溢れる選挙公約を提示してくれれば、私自身が喜んでその立候補者に投票することになるでしょう。
LC：自分に課せられた責任や、Debianプロジェクトに関して何か述べておきたいことは無いでしょうか？
SH：果たすべき仕事は大変だと感じていますが、決して不可能事だとは思っておりません。Debianプロジェクトについても、ここ数年でリリース管理のノウハウはかなり改善されたと見ています。これはつまり、コミュニティのメンバ達は単に改善の必要性を訴えているだけではなく、そのための具体的な作業に着手していることの証明です。いずれにせよ私1人では何1つ達成できるはずがありませんから、開発陣の手によってDebianをより素晴らしいものに育てるための環境を私の働きで整えることができれば、それは望外の喜びだと言ってもいいのではないでしょうか。そのための支援を頂けるのであれば、諸手を上げて歓迎させて頂きます。
Bruce Byfieldは、コンピュータジャーナリストとして活躍しており、NewsForge、Linux.com、IT Manager’s Journalに定期的に寄稿している。
