こんにちは！GrowGroup株式会社の石原です。
本業はエンジニアですが、社内のワークフローや業務周りの制度を整えています。
その中である程度知見がたまりまして、すでに知っているというものも多いかもしれませんが、最初から意識していればよかったという事項を書き記します。
目次
タスク管理について
どれだけ｢意識できる｣か
世の中、タスク管理やストレージ管理など様々なツールやサービスがでていますが、どれだけ運用できているかが、結局は組織にとっての成果基準になります。
タスク管理も Asana でも Backlog でもスプレッドシートでもなんでも良い。しっかりと組織のメンバーが意識して使うかどうか。それが肝です。(当たり前ですが)
タスク管理が難しい、なかなかうまくいかないと耳に挟みますが、そもそも意識の問題という結論に至る気がします。
非常に泥臭いですが、まずはスプレッドシートでも何でも良いので運用してみて、運用にフォーカスして見た方が良いです。
タスクの和が稼働時間となるように
打ち合わせや社内のミーティング、制作以外の業務をある程度見える化しなければ、タスク管理は途端に破綻します。1日8時間稼働するとしても、場合によっては4時間ほどしか稼働できない場合は多々あるはずです。
プロジェクト以外の個人のタスクも一緒に管理しなければ、予想していた期日間際になっても着手できていない状態になりがちです。
GrowGroupでは別途個人ごとのプロジェクトを立て、業務以外のタスクを登録し、タスクの和が稼働時間となるように調整しています。
心理的安全性は重要
タスクの期日に間に合いませんと報告するのにはハードルがあります。
期日を過ぎるというのは、当然業務的にもまずい状態。
しかし、｢期日を守って！期日に間に合わなさそうな場合は即刻連絡して！｣と伝えても、きっと同じことが繰り返されます。
何でも言い出しやすい環境、つまり心理的安全性が担保された状態というのは、タスク管理でも重要です。
チーム内でアラートが出しやすい環境や仕組みを作ることで、より早くリスクを洗いだしましょう。
GrowGroupでは朝のミーティング時に各個人のタスクを確認し、アラートを早めに上げてもらえるように日々運用しています。
ルール・制度
ルールや制度は導入後がより重要
社内でいろいろなルールや制度が立てられていきますが、制度を作って、アナウンスしただけではまず運用されません。
実際に運用できているかどうか定期的に監視し、リマインドしていく必要があります。
ルール・制度の立案時点から担当者をだれにするか、どのようにリマインドしていくかは検討した方がよいです。
GrowGroupでも、業務改善の担当者の方で、4半期ごとに施策の状態を確認し、リマインドするなどのフローを作っています。
マニュアル文化は一長一短。バランスが重要。
組織としてマニュアルは非常に重要です。GrowGroupでもマニュアルは社内で各工程ごと、工程をまたいだものは全体のマニュアルサイトにて管理しています。
マニュアルは業務を円滑にしますが、作成されたマニュアルをどのように周知徹底し、運用していくかはまた別の話です。
マニュアル文化が変な方向に進むと、｢マニュアルを確認していない方が悪い｣という文化が出来上がり、途端に仕事がしにくくなってしまいます。
マニュアルは当然重要なドキュメントですが、作るだけでは運用できないことを念頭に、前項の導入後の運用体制を同時に検討する必要があります。
自動化とモチベーション
マニュアルやルールも、管理コストを削減する一種の自動化だと思います。
マニュアルやルール、ツールなどで自動化を推し進めた場合、業務の定型化が進みます。
業務を統括する立場としては、当然、属人化せず、効率化された業務フローを望みますが、誰でもできる仕事に人はやりがいを中々見い出せません。
何ごとも改善する時は｢遊び｣が重要です。最低限守るべきルールは作った方が良いですが、それ以上のことは担当者の裁量に任せるべきだと思います。
業務改善
過去より未来を意識する
何か社内でミスが起因したインシデントやアクシデントが発生すると、どうしても言い訳を考えてしまいます。
｢そっちの伝え方が悪い｣｢どこにもそんなこと書いていなかった｣｢そっちでも確認してもらえていれば…｣など。
ただ、その思考に陥ったとしても発生した事実は変わりません。
責任の所在や言い訳を検討するよりも、発生した事実を受け止めて｢次どうするか｣が重要です。
ワークフローや業務改善を行う上で、あくまでも主語は｢組織｣です。
改善策を検討する際には当然原因も検討する必要がありますが、それは個人の問題ではなく、
そのような体制になっている組織の問題であるという意識をもち、組織としてこれからどうしていけば良いのか考えます。
非中央集権型の改善活動
GrowGroupは 0=>1の組織です。
平坦でミニマムな構造から始まり、いまでは20名ほどになりました。
最初は当然3~5人程度のため、業務改善なども責任者は私で行えていましたが、組織の規模が大きくなると当然難しくなります。
そんな時、一応は業務改善周りを統括する責任者として、各工程ごと(設計、デザイン、コーディング)の業務改善などにも口出ししていましたが、今ではほぼ任せっぱなしです。
課題の提起だけポロッと伝え、実際の改善案の検討や運用はそれぞれの責任者に全部任せています。
業務改善で肝になってくるのは、いかに改善のサイクルを回すかです。
意志決定時に口を挟むと、途端に心理的安全性がなくなりサイクルが回りにくい状態になります。
それよりも、すべて任せ改善を実際にどんどん回してもらい、自分自身らで改善が回っていき、改善の方法自体も向上していく方が長期的には良いと考えています。
データはデータ。人は人。
Webサイトを制作する際もアクセス解析のデータを元に改善しますが、業務改善もこれまでのタスクの実積データを元に改善案を検討することもあります。
- 案件ごと、工程ごとのリードタイム
- 工程ごとの実積効率
- 個人ごとの実積
- 個人ごとの予想工数
- 実積工数と案件単価の比較
当初、実積の入力を正確に行ってもらい各工数を算出し、工程ごとに非効率的な業務フローを改善したりなどデータを元にした改善を行っていました。
しかし、データを元に改善をしていると、どうしても実際に働く人の気持ちが見えづらくなり、各個人のスキルや課題に責任を被せがちです。
データだけではなく、もっと人に向き合い意見をヒアリングしながら改善を進める方が、より重要だと今では考えています。
その上で受注高と売上高のバランスは注視し、組織全体として正常に稼働しているかどうか判断ができるようなデータのみ集め、改善を図っています。
以上、業務管理をこれまで行ってきた上で最初から知っておきたかったことをつらつらと記しました。
当然、経験したからこそわかったこともありますが、組織の目的に即した業務ができるようにするにはどうすれば良いのか皆さんも考えてみてください。
現場からは以上です。
