Red Hatの佐藤匡剛です。昨日、Red Hat Forum / Tech Nightにお越しいただいた方、ありがとうございました。
昨日のRed Hat Tech Night冒頭のトークセッションで、id:nekopこと木村さんから面白い発言があり、Twitterでも話題になっていたようなので、ちょっとフォローアップの記事を書きたいと思います。
「これは仕様ですか？」 と聞かれても、たまたま開発者がそうしただけというケースもあり、答えにくいことが多々ある #rhtn2018
— 転職しても肉の妖精だった件 (@nanodayo) November 8, 2018
仕様が先かコード書いた人の気持ちが先か #rhtn2018
— えいご (@enagok) November 8, 2018
実装がたまたまそうなっているw
— 水無月 忠司 (@longyoru) November 8, 2018
とても分かる。#rhtn2018
たまたま実装がそうなった、っていうのはとても良くある、わかる（笑） #rhtn2018
— まさみさんは語りたい (@mhiramat) November 8, 2018
これは本当にその通りで、サポートケースなどで顧客から実際に「仕様」について聞かれることが多いのですが、エンジニアの側からすると毎回回答に困っています。このギャップがなぜ発生するのか考えてみます。
オープンソースに「仕様書」はない
そもそもこういう質問が来るのは、顧客側に「ソフトウェア製品には必ず詳細な仕様（書）があり、細かなパラメータの挙動まで含めて予め明文化された上で作られている」という思いがあるからだと思います。これもおかしな想定とは思いません。私自身SIer出身ですが、いわゆるエンタープライズのシステム開発の現場では、まず上流工程として要件定義から詳細な仕様書を作成し、その上でようやくシステムの実装に入る、というプロセスが長年行われてきました。最近でこそWebサービス会社の隆盛やアジャイル開発への注目によって少しずつ変わって来ているとは思いますが、まだまだ開発の現場では主流の考え方でしょう。
しかしご存知の通り、OSSのプロジェクトは全くそういうプロセスでは動いていません。基本的に、一部の優秀なエンジニアが頭の中にあったアイディアをコードに吐き出すところから始まり、それを別のエンジニアが興味を持って少しずつ改良をコントリビュートしていく中でコードを中心としてコミュニティが形成され、エンタープライズでも使えるソフトウェアに成長していきます。しっかりしたOSSの中には内部の大まかな構造を説明したアーキテクチャドキュメントが用意されているものもありますが、詳細な仕様書のようなものが残っているプロジェクトは存在しないはずです。
オープンソースはコミュニケーションを重視する
OSSは、その代わりにコミュニケーションとイシュー管理を重視します。メーリングリストのないプロジェクトはありませんし、GitHub IssuesやJIRA、Bugzillaといった専用のITSを使っていないプロジェクトもありません。
ソフトウェアの動作が分からなかったらメーリングリストに質問します（最近ではStackOverflowを使うのがもっとクールだったりもします :-) ）。するとコア開発者が挙動について答えてくれるので、それが「仕様」として残ります。またソフトウェアの動作が気に入らなかったらDevメーリングリストに議論を吹っかけます。理路整然とした良い改善案で、かつ開発者がオープンな心を持っていれば（笑）、その案は「仕様」として取り入れられますし、そうでなければ開発者に欠点を指摘されて却下されます。
同じように、バグや機能リクエスト（RFE）はITSにチケットを上げます。そうすると、そこでの報告やその後の議論はすべてそこに記録されて、誰もが参照できる「仕様」になります。まともなプロジェクトでは、ソースのコミットコメントに必ずチケット番号を紐付けます。そうすることで、コード上から、なぜこういう変更がされたのかを後から完全にトラッキングできます。
仕様書のあるエンタープライズな開発とOSSの何が一番違うのかというと、「仕様書」が所与のものではないという認識があるかどうかです。OSSでは、「仕様」は自ら参加して、コミュニケーションの中で創り上げるものです。OSSは誰もが改変可能なソフトウェアなので、所与の「仕様」に縛られる必要はないのです。必要なのはコミュニケーションであって、既存の「仕様」よりもっと良いアイディアがあればそちらこそが本来の「あるべき」動作であり、既存のイマイチな「仕様」通りの動作ではないのです。この認識こそが、オープンソースのイノベーションの源泉だと思います。
Red Hatのオープンソース製品
とはいえOSSも製品として提供してビジネスをする以上、製品としての「仕様」はあります。それは公式サイトに上がっている、サポートされる環境（OS、JVM、ブラウザ、etc.）や標準（RFC、JSR、WS-*、etc.）であったり、提供される製品／コンポーネント同士の組み合わせであったり、また公式ドキュメントであったりです。こうした「仕様」は、製品毎にプロダクトマネージャ（PM）という人が1人いて、その人が大口顧客などと話をしつつ、次期製品に顧客への約束として策定しています。（ちなみに、こうした製品仕様も、Red HatではJIRAやBugzillaなどで管理しています。）
したがって、このレベルの大まかな「仕様」であれば間違いなくありますし、問い合わせがあればPMに聞いて明確な回答をもらえます。しかし、それより細かなレベルの、例えば1コンポーネントのパラメータを変更したときの細かな挙動であるとか、そういった部分には上述の通り「仕様書」はありません。そういう問い合わせがあると、最終的にそのコンポーネントを作った／メンテしている開発者のところまで落ちてきて、その開発者が自分の頭の中から回答をします。場合によってはメンテ担当者がその改変を加えた当事者でないこともあるので、その場合はその開発者がコードとにらめっこをしながらエンジニアリング能力を最大限に発揮して、あるべき回答を導き出します。
エンジニアが日々どうやって「仕様」を生み出しているか
少し見方を変えて、エンジニアが日々どうやって「仕様」を生み出しているかを見ていきます。
Red Hatのエンジニアリング部門は基本的にチケット駆動で仕事をしています。上記のようにPMが決めた「仕様」がJIRAのチケットとして降ってきたり、また顧客から報告されたバグがサポートエンジニアを通してバグチケットとして起票されたりして、チケットがたくさん溜まっています。そのチケットを自分でアサインするところから仕事が始まります。アサインされたチケットには、当然ながら最低限のことしか書かれていません。詳細設計書のように、こういうステップでこれを実行して、機能を実現する／バグをFixする、なんてことは当然書かれていない訳です。どういうアプローチでこの問題に取り組むか、そもそも取り組むべきなのか（リジェクトすべきか）といったところから自分で考える必要があります。
ここで上意下達のマインドセットに慣れていると、自分より上の権威（上司）に判断を仰ぎたくなりますが、実際にそんなことをする人は誰もいません。誰かが仕様を落としてくれないかと指をくわえて待っていても、いつまで経っても自分の仕事は進まないからです。
Red Hatのマネジメントはボトムアップ型です。自分は行ったことはありませんが、Red Hatでマネージャになると最初にブートキャンプに送り込まれて、このボトムアップ型のマネジメントを叩きこまれ（ているはず）です。マネージャはあくまでファシリテータに徹して、円滑なチーム間のコミュニケーション等に腐心してくれますが、各自のエンジニアリングタスクに介入することはありません。基本的にエンジニアは放牧されていて、困った時だけマネージャにアドバイスを聞くと他の手助けできるエンジニアにディスパッチしてくれる、といったイメージです。
したがって、マネージャに技術的な詳細の相談をしても、その分野に詳しいエンジニアを紹介してくれるだけです。技術的に困難な課題は、エンジニア同士でプロアクティブに相談して解決していきます。
エンジニアに最大限エンパワーメント（権限委譲）する
これは誰かに言われた訳ではなく私自身の感想ですが、Red Hatは各人に最大限のエンパワーメント（権限委譲）をしてくれる組織です。そのチケットを任せた以上、お前がその分野の第一人者でチーム内で一番調べて詳しいエンジニアなのだから、お前がソフトウェアのあるべき動作についてベストな決定を下せるはずだ、というメッセージを日々感じます。もちろん大枠の製品仕様はPMから降ってくる訳ですが、その枠組みを尊重しつつ、かつ他のエンジニアが決めたミクロな決定と整合性を取りながら、ソフトウェアのそのミクロな分野において最良の「仕様」を決める権限はエンジニア各人に任される訳です。
ここで自分が昔にやった仕事を例にすると、Red Hat Fuse（旧JBoss Fuse）のWebコンソールにパフォーマンスの問題がありました。
調べていくと、コンソールからサーバへのリクエストが頻繁に行われ、それがキャッシングされていないことが原因と判明したので、私自身の判断でGoogle Guavaを使ってキャッシングを実装することにしました。
その際、キャッシュの有効期限がどのくらいが最適かを決める必要がありました。私は、キャッシュされるデータが変更される頻度と、キャッシングによるパフォーマンス向上との兼ね合いを検討した上で、有効期限を10分間と決めました。また、その値はソースにハードコーディングしました。設定値をパラメータ化して、外から変更できるようにすることもできましたが、そういったニーズがあるかも分からない段階ではオーバーエンジニアリングであろうと判断したためです。
こうした一連の判断は、自分の上司や上のエンジニアにしつこく聞いて判断を仰いだところで、期待する答えはもらえないでしょう。仕事を進めるには、こうしたミクロな仕様決定を各自が日々行っていく必要がある訳です。
エンジニアにどう聞けばいいか
最後に元の話題に戻って、ではエンジニアに「仕様」ではなく何を／どう聞けばいいのでしょうか。
そういうときは「仕様ですか？」じゃなくて「意図的ですか？」って質問するのが良い。 #rhtn2018
— みょうが (@mrkn) November 8, 2018
バグかどうかを聞くときはこの質問はいいと思います。ただし、端的に「仕様か」あるいは「意図的か」と聞かれても、意図的とも意図的でないとも判断がつかないグレーゾーンもありますので、回答に迷うことがあります。
個人的には、自分がどういったシナリオ、ユースケースを実現したいのかを一緒に添えてその質問をするのがいいと思います。上記の通り、明確な「仕様」というものは存在しないので、多くの場合ミクロなケースではどういった挙動をするのが本来正しいのかをエンジニアが考えることになります。その際に、具体的なユースケースが添えられていると、そのユースケースが本来妥当なのか、妥当な場合はソフトウェアが本来どう動くべきかを検討しやすいためです。そのユースケースが非常に真っ当で素晴らしいものであれば、たとえ現状が仕様っぽい動作だったとしてもそれを捨ててでもそのユースケースをサポートするべき、と判断する可能性さえあります。
余談ですが、個人的な体感として、海外の顧客が「仕様かどうか」だけを聞いてくることはほとんどありません。彼らからは「自分の仕事を早く終わらせたい！」という意志をひしひしと感じます。なので、「自分のユースケースだとここが動かないから、こういう風に直せ！」という要求を貰うことが多く、それが通って問題が解決すれば後の細かい部分はあまり気にしない（それが自分たちに関係なければ）という印象があります。
Red Hatはエンジニアを募集しています！
最後になりますが、Red Hatは常に優れたエンジニアを募集しています。Red Hatで働いてみたいなと思った方は、ぜひこちらから興味のあるポジションを見つけて応募してみてください！
Red Hat Jobs - Explore Open Source Career Opportunities & Apply Online
（リンクは勤務地：東京に絞ってますが、英語に自信のある方はぜひ直接USやRemoteのポジションも探してみてください :-) ）
