学生主体企業による実証実験PMとしての経験と試行錯誤
BATNAによる社内外調整
認識合わせのプロセス
フロー情報とストック情報
1on1による期待値調整
エンジニアとデザイナーの共通認識
サーバント的立ち振る舞い
iQ Lab の存在意義
この記事ではこんな事について、自分の経験や試行錯誤した道のりを書いています。プロジェクトの進め方が体系化されていない頃から、さまざまな変化を経て今現在まで辿り着いています。
このような活動内容を約1年半続けてきた知識の棚卸しのために、そして、iQ Labという組織が何をしていて、何のために存在しているか（個人的意見）の表明のためにこの記事を書きます。
☝️ 役職引き継ぎのためにやってきた事を書き出していたら、これ記事にできるんじゃない？というノリで書いているので、ドキュメントっぽい内容が少し多めかもしれません。
この内容を見て面白い！自分もバリバリ働いてみたい！と思ったそこの九大生のあなた。（執筆中の）現在、絶賛採用活動中ですので、ご応募お待ちしております！詳細は最後に。
筆者について
松尾周汰（マツオシュウタ）。執筆現在九州大学大学院システム情報科学府の修士2年生です。実証実験プロジェクトのプロジェクトマネージャー兼エンジニアとしてiQ Labに携わっています。
実証実験って何？
昨年度の「三密回避実験」に引き続き、今年度も九州大学とNTTドコモによる「新規サービス開発実証」の共同研究が行われています。
今年度は「FureFure」という九大生がお互いのちょっとした頑張りを応援しあうSNSアプリを用いた、ソーシャルコミュニケーションの実証実験が進行中です。
iQ Labってどんな組織？
この記事を書く上で欠かせないのが、我々の組織形態です。
📝 超ざっくり概要
iQ Labとは民間企業の一組織です。
事業内容として、この実証実験における運営全般・システム開発・事業部へのプロデュースの他、コンサルティングやメディアなどの領域があります。
iQ Lab最大の特徴として、メンバーがほぼ全員現役の九大生で構成されている点があります。学生ということはもちろん授業があるため、普段は学業と両立させながら仕事をすることになります。そのため平日にコアタイムを設定することはせず、会議や共同作業が必要な時以外は、基本的にフルフレックスで各々のタイミングで仕事を進めることが主です。また、メンバーによっては、クライアントとの会議にも参加し協議をしたり、意思決定の一役を担うこともあります。
この（自分が知る限り）特殊な働き方で、実証実験プロジェクトを滞りなく進行させるためには、さまざまな工夫が必要となりました。
昨年度の三密回避実験におけるエンジニアチームの裏話の記事も書いているので是非に（懐かしい。。）
現在は↑の時よりも規模が拡大し、やることは何倍にも増えています。その中でプロジェクトの進行のために自分が行ってきた、対外・対内での経験や試行錯誤について振り返っていきます。
🚀 🚀 🚀
プロジェクトの流れ
どのような進行かのイメージを掴んでもらいやすいように、以下に簡単なフローを作成してみました。
🟥 赤枠に示してあるのは、九大・ドコモ・iQ Labの三者が揃う「研究者MTG」と呼ばれ、全体進行に関する協議や意思決定をする場です。
以下のように実験が進みます。
① 研究者や事業部から、実証したい事が提案される
② 要求を整理し、仕様に落とし込む
③ 三者の認識を一致させる
④ 開発や運営業務へ取り掛かる
⑤ 進行と共に進捗報告しながら、完成次第機能をリリース
と、あっさり書きましたが、たったこれだけの事のように見えて、実はかなりの努力が必要となりました。もちろん自分一人の力ではなく、メンバー全員の協力があって初めて成し遂げられるものです。
対外に向けてのこと
主に研究者MTGでクライアントとの協議やプロジェクト進行の意思決定に関わる領域の話です。自分にとっては、ここが一番の力の見せ所。
BATNAを探し続けるマシーンになる
クライアントにとって実証実験は「実験内容の論文化」と「事業化へ向けた検証」が目的です。そのため、研究者MTGの場で提案される内容は、「ユーザーがどんな行動をとってくれるのかを検証するために、こんな機能が欲しい」という事が共通項目としてある一方で、「研究視点」と「事業視点」が混在しています。
これらの要素を分解していくときに、大きな壁にぶつかります。それは、研究としてデータを取りたいシナリオと、事業としてユーザーが使ってくれるシナリオが一致しないというものです。
研究の観点からすると、「インセンティブを与えて実験に参加してもらい、欲しいデータを取得する」方法が一般的です。しかし、この実証実験の場合は、参加に対する謝礼はあるものの、逐一行動を指示したり監視することはありません。あくまでもユーザーの実験アプリへの興味関心に基づいて利用してもらい、その結果として実験データが取得されます。そのため、サービスとしてまだ成立していないものを研究したい機能にそのまま反映させるだけでは、そもそもユーザーが機能を使ってくれず、データが集まらないという事態が起こり得ます。
また、事業の観点からすると、シナリオが商用化されるときには、実証機能のどの要素が応用可能かを考える必要があります。全く同じシナリオには適用できないとしても、ほとんど商用化に向かないものでは勿体無い結果となります。
さらに、実証したい機能がそもそも開発可能かの技術検証から始まり、効果検証のための研究実施期間にリリースが間に合うかの工数とのにらめっこも必要です。
このように整理すると、実証実験では
👀 研究視点・事業視点・ ユーザー視点・開発視点 👀
の4つの視点が入り乱れている事がわかります。意味のある実証実験プロジェクトを遂行するには、この4つの意見に対する落とし所を見つけないといけません。
そこで自分が意識しているのが、BATNA(Best Alternative to Negotiated Agreement) です。
「交渉で合意が成立しない場合の最善の案」などと訳されますが、自分では「最悪の場合のプラン」や「絶対に引くことの出来ない最終防衛ライン」という解釈をしています。（視点によって若干ニュアンスが変わったり、理解しやすい形の整理なので厳密ではないです。悪しからず。）
実証実験の場合、要求側の各者のBATNAを引き出すことから始まります。最初の大きな要求を以下のような要求まで落とし込めるように、ヒアリングをして項目を削ったり、代替案の提示をしたりしていきます。
🧪 研究視点
「あれとこれとオプションが付けれたら良いが、最低でもこの観点の研究がしたい」
🏢 事業視点
「リアルなユーザーの状況を想定したいが、最悪このケースに代替できる」
また、これらの要求を整理するときには、なぜ削る判断をするかの根拠が必要です。そのため、その時点での要求に対するユーザ視点、開発視点でのBATNAを以下のように提示します。
🎨 ユーザー視点
「ユーザーが動いてくれるためには、絶対にこのコンセプトは守るべき」
💻 開発視点
「この要求仕様であれば、この機能を実装するのに、必ずこれだけの時間が必要」
要求事項のコアとなる部分が、ユーザー・開発視点それぞれの許容範囲に入るまで協議を重ね、合意点を探ります。その上で、オプション部分をどれだけ実行できるかの交渉となります。
初めはこの状態を、、、
こうなるまで持っていく！
定数を疑い、仮説の再構築を恐れない
お互いのBATNAが明らかになったら、その範囲の中に収まる形で要件の整理をします。
まずは、要求事項を開発チームのデザイナーとエンジニアに「これこれの理由で、こんな機能が必要です。」と伝える所からスタートします。この段階ではまだ、機能が必要な理由が明確でない事が多く「何を達成するためにどんな機能が必要か」の詳細化や仕様に落とし込むことができません。
そこで、デザイナーとエンジニアそれぞれで、機能が必要な理由を深掘りし、真の目的は何か？を発見します。ユーザーはどんなモチベーションでその機能を使いたくなるのか、研究ではどんな仮説を検証したいのか、その機能でどんなデータを取得したいのか、などなどの疑問点を要求側と協議して解消していく形で、機能に求められるものを突き止めていきます。また、物理的な場所や行動が必要となる場合は、実験運用が成り立つかどうかや、想定シナリオに沿った行動を取る可能性がどれほどあるか、なども論点に含まれます。
この疑問の解消と機能目的の明確化や、運営面での懸念を洗い出していくと、要求側のコア部分（＝定数でありこれ以上動かせないとされた部分）を変更しないと整合性が取れなかったり、実験がどうしても成り立たなくなる場面に遭遇することもあります。その場合は、整理された根拠をもとに、要求側に仮説やシナリオを変えることを提案し、意味のある実験が実施できるような軌道修正が必要となります。
もちろんクライアントの要求であれば、契約上は遂行する義務があるので、何でもかんでも断って良いわけではないです。ただし、言われた事を鵜呑みにしてそのままこなすだけでは、iQ Lab が請け負っている意味がありません。有意義な実証実験にするためにも、勇気を持って元の仮説を再構築し提案することも重要な仕事の一つだと思っています。
擦り切れるまで認識を合わせまくる
要求の整理ができたら、次はそれを仕様に落とし込み、ワイヤーフレームで可視化して、認識の一致を目指します。自分としては、このステップが一番難しく、時間がかかると感じています。
要件の仕様ができ、共有されたとしても、いざ可視化されると想定とは異なるという事態がよく発生します。この理由としては、その機能の「システム的」な動きの言語化の他に、「ユーザー体験」の定義ができていない事が挙げられます。同じ機能を見ていても、どのような動機で使って欲しいかによって想定仕様が異なる場合があるからです。
このような事態を避けるため、機能検討のワイヤーフレームを共有するときは、機能視点ではなく、ユーザー視点でフローを作り共有することを意識しています。また、機能の本筋の話の他に、パラメーターの設定や運用ルールで協議した内容も、合意が取れていたはずが、認識がずれていることが後から発覚する場面もあります。
以上のような認識のずれを起こさないためや、万が一起こってしまった場合の対処として以下の心がけをしています。
意思決定のプロセスを言語化し、
どの案をどういう理由で採用したかを全員の前で認証を得る
しつこいくらいに、どんな理由で何が決まったかを言語化し、全員の合意を得て記録することで、一歩ずつ意思決定の足並みを揃えられます。認識のずれが起こった場合でも、過去の記録を遡ることで憶測でない確認ができます。
以上が自分が対外との交渉や会議で気を付けているポイントになります。
💭 色々と偉そうに書いていますが、まだまだ十分でなかったり、完璧には実行できていない部分も多々あるので、実践と経験あるのみだと思っています 💪
対内に向けてのこと
対外の協議と並行して、各内部チームとの意思疎通も重要な役割となります。ここでは、チーム内のコミュニケーションで意識していることを何点か挙げていきます。
フロー情報ストック情報の使い分け
冒頭でも書きましたが、メンバーは皆学生で、コアタイムが存在しません。定例会議や共同作業が必要な場合以外は、基本的に別々の時間に仕事を進めています。iQ Lab でのコミュニケーションは主に Slack を用いて、タスク管理や各種記録は Google Docs や Notion を活用しています。
非同期コミュニケーションの良いところは、チャットの会話がメインなので、テキストで記録が残ることです。また、相手の状態に関係なく、自分の都合の良いタイミングで会話を始める事ができます。
しかし、この非同期的なテキストコミュニケーションにも限界はあります。プロジェクトが進行するにつれ、やることが増えていくと以下のような状態になることがありました。
😓 議論の結果がどうなったか忘れた
↓
🔍 Slack の会話を遡ってみる
↓
😫 探すのに時間かけた上に見つからない！結論がない！
🤔 タスクが振られたが、どんな理由があって何をしたらいいかわからない
↓
💬 チャットで質問する
↓
😑 仕事のタイミングが合わずになかなか返信がこない
↓
😱 着手に遅れが生じる or 認識がずれたまま進めてしまう
この状態を回避するために、チームのやり取りではフロー情報とストック情報を意識して使い分けるようにしています。それぞれは以下のようなものを指します。
フロー情報：流れ去ってしまう情報（Slack 上の情報）
ストック情報：蓄積される情報（Google Document, Slide, Notionなど）
これらの使い分けをもとに、以下のような運用を徹底しています。
口頭ベースの会議や Slack 上の会話など種類に関わらず、議論したものは必ず、論点と結果、その理由をセットにして Notion に記録する
タスクを振るときは、テンプレートを用いてタスク背景とタスク内容、参考資料や期限などを Notion ページに記載して、Slack 上で概要と共にそのページリンクを共有する
また、画像データのやり取りも Slack 上で済まされがちですが、「あれ、あの画像どこにあったっけ？」と何度も探す手間を避けるために、共有後は Google Drive に格納するようにしています。
しつこいくらいに周知を繰り返したので、現在はほとんど定着しており、上記のような困った状態になることはかなり減っています。究極の形としては、 Slack での「この話どうなりましたっけ？」のような質問には、これを見て！とドキュメントのリンクを貼るだけで解決する仕組みができれば良いなと思っています。
責任領域によるメンバーとの期待値調整
働く時間やコミュニケーションの取り方以外にも、一般企業とは少し違う点がほかにもあります。
一つ目が、「大学の時期」が稼働量にかなり影響するという点です。
上記のスケジュールの中で、メンバーによっては授業が忙しい時期、休暇中の部活が忙しい時期など、仕事以外の時間との調整が大事になってきます。iQ Lab には基本的に「学業優先の原則」があるため、会議などの仕事と講義など大学関連の予定が被った場合は、大学の予定を優先する権利を持っています。しかし、「この仕事が終わらないと先に進めない」という状況で、学業が忙しくなかなか進捗を生む事ができないとなると、仕事を振る側のコントロールがしづらく、仕事を任される側のプレッシャーも大きくなります。このような状況は誰も得をせずお互いの関係がギスギスしていくだけです。
二つ目として、採用時の応募動機やその後の仕事との関わり方にも考慮すべき点があります。
「なんかよくわからんけど、面白いことやってそうから応募してみよ！」
応募する時の動機は正直このようなものだと思います。笑（実際に自分もそうでした）
決して応募者の理解が浅いことを揶揄しているのではなく、iQ Lab の活動が全然外に伝えられていないのが原因だと思っています。事業会社のように看板となるプロダクトがあるわけでもなく、守秘義務範囲外の部分で企業として成果を公表する場を作ることもなかなか難しく、試行錯誤している状況です。
また、採用時はほとんどの人が特定のスキルを持っていない事が多いです。と、言うよりそもそもスキルを期待して採用することは少なく、多くの場合は iQ Lab らしい働き方への相性や、簡単なワークサンプルを行なってコミュニケーションを取ることで採用するかどうかを決めています。働きながらスキルを身につけることが前提となるので、最低でも2年以上の長期で関わってもらえる人が対象となっている理由でもあります。
このような採用をしているため、どのポジションで働きたいか、どのようなキャリア形成をしていきたいかなどはほとんど空の状態で始まります。そのため、一緒に仕事をしていく中で、その人がどのようなモチベーションがあり、何を目標として、どんな仕事をしたいのか？を擦り合わせることが重要だと思っています。
以上のような考慮すべき点があり、一人一人の状況に合わせながら仕事を進めていくことになります。
しかし、なかなか同じ空間・同じ時間に顔を合わせて仕事をすることが少なく、気軽に悩みや相談ができる場がないなと感じる事がありました。特に、どのメンバーにどれくらいの稼働を期待して良いか、今任せている仕事の責任範囲は適切だと感じているか、組織に対する不満や個人の悩みはないか、などがほとんどわからずに、一人でモヤモヤしている時期もありました。
これらを解決するために、1on1 を導入しました。現在は学期の区切りとだいたい一致するように四半期ごとに、前四半期の振り返りと次の四半期への目標をざっくばらんに話す機会を設けています。
実施方法は以下の通りです。
「事前記入シート」に書き込みを行う
記入シートをもとに「アウトプットシート」を埋める形で対話を進める
組織体制上、隔週など頻繁に 1on1 を実施する事らわ難しいので、話す内容はある程度明確に決めています。形式を決めることで、上辺だけの会話でなんとなく雑談するだけの時間になってしまうことを避けています。（メンターはチームリーダーに任せているのである程度やり方に差はあると思いますが）
事前記入シートの内容は以下の通りです。（大公開！）
仕事に関する成果や大学生活、プライベートなどのポジティブなニュースを教えてください
iQ Lab への現在のモチベーションは100点満点中何点ですか？
業務内容で不安、心配、うまくいっていないことがあれば教えてください
他のメンバーと仕事をする上で不安、心配、うまくいっていないことがあれば教えてください
iQ Lab 全体で改善すべきと思っていること、不満やモヤモヤがあるところ、もっと挑戦すべきだと思っていることがあれば教えてください
もちろん仕事の話だけを堅苦しく話す場にはあまりしたくないので、まずはなんでもいいのでポジティブニュースを話してもらいます。今はまっていることや、研究の話が話題に上がることで、普段知らないような興味関心の一面を見る事ができて楽しいです。アイスブレイク的に緊張もほぐせます。（ここで盛り上がることが多く後半時間に追われることも。笑）
次は仕事に対するモチベーションを聞きます。多くの場合はここで、学業が忙しくてあんまり時間を割けない、あんまりこの仕事はしたくない、新しく始めた仕事が楽しい、もっとこんな仕事をしてみたい、など期待値調整のヒントになる内容を話してくれます。
残りは業務内容や対人関係、全体に対する不満や意見を話してもらいます。その場の思いつきで話すのではなく、事前記入時の考える時間を確保できているので、かなり濃い内容を話してもらえます。毎回みんなのモヤモヤを受け止めるにはなかなかの勇気が必要ですが、健全なチーム、組織を作っていくためには必要不可欠だと思っています。
続いて、事前記入シートの内容をもとに、以下のアウトプット項目を埋めていきます。
達成できた目標
成長した点・出せた成果
達成できなかった目標
目標達成ができなかった理由・足りなかった行動など
今四半期の期待値調整
今四半期の目標設定
達成できたこと、できなかったことを理由とともに整理し、次の四半期の目標を立てます。特に「期待値調整」の項目を大事にしており、以下の図のどの責任領域で働きたいかの意思確認をします。上段に行けば行くほど、重要な責任が問われますが、使えるリソースや自由裁量が増えるという関係です。
💭 今はユニット（2, 3人のかたまり）で仕事をする事が多いけど、今期はガッツリ稼働できるのでもっとチーム全体への貢献がしたい！
💭 就活とか諸々忙しくてプロジェクト進行に張り付きでついていくのが難しいので、個人に割り振られる仕事をこなすくらいが良い。
このような意見のすり合わせを行うことで、どれくらいの責任や稼働を期待して良いかの確認ができます。また、図の下の方は「タスクベース」でやってほしいことが明確な仕事を振るようにし、上にいくにつれ「イシューベース」の課題の分解と特定から始まる仕事を任せるようにしています。お互いの限られた時間を有効に活用するために、仕事内容も人によって変える工夫をしています。
アウトプットシートの記録は同意が取れる範囲で、みんなが見れる形で公開しているので、他のチームの人がどんなことを考えてるのかを覗きにいける機会でもあります。
💭 風通し抜群の、みんなが心地よく働ける組織にしたい！
エンジニアとデザイナーの共通認識
プロジェクトマネージャーの視点から少し変わり、エンジニアとデザイナー間のコミュニケーションという絞ったスコープの話になります。
これまで書いてきたマネージャーの仕事に付随して、自分はエンジニアとしての開発メンバーの1人でもあります。アプリ開発を進めていく上で、 UI 実装はデザイナーのデザインをもとにしています。昨年度は主に一人のデザイナーと以下のような流れで開発を進めていました。
👨💻 < こんな機能を表す UI をいい感じに作ってくれ！
👨🎨 < おけっす！XD できました！
👨💻 < あざます！こんな感じで作ってリリース完了しました〜
👨🎨 < なんかここイメージと違うんで、こっちに修正おなしゃす！
…
今思えばかなりざっくりしていました。加えてほとんど一方向のコミュニケーションで、双方向の対話はほとんどなかった気がします。今年度になり、UI の刷新や新機能開発、メンバーの増加などに伴い、今までのコミュニケーションでは限界がきました。そこで、一度エンジニアとデザイナーのコミュニケーションのやり方を見直しました。
複数人での共同作業をしやすくするため、トンマナや実装ルールなどを含めたデザイントークンの共通化や管理をするため、 Figma によるデザインシステムを導入しました。さらに、UI の作成、実装状況を相互にレビューしフィードバックする「Figma FB会」という定例会を週に一度30分〜1時間程度で開催しています。
デザインシステムの内容はまだまだ未熟ですが、さまざまな企業のデザインシステムを参考にしながら構築を進めています。あまり最初からガチガチなルールは作らずに、流れに乗ってルール化できるところを探していこうという方針です（ということで一旦ここは逃げます。）
Figma FB会は当初の役割からどんどんと進化しています。当初は、デザイナーが作成した UI をエンジニアが正しく実装できているかの確認が目的でしたが、現在は「新しい機能をどう見せるのか、そもそもどんな機能にするのか」をエンジニアとデザイナー共同で考えています。これにより、決定事項を持ち寄って追加議論を探す場から、議論事項を持ち寄って議論する場となりました。複雑な要件をどう対処していくか？を異なる視点から一緒に考える事ができています。また、デザイナーのこだわりポイントをしっかり汲み取り、実装が難しいところは妥協点を議論するなど、お互いの考えを同じ場で言語化して共通認識を取ることの大事さにも気づきました。
以下、一緒に開発しているデザイナーがこの会について残してくれた、とっても嬉しかったコメント。
エンジニアの肌感がその場で分かるのも嬉しいし、普段デザイン班がどんなこと考えながら議論してるのかを知ってもらえるのも嬉しい
前から「エンジニアの頭の中覗きたい」「デザイン/エンジニアで共通認識持ちたい」って言ってて、情報共有の仕方を考えたり、エンジニア留学を考えてみたりしたけど、一緒に話すだけでこんなにも簡単にそれが解決されるのかあ
エンジニア組織の話も、前回の記事から相当なアップデートがあり、現在の運用の知見も溜まってきましたが、それは他の誰かが書いてくれる事でしょう（期待！）
「結局は人」のサーバント的立ち振る舞い
少し話は変わりますが、自分がなぜ現在マネージャーをやっているかをふと振り返ると、正直よく覚えていません。笑 エンジニアとして採用されたので、初めは右も左も分からないまま初のモバイルアプリ開発、初のチーム開発に取り組んでいました。チーム開発をしていく中で、さまざまな課題点が見つかり、紆余曲折色んなことを試しながら iQ Lab らしいエンジニアチームがうまく回っていく方法を探していたの1年半ほど前です。そこから、会議で進捗報告をするようになり、運営業務担当として新たに設立されたオペレーションチームとの連携をとったり、今年度の実験のあれやこれやの調整役を買って出ていたらいつの間にかこの仕事をしていました。
この仕事をやるモチベーションとして大きいのが、「人の役に立ちたい」という気持ちだと思います。困っている課題があれば原因を探って解決のために仕組みを作る。情報がカオスになって混乱してきたら情報を整理して秩序を持たせる。コミュニケーションが取りづらそうであれば間に入って架け橋になる。他の人が十分に力を発揮できるように場を整え、障壁を取り除いてきたことが転じてマネージャーとしての動きになったと思えます。
しかし、ただの指示出し人間になりたいわけではありません。まずは自分が手を動かしたり調べてみて、仕組み化を検討してみる。ある程度形ができてきたら、その領域で手を動かすことから離れて、他のメンバーに信頼して任せる。このように、自分で実態を掴んで仕事のイメージができて初めて他の人に任せるようにしています。自分が手を離した領域でも、助けが必要そうであれば中まで入り、手を動かすこともあります。
最終的には、「この人から頼まれたんならやってあげるか」と思われるような存在になりたいと思っています。プロジェクトには想定外の依頼や、緊急対応すべきことがゲリラ豪雨のように降ってきます。予定外のタスクを振るときでも、「しょうがないな」と一緒に地獄を乗り切ってくれる信頼関係を築いていくことを目標に、組織づくりをおこなっているつもりです。
しかし、最近は業務量や複雑な要件が増えてきた結果、自分で抱え込みすぎて、適切な権限委譲ができていないことを課題に感じています。「自分でやった方が早い病」とも呼ばれる通り、メンバーに負担をかけないように自分で対処しようとすることが、かえってプロジェクト全体に対して、遅延や属人化など良くない影響を与えかねません。定期的に自分の仕事の棚卸しをして、「やること」と「やらないこと」をはっきりさせた後、仕事の押し付けにはならないように、なぜこの仕事を任せたいのかをはっきり伝え、メンバーの裁量に全て任せるようになる事が次の目標です。
以上、自分が実証実験チームのコミュニケーションにおいて、意識していることや改善をおこなってきたことになります。色々試してきたことが少しづつ定着して効果が出ているものもあり、些細なものでもポジティブなコメントがあれば、やってよかったと報われる気持ちになります。また、コミュニケーション量が増えてくると、どうしても一方的な共有になりがちです。相手の意見を聞いて、双方の対話で結論を出すことを忘れない意識をずっと持ち続けていたいです。
⚡️ ⚡️ ⚡️
実証実験を通して考えた iQ Lab とは
ここまでは自分のやってきた仕事内容の具体的なものにフォーカスした話をしてきましたが、最後は少しメタな視点で iQ Lab がこのプロジェクトをやる意味について自分の考えていることをまとめたいと思います。
とにかく考えてトライアンドエラーを繰り返す
iQ Lab のメンバーはほとんどが学生です。良くも悪くも、手取り足取り仕事の進め方を教えてくれる上司はいません。だからと言って、手を抜いた仕事は許されず、クライアントも「学生だから」と甘く見ることもありません。一般企業の質とスピードについて行くには、とにかく調べて手を動かして、挑戦する、失敗からどんどん学ぶことが必須です。「誰かが教えてくれるだろう」のマインドではなく「自分から学びに行く」事が好きな人にとっては、新しい方法を好きなように試す事ができる最高の環境です。ある意味ずっと背水の陣のような状況であるからこそ、クライアントの要望に対してどうすればより良い価値を提供できるかを考え抜く力がつきます。その結果、「学生だからこんなもんでしょ」という理由で社会から甘い目で見られることもなく、逆に「学生だからまだ仕事ができなくてもよい」という消極的になる理由も打ち消されると思っています。
iQ Lab で働くこと自体がキャリア形成の実証実験
実は、自分自身 iQ Lab で働く前、わずか2年ほど前までは、明確にやりたいことも仕事への興味関心もほとんどなく、惰性で過ごしている日々が大半でした。（本当にお酒を飲んだくれている日々でした笑）しかし、あることをきっかけに iQ Lab で働き始め、エンジニアとしてモノづくりをすることが楽しい！異なるバックグラウンドを持つ様々な職種の人とのコラボレーションのために働く事が楽しい！と思えるようになりました。おそらく2年前の自分とは180° 別人になっていると思います。
長期的には、自分のようなモデルをもっと増やしたいと思っています。「周りがやってるから自分もなんとなく」ではなく、主体性を持ってリアルな社会の場を経験することによって、自分の頭で、自分のキャリアを考えて行動するようになりました。
もちろん大学は教育・研究機関であるため、学業や研究に身を置いて成果を出すことも重要です。この点において、iQ Lab は単なるビジネスの場だけではなく、大学を拠点にしている事が強みです。quickQ のような自分達の手で大学をより良くしたいという気持ちがダイレクトに大学に還元されたり、「学びながら仕事にする」ことで、学業と仕事の両立もしやすい環境にあります。こう考えると、iQ Lab で働くこと自体が、自分の人生におけるキャリア選択の実証実験をしている期間であるとも思えてきます。「自分が興味のある領域は実は今の学部とは違った」「色々やったけどやっぱりビジネスではなくもっと研究に打ち込みたい」「今の研究テーマをもっと深掘りしたらスキルとして活かせそう」など、いろんな答えがあっていいと思います。iQ Lab という組織を踏み台にして社会に出て行くのか、残って組織に貢献するのか、いろんな選択肢・可能性を増やすことのできる存在であると、個人的には感じています。
📣 📣 📣
最後に…
iQ Lab で一緒に働きませんか？
このプロジェクトや iQ Lab の活動を通して、「学生」と「社会人」という年齢や身分だけで能力を判断する/される境界線を壊していきたいと思っています。根拠を持って考える力さえあれば、たとえ実績がなくても、特殊なスキルがなくても大学や民間企業とも対等に渡り合えます。(共同代表の野口の言葉でもあります)
※ 現在、実証実験関連メンバーの採用は行っておりませんが、iQ Labに興味があるという方は是非こちらの公式LINEからお問合せください🙌🏻
この記事が気に入ったらサポートをしてみませんか？