Paiza スキルチェックとは？
公式の「paizaとは？」がこちら。
paiza転職とは？ | ITエンジニア向け転職・就活・学習サービス【paiza】
で、スキルチェックのランクに関してはこっちのガイドページに詳細が載ってます。
paiza転職とは？ | ITエンジニア向け転職・就活・学習サービス【paiza】
以下、引用して軽く纏めます。
引用：ランクと分布（paiza調べ）
上記図を表にまとめてみた。
| ランク | ％ | コメント |
|---|---|---|
| Ｓ | 2％ | 非常に高いスキルを持っています。 |
| Ａ | 8％ | 高いスキルを持っています。 |
| Ｂ | 30％ | 一定基準以上のスキルを持っています。 |
| Ｃ | 60％ | 基本的なスキルは十分、効率的なコードを意識しましょう。 |
| Ｄ | - | - |
引用：出題レベルと目安
★☆☆ 初級 ・・・データ出力系の基本的な実装ができる。
内容
if,for,while,foreach,変数、配列、連想配列、文字列操作、ソートを使って指示通りのプログラムを書けるか。回答スピード、正確性が問われる。
業務レベル
業務システム、Webアプリケーションの運用保守、一部開発ができる。
★★☆ 中級 ・・・計算量を意識した効率的なロジックを組み立てられる。
内容
指示通りにロジックを組むだけでなく、自分で効率的なロジックを考えだせるか。またツリー構造、探索等を使いアルゴリズムを組めるか。
業務レベル
業務システム、Webアプリケーションの開発をリードできる。
★★★ 上級 ・・・より良いアルゴリズムを設計、実装できる。
内容
O(n²)⇒O(n)の様な計算量、メモリの削減を意識した高度なアルゴリズムが組めるか。問題によっては数学的(確率計算)問題についても問う。
業務レベル
検索エンジン、データ解析、レコメンデーションエンジン、広告配信、大規模ユーザー管理などパフォーマンスが要求される開発や運用、イノベーティブな開発分野に取り組める。
■ 専門領域 ■ ・・・専門領域の研究、開発ができる。（Ｓランクのみ）
内容
確率、統計解析、形態素解析、機械学習、グラフィック、ゲーム木、検索等の専門分野の課題が解けるか。
業務レベル
各専門領域での即戦力。
取り敢えずＳランク取ってみた
先日のブログにも書いた通り、
- Ｓランク取った上で批評した方がっかこいい
- Ｓランク取らずに批評しても説得力が無い
と思ったので、何はさておきサクッとＳランク取ってみました。
各レベルの問題を解いた感想。
ランクＤの問題
問題じゃなくてチュートリアル。
言語の基本構文と、標準入出力の扱い方が解っていれば正答出来るレベル。
問題のレベルとしてはもはや「解く」というレベルではない、アプリの使い方というか問題の解答方法を確認する為のチュートリアルといった印象。
ランクＣの問題
未経験の学生向け学習教材。
言語の基本構文と基本的な標準ライブラリの知識があり、問題文の日本語が理解できれば正答出来るレベル。
まだこれも「解く」というレベルではない。
ランクＢの問題
まぁ、普通。
印象：
これが解けないようでは職業エンジニアを名乗るのはどうかと思う、というレベル。
未経験の新卒新人がまず一年目にクリアを目指すレベルじゃないかな。
レベル感：
中途の転職者（いわゆる即戦力）では、一種の足切りラインと考えて良いのではないかと思う。
ランクＡの問題
この辺から、解くのに時間か頭を多少要するようになってくる。
印象：
ランクＢ以下の問題は別に10分20分でササッとコード書けるが、ランクＡ以上となるとそんな「隙間時間」では解けない感じ。
小一時間は最低限必須のレベルになって来るので、まとまった時間が無いとそもそもチャレンジ出来ないレベルになってる。
まぁでもこの辺のレベルじゃないと「解く」というレベルとは言えないので、ある意味ではここからが本題。
レベル感：
「要件の読解」と「解法の検討」に少し時間を要するようになり、漸く問題らしい問題になって来たかな、って感じ。
コーディングに関しても、ノーミスで一気に完成形まで行ける事はたぶん稀で、ある程度試行錯誤が出て来ると思う。
エンジニアとしてプロを名乗るなら最低限このレベルの問題が解けなきゃ業務開発なんて出来ないと思われる。
ランクＳの問題
まー、時間が掛かるｗｗ
何て言うの、シス開午後問の疑似言語、ってかんじ？
難しいと言うよりめんどくさいって感じ。
印象：
言語構文や標準ライブラリの知識だけでは高スコアを取るのは難しく、それ以外にアルゴリズムの知識があると有利になる問題が増えている気がする。
ぼくが解いた「経路探索」なんかはこの好例かも知れない。
（言うて、大した頭のいいアルゴリズムが要求された訳じゃなく、問題を読解して愚直に機械的に処理組んでも正当出来る類の問題だったけど）
レベル感：
ある意味、ランクＡと純粋な意味での「問題の難しさ」としては大して変わらないと思う。
ただ、難易度ではなくて、知識ベクトルが何かしらのジャンルに特化した問題として進化してるようなイメージ。
単純な簡単・難しいというレベルから、ジャンル的に得意・不得意というベクトルに変わって来ている感じ。
そういう意味で、「Ｓランク問題のどれか一つを解ける」というのなら敷居はかなり低いが、「Ｓランクレベルの問題をコンスタントに解ける」だと相当にハードルが上がる。
所感：
正直、そこそこ難しかった。
Ｓランク問題を「簡単だった」と言える人は本当に優秀なエンジニアか、単純に地頭が良いかだろうねぇ。 とあるブログでは「頭が良いか性格が悪いかのどちらか」と言う、なかなか痛烈な表現があった。
またとあるブログでは「if文とfor文が書ければ解けた」と言い切ってる人もいたｗ
人によってＳランクへの評価はかなり別れてるなぁ。
総評
Ｓランクが「専門領域」として「初級・中級・上級」とはなんか別枠で記載されていたのはある意味納得。
まともなレベルのエンジニアとしてはＡランクがコンスタントに解ければ取り敢えず良いんじゃないかな、と思った。 逆に、Ａランク程度が解けた所で別に何も凄くないんで、エンジニアの転職のアピールポイントとしては弱いと思った。
上の方でも記載したけど、Ｂランク以下は足切りと考えて良いと思う。
かわりに、Ｓランク問題で幾つかハイスコア取ったり、トップランキングに入賞とかしてれば、単純なコーディングスキルに関してはかなり自慢できるレベルじゃないかなとは思う。
ただこれも前述した通り、「Ｓランクになる」のと、「Ｓランクレベルの問題をコンスタントに解ける」というのは、雲泥の差だからそこはキッチリ区別する必要があると思う。
Paiza スキルチェックについて思う事。
漸く本題。
取り敢えず、ぼくが実際にコーディングスキルチェックを受けて、Ｓランク取ってみて思った事。
Ｓランク２％はどう考えても嘘だと思う。
いくらなんでも少な過ぎる、、、。
確かにＳランク問題は手応えがあったが、 別に何問もクリアする必要がある訳じゃなく、一回で良いからＳランク問題をクリアすれば良いのだから、Ｓランクに上がる条件はかなり易しいと言える。 しかも、一度上がったランクは下がる事が無いという仕様、これだけユルい条件でＳランカーが２％しかいない訳がない。
Ｓランク問題全クリした人が２％、と言うのであれば納得する。
競技プログラミングの宿命。
いわゆる競技プログラミングの形態である為、どうしてもスピード重視の雑な実装になってしまいがち。 これで「コーディングスキルを測る」と言うのはちょっと疑問が残る。
本来であれば、一旦動作確認が終わった段階とかで綺麗にリファクタリングして、 場合によっては抽象化設計して部品化・共通化を検討して、、、。 と言った、実務開発に必要なスキルの真逆を行ってしまうのが気に食わない。
回答時間加点に関しては配分を考え直した方が良いような気がする。
（実際問題、コードの読み易さとか、変数名の解り易さ、処理の見通しの良さなんかは後半どうでも良くなって、とにかくスピード重視で組むだけ組んでテスト通した感があるが、実務でこんな事やられたら激怒する）
リファクタリングフェーズを設けてはどうか
上記、時間加点問題に対する改善案。
現在の回答送信を「一次提出」とし、これには「回答時間」及び「テストコード通過」の２つの観点で加点する、ここまでは現状通り。
テストを通過し基準点を満たしてから「正式提出」の前に「リファクタリングフェーズ」を設けて、提出したコードをリファクタリングし、テストコードを回数無限で流し放題にするのはどうか。
自分で納得のいくまでリファクタリングを行って「これでリポジトリにコミット掛けるぜ！」と胸を張れる状態になってからコードを提出する。
これなら、現状の「いかに正確に、早く要求事項を満たしたコードを書けるか」と言うスキルと、 リファクタリングによって「既存のコードをより良いコードに整理・改善できるか」と言うスキル、両面で評価する事ができる。
（そして、個人的にはリファクタリングスキルこそプログラマにとって非常に重要なスキルの一つだと思ってる）
本当に「コーディング」のみのスキルしか測れない
これはもう、仕方ない事なので言うだけ野暮って気もするが、、、。
システム開発に必要なスキルは、コーディングだけではない。
- 顧客との折衝、要件定義、仕様調整。
- タスクの細分化、進捗管理。
- 言語だけでなく、フレームワーク、ライブラリ、サードパーティ製品の知識
- クラス設計、単純責任原則に則った適切な分割。
- 処理の共通化、部品化設計。
- テスト設計、テストコード実装。
などなど。。。
コーディングだけを評価して年収おいくら、なんて言ってても、なんかあまり説得力を感じない。
無論、コーディングスキルは最も下の土台となる重要なレイヤであるが、それを測るＳランク問題がアレではそれも推して知るべし、って感じ。
前述の通り、あるレベル「以下」に対する足切りとしては機能すると思うが、あるレベル「以上」の優秀なエンジニアを見付ける指標にはならなさそうだなぁ、と思った。
（そういう使い方をするのであれば良いと思う）
初期学習にちょうど良い
ぶっちゃけ、別に転職用途としては大して利点を感じなかった。
かわりに、新しい言語を始めたとか、学生が就職活動の一環として勉強に使うとか、専門学校生が資格試験対策に利用するとか、そういう用途には凄く良いと感じた。
カバーしている言語が多く、それら全てでREPL的なサービスが使えると言うのは、オンラインの学習環境として非常に秀逸だと思う。
IDEの支援こそ貧弱になるので不便ではあるものの、各言語の開発環境・実行環境をローカルにいちいち作る必要が無い、どころか何もインストールする必要がない、と言うのはとても魅力的。
転職者が得意な言語だけで問題を解いていくと言う使い方ではなく、むしろ不慣れな言語で積極的にコードを書く為の環境として利用するのが効果的じゃないかと感じた。（しかも簡単な問題集と採点テスト付き）
学習中の言語でＢ～Ｃくらいのレベルの問題を沢山解いて、仕上げにＡランクを幾つかクリアする、みたいな。 この場合、Ｓランクを解く必要は無い。 Ｓランクは、特定のアルゴリズムを知っているか否か（或いは、思い至るか否か、調べられるか否か）と言う領域の問題が多く、「言語のスキル」とはまた別な所にある気がした。
【番外編】過去の某炎上ブログに関して思った事。
何年か前の記事だけど、とあるＰＭを名乗る方がブログでpaizaに関して批判（と言う程でもなかったけど）して炎上した、と言う事があったそうです。
確かに技術軽視（もっと言うと技術「者」軽視）の発言が目について、こりゃあ反感を買うだろうなぁ、と思う記事であったが、そういう感情的な部分に目を瞑れば言っている事は割と間違ってないと感じた。
ただ、ぼくとしても記事を読んだとき「コーダー」と言う表現を見て、ああこいつは腹の中では技術者をただのキーパンチャーとして見下してるんだな、と感じた。
そもそも、
- ＳＥ様が頭を使って設計書を作る
- ＰＧ君は作られた設計書に従って脳死でコードに落とし込む
なんてのはCOBOLかなんかの相当古い時代、それこそ「コンパイル一回いくら」とか「コード一行いくら」とか言ってた時代の話であって、ハッキリ言って時代錯誤も良い所だと思うんだ。
エンジニアとしての価値提供にはコーディングスキル以外にも必要なスキルはたくさんある、その主張自体は正しいと思うしぼくも同じ意見。
ただ、技術者（プログラマ）と言うものを蔑み過ぎなんじゃないかなぁと思いました。
