11月, 2020 | SBWorks社員ブログ!

こんにちは。SBWorksでディレクターとして働いているWと申します。前職も含めると、かれこれ10年近くWEB業界でディレクターというお仕事をやらせてもらっていますので、これまでの経験にもとづき、

WEB業界のディレクターの仕事内容
ディレクターに必要なスキル

についてお話しさせていただければと思います。

WEB業界のディレクターの仕事内容は？

身も蓋もない話ですが、正直に言ってしまうと、ひとくちにディレクターと言っても、その仕事内容は働く会社やアサインされるプロジェクトによって異なり、明確に「これだ」と定義するのは難しいと思います。

担保する工程で分けるとすると、
いままでいくつかの現場で見聞きしてきた中でも、

パターン1：ビジネス検討およびシステム概要の検討
パターン2：ビジネス検討から実装まで
パターン3：ビジネス検討とシステム概要の検討＋プロマネ

という3つのパターンがありましたので、
現場によりディレクターのカバー範囲となる工程が異なるのが分かっていただけるかと思います。

また経験上、ディレクターは得意とする領域により、下図のように4つの系統に分けることもできるかと思います。

コアスキルを中心として、

SEOやWEB広告などが得意なら、マーケティング系ディレクター
開発マネジメントが得意なら、開発系ディレクター
UI/UXなどが得意なら、フロント系ディレクター
業務知見が豊富にあり業務運用が得意なら、バックエンド系ディレクター

という感じですね。
※ディレクターのコアスキルに関しては後述いたします。

ただ、どの系統にも共通して概ね、

ビジネスの検討を行うこと（自社サービスであれば自社メンバと、お客様がいるのであればお客様と）
そのビジネスを実現するための要件定義を行う
必要に応じてプロジェクトのマネジメントや設計・実装・テストを行う

というのがディレクターとしての仕事の流れになります。

なお、SBWorksでは「ビジネス検討とシステム概要の検討＋プロマネ」のパターンの「開発系ディレクター」が多く、私もいま現在この役割を担っています。

ディレクターに必要なコアスキルは何か？

どの系統のディレクターにも必要なコアスキルがある、
とお話ししましたが、その中でも代表的なものを4つ、ピックアップします。

・コミュニケーション能力

ディレクターはビジネス検討もしくはそれに近いフェーズを担うため、ビジネスやプロジェクトの意思決定者と会話し、判断いただく機会がかなり多いです。ビジネスやプロジェクトの方針を意思決定者に判断頂く際、なかなかGOが出ないとその分スタートは遅れ、機会損失になってしまいます。そのため、コミュニケーション能力…厳密に言えば「物事を分かりやすく、端的かつロジカルに説明できる能力」は必須能力と言えます。

・ITに対する幅広い知見

自社サービス然り、お客様のビジネス然り、予算は無尽蔵にあるわけでありません。何をどう組み合わせればそのサービス・ビジネスは費用対効果高く実現できるのか、ディレクターはシステム概要の検討時に模索する必要があります。そのため、実際にシステムを構築できなくても構わないので、プログラミング言語の特性や各種インフラ・ミドルウェアの特徴など、幅広い知識を自分の引き出しから出せるようにしておく必要があります。

・関係者調整力

ディレクターは社内外含めて複数のステークホルダーと関わる場面が多いですが、ステークホルダー全員の要望が一致していることは稀です。全員の要望を叶えようとするとプロジェクトは一向に前に進まないため、第三者視点に立ち、各ステークホルダーの要望を取りまとめて1つのプラン・方向性を練り上げる、といった役割がディレクターに求められます。そのため、皆の要望を聞きつつ、その落としどころを探って方々を説得して回り推進する「関係者調整力」がとても重要なスキルになってきます。

・提案力

特にお客様のビジネスをお手伝いする場合ですが、ディレクターに求められるものは、「筋の良い提案」です。現在の状況や様々な事象を思考フレームワークを使いながら分析し、クリティカルな課題を抽出、その課題を解決する方法をメリット・デメリット等とあわせて分かりやすく資料にまとめ、お客様に提案する…といった、筋の良い提案を行うための一通りの力も、ディレクターに欠かせないスキルのひとつです。また、提案を行う際、お客様の目線に立つことも大事ですが、「このサービスを使うユーザはどう思うか？」「自社(開発会社)として最適なソリューションは何か？」といった多角的な視点があると、関わる人皆が幸せになれる提案ができると思います。

