見出し画像

#19|1カ月かかるはずだった仕事が、一晩で会社の資産になった。

【この記事で学べること】
散らばった経験をAIで整理し、再利用できる経営資産へ変える方法

【1分でわかる、この記事のポイント】
・独立後、自分の仕事の価値や適正価格を見極めるため、過去案件の棚卸しを続けてきた。しかし、資料を探して整理するだけで疲れ、肝心の振り返りまでたどり着けないことも多かった。

・PCやGoogle Driveに散らばっていた資料を集約し、対象フォルダをAIのDeep Researchで調査。保存資料から確認できる過去案件を、昨晩から翌朝までの数時間で網羅的に振り返る土台ができた。その結果、既存の活動履歴31件に106件の候補が加わり、一度は137件に増加。その後、企業別、工程別、施策別に重複していた57件を統合・整理し、最終的に80件へ集約した。

・完成した活動履歴は、単なる実績一覧ではない。自社が「誰に、どのフェーズで、どのような価値を提供できるのか」をAIを使うことで短期間に明らかにし、会社のポジショニングまで見直す経営資産になったというお話。



Builder | Issue #19
第1章 | Builderとは何者か


「これ、本気でやったら1カ月かかるな」

ある夜、私はこれまで自分が関わってきた仕事を、あらためて整理し始めました。

目的は、単に実績一覧をつくることではありません。

どのような依頼から仕事が始まり、何を課題だと考え、最初に何をしたのか。途中で見立てが変わった出来事は何だったのか。どのような追加課題が生まれ、何を変え、最終的にどこまで進んだのか。

過去の案件を、結果だけではなく、判断の過程まで含めて振り返りたいと考えたのです。

そして一番知りたかったのは、次のことでした。

「私の仕事の価値は何なのか。価格はいくらが適正なのだろうか」

独立して仕事をしていると、自分の価格を客観的に決めるのは簡単ではありません。

契約上の依頼をこなすだけで終わった案件もあれば、途中から役割が広がり、当初の想定を超えて事業づくりそのものを担った案件もあります。

自分は、どのような場面で特に価値を出してきたのか。どこから追加対応が増えたのか。その成果と報酬は見合っていたのか。

それを明らかにするには、過去の仕事を同じ基準で並べ、比較できる状態にする必要がありました。

ところが、少し手をつけただけで気が遠くなります。

資料はPCのローカルやGoogle Driveのさまざまなフォルダに分散しています。同じプロジェクトでも、提案先、協力会社、施策、作成した資料によって、別々の仕事として記録されていることも少なくありません。

資料を探す。中身を読む。記憶をたどる。同じ案件を見つけてまとめる。さらに、当時の判断や結果を文章にする。

「これ、本気でやったら1カ月かかるな」

正直、そう思いました。

もちろん「1カ月」は、ストップウォッチで測った比較ではありません。これまで同じ規模の資料整理をしてきた経験から、人力なら1カ月近くを見込む作業量だと考えたのです。

仮に誰かへ資料整理を依頼しても、案件への思いや当時の重要性、難易度までは分かりません。目的を達成するには、結局、自分で一つずつ振り返るしかない。半ば諦めかけていました。

ところが、AIと一緒に整理を始めると、翌朝には全体を一定の基準で振り返るための土台ができていたのです。


31件だった活動履歴が、一度は137件になった

もともとの活動履歴には、31件の仕事が記録されていました。

まず、PCに残っていた資料もGoogle Driveへ集約し、受注・失注を問わず、過去の提案書、議事録、分析資料などが保存された対象フォルダをAIのDeep Researchで調査します。

なお、業務資料をAIで扱う際は、利用する環境や契約条件、機密情報の取り扱いを確認し、対象資料を適切に限定することが前提です。

調査の結果、新たに106件の候補が抽出され、活動履歴は31件から137件へ。情報量は一気に4倍以上になりました。

その中には、失注した提案や、資料を見るまですっかり忘れていた案件もあり、137件の一覧を眺めると、「確かに、こんなにやってきたのか」と感慨に浸りたくなります。

しかし、それでは棚卸しの目的を果たせません。

一覧を見ると、同じプロジェクトが、関係する企業ごとに別の案件として記録されていました。さらに、戦略、UI・UX、販促、データ分析など、工程ごとにも分かれています。EC改善、業務改善、顧客リスト活用、販路開拓が、それぞれ独立した仕事として抽出されているケースもありました。

仕事の数が多いのではなく、一つの仕事が複数の角度から記録されていたのです。

そこで、案件名、企業名、期間、資料の内容、関係者、実施した施策などをAIに照合してもらい、重複や包含関係を洗い出しました。AIが統合候補と理由を示し、最終的にどうまとめるかは私自身が判断しています。

