“秘伝のタレ駆動開発”をぶち壊せ！

カーゴカルトプログラミングという悪夢

 カーゴカルトプログラミングという言葉を聞いたことがあるでしょうか。  

言葉は知らずとも、その意味するところは、Twitterやその他メディアでもよく取り上げられ、話題になっているような内容で、実は馴染みのあるものなのです。  

カーゴカルトプログラミングとはなにか？ 

言葉の正確な意味や由来はWikipediaなどの辞書に譲るとして、カーゴカルトプログラミングの意味するところは、乱暴に「秘伝のタレによる駆動開発」と言っても良いかも知れません。すなわち、プログラミングにおける様々な手法を、手法自体も現状の問題も深く理解しないまま、適用してしまうことを指します。  

どうしてそんなことが起きるのか？ 

プログラミングには様々な「お作法」とも言うべき先人の知恵があります。 

• アルゴリズム 
• デザインパターン 
• 組織設計ノウハウ 

などなど… 

 これらの「お作法」を正しく使いこなすには、  

• 生み出された背景 
• その手法によって解決する課題の性質 
• 直面している課題の性質 

といったものを正しく理解する必要があります。 

しかし、それには多大な労力と時間や経験を要することが多く、つい短絡的に「コピー＆ペーストでいいや」と妥協したり、「○○さんが良いと言っていたから」と権威主義的になってしまったりして、盲目的に取り込んでしまいがちです。

 カーゴカルトの何が悪いのか？ 

盲目的な理由で取り込まれた手法は、悪夢です。

 特に、ある程度大きい規模、長い寿命を以て提供されるシステムの開発に携わる方々であれば嫌というほど体感してきていることでしょう。

• いつの間にか秘伝のタレが腐っていて、誰も直せない
• 誰も実態が分からず、必要か不要かも分からず、やめられない営み・ソースコードがある
• 「分からなくていい」といわれつづけてメンバーのモチベーションが下がる 

デメリットは上げたらキリがありません。  

まるで薬物依存のように、秘伝のタレは組織を、そしてシステムを蝕み続けるのです。

秘伝のタレを作らないために

「秘伝のタレ」を作り込んでしまわないためには、手法を正しく、深く理解し、自分たちの抱える問題を正しく、深く理解し続けることが重要になります。

その① プロフェッショナルとしての探究心を持つ 

自身が作っているもの、使っている道具について理解しないままでは、プロフェッショナルとしてのものづくりはできません。目の前に自分のよく知らない「ナニカ」が現れた時点で、「その手法がなぜ存在するのか」について少しでも知りたい、と理解への探究心を持てば、自然に一人ひとりが手法への理解を進め、秘伝のタレ化は起き得ません。 

その② エンジニアが組織を作る 

仕事や大きなプロジェクトを運営する上では、メンバーだけでなく意思決定者もカーゴカルトに陥らないことが重要です。 そのためには、意思決定の場面にエンジニアが主体性をもって参加することです。「誰かが決めてくれるのを待つ」といった受動的な態度ではなく、意思決定者に向けて翻訳して理解を求め、必要とあれば新たな手法を自ら提案する、といった能動的な態度が求められることでしょう。 

その③ 「上流工程」にNO 

往々にして開発の世界は「工程」という幻想に囚われがちです。 いわゆるウォーターフォールの世界では、工程の流れが不可逆です。また、工程の上流が上位の権限者に割り振られ、さも上流工程をこなす人間が偉いかのように振る舞う光景もよく見受けられます。 結果として「もう決まったことだから」「○○さんが言ってるから」という悪しき判断基準を生み、思考停止した現場は秘伝のタレを生み出し続けることにつながります。

「上流」もとい大枠で考えられた設計は、小さく分解した結果として疑われ、時として考え直しを迫られる、ということを常に受け入れ続けることが重要です。 

その④ お互いに助け合える仕組みを作る 

