こんにちは。秋葉といいます。
webサービスを運営されているお客様の元で3年半ほどITディレクターとしてシステム保守をしています。
システムが複雑で制約も多くて何をどうしたらよいのかわからない…
技術は進歩しててできることはいっぱいありそうだけど、選択肢がありすぎて何を選べばよいかがよくわからない…
せっかく作った機能なのに、イマイチ思惑通りの効果が出ない…
そんな悩みをかかえるユーザーの課題解決に向けて、ユーザーとともに最適な方法を考え、実現に伴走するITディレクター。
とはいえ、具体的にどういうことをするのか、イメージがつきづらいのではないでしょうか。
今回、この記事を書くにあたって、
改めてディレクターとは？を調べてみたところ、
制作物の作品としての質に責任を持つ者のこと
by Wikipedia
という定義があったので「質」というキーワードで私のお仕事をもとにITディレクターとは何をする人なのか振り返ってみようと思います。
まずはお仕事紹介
ユーザーがシステム開発を外部の会社（以下ベンダー）に依頼する形の場合、ユーザーが機能要求を提示し、ベンダーが要求実現のために要件定義・開発・テスト・納品を行います。
つまり、ユーザーが取り組んでいる課題に対しどのようにシステム化するべきなのかを明確にしている必要があるのですが、先述のとおり、そもそものシステムに制約が多かったり、逆に取れる選択肢がたくさんある中で、最適な実現方法を選び取るのはかなり難しい。
また、ユーザーは他業務を持ちつつシステム化を担当していることも多く、検討やベンダーコミュニケーションに時間を割けず、思うように工程が進められない、といった悩みも多いです。
ITディレクターはユーザーのやりたいことをくみ取り、システムとしてどうあるべきかをユーザーとともに具体化し、時にはユーザーに代わってベンダーとのコミュニケーションを行い、最適な形で確実に実現できるよう各工程を伴走します。
…と書くと、だーいぶ大仰ですが、保守フェーズであれば1つ1つの案件規模はそんなに大きくはありません。
私の日々のお仕事はこんな感じ。
- 仕様問い合わせ/調査
- 案件相談（できる？できない？）
- 概算見積り
- 要件定義
- 開発ベンダー接続/QA対応/成果物レビュー
- 保守案件スケジュール管理/推進
- プロセス改善提案/検討
…etc
システムまわりの便利屋さんといったところでしょうか。
で、「質」に責任を持つとは？
システム開発で「質」と言った場合、真っ先に思い浮かぶのは「品質」≒バグが出ないことです。
もちろん品質は大事。
利用者に影響が出るのは言わずもがな、対応に割かれる工数も馬鹿になりません。
これを担保するための成果物レビュー・受け入れテストもITディレクターの仕事です。
－－－－製造品質
では、品質を担保するためならどんなに工数をかけてもよいか？
システムは大規模で複雑です。
品質担保のためにはテスト工数なんていくらでもかけられます。
でも、かけられる工数には上限がある。
ITディレクターはシステム構成・案件特性を理解した上で、品質が担保できる最小限の工数となるようにテストのスコープを判断します。
納期優先案件の場合には品質リスクをとってでもケースを減らす判断をすることもあります。
－－－－品質と工数の妥当性評価
「バグ」というと「仕様バグ」というのもありますね。
できたシステムは取り決めた仕様どおりなのに、ユーザーの求めている機能を満たせない・運用がまわらないというやつ。
これは開発にかけたコストがまるまる無駄になる、要件定義を実施しているITディレクターとしては最も避けなければならないバグ、と思っています。
「仕様バグ」を回避するには？
当然、ユーザーの意図を正確に把握すること、
機能実装後のシステムを含めた全体フローが描けていること、
関連部署との調整ができていること。
そのすべてをITディレクターが実施するわけではありませんが、関係者を集めて場をセッティングしたり、個別にヒアリングしたり、必要なデータを用意したり、スケジュールを守るため、そして狙った結果を出せる機能を作るために奔走します。
－－－－要件定義品質
上記をクリアして、意図通りの機能を障害なく最小の工数でリリースできた！
さて、その「最小」はどこから見た最小でしょうか。
単案件で最小だったとしても、工数を削減するためにイレギュラーなつくりにしてしまうと、 後々の案件で影響調査にかかる工数も肥大化・最悪障害の温床になることがあります。
長期的に保守していくシステムは、将来にわたって改修しやすい作りを維持することが長い目で見るとコスト削減になります。
今の「最小」を犠牲にしても大方針に沿ったつくりにするか、
とはいえ売上に影響するような案件はタイミングが重要、
後でちゃんと作り直すことを前提に、今はミニマム要件で暫定的な実装をするか、
そんな調整を行うこともあります。
－－－－適切なQCD
さらに、案件として起案される前、まだやるかやらないか？なとき。
案件によっては、発案者が「やる！」といえば実現に向けて動ける案件と、関連部署と調整しなければ動けない案件があります。
後者は特に会社への業務・売上等のインパクトが大きいものが多いのですが、その分要件を固めるまでのパワーがかなりかかります。
こんなとき、調整の前にこういうことってできるの？であったり、どれくらい工数かかりそうか？という情報を提供することで、詳細検討するパワーを割くか、それとも見送るかの判断ができ、無駄なパワーを使うことを避けられます。
－－－－企画検討パワーの最適配分
…と、案件にフォーカスした振り返りになりましたが、こうしてみると、どのフェーズでも、やるべきことにかかる工数・パワー≒コストを最小限にすることで、やりたいことにコストを割けるようにする、という観点で日々の業務を行っていると言えるかなと。
まとめ
ITディレクターとは
決められたコストで最適な状態を実現することに責任を持つ、
一言でいうと「かけるコストの質を最大化する人」！
ということで、私もさらなる質向上に向けて日々精進していきたいと思います。