まとめ

WEB業界におけるディレクターの役割は幅広く現場によって異なるものの、そのどれにも共通したスキルが必要であることをお話しいたしました。

なお、SBWorksではディレクターを大募集しておりますので、我こそは！という方はぜひ、blogコメントや弊社公式HPの問い合わせフォームからコンタクトいただければと思います。

お読みいただきありがとうございました。

1. 本記事について

CS-Cart のレスポンス（サイト応答）が極端に劣化し、HTTP 500 エラーが発生するケースがあったため、確認すべき箇所と、その対処方法を記事にします。

本記事は CS-Cart 導入済みの方向けのため、
CS-Cart についての説明は割愛致します。
詳しくは公式サイトをご確認ください。

公式サイト
開発者ドキュメント

2. 環境情報

– OS/ソフトウェア
EC2（Amazon Linux 2, SSD, 64 ビット, t3.large）
RDS（MySQL 8.0.17, マルチAZ, db.r3.large）

CS-Cart マーケットプレイス版（4.9.2_JP_1）
PHP（7.2.30）
PHP-fpm（7.2.30）
Apache（2.4.39）

– AWS環境（ロードバランサ + EC2 + RDS のシンプル構成です）

3. 問題発生時のリソース状況

以下は CloudWatch ダッシュボードで表示したメトリクスです。
※ 表示されている値は 5 分間隔の平均値です。

問題が発生した 19:00 前後の状況を確認すると、

①EC2
　1. CPUUtilization（CPU 使用率）は特に問題なし
　2. CpuWait（CPU 待ち時間）が上がっている

②ApplicationELB（ロードバランサ）
　1. TargetResponseTime（ユーザへリクエストが返却されるまでの時間）が上がっている
　2. NewConnectionCount（新規接続数）は遅延が発生した時間帯以外と比較する限り問題なし

③RDS
　1. DatabaseConnections（DBコネクション数）が上がっている
　2. CPUUtilization（CPU 使用率）は特に問題なし
　3. ReadLatency（SelectSQLの待ち時間）が上がっている

上記のため、

・WEB サーバが忙しい訳ではない。
・DB コネクション数が上がっている時間帯に処理待ちが多く発生し、レスポンスタイムが遅くなっている。

という状況でした。

4. 原因

RDS の Performance Insights を確認したところ、問題が発生した時間帯で「Table_locks_waited（テーブルロックによる処理待ち）」が多数発生していました。

「Table_locks_waited MySQL」で調べると、テーブルのストレージエンジンが「MyISAM（マイアイサム）」の場合はテーブルロック方式という記述が、、

CS-Cart テーブルのストレージエンジンを確認したら「lock_keys」テーブルを除き、全て「MyISAM(マイアイサム)」でした。

※ 詳しい内容は後述致します。

テーブルのストレージエンジンを確認するためのSQLは以下です。

select TABLE_NAME, ENGINE from information_schema.TABLES where TABLE_SCHEMA like '%cscart%';

テーブルロックの原因となっているストレージエンジンの変更を検討したいですが、CS-Cart が MyISAM 以外に対応していない可能性があるため、「CS-Cart MyISAM」で調べたところ、
CS-Cart は InnoDB（イノディービー）にも対応しているので問題ない。という情報と、
CS-Cart 開発者が高速化の方法について説明している記事の中で InnoDB への変換を推奨している情報が見つかりました。

MySQLストレージエンジン
How to speed up CS-Cart. Server details

これで裏付けが取れましたので、以降の対処を行いました。

5. 対処内容

それぞれ以下の作業を行いました。

①RDS
　CS-Cart テーブルのストレージエンジンを「MyISAM(マイアイサム)」から「InnoDB(イノディービー)」へ変更

②EC2
　OPcache と APCu を導入
　※ こちらはテーブルロックへの対処ではないですが、高速化の観点で CS-Cart 開発者から推奨されているため、実施しました。

①RDS

CS-Cart テーブルのストレージエンジンを「MyISAM(マイアイサム)」から「InnoDB(イノディービー)」へ変更

MyISAM はテーブルロックの方式なので、参照クエリや更新クエリが多くなるにつれ、処理待ちが発生します。

共有ロック（READロック)	他のプロセスは読み込みはできるが、書き込みができなくなる
排他ロック (WRITEロック)	他のプロセスは読み込みも書き込みもできない

