Dyno

Drupal 開発会社を選ぶときにチェックすべきポイントまとめ

今回はウェブ制作の「発注者」側の方が Drupal の開発会社を選ぶときに「見るべきポイント」をまとめました。 Drupal を使ったサイト制作・ウェブアプリケーション開発をこれからどこかに依頼しようとされている方はぜひ参考にしてみてください。

「開発会社選び」というのはウェブ制作のプロジェクトにおいて最も重要な意思決定ポイントのひとつです。 開発会社選びに失敗すると、酷い場合は「他の会社に変えてゼロからやり直す」必要があることもあります。 そのときに生じるお金と時間のロス、スタッフへの負担、機会損失の額は最初から適切な会社を選べていた場合とは比べ物になりません。 大きな損失が発生してから「もっと真剣に選べばよかった」と思っても後の祭りなので、開発会社選びはぜひ慎重に行うようにしてください。

ということで、 Drupal 会社を選ぶときにチェックすべきポイントをまとめました。

尚、この記事の考え方はあくまでも筆者のものです。 そのまま鵜呑みにはしないようにしてください。 ぜひ批判的にお読みいただき、他の意見も聞くようにしてください。

筆者のプロフィール

背景として筆者のプロフィールをかんたんに説明しておきます。

筆者は Drupal 経験のあるウェブエンジニアです。 導入経験のあるコミュニティモジュールは 100 〜 200 の間くらいで、カスタムモジュールの開発で書いたコード行数は数万行ぐらいです。 わずかながら Drupal 本体にもコードで貢献したことがあります。 貢献といってもごくわずかなのですが、 90% 以上の Drupal 技術者はその貢献ができるレベルにはないので、 Drupal 経験者が 10 人いたら 1 〜 2 番目に詳しいくらいには詳しいはずです。 ちなみに、 Drupal をやっていた頃に英語の Drupal 書籍を 5 冊ほど読みました。

また、重要なこととして、 Drupal 以外の CMS とウェブアプリケーションフレームワークを実プロジェクトで使った経験があります。 Drupal プロジェクトの状況をある程度知りながら、なおかつ一歩引いた視点から相対的に開発会社の評価をできる立場にいると思います。

前提

お話の前提として、今回は開発の規模が 100 〜 2,000 万円ぐらいの Drupal プロジェクトを想定しています。

「 Drupal を使おう」となるケースの多くは「他の CMS ではコストがかかるか実現が難しい」という理由で Drupal を選んでいるかと思います。 サイトのタイプとしては SNS / CGM サイトや多言語サイトが多いでしょうか。

そのようなプロジェクトは一般的な情報発信のためのコーポレートサイトの構築プロジェクトに比べると要件や仕様が複雑で予算も多めです。 しかし、一部の人だけが理解できる難解なビジネスロジックがあるというほどではなく、「(ウェブ制作 + システム開発) ÷ 2 」といった性格のものが多いかと思います。

そのタイプのプロジェクトを成功させるために必要なことは、「ウェブ制作」的な作業と「システム開発」的な 作業のどちらもうまくやることです。 そこでは Drupal に関する知識やスキルも役立ちますが、それは全体から見ればごく一部に過ぎません。

その実態に反して、 Drupal 開発会社を探す発注者は「 Drupal に長けている」というポイントを重視しすぎており、その他の面の評価がおろそかになりがちです。 それが会社選定に失敗し、引いてはトラブルに繋がる大きな原因です。

Drupal 開発会社を選ぶときにチェックすべきポイント

  1. 総合的な開発力
  2. プロジェクトマネジメント力
  3. ビジネスリテラシー
  4. 英語力
  5. Drupal 技術力
  6. 価値観・文化
  7. 社員定着度
  8. 価格

1. 総合的な開発力

第一に見るべきポイントは「総合的な開発力」です。

ポイントとしてたとえば「要件が正しく抽出できる」「要件に合った正しい技術選定ができる」「品質を保てる仕組みを持っている」「 UI / UX も考慮できる」「汎用的な問題解決力を持っている」「システムのメンテナビリティを保てる」等があります。

重要なのは、ここには「 Drupal 特化のスキル」は含まれないということです。 「総合的な開発力」という大きな領域と比べると、「 Drupal 特化のスキル」の重要度は 10 分の 1 もありません。

もちろん、開発会社が Drupal の知識・経験を保有しているのに越したことはありませんが、プロジェクトを成功に導くのは Drupal の知識ではありません。 ウェブプロジェクトを真の意味で成功させる知恵に「幹」と「枝葉」があるとすれば、 Drupal の知識は「枝葉」です。 おそらくこれは上位 20% ぐらいのレベルの技術者であれば皆同意するところだと思います。

1 〜 2 ヶ月ぐらいの超短期プロジェクトであれば、スタートダッシュの速さに関わるという意味で「事前に持っている Drupal の知識」がものを言いますが、それを越える期間のプロジェクトになれば Drupal の知識はプロジェクト期間中に習得するのでも十分に間に合うと筆者は思います。

2. プロジェクトマネジメント力

ふたつめに見るべきは「プロジェクトマネジメント力」です。