どんな人でも、理解できないことに直面することは充分に有り得ることです。 「分からない」ことは必ずしも悪ではありません。お互いに「分からないことを告げる」「分からない人を助けてあげる」という仕組みを作ることが大切です。 またそのためには、関係者が余裕をもって誰かを助けてあげられる状態を作らなくてはなりません。誰も彼もが締切に追われ、辛い状況のなかで「分からない」と声を上げることは難しく、またサポートしてあげる心の余裕も持てないでしょう。 

その⑤ トライできる環境を大切にする 

アレもダメ、コレもダメ、としてしまうと新しい手法を理解する機会が損なわれてしまいます。「失敗しても良い」という前提で、楽しく新しい手法にトライし、体感することが重要です。 「今までコレでうまく言ったから」と古臭くなった手法にしがみつくのではなく、失敗を恐れず新しい手法にどんどんトライし、美味しいところを選んで行くという前のめりの姿勢が求められます。 また、それを許容する周囲の環境を作ることが大切です。

WACULではどのように対処しているか

WACULではカーゴカルトに陥ること無く、開発に取り組める環境を整えています。

お互いに「助け合う」文化が根づいている 

今どきはスタンダードかもしれませんが、チーム内の成果物は常に「他の誰かの目を通す」ことが文化として根付いています。

 ソースコードであればGitHubのPull-Requestでレビューであったり、画面設計であればProttを通したコメントレビューであったり、成果物に対してお互いの知見を以て意見を出し、より完成度の高い成果物を作れるような環境です。 

また、メンバーが気軽に思ったことを呟くSlackチャンネルを用意して、何気なく思いついたことや、ちょっとした疑問を軽く発信するようにしています。これは、開発チームに閉じた話のみならず、ビジネスチームの意見を聞くことも容易にできる環境にあります。 この呟きによって、違った視点からの意見や回答を得たり、議論を呼んで新しい機能開発に結びついたりと、常に人と人との化学反応が起きやすい環境が実現できています。  

トライできる環境がある 

WACULでは強力なインフラエンジニアがメンバーとして活躍してくれています。 そのため、「誰でも気軽に自分のプロダクト環境を作ることができる」状況が実現できています。

何か新しいものをプロダクトに取り込んでみたい、と思いついた時、咄嗟に試してみる環境は、開発の足を軽くして、新しいものへの挑戦を促進できます。  

スクラム開発への取り組みをすすめている 

WACULではスクラム開発への取り組みを推進しています。

理由としては、仕様が固まるのを待ってから物を作るよりも、実際に作ってみてフィードバックをもらったほうが良いものが作れるからです。エンジニアとしてもみんなから使われる、より良いプロダクトを作りたいという希望にマッチした環境になると考えています。  

一人ひとりが何かしら「得意なもの」を持っている 

WACULの開発部メンバーは、一人ひとりがそれぞれの「得意分野」を持っています。

 世の中の情報をキャッチアップするだけでなく、自分なりに噛み砕いて解釈し、きちんと理解していつでも自分の道具として使いこなすだけの基盤を築く、ということが日常に染み付いているメンバーばかりです。 チームとして新しい課題に直面したときも、その課題に何かしら知見のあるメンバーが、解決策を呈示し、それが適切なものか評価できるだけの材料を提供できています。

WACULは、“テクノロジーでビジネスの相棒をひとりひとりに”というビジョン達成のために、共に挑戦するメンバーを募集しています。

◆こんな方に仲間になってほしい  

・仕事に真摯に向き合える方 

・サービスのあり方に想いを持って、設計に参加できる方 

・プログラミング能力に秀でている方 

・プログラミングに情熱がある方 

・プロダクト全体の構成を理解して、プログラミングができる方 

・新しいことに前向きに向き合える方 

・作ったものに愛着を持てる方

 ・チームの中だけでなく、会社全体プロダクト全体に思いを持って開発に向き合える方

弊社は風通しもよく、エンジニアが働くにはいい環境（音楽を聞いての業務OK/ 服装自由等）だと自負しています。また、新しい技術への取り組みも盛んです。