データギルドにおけるQCD向上に向けた取り組み

本記事は、クリスマスに向けデータに関する想いや技術をぶっちゃける Advent Calendar 2022 24日目の記事です。

はじめに

　はじめまして、データギルドを運営しているSinkCapitalの櫻井と申します。
カレンダーの終盤とのことで自分の会社について触れておこうかなと思います。
少し細かい自己紹介はこちらを参考にしてもらえればと思います。
では以下本編になりますのでよろしくお願いたします！

なぜQCD向上が必要だったか

　弊社はデータギルドという形式でデータに関する業務の支援をさせていただいており、
ワーカーの多くが副業やフリーランスで構成されています。
必要に応じて副業やフリーランスの人材を活用することで、
必要十分な稼働を短期的に確保することができると言った特徴があります。
　ただ一方特に副業という形態の場合は工数や働き方のばらつきは大きく、
それによって提供価値のQCDは不安定になりがちです。
弊社の規模拡大に合わせて運営側が見れる範囲も限られてきた中、
QCDを下げないために行ってきた取り組みについて書かせていただければと思います。

ギルド組織におけるQCDの特徴

＊ 弊社提供価値のイメージ図

　まず取り組みの説明の前にQCDそれぞれの簡単な説明を記載させていただこうと思います。

Quality :　品質

　これはアウトプットそのものの品質を指しており、
以下のようなものの品質を表しています。

• パイプライン構築　：　設計や開発したシステム
• マート設計　：　dwh上でのマート設計書
• データ分析　：　分析設計やデータ抽出結果
• ...

まさに技術力や経験が必要になってくる箇所であり、
ここが不十分だと例えばSQLや仮説設計のミスが発生してしまいます。
その結果「無駄にデータをこねただけでなんの成果も得られなかった...」
といった状況を招きかねない箇所になります。

Cost　：　コスト

　次は活動にかかるコストの部分になります。
コストは役割に応じて設定しており無理に調整する取り組みは行ってはいませんが、
元々営業非介在で見積もり時から最適な人員配置を提案することで、
必要十分な分のみのコストが掛かるような仕組みとなっています。
案件推進中であっても稼働内容の変更に応じて体制を変えるため、
初めデータ基板側の人材が多かったところから、
データ分析側の人材に入れ替えていくと言ったことを行う場合もあります。

Delivery　：　納期

　最後のデリバリーが個人的にギルドで一番困難な点だと考えています。
というのも工数や働き方のばらつきが大きい副業という形態では、
外部要因によって工数が取れるタイミングが変わったり、
想定より取れる工数が少なかったりといった事が起きる可能性が大きいためです。
そのため単純に規模を大きくしていくと、
外部要因によりデリバリーへのリスクが高まります。

QCDを高めるための取り組み

　ここからはそういった中組織拡大時にQCD低下を防ぐため、
取り組んできた内容について説明させていただこうと思います。

メンバー加入時の技術テスト

　まずはメンバー加入時に行うテストの導入です。
当然Qualityに関わる技術力の面は図ることができますが、
それと同時に問題の解釈に幅をもたせることで、
期日に対して要件確認をどのように行うかも確認することができます。
一例として問題によっては以下のような基準で採点しており、
回答の正確性以上に事前確認を以下に行えているかを重視していたりします。

　実際の業務においては最初から要件が固まりきっていないことも多く、
要件確認の余裕を持って対応を行えるかなどの確認をすることができます。

余談ですがテスト受講用のGoogle Forms送信後に、
Google Apps Scriptが動き権限付与がされた回答用Google Driveができるといった、
少し凝った自動化を行っていたりします。

疎結合なタスク管理

　次に行ったのがJIRAやBacklogといったツールを用いた疎結合なタスク管理です。
「工数や働き方のばらつき」がある中でPRJを回すためには疎結合にすることが重要で、
それによって例えば朝に稼働する人と夜に稼働する人が同じPRJで稼働できるようになっています。
またツール自体の使い勝手もありますがタスクを渡す側がツールに合わせることで、
副次的に背景やゴールの言語化が進みテキスト上での案件推進が促進されたり、
期日やステータスのモニタリングによってシステム的にデリバリーの担保を行うことができます。

全体の管理業務のフロー化

　最後に行ったのがそういったツールを用いた管理フローの型化です。
例えば内部定例の開催頻度や確認内容などを型化することで、
PMにあたる人が変わっても必要な内容が確認できるようにしています。
こちらは現在進んでいるプロジェクトの中で良いものを残しているため、
今後も改善余地が大きく存在する箇所かと思われます。

１年推進して見た結果

　一番わかりやすく変化したのはタスク管理のところで、
現在ではほぼすべてのプロジェクトにおいてチケット管理が行われ、
期日や稼動内容がひと目で分かる状態が担保されています。
フルリモートでの個人の予定に合わせて時間が組めることは、
副業やフリーランスの方の好む働き方ともマッチしており、
メンバー内でも働きやすいといった声を聞けることが多いです。
　テストや管理業務の型化による効果は感覚値ではで始めてきているため、
目に見える効果が出てき次第また記事にさせていただければと思います。

最後に

　今年は会社3期目の年だったのですが、
単なる人の集まりから「組織」へと変革させる準備をしていた１年だと感じています。
まだ組織の体裁を整えている状態ですが、
今後は知見の蓄積などより未来に向けた準備を進めていきますので、
引き続きどうぞよろしくお願いします！