Gaji-Laboはフロントエンド開発パートナーとしてクライアントに技術的価値を提供するのがお仕事ですが、それ以外にもできる価値提供を考えています。その一つとして、プロジェクトにジョインしたばかりの時は積極的に「何も知らない人」として振る舞うようにしています。

なぜやるのか

知識のバイアスがない状態の方が、暗黙知をあぶり出せる

• 既存メンバーがすでに当然の知識として持っているものが暗黙知になっていく
• それらを形式知にしていくことで、共有が簡単になる
• 暗黙知として誰も表に出してこなかったものが場に出ることで、形式知の連結化が期待でき、新たなる知見が生まれうる

アサインの振り替えを行いやすい

• 長期にわたるプロジェクトにずっと居続ける状況をなるべく作らないようにしている
• マンネリ防止もあるが、同じ技術スタックに居続けることによるメンバーのスキルが極端に偏る原因になる
• ○○さんの知見がないと回せないという状態はロックインに繋がり、関わっているメンバーが次のキャリアを考えにくい
• 受託の楽しさの一つである「多くのビジネスと技術に携わる」が消えてしまう（あえて受託で関わっている意味が薄れてしまうことにつながる）

工数追加発注を受けやすい状態をつくる

• 追加工数の発注をいただいたときに、アサインするメンバーを増やしたり、リソースに余裕があるメンバーに振り替えやすい
• 会社の売上にもつながる
• 顧客のプロダクト成長スピードを上げることに繋がる

クライアント企業に新しくジョインするメンバーのオンボーディング体験があがり、スピーディに開発に参加できる

• Gaji-Labo離脱後も、円滑にプロジェクトが進みやすくなる

Gaji-Laboがクライアントにとってかけがえの存在になっていることはありがたいことですが、あえていうとGaji-Laboが離脱した後もプロジェクトが円滑に回り続ける感覚がつくことが理想だと考えます。逆に、Gaji-Laboでなければ回らないという気持ちにさせてしまうことはなるべく避けたいとも考えます。そのため、なるべく得た知見はブラックボックスに閉じ込めず、関わる人が見える場に出していくことを大事にしています。

どうやっているのか

大雑把にいうと、炙り出した暗黙知の形式知化としてドキュメンテーション及び仕組みづくりの提案を行います。

プロジェクト参加の序盤は、開発フローのキャッチアップも兼ねて軽微なタスクから入ることが多くなりがちです。コードベース、事業ベースのインプットが薄い中、即応が求められるような顧客体験に影響するバグやセキュリティインシデントなどの対応は簡単にはできないこと、また既存プロジェクトへの途中参加ではスプリントの中途半端なタイミングになったりし、ちょうどよく割り振れてやり切れるタスクがなかったりすることによります。

タスク自体は大したことはなくても、開発フローはプロジェクトによって違いがあります。まずはそのフローを体験する中で、初見では分かりづらいことをドキュメントに残します。例えば以下のようなものが当てはまります。

• ブランチの使われ方……ネーミングや構成など
• レビューの行われ方……メンションをどうつけるか、誰につけるか、WIPの利用方針など
• テストの行われ方……特定のツールを使うのか。スクリーンショットを取るのか。CIはどのように動いているか。
• 完了の決め方……何をもってイシューを完了したとみなすか。誰が完了の判断を行うのか

この様に、序盤はやれることが少ない状態だからこそ、コード改修以外のところで今後のプロジェクトが円滑に回り続ける仕組みをどう作るか、を考えながら動いています。

最近気になっていること

ドキュメンテーションにおいて、ストックされる知見の多くはREADME.mdの充実で事足りたりしますが、最近はより機能的に活用できる方向性を考える機会を模索しています。

Github Discussionsの活用

• SlackでのQ&Aはフロー情報としてその瞬間が過ぎると流れていきやすく、検索をかけても都合よく問題と解決法がセットにならないため、Github Discussionsなどを利用して検索性を高め、ストックドキュメントに近づける。

ISSUE_TEMPLATEの活用

• Slack、Google Workspace、Githubなどは最低限即時準備されることが多い
• 意外と「検証ユーザーアカウントを作ってなかった」「なんとか権限を付与し忘れていた」「基本的なサービスには招待し終えていたが、CIツールに招待し忘れてた」などは後から発覚し、いざ開発を始めたときにあれがないこれがないと慌ててしまうことがある
• それらを一発で入社時タスクをチェックリスト化できるISSUE_TEMPLATE.mdを作る
• 何か足りてなかったことが発覚した瞬間に都度更新する

Notionについて

以上はGithubを活用するものばかりですが、個人的には、受託制作で関わるならばあえてGithubに寄せきってしまう方がいいと感じます。

• Notionは明示的なレビュー機能が存在しないため、加えた変更が正しいのかが少しわかりにくい
• GithubにくわえてNotionもSeatを準備してもらうとなると、軽微とはいえクライアントに出費を要求してしまう形になる
• すでに運用されている場合、形式上外部パートナーに全てを公開するわけにもいかず、中途半端に権限をもらう形になることがある

以上の様なことがよくおこることから、Notionは簡易的にパブリックシェアできるドキュメントツールとしては優秀であるものの、受託制作で開発で関わるのならばGithubに寄せていくのがよさそうだと考えています。

終わりに

このように、Gaji-Laboは受託制作ならではの面白さを損なわず、Gaji-Laboを成長させる手段としても、顧客への価値貢献という意味でも、知見をどう残すかを試行錯誤しながらプロジェクトに携わっています。

あるプロジェクトで得た知見を別のプロジェクトで活かし、またそのプロジェクトで別の知見を得て、次のプロジェクトをよりよいものにする、そんなサイクルを積み重ねながら、ただ技術力の高いエンジニアではなく、事業成長に貢献できるソフトスキルを備えたメンバーの集まる組織にしたいと考えています。

この考え方に共感してもらえる方と出会えるととても嬉しく思います。