「良い設計」は分からない。では、どうする？
NoSchoolは2018年設立の新しい会社だが、設立当初からマナリンクに取り組んでいたわけではない。別の事業を進めていたが2020年に行き詰まり、方針を転換してマナリンクの事業を始めた。meijin氏は当時を振り返り「元々の事業の後始末をしながらマナリンクを立ち上げなければならなかったが、エンジニアは3～4人しかいなかった。割り切りが必要だと判断した」と語る。
競合の参入や、そもそもの事業計画が良くなかったなど、失敗の原因は色々考えられるものの、当初は「コードの品質が悪かったためにバグが入ってしまったのか」とか「DDDに基づく実装を突き詰め過ぎたのか」と失敗の原因をいろいろ考えてしまったという。
meijin氏は、こういうときエンジニアが考えることは3つに分かれると言う。1つ目は、事業失敗の経験から「立ち上げ期の設計で頑張るのはもう止めよう」という考え。2つ目は「どんなに事業が良くないものでも、設計だけは頑張ろう」という考え。3つ目は「どの設計が良いのかは、そんなに簡単には分からないのだから、その時々で最善と思う判断をしていこう」という考えだ。当時のmeijin氏の頭の中には、3つ目の考えがあった。
またmeijin氏は、DDDについてさまざまな論争が巻き起こっていることに気付いたという。例えば「DDDはこうあるべきだ」という意見と、「そんなことにこだわる暇があるなら機能を作れ」という意見がぶつかり合っていたと振り返る。また、「DDDに従わないとまともなプロダクトは作れない」という意見もあったと紹介しながら、「設計を学び始めた人が陥りがちな落とし穴。良いものを作るなら、これに従わなくてはならないと考えてしまいがち」と指摘する。
このような論争を眺めたmeijin氏はあることに気付く。「こういう組織、こういう事業でやったら上手くいった」という前提がないまま議論が進んでしまっていることと、前提が無いまま議論をしてしまうと論争になりやすい。良いものを作るためにDDDを活用することは良いことだが、がんじがらめに縛られてしまうと何もできなくなる。そしてDDDを使うにしても事業の内容や組織に合わせて、使い方を考える必要がある。
また、この時期から「削除しやすい設計」を意識するようになった。どんどん機能を作って、試してみて、不要なものはどんどん捨てていくという、スタートアップ企業によく見られる仕事の進め方を意識してのことだ。つまり、自然と機能を削除しやすい疎結合な設計を意識していたのだ。