その結果、57件を統合または削除し、137件あった活動履歴は80件へ集約。新たに抽出された106件の候補も、独立した振り返り対象としては51件になりました。

案件IDの重複をなくし、何をどこへ統合したのか、その理由までログとして忘れず保存。

数字が減ったことで、むしろ自分が何をしてきたのかを、第三者にも的確に説明できる形で捉えられるようになったことは一人では無理だったかも?とあらためて思いましたね。


会社名ではなく、「一つの事業の動き」として捉え直す

例えば、ゴルフ場で行った広告配信事業・リテールメディアのPoCの案件がありました。

活動履歴には、弊社のクライアント、広告主、ゴルフ場、協力会社と、関係者ごとに別の仕事として記録されています。

しかし、実際には一つのプロジェクトです。

誰との会話から始まり、どの企業を巻き込み、途中で何が変わったのか。広告主へどう営業し、PoCで何を確かめ、次の展開へどうつなげたのか。

別々の記録を一つにまとめると、単発の作業ではなく、一つの事業が動いていく過程として見えるようになります。

また、アプリのMAU拡大に関する仕事も同様でした。

戦略、UI・UX、販促、ロイヤリティ施策など、資料だけを見れば別々の仕事です。けれども、全体をつなぐと「アプリを成長させるための継続的な取り組み」として捉え直せます。

その他、ECサイト改善の案件も、EC改善、業務改善、顧客リスト活用、販路開拓を個別に数えるより、「通販事業を成長させる継続伴走」と整理した方が、実際に担った役割へ近づきます。

案件をまとめ直すことで、見えてきたものがあります。

それは、納品した資料の数ではありません。

何を課題だと捉え、誰を巻き込み、どこで見立てを変え、何を実現したのか。

仕事の本当の単位は、作業や資料ではなく、そこで「起こした変化」であり、「提供した価値」だったのです。


AIからの9つの質問。あえて空白のまま残した9問目

整理した51案件については、代表的な資料や主要な改版をAIに確認してもらい、共通の問いに沿って内容をまとめました。

問いは、次の九つです。

  1. その案件は、どのように始まったのか

  2. 当初、何が問題だと考えていたのか

  3. 自分には、どのような役割が求められたのか

  4. 最初に何を行い、なぜそう判断したのか

  5. 途中で見立てが変わった出来事は何か

  6. どのような追加課題が生まれたのか

  7. 途中で何を変えたのか

  8. 最終的に、どのような結果になったのか

  9. 今なら、どのようにやり直すか

資料に残っている範囲で、AIはQ1からQ8までを整理できました。

一方、Q9だけは違います。

「今なら、どのようにやり直すか」

この問いに対して、AIはもっともらしい答えをつくることもできたでしょう。しかし、それでは私自身の振り返りにはなりません。

当時は何が見えていなかったのか。なぜ、その判断をしたのか。今の経験を持って戻れるなら、どこを変えるのか。

それは、資料に書かれている事実だけでは答えられない問いです。

そこで、Q9は全案件とも「要本人追記」として残しました。AIができなかったから、空欄になったのではありません。AIに推測させるべきではない部分として、意図的に人間へ返した空欄です。

もし、この話に興味をもっていただいた方で、自分もやってみようとご自身の仕事を棚卸しするなら、最初からすべての案件を整理する必要はありません。

まずは、代表的な3案件の提案書や議事録をAIに読み込ませ、この9つの問いで整理してみる。Q1からQ8までをAIと一緒にまとめ、Q9だけは自分で考える。

それだけでも、自分が価値を出しやすい仕事と、次に改善すべき点が見え始めるはずです。


経験は、保存されているだけでは資産にならない

過去の提案書、議事録、分析資料、メールがGoogle Driveに保存されていても、それだけでは次の仕事に十分活かせません。

必要なときに見つけられない。似た案件と比較できない。どの判断が成果につながったのかも分からない。

保存されていることと、「使える」ことは別です。

一橋大学名誉教授の野中郁次郎氏は、組織の知識は、経験や勘に根ざした暗黙知と、言葉や文書で表せる形式知との継続的な対話によって生まれると論じています。これは、組織的知識創造論として知られる考え方です。(Nonaka, 1994)

今回の経験をこの考え方に重ねると、AIが扱ったのは、資料として残された形式知でした。

それを案件ごとに集め、比較できる形へ組み直し、足りない部分を明らかにする。そのうえで、Q9に残った自分の経験や反省を、あらためて言葉にしていく。

資料を整理しただけでは、過去の経験はまだ完成しません。AIが形式知をつなぎ、人間が暗黙知を言語化することで、初めて次に使える知識へ変わるのだと思います。