プロジェクトマネジメントの重要性は知っている方には改めて説明するまでもないでしょう。 ICT のプロジェクトをいくつか経験したことのある経験者であれば誰しもが、プロジェクトを成功させるにはプロジェクトマネジメントのスキルも必要になることを知っているはずです。 マネジメント機能は発注者側だけでなく、開発会社側でも持っている必要があります。

3. ビジネスリテラシー

3 つめは「ビジネスリテラシー」です。

ここで言うビジネスリテラシーには、「開発プロジェクトの背景にある、クライアントの環境や課題意識が正しく理解できること」「クライアントにとって重要な TCO 1 の視点を持てること」「個人の趣味や好みではなく、チャンスやリスクの視点から技術選定ができること」といったスキルが含まれます。

もし発注者または間に入ってくれる代理店の方がビジネスの側面をカバーし、ビジネスと技術の橋渡しも十分にできるというのであれば、このあたりは開発会社に期待しなくても大丈夫です。 しかし、もしそのあたりが不十分あるいは不安に感じるのであれば、開発会社に「どのぐらいのビジネスリテラシーがあるか」というポイントも必ず見ておくべきです。

特に Drupal は過去 10 年にわたり年々シェアが下がってきている CMS であることもポイントです。 2020 年の Drupal のシェアは 5 年前の半分です。 シェアが下がっている CMS が必ずしも悪いわけではありませんが、そんな CMS を採用することには相応のリスクとデメリットが伴います。 そして、そのリスクとデメリットや発注者側でも負う必要があります。

その事実を無視あるいは軽視する会社はまず論外ですし、リスクやデメリットを上回るだけの大きなメリットがあることをきちんと説明できない会社に顧客のビジネスを中長期的に支援できるだけのビジネスリテラシーがあるかは疑問です。

4. 英語力

4 つめは「英語力」です。

英語力といっても、ネイティブ並みにペラペラしゃべれる必要はありません。高校卒業レベルの読み書きがスムーズにできて英語の技術書が読めれば十分です。

なぜ英語力が重要かというと、 Drupal ぐらいの普及度の技術の場合、日本語で得られる情報は非常にかぎられてくるからです。 この普及度の技術において、学習や問題解決に利用する情報源のほとんどは英語です。 Drupal に関する情報の量を英語圏と日本語圏で比べると少なくとも 30 〜 50 倍以上の差があります。

ということは、一定レベル以上の Drupal 開発をしている会社のスタッフであれば日常的に英語に触れるはずです。 そして、毎日英語に触れていれば読み書きスキルはおのずと伸びていくはずです。 もしその英語のスキルが低ければ、大したことをやっていないか、英語を毎日やっても伸びないくらいのレベルかのどちらかです。

英語力があるからといって必ずしもよい開発会社であるとはかぎりませんが、英語力がなければ Drupal 開発において一定レベルの生産性を出すことは不可能です。 その意味で英語力は Drupal 開発会社と Drupal 技術者の力を測れるよいバロメータになります。

ただし、「英語どのくらいできますか?」と直接聞いても、見栄を張る技術者もいるので、単純に質問するだけではいけません。 実際の能力を見極めましょう。

5. Drupal 技術力

5 つめは「 Drupal 技術力」です。

当然のことながら、 Drupal を使ったプロジェクトでは Drupal の知識と経験が役に立ちます。 ただし、実は Drupal の技術は適切な学習とトレーニングを行えば短期的に習得可能なので、「プロジェクト開始前に持っている Drupal 技術力の高さ」はさほど重要ではありません。 「総合的な開発力」や「プロジェクトマネジメント力」を一朝一夕に身につけることはまず不可能ですが、 Drupal の技術力であれば 2 〜 3 ヶ月ほどで並の Drupal 技術者レベルに追いつくことが可能です。 もし他の CMS やフレームワークを使ったシステム開発の経験があり英語の技術書をスムーズに読める人なら習得はもっと早いでしょう。

少なくとも、 Drupal を使った開発をきちんと行えるレベルに達するために必要なインプットの量は、年単位での学習が必要な高校・大学学部レベルの数学や、情報系の学部で学ぶ体系的なコンピュータサイエンスの知識には遠く及びません。 これは「 Drupal はかんたんだ」と言っているのではなく、あくまでも相対的な評価として言っています。

そのため、「 Drupal 技術に長けています」という肩書きは「数ヶ月の勉強で取れる資格」と同程度のものです。 その認識に立つと、開発会社を選ぶときに「 Drupal ができる」というポイントを重視し過ぎることのリスクがよくおわかりいただけるものと思います。

ただし、 Drupal に関して十分な知識を持たない方が Drupal 開発会社の技術力を見極めるのは極めて困難で、実質不可能です。 たとえば、開発会社のサイトには「 Drupal に貢献しています」「認定を受けました」といったアピールが書かれていることがありますが、それらを見て「へぇ、技術力が高い会社なんだ」と単純に思ってしまう方は注意してください。 重要なのは「真に技術力があるかどうか」ですが、それはサイトに載っているアピールをちらっと見る程度ではわかりません。