本件の問題が発生した際はテーブルロックが多く発生しておりましたので、
処理待ちが発生した結果、ユーザへ HTTP 500 エラーが返却されてしまいました。

この問題を解消するため、テーブルエンジンを InnoDB へ変更します。

InnoDB を採用した理由は行ロック方式であることと、
CS-Cart は InnoDB でも適切に動作する旨、公式サイトに明記されているためです。
MySQL のテーブルエンジンは MyISAM や InnoDB の他にもありますが、特殊なユースケースで使用するタイプのため検討しておりません。
気になる方は公式サイトの「第16章代替ストレージエンジン」リンクを辿ってください。

公式サイト
第16章代替ストレージエンジン

MyISAM から InnoDB への変更は、

ALTER TABLE cscart_addon_descriptions ENGINE=InnoDB;

このように「ALTER TABLE」SQL で行います。
ひとつひとつ SQL を書くのが大変なので、以下のように一括で作成します。

select
  concat('ALTER TABLE ', TABLE_NAME, ' ENGINE=InnoDB;') as 'sql'
from
  information_schema.tables
where
  table_schema like '%cscart%'
  and
  engine = 'MyISAM';

CS-Cart の全テーブルを MyISAM から InnoDB へ変更したら RDS への対処は完了です。

②EC2

OPcache と APCu を導入

PHP はインタプリタ言語のため、呼び出される度にプログラムの解析/解釈が行われ、オーバーヘッドがあります。
今回はクライアントへのレスポンス速度を改善する必要があるため、PHP の速度改善に寄与する「OPcache」と「APCu」をインストールします。

— 解説
OPcache を導入すると、コンピュータが解析済みの「バイトコード」をキャッシュして再利用してくれるため、処理が高速になります。
APCu は PHP が動的に作成したデータをキャッシュしてくれるので、ページの表示速度が改善されます。

本環境の PHP は「remi」リポジトリでインストールされているため、
インストールコマンドは以下になります。

$ sudo yum install --enablerepo=remi,remi-php72 php-opcache php-pecl-apcu

※ OPcache が php-opcache です。
※ APCu が php-pecl-apcu です。

インストールが終わりましたら、Apache を再起動しましょう。

$ sudo systemctl restart httpd

以下の表示となれば完了です。

OPcache（with Zend OPcache … の記述が追加されます）

$ php -v

PHP 7.2.30 (cli) (built: May  5 2020 18:04:45) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.30, Copyright (c) 1999-2018, by Zend Technologies

APCu（apcu が表示されます）

$ php -i | grep apc
 /etc/php.d/40-apcu.ini,
 apcu
 MMAP File Mask => /tmp/apc.XXXXXX
 apc.coredump_unmap => Off => Off
 apc.enable_cli => Off => Off
 apc.enabled => On => On
 apc.entries_hint => 4096 => 4096
 apc.gc_ttl => 3600 => 3600
 apc.mmap_file_mask => /tmp/apc.XXXXXX => /tmp/apc.XXXXXX
 apc.preload_path => no value => no value
 apc.serializer => php => php
 apc.shm_segments => 1 => 1
 apc.shm_size => 32M => 32M
 apc.slam_defense => On => On
 apc.smart => 0 => 0
 apc.ttl => 0 => 0
 apc.use_request_time => On => On
 apc.writable => /tmp => /tmp

本来、性能問題を解決するにあたっては、1つ1つ対応を試し、原因箇所の特定をし、対策をし、効果を確認するのが鉄則ですが、本記事では「それぞれどの程度効果があったのか」についての測定結果がありません。
急を要したため、テーブルのストレージエンジン変更とPHPのキャッシュ化を同時に行い解決を優先しました。

6. 対処後のリソース状況

※ 表示されている値は 5 分間隔の平均値です。

対応前後の状況を比較すると、

– ApplicationELB（ロードバランサ）
　1. TargetResponseTime（ユーザへリクエストが返却されるまでの時間）
　　 6.87　→　0.8
　2. NewConnectionCount（新規接続数）
　　 6.87　→　395

レスポンスタイムが改善されていることが確認できます。

本記事は以上です。
問題が発生した際に CS-Cart についての情報をインターネットで検索したのですが、なかなか欲しい情報が見つからず苦労したため、掲載致しました。
解決への一助となりましたら幸いです。

月別: 2020年11月

WEB業界におけるディレクターとは何か？