GYOMUハックのプロセスについて考えた

この記事はGYOMUハック/業務ハック Advent Calendar 2019の1日目の記事です。

 

こんにちは、GYOMUハックエンジニア歴5年目のみりです。今年も始まりましたAdvent Calendar!どんな記事が続くのか楽しみにしつつ、私はGYOMUハックのプロセスについて考えてみたことを書いていくことにします。

GYOMUハックのおしごと

そもそもGYOMUハックって何をやっているのという方が多いと思いますが、マーケやセールス、サポートなどのエンジニア以外のBizメンバーの業務の基盤をサポートする社内SEみたいなイメージです。

 

f:id:mirygoaround:20191130152029p:plain

GYOMUハックの仕事の範囲

こんな感じの記事も書いているので、ぜひ読んでみてください!

mirygoaround.hatenablog.com

プロジェクトのやっていき

プロダクトの開発においては開発ロードマップがあり、そのロードマップにそって機能開発することが多いかと思います。GYOMUハックにおいては、事業の成長曲線をイメージしながら未来を見据えて基盤を作る必要があります。事業部が今やりたいという施策や業務はその時点で機能提供できている必要があり、その機能提供のためのプロジェクトを実施する必要があるのです。

f:id:mirygoaround:20191130152944p:plain

成長曲線

ここで難しいのは、その時点で事業部側はその機能を求めていないことも多い、ということです。GYOMUハックのプロジェクトの特性としてステークホルダーが多く巻き込み型のプロジェクトが多いですが、そのプロジェクトメンバーがイマイチなぜやるのかに納得しないとなかなかプロジェクトはうまくいきません。

なぜやるのか、なぜ今なのかをロジカルに説明できない案件は進められないですし失敗するので、いつやるのかのタイミングを計るのかもかなり重要なスキルになってくると思います。個人的にはGYOMUハックロードマップを作成していて、それをもとに話をできると良いと考えています。

プロジェクトを始める前に

プロジェクトを始めるときに最初にやらなくてはいけないことはステークホルダーをおさえることです。

そのプロジェクトで解決したい課題、成し遂げたいことを話し合います。ここでGYOMUハックは話を聞いてある程度どんな実装が必要か、どれくらいの工数がかかるのかの見積もりをします。完全に脳内試算です。その場でわからないことは持ち帰ります。

そして実現難易度と、業務インパクト、他の案件の状況を天秤にかけて優先度を決めます。

 

プロジェクトが始まってまず最初にやること

プロジェクトが始まってから、最初にやらなくてはいけないことはプロジェクト終了後の理想状態はなんなのかをイメージしておくことです。事前準備は大事なので、それくらいまでは心の準備をしておきます。

次にステークホルダーを集めて、ゴールの認識合わせをします。何が達成さたら・実装されたら、プロジェクトとして終了なのかを決めます。

それが決まったら、いつまでになにをやるのか、やらないのかをきめます。大まかなスケジュールを決めることによって、全員の認識があうので、すり合わせは大事です。

理想状態を定義するには

ここで私がプロジェクトの序盤でかなり大事にしていることが1つあって、それは全員に理想を語ってもらうことです。課題ベースで話をすると、現状+αの何かしかアイデアが出ないことがあります。目の前の業務と今までの業務にかなり引きずられるためです。

そんなとき、私は1〜2時間たっぷり時間をとって、今までの業務は全部忘れてどうなるのが理想なんだろう、を一緒に考えるようにしています。最初はピンとこないんですが、例えばこんなのはどう?など簡単な例を出してみると、結構刺激されてみんなのアイデアが出るようになります。

そうして一緒に理想状態を定義して行くと、たどり着きたい状態が共通認識としてイメージしやすいです。

進めていきかた

いざプロジェクトが開始したら、あとはひたすらスケジュールに合わせてタスクをこなしていくだけになるのですが、定例は必ず入れるようにしています。

プロジェクトのスピード感で、WeeklyかTwice a Weekで定例を行います。

定例の中では、

  • タスク進捗
  • 状況の変化
  • スケジュールへの影響
  • 問題点

を確認します。日々状況が変わるので、状況の変化によってスケジュールに影響がないか、プロジェクトを進めることに影響がないかを逐一確認をします。

 

あとはひたすらタスクを消化していくのみです。邁進!

クロージング

ゴールで決めた判定基準が満たされたらプロジェクト自体は完了となります。

その後、しばらくは不具合がないことを監視して、一旦監視体制はおわりです。

振り返り

リリースしてしばらくしてから、関係者を集めて振り返ります。これも物によってタイミングが重要なのでうまく見計らって振り返りの日程を決めてください。

KPT(Keep、Problem、Try)で、プロジェクトの進め方自体とリリースした物自体についてふりかえります。ここで、当初の目的が達成されたのかも判定します。

振り返りを行うことで次のプロジェクトの進め方などを改善していきます。

おわりに

言葉にして書いてみるとけっこうあっさりしていて当たり前のプロジェクト開発じゃん、みたいな感じになってしまいましたが、関わる人が多かったり、期日が決まっていたりするとめちゃくちゃ大変です。

きめ細やかなコミュニケーションが重要になってきますし、手を動かしながらプロジェクトを回す力が求められます。

GYOMUハックというまだ世間的には新しい領域を広めていきたいと思っていて、スキルの言語化や仕事のフレームワーク化を頑張っているところです。

 

世の中のGYOMUハックに携わるみなさんとのコミュニティを作っているので、もし興味のある方がいらっしゃったらぜひご参加ください!

sites.google.com