副業でも、主体的に意思決定をしていくための技術

こんにちは。Rimo合同会社で代表社員をしている相川です。

Rimo合同会社は、基本的に副業の人で(フルタイムとの割合でいうと1:20ぐらいです)組織運営しています。なぜ副業中心の会社にしたのかは書いていなかったので次回書きます。

今日は、その副業中心の組織で、副業として働き始めた人が主体的に意思決定できるようになる技術というか心構えみたいなものを話そうかなと思います。

結論

先に結論を書きます。
「ティール組織」の意思決定をベースに、以下のように実行します。

1. 「問題の内容とその背景」と「解決策(選択肢がありメリット・デメリットがまとめられているとBetter)」の2点を書いて、関係者(社長・部長・メンター等の組織構成上の意思決定者、及び、有効な知見や意見を持っていそうな人)にSlack等で通知。
※ 議論が複雑になりそうな場合はGithub Issueを使う。

2. 関係者は、その解決策に対する意見や質問をする。ネガティブな場合は、懸念事項(なぜ悪いと思っているか)と代替案を示す。提案者はそれに答え議論を重ねる
※ ここで質問とかネガティブな意見が少なく2のフェーズが短くなるほど洗練されていて優秀

3. 2の意見を踏まえ、通常の場合、最終的に自分自身で意思決定する。
※ 大抵の場合意思決定には締切があるのでそれに間に合うように催促しながらすすめる。締切がない場合は簡単な問題なら当日-翌日、難しい問題でも2週間を目処にすると良い。

ポイントとしては、以下:
・1.の部分で解決したい問題の中身だけでなくその背景も書く
・1.の解決策の部分を洗練させ、2の時間を短くできるようにしていく
・3の部分で最終意思決定者は提案した本人(副業の人)であること

2つ目のポイントは、最初は洗練されていなくてもOKで、これを何回か繰り返すうちに勝手に短くなっていきます。

なぜ、主体的に意思決定する必要があるのか

雇い主も嬉しい
副業の場合、振られたタスクを単純にこなすだけという印象をもたれることがあります。実際、振られたタスクを着実に実行できれば十分優秀ですしそれが求められることも往々にしてあります。ですが、副業の人ばかりの会社では全員が振られたしごとだけやっていると、タスクを振る側が疲れ果ててしまうのでそれだと困るのです。

傭われ主も嬉しい
また、副業としてはたらく立場から見ても、主体的に意思決定できる環境で働くほうが楽しいという人は多いのではないかと思います。本業の会社選びで、「若手でも活躍できる」職場などが人気度が高いことを見ても、意思決定できる自由度が、仕事の楽しさややりがいを決定している一因とみてよさそうです。
自分自身の経験でも、何社かでエンジニアとしての副業や技術アドバイザーのようなことをやったことがあるのですが、言われたことをやるだけに近い環境のところは、「そもそももっと根本的なとこから設計しないとダメそう」みたいなことや「これ絶対やったほうがいいけど、進められる人もいないしやられないんだろうな」といった歯がゆさを感じたこともありました。その結果、正社員として働く魅力のようなものを再認識させられた記憶があります。一方、好き勝手なんでもしてくれていいよと言われたときはさすがに困ってしまったので、バランスが大事なのですが。

ただタスクをこなすだけの際も必要になる意思決定

先程振られたタスクをこなすだけの場合の話もしましたが、その場合でもある程度の主体的な意思決定が求められる場合もあります。

・営業活動で先方から利用契約の簡単な修正を求められた
・問い合わせに割と聞く価値のありそうな営業メールが入っていた
・終わりのあるタスクで、振られたタスクが終わってしまった

などです。

・営業活動で先方から利用契約の簡単な修正を求められた
　→ 通常はただ「どうすればいいですか？」と聞く。
　→ 洗練されると、まず自分で顧問の弁護士に意見を聞いた上で、「賠償金の限度額の上昇部分は受け入れられないけれどその他の修正は受け入れる方針でいかがでしょうか？」と聞く

・問い合わせに割と聞く価値のありそうな営業メールが入っていた
　→ 通常はただ無視
　→ 洗練されると、「この提案だけ価値ありそうですがどうしますか？」と聞く、または、自分でその営業の話を聞いた上で提案する

・終わりのあるタスクで、振られたタスクが終わってしまった
　→ 通常はただ「次何すればいいですか？」と聞く。レベル1だと次のタスク振られるまで待つ。
　→ 洗練されると、「XXのタスクやってて、YYのポイントが課題だと思ったんですがこれ解決してみましょうか」や「他のIssueを自分で情報取得してZZの部分できそうですがやりましょうか」と聞く

みたいになると思います。

もちろん、副業の人などの提案する側だけの努力だけではなく、組織側にもそれをやりやすいように、情報を開示しておくとか基本的なルールを予め示しておくなどの努力が必要です。

エンジニアの場合

上の例は簡単目な問題にこのルールを当てはめた例でした。より複雑な問題でもこの方法はうまくいきます。
うちの組織に多いエンジニアの場合は特に大事なので、エンジニアの例でより具体的に書きます。「XXXという課題を解決したい。YYY機能を実現したい」といったIssueを自分がひきうけた場合を考えます。

1-1. Issue上で問題の細分化をし、解決の方針を書いた上で、その方針でいいレビューを受ける。(この工程は問題がすでに細分化されていて十分小さい場合は省略される)

1-2. そのIssueを解決するPull Requestを作成しコードレビューを受ける。

2. レビューの指摘を受け、それを直す。

3. Approve(LGTM)をもらっていたら、自分でマージし、本番上でも問題なく動いているか動作チェックする。
※ マージはレビュー側がすることもありますが、コードを書いた本人がやったほうが問題が起きにくいと信じています。

なぜこの方法でうまくいくか

もう一度結論である意思決定方法を載せます。

1. 「問題の内容とその背景」と「解決策(選択肢がありメリット・デメリットがまとめられているとBetter)」の2点を書いて、関係者(社長・部長・メンター等の組織構成上の意思決定者、及び、有効な知見や意見を持っていそうな人)にSlack等で通知。
※ 議論が複雑になりそうな場合はGithub Issueを使う。

2. 関係者は、その解決策に対する意見や質問をする。ネガティブな場合は、懸念事項(なぜ悪いと思っているか)と代替案を示す。提案者はそれに答え議論を重ねる
※ ここで質問とかネガティブな意見が少なく2のフェーズが短くなるほど洗練されていて優秀

3. 2の意見を踏まえ、通常の場合、最終的に自分自身で意思決定する。
※ 大抵の場合意思決定には締切があるのでそれに間に合うように催促しながらすすめる。締切がない場合は簡単な問題なら当日-翌日、難しい問題でも2週間を目処にすると良い。

この方法でいい理由は、実は会社の最高意思決定者である代表/CEOも、これをやっているだけだからです。代表であっても、直面している課題に対して専門家であることの方が珍しいので、方針を示して、その領域に詳しい社員に意見を求めて、最後に自分で意思決定をしているだけなのです。

勢いのある組織だと、実際に仮置の解決案を施行してみて、現場からいろいろな不満や問題を吹き出させて、やりながら微調整していくといったことをとるかもしれません。思い当たる節などあるのではないでしょうか？？

この代表がやっている意思決定を、すべての人が行えたらより強い組織になりそうですよね。

それでは、今日はこんなところで。

はたらくを未来に