├── .nvmrc ├── .npmrc ├── mdx-components.tsx ├── .gitignore ├── app ├── page.md ├── numbers │ └── page.md ├── _meta.js ├── layout.tsx ├── business-overview │ └── page.md ├── ui-ux-designer-recruit │ └── page.md ├── benefits │ └── page.md ├── employee-interview │ └── page.md ├── praha-overview │ └── page.md ├── web-engineer-recruit │ └── page.md ├── hr-evaluation │ └── page.md └── pracracy-manual │ └── page.md ├── .textlintrc ├── README.md ├── renovate.json ├── next-sitemap.config.mjs ├── next.config.mjs ├── next-env.d.ts ├── tsconfig.json ├── eslint.config.mjs ├── .github ├── actions │ └── setup │ │ └── action.yml └── workflows │ └── pr-push-check.yml └── package.json /.nvmrc: -------------------------------------------------------------------------------- 1 | 24.12.0 2 | -------------------------------------------------------------------------------- /.npmrc: -------------------------------------------------------------------------------- 1 | save-exact=true 2 | -------------------------------------------------------------------------------- /mdx-components.tsx: -------------------------------------------------------------------------------- 1 | export { useMDXComponents } from 'nextra-theme-docs'; 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .next 2 | node_modules 3 | out 4 | tsconfig.tsbuildinfo 5 | _pagefind/ 6 | -------------------------------------------------------------------------------- /app/page.md: -------------------------------------------------------------------------------- 1 | # このサイトは何？ 2 | 株式会社PrAhaのことをまとめているサイトです。 3 | 4 | PrAhaで働きたい方が役立つ情報を書いています。 5 | -------------------------------------------------------------------------------- /.textlintrc: -------------------------------------------------------------------------------- 1 | { 2 | "rules": { 3 | "preset-smarthr": { 4 | "sentence-length": false 5 | } 6 | } 7 | } 8 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # このレポジトリis何? 2 | 株式会社PrAhaという会社について知ってもらいたくて書いた内容や社内制度をまとめています。 3 | 4 | 以下のリンクからご覧いただけます。 5 | 6 | - https://entrance.praha-inc.com/ 7 | -------------------------------------------------------------------------------- /renovate.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://docs.renovatebot.com/renovate-schema.json", 3 | "extends": [ 4 | "github>agaroot-technologies/renovate-config" 5 | ] 6 | } 7 | -------------------------------------------------------------------------------- /next-sitemap.config.mjs: -------------------------------------------------------------------------------- 1 | /** @type {import('next-sitemap').IConfig} */ 2 | export default { 3 | siteUrl: 'https://entrance.praha-inc.com/', 4 | generateRobotsTxt: true, 5 | generateIndexSitemap: false, 6 | outDir: './out', 7 | }; 8 | -------------------------------------------------------------------------------- /next.config.mjs: -------------------------------------------------------------------------------- 1 | import nextra from 'nextra'; 2 | 3 | const withNextra = nextra({}); 4 | 5 | /** @type {import('next').NextConfig} */ 6 | const nextConfig = { 7 | output: 'export', 8 | images: { 9 | unoptimized: true, 10 | }, 11 | }; 12 | 13 | export default withNextra(nextConfig); 14 | -------------------------------------------------------------------------------- /app/numbers/page.md: -------------------------------------------------------------------------------- 1 | # 数字で見るPrAha 2 | 株式会社PrAhaに関する数字を公開しているページです（2025年10月現在）。 3 | 4 | - 平均年収: 847.33万円 5 | - 中央年収: 860.00万円 6 | - 平均年齢: 30.2歳 7 | - 中央年齢: 30.5歳 8 | - 年間休日数: 120日+4日(夏季休暇)+4日(年末年始休暇)+10~20日(年次有給休暇) 9 | - 社員数: 14人 10 | - エンジニア: 12人（男性11人、女性1人） 11 | - デザイナー: 2人（男性0人、女性2人） 12 | 13 | ※年収は正社員のみを対象としています -------------------------------------------------------------------------------- /next-env.d.ts: -------------------------------------------------------------------------------- 1 | /// 2 | /// 3 | /// 4 | 5 | // NOTE: This file should not be edited 6 | // see https://nextjs.org/docs/app/building-your-application/configuring/typescript for more information. 7 | -------------------------------------------------------------------------------- /tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | "$schema": "https://json.schemastore.org/tsconfig", 3 | "extends": [ 4 | "@tsconfig/strictest/tsconfig.json", 5 | "@tsconfig/next/tsconfig.json" 6 | ], 7 | "compilerOptions": { 8 | "strictNullChecks": true, 9 | "plugins": [ 10 | { 11 | "name": "next" 12 | } 13 | ] 14 | }, 15 | "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"] 16 | } 17 | -------------------------------------------------------------------------------- /eslint.config.mjs: -------------------------------------------------------------------------------- 1 | import { common } from '@agaroot/eslint-config-common'; 2 | import { define } from '@agaroot/eslint-config-definer'; 3 | import { javascript } from '@agaroot/eslint-config-javascript'; 4 | import { next } from '@agaroot/eslint-config-next'; 5 | import { react } from '@agaroot/eslint-config-react'; 6 | import { style } from '@agaroot/eslint-config-style'; 7 | import { typescript } from '@agaroot/eslint-config-typescript'; 8 | 9 | const config = define([ 10 | common, 11 | javascript, 12 | typescript, 13 | style, 14 | react, 15 | next, 16 | ]); 17 | 18 | export default config({ 19 | tsconfigPath: './tsconfig.json', 20 | }); 21 | -------------------------------------------------------------------------------- /app/_meta.js: -------------------------------------------------------------------------------- 1 | export default { 2 | '*': { 3 | theme: { 4 | breadcrumb: false, 5 | }, 6 | }, 7 | 'casual-interview-form': { 8 | type: 'page', 9 | title: 'カジュアル面談に応募する', 10 | href: 'https://docs.google.com/forms/d/1whmNgig8TKm8qTvAAYm5xjYE-3twTW8IIIen1ZMlyZE/viewform', 11 | }, 12 | 'introduction-section': { 13 | type: 'separator', 14 | title: 'はじめに', 15 | }, 16 | 'index': 'このサイトは何？', 17 | 'praha-overview-section': { 18 | type: 'separator', 19 | title: '会社紹介', 20 | }, 21 | 'praha-overview': 'PrAhaってどんな会社？', 22 | 'business-overview': '事業内容', 23 | 'benefits': '福利厚生', 24 | 'hr-evaluation': '人事評価', 25 | 'pracracy-manual': 'プラクラシー', 26 | 'employee-interview': '社員インタビュー', 27 | 'numbers': '数字で見るPrAha', 28 | 'recruitment-section': { 29 | type: 'separator', 30 | title: '採用情報', 31 | }, 32 | 'web-engineer-recruit': 'Webエンジニア', 33 | 'ui-ux-designer-recruit': 'UI/UXデザイナー', 34 | }; 35 | -------------------------------------------------------------------------------- /.github/actions/setup/action.yml: -------------------------------------------------------------------------------- 1 | name: Setup 2 | description: Setup workspace 3 | 4 | runs: 5 | using: composite 6 | steps: 7 | - name: Setup Node.js 8 | uses: actions/setup-node@395ad3262231945c25e8478fd5baf05154b1d79f # v6.1.0 9 | with: 10 | node-version-file: .nvmrc 11 | 12 | - name: Setup pnpm 13 | uses: pnpm/action-setup@41ff72655975bd51cab0327fa583b6e92b6d3061 # v4.2.0 14 | 15 | - name: Expose pnpm store path 16 | id: pnpm_store_path 17 | shell: bash 18 | run: | 19 | echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT 20 | 21 | - uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4.3.0 22 | name: Setup pnpm cache 23 | with: 24 | path: ${{ steps.pnpm_store_path.outputs.STORE_PATH }} 25 | key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }} 26 | restore-keys: | 27 | ${{ runner.os }}-pnpm-store- 28 | 29 | - name: Install dependencies 30 | shell: bash 31 | run: pnpm install --frozen-lockfile --prefer-offline 32 | -------------------------------------------------------------------------------- /.github/workflows/pr-push-check.yml: -------------------------------------------------------------------------------- 1 | name: PR Push check 2 | 3 | on: 4 | pull_request: 5 | types: [opened, reopened, synchronize] 6 | 7 | concurrency: 8 | group: ${{ github.workflow }}-${{ github.ref }} 9 | cancel-in-progress: true 10 | 11 | jobs: 12 | build: 13 | name: Build 14 | runs-on: ubuntu-latest 15 | timeout-minutes: 10 16 | steps: 17 | - name: Checkout 18 | uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 19 | 20 | - name: Setup 21 | uses: ./.github/actions/setup 22 | 23 | - name: Build 24 | run: pnpm run build 25 | 26 | lint-text: 27 | name: Lint Text 28 | runs-on: ubuntu-latest 29 | timeout-minutes: 10 30 | steps: 31 | - name: Checkout 32 | uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 33 | 34 | - name: Setup 35 | uses: ./.github/actions/setup 36 | 37 | - name: Lint 38 | run: pnpm run lint:text 39 | 40 | lint-code: 41 | name: Lint Code 42 | runs-on: ubuntu-latest 43 | timeout-minutes: 10 44 | steps: 45 | - name: Checkout 46 | uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 47 | 48 | - name: Setup 49 | uses: ./.github/actions/setup 50 | 51 | - name: Lint 52 | run: pnpm run lint:code 53 | 54 | lint-type: 55 | name: Lint Type 56 | runs-on: ubuntu-latest 57 | timeout-minutes: 10 58 | steps: 59 | - name: Checkout 60 | uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 61 | 62 | - name: Setup 63 | uses: ./.github/actions/setup 64 | 65 | - name: Lint 66 | run: pnpm run lint:type 67 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "praha-inc-about-us", 3 | "version": "1.0.0", 4 | "private": true, 5 | "description": "About PrAha, Inc.", 6 | "homepage": "https://github.com/shuding/nextra-docs-template#readme", 7 | "bugs": { 8 | "url": "https://github.com/shuding/nextra-docs-template/issues" 9 | }, 10 | "repository": { 11 | "type": "git", 12 | "url": "git+https://github.com/praha-inc/about-us.git" 13 | }, 14 | "license": "UNLICENSED", 15 | "scripts": { 16 | "dev": "next dev", 17 | "build": "next build", 18 | "postbuild": "next-sitemap --config next-sitemap.config.mjs && pagefind --site .next/server/app --output-path out/_pagefind", 19 | "start": "next start", 20 | "lint:code": "eslint .", 21 | "lint:text": "textlint *.md **/*.md", 22 | "lint:type": "tsc --noEmit --pretty" 23 | }, 24 | "dependencies": { 25 | "@next/third-parties": "15.5.9", 26 | "next": "15.5.9", 27 | "next-sitemap": "4.2.3", 28 | "nextra": "4.6.1", 29 | "nextra-theme-docs": "4.6.1", 30 | "react": "19.2.3", 31 | "react-dom": "19.2.3", 32 | "remark-emoji": "5.0.2", 33 | "textlint": "15.5.0", 34 | "textlint-rule-preset-smarthr": "1.36.1" 35 | }, 36 | "devDependencies": { 37 | "@agaroot/eslint-config-common": "3.0.6", 38 | "@agaroot/eslint-config-definer": "1.0.5", 39 | "@agaroot/eslint-config-javascript": "2.0.7", 40 | "@agaroot/eslint-config-next": "3.0.9", 41 | "@agaroot/eslint-config-react": "3.0.9", 42 | "@agaroot/eslint-config-style": "2.0.9", 43 | "@agaroot/eslint-config-typescript": "2.0.8", 44 | "@tsconfig/next": "2.0.5", 45 | "@tsconfig/strictest": "2.0.8", 46 | "@types/node": "24.10.4", 47 | "@types/react": "19.2.7", 48 | "eslint": "8.57.1", 49 | "pagefind": "1.4.0", 50 | "typescript": "5.9.3" 51 | }, 52 | "packageManager": "pnpm@10.26.1" 53 | } 54 | -------------------------------------------------------------------------------- /app/layout.tsx: -------------------------------------------------------------------------------- 1 | import { GoogleTagManager } from '@next/third-parties/google'; 2 | import { Head } from 'nextra/components'; 3 | import { getPageMap } from 'nextra/page-map'; 4 | import { Footer, Layout, Navbar } from 'nextra-theme-docs'; 5 | 6 | import type { Metadata } from 'next'; 7 | import type { FC, PropsWithChildren } from 'react'; 8 | 9 | import 'nextra-theme-docs/style.css'; 10 | 11 | const companyImage = 'https://storage.googleapis.com/production-os-assets/assets/3e2414da-29eb-4a09-a665-b35ce4ecb451'; 12 | 13 | export const metadata: Metadata = { 14 | title: { 15 | template: '%s | PrAha Entrance Book', 16 | default: 'PrAha Entrance Book', 17 | }, 18 | description: '株式会社PrAhaのEntrance Bookです。', 19 | twitter: { 20 | card: 'summary_large_image', 21 | images: companyImage, 22 | }, 23 | icons: companyImage, 24 | openGraph: { 25 | type: 'website', 26 | images: companyImage, 27 | }, 28 | }; 29 | 30 | const RootLayout: FC = async ({ children }) => { 31 | return ( 32 | 36 | 37 | 38 | 39 | 40 | PrAha Entrance Book} projectLink="https://github.com/praha-inc/entrance-book" /> 43 | )} 44 | pageMap={await getPageMap()} 45 | docsRepositoryBase="https://github.com/praha-inc/about-us/tree/main" 46 | editLink="GitHubでこのページの修正を提案する" 47 | sidebar={{ defaultMenuCollapseLevel: 1 }} 48 | feedback={{ content: null }} 49 | footer={( 50 |
51 | ©{new Date().getFullYear()} PrAha Inc. All Rights Reserved 52 |
53 | )} 54 | > 55 | {children} 56 | 57 | 58 | 59 | ); 60 | }; 61 | 62 | export default RootLayout; 63 | -------------------------------------------------------------------------------- /app/business-overview/page.md: -------------------------------------------------------------------------------- 1 | # 事業内容 2 | 3 | 以下の3つの事業を行なっています。 4 | 5 | 1. アガルートグループのシステム開発 6 | 2. PrAha Challengeの運営 7 | 3. 受託開発 8 | 9 | ## 1. アガルートグループのシステム開発 10 | PrAhaは2022年6月にM&Aを経て、アガルートグループに参画しました。 11 | 12 | それに伴い、アガルートグループのさまざまなシステムを開発しています。 13 | 14 | アガルートと密に連携をとりつつ、作る機能の優先順位などを決めており、システム部のような距離感で開発を進めています。 15 | 16 | ### 既存サービスの改修 17 | アガルートグループの主力サービスである[アガルートアカデミー](https://www.agaroot.jp/)（登録者数9.2万人・2022年11月時点）と、それに関連するシステムの改修を進めています。 18 | 19 | かなりレガシーなシステムになってしまっているので、新しいシステムへの刷新も必要となっています。 20 | 21 | その他に、以下なども進めています。 22 | 23 | - 新機能の開発 24 | - UX（ユーザー体験）の向上 25 | - セキュリティ強化 26 | - 業務効率化 27 | 28 | ### 新規サービスの開発 29 | [最新の技術スタック](/web-engineer-recruit#%E6%8A%80%E8%A1%93%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF)を活用して、より良い学習環境を実現する新規サービスの開発も行なっています。 30 | 31 | 以下は、PrAhaが新規開発したサービスの一例です。 32 | - [TENSAKUN](https://www.agaroot.jp/about_lecture/online_tensaku/) 33 | - [KIKERUKUN](https://www.agaroot.jp/about_lecture/online_shitsumon/) 34 | - [TOKERUKUN](https://www.agaroot.jp/about_lecture/online_enshu/) 35 | 36 | ## 2. PrAha Challengeの運営 37 | 中級エンジニアを育成するオンラインブートキャンプ「[PrAha Challenge](https://praha-challenge.com/)」の運営をしています。 38 | 39 | 業務としては、以下を行なっています。 40 | 41 | - 技術の移り変わりに合わせて課題を見直す 42 | - 受講者からの質問に回答する（メンター） 43 | 44 | ## 3. 受託開発 45 | スタートアップの新規事業に特化して、月額定額制でデザイン＋受託開発を提供している事業です。 46 | 47 | ### PrAhaの受託開発の特徴 48 | #### 1次受けのみ 49 | 基本的に1次請けの案件しかお受けしていません。 50 | 51 | アイデアの持ち主と直接話すことで、その考えや想いを理解し、一緒に創造的な挑戦をすることで、より良いものづくりができるからです。 52 | 53 | #### 仕事はリファラルか会社HPへの問い合わせのみ 54 | すべての案件は、以下のどちらか経由でご相談をいただいています。 55 | 56 | - リファラル 57 | - 会社ホームページへの直接のお問い合わせ 58 | 59 | 弊社の開発スタイルや理念を理解してくれているクライアントとの仕事が多いので、受発注の関係性ではなく1つのチームとしてものづくりに取り組めます。 60 | 61 | 良い関係性のなかで質の高いものづくりをすることで自然と良い評判が広がり、自分たちから営業活動をしなくても事業が成り立つ仕組みを作ろうとしています。 62 | 63 | #### 利益より面白さ 64 | スタートアップは大手企業ほど資金的な余裕がなく、大手企業の開発案件や保守案件を受けた方が開発会社の利益は膨らむので、利益を追求するのであればスタートアップに特化した受託開発にはほとんど旨みがありません。 65 | 66 | ただ弊社は利益を生むためではなく、ものづくりを楽しむために存在しているので、今後も新規事業に特化して開発案件のみを受けます。 67 | 68 | 現時点では、そちらの方がものづくりとして面白いと感じるからです。 69 | 70 | #### 何より誠実さ 71 | 72 | スタートアップ界隈は非常に狭い世界なので、悪評も好評も瞬く間に広がります。 73 | 誠実に良いものを作り続けることがこの事業においては何よりも大切なことだと信じています。 74 | 75 | なので知識差を悪用してクライアントからぼったくったり、手を抜くことなく、誠実さを何より大事にしながらこれからも事業を運営していきます。 76 | 77 | ### なぜ月額定額なのか 78 | 長期間の見積もりはほぼ確実に外れます。そんな情報をもとにクライアントに対価を請求するのは不誠実だと考えているからです。 79 | 80 | ソフトウェア開発は非常に[柔らかく、創造的で、不確実な仕事](https://www.amazon.co.jp/dp/1732102201)ですから、不確実性が高すぎて見積もりが機能しないのです。 81 | 私(CEO)自身、大手企業で長期プロジェクトを事前に見積もる形式で何度も開発に関わったことがありますが、1度もうまくいった試しがありません。 82 | 83 | 開発途中にユーザーからフィードバックを得て仕様を変えたくなる状況も多々発生します。 84 | その度に見積もりの作り直しに何日も費やして「では200万円の追加ですね」「150万円になりませんかね？」などとネゴシエーションを繰り返す組織が1つのチームとしてものづくりに集中できるとは思えません。 85 | 86 | そのため弊社から請求する費用は月額定額としています。 87 | 88 | 今まで作ってきたサービスをすべて捨てて新しいサービスを作り直すのも、それがユーザーが本当に望むことであれば全く構いません。 89 | チームのために何が必要か、利害関係なくフラットに考えて、一緒に伴走できる状況を私たちは目指しています。 90 | -------------------------------------------------------------------------------- /app/ui-ux-designer-recruit/page.md: -------------------------------------------------------------------------------- 1 | # UI/UXデザイナーの募集要項 2 | 株式会社PrAhaのUI/UXデザイナーの求人ページです。 3 | 4 | ## 概要 5 | **給与** 6 | - 正社員の場合: 7 | - 566~961万円(固定残業代40時間/月を含みます) 8 | - 業務委託の場合: 9 | - 708~900万円 10 | 11 | **勤務地** 12 | - フルリモート・フルフレックス 13 | 14 | **雇用形態** 15 | - 正社員（業務委託も相談いただけます） 16 | 17 | **勤務形態** 18 | - 裁量労働制 (1日8時間のみなし労働) 19 | 20 | **年間休日数** 21 | - 正社員の場合: 22 | - 120日+4日(夏季休暇)+4日(年末年始休暇)+10~20日(年次有給休暇) 23 | - 業務委託の場合: 24 | - 業務に支障がない限り自由に休んでいただけます 25 | 26 | **福利厚生** 27 | - [福利厚生のページ](/benefits)に書いています 28 | 29 | **試用期間** 30 | - あり（3か月） 31 | 32 | **昇級評価** 33 | - 年3回（4月、8月、12月）行ないます 34 | - [人事評価のページ](/hr-evaluation)で「スキル通過申請シートを提出して通過したらスキルが上がる」と記載していますが、スキルが上がって給与に反映されるのが年3回という意味になります 35 | 36 | ## 仕事内容 37 | - 運用中のシステムのリニューアル、エンハンス 38 | - 新規サービスのコンセプトづくりから設計、表層のデザイン 39 | - その他ビジュアル作成業務 40 | 41 | ### 具体的な仕事内容の一例 42 | - ロゴ、ピクトグラム、アイコンなどのデザインアセットの作成 43 | - webアプリケーションやiOS/AndroidネイティブアプリのUI作成 44 | - Figmaコンポーネントライブラリやスタイルの作成・運用 45 | - グループ会社のLP作成 46 | 47 | ## PrAhaのデザイン文化 48 | - 上下関係や職種の垣根なくフラットに意見交換ができる 49 | - 要件を満たすためでなく、使ってくれる人にとって本当にいいものを提供するために話し合い、協力し合う 50 | - 主なデザインツールはFigma, コミュニケーションツールはSlack 51 | 52 | ## 求める人物像 53 | - アイデアの持ち主と直接対話しながらソフトウェアを開発していくことに喜びを感じる方 54 | - 課題を自ら発見し、提案し、解決していくのが好きな前向きな方 55 | - まだまだ開発チームの人手は足りておらず、やりたいことが山積みです 56 | - その時々に必要なことを見つけて主体的に動く人が集まってチームができています 57 | - 特に自分の得意領域に関することなら「こういうこともやっておいた方が良い」と提案する動きが歓迎されます 58 | - 状況に応じて最適な解決策をゼロベースで考えられること 59 | - 常に1つの手法に固執する方だと、[最適な別解を見落としてしまう可能性があるから](https://www.google.com/search?q=%E3%83%8F%E3%83%B3%E3%83%9E%E3%83%BC%E3%81%97%E3%81%8B%E6%8C%81%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%91%E3%82%8C%E3%81%B0%E5%85%A8%E3%81%A6%E3%81%8C%E9%87%98%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E8%A6%8B%E3%81%88%E3%82%8B&oq=%E3%83%8F%E3%83%B3%E3%83%9E%E3%83%BC%E3%81%97%E3%81%8B%E6%8C%81%E3%81%A3%E3%81%A6%E3%81%84%E3%81%AA%E3%81%91%E3%82%8C%E3%81%B0%E5%85%A8%E3%81%A6%E3%81%8C%E9%87%98%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E8%A6%8B%E3%81%88%E3%82%8B&aqs=chrome..69i57.6400j0j4&sourceid=chrome&ie=UTF-8)です 60 | - 我々のクライアントが置かれている状況は常に異なるので最適な解決策も(多少の傾向はあれど)異なるはずです 61 | - どんなベテランでも、必要に応じてアンラーニングできる柔軟な姿勢がなければ、本当の課題解決はできないと考えています 62 | - 自分の周りの人を喜ばせたり、楽しませるのが好きな方 63 | - もし何かに躓いて困ったとしても、周囲と良好な関係を構築できる方なら周りに助けてもらえるので、安定して高い成果を出し続ける可能性が高まります 64 | - 何より仕事は一日の時間の大部分を占めるので、一緒に居て楽しい人と働きたい 65 | - PrAhaでは社員同士で旅行に行なったり遊んだり仲が良いので、友達に近い関係性で働ける方だと嬉しいです 66 | 67 | ## 必須スキル 68 | - ユーザーに寄り添い理解する力 69 | - UI/UXデザインに関する実務経験（toC, toB問わず） 70 | - FigmaなどのプロトタイピングツールでUIを作成できる能力 71 | - ネイティブレベルの日本語能力（N1以上） 72 | 73 | ## 歓迎するスキル 74 | - プロジェクトリードの経験 75 | - グラフィックデザインスキル 76 | - エンジニアリングスキル 77 | - ユーザーリサーチの経験 78 | 79 | ## 選考フロー 80 | 1. ポートフォリオ選考 81 | - レジュメもしくはメッセージで、ポートフォリオのURLをご共有ください。 82 | 2. カジュアル面談 83 | - ざっくばらんに30分程度お話しましょう。 84 | - あなたのご経験や今後やりたいことをお聞かせください。 85 | 3. ポートフォリオ面接 86 | - プレゼンでご自身のスキルをアピールしてください。 87 | 4. 課題選考 88 | - デザイン課題の実施に取り組んでいただきます。 89 | - 課題の取り組みにかかる時間は1日～3日程度（8時間～24時間程度）で、実施には2週間程度の期間（応相談）を設けています。 90 | 91 | ## この仕事で得られるもの 92 | - 挑戦の機会 93 | - あなたの「やってみたい」にチャレンジしやすい環境です。 94 | - 新しくツールや技術を歓迎し、変化を柔軟に受け入れる文化があります。 95 | - 「何をすべきか」から考えることができる 96 | - 決定事項だけが降りてきてデザイン着手することはほぼありません。 97 | - プロダクトオーナーと直接コミュニケーションを取りながら、納得感を持って仕事に取り組むことができます。 98 | - 「なぜつくるのか？」「なぜこのデザインなのか？」疑問を解消しながら進めることができます。 99 | - フルリモート勤務の働き心地の良さ 100 | - 好きな場所で好きな時間に働くことができます。 101 | - 子育て中でもストレスフリーで働くことができます。 102 | 103 | ## 応募方法 104 | 以下からご応募ください！心よりお待ちしております！ 105 | 106 | [→カジュアル面談に応募する](https://docs.google.com/forms/d/1whmNgig8TKm8qTvAAYm5xjYE-3twTW8IIIen1ZMlyZE/viewform) -------------------------------------------------------------------------------- /app/benefits/page.md: -------------------------------------------------------------------------------- 1 | # 福利厚生 2 | 株式会社PrAhaの福利厚生を紹介するページです。 3 | 4 | ## 対象者 5 | 福利厚生の対象者は、「正社員」のみです。 6 | 7 | ## 福利厚生の詳細 8 | ### 本購入補助 9 | 仕事に関連する書籍を購入できる制度です。 10 | 11 | - 月額上限：1か月につき3,000円 12 | - 積立方式：利用可能額は1月から12月まで積み立てられます。12月31日にリセットされます。 13 | 14 | 新入社員の場合は、入社月から3,000円分が付与されます。 15 | 16 | 例：11月に入社した場合、入社時点で3,000円分が積み立てされます。12月になると3,000円分が追加で積み立てられるので、合計6,000円の積み立てになります。この時点で6,000円分の本を購入できます。6,000円分を使用せずに翌年の1月になると、積み立てた分はリセットされ、0円からスタートします。 17 | 18 | ### 休暇 19 | 20 | #### 夏季休暇 21 | 6月〜9月の間に取得できる休暇を、全社員に一律で4日間付与する制度です。 22 | 23 | 6月1日に付与されます。9月30日までに使用しないと無効になります。 24 | 25 | #### 年末年始休暇 26 | 年末年始に、全社員一律に4日間の休暇を付与する制度です。 27 | 28 | #### 慶弔休暇 29 | 以下の場合に、慶弔休暇を付与する制度です。 30 | 31 | - 社員本人が結婚したとき: 8日 32 | - 社員の妻が出産するとき: 3日 33 | - 社員の子が結婚するとき: 1日 34 | - 親族が死亡したとき 35 | - 社員の配偶者のとき: 7日 36 | - 実養父母、子のとき: 7日 37 | - 同居の配偶者の父母のとき: 7日 38 | - 祖父母、兄弟姉妹、別居の配偶者の父母、孫、直系卑属の配偶者のとき: 4日 39 | - 3親等以内の親族のとき: 2日 40 | 41 | ※葬儀などが海外で行なわれる場合、7日間を限度に日数を加算されます。 42 | ※原則としてその事由が発生した日から連続して取得する必要があります。 43 | 44 | #### 特別休暇 45 | 以下の場合に、会社が必要と認める期間だけ付与する制度です。 46 | 47 | - 選挙権その他公民としての権利を行使するとき 48 | - 裁判員制度により、裁判員候補者、裁判員もしくは補充裁判員として裁判所に出頭するとき 49 | - 証人、参考人など、公の職務のため、官公庁より公用出頭を命ぜられたとき 50 | - 天災その他の災害にあったとき 51 | - 交通機関の事故など、会社が欠勤することにつきやむを得ない事情によるものと認めたとき 52 | - その他、会社が特に必要と認めたとき 53 | 54 | ※裁判員制度により裁判所に出頭する場合、裁判所より命ぜられた期間だけ付与されます。 55 | 56 | ### MacBook Proの支給 57 | 希望者にMacBook Proを支給する制度です。 58 | 59 | 2025年現在、支給されるMacBook Proのスペックは以下の通りです。 60 | 61 | - モデル: MacBook Pro(2024年11月) 62 | - CPU: Apple M4 Pro 63 | - メモリ: 48GB 64 | - ディスプレイサイズ: 14インチ 65 | 66 | ※支給されるMacBook Proのスペックは、その時点で発売されている同等クラスの最新モデルとなります。（たとえばM5 Proが出たらM5 Proになります） 67 | 68 | ### CTO室 69 | 週に1日だけ、業務時間を使って技術記事を執筆したり、OSS活動ができる制度です。 70 | 71 | 技術記事は、[Zenn](https://zenn.dev/p/praha)に投稿しています。 72 | 73 | OSS活動では、以下のようなものを公開しています。 74 | - [LooksToMe](https://looks-to.me/) 75 | - プルリク上でのやり取りに使える「LGTM」の画像を作れるサービス。 76 | - [feedbackun](https://github.com/praha-inc/feedbackun) 77 | - 360度評価ツール。 78 | - Slack上で動作し、任意のスタンプを押すと、その人の良い行動を評価できるツール。 79 | - [Merge Master](https://github.com/praha-inc/merge-master) 80 | - 大量のプルリクがあるときに、すべてを順番に良い感じにマージしてくれるGitHub Actionsのカスタムアクション。 81 | - [zundamon](https://github.com/praha-inc/zundamon) 82 | - ずんだもんのような喋り方をするChatGPTのSlackBot。 83 | - 追加すると@zunndamonnにメンションできるようになる。 84 | - [GitHub Actionsでブランチ名を制限する系のカスタムアクションいろいろ](https://zenn.dev/praha/articles/11acc8f530078a) 85 | 86 | その他にもCTO室では、社内の技術的課題解決や技術的意思決定を行なっています。 87 | 88 | ### ワーケーション 89 | みんなでホテルに集まって仕事しようという制度です。 90 | 91 | - 開催スパン: 3か月に1回 92 | - 開催期間: 月~土の5日間（途中で帰宅しても良い） 93 | 94 | 作業する場所は自由です。部屋にこもって作業する人もいれば、誰かの部屋に集まって作業することもあります。 95 | 昼と夜はみんなで食事に行くことが多いです。 96 | 97 | ### 社員旅行 98 | みんなで遊びに行こうという制度です。 99 | 100 | - 開催スパン: 6か月に1回 101 | - 開催期間: 土日+金or月の2泊3日で行なわれることが多い（途中で帰宅しても良い） 102 | 103 | いい宿に泊まって、いいご飯を食べて、たくさん話します。 104 | 105 | ### 部活動費の全額負担 106 | 社員同士で、一緒に何かの活動をするときに掛かるお金を支援する制度です。 107 | 108 | - 支給条件: PrAhaの社員2人以上で何かの活動をする（リモートの会も可） 109 | - 上限: 5,500円/1回1人 110 | 111 | 以下、具体例です。 112 | 113 | - やっていいことの例（基本的には何でもOK） 114 | - ビールが好きな人を集めてビールを飲むときの飲み代 115 | - 陶芸体験のワークショップ参加費 116 | - みんなで読みたい輪読会の本代 117 | - みんなでサウナに行くときのサウナ代 118 | - 一緒にシェアオフィスでリモートワークするときのシェアオフィス代 119 | - やってはダメなこと 120 | - 業務にあまり関係のないものを買う（個人に帰属するものだと給与課税される可能性があるため） 121 | - 公序良俗に反するもの 122 | - ゴルフ 123 | 124 | ### 月末食事会 125 | 月末にみんなでおいしいものを食べに行こうという制度です。 126 | 127 | 以下は例です。 128 | 129 | - 焼き肉 130 | - 寿司 131 | - お好み焼き 132 | - ビストロ 133 | - イタリアン 134 | - 炉端焼き 135 | 136 | 焼き肉になることが多いです。 137 | 138 | ### PrAha Challenge代の全額負担 139 | 弊社の自社サービスである「[PrAha Challenge](https://praha-challenge.com/)」（10,780円/月）を無料で受けられる制度です。 140 | 141 | ### AI系プロダクトの使用料支援 142 | 200ドル/月までのAI系プロダクトの使用料を全額負担する制度です。 143 | 144 | ### 人間ドック代の全額負担 145 | 人間ドック（上限7万円）を無料で受けられる制度です。 146 | 147 | ### GitHub Copilot代の全額負担 148 | GitHub Copilot代（10ドル/月）を全額負担する制度です。 149 | 150 | ### その他 151 | - 法定福利厚生 152 | - 健康保険 153 | - 厚生年金保険 154 | - 雇用保険 155 | - 労災保険 156 | - 介護保険 157 | - 子ども・子育て拠出金 158 | - 有給休暇 159 | - 入社半年経過で10日/年、6年半経過で20日/年 160 | 161 | **※このページに書かれている金額は、すべて税込み（10％）です。** 162 | -------------------------------------------------------------------------------- /app/employee-interview/page.md: -------------------------------------------------------------------------------- 1 | # 社員インタビュー 2 | 株式会社PrAhaの社員にインタビューした音声を紹介しているページです。 3 | 4 | 会社の雰囲気を感じていただくのが目的です。 5 | 6 | ## 社員の特徴 7 | 以下のような方が多いです。 8 | 9 | - 優しいギーク 10 | - 知的好奇心が強く、納得するまで探求し、論理的に考えるのが好き。 11 | - ただ、根っこの部分は優しくて親しみやすい。 12 | - ゲーマー 13 | - ゲームが大好き。 14 | - 自立している 15 | - 自己管理ができて、周りと協調できる。 16 | 17 | ## エンジニアへのインタビュー 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | ## デザイナーへのインタビュー 42 | 43 | 44 | 45 | -------------------------------------------------------------------------------- /app/praha-overview/page.md: -------------------------------------------------------------------------------- 1 | # PrAhaってどんな会社？ 2 | 3 | フルリモートでデザインと開発を行なうものづくり集団です。 4 | 5 | ## ミッション 6 | **アイデアを形にすること**。これがPrAhaのミッションです。 7 | 8 | リクルートの同期5人とPrAhaを創業したとき、私たちの周りには「アイデアはある。資金調達も完了している。だけど作り手が居ないからモノを作れない」という会社がたくさんありました。 9 | 10 | 開発を外注しても、お金だけ消えてバグだらけのサービスしか出来上がらなかった、という悲しい話もたくさん耳にしました。 11 | 12 | 良い作り手と巡り会えなかったことで今この瞬間も素晴らしいアイデアが潰えているかもしれない。そんな状況を解決して、良いアイデアを1つ残らず形にするためにPrAhaは日々ものづくりに取り組んでいます。 13 | 14 | PrAhaはまだまだ小さな会社で、私たちの手が届く範囲で良いアイデアをどれだけ形にしても、それだけでは到底追いつきません。「ものづくりって楽しいよね！」と言えるような環境を作り、ものづくりの担い手を増やしていくことも私たちの存在理由です。 15 | 16 | こんな取り組みに共感してくれる方がいたら、ぜひこの先も読み進めていただけると幸いです。 17 | 18 | ## PrAhaらしさとは何か? 19 | PrAhaらしさを一言で表現すると「優しいギーク」だと思います。 20 | 21 | ### ラーニングアニマル(常に学び続けること) 22 | ギークとして何より欠かせないのは新しいことを学ぼう・試そうとする、旺盛な知的好奇心です。 23 | 24 | Webの世界は変化が激しく、新しいツールやパラダイムは生産性を飛躍的に高めたり、従来の手法が生み出していた問題や不便さを一掃してくれることもあります。こうした業界では絶えず学習を続ける人とそうでない人の差はどんどん広がっていくため、質の高いものづくりを継続するためには、学び続ける心が何よりも大切だと考えています。 25 | 26 | ラーニングアニマルであることはハードスキルの面ではもちろんソフトスキルの面でも重要です。 27 | 28 | 自分のやり方を捨てられず周囲から孤立してしまう人よりも、周囲の意見を柔軟に取り入れて新しいことを学ぼうとしている人の方が、周囲と良質な人間関係を築けます。 29 | 30 | ソフトウェアという目に見えない巨大な制作物を大人数で協働して作っていくには密な会話が欠かせません。 31 | 32 | 一度書いたコードはソフトウェアに残り続けるので、何度も議論を重ねて認識を丁寧に擦りあわせていかなければいけません。 33 | 34 | 時には意見が対立することもありますが、そんな時ほど以下のように学ぶ姿勢を持っている人同士でないと良好なチームは継続できません。 35 | 36 | - 相手はなぜ自分とは異なる手法を選択しているのか？ 37 | - どのような前提情報の違いから生じているのか？ 38 | - 相手と自分の考えをうまくマージして、より良い解決策が作れないか？ 39 | 40 | ですので、PrAhaのメンバーに対しては、ラーニングアニマルであることを何よりも大事にしています。 41 | 42 | また、PrAhaでは**知的好奇心が強い人にとって1番の報酬は、同じぐらい知的好奇心が強い人と切磋琢磨できること**、と定義しています。 43 | 44 | そのため社内では常に複数の輪読会や勉強会が同時並行しており、業務時間外に勉強することが当たり前の社風が出来上がっています。 45 | 46 | 以下は、過去に輪読した書籍の一例です。 47 | - 実践ドメイン駆動設計 48 | - SQLアンチパターン 49 | - Akka実践バイブル 50 | - Engineers in Voyage 51 | - レガシーコードからの脱却 52 | - セキュア・バイ・デザイン 53 | - A Philosophy of Software Design 54 | 55 | 業務外の勉強を会社が強制することはありませんが、「好きだから学んでいる」状態のメンバーが多く在籍しており、ラーニングアニマルにとっては楽しい環境です。 56 | 57 | ### 論理的に思考して伝える力 58 | たくさんの人と意見を擦り合わせながらものを作るためには論理的思考を行ない、考えたことを伝える力が欠かせません。 59 | 60 | 例えばフレームワークや言語を選定する際に「最近の流行りだから」と安易に選ぶのではなく、以下のように最適な解決策を論理的に思考する必要があると考えています。 61 | 62 | 1. その技術が解決したい課題を理解する 63 | 2. [その課題が自分たちのサービスに関係あるのか](https://w.wiki/4vdT)を考える 64 | 65 | 論理的思考の強みは、その思考を辿ることで大勢が同じ結論に到達できて、力を合わせやすくなることです。 66 | 67 | 自分の感情しか物事の判断軸を持たない人が周囲と常に同じ結論に到達できる確率は限りなくゼロですが、論理的に納得できる事実を共有できれば、同じ結論にたどり着く確率は飛躍的に高まります。 68 | 論理的思考を明文化して残しておけば、自分たちが書いたコードを将来メンテナンスする人とも[時間を超えて共有できます](https://adr.github.io/)。 69 | 70 | ### 想像力(優しさ) 71 | PrAhaの人材要件をただ一言「ギーク」とまとめることもできたのですが、改めて社内に今いるメンバーの顔を思い浮かべてみると、なんだかそれだけでは捉えきれていない気がしていました。そこで「優しいギーク」と一言加えてみるとしっくりきました。 72 | 73 | 優しさの定義はさまざまですが、私たちは**優しさとは想像力**だと考えています。 74 | 75 | - 苦しそうな表情をしている。何かあったのかもしれないから声をかけてみよう 76 | - こんな風にコードを書いておけば将来触る人が理解しやすいかもしれない 77 | - 言葉尻を少し変えた方が、言われた相手が気を悪くしないかもしれない 78 | 79 | 相手の状況を想像したり、自分の振る舞いが相手にどう伝わるか想像したり、優しさの基礎には必ず想像力があるように思うのです。 80 | 81 | どれだけ能力が高くても、優しさを持ちあわせていない人と働いていると次第に周囲が疲弊して離脱してしまいます。 82 | 83 | ですから私たちは、学び続ける意思と論理的な思考を伝える力を持ちながらも、人間的な優しさを持った方を仲間として迎え入れたいと考えています。 84 | 85 | ## PrAhaが大事にしている理念 86 | 優しいギークが集まるPrAhaでは、いくつかの大事な理念を持って会社を経営しています。 87 | 88 | ### 社員が自己決定できる環境を作る 89 | #### 自分の仕事は自分で決める 90 | マネージャーは居らず、組織は完全にフラットです。 91 | 自分の仕事内容を決める権限をメンバーに委譲しているので、自分の仕事は自分で決めます。 92 | 93 | 例えばクライアントワークを変えたいとメンバーが言えば、代表取締役であっても反対できません。 94 | 採用に携わってみたいと思えば手を上げれば良いし、会社のブランド作りに関わりたいと思えばやり始めれば良いし、メンバーが仕事を変えることを止める人はいません。 95 | 96 | 誰かに命じられて嫌々やっている仕事ではなく、[自分が興味を持っている仕事に全員が取り組んでいる組織の方が高い成果を出せる](https://www.amazon.co.jp/dp/4062144492)と信じているからです。 97 | 98 | #### 意思決定のための情報を提供する 99 | 必要な情報が得られなければ良質な意思決定にはつながりません。 100 | 101 | ですので、社内の情報は常に共有しています。 102 | 103 | 以下は共有している情報の一例です。 104 | - 全員の給与(報酬) 105 | - プロジェクトごとの営業利益 106 | - 開発依頼を受けた案件 107 | 108 | 社内のディレクトリにファイルが追加されたら自動的にSlackに通知されるなど、透明性を高める施策に取り組んでいます。 109 | 110 | ### 管理するのではなく信頼する 111 | PrAhaの社風を一言で表現すると「自由」です。 112 | 113 | 社員をルールや規則でがんじがらめにするのではなく、必要最小限のルールに留め、あとは自由に動いてもらうことを大事にしています。 114 | 115 | 適切な人材要件とセットで考えなければ自由な環境は無法地帯と化してしまいますが、先述のPrAhaらしさを兼ね備えたメンバーであれば、自由を健全に活用してくれていると信じています。 116 | 117 | #### 業務時間は管理しない 118 | PrAhaでは皆さんの業務時間を管理しません。1日何時間働いても構わないし、業務上支障がない限り、いつ休んでも問題ありません。 119 | 120 | 「管理しないと社員はサボる」と考えるのではなく「**管理しなくてもサボらない人を採用すれば良いのでは？**」と考えるのがPrAhaです。 121 | 122 | #### 会社のお金を使うために複雑な稟議は要らない 123 | 会社の資金を使う際は特に複雑な稟議プロセスを通す必要はなく、Slackに金額と用途を記載して2名以上から 👍スタンプをもらえたら、全社員に支給されるpaildカードを使って自由に決済いただけます。 124 | 125 | 面倒な承認プロセスを作らなくても、PrAhaのメンバーなら適切に会社のお金を使えると信頼しています。 126 | 127 | #### 副業は自由 128 | 個人の時間に副業を通して新たな知識の習得を目指す人を阻む理由がありません。そもそもラーニングアニマルを本業に留めておくことは不可能だと考えているので、仕事に支障がない限り副業に関する制限はありません。 129 | 130 | #### フルリモート 131 | 働く場所は規定していません。好きな場所で働いていただけます。 132 | 133 | ## 避けるべき行動 134 | 人材要件や理念をより具体的にイメージしやすいよう、避けるべき行動を例示します。 135 | 136 | ### 聞かれなければ何も言わない 137 | フルリモートで働いているとお互いについて得られる情報が少ないため、自分から状況を伝えていかないと周囲の助けを得られません。 138 | 139 | 積極的に以下のような情報をslackのtimesに投稿したりして、助けてもらいやすい状況を自分で作り出すことが求められます。 140 | 141 | - 今取り組んでいること 142 | - 詰まっていること 143 | - 考えていること 144 | 145 | フルリモート環境で周囲と協働して働く上で、自分について発信することは仕事の一部です。 146 | 147 | ### 自分の快適さしか考えない 148 | PrAhaのプロジェクトは1人で完結することがないためチームとして成果を出し続けられる人を大事にしています。 149 | 自分さえ良ければよい方に弊社は向いていません。 150 | 151 | ### 他の人が関わってくるのを待つ 152 | フルリモートだとオフィスで顔を合わせて雑談しているうちに仲良くなるということが起きづらいため、自分から周りの人に絡み、会話に参加していける人ほど良好な関係を築きやすくなります。 153 | 154 | ### 理詰めで論破する 155 | 人は感情で動く生き物です。 156 | 157 | 正しいことを言うのも大切ですが、より大切なのは正しいことが実行されることです。正しい意見だったとしても、伝え方が悪いために相手が聞き入れて実行してくれなければ意味がありません。遠慮は不要ですが、相手の心情を想像して伝え方やタイミングを配慮する必要はあります。 158 | 159 | ### 意見の否定を自身の否定と捉える 160 | 意見を否定することと個人を否定することは別です。 161 | 162 | 議論の度に傷ついたり、自己防衛をしていると、終いには健全な議論ができない相手とみなされてしまいます。意見が論理的に却下されたときは、良い学びを得たと解釈して、次の提案の質を高める方が健全です。 163 | 164 | ### 仕様変更に対して愚痴を言う 165 | 新規事業を開発していると日々新しい情報に触れて仮説検証が更新されていくため、仕様変更はつきものです。 166 | 167 | 以下のように想像力を働かせて仕様変更に耐えられるように備えておくことが、プロとしての腕の見せ所であり私たちの存在価値です。 168 | - 高凝集で疎結合なコードを書く 169 | - 事業ドメインを理解してデザイン的な拡張性を事前に検討しておく 170 | 171 | ### 頼まれたことしかやらない 172 | PrAhaに仕事を依頼するクライアントはITの専門家ではないことも多いです。 173 | 174 | そんな時は頼まれたことをやるだけでは不十分なので、想像力を働かせながら私たちのほうから必要なタスクを洗い出して提案していく必要があります。 175 | 176 | ### 自分のやり方を押しつける 177 | 1つのプロジェクトには異なる専門知識を持つ人たちが集まるわけですから、人それぞれのやり方があり、事業的な背景から生じる考え方や進め方があります。 178 | 179 | PrAhaのやり方が常に最適とは限りません。どんなに優れた解決策もコンテキストを考えず当てはめていると愚策になり得るので、それぞれの状況で何がベストかゼロベースで想像する必要があります。 180 | 181 | ### 批判しかしない 182 | PrAhaはものづくりの会社なので、必要なのは解決策を作れる人です。 183 | 184 | 100の批判を述べる人より、自分にできることを1つ考えて実行する前向きな人の方がPrAhaにとっては大切です。 185 | 186 | ### 解決策を1つ思いついたら思考が止まる 187 | 人は一度始めたことを止めるのが苦手なので、最初に思いついたアイデアを過大評価しやすい傾向があります。 188 | 189 | そうならないよう、常に複数の案を想像してから合理的に選択する癖を身につけることが大切です。 190 | 191 | ### 失敗を恐れて何もしない 192 | 失敗は自分の能力を超えた課題に挑戦した証です。 193 | 194 | 失敗を経験せずに成功する仕事なんてあり得ません。小さく失敗する方法を想像し、仮に失敗してもそこから何かを学んで次に活かす限り、失敗しても何も問題はありません。 195 | -------------------------------------------------------------------------------- /app/web-engineer-recruit/page.md: -------------------------------------------------------------------------------- 1 | # Webエンジニアの募集要項 2 | 株式会社PrAhaのWebエンジニアの求人ページです。 3 | 4 | ## 概要 5 | **給与** 6 | - 正社員の場合: 7 | - 618~1,069万円(固定残業代40時間/月を含みます) 8 | - 業務委託の場合: 9 | - 768~960万円 10 | 11 | **勤務地** 12 | - フルリモート・フルフレックス 13 | 14 | **雇用形態** 15 | - 正社員（業務委託も相談いただけます） 16 | 17 | **勤務形態** 18 | - 裁量労働制 (1日8時間のみなし労働) 19 | 20 | **年間休日数** 21 | - 正社員の場合: 22 | - 120日+4日(夏季休暇)+4日(年末年始休暇)+10~20日(年次有給休暇) 23 | - 業務委託の場合: 24 | - 業務に支障がない限り自由に休んでいただけます 25 | 26 | **福利厚生** 27 | - [福利厚生のページ](/benefits)に書いています 28 | 29 | **試用期間** 30 | - あり（3か月） 31 | 32 | **昇級評価** 33 | - 年3回（4月、8月、12月）行ないます 34 | - [人事評価のページ](/hr-evaluation)で「スキル通過申請シートを提出して通過したらスキルが上がる」と記載していますが、スキルが上がって給与に反映されるのが年3回という意味になります 35 | 36 | ## 仕事内容 37 | Webアプリのフロントエンド、バックエンド、クラウドインフラまでフルスタックに開発していただきます。 38 | 39 | ただし、雇用形態によって仕事内容が以下のように変わります。 40 | 41 | - 正社員の場合 42 | - アガルートグループのシステム開発（＝自社開発のようなもの） 43 | - PrAha Challengeのメンター 44 | - 業務委託の場合 45 | - 受託開発 46 | 47 | 2022年6月14日より、株式会社PrAhaは株式会社アガルートの子会社となりました。それに伴い、現在は株式会社アガルートが運営するサービスの自社開発をメインに行なっています。 48 | 49 | 以前までは、[PrAhaでは雇用形態を業務委託に限定していましたが](https://zenn.dev/praha/articles/8b7923cf261065)、自社グループの開発を行なうには、法的な理由で正社員として雇用が必要になりました。 50 | 51 | そのため、現在は業務内容に応じて「正社員」または「業務委託」に分ける形態を取っており、入社時にどちらかを選んでいただいています（入社後の変更も可能です）。 52 | 53 | ただし、現在はアガルートグループの体制強化のため、「正社員」での採用を積極的に進めています。 54 | 55 | ### 具体的な仕事内容の一例 56 | - ユーザーストーリーの実装 57 | - ドメインエキスパートへのヒアリングなどを通して事業理解を深め、適切なモデリングやDBスキーマ設計を行なう 58 | - 単体、統合、E2E、VRTなどさまざまなテスト手法を組み合わせて、安心して高頻度にデプロイ可能な開発フローの作成 59 | - XP、スクラムなどの手法に基づく開発プロセスの改善 60 | - 新規機能をマイクロサービスとして切り出して開発する際の技術選定 61 | - 円滑なデプロイを実現するためのCI/CDパイプラインの改善 62 | 63 | ## PrAhaの開発文化 64 | システム開発で重要なのは、機能追加や変更がしやすいこと。そしてその状態が長く続くことです。 65 | 66 | そのためには、認知負荷が低く変更容易性の高いコードを書くことが何より大切です。 67 | 68 | ですので、PrAhaでは以下のような開発文化を持っています。 69 | 70 | - プロダクトのコードはすべてコードレビュー、もしくはペア/モブプロを実施 71 | - マージ前には自動的にリグレッションテストが実行されるCI環境を構築 72 | - 各環境へのデプロイも自動化 73 | - 部分的にTDDで開発、特にバックエンドのコードは基本的にテストを書く 74 | - Storybookを導入したり、フロントエンドでもテストしやすい基盤を作る 75 | - 自社デザイナーがおり、開発だけではなくユーザー体験やUI/UXも重視 76 | 77 | PrAhaでは[新規事業のWEBサービスを開発するために必要な知識](https://zenn.dev/dowanna6/articles/502c49e3069132)を学べるブートキャンプ「[PrAha Challenge](https://praha-challenge.com/)」を運営しており、そこでは上記の開発文化に沿ったカリキュラムが用意されています。 78 | 79 | ## 技術スタック 80 | フロントもバックもTypeScriptで揃えることがほとんどです。 81 | 82 | 昔から存在するシステムは、Laravelで構築されています。 83 | 84 | - 言語 85 | - TypeScript 86 | - PHP 87 | - Dart 88 | - Rust 89 | - フロントエンド 90 | - Next.js 91 | - Vanilla Extract 92 | - Radix UI 93 | - Storybook 94 | - Flutter 95 | - Chromatic(VRT) 96 | - plop 97 | - バックエンド 98 | - Next.js 99 | - GraphQL Yoga 100 | - Drizzle ORM 101 | - Hono 102 | - Laravel 103 | - NestJS 104 | - データベース 105 | - MySQL 106 | - PostgreSQL 107 | - テスト 108 | - Jest 109 | - Vitest 110 | - Playwright 111 | - エラー監視 112 | - Sentry 113 | - バリデーション 114 | - Zod 115 | - 認証 116 | - Auth0 117 | - CI/CD 118 | - GitHub Actions 119 | - インフラ 120 | - AWS 121 | - Vercel 122 | - Cloudflare 123 | - Iac 124 | - AWS CDK 125 | - AWS Copilot 126 | - モノレポ管理 127 | - Turborepo 128 | - 依存関係管理 129 | - Renovate 130 | - パッケージ管理 131 | - pnpm 132 | - mise 133 | - aqua 134 | 135 | ## 求める人物像 136 | - [プラハってどんな会社？](/praha-overview)を読んで、共感していただいた方 137 | - プロダクトオーナーと直接対話しながらソフトウェアを開発していくことに喜びを感じる方 138 | - アプリケーション開発のプロとして、プロダクトオーナーと対等な関係でコミュニケーションを取り、良いプロダクトを作っていくことになるからです 139 | - 「こういう作りにすればもっと短期間で仮説検証できますよ」など、一歩踏み込んだ提案を通して、プロダクトオーナーと伴走してくれる方だと嬉しいです 140 | 141 | ## こんなキーワードに興味がある人は応募して欲しい 142 | - DDD(ドメイン駆動設計) 143 | - TDD(テスト駆動開発) 144 | - テストを書くのが好き(書かないと落ち着かない) 145 | - 型で固めるのが好き(できないと落ち着かない) 146 | - 高凝集、低結合 147 | - 静的型付け言語 148 | - 関数型プログラミング 149 | - ランタイムエラーが憎い 150 | - 単一責任原則 151 | - アジャイル開発 152 | - XP(エクストリームプログラミング),スクラム 153 | - 自動化 154 | - LeanとDevOpsの科学 155 | 156 | ※これらのキーワードを理解している必要はありません！これらに興味がある・学びたい・実践したいという方を歓迎します！ 157 | 158 | ## 必須スキル 159 | - 以下のうち1つ以上の経験 160 | - Vue.js、React、AngularJSなどを用いたSPAの開発経験 161 | - APIの開発経験（言語、フレームワーク不問） 162 | - AWS、GCPを始めとしたクラウドインフラ使用経験 163 | - ネイティブレベルの日本語能力（N1以上） 164 | 165 | まだ必須スキルを満たしていないもののPrAhaには興味がある！という方は「[PrAha Challenge](https://praha-challenge.com/)」の受講がオススメです！ 166 | 167 | ## 歓迎するスキル 168 | - クリーンアーキテクチャなど、ソフトウェアアーキテクチャの設計とそれに基づいた実装経験 169 | - SOLID原則など設計原則を理解してコードを書ける 170 | - テスタビリティの高いコードを書ける 171 | - リファクタリング経験 172 | 173 | ## この仕事で得られるもの 174 | - 意見が反映されやすい環境での開発経験 175 | - 密な会話を通して1つのものを作り上げていく楽しさ 176 | - 技術的負債を抑えることの重要性を理解している企業での低ストレスな開発環境 177 | - 質の高い開発を行なうメンバーから盗める開発ノウハウ 178 | - フルリモート勤務の働き心地の良さ 179 | 180 | ## 選考フロー 181 | 以下のステップで実施します。 182 | 183 | 1. カジュアル面談(30~60分) 184 | 2. フロントエンド技術面談(60~120分) 185 | 3. バックエンド技術面談(60~120分) 186 | 187 | ただし、フロントエンドとバックエンドの技術面談は、お好きな順番で受けていただけます。もし「バックエンドを先に受けたい」というご希望があれば、カジュアル面談の際にお伝えください（特にご指定がなければフロントエンドからご案内いたします）。 188 | 189 | なお、すべての面談はリモートでGoogle Meetを使って実施されます。 190 | 191 | [→カジュアル面談に応募する](https://docs.google.com/forms/d/1whmNgig8TKm8qTvAAYm5xjYE-3twTW8IIIen1ZMlyZE/viewform) 192 | 193 | ### 1. カジュアル面談 194 | ワイワイ雑談しましょう！ 195 | 面接官に30分罵詈雑言を浴びせ続けるぐらいのことをしない限り、ここで選考が止まることはありません。気軽に面談をお申し込みください! 196 | 197 | ### 2. フロントエンド技術面接 198 | #### やってもらうこと 199 | 弊社が用意したデザインとAPIに対して、フロントエンドの実装（ライブコーディング）をしていただきます。 200 | 201 | 言語はReact+TypeScriptでお願いしています。 202 | 203 | 公平のためアプリケーションは事前に公開しておりません。 204 | 205 | #### 評価したいこと 206 | - 既存のコードの設計思想を汲み取って合わせられるか 207 | - 責務を意識して凝集度とテスタビリティの高いコードを書けるか 208 | - 想像力を働かせて、将来的な拡張性をどこまで担保したコードを書けるか 209 | - 一般的なデザインをどこまで素早くCSSで表現できるか 210 | - コードを書き慣れているか 211 | - 適切なコミュニケーションで不明点を明らかにしながら作業を進められるか 212 | - 他のエンジニアが読み解きやすいコードを書けるか 213 | - 健全に技術的な議論ができるか 214 | 215 | ※すべてが100点でなくても大丈夫です！全体の評価が低かった場合でも、成長の可能性を感じたり、[プラハの社風](/praha-overview)にマッチしていると判断した場合は、プラス評価させていただきます！ 216 | 217 | #### なぜフロントエンドの面接を行なうのか 218 | PrAhaの開発では、1人のエンジニアがユースケース単位でフロントエンドからバックエンドまで一気通貫で実装することを多いです。 219 | 220 | そのほうがコミュニケーションコストがかからず、モジュール間で必要なタスクが埋もれたり(これはバックエンド(orフロントエンド)がやってくれると思ってました！的な)、仕事のサイロ化を防げると考えているからです。 221 | 222 | そのため、フロントエンドとバックエンドの技術面接はそれぞれ1回ずつ実施しています。 223 | 224 | #### なぜライブコーディングなのか 225 | 創業初期は口頭の技術面接を行なっていたのですが、口頭面接で測れるのはあくまで受け答えの上手さだけで、コードを書くのは上手だけど受け答えが苦手な方が評価されないなど、面接としての不完全さが目立つようになりました。 226 | 227 | どれぐらいコードを書けるのか判断するには、実際コードを書いている様子を見せていただくのが最も効果的だと考えたため、今のライブコーディング面接に落ち着きました。 228 | 229 | ### 3. バックエンド技術面接 230 | #### やってもらうこと 231 | 以下の2つの課題に取り組んでいただきます。 232 | 233 | 1. リレーショナルデータベースの論理設計 234 | - 既存のテーブルに対して「どのように改善するか」を検討していただきます。 235 | - 改善したテーブルを使って、簡単なSQLを書いていただきます。 236 | 2. 架空のサービスを想定したエンドポイントの実装 237 | - 任意のプログラミング言語で、1つのユースケースを実装していただきます。 238 | 239 | #### 評価したいこと 240 | - トランザクション、外部キー制約、インデックスなど、RDBMSに関する必要最低限の知識を持っているか 241 | - RDBMSを触り慣れているか 242 | - データベースのスキーマ設計に最低限必要な知識を持ちあわせているか 243 | - 想像力を働かせて、将来的な拡張性をどこまで担保したデータベースを設計できるか 244 | - 責務を意識して凝集度とテスタビリティの高いコードを書けるか 245 | - コードを書き慣れているか 246 | - 適切なコミュニケーションで不明点を明らかにしながら作業を進められるか 247 | - 他のエンジニアが読み解きやすいコードを書けるか 248 | - 健全に技術的な議論ができるか 249 | 250 | ※すべてが100点でなくても大丈夫です！全体の評価が低かった場合でも、成長の可能性を感じたり、[プラハの社風](/praha-overview)にマッチしていると判断した場合は、プラス評価させていただきます！ 251 | 252 | #### なぜバックエンドの面接を行なうのか 253 | フロントエンドの面接理由と同じなので割愛します。 254 | 255 | #### なぜ言語を問わないのか 256 | 以下の理由からです。 257 | 258 | - 言語特有の機能を駆使するよりも、適切な設計でコードを書けることの方が大切だから 259 | - 1つの言語で丁寧なコードを書ける人は、経験の浅い言語に移っても丁寧なコードを書いてくれると思うから 260 | 261 | ですので、面接では候補者の一番得意な言語を選んでいただいています。 262 | 263 | ただし、流石にアセンブラで書かれたら誰も評価できないので相談させていただく可能性がございます。 264 | 265 | #### なぜデータベース設計を行なうのか 266 | 負債が蓄積したデータベースを改修するのは本当に大変だからです。デプロイすれば終わりのアプリケーションコードと異なりデータベースには既存データが蓄積されているのでマイグレーションが伴うし、ロールバックしづらいし、作業の緊張感が段違いです。あとデータベースが腐っていたらアプリケーションコードも自然と腐っていくので、根っこの部分が何より大切だと考えています。 267 | 268 | そんな負債をクライアントに押しつけるわけにはいかないので、現実の事象を適切にモデリングできること、実用的な形で正規化と非正規化のバランスが取れること、適切な制約を設けられることなど、データベースの設計能力は重視しています。 269 | 270 | ### 面接の後は何が起きるのか 271 | 面接に参加しなかった他のエンジニアもライブコーディングの映像を拝見して、合否を検討します。技術面接の終了から1~2営業日で結果をご連絡いたします。 272 | 273 | ### 内定承諾 274 | 弊社がお送りする合格の連絡には、特に返信期限を設けていません。 275 | 276 | 転職すると生活が大きく変わる可能性があるので、いろんな情報を得て、納得してから決めた方が良いと考えています。それなのに短い期間で返信を迫るのは不誠実だと思うので、他の企業の選考を受けてみたり、弊社についてもっと調べてみたり、好きなだけ時間をかけていただいて構いません。合格から1年後に「入ります！」と言っていただいても大丈夫です。嬉しいです！ 277 | 278 | 内定者が社風を知るための機会を用意しています。もしご興味があれば毎月末を高級焼肉で祝う会にご招待しますし、面接では話せなかった他のメンバーとのオンライン面談も設定させていただきます！ 279 | 280 | ## 応募方法 281 | 以下からご応募ください！心よりお待ちしております！ 282 | 283 | [→カジュアル面談に応募する](https://docs.google.com/forms/d/1whmNgig8TKm8qTvAAYm5xjYE-3twTW8IIIen1ZMlyZE/viewform) -------------------------------------------------------------------------------- /app/hr-evaluation/page.md: -------------------------------------------------------------------------------- 1 | # 人事評価 2 | 株式会社PrAhaの人事評価について紹介するページです。 3 | 4 | ## 大前提 5 | 目先のお金とか評価を気にして働く会社ではなく、ものづくりを楽しむ人の会社を作りたいと考えています。 6 | 7 | 「不自由なく暮らせる程度のお金がもらえたら、あとはものづくりに集中したいよね」というのがPrAhaの考え方なので、社内のジュニアとシニア層の報酬差はそこまで大きくありません。 8 | 9 | 会社の調子が良ければ全員昇給するし、調子が悪ければ全員減給する。そんな基本コンセプトに基づいて人事制度を考えています。 10 | 11 | ## そもそもなぜ評価制度が必要なのか 12 | 個人(CEO)的には評価制度を作りたくありません。隙さえあればなくしたいと考えています。 13 | 14 | 誰もが評価を必要としているわけではないし、評価にかかる時間をコード書いたりデザインを作る時間に充てたいし、他人を評価すること自体がおこがましいし、低く評価するのは心が痛みます。 15 | 16 | そうした理由があるのにもかかわらず、PrAhaで人事評価制度を作っているのは、以下の2つの理由があるからです。 17 | 18 | - 幅広い経験の人と働けるようになる 19 | - 会社の方向性を揃えられる 20 | 21 | ### 幅広い経験の人と働けるようになる 22 | 「1人前の人しか採用しなければ評価しなくても済むのでは？」というのが創業当初のPrAhaの考え方でした。 23 | 24 | ただし、この考えだと以下の問題がありました。 25 | 26 | - 母集団が小さすぎて採用が進まない 27 | - 「人柄も申し分ないし、これから間違いなく伸びるから、一緒に働きたいなぁ」と思う人でも、報酬額と比較するとコストが高すぎて採用できない 28 | 29 | PrAha Challengeの卒業生がPrAhaを転職先に選んでくれる機会が増えていますが、それも修行中と1人前の給与制度を分けているからこそと言えます。 30 | 31 | なので「これからの成長に期待する人にも門戸を開きたい」という思いから新たに修行中枠の給与制度を設け、それに伴い評価制度が生まれました。 32 | 33 | ### 会社の方向性を揃えられる 34 | 開発やデザインのプロとして、必ず身につけなければいけない能力や振る舞いがあると考えています。 35 | 36 | その要素を全員に日常的に意識してもらうためには評価に組み込むのが効果的だと考えてたので、会社の方向性を揃えるために評価制度を設けています。 37 | 38 | ## 人事評価制度の概要 39 | ### スキルとは？ 40 | PrAhaが考える「1人前の社員として必要な能力」のことです。 41 | 42 | たとえば、エンジニアの場合は以下の通りです。 43 | - スキル1：確動性が高いか？ 44 | - スキル2：技術者として慣れているか？ 45 | - スキル3：学習意欲、能力が高いか？ 46 | - スキル4：質の高い開発ができるか？ 47 | - スキル5：チームで成果を出せるか？ 48 | - スキル6：アガルートグループ全体に対してどこまで影響力を持っているか？（正社員のみ） 49 | - スキル7：業界全体に対してどこまで影響力を持っているか？（正社員のみ） 50 | 51 | ### スキルを会得すると何が起きるのか 52 | 給料(月額報酬)が上がります。 53 | 54 | スキル1〜4を満たすと、「1人前」と呼ばれます。 55 | 56 | それまでは「修行中」と呼ばれます。 57 | 58 | ### エンジニアのスキル詳細 59 | 60 | それぞれのスキルを満たすために、具体的にどんな要素（✅）を満たせばいいのかを記載しています。 61 | 62 | - 正社員の場合、要素（✅）を満たすごとに昇給します 63 | - ()の中の金額は、正社員の場合の昇給額です 64 | - たとえば、スキル1の要素を4つ満たすと[ベース給与618](/web-engineer-recruit)＋(5×4)＝638万円/年になります 65 | - 業務委託の場合、スキルを満たすごとに昇給します 66 | - 以下はスキルごとの昇給額です 67 | - スキル1: +32.4万円 68 | - スキル2: +32.4万円 69 | - スキル3: +32.4万円 70 | - スキル4: +32.4万円 71 | - スキル5: +62.4万円 72 | - たとえば、スキル1,2,3を満たすと、[ベース給与768](/web-engineer-recruit)+(32.4+32.4+32.4)＝865.2万円/年になります 73 | - このページには記載していませんが、デザイナーも同じようなチェックリストで評価しています 74 | 75 | #### スキル1：確動性が高いか？ 76 | - ✅要素1: ミスが起きた際、自力ですぐに修正できる（+5万円） 77 | - 指摘された箇所をすぐ直せる 78 | - 指摘された問題にすぐ対応できる 79 | - 問題が起きたときのリカバリー方法を事前に考えている 80 | - ✅要素2: 過去の失敗から学び、同じ失敗をしない（+5万円） 81 | - 過去のやり方や考え方に固執せず、変化し続けられていること 82 | - ミスの原因を考えて対策を講じる 83 | - 何度も同じミスを指摘されない 84 | - ✅要素3: 1人でも着実に仕事を進められる（+5万円） 85 | - 能動的に動き、誰かから細かく指示を受けなくても着実に成果を出せる 86 | - 正常系の処理が網羅されていないコードを書かない 87 | - 異常系が考慮されていないコードを書かない 88 | - 誤った結果を生み出してしまうコードを書かない 89 | - ✅要素4: 情報伝達ミスが少なく、周囲と心地よく協働できる（+5万円） 90 | - 相手の意図を正確に把握し、他者に求められた成果物を齟齬なく提供できる 91 | - 必要に応じて確認して認識をすり合わせる 92 | - 進捗を周囲に共有し、チームとしての行動に支障をきたさないように動けるか 93 | - 仮に進捗が遅れているときは適切なタイミングで周囲に共有できているか、リカバリーをできているか 94 | - ✅要素5: 他者に仕事を頼む際、相手が確動性高く対応できるような明確なコミュニケーションを取れる（+5万円） 95 | - 相手の誤解を生まないよう、具体的な指示を出せるか 96 | - 自身の思考や求める結果を明文化して齟齬なく伝達できるか 97 | 98 | #### スキル2：技術者として慣れているか？ 99 | - ✅要素1: フロントエンドの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円） 100 | - 基本的な実装（ビューの構築、APIとの連携、feロジックの実装など）を周囲に負荷をかけることなく1人で実装できるか 101 | - バグや不具合などを自力で解決できるか 102 | - 手戻りによるタイムロスなく実装できるか 103 | - 1人で作業を任せてもスプリント（何らかのタイムスコープ）終了時に想定を大きく逸脱しない成果物を出せる 104 | - ✅要素2: バックエンドの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円） 105 | - 基本的な実装（db設計、アプリ単体で完結するような単純なデータのCRUD、テストの実装など）を周囲に負荷をかけることなく1人で実装できるか 106 | - 以下、同上 107 | - ✅要素3: インフラの実装スピードが1人前のメンバーと比較して遜色がないか（+12万円） 108 | - 基本的な構築（アプリケーションの実行環境の構築、dbのセットアップ、モニタリングや監視の仕組みの構築など）を周囲に負荷をかけることなく1人で実装できるか 109 | - 以下、同上 110 | - ✅要素4: 挑戦的な実装を担当しても大きく速度を落とすことなく実装できるか（+12万円） 111 | - チームに知見を持っている人がいないような領域の実装を任されても適切な技術調査を行ない、スプリントで合意した時間内に解決策を実装できるか 112 | - 設計や実装で何か問題が起きた際に、周りの力を借りるなど、素早く必要な対応を取れること 113 | - ✅要素5: 周囲の速度を落とすことなく立ち回れるか（+12万円） 114 | - 自身の実装速度を高めるために周囲の実装速度を落とすようなことがないか 115 | - 他者に仕事を依頼する際、相手が速度を落とすことなく作業できるような頼み方や、前提の共有をできているか 116 | 117 | #### スキル3：学習意欲、能力が高いか？ 118 | - ✅要素1: 個人の時間でも勉強しているか？その結果をアウトプットしているか？（+13万円） 119 | - 個人の時間に絶えず学習を行なっているか 120 | - 周囲が学習意欲を判断できるようなアウトプットを行なっているか（timesへの投稿、技術記事の執筆など） 121 | - ✅要素2: 日々できることが増えているか？（+13万円） 122 | - 学習結果を活用して新しいことができるようになっているか 123 | - 学習したことが見える形でアウトプットに反映されているか 124 | - ✅要素3: 学んだことを他者に教えられるほど理解しているか？（+13万円） 125 | - 学んだことを自分の言葉で説明できるか 126 | - 他者に説明できるほど深く物事を学んでいるか 127 | - 学んだことを他者に伝えたり外部に発信できているか 128 | - ✅要素4: 他者の学習意欲、学習能力も向上させているか？（+13万円） 129 | - 周りの人にメンションして質問したり、勉強会に誘うなどして、自分以外の人の学習意欲を高めているか 130 | - 社内にとどまらず社外の人も参加できる学習体験を生み出しているか 131 | 132 | #### スキル4：質の高い開発ができるか？ 133 | - ✅要素1: 責務を明確にして高凝集・低結合なコードを書けるか（+15万円） 134 | - 新たに作成したコード（ないしシステムの一部）は、常に責務が明確になっているか 135 | - テスタビリティが高いコードを書けるか（あるいはシステムの一部を作れるか） 136 | - 変更容易なコードを書いたり、システムの一部を作れるか 137 | - システムの複雑性を過度に増加することなく開発できる 138 | - 後々の開発者が理解に苦しんだり、改修する際に苦労しないよう、既存のサービスに手を加えられる 139 | - ✅要素2: 将来的に起こり得る問題を事前に想定して対処できるか（+15万円） 140 | - 現時点では起きていないものの将来的に起きうる問題を見つけられるか 141 | - 1人前エンジニアでなければ気づかないような複雑な問題を見つけられるか 142 | - 見つけた問題に対策を講じられるか 143 | - ✅要素3: 既存サービスをリファクタリングして技術負債を減らせるか（+15万円） 144 | - 既存コードを高凝集、低結合なコードに書き換えてテスタビリティや認知的負荷を改善できるか 145 | - コードに限らずシステムの構成要素を改善して、より高い非機能要件を満たせる状態を作れるか 146 | - デグレを起こさないよう必要な対策を講じた上でリファクタリングできるか 147 | - ボーイスカウトルールを忘れず、既存コードを少しずつでも構わないので改善しているか 148 | 149 | #### スキル5：チームで成果を出せるか？ 150 | - ✅要素1: チーム全体の生産性を底上げする努力をしているか？成果を出しているか？（+20万円） 151 | - チームの開発手法を改善する、新しいツールを導入するなどして、チームの生産性向上に貢献しているか 152 | - 自信の守備範囲を広げ、チーム内での貢献手段を増やそうとしているか。 153 | - 例えば... 154 | - PdMとして円滑なプロジェクトを進行を支援する 155 | - デザイナー、POなど、チーム外のメンバーとのやりとりの窓口を担う 156 | - スクラムプロセスを改善している 157 | - 他のエンジニアの開発者体験の向上につながる施策をしている 158 | - 自分がいなくなるとチームの成果や成長が止まるぐらい重要な存在になっているか 159 | - ✅要素2: 他のメンバーを助けているか？（+20万円） 160 | - チーム内、あるいはチームと密接に関わる人が困っているとき、助けを差し伸べているか 161 | - 直接助けを差し伸べられない場合も、助けを差し伸べられる可能性のある人に共有するなど、状況の改善に向けて行動しているか 162 | - 他のメンバーの業務を阻害したり、生産性を低下させる動きをしないか 163 | - ✅要素3: 課題を自ら見つけ、解決策を提案し、解決しようとしているか？（+20万円） 164 | - 仕事を割り振られるのを待つだけでなく、解くべき課題を自ら見つけられているか 165 | - 解決したときチームに役立つ課題を見つけられているか 166 | - 課題を指摘したり不満を口にするだけで終わらず、解決策を提案できるか 167 | - 課題を解決するための段取りを自分で作り、解決に向かっていけるか 168 | - ✅要素4: 適切なコミュニケーションを取れるか？（+20万円） 169 | - 端的に要点をまとめて意見を伝えたり、質問に答えられる 170 | - 自分の要望を伝えて他者の協力を得られる 171 | - 利害や優先順位が異なる人の意見をまとめて、開発を円滑に進められる 172 | - 相手に不快感を与えないコミュニケーションを取れる 173 | - チームの雰囲気を悪くしたり、他のメンバーに気を遣わせるなど、周りに負荷を与える振る舞いをしない 174 | - ✅要素5: チームの力を活かして問題解決できるか？（+20万円） 175 | - 単独で解決できる課題だけではなく、周囲の支援や行動を必要とする挑戦的な課題も解決していけるか 176 | - 課題を解決する際に孤立せず、関係者を巻き込み、協調して課題を解決できるか 177 | 178 | #### スキル6：アガルートグループ全体に対してどこまで影響力を持っているか？(正社員のみ) 179 | - ✅要素1: 自身の所属部署だけでは完結しない大きな課題を解決できるか？（+15万円） 180 | - 運用フローの変更、デザイン作成などの行動を他部署にも求めるような、自身の所属部署だけでは完結しない大きな課題を解決できる 181 | - 他部署の業務改善、成果向上に貢献している 182 | - 自身の成果物が所属するチームに留まらずグループ全体に影響を与えているか 183 | - ✅要素2: 他部署と良好な人間関係を構築できているか？（+15万円） 184 | - 他部署からとポジティブな形で存在を認識されている 185 | - 他部署からの情報をチームにもたらすハブになっている、あるいはそうした情報がもたらされる仕組みを構築している 186 | - ✅要素3: グループ全体に関する知識を有しているか？（+15万円） 187 | - 自身の所属部署以外の業務や組織に関する知識を多く有している 188 | - 上記知識を活用して、他部署からのクレームや遺恨を生むことなく、他部署にとっても満足度の高い意思決定を行なえる 189 | - 上記知識を活用して、解決すべき課題を自ら発見し、解決策を提案し、遂行できる 190 | - ✅要素4: グループ全体に発信しているか？（+15万円） 191 | - グループ全体の技術力、ITリテラシーを高めるための発信/発表などをしているか 192 | - グループ内で横展開されるような知見（実装方法/技術スタックなど）を提案、実用しているか 193 | 194 | #### スキル7：業界全体に対してどこまで影響力を持っているか？(正社員のみ) 195 | - ✅要素1: その人の存在が業界全体で広く認識されているか？（+33万円） 196 | - SNSで技術に関連する投稿を通して多くのフォロワーを有している（Twitterでフォロワー3,000名以上など） 197 | - 技術ブログで技術に関連する投稿を通して多くのフォロワーを有している（Qiitaの年間Contribution1,000以上など） 198 | - SpeakerDeckの登壇資料や自著書籍などを多く有している 199 | - 勉強会コミュニティを運営しているなど、社外のエンジニアと関係性を構築できている 200 | - ✅要素2: その人の存在が採用競争において優位に立てる要因になっているか？（+33万円） 201 | - 採用につながる広報活動を行なっており、成果を上げている（採用1人以上、もしくは多数の面談数） 202 | - グループ全体の認知度を上げるための活動を行なっており、成果を出しているか 203 | - 開発者としての発信力を上げるための活動（SNS、ブログ）を日々行なっている 204 | - ✅要素3: アガルートグループへの採用影響を問わず、その人の存在が業界全体に良い影響を与えているか？（+33万円） 205 | - 開発者コミュニティ全体に対して有益な情報を発信している 206 | - OSSへの貢献などを通してコミュニティに貢献している 207 | 208 | ### どうやってスキルを会得するのか 209 | 以下のような流れで会得できます。 210 | 211 | 1. スキル通過申請シートを埋めて提出する 212 | - たとえば、Aさんのスキル通過申請シートを提出できるのは、以下のいずれかの人です 213 | - Aさん本人（自薦） 214 | - 社員（他薦） 215 | - スキル通過申請シートはいつでも提出できます 216 | 2. 提出を受けたら、「1人前の社員」がスキルを会得しているか否か判断する 217 | - 評価に参加したい「1人前の社員」が評価を行ないます 218 | 219 | #### 評価のポイント 220 | ##### 妥当性 221 | - スキル通過を判断する上で妥当な推薦理由になっているか 222 | - 例えばスキル5に対して「コードを書くのが速い」という推薦理由の場合、チーム成果と関係がないので妥当ではない 223 | - 推薦項目に記載されたことは事実か 224 | - クライアント、および同じチームのPrAhaメンバーにヒアリングして確認する 225 | 226 | ##### プロジェクトの期間 227 | - より長くプロジェクトに在籍しているとプラス 228 | - 1か月しかプロジェクトに在籍していない場合、まだ難易度の高いタスクが渡されていない可能性がある。一方、同じプロジェクトに3年所属していれば重要なタスクを任されている可能性が高いため。 229 | - 難易度の高い仕事に挑戦しながらも推薦を受けている人の方が高く評価されるべきだと考えているため、長く参加しているプロジェクトに関する推薦の方が高く評価されやすい 230 | 231 | ##### プロジェクトの数 232 | - より多くのプロジェクトで推薦されているとプラス 233 | - 特定のプロジェクトでのみ推薦される人より、プロジェクトを問わず推薦される人の方が高く評価されやすい 234 | - より汎用的にスキルを発揮できる人の方が高く評価されるべきだと考えているため 235 | 236 | ##### 推薦してくれた人数 237 | - より多くのPrAhaメンバーから推薦されているとプラス 238 | - 特定のメンバーからのみ推薦される人より、複数人から推薦される人の方が高く評価されやすい 239 | - より汎用的にスキルを発揮できる人の方が高く評価されるべきだと考えているため 240 | 241 | #### 人事制度見直しのタイミング 242 | - 評価に関わる1人前社員が8人を超えたとき（全員が集まると会議が非効率なため） 243 | - 1on1などで社内メンバーが給与制度に不満を持っていることが判明したとき 244 | 245 | ## この評価制度の問題点 246 | 万能の評価制度は存在せず、すべての評価制度には問題がある（不安を抱える人がいる）と考えています。 247 | 248 | 今の評価制度の問題は以下の通りです。 249 | 250 | - 1人プロジェクトで1人のクライアントとしか関わらない人が評価されづらい 251 | - フルリモート、かつ各々が異なるプロジェクトに関わっていることがあるため、少ない情報で判断を下さなければいけない 252 | - エンジニアやデザイナーという職種は繰り返し作業が少ないので、具体的な評価項目を作りづらい 253 | - 以前「Vue.jsでコレができたら昇給」というような細かな評価基準を作ったことがあるが、すぐ基準が陳腐化して誰も使わなくなった 254 | - そもそも定量的に判断しづらい職種だから、多数の定性評価を集めて定量的な判断を代替しよう、というのがPrAhaの評価制度の根底にある考え方 255 | - そのためには多数の定性評価が必要だが、定性評価が集まりづらい条件が揃っている（プロジェクト制、フルリモート）のが今のPrAhaの評価制度の最大の問題点 256 | 257 | ## この評価制度を廃止する条件 258 | 評価制度は基本的に撤廃したいと考えています。 259 | 260 | 以下の課題さえクリアできれば撤廃したいと思っています。 261 | 262 | - これから間違いなく伸びる！と感じたジュニア層を採用できる 263 | - 全員給与を一律にすると能力に対する報酬が高すぎるため会社としての経営が苦しくなる 264 | - 社内の不満が今より減る 265 | - 「なんでこの人自分より圧倒的にスキルが低いのに同じ報酬なの？」という不満が起きない 266 | - スキルを伸ばすモチベーションがなくならない 267 | - 報酬が一緒なら頑張らなくてもいいや、みたいな 268 | - 会社として大事にして欲しい行動を促せる 269 | - チームの成果を最大化することを考えて動くとか、想像力を働かせて働くとか 270 | - 現実的な負荷で採用面接を実施できる 271 | - 評価をなくすと採用面接で事前に見ておかなければいけないことが増える。ただでさえ重めの面接を実施している＋PrAha自体の知名度が足りないため、そもそも受けてくれる人がいなくなってしまう問題 272 | 273 | ## FAQ 274 | ### なぜ申請シートを記述するの？ 275 | - 口頭だけで評価を実施してしまうと評価の観点や「何をすれば昇給するのか」などの大切な情報が隠蔽されてしまうから 276 | - 納得感のある制度を作るためにも過去の決定や検討事項は残しておきたい 277 | 278 | ### スキルを失うことはあるの？ 279 | 現時点ではないです。 280 | 281 | ### 一度の申請ですべてのスキルを通過する可能性もあるの？ 282 | あります。 283 | 284 | ### ずーっとスキルが上がらないこともあるの？ 285 | あります。 286 | 287 | ### 平均でどれぐらいの期間で1人前になるの？ 288 | 入社から2年ぐらいで1人前になっているイメージです。 289 | 290 | 参考までに、2024年のスキル通過履歴です（2024年12月現在）。 291 | 292 | - 2024/1から 293 | - MGさん: 6-1, 7-2 294 | - 2024/3から 295 | - OMさん: 2-2, 2-3, 3-2 296 | - 2024/4から 297 | - KMさん: 1-1, 1-3, 1-4, 1-5, 2-2, 2-3, 2-4, 2-5 298 | - 2024/6から 299 | - KYさん: 4-1, 4-2, 4-3, 5-1, 5-2, 5-3, 5-4, 5-5, 7-2, 7-3 300 | - 2024/7から 301 | - HYさん: 6-1, 6-2, 6-3 302 | - 2024/8から 303 | - 全社員のベースアップ（約20万円/年アップ） 304 | - SSさん: 1-1〜1-5, 2-2〜2-4, 7-3 305 | - MYさん: 1-1〜1-4 306 | - KSさん: 5-2 307 | - KMさん: 5-2,5-3 308 | - 2024/12から 309 | - KSさん: 5-1, 5-4, 6-2 310 | - OMさん: 1-3, 3-1, 4-2 311 | - KMさん: 2-1 312 | - NKさん: 1-3 313 | 314 | ### 推薦した人が昇給を拒否した場合は？ 315 | 本人の意思を尊重して昇給しませんが、レアケースだと思うので事情を聞かせてもらいたいです！ -------------------------------------------------------------------------------- /app/pracracy-manual/page.md: -------------------------------------------------------------------------------- 1 | # プラクラシー 2 | 3 | PrAha独自のホラクラシーである「**プラクラシー**(PrAcracy)」のルールを明記したページです。 4 | 5 | ## プラクラシーとは？ 6 | プラクラシーは、ホラクラシーをPrAhaに適した形にアレンジした組織体制のことです。 7 | 8 | ホラクラシーは、明確な役職や上下の階級を設けず、誰もが意思決定できるフラットな組織体制を指します。 9 | 10 | ## なぜプラクラシーが必要なのか 11 | PrAhaは2021年頃にホラクラシーを採用していました。 12 | 13 | しかし、以下の2点の理由から意識する機会がほとんどありませんでした。 14 | 15 | - 覚える用語やルールが多すぎた 16 | - 独立したプロジェクトに取り組む社員が多かったためホラクラシーで社内を整理するまでもなかった 17 | 18 | ただ、2022年6月にアガルートにM&Aした影響で、アガルートの自社サービス開発がはじまり、採用活動も活発化し、相互作用する仕事が増えてきました。 19 | 20 | ですので、ホラクラシーでの経験を踏まえた上で、プラクラシーを導入することにしました。 21 | 22 | ## プラクラシーの目的 23 | 以下の2つです。 24 | 25 | 1. 社員が能力を最大限に活かせる状態を作ること 26 | 2. マネージャーが居なくても回る会社を作ること 27 | 28 | ### 1. 社員が能力を最大限に活かせる状態を作ること 29 | 以下の3つが重なった仕事を任されたとき、人の力は最大化されると考えています。 30 | 31 | - 自分がやりたいこと 32 | - 自分ができること 33 | - 周りに役立つこと 34 | 35 | 全社員がそんな仕事を持てるようにすることがプラクラシーの目的です。 36 | 37 | ### 2. マネージャーが居なくても回る会社を作ること 38 | ものづくりが好きな人が集まっている弊社ではマネージャーをやりたがる人が少ないので、マネージャーの役割を分割して仕組み化して、マネージャー不在でも回る会社を作る方が建設的だと考えました。 39 | 40 | ## プラクラシーのルールを理解する 41 | ルールを列挙しても覚えづらいと思うので、新人が入社したものとして社内のルールを解説します。 42 | 43 | 「**まとめ**」と書いてある部分だけ読んでいただいても大丈夫です。 44 | 45 | ## プラハの勤務初日 46 | 新人「今日からプラハに入社だ！頑張ろう！」 47 | 48 | プラヲ「君が新人くんだね！僕は**新入社員のフォローチーム**の**リーダー**をしているプラヲです！」 49 | 50 | 新人「**チーム？リーダー？** よくわかりませんがよろしくお願いします。早速ですが、僕は今日から何をすれば良いですか？」 51 | 52 | プラヲ「新人くんは、プロジェクトAの開発という**チームにアサインされている**から、詳しくはそこの**リーダー**に聞いてみてね」 53 | 54 | 新人「わかりました！」 55 | 56 | ### まとめ 57 | - チームという概念がある 58 | - チームにはリーダーがいる 59 | 60 | ## チームとは？ 61 | 新人「おはようございます、新人です！プロジェクトAのリーダーさんはいますか？」 62 | 63 | A男「どうも、プロジェクトAのリーダー、A男です！」 64 | 65 | 新人「まだ会社のことがよくわかっていないのですが、**チームって何ですか？**」 66 | 67 | A男「チームというのは1名以上の社員から構成される**組織の最小単位で**、一般的な会社で言う「課」と思ってもらえたら大丈夫だよ」 68 | 69 | 新人「なるほど。部とか事業部は存在しないんですか？」 70 | 71 | A男「プラハにはチームしか存在しないよ。以下の階層構造になることはあるけど、名前は全部一貫してチームだよ」 72 | 73 | - チームの上に別のチームがある 74 | - チームの中に他のチームがある 75 | 76 | 新人「何となくわかりました。ところで、ここは何をするチームなんですか？」 77 | 78 | A男「それを説明するには、チームの目的から話さないといけないね。チームにはすべて目的があり、その目的は以下によって定義されているんだ」 79 | 80 | - **背景** 81 | - **Objective** 82 | - **責務** 83 | - **権限** 84 | - **Key Results** 85 | 86 | 新人「Objective？責務？よくわからないです」 87 | 88 | A男「まずはこのチーム↓を例に見てみようか。全部書き出すと大変だから一部抜粋して紹介するよ」 89 | 90 | ``` 91 | ## チーム名 92 | - プロジェクトAの開発 93 | 　 94 | ## 背景 95 | - 昨年の売上は過去5年で最も伸び幅が少なかった。 96 | - 市場を取り尽くしてしまったことが要因として考えられるため、新たな市場にサービスを提供する必要がある 97 | 　 98 | ## Objective 99 | - 関係者と合意した期日までにサービスAの全機能をリリースし、全社売上の5割を超える事業を作ること 100 | 　 101 | ## 責務 102 | - リリース日を変更する必要が生じたら関係者と合意形成すること 103 | - 合意したSLAをリリース後も満たせるよう運用すること 104 | 　 105 | ## 権限 106 | - 追加で3名までエンジニア・デザイナーを採用してチームに加える権限 107 | - リリース日を決定する権限 108 | 　 109 | ## Key Results 110 | - マージできたPRの数(週次) 111 | - 次回リリース予定の機能とリリース予定日(週次) 112 | - 全機能のリリース予定日(月次) 113 | 　 114 | ## 目を通しておくべき情報 115 | - (何らかのURLへのリンク) 116 | ``` 117 | 新人「なんだか、1つのチームに対してずいぶん色々と細かく明文化されているんですね」 118 | 119 | A男「これがプラクラシーのキモとも言える、**暗黙の期待を作らないこと**に繋がるんだ」 120 | 121 | ### まとめ 122 | - チームは**組織の最小単位** 123 | - チームの中にチームが入っていたり、**チームは階層構造になる** 124 | - チームには、以下が必ず明文化されている 125 | - 背景 126 | - Objective 127 | - 責務 128 | - 権限 129 | - Key Results 130 | - 目を通しておくべき情報 131 | 132 | ## 暗黙の期待を作らない 133 | 新人「暗黙の期待？」 134 | 135 | A男「上司が **「こういうことをしてくれるだろう」と暗黙的に期待していることが多いと、やって欲しいこととやることのミスマッチが起きやすい**んだよね。そうならないように仕事を頼む上で大事なポイントは明文化しておくのがプラクラシーなのさ」 136 | 137 | 新人「明文化しておけば誤解も起きづらいですもんね。完全に理解しました！ただ、「背景」とか「Objective(直訳:目的)」は何となくイメージがつくんですが、「責務」ってなんでしょう？Objectiveだけじゃダメなんですか？」 138 | 139 | A男「**まず前提として、チームはObjectiveを達成する手段を制限なく自分達で自由に考えて良いんだ**。例えばサービスAを作ることがObjectiveだとしたら、自社のエンジニアで作るのではなく外注する選択肢もあるよね」 140 | 141 | 新人「え、そんなことまでA男さんが決めていいんですか？」 142 | 143 | A男「理論的にはね！ただ、**このチームの1つ上に位置するチーム** のリーダーからこのチームを託されたときの**アサインミーティング**で質問してみたら、今回は自社エンジニアで開発して欲しいと回答されたので、外注は選択肢から除外したよ。それ以外のことは基本的にリーダーの僕が決めていいんだ」 144 | 145 | 新人「へ〜、**色々決められているけど、決められたことの達成方法は自由に任されているんですね**」 146 | 147 | A男「その通り。**何がほしいかは伝えるけど、どう実現するかは指示しない。それがプラクラシーの基本だ**」 148 | 149 | ### まとめ 150 | - 暗黙の期待がコミュニケーションミスを生む 151 | - 暗黙の期待を作らないために、徹底的に明文化する 152 | - チームのObjectiveは決まっているが、その達成方法はチーム内で自由に考えて構わない 153 | 154 | ## 責務とは？ 155 | 新人「目的を達成する方法はチームが自由に考えてよし、と」 156 | 157 | 新人「あれ、でも**責務はやるべきことをかなり具体的に指示**していませんか？」 158 | 159 | A男「そうだね。**目的の実現方法は基本的に任せるけどこれだけは必ずやってほしい、という行動が責務として記載される**んだ。あまりにも想像と違うことをされてしまうと、周りが困ってしまうからね」 160 | 161 | 新人「なるほど。プロジェクトAの場合『リリース日を変更する必要が生じたら関係者と合意形成すること』って責務が加えられていますね。この仕事の進め方だけは絶対に守ってほしい、ってことか」 162 | 163 | A男「そんなイメージだね！」 164 | 165 | 新人「期待されるSLAを守ること、って責務も書いてありますね。期日通りにリリースされても品質がボロボロだとダメだから、それを事前に責務として明言してくれているんですね」 166 | 167 | A男「そうそう。ただ、このチームのObjectiveに「全社売上の5割を超える事業を作る」って書いてあるよね。仮にSLAが責務に書かれていなかったとしても、ボロボロのサービスでこの目的が達成できるとは思えない。となると品質面も妥協できないことは**自分達でも判断して考える**べきなんだ。 168 | 169 | 細かく明文化すると「それは書いていないのでやりません」っていうマニュアル文化が生まれがちだけど、それはプラクラシーの本質を理解していないんだよね。**暗黙の期待を減らして合意形成を支援するための明文化であって、ここまでやればOKと思考停止するための明文化ではない**からね」 170 | 171 | 新人「暗黙の期待を避けるために期待を明文化するけど、書かれた内容に盲従するだけではいけないんですね。難しい」 172 | 173 | A男「最初は難しいけど、徐々に慣れてくるよ！じゃあ早速このチームで明日から働きはじめてもらおうか」 174 | 175 | 新人「はい！」 176 | 177 | ### まとめ 178 | - 基本的な仕事の進め方は自由。ただしこれだけは必ずやって欲しい、というタスクはチームの「責務」として明文化される 179 | - 暗黙の期待が生まれてしまうのを避けるために明文化するが、明文化されたこと以外はやらなくて良いというマニュアル文化が生まれてしまうのは本来意図していることではない 180 | 181 | ## 権限 182 | （数日後） 183 | 184 | A男「新人君おはよう。最近仕事で困っていることはない？」 185 | 186 | 新人「あります！会社横断の基幹サービスと連携する部分を書いているのですが、このコードレビューは誰にお願いすれば良いのでしょうか？」 187 | 188 | A男「ちょうどいい質問だね！**チームに与えられた権限**について話そうか」 189 | 190 | A男「改めてこのチームの権限を振り返ってみよう」 191 | ``` 192 | ## 権限 193 | - 追加で3名までエンジニア・デザイナーを採用してチームに加える権限 194 | - リリース日を決定する権限 195 | ``` 196 | A男「ここには基幹サービスに関することは特に書いていないね。じゃあ改めて僕らの会社の組織図を見てみようか↓」 197 | 198 | ``` 199 | praha 200 | ├── オンボーディングチーム 201 | │ └── 新入社員のフォローチーム 202 | ├── ミラクル新規事業チーム 203 | ├── 営業チーム 204 | ├── 情報整理チーム 205 | ├── 経理チーム 206 | └── 開発チーム 207 | ├── プロジェクトAの開発チーム <- イマココ! 208 | ├── Bプロジェクトの開発チーム 209 | ├── DX改善チーム 210 | ├── 技術力底上げチーム 211 | └── 基盤開発チーム 👈 212 | ``` 213 | 214 | A男「この組織図を見た感じ、基盤開発チームが関係してそうだね。ここの権限を見せてもらおう↓」 215 | ``` 216 | ## 基盤開発チームの権限 217 | - 基盤サービスに向けられたPRのレビュー及び取捨選択 218 | ``` 219 | 新人「あ、それっぽいことが書いてある！」 220 | 221 | A男「基盤サービスのコードレビューは**このチームの権限だから、このチームに頼まなければいけないことがわかったね**」 222 | 223 | 新人「こういう風に権限が明文化されていると、誰が何をやって良いのかわかりやすくて便利ですね」 224 | 225 | A男「同じ会社で働いていると、**複数のチームが同じリソースを共有することが多々あるからね。** リソースに対する操作がバッティングしないように、**誰がリソースに対する権限を持っているのか明記しておく必要がある**んだ」 226 | 227 | 新人「完全に理解しました」 228 | 229 | ### まとめ 230 | - チームには「権限」が与えられる（与えられないこともある） 231 | - **誰がどのリソースに対して何の権限を持っているのか**、が権限の項目には明記される 232 | - 複数チームが同じリソースに対して競合する作業を行なうことを防ぐためにある 233 | 234 | ## Key Results 235 | （数日後） 236 | 237 | A男「そろそろKey Resultsを報告する時期だから、今週このチームでクローズされたPRの数を集計して報告してもらっても良いかな？」 238 | 239 | 新人「Key Results？」 240 | 241 | A男「まだ説明してなかったね。じゃあこのチームに与えられたKey Resultsを振り返りながら説明しよう」 242 | 243 | > - マージできたPRの数(週次) 244 | > - 次回リリース予定の機能とリリース予定日(週次) 245 | > - 全機能のリリース予定日(月次) 246 | 247 | A男「うちのチームにはこういうKey Resultsが決められているから、1つ目のKey Results「マージできたPRの数」を毎週集計してspreadasheetを更新しているわけだよ」 248 | 249 | 新人「**要は1つ上のチームリーダーに報告する内容**ってことですかね？」 250 | 251 | A男「チームの階層構造についてしっかり覚えているみたいだね！ひとまずそう捉えてもらって構わないよ。例えばうちの組織図で言うと「開発チーム」は「プロジェクトAの開発チーム」とか、1つ下のチームのKey Resultsには興味があるだろうね」 252 | 253 | ``` 254 | praha 255 | ├── オンボーディングチーム 256 | │ └── 新入社員のフォローチーム 257 | ├── ミラクル新規事業チーム 258 | ├── 営業チーム 259 | ├── 情報整理チーム 260 | ├── 経理チーム 261 | └── 開発チーム 👈このチームのリーダーは 262 | ├── プロジェクトAの開発チーム 👈このチームのKRを知りたい事が多い 263 | ├── Bプロジェクトの開発チーム 👈このチームのKRを知りたい事が多い 264 | ├── DX改善チーム 👈このチームのKRを知りたい事が多い 265 | ├── 技術力底上げチーム 👈このチームのKRを知りたい事が多い 266 | └── 基盤開発チーム 👈このチームのKRを知りたい事が多い 267 | ``` 268 | 269 | 新人「ひとまず？ってことは、例外があるんですか？」 270 | 271 | A男「その通り。プラクラシーで特徴的なのは、**KRは社内の誰にいつ要求されても、必ず開示する必要がある**ということだね」 272 | 273 | 新人「え！じゃあ僕がミラクル新規事業チームとか、**全然自分が関係ないチームにKRを聞いても教えてくれる**んですか？」 274 | 275 | A男「そうだよ。プラクラシーで大事にしているのは情報の透明性だから、上長とかを経由することなく直接あらゆるチームのKRを閲覧できるようになってるよ」 276 | 277 | 新人「へ〜。でも全然関係ないチームにしょっちゅう聞かれたら面倒臭そうですね」 278 | 279 | A男「そうなんだよね。だから大体のチームは「KRに興味ある方はこちらをみてください」とわかりやすく組織図にリンクを貼っていたりするよ。こうすれば見たい人は勝手に見て解決できるから」 280 | 281 | 新人「そうやって情報の透明性を担保していくんですね。了解です、集計してきます！」 282 | 283 | ### まとめ 284 | - チームはKey Resultsに定められた頻度で指標を更新し、閲覧可能な状態にしなければいけない 285 | - KRは社内の誰にいつ要求されても必ず開示する必要がある 286 | - この仕組みを通して情報の透明性を担保していく 287 | 288 | ## tension 289 | (数日後) 290 | 291 | 新人「うーん」 292 | 293 | A男「何かお悩みの様子だね」 294 | 295 | 新人「あ、お疲れ様です。最近DX改善チームから「こういうツールを入れてください」と言われたんですが、逆に技術力底上げチームからは「外部ツールに頼らず可能な限り自前で作りましょう」と言われて、どちらのいうことを聞くべきなのか困惑してるんですよね」 296 | 297 | A男「なるほど、それはプラクラシーの「**tension**」だね。プラクラシーにおけるtensionは、**あるべき姿と現状が乖離していて、それにより不都合が生じている状態**、という定義だよ」 298 | 299 | A男「例えば今回のケースでは、新人くんは2つのチームから異なる指示を受けてどう動けば良いかわからなくなってしまった。これは本来あるべき姿ではないと思うんだ」 300 | 301 | 新人「そうですね。前にも似たようなことが起きたので、組織を横断して技術力を高めるチームが1つにまとまっていた方が良い気がします。A男さん、なんとかしてくれませんか？」 302 | 303 | A男「え？どうして？」 304 | 305 | 新人「えーと、A男さんは僕の上司だから？」 306 | 307 | A男「**プラクラシーに上司とか部下という概念はないよ**。僕は自分のチームのリーダーではあるけど、新人くんの困りごとをすべて解決するのはリーダーの役割ではないんだ。だから**tensionに関しても、それを感じた本人が解消に向けて動くことが求められるよ**」 308 | 309 | 新人「えー、そんなー！僕は誰に相談すればいいんだろう」 310 | 311 | A男「とはいえ、**役割じゃないからといって困っている人を見捨てて良いわけではないから、僕ができる限りの支援をしよう**。まず開発チームのリーダーに引き合わせるから、その人に相談してみようか！きっと開発チームのリーダーならこのtensionの解決に一役買ってくれるはず」 312 | 313 | A男「今から開発チームのリーダーに会いに行こう」 314 | 315 | ### まとめ 316 | - あるべき姿と現状が乖離していて、それにより不都合が生じている状態をtensionと呼ぶ 317 | - tensionを解決するのは、tensionを感じている本人の責務 318 | - 周りはtensionを解決しようとしている人をできる限り支援することが求められる 319 | 320 | ## tensionからチームが再構成される瞬間 321 | （2人でオフィスを移動する） 322 | 323 | A男「安倍さん、お疲れ様です」 324 | 325 | 安倍「お疲れ！」 326 | 327 | A男「うちのメンバーが現状のチーム構造にtensionを感じているみたいなので、相談させてもらえないでしょうか。安倍先輩は開発チームのリーダでしたよね？」 328 | 329 | 安倍「**いや、俺は先週リーダーを他の人に頼んだよ**。もう少しコードを書く方に集中したくてさ」 330 | 331 | A男「あ、そうだったんですね。誰が今リーダーやってるんですか？」 332 | 333 | 安倍「**組織図に反映しておいた**から、そこを見ればわかるよ」 334 | 335 | ``` 336 | praha 337 | ├── オンボーディングチーム 338 | │ └── 新入社員のフォローチーム 339 | ├── ミラクル新規事業チーム 340 | ├── 営業チーム 341 | ├── 情報整理チーム 342 | ├── 経理チーム 343 | └── 開発チーム リーダー: 安倍->岸田(4月1日から) 344 | ├── プロジェクトAの開発チーム リーダー: A男 345 | ├── Bプロジェクトの開発チーム 346 | ├── DX改善チーム 347 | ├── 技術力底上げチーム 348 | └── 基盤開発チーム 349 | ``` 350 | 351 | A男「了解です！えーと、岸田さんか。ありがとうございます！」 352 | 353 | （2人でオフィスを移動する） 354 | 355 | A男「岸田さんお疲れ様です。うちのメンバーがtensionを感じているらしいので、少し相談に乗っていただけないでしょうか？」 356 | 357 | 岸田「いいよー」 358 | 359 | 新人「えーと、実はかくかくしかじかで」 360 | 361 | 岸田「あー、確かにそのtensionは他の社員からも聞いたなぁ。今2つに分かれているチームのリーダーは、麻生さんと小泉さんか」 362 | 363 | 364 | ``` 365 | praha 366 | ├── オンボーディングチーム 367 | │ └── 新入社員のフォローチーム 368 | ├── ミラクル新規事業チーム 369 | ├── 営業チーム 370 | ├── 情報整理チーム 371 | ├── 経理チーム 372 | └── 開発チーム 373 | ├── プロジェクトAの開発チーム 374 | ├── Bプロジェクトの開発チーム 375 | ├── DX改善チーム リーダー: 麻生さん <- この2つのチームをまとめようかな 376 | ├── 技術力底上げチーム リーダー: 小泉さん <- この2つのチームをまとめようかな 377 | └── 基盤開発チーム 378 | ``` 379 | 380 | 岸田「**俺がリーダーを務めているチーム内の統廃合に関しては俺が決められるから**、1つのチームにまとめることにしようか」 381 | 382 | 新人「やった！」 383 | 384 | 岸田「**ただ今回のチーム統合により新たなtensionが生まれるといけないから**、次の開発チーム定例で開発チーム配下のリーダーを集めて話し合ってみるよ」 385 | 386 | 新人「僕の提案をきっかけにチーム構成があっという間に変わってしまった。すごいスピード感だ」 387 | 388 | 岸田「**tensionを報告した当事者として君もミーティングに参加してね**」 389 | 390 | 新人「あ、僕も参加するんですね」 391 | 392 | 岸田「そりゃそうさ。もしかしたらチームを統合する以外の解決策が提案されるかもしれない。**新しく提案された解決策が本当にtensionを解消できるか、tensionを報告した君が一番よく判断できるだろう**」 393 | 394 | 新人「えー！チームの統廃合に関わる大事な話が、僕のtensionに対する意見で決まっちゃっても良いんですか？僕の意見でプジョルさんとシャビさんのどちらかがリーダーではなくなってしまうのは、なんだか申し訳ないというか」 395 | 396 | 岸田「プラクラシーでは、チームの統廃合とか、誰がどれだけ上のチームのリーダーだとか、そんなのは些細なことだ。**状況が変化しているのに組織だけ変化しないままtensionが放置されることは、何としても回避しなければいけない**。最高だと思っていた組織形態も、社員が増えることで破綻することがあるだろう？そうならないためにも、**状況に合わせて組織が有機的に変わっていく必要がある**んだ」 397 | 398 | 新人「組織全体がすごく柔軟なんですね。わかりました、責任持ってtensionを定例で報告します！」 399 | 400 | (そして数日後、定例での話し合いにより麻生さんのDX改善チームは「技術力底上げチーム」に統合された) 401 | 402 | ``` 403 | praha 404 | ├── オンボーディングチーム 405 | │ └── 新入社員のフォローチーム 406 | ├── ミラクル新規事業チーム 407 | ├── 営業チーム 408 | ├── 情報整理チーム 409 | ├── 経理チーム 410 | └── 開発チーム 411 | ├── プロジェクトAの開発チーム 412 | ├── Bプロジェクトの開発チーム 413 | ├── 技術力底上げチーム 414 | └── 基盤開発チーム 415 | ``` 416 | 417 | ### まとめ 418 | - プラクラシーでは、tensionを解消するためにチームが新しく誕生したり、統廃合されることがある 419 | - 自チーム内の構成を変える（新しく作る、変える、消す）権限はチームのリーダーに移譲されている 420 | - ただしチーム構成を変える際は、新たなtensionが生まれないことに留意しなければいけない 421 | - 大事なのは、組織がどんな状態になっていればtensionを最小限に抑えられるか考えること 422 | - 状況の変化によって新たなtensionが生じたら、tensionを解消するために組織も変わっていかなければいけない 423 | - 置かれた状況と組織のミスマッチによるtensionを防ぐことがプラクラシーの最大の目的 424 | 425 | ## リーダー交代 426 | （数か月後） 427 | 428 | A男「新人くん元気？」 429 | 430 | A男「ちょっと突然だけどプロジェクトAのリーダーを他の人に任せることになったから、それを共有したくて」 431 | 432 | 新人「え！どうして降格に？何か悪いことしたんですか？」 433 | 434 | A男「降格ではないよ！リーダーはあくまでポジションの1つで、偉いわけじゃないからね。インフラエンジニアがフロントエンジニアになるぐらいの話さ。どっちの方が偉い、とか考えないだろ？」 435 | 436 | 新人「確かに」 437 | 438 | A男「どうしてリーダーをやめるかと言うと、僕はミラクル新規事業チームのメンバーでもあるから、そっちにもう少し時間を使いたくてね」 439 | 440 | 新人「そうなんですね。その場合プロジェクトAのリーダーは不在になるんですか？」 441 | 442 | A男「**チームのリーダーが居ない場合、1つ上のチームのリーダーがそのポジションを担うから、今回の場合は岸田さんが暫定的にプロジェクトAのリーダーだね**」 443 | 444 | 新人「なるほど。岸田さんも開発チームのリーダーをやめた場合は、praha全体のリーダー、つまりCEOがプロジェクトAのリーダーになるってことですね」 445 | 446 | A男「そうそう」 447 | 448 | 新人「だいぶプラクラシーの組織構造がわかってきました。明日から岸田さんがリーダーか〜どんなチームになるんだろう、楽しみだな」 449 | 450 | （翌日） 451 | 452 | 岸田「えーと、いた！新人くん、ちょっとこっち来て」 453 | 454 | 新人「？」 455 | 456 | 岸田「**君をプロジェクトAのリーダーにアサインするから、アサインミーティングやろうか**」 457 | 458 | 新人「へ？僕がリーダーですか？」 459 | 460 | 岸田「うん。A男くんから聞いた推薦理由にも納得感があったし、プロジェクトAのメンバーに聞いても新人くんが良いってことだったからさ。君に決めた」 461 | 462 | 新人「それは光栄です、頑張ります！とは言ったものの、プロジェクトAのリーダーって何をすれば良いんです？」 463 | 464 | 岸田「**それを説明するのがアサインミーティング**だな。早速始めよう」 465 | 466 | ### まとめ 467 | - リーダーが交代することもある 468 | - チームにリーダーが居ない場合、1つ上のチームのリーダーが、リーダーを兼任する 469 | - 誰かをリーダーにアサインするときはアサインミーティングを行なう 470 | - リーダーはポジションの1つなので、昇格や降格という概念は不適当 471 | 472 | ## アサインミーティング 473 | 474 | 岸田「**アサインミーティングは2部構成**だ。まずは**前半でチームの目的を説明するために、背景、OKR、権限などを伝える** 。このチームの概要を振り返ろう」 475 | ``` 476 | ## チーム名 477 | - プロジェクトAの開発 478 | 479 | ## 背景 480 | - 昨年の売上は過去5年で最も伸び幅が少なかった。市場を取り尽くしてしまったことが要因として考えられるため、新たな市場にサービスを提供する必要がある 481 | 482 | ## Objective(目的) 483 | - 関係者と合意した期日までにサービスAの全機能をリリースし、全社売上の5割を超える事業を作ること 484 | 485 | ## 責務 486 | - リリース日を変更する必要が生じたら関係者と合意形成すること 487 | - 合意したSLAをリリース後も満たせるよう運用すること 488 | 489 | ## 権限 490 | - 追加で3名までエンジニア・デザイナーを採用してチームに加える権限 491 | - リリース日を決定する権限 492 | 493 | ## Key Results 494 | - マージできたPRの数(週次) 495 | - 次回リリース予定の機能とリリース予定日(週次) 496 | - 全機能のリリース予定日(月次) 497 | ``` 498 | 岸田「ここに書かれている内容で、理解できないことはある？」 499 | 500 | 新人「ないです。チームのobjectiveとか前々から明文化されていたので」 501 | 502 | 岸田「よし。アサインミーティングの**後半はアサインされた側からの質疑応答の時間だ**。こっちがメインだから、好きなだけ聞きたいことを聞くと良い」 503 | 504 | 新人「じゃあ権限について。エンジニアを増やす権限については言及されていたと思うんですが、減らす権限はありますか？」 505 | 506 | 岸田「ある。Objectiveを達成できていてKey Resultsも順調なら、どれだけの人員でプロジェクトを遂行するかは君が決めていい。他に何か聞きたいことはないか？」 507 | 508 | 新人「では続いてKey Resultsについて。「全機能のリリース予定日」をKRから削除しても良いですか？これまでも滅多に当たることがない不正確な数値だったので、KRとして報告する必要もないと思いまして」 509 | 510 | 岸田「ふむ。**無意味なKey Resultsは削除した方がよさそう**だが、全機能がリリースされるタイミングは知っておきたいな。理由はこの機能のリリースに合わせて盛大にCMを打つ予定だからだ。開始時期を決める情報が欲しい。**何か他の形で有益な情報を出してもらえないか？**」 511 | 512 | 新人「わかりました。どんなKRが適しているかチームとも会話してから提案しても良いですか？」 513 | 514 | 岸田「大丈夫だ。ではKRに関してはこれにて完了。他に何か聞きたいことはないか？」 515 | 516 | 新人「**チームの中をさらに細かく複数のチームに分けて、そのなかでリーダーをアサインしても大丈夫ですか？**」 517 | 518 | 岸田「大丈夫だ。 **それはこのチームに限らずチームリーダーに等しく与えられた権利だ。好きなように細分化してくれ。** 他に何か聞きたいことはないか？」 519 | 520 | 新人「Objectiveに書かれている『全社売上の5割を超える事業』って結構しんどいので、3割に減らすことはできませんか？」 521 | 522 | 岸田「だめだ。5割は死守してほしい」 523 | 524 | 新人「どうしてですか？」 525 | 526 | 岸田「そうだな、ここについては俺も背景を詳しく知らないobjectiveになっていたな。PrAhaのリーダーに理由を聞いて、後日君に共有しよう。他に何か聞きたいことはないか？」 527 | 528 | 新人「いえ、ありません！」 529 | 530 | 岸田「よろしい。ではアサインミーティングは終了だ」 531 | 532 | ### まとめ 533 | - チームのリーダーに誰かをアサインする際は、**必ずアサインミーティングを実施しなければいけない** 534 | - アサインミーティングは、**チームの目的を伝える時間と、質疑応答の時間に分かれた２部構成** 535 | - チームの目的が明文化されていれば前半はアッサリ終わることが多い 536 | - 後半は好きなだけ質問をする 537 | - チームの中をどう分割するかはチームリーダーが決めて良い 538 | 539 | ## リーダーを交代したくなったら？ 540 | 541 | 新人「あ、最後に。リーダーを誰かに譲りたい、あるいは辞めたいと思ったら、いつでも実行して良いんですか？」 542 | 543 | 岸田「時期は君が判断して良い。**このチーム、同じ階層の他チーム、上下のチームに新たなtensionを生じさせない方法とタイミングを君が考えるんだ**」 544 | 545 | 新人「タイミングは自分が決めていいんですね」 546 | 547 | 岸田「ただリーダーをやめる場合、**自分1人で最適な判断を下せるケースはほとんどないと思った方が良い。周りに相談して、意見を集めて、tensionが生まれないことを確認してからやめる**んだ。自分では大したことないと思っていても、周りから見たら影響が大きいことはあるからな。**特に1つ上のチームリーダーには相談した方が良いだろうな**」 548 | 549 | 新人「逆に僕が残りたくてもリーダーではなくなることもあるんでしょうか？」 550 | 551 | 岸田「ありえるな。**1つ上のチームのリーダー**が必要だと判断したら、下のチームのリーダーを代えることもあるだろう。その時は「**今のリーダーのままだとこのようなtensionが生じているから、リーダーを代える必要がある**」といった具合に、どういうtensionを解決するためにリーダーを交代するのか説明した方が良いだろうな」 552 | 553 | 新人「なるほど。チームを新しく作るのはtensionを解決するため、チームを減らすのもtensionを解決するため、リーダーを代えるのもtensionを解決するため。**組織再編で生じるすべての出来事がtensionを解消するために行なわれなければいけない**んですね」 554 | 555 | 岸田「飲み込みが早いな。他に質問はあるか？」 556 | 557 | 新人「いえ、ありません！」 558 | 559 | 岸田「よし。じゃあアサインミーティングは終了だ」 560 | 561 | 新人「いっぱい質問したのに、全部答えてくれてありがとうございます」 562 | 563 | 岸田「**アサインミーティングで質問に答えるのはアサインする側の義務だ。** 気にするな。明日から頼んだぞ」 564 | 565 | 新人「はい！」 566 | 567 | ### まとめ 568 | - リーダーをやめるときは、**同じ階層のチームや上下のチームに新たなtensionを生じさせない方法とタイミング**を考えて、自分で決める 569 | - **最適な方法とタイミングを自分1人で判断できることはほとんどない**。少なくとも1つ上のチームのリーダーには相談した方が良い 570 | - リーダーの任命権は1つ上のチームリーダーが持っているため、時には自分の意思に反してリーダーを交代することもある 571 | - あらゆる組織再編はtensionを解消するために行なわれる 572 | - 質問に答えるのはアサインする側の義務なので、アサインされる側は好きなだけ質問をして構わない 573 | 574 | ## チームにメンバーを増やしたくなったら 575 | （数日後） 576 | 577 | 岸田「調子はどうだリーダー」 578 | 579 | 新人「やばいです。全然タスクが終わりません。リーダー業務に圧倒されて全然実装時間が取れないから、開発スケジュールが押しちゃってます。もう1人メンバーが欲しいですね」 580 | 581 | 岸田「そうか。メンバーを増やせばいいんじゃないか？」 582 | 583 | 新人「確かに、そろそろ増やしても良いかも。でもどうやって増やせばいいんですかね？」 584 | 585 | 岸田「めぼしいやつを見つけたら**声をかけて、承諾されたらアサインミーティングをするだけ**だ」 586 | 587 | 新人「言ってしまえば他のチームから引き抜くってことですかね？」 588 | 589 | 岸田「そういうことになるな」 590 | 591 | 新人「でも、声をかけた人が元々いたチームから、誰もいなくなってしまうこともありますよね？」 592 | 593 | 岸田「それは仕方のないことだ。**そういう状況が起きるからこそ自分のチームを魅力的に保つインセンティブがリーダーに働いて、組織全体の浄化作用が働く**」 594 | 595 | 新人「ひえー、結構シビアですね。誰もいなくなったチームが会社にとってすごく大事だったら、どうするんですか？」 596 | 597 | 岸田「**PrAhaのリーダーが1人でやることになる**だろうな。限界が来たらまた新しいチームを作って、別のリーダーに移譲することになるだろう」 598 | 599 | 新人「すごくダイナミックに組織が統廃合していきますね」 600 | 601 | 岸田「そうだ。絶えず変化する環境に対応するにはそれぐらい組織自体も変わっていかなければいけないからな」 602 | 603 | 新人「じゃあ、チーム間の引き抜きは遠慮なく行なうということで。ところで兼務もありですよね？」 604 | 605 | 岸田「**兼務も可能だ**」 606 | 607 | 新人「引き抜くチームのリーダーと調整する必要はありますか？」 608 | 609 | 岸田「**調整の責務は、まず声をかけられたメンバーにある**。チームを抜けたら、**普通はtensionが発生する**からな。**引き継ぎをする、自分の仕事を自動化する、代わりのメンバーを探す、リーダーに相談する。**こういう行動を通して **tensionの発生を最小限に抑えた上でチームを移動する。** それがスマートな社会人だ」 610 | 611 | 新人「逆にリーダーは何もしなくても良い、ってことですかね？」 612 | 613 | 岸田「そんなことはない。場合によってはチームリーダー同士で移動時期や方法について話し合う必要もあるだろう。想定外のチームが関わることもあるから全体定例会などで情報を周知することも考えた方が良いだろうな。**誰かがチームを移動する場合は、その移動に関連する全員がtensionを最小限に抑えることに注意する必要がある**。プラクラシーの場合は**リーダーのみならずメンバーも注意しなければいけない**、という話だ」 614 | 615 | 新人「そういうことか。メンバーに求める立ち回りが普通の会社よりも多いですね。普通はそういうのは全部リーダーに任せるものだと思ってました」 616 | 617 | 岸田「良いポイントだ。**普通の会社は社員を子供扱いする**。子供に過度な自由を与えると何をしでかすかわからないし、まだ自分の行動に責任を取れない。だから分別ある大人が管理する必要がある、というのが根本的な思想だ」 618 | 619 | 岸田「**プラクラシーでは社員を大人扱いする。大人なら自分がどう動いたら周りのチームにどんな影響が出るか考えられる**し、**自分の行動に責任を取れる**。**自由を与えても適切に扱えるから誰かが管理する必要はない**、というのが根本的な思想だ」 620 | 621 | 新人「そのぶん求められることは多い、ということですね」 622 | 623 | 岸田「その通りだ。だからチームを移動する際も、自分がどう行動すべきかはメンバーが判断するのが基本だ」 624 | 625 | 新人「プラハって自由な社風だな〜と感じていたんですが、周りに配慮することが結構多いですね。思ったより窮屈かも？」 626 | 627 | 岸田「**自由と身勝手は別だからな**。プラハの社員なら**他者の自由を侵害することなく、会社の成長を促進するために自由を適切に扱ってくれる**、という信頼関係が根底にあるんだ。例えばプラハでは就労時間を管理していないだろう？」 628 | 629 | 新人「そういえば確かに。サボろうと思えばいくらでもサボれますよね」 630 | 631 | 岸田「しかし君がサボったら誰かが君の仕事をカバーする必要があるから、 **君の行動が他人の行動を制限する。それはただの身勝手だ。** プラハの社員なら自由と身勝手の違いを理解して行動できる大人であると、会社が君を信頼している」 632 | 633 | 新人「その信頼が裏切られたとしても、プラクラシーを続けるんですか？」 634 | 635 | 岸田「普通は裏切られたタイミングで経営方針を見直して、ルールと管理を増やして、普通の会社に近づいていくのだろうな。だが、たかだか一度や二度の痛みで、**プラハの社員が長い時間をかけて築き上げてきた信頼関係**を壊してしまうのは勿体ないことだと俺は思う。これから入社する人にも、この信頼関係を大事にしてほしい」 636 | 637 | 新人「わかりました。今回の話を踏まえて、1人声をかけてきます！」 638 | 639 | ### まとめ 640 | - チームにメンバーを増やしたくなったら、自由に他のメンバーやリーダーに声をかけて構わない 641 | - チームは兼務することも可能 642 | - **ただしメンバーのチーム移動によって生じるtensionが最小限に保たれるよう、移動に関わる全員が配慮する必要がある** 643 | - **プラハは社員を大人扱いする**。管理されなくても自分の行動に責任をとれることが期待されている 644 | - プラハの社員は自由だが、身勝手ではない 645 | 646 | ## メンバーをチームにアサインする 647 | 新人「あ、福田さーん」 648 | 649 | 福田「はい〜？」 650 | 651 | 新人「先日チームリーダーになったのですが、人手が足りていないからメンバーを増やしたいんです。仕事を手伝っていただけないでしょうか？」 652 | 653 | 福田「アサインミーテイングをしたい、ってことですね。アサインミーティングは基本的に断ることができない行事ですし、大丈夫ですよ！」 654 | 655 | 新人「あ、断っちゃいけないんでしたっけ」 656 | 657 | 福田「話を聞いた結果仕事を引き受けないことはOKなんですが、話をそもそも聞かないのはNGですね」 658 | 659 | 新人「じゃあ遠慮なく！アサインミーティングお願いします！」 660 | 661 | 福田「はい〜」 662 | 663 | 新人「かくかくしかじかでこのようなチームの目的がありまして〜」 664 | 665 | 福田「ふむふむ」 666 | 667 | 新人「つきましては福田さんに手伝っていただきたいと思った次第です」 668 | 669 | 福田「そうですね〜。面白そうですしできることなら引き受けたいのですが、今担当している他の仕事の方が会社にとって重要度が高いと僕は感じました。なので残念ながらお受けできそうにありません」 670 | 671 | 新人「そうですか。残念です」 672 | 673 | 福田「でも断っておしまいだと、人が足りない、という新人さんにとってのtensionが残ったままですよね。自分の周りにもこのチームが人を募集していることを伝えてみましょうか？良い人が手を上げてくれるかもしれません」 674 | 675 | 新人「それはものすごく助かります！ありがとうございます」 676 | 677 | （後日福田さんの声かけに応じた1人とアサインミーティングを実施した結果、メンバーに加わってくれることになった。こうして新人のtensionは解消された） 678 | 679 | ### まとめ 680 | - チームに誰かを誘う際はアサインミーティングを実施する 681 | - アサインミーティングの結果、仕事を引き受けないことはOK 682 | - **アサインミーティング自体を断るのはNG** 683 | - **仕事を断った場合はtensionがそのまま残ってしまう**ため、可能な限りその解消にむけて協力する 684 | 685 | ## チームが生まれないケース 686 | 新人「うーん、最近ちょっとプロジェクトの進捗が遅れがちだなあ」 687 | 688 | B男「あ、新人さんのプロジェクトAもですか？」 689 | 690 | 新人「あ、BプロジェクトのB男さん。似た課題を抱えていますね」 691 | 692 | B男「弊社はプロジェクトマネジメントに関する知見が不足していますからね。その辺りに専門知識を持った人が横断でプロジェクトマネジメントを担っても良いのではないでしょうか？」 693 | 694 | 新人「それは確かにいいアイデアですね！すぐ新しいチームを作りましょう！開発チームと同列に位置付けた方が良いだろうから、これはPrAhaのリーダーに相談してきます」 695 | 696 | B男「お願いします！」 697 | 698 | （数時間後） 699 | 700 | PrAhaリーダー「どうもPrAhaリーダーです」 701 | 702 | 新人「かくかくしかじかでプロジェクトマネジメントチームを作りたいのですがいかがでしょう？」 703 | 704 | PrAhaリーダー「なるほど。**解決したいtensionは何でしたっけ？**」 705 | 706 | 新人「プロジェクトの進捗が当初予定より遅れがちなことです」 707 | 708 | PrAhaリーダー「率直な感想ですが、**新しいチームを作らなくても解決できる**問題に聞こえますね。開発チームの岸田さんは何て言っていましたか？」 709 | 710 | 新人「いえ、岸田さんには何も聞いていません。PMチームを作るとしたら開発チームと同じ階層になると考えたので、開発チームの1つ上のチームであるPrAhaリーダーに相談しようと考えました」 711 | 712 | PrAhaリーダー「そういうことでしたか。ただ残念ながら私は各チームの細部までは把握していないので、今回の新チーム設立に関しては判断できそうにありませんね」 713 | 714 | 新人「あれ、そうなんですか！一番上のチームのリーダーって、言ってしまえば社長ですよね。社長ならなんでも判断できると思っていました」 715 | 716 | PrAhaリーダー「確かに僕は便宜上この法人の社長ですが、それはあくまで日本で会社として認められるためにやっているだけなんですね。**社長であろうと、皆さんと同じルールのもとで動いています**。ですから僕も他のチームのリーダー同様、1つ下のチームまでしか影響を及ぼせません。例えば直下の開発チームをなくす、みたいな決断なら下せるのですが、開発チームのさらに1つ下のチームのことまで具体的に決める権利は、僕にもありません」 717 | 718 | 新人「もしプロジェクトAの開発をこうしたい！と社長が考えて、それに岸田さんがずっと反対していたらどうするんですか？」 719 | 720 | PrAhaリーダー「そこまで反対されるということは、岸田さんが持っている大切な情報を僕が持っていないことを示唆しています。ですから僕は岸田さんと話し合い、お互いの情報と見解を共有しながらお互いが合意できる結論を出すのがベストですね」 721 | 722 | 新人「話が全然まとまらなかったらどうするんですか？」 723 | 724 | PrAhaリーダー「最終手段としては、開発チームのリーダーを他の人に譲ってもらうことになるでしょうね。**リーダーの任命権は1つ上のチームのリーダーにありますから**」 725 | 726 | 新人「なるほど、プラクラシーにおいては全員がルールの上に平等に存在していて特別扱いされる人はいないということですね」 727 | 728 | PrAhaリーダー「そうなりますね」 729 | 730 | 新人「ありがとうございます。おっと、話が脱線してしまった。何の話をしてましたっけ」 731 | 732 | PrAhaリーダー「PMチームを新しく作りたいけれど僕では判断できないという話でしたね」 733 | 734 | 新人「あ、そうだった。困ったな、どうしよう？」 735 | 736 | PrAhaリーダー「**今回のチーム追加が誰に影響を与えそうか**僕から提案しましょうか。今までプロジェクトマネジメントは各開発チームが担当していましたから、開発チームリーダーの岸田さんは会話に参加した方が良いでしょうね。クライアントに対する説明責任を持っている営業チームも影響を受けると思います。オンボーディングチームも影響を受けそうです。思い当たるのはこれぐらいかな」 737 | 738 | 新人「そしたら、ひとまず全社のSlackで今回の新チームについて意見を募って、今教えていただいた関係者を集めて協議してから、また相談しますね」 739 | 740 | PrAhaリーダー「はい、お願いします！」 741 | 742 | （数日後） 743 | 744 | 新人「B男さん、お疲れ様です」 745 | 746 | B男「お疲れ様です！Slackみましたよ、結構いろんな意見が集まっていましたね」 747 | 748 | 新人「諸々の意見と協議した結果、今回は新しいチームを作らないことになりました。残念です」 749 | 750 | B男「そんなに落ち込まないでください！確かに当初の提案は新しいチームを作ることでしたが、より良い解決策に落ち着いたのであれば、それはそれで良いのではないでしょうか？」 751 | 752 | 新人「そうか、**目的はtensionを解消することで、新しいチームを作ることではない**ですもんね」 753 | 754 | B男「そうですそうです。**常に「これは何のtensionを解決しようとしているのか」と考え続ける**のがプラクラシーのコツだと以前僕も教わりました」 755 | 756 | 新人「なるほどな〜。僕も明日からそれを意識してみます！」 757 | 758 | ### まとめ 759 | - チームリーダーの任命権は、1つ上のチームのリーダーが持っている 760 | - tensionを常に意識する。新しいチームを作ることがtensionを解決するための最適解とは限らない 761 | - 新しいチームを作るときは、誰が影響を受けるのか検討しなければいけない 762 | - 社長だからと言って特別扱いされることはなく、他のチームリーダーと同じ役割や権利を持ち、プラクラシーのルールに則って動く --------------------------------------------------------------------------------