Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

経験を知識・スキルに置き換えて細分化する - 副業の改善編

転職活動中ということがあり、自分の過去の経験をもとに、求められる知識・スキルを持っているかを問われる機会が増えてきました。
そこで、過去の経験の一つを個別の知識・スキルとして細分化することで、一つの経験談からどのくらいの知識・スキルを持ち、それを実践で使ってきたのかを伝えられるのか、ということに取り組んでみたくなりました。

事例

以下の記事にまとめた、1年間の取り組みを対象にします。
1年ではありますが、コミット時間的には週1のオンライン8時間勤務と、それとは別に月20-30時間程度のリモート勤務でのものです。
そのため、フルタイムの仕事と比較するなら 1/4 - 1/5 程度にあたるできごとです。
大まかに 3 ヶ月のフルタイム労働くらいの感じで見ると良さそうです。

もともと開発者以外の人がメインの組織なので、営業・Web制作のディレクター・Webライターなど、様々な人への説明・ツール利用支援などが必要となりました。

tbpgr.hatenablog.com

情報共有ツールの導入

情報共有基盤のない環境に esa を導入した。

知識・能力

  • 情報共有ツールがあったほうが好ましいことを判断できる能力
  • 情報共有ツールの有効性を決済者に説明して納得してもらう能力
  • esa の基礎知識
    • 本業・個人で利用していて詳しい、という知的資産があった
  • Markdown の導入支援
  • 情報ストック化の選球眼 - 既存の情報を共有する際や、チャットの流れでストックされずにスルーされたものへの反応
  • 仕組みの導入・定着に関わる力
    • 主担当としてツールを導入
    • Slack への通知設定
    • 便利な機能を実際に使って実感してもらう - テンプレート機能など
    • 利用目的の伝達により必要性を理解して利用してもらう
    • 率先して利用して利用方法のサンプルを増やす
    • 初期メンバーへのツール利用サポート
    • ツール利用サポートができる人材の育成→サポート業務を委譲
    • 定着までの継続支援
      • ツール利用に関する QA 窓口
      • star , コメントなどによりうまく利用している人へのポジティブ・フィードバックを行う

成果

  • 業務で繰り返し利用される情報、発想のもとになる情報、議事録などが概ね esa にストックされるようになった
  • まずは検索で情報を探し、なければ人に聞くという流れになったことによるコスト削減
  • プロセスが明文化されたことによる属人化された業務の改善
  • 細切れだった議論が継続可能になった

Slack の導入

ChatWork を利用していたが、外部ツール連携の使いやすさや、そのあとの開発者増加に向けてより開発側にとって恩恵のある Slack への移行

知識・能力

  • Slack があったほうが好ましいことを判断できる能力
  • Slack の有効性を決済者に説明して納得してもらう能力
  • Slack の基礎知識
    • 本業・個人で利用していて詳しい、という知的資産があった
  • 分報 の導入
    • リモートワーク対応ということもあり、お互いの状況がわかることやコミュニケーション増の狙いも含めて導入し、定着
  • 外部協力者を シングルチャンネルゲスト として招く運用の導入支援
  • 仕組みの導入・定着に関わる力
    • channel 運用
      • ベースで必要な channel の作成と意図の周知
      • topic ごとに必要となる channel の必要性の周知
    • emoji Reaction を率先して行う
    • emoji 運用

成果

※チャット自体は ChatWork 時代で慣れていた

  • Emoji Reaction の活用が定着
  • 分報によって、今まで見えていなかった各自の考えていることの一部が可視化されるようになった
  • 分報によって、リモートでの雑談コミュニケーションによる交流が深まった
  • 外部ツール連携で業務が円滑になった

GitHub + Waffle.io の導入

ソースコードの履歴、タスク管理ともに全くない状態からのスタート。
導入当初は GitHub Project がなかったこともあり、かんばん機能として Waffle.io を利用した。
※現在は Waffle.io をやめて GitHub Project を利用している

知識・能力

  • GitHub があったほうが好ましいことを判断できる能力
  • GitHub の有効性を決済者に説明して納得してもらう能力
  • GitHub の基礎知識
    • 本業・個人で利用していて詳しい、という知的資産があった
  • Slack への通知連携設定
  • Issue 管理の定着
    • Issue 管理の必要性の周知・定着
    • Issue の記載において必要な情報の周知・定着
      • Issue テンプレートの導入による記載レベルの向上
  • label 運用
    • label の作成
    • label の利用周知
  • milestone 運用
    • milestone の作成
    • milestone の利用周知
  • Waffle.io の導入
    • 初利用だったので、機能の把握・試用を担当
    • 内容を把握した上で、組織内で利用する機能を説明するガイドの作成・周知
    • かんばんの運用を決定し、周知・導入

成果

  • GitHub の導入でプログラムの履歴を関係者全体が確認可能になった
  • GitHub の導入で開発課題が管理可能になった
  • Waffle.io によって、タスクのステータスが把握可能になった

業務プロセスの明確化・自動化

開発にまつわる業務プロセスが意識されていなかった。
特に境界や状態が意識されていないことで、個別の問題の原因やプロセス全体のボトルネックがどこにあるか把握困難になっていた。

