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