6. 価値観・文化

6 つめは「価値観・文化」です。

ここで、価値観・文化とは、物事の基本的な考え方や判断基準、コミュニケーション習慣のことを指します。 ウェブ制作業界は歴史が浅く社歴の浅い会社が多いこともあり、歴史の長い他の業界に比べると倫理観や価値観、思考のフレームワークが十分に成熟していません。

中には、会社組織としての基礎がボロボロの会社や嘘をつく会社もありますし、「ウェブ制作」や「システム開発」の世界は売り手と買い手の間の情報格差が大きい(=情報の非対称性が高い)取引でもあるので、顧客や従業員との関係が長続きせず「焼き畑農業」的に次々と新しい顧客と労働者を食い物にしていく会社も珍しくありません。

開発会社との間で中長期的な信頼関係を築きたいとお考えの場合は特に、その会社の「ハード」的な能力だけではなく、「ソフト」的な価値観や文化の面もチェックしておくべきです。 結局ウェブ制作やシステム開発というのは人と人とのコミュニケーションなので、どれだけ腕のよい会社でも根本的な価値観が合わない会社とは組むべきではありません。

7. 社員定着度

7 つめは「社員定着度」です。

ご存知の方はよくご存知のとおり、ウェブ業界は人材の流動性が高い業界で、社員の定着度が低い会社がたくさんあります。 規模の小さな会社なら 3 年経てばメンバーの大半が入れ替わっていることも珍しくありません。 ただでさえ流動性の高い業界で、特に人の出入りが激しい会社には注意が必要です。

社員定着度の低い開発会社だと「プロジェクトを発注したときのメンバーが途中でいなくなる」「初期開発のメンバーがすぐに抜けて知識継承が途絶える」といったことがよく発生します。 サイトに載っている制作事例がよいと思って発注したら、担当スタッフはほとんど辞めていなくなっていたなんてこともあります。

社員の定着度が低いとノウハウの蓄積もうまく進みません。 たとえば「 Drupal を 10 年やっています」という会社のスタッフの大半が在籍 5 年以内だった場合、その会社には 10 年相当のノウハウの蓄積はまずありません。

さらに、社員の定着度はその会社の労働環境やマネジメントレベルを如実に反映します。 社員が定着しないということはその会社のマネジメントのレベルが低いと見てまず間違いありません。 組織のマネジメントがろくにできていない会社がプロジェクトマネジメントだけうまくできるなんてことがあるでしょうか。

ちなみに、このポイントを直接確認するのは難しいですが、サイトのスタッフ紹介ページやリクルート情報からある程度は推測が可能です。 徹底的にチェックするなら Wayback Machine 等のアーカイブサイトで過去のサイトでスタッフ一覧を見るという手もあります。

8. 価格

8 つめは「価格」です。

いくら能力の高い開発会社があったとしても価格が高すぎればその会社に発注することは当然できません。 身の丈に合わない会社に発注して自社の経営が傾いては元も子もないので、予算の範囲内で依頼できる開発会社だけを候補にすべきです。

価格に関する注意点として、発注者の多くは「価格が高い会社はそれだけ腕がよいのだろう」とつい考えますが、必ずしもそうではありません。 開発会社が提供する「価値」と「価格」との間にはある程度の相関がありますが、それは統計的にだけ言えることです。 個別の会社に対しては「価格が高い=腕がよい」とはかぎりません。 そこを逆手にとって、実力に見合わない価格で受注して焼き畑農業的に営業しているところもあります。

おわりに

ということで、「 Drupal 開発会社を選ぶときにチェックすべきポイント」をご紹介しました。

最後にポイントをまとめます。

  1. 総合的な開発力
  2. プロジェクトマネジメント力
  3. ビジネスリテラシー
  4. 英語力
  5. Drupal 技術力
  6. 価値観・文化
  7. 社員定着度
  8. 価格

必ずしもこのすべてのポイントをチェックする必要はないですが、 1 〜 2 つのポイントだけを見て判断するのは避けてください。 各ポイントの調査にも当然コストはかかるので、どこまでチェックするかはかけうるコストとのバランスを見て決めるとよいと思います。

ウェブプロジェクト全体をサッカーにたとえるなら、「 Drupal 技術力」というのは「シュート力」のようなものと言えます。 それも重要な要素のひとつではありますが、それだけで勝敗(成否)が決まるわけではありません。 重要な要素は他にもたくさんあります。

ウェブ制作のプロジェクトにはさまざまな落とし穴があり、発注前には思いもよらなかったところでつまづきます。 「自分は大丈夫だろう」「この会社なら大丈夫だろう」「何年もやってるならこのぐらいはやってくれるだろう」という楽観が失敗のもとです。

プロジェクトを成功させたいと本気で考えるのであれば、くれぐれも「 Drupal ができそう」とか「事例がよさそう」といったふんわりしたピンポイントの評価軸で開発会社を選ばず、多角的・総合的な視点で見るようにしてください。


  1. Total Cost of Ownership 。初期の開発だけではなくサイトのライフスパン全体に及ぶ、すべてひっくるめたコストのこと。