また、もともとはすべて手動でデプロイされていて、その作業時のオペレーションミスからくる障害やプログラムのデグレードが発生していた。

知識・能力

  • 業務プロセスの明確化
  • ブランチ戦略の策定(GitHub Flow)と周知・運用定着
  • 業務プロセスの自動化( CI / CD )についてインフラ担当と連携して実現
  • 各フェーズでの必要な成果物や受け入れ条件を定義し、必要性を関係者に説明

成果

  • 業務プロセスの明確化による効果
    • プロセスに関わる問題の発見が容易になった
  • ブランチ戦略の統一によって、場当たりできではない対応が可能になった
  • 業務プロセスの自動化( CI / CD )による効果
    • 機能の追加確認にかかるコストが大幅に低下した
    • オペレーションミスが減り、本番環境へのバグ混入率が下がり、結果的にプロダクト品質が向上した
    • デプロイに対する心理的・物理的コストが下がり、新しい機能をリリースしやすくなることによりユーザーに価値を届けるサイクルが早まった

フリーランス・副業開発者の参入支援

参加時点ではリソース不足の上に、クラウドサービスでやとった開発者の開発スキルの低さや、タスクマネジメント能力の低さにより低品質の成果物の発生や、現在の状況が分からなくなるなどの問題が発生していた。

知識・能力

  • プロジェクトに参画する上での魅力・現状・問題点などを適切に説明する能力
    • 自走して開発できる、1人でもリーダークラスの業務が担当できるフリーランスを3名、副業開発者を1名に協力依頼をし、参入いただいた
    • 案件の魅力や、現状不十分な点について包み隠さず説明して、その上で相手に参画の動機があれば参画していただくような説明方法
  • 信頼と誠実さ
    • 自分で書くと微妙ですが、案件について説明し、参入していただいた理由の一つであると思っています
  • オンボーディング能力
    • プロジェクトの現状を参入時に伝えた
    • 開発に必要なツール類に関する案内、設定業務を行った
  • メンタル面でのケア
    • デモチベーションが発生するイベントの際には個別にケアした

成果

  • 初期のプロダクト品質が低く、新たな価値を追加する余力がなく、バグを潰すだけになっていた状態を追加メンバーの力で脱却し、プロダクトに価値を追加できる状態になった
  • Webサービスを開始したばかりのベンチャーとしては破格と言えるほどの優秀なメンバーを開発陣として揃えることができた
    • 結果としてマネジメントコストがかなり低い状態での開発が可能となった
    • 協力してくださった皆様に感謝です。すでに離脱している方もいますが、一緒にお仕事ができたことで私にとっても、ものすごく良い経験になりました

人との出会いや、声がけ自体はタイミングの妙もあるため、再現性が低いものの今回の貢献の中では最大のものだと思います。
ただでさえ、開発者不足で優秀な開発者の確保が難しいなかで即戦力どころかリーダークラスのみを4名も集めることは容易ではありません。
ただ、人との出会いの面でいうと、この頃よりも格段に友人・知人が増えたので今のほうが顔つなぎできる可能性は高いかもしれません。

抽象化

ここまでのような要素を抽象化して考えます。
現場で起こる様々な問題があり、それ対して問題解決をしてきたという形になります。

知識・能力

  • 問題発見能力
    • 現状と理想の差異から、何が問題になっているか把握する能力
  • 情報収集能力
    • 現状分析、問題分析、解決策の立案などに必要となる情報を収集する能力
      • 人からの情報収集
      • 過去の資料からの情報収集
      • Webからの情報収集
      • 書籍からの情報収集
  • 問題定義能力
    • 集めた情報から現在対応が必要な重要な問題はどのようなものかを明確にすること
  • 解決策の立案能力
    • 問題を解決するために必要な施策を立案すること
  • 解決策の選定能力
    • 複数の解決案から有効と思われるものから順に選定する能力
  • 結果検証能力
    • 実行した施策の成否を確認する能力
  • 交渉能力
    • 取り扱う問題構造を説明し、解決のために必要な施策の説明をし、必要な意思決定や協力を得る能力
  • 遂行力
    • 発見した問題をスルーせずに解決する意思決定をし、関係者を巻き込んで解決まで導く能力 ※すべてを解決できるわけではないですが
  • システム思考力
    • 個別の症状から全体の問題構造を推測し、真因にたどり着く能力

成果

  • その場で重要度が高いが、解決されないままになっている問題を解決しつづけた

まとめ

公式な役職としてのマネジメントの経験はないものの、こうやって分解してみると要素としては様々な事を経験していることが把握できます。
また、「よくある課題を与えられて解決する」のではなく、「その場で何が問題か発見し、明確にし、分析し、真因を導き、インパクトの大きいものから解決する」ということが私の強みであることを再認識することができました。

特に私と同様、異職種への転職をする方は個人の経験のどの部分が転職移行の職種につながる能力を含んでいるか、説明できるようになっているとよさそうですね。
説明の際は STAR 法などを意識できるとよさそうです。

www.hrreview.jp