開いていただきありがとうございます。 履歴書として記載しております。
- 会社員としてはEnterprise GitHubにcommitしており、 副業ではプライベートリポジトリにcommitしているため、草は生えてないですが、エンジニアリングに関する最低限の素養はございます。
- 名前はRyosuke Takahashiになってますが、村上僚のリポジトリです。
- 掲載されているのは、基本的に学生時代のコードで、今は、当時よりまともなコードを書けます。
- 海城中学/高校卒業
- 筑波大学/大学院で経営工学系を卒業/修了
- 修論では、市役所の電話窓口対応を効率化するためのチャットボットの開発/市役所への試験導入/効果検証をしました。
- 業務受託開発を中心に数件。
- Webサイト、Webアプリの要件定義、設計、開発、テスト、保守
- 合計２００万程度の売上。
- 協同創立者のエンジニアが開発に集中できるようにに、各種環境整備や、事務作業や経理もした。
- 現在もほそぼそとではあるが、継続している。
- TypeScript, React.js, Next.js, Node.js
- Firebase
- Firestore
- Function
- Storage
- Auth
- Analytics
- １年毎に機能リニューアルがあるため、１年前のコードを読める/変更しやすいよう、保守性意識した開発をすることの重要性
- 技術のキャッチアップの際には、既存技術との差異を意識しながらキャッチアップすると良いこと
- e.g. ReactはjQueryのどんなペインをどのようなパラダイムを導入することで解決しているのか、など
- 要件定義から保守から請求書の作成までをすべてをやっていたため、それぞれの業務の専門家（営業や、CSの方など）へのリスペクトが増した
- 顧客の本当のニーズを聞き取り、そのニーズを満たすために必要なMVPをすり合わせながら開発することの重要性
- 顧客との期待値のズレは、大変な手戻りを発生させ、信用を失うことにつながること
- ヘルスケア系アプリのkencomの開発・保守
- 社内オペレーションを改善するためのツール開発
- 新機能のバックエンドの設計と開発
- 日常的な運用作業
- 新卒1年目社員のメンターとして、技術支援/内省支援を2年目に行った。
- Ruby, Rails
- チーム開発の基本
- 作りたい機能やプロダクトのイメージをすり合わせながら、手戻り少なく、バグ少なく開発するためのの流れやコミュニケーションについて
- コードレビューの考え方参考にしたもの
- 基礎的な保守性を意識した開発
- 基本的な開発するうえでのマインド
- SOLID, DRY, KISS, YAGNI など
- 基本的なデータベースの設計
- 基本的な開発するうえでのマインド
- パフォーマンスを一定意識した開発
- インデックスのはりどころ
- ORMが裏で叩いているSQLを意識すること, N+1が発生しないようにする、、、など
- I/Oがなるべく発生しないような書き方を意識するなど
- 技術的負債を発見し、優先順位をつけながら返済していく能力
- 中途半端なスクラムや不完全なバックログリファインメントは、スムーズな開発を阻害すること
- なお、中途半端になってしまったのは、事業構造によるものが大きい
- 今思えば、明確なプロダクトオーナーが不在で、あまたいるステークホルダーの顔色を少しずつ伺ってしまったことによる影響が大きそうと考えている
- 採用のための母集団形成、イベント運営
- 選考設計、選考運用、面接官管理
- 内定者のクロージング
- 各種調整、業務効率化、ドキュメント作成
- 採用業務をスクラムで実行する際の、スクラムマスター的な役割
- 採用は[興味, 応募, 選考, 内定, 承諾]の各ステップがあり、それぞれのステップでの候補者体験を泥臭く改善することが、採用数に効いてくること
- 理想的には、採用は入社後の[オンボーディング, 活躍, ロイヤリティ発揮]をふまえて設計すると良いこと
- コーチング的な対話をすることで人の意思決定の基準を整理し、相手が納得感のある意思決定をすることを支援する方法
- 泥臭く人と向き合い、仲間を増やすためのメンタリティ
- スクラムの導入と浸透には、Whyを根気強く伝えるのが重要なこと。守破離の順番を間違えないこと。
- なんらかの生産性を向上させるプロダクトの開発に関わりたい
- 開発に関わるメンバーの開発効率向上に関わりたい
- エンジニアリングのバックグラウンドを持ちながら、採用、育成、チームビルド、ビジネスなどのことも意欲的に取り組めること
- ビジネス＆エンジニア間のコミュニケーションを翻訳しつつ、ファシリテートする素養があること
- 傾聴/コーチング能力
- 必要に応じて相手のトラウマや奥深い心理までも共感的に傾聴することが、一定可能です。
- 傾聴して得られた情報をもとに、コーチングをし、相手と共に解を見つけようとするスタンスもあるとおもいます。
- スクラムマスター, エンジニアマネージャー, PdM, エンジニア等
- 強み、弱み、進もうとしている方向性などを記載しております。
- https://github.com/RyosukeTakahashi/ProfileOfRyoMurakami/blob/master/how_to_manage_murakami.md
- note
- 一番ヒットした記事は、リモートワーク用のデスク環境の記事
- だが、コーチングや傾聴系の記事のほうが多くはある
- 『コーチャブルかを見極める方法』という記事は、刺さる人には刺さるようで、これきっかけで複数人の方とお会いした