活動履歴が、「次の経営判断に使えるデータ」へ変わった

完成した活動履歴は、単なる実績一覧ではありません。

ここには、次の経営判断に使える情報が詰まっています。

  • どのような案件で価値を出しやすいのか

  • どこから追加対応が増えたのか

  • 当初の契約範囲と、実際に担った仕事は合っていたのか

  • 成果に対して、報酬は妥当だったのか

  • 似た案件を受けるなら、次はどのような条件を契約に入れるべきか

現時点では、過去の契約を一件ずつ再評価したわけではありません。しかし、それを考えるための共通の土台はできました。

適正価格そのものの答えが、すぐに出たわけでもありません。

ただ、誰に、どのフェーズで、どのような価値を提供できるのかが見えたことで、価格を考えるための土台ができました。

さらに、活動履歴は別の用途にも展開できます。

  • noteや書籍で紹介する事例

  • 営業資料や実績紹介

  • 自分や会社の強みの言語化

  • 研修で使う教材

  • 類似案件へ応用できる仕事の型

  • 契約範囲や価格の見直し

  • 組織に残す学習データ

ここでいう「会社の資産」は、会計上の資産という意味ではありません。

過去の経験を、次の判断、提案、契約、教育へ再利用できる経営資源に変えた、ということです。


AIが短くしたのは、「考える時間」ではなかった

今回、AIを使ったことで、人力なら1カ月近くを見込んだ作業が、昨晩から翌朝までの数時間で大きく進みました。

ただ、本当に重要なのは、作業時間が短くなったことだけではありません。

AIが私の代わりに、過去の仕事を評価したわけではない。どの案件に価値があり、何を反省し、次にどうするべきかを決めたわけでもありません。

AIが行ったのは、考える前に必要だった膨大な準備です。

資料を探し、読み、並べ、重複を見つけ、共通の形式にそろえる。人が考え始められる状態になるまでの「思考の前処理」を、ほぼ終わらせてくれました。

言い換えるなら、こうなります。

AIで短くなったのは、考える時間ではない。
「考え始められる状態」になるまでの時間だった。

振り返りは大切だと分かっていても、目の前の仕事に追われ、後回しになりがちではないでしょうか。

しかし、準備にかかる時間が数週間から数時間へ縮まれば、振り返り、評価、再設計を、経営の日常へ組み込めるようになります。

空いた時間で、さらに多くの作業をこなすだけではない。これまで時間がなくてできなかった判断へ、人間の時間を使う。

そこに、AIによるスピードの本当の価値があると感じています。


Builderは、一つの仕事を一度で終わらせない

この活動履歴は、最初から大きな経営資産をつくろうとして始めたものではありませんでした。

過去の仕事を振り返り、自分の価値を測りたい。加えて、このBuilder連載で使える事例を整理したい。それが出発点です。

ところが、整理してみると、記事の材料だけでなく、営業、研修、契約評価、提案改善、組織学習にも使えることが分かってきました。

そして、最も大きかったのは、自分たちが「どのフェーズで、どのような企業や課題に対して、特に価値を提供できるのか」が明確になったことです。

この振り返りを受けて、弊社は自らを、

大手企業の新規事業立ち上げに特化し、特にPoCの実施までを素早く形にすることを得意とするチーム

と、あらためて定義しました。

過去の資料を整理しただけで終わったのではありません。

そこから、自分たちの強みを言語化し、狙う仕事を明確にし、会社のポジショニングまで見直すことができたのです。

私は今回の振り返りを通じて、一つの仕事を、一度で終わらせないことの価値をあらためて実感しました。

一つの仕事を、その場の成果物だけで終わらせない。そこから次の事業機会を見つけ、再現できる型を抽出し、発信できる知識へ変え、契約や経営の改善にもつなげる。

この#19の記事自体も、活動履歴から生まれた価値の一つです。

今回つくったのは、80件の実績一覧ではありません。

散らばっていた経験を、次の仕事に使える会社の資産へ変えたのです。

振り返ってみると、ここにはBuilderの「形にする力」と、それを圧倒的に加速する「AIレバレッジ」が表れていました。

では、Builderの提供価値とは、結局何なのでしょうか。

見立てること。つなぐこと。形にすること。そして、そのすべてをAIで速くすること。

今回の経験を通じて、私はそれをもう一段深く考えるようになりました。

次回は、ここまでの事例に共通していたBuilderの仕事を振り返り、その提供価値を一つの式にしてみたいと思います。

このテーマをもっと読む

AIを使った働き方をもっと読む → #21|大企業の意思決定を、毎週止めずに回す方法

Builderという働き方を知る → #20|Builderって、結局何ができる人なのか?

いいなと思ったら応援しよう!