この記事はDrupal Advent Calendar 2023の22日目の記事です。

毎年記事のネタが思い浮かばず、他の方が書かれたエントリーを見てからネタを考えているのですが、今年はさくらインターネットの田中社長の記事にとても感銘を受けました。

なぜエンジニア組織をうまくマネジメントできないと悩む経営者が多いのか？

そこで、「Drupalなエンジニア組織をどのように作っていくか」という考察を書いてみようと思います。なお、以降は上記の記事に合わせた章立てとテイストでお送りします。

はじめに

私は、今までに「Drupalは自社で利用するOSSの選択肢のうちの１つだった」、「自社がDrupal案件のみでビジネスを行っていた」、「Drupal専業で開発している会社に技術顧問として参画する」など、いくつかの形でDrupalと関わってきました。

その中で共通の課題は、「どのようにDrupalのプロジェクトが回るようなエンジニア組織を作っていくのか」というテーマです。

Drupalは非常に強力なOSSであり、標準で多くの機能を備えていますが、顧客の要望を満たすためには機能をカスタムで開発しないといけない場面も多くあります。

しかし、国内だと組織・個人共にプレイヤーが少ないこともあり、外注しても思い通りの結果が出てこないケースがとても多い印象です。

また、フレームワークの特性としてエンドユーザーによる設定変更に寛容なため、開発時点から保守運用を見据えた設計をしておかないと、いわゆる「ブラックボックス」・「技術的負債」・「特級呪物」などになってしまいがちです。

そのため、自社内にDrupalをしっかりと理解したエンジニアを抱えておかないと、Drupalでビジネスをすることのリスクは非常に高くなります。

しかしながら、エンジニアが周りの人とうまくできないとか、言うことを聞いてくれないとか、なぜ他の人より高い給与を払わなければならないのかとか、さまざまな葛藤がある中で、結局エンジニア組織が崩壊したというような話も聞きます（もしくは見ます）。

(Drupal) エンジニアとそれ以外の人とは違う人種なのか

まずそのような話をされた時にする質問が、「社内のエンジニアをまるで外注先に依頼するかのように扱っていませんか？たとえば、顧客との打ち合わせにエンジニアも参加していますか？」というものです。

例として、顧客からあるコンポーネントに関するデザインと機能を変更したい、という打診があったとします。この時に、エンジニアチームがミーティングに参加しない状態で、顧客の要望がリーズナブルなQCD内で実現可能か判断がつけられるでしょうか。

Drupalは、「統一されたデータモデルを元に基本機能とUIを自動生成する」という思想を持ったフレームワークです。

そのため、顧客の要望は実は数クリックだけで実現できるかもしれません。逆に今のデータモデルと顧客の要件が衝突してしまい、見た目にはちょっとした変更でも想定外のコストがかかるケースもあります。

商売道具（Drupal）の特性を理解せずに顧客からの要望を気軽に受けてしまい、結果として後段の作業を行うエンジニアが苦労するようなことが常態化しているなら、信頼関係を築きようがありません。

このような判断ミスをしないためにも、ミーティングにはエンジニアに同席してもらうか、顧客対応や意思決定を行う人にはDrupalの道具としての特性・制約をしっかりと理解してもらうようにしましょう。

難しいことのように感じるかもしれませんが、非エンジニアでDrupalの特性や制約を理解している人もたくさんいます。

たとえば、私が技術顧問をしている会社のIさんは、本当にPHPコードが全く書けない非エンジニアですが、私の知る限りでは国内でもっとも優れたDrupalのアーキテクチャ設計ができる人物の一人です。

結局のところ、エンジニアも非エンジニアも、専門性が違うだけで、一緒の社内の仲間だし、別の人種ではないし、一緒に仕事すればいいのです。

せっかく、社内にエンジニアを抱えているのに、非エンジニアの人たちだけで決めて、依頼だけするとなると、エンジニア側は面白くないし、もし意見をしたならば「エンジニアは批判的だ」みたいな話にしかなりません。

間違っても、「エンジニアはマネージャーの言うことに絶対に従ってください。あなたたちにはその義務があります」みたいなことを言ってはいけません。そのような発言をしてしまうと、半年経たずにエンジニアがチームごと全員いなくなるかもしれません。

なぜ高い給与を払わなければならないのか

ここに関しては、あまり書くことはありません。

田中社長の記事にあるように、「誰にどのように給与を支払うかは経営者が決めればいい話だし、それに納得できない社員がいれば辞められてしまいますが、いずれにせよエンジニアが欲しければ給与を上げるしかないということを経営者側が納得するしかない」、というだけだと思います。

参考までに、Indeedが公開しているアメリカのDrupalエンジニアの給料は、この記事を書いている時点では年間$102,105になっていました。

https://www.indeed.com/career/drupal-developer/salaries

アメリカの給与水準と契約内容なので単純に日本の給与と比較はできませんが、少なくともアメリカではこれくらいの待遇でエンジニアを雇ってDrupalでビジネスが行われている、ということは頭の片隅に入れておくといいのかなと思います。

また、国内ではDrupalを使ってきちんとした開発ができるエンジニアの人口はかなり少ない、つまり希少性が高いという点も考慮しておきましょう。

ただ、気をつけないといけないのが、(Drupal)エンジニアのスキルを評価できないまま高い給与を払い、かつとんでもないシステムを作られることです。

特に、これから積極的にエンジニアを採用して組織を拡充しようとしていたり、大規模なプロジェクトを始めようと考えている局面において、採用に失敗するのは大きな痛手になります。

人材採用の観点は技術以外にもたくさんありますが、少なくとも技術的な判断ができるエンジニアにも採用プロセスに協力してもらいましょう。

間違っても、目利きができない人達だけで採用を決めて、「今日からこの人があなたたちエンジニアチームの上司（or 同僚)です、あとはよろしく」みたいなことをしてはいけません。繰り返しになりますが、半年経たずにエンジニアがチームごと全員いなくなるかもしれません。

システムをITリテラシーの低い人に合わせて選択しないように

ここも、田中社長の記事でおおむね書かれている通りなので、あまり書くことはありません。

「要は、ITリテラシーの低い人に合わせてソリューションの選択をするのではなくて、自社にマッチするソリューションに対してITリテラシーを上げていかないと、エンジニアは離れていくよ」の通りかなと思います。

個人的には、最近は業務用PCのスペックをそこまでケチる組織は昔と比べるとほとんど見かけません。

一方で、1人あたり月数千円程度のSaaSの利用コストをケチって節約して使いにくい自前管理のサービスを使ったり、機密性の高い情報を取り扱うのに組織ではなく個人に紐づいた無料アカウントでサービスを利用しているシーンなどはまだまだ見かけます。

組織のIT・開発リテラシーのベースラインは全体の生産性や安全性に直結します。無理のない範囲でベースラインを上げていくようにしましょう。

さいごに

いかがだったでしょうか。

元ネタの記事とテイストを合わせたので、無理やりな文章の組み立てで読みにくい部分も多々あったかと思いますが、今までの経験で私が感じたDrupalに関するエンジニア組織の課題を書いてみました。

Drupalに限らず、ソフトウェア開発はどんどん複雑化しています。

残念なことに、IT黎明期のまだシンプルだった時代（2000年代前半くらいまで？）の成功体験に引きずられ、「いや、私は開発のことをそれなりにわかってるから」という過信で意思決定を行った結果、優秀なエンジニアに愛想を尽かされてしまうようなケースは比較的よく見聞きします。

エンジニアだけを特別扱いする必要はありませんが、もし自身が開発のことがわからないのであれば、相手の知見に対して敬意を払ったコミュニケーションを取りましょう。もし、それができない・納得いかないという場合は、最終的には自身がエンジニアの実務をこなすしかありません。これは「エンジニア」という職種の部分を他の専門職に変えても成り立つ話ですね。

また、某省庁のWebサイトでDrupalが表面に現れたこともあり、一部では久しぶりにDrupalが話題になっています。

国内ではDrupalでビジネスを行っている組織・個人ともに少ないのですが、横のつながりは他のコミュニティと比べると少ないようです。みなさん仲良くやっていきましょう。