Intro
先日JBUGが開催するイベントに参加しました。
JBUGは全国で15拠点あるBacklogのユーザーグループですが、京都は初開催ということでした。
自分はBacklogユーザーではないのですが、オフィス近くで開催されるということと、プロジェクトマネジメントに関するイベントは参加したことがなかったのでせっかくなので参加してみました。
まず参加するとモスバーガーを配っていただけました。飲み物をいただけるイベントは多いですが、モスを頂くのは初めてで新鮮でした。
19時開始で小腹がすき始める時間なのでありがたかったです。
ただ食欲に負けて食前に写真を撮り忘れました。。。
LT大会
LT01:「情報伝達から見るコミュニケーションマネジメント設計」
まずはLT大会からのスタートでした。
一人目はロフトワークの上ノ薗さんの発表です。
内容はコミュニケーションマネジメントについてでした。
大きくポイントとしては3つ。
- 相手の文化を知り自分たちの文化と比較する
自分が使っているという言葉が必ずしも相手に正確には伝わっているとは限らないという話です。
例えば、「Fixした」という言葉を使っていた時、自分は内容が確定したという意味で使っていたにも関わらず、クライアントはそういう意味で受け取っておらず、プロジェクト中盤でそのことに気づいて冷や汗をかいたという話をされていました。
早いうちに言葉の意味や文化を握りあっておくというのは重要ですね。 - コミュニケーションラインにプラスしてツールと手法の確認をすること
チーム間のコミュニケーションラインのみならず、どういうツールや手法を使っているかということも確認しておく必要があります。
特に決裁者とのコミュニケーション方法は早めに確認しておいたほうがよいとのこと。それは決裁者が他の人が使っているツールと全く違うツールを使っている場合があるからです。
例えば決裁者のみ画面のレイアウトを紙に印刷して確認している場合、実はレイアウトが崩れていて決裁をもらえないということがあり得るからということです。 - プロジェクト序盤に摩擦を起こしておく
プロジェクト序盤に色々と本音を聞いておけば、設計のサイクルを早く回すことができます。後々コミュニケーションの摩擦が起きると今更感があったりするということもあります。
色々をプロジェクトを回すうえでのコミュニケーションについてのお話を聞けて、自分の経験からしても確かになーと納得できることが多く、経験を言語化していただいたように感じました。
LT02:「社内での知見共有」
二人目はビーワークス 三谷さんの発表です。
内容は社内での知見共有についてでした。
技術の進歩が激しい昨今、自分ひとりで全ての情報をキャッチアップするのは難しく、チームでカバーすることが重要になってきています。ただ、チームでのカバーにも難しさもあるとのことでした。
例えば知識差が大きい場合、初心者はそもそも質問するための言葉がわからず、熟練者は初心者に対してどう説明していいかがわからないということが起こりえます。
またチーム規模が大きい場合、互いに何が得意かがわからず、誰に聞けばいいかがわからないということが起こりえます。
その問題を解決するために知見共有が役立つとのことです。
とはいえ知見共有もどうやったらいいのか？という問題もあり、ビーワークス様ではbacklog上で社内ブログをやることで解決しているとのことでした。
使い方としては、ブログ用のプロジェクトを作成して、issueを立てることでそのissueがブログのような機能を果たしているとのことでした。確かにissueであればコメントを追加したり、コードを紐づけたりできるので面白い活用の仕方だなと思いました。
LT03:「Backlogで爆速カスタマーサクセス」
三人目はブリッジコーポレーションの谷口さんの発表です。
谷口さんはスライドを用意されていたのですが、時間がないからということでスライドを全てスルーしてフリートークするというスタイルをとられて中々の発表強者感でした。
内容としては、納品したあとの製品の変更をする際の対応速度の話だったのですが、過去は軽微な変更をするのにも人員配置の問題で1か月ほどかかってしまっていたという問題があったそうです。
それを運用チームを作成し、一人が窓口から最後までまでやることで対応速度が非常に早くなったとのことでした。
ただしこの方法には一つ問題があり、その人に属人化してしまうということです。
それを防ぐためにBacklogを使ってタスクを集約し、もしその人がいなくても誰でもできるような体制にしたとのことです。
このあたりは非常に共感できるところで、うちも人手が少ないので属人化しがちなので、なるべくドキュメントを用意したり、自動化して誰でもできるようにがんばっています。
トークセッション
LT大会の後はトークセッションがありました。テーマはチームで生産性をあげるための心得ということで、スクラムマスダーさん、dalizさん、上ノ薗の三名が各トピックごとにパネルディスカッションされるという形式でした。
ここでは各トピックごとに皆さんが離された内容を簡単にまとめたいと思います。
質問しやすい雰囲気を作るには
スクラムマスダーさん
- 話す回数が多いほど仲良くなる
- 出社するタイミングでのコミュニケーション設計
- おやつ神社（おやつを置いといて人が集まりやすくする）
- おやつを持ち込んで意図的に会話をできるチャンスを作る
- リモートの場合はランチミーティングのような形で作っていかないと難しい
daiizさん
- 社内ブログに仕事以外の情報を書く、観光地の情報とか
- 他の人が観光地の情報を参考にして話題になる
上ノ薗 正人さん
- チーム内に関して、ファーストバカになる
- 誰でもわかるようなことをまず質問すると質問のハードルが下がる
- バカにも種類がある
- 質問は鋭いが、聞き方を幼稚に見せて質問のハードルを下げる
- バカな質問するときは自分もある程度答えを持っていて、リカバリーが必要な場合は答える
会話が増えるような方向の工夫なり、質問しやすい雰囲気を作る工夫なり色々と皆さんトライされているんだなというのがわかる回でした。
プロダクトの機能を選ぶ、無くすはどう決める
スクラムマスダーさん
- 10年くらい使っているプロダクトだと使っている使っていないという機能がわかってくる。とはいえ消すのは難しい
- 機能offで作っていつかONにしようと思ったけど結局してないもの
- 本当にONにする必要があるか？
- 無くすタイミングは年に何回か見直しをかけるのが現実的
daiizさん
- お客様の要望を全て対応しないというのが大前提
- 機能は消すのが大変なので、本当に欲しいものが見つかるまでは作らない
上ノ薗 正人さん
- 序盤にある程度目安をつけておく
- クライアントが本当に欲しいものを見つけること必要なことが多い
- クライアントのいうことを鵜呑みにしない
皆さんそもそも作らない方がいいという意見が多かったですね。
一度作ってしまうとメンテしないといけないし、なかなか消すのは難しいので、作る前によく考えることが大事というのはその通りだと思います。
いい人が入社したくなる会社にするためにどんな事を工夫している？
スクラムマスダーさん
- 候補者には登壇、カンファレンスで知ってもらう
- 登壇しているから面接きましたみたいな話もある
- 逆に引き抜かれちゃうことも
- 登壇しているから面接きましたみたいな話もある
daiizさん
- 自分たちのプロジェクトがどういうビジョンを目指しているかをブログに書く
- 自分でプロダクトを作った苦しみみたいなところも公開していく
上ノ薗 正人さん
- プロジェクトの事例をアップすることを大事にしている
- スキルも大事だがカルチャーフィットを大事にしている
- 事例を読んで調べているかどうかも重視
- そういう熱意があるかどうかがカルチャーフィットしているかどうかに繋がる
- 事例を読んで調べているかどうかも重視
この辺りはうちの会社も採用困っているので参考にしたいところです。
まとめ
プロジェクトマネジメントをテーマとした勉強会の参加は初めてでしたが、技術系の勉強会とはまた違った刺激を受けることができました。
コミュニケーションマネジメントであったり、組織文化の醸成の話など、聞いてみると中々普段意識していないことを言語がしていただけたような気がして、いい経験になりました。
また、京都や関西でイベントが開催されれば参加していきたいと思います。
Discussion