Hi there 👋

この記事は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でビジネスを行っている組織・個人ともに少ないのですが、横のつながりは他のコミュニティと比べると少ないようです。みなさん仲良くやっていきましょう。

この記事はDrupal Advent Calendar 2022の14日目です。 DrupalCon Portland 2022 Driesnote に登場した Ambitious Site Builders という言葉が一部で注目されています。 Drupal Advent Calendar 2022 でも、すでに複数の方がこのテーマで記事を書かれていますね。 @gongo_k さん: Drupal の ambitious site builders とは何か @hagi60 さん: Ambitious site builders 両記事とも、とてもよい考察が書かれているのでぜひ読みましょう。 お二人の属性は、記事の内容や bio からどちらかというとプロジェクトマネージャー・ディレクター寄りのように読み取れます。 ということで、この記事では開発者の目線から次のことを考えてみようと思います。 Ambitious Site Builder とは こんなサイトビルダーと一緒だといい仕事できるよね 決して記事のネタが思いつかなかったから真似しているわけではありません。😇 Ambitious Site Builder とは これを考えるには、まず（普通の、もしくは以前の）「サイトビルダーの役割・スキルセットとは」の整理からですね。 この点については、先に紹介した @gongo_k さんの記事中の 旧来のサイトビルダー のセクションにまとまっています。ありがとうございます（他力本願）。 一言でまとめてしまうと、「Drupal のコアとモジュールを使い、管理画面の機能でサイトを構築する人」でしょうか。 一方で、 @hagi60 さんの記事でも言及があるように (他力本願その2)、 Drupal 8での大きなアーキテクチャ変更により、 Drupal 7 では存在したモジュールが使えなくなったり、開発が滞るようになった モジュールを導入する際に composer, config management などの知識が必要になった という歴史的な背景もあり、「サイトビルダーだけで完結できること」が少なくなってきているのが現在の状況です。 ざっくりの方向性としては、（もちろん Drupal 自体がより使いやすくなる前提で）この状況を変えていける人材が Ambitious Site Builder なのかなと思います。...

この記事はDrupal Advent Calendar 2020の21日目です。 DockerやLXDなど、アプリケーションの実行環境を抽象化する技術の普及により、ローカルマシン上に簡単に使い捨ての環境が構築できるようになりました。 しかし、ちょっとしたモジュールの動作確認のためにいちいちローカルマシン上でコンテナを起動したり、ネットワーク帯域を消費してcomposer installしたり、使い終わったらクリーンアップするのは面倒ですよね。ちなみに私はとても面倒です。 あまりに面倒なので Gitpod でDrupalを立ち上げるようにしました。 コードはgithubで公開しています。 https://github.com/blauerberg/gitpod-drupal GithubとGitpodのアカウントがあれば、「Open in Gitpod」ボタンを押すだけでGitpod上でDrupalが起動します。 これで、 Eclipse Theia上でコードを読んだり書いたり Xdebugでデバッグしたり シェルを開いてモジュールを追加したり PRのレビューをしたり 環境一式を他の人と共有したり カフェでiPadを開いてドヤ顔してプログラミングするふりをしたり などなどを、全てブラウザ上だけで楽しむことができます。 しばらく利用していない環境は自動的にGarbage Collection が働き削除されるので、メンテナンスも不要です。いやー、いい時代になりましたね。 何ができるかの詳細はREADMEやGitpodのドキュメントを参照してください。