~Aperport機能紹介：発注会社として使用するプロジェクト登録機能~
本記事ではAperport（アペルポート）の開発プロジェクトの登録機能の概要と、画面設計および機能設計の意図・背景をお伝えします。
プロジェクト情報は以下の３つの目的のために登録をします。
①プロジェクト情報に基づく検索
②マッチング度の計算
②実際に商談を行う相手に情報を伝達するため
目次
プロジェクトの構成
プロジェクトの基本情報の項目
主要勤務地
最寄り駅
働き方
案件化状況
案件の特徴
募集ポジション
役割
技術
ドメイン知識
人月単価
その他勤務条件
プロジェクト情報は、
の二つに分かれています。
したがって、はじめに「プロジェクトの基本情報」を登録し、その後に別の画面で「募集ポジション」の情報を登録する形になります。
このような構成とした理由は、「体制検索」を実現するためです。
１つのプロジェクトに対してN個の募集ポジションがぶら下がる形にすることで、１つのプロジェクトを選択していただければ、すべての募集ポジションの要件を考慮して、もっともマッチング度の高いエンジニアを複数名以上提案できるパートナーを探すことができるようになります。
参考）体制検索画面
上記の項目の内、エンジニアの検索の際に考慮されるのは「主要勤務地」（都道府県）の情報のみです。現在はリモートワークも拡がっており、場所を問わず募集するケースもでていますが、いざというときに事務所に出勤できる必要もあることから、プロジェクトの主要勤務地が属する都道府県と隣接する都道府県に住んでいるエンジニアを検索結果で出せるようにしています。（対象を全国にすることも可能です。）
最寄り駅については、ユーザー顧客を推測できてしまうおそれがあるため、任意項目としています。ただし、Aperportにおいては現在発注側がエンジニアを検索できるものの、受注側は案件の検索はできない仕組みになっており、実際に取引関係のない会社に最寄り駅情報が伝わってしまうことはありません。マッチング度の高いエンジニアが所属しており、商談をパートナー会社に申し込んだときにはじめて最寄り駅の情報が開示されます。
働き方については、リモートか出勤が必要かという大まかな区分がありますが、Aperportでは発注会社の管理者にとってどのような勤務形態であれば管理しやすいか、という視点で選択肢を設けています。
現在はエンジニア側もリモートを希望するケースが増えており、マッチング度の計算において考慮することも検討しましたが、スキルそのものと直接関係がなく、あくまでも「管理」上の問題であることから、受注会社の営業に最後は提案の是非を判断してもらうための要素として扱っています。
したがって、管理者としては、以下のような管理のしやすさの観点で選んでいただく想定です。
|
リモートのみ・推奨 |
すでにリモート作業でのマネジメントが成熟しており、管理者も含め皆リモートの方が都合が良い場合 |
|
リモート中心＋少し出勤 |
原則はリモートだが、リリース時や定例会はより慎重なコミュニケーションをすべきと判断し、柔軟に出勤もして欲しい場合 |
|
出勤中心＋少しリモート |
原則は出勤で偶発的なコミュニケーションを起こしていくことが望ましいが、エンジニアが希望する場合には週に１－２日リモートも許可できる場合 |
|
出勤のみ・推奨 |
原則は出勤のみでよほどの理由がない限りリモートが認められず、仮に一時的にリモート対応を可能としていても近い将来出勤のみとなる可能性が高い場合 |
なお、エンジニアが利用するExperportにおいては、「オフィス環境の好み」を自由記述で任意登録できるようになっており、Aperport上でこちらを確認することができます。したがって、発注側は商談を依頼するかどうかの判断材料とすることができます。
案件化状況はおもに既存のパートナーとの間のコミュニケーションをスムーズにするために設けられています。案件がまだ固まっていないものの、募集人数が多かったり、募集スキルが稀少であるために容易にみつからない可能性が高い場合に、案件確度が低いことを前提に３－６か月先を見据えて商談できる相手を探すために、商談前の事前シグナルとして活用していただけます。これにより実際に商談をしてみたら、翌月の案件ではないので提案できません、といった期待外れの状況を防ぐことができ、調達側も従来よりも気軽により多くの既存パートナーに声掛けをすることができるようになります。
案件の特徴は、それぞれの案件ごとに要求されるソフトスキルを意識して選択肢を用意しています。開発プロジェクトは、顧客ユーザーの組織文化や、開発領域によって、開発に参加するメンバーに求められるコミュニケーションの仕方や立ち居振る舞い方が変わってきます。プロジェクト毎に、明確なビジョンやミッションまでは定義されていなくとも、実際にそのプロジェクトが重視している価値はあるため、それを可視化することができます。
この情報は商談が実際に行われる相手にのみ開示され、受注会社の営業担当が個々のエンジニアをアサインする際の重要な参考情報となります。
募集ポジションごとに役割・技術・ドメイン知識の他、人数・単価・時期・就業時間・清算方法などを設定することができます。これらはプロジェクト全体で同じだとは限らないことから、募集ポジションおよび各パートナー会社との交渉次第で変わりうる情報になるため、個別に柔軟に設定できるようになっています。
このうち、役割・技術・ドメイン知識・単価の４点については、エンジニア検索や体制検索機能において、マッチング度を計算する際に使用されます。
役割については、１つの募集ポジションにつき、複数の役割を工程ごとに設定できます。
|
業務SE |
要件定義 |
|
外部設計 |
|
|
総合試験 |
|
|
運用保守 |
|
|
プログラマー |
内部設計 |
|
製造 |
|
|
単体試験 |
|
|
結合試験 |
|
|
運用保守 |
|
|
（以下、省略） |
|
その他、就業時間や、就業時間外勤務の有無、精算方法などについての情報を登録し受注会社の営業に伝えることができます。