擬似言語は実務で役に立つ?現場のコードとの共通点を解説
擬似言語って、試験が終わったら二度と使わないんじゃないの?
勉強しながら、ふとそう思ったことはありませんか?
実際の現場で擬似言語そのものを書くことは、まずありません。それなら覚えても意味がないのでは、と感じるのは自然なことです。
私はエンジニアとして10年以上、Webシステムの開発や運用に携わってきました。その経験から言うと、擬似言語で身につく力のうち、かなりの部分は現場でもそのまま使えます。
一方で、擬似言語だけでは仕事にならない部分があるのも事実です。この記事では、役に立つところと、別に学ぶ必要があるところを、誇張せずに切り分けてお伝えします。
そもそも科目Bで擬似言語がどう問われるのかを先に確かめたい人は、親記事で全体像をつかんでおくと、この先の話がつながりやすくなります。
【関連記事】基本情報技術者試験の科目Bとは?擬似言語・アルゴリズム対策を初心者向けに解説
擬似言語と現場のコードの関係¶
まず、擬似言語と実際のプログラミング言語がどんな関係にあるのかを整理しておきましょう。ここがあいまいなままだと、役に立つかどうかの判断もぶれてしまいます。
擬似言語は、特定の言語の書き方に左右されずに、処理の手順だけを表すための書き方です。現場で使う言語は Java、Python、PHP、JavaScript などさまざまですが、どれも中身は同じ部品でできています。
その部品とは、値を覚えておく変数、同じ処理を繰り返すループ、条件で道を分ける分岐、処理をひとまとめにする関数の4つです。擬似言語は、この4つを日本語に近い形で書いたものだと考えてください。
言語ごとの見た目の違いが気になる人は、Pythonと並べて対応を確かめたこちらの記事を読むと、書き方が変わっても中身は同じだと実感できます。
【関連記事】擬似言語はPythonにそっくり?対応表で見ると一気に読めるようになる話
同じ処理を並べて比べてみる¶
具体例で確かめてみましょう。ネットショップでよくある、注文の合計金額を出して、一定額未満なら送料を足す処理です。
まず擬似言語で書くと、次のようになります。IPAの公開問題ではなく、実務の処理をもとに作った例です。
○整数型: calcTotal(整数型の配列: prices, 整数型の配列: counts)
整数型: i
整数型: total ← 0
for (i を 1 から pricesの要素数 まで 1 ずつ増やす)
total ← total + prices[i] × counts[i]
endfor
if (total < 5000)
total ← total + 500
endif
return total
同じ処理を Python で書くと、次のような形になります。
def calc_total(prices, counts):
total = 0
for i in range(len(prices)):
total = total + prices[i] * counts[i]
if total < 5000:
total = total + 500
return total
記号や添字の始まりは違いますが、流れは1行ずつきれいに対応しています。合計用の変数を 0 で用意し、ループで足し込み、条件で送料を足して返す、という手順はまったく同じです。
現場のコードには、この形の処理が本当にたくさん出てきます。売上の集計、在庫数のチェック、ポイントの計算など、中身をほどいていくと、科目Bで練習した集計や分岐の組み合わせになっていることがほとんどです。
擬似言語で身につく力が実務で役立つ場面¶
では、擬似言語の勉強で身につく力は、現場のどんな場面で生きるのでしょうか。私が実際の仕事で役立つと感じている場面を、表にまとめてみます。
| 擬似言語で練習すること | 実務で役立つ場面 |
|---|---|
| 変数の値を1行ずつ追うトレース | 不具合の原因を探すデバッグ |
| 他人が書いたコードを読んで答えを出す | 既存システムの改修やコードレビュー |
| ループの回数や境界の値を確かめる | 最初や最後の1件だけずれる不具合の予防 |
| 合計・最大値・件数などの集計 | 売上やアクセス数の集計処理 |
| 手続や関数の引数と戻り値を読む | 部品化された処理の使い方を理解する |
| 空欄に入る処理を推測する | 仕様から足りない処理を考える設計 |
どれも地味に見えますが、現場で毎日のように使う力です。特に上の2つは、経験年数に関係なく求められます。
コードを読む時間は書く時間より長い¶
現場に入って驚くことの一つが、コードを書くより読む時間のほうが長いということです。新しく作るより、すでにあるシステムを直したり機能を足したりする仕事のほうが多いからです。
私も新しい案件に入るたびに、まず既存のコードを読んで、どの変数がどこで変わるのかを追うところから始めてきました。他人の書いた処理を正確に読む力は、科目Bで問われている力とほぼ同じです。
科目Bの問題は、他人が書いたコードを読んで、実行結果や空欄を答える形式が中心です。つまり試験勉強そのものが、現場で一番よく使う読む力の練習になっています。
トレースはそのままデバッグになる¶
不具合が起きたとき、エンジニアがやることは意外と地道です。怪しい場所に目星を付け、変数の値を1つずつ確かめて、想定とずれた場所を探します。
これは、擬似言語で書くトレース表とまったく同じ作業です。現場では値を画面やログに出して確かめますが、頭の中で予想を立ててから確かめる、という手順は変わりません。
トレース表を書く習慣がまだ身についていない人は、書き方の手順をまとめたこちらの記事で基本を固めておくと、試験にも仕事にも効いてきます。
【関連記事】擬似言語のトレース表の書き方|科目Bで変数の値を追う手順を解説
境界の確認は不具合の予防になる¶
先ほどの送料の例で、条件が total < 5000 なのか total ≦ 5000 なのかで、ちょうど5000円の注文だけ結果が変わります。科目Bでも、この境目の値を問う問題はよく見かけます。
現場でも、この境目の間違いはとても多い不具合です。私自身、条件の記号を1つ取り違えて、境目の金額のときだけ計算がずれる不具合をテストで見つけたことがあります。
ループの最初と最後、条件のちょうど境目を確かめる癖は、擬似言語の練習で自然に身につきます。この癖があるだけで、防げる不具合はぐっと増えます。
現場のコードに出てくる科目Bの型¶
もう少し具体的に、現場のどんな処理が科目Bの型と重なるのかを見ていきましょう。名前は違っても、骨組みは試験で見たものとそっくりです。
私がこれまでの仕事で繰り返し書いてきた処理と、科目Bでの呼び方を対応させると、次のようになります。
| 現場でよく書く処理 | 科目Bでの型 |
|---|---|
| 会員一覧から条件に合う人を数える | 件数を数える集計 |
| 注文の中に在庫切れの商品があるか調べる | 線形探索とフラグ変数 |
| 売上の一番多い日を探す | 最大値を求める処理 |
| 一覧を日付や金額の順に並べ替える | 整列(ソート) |
| 入力された文字列の形式を確かめる | 文字列を1文字ずつ調べる処理 |
もちろん現場では、並べ替えや検索は言語に用意された機能を呼び出すことが多いです。それでも、中で何が起きているかを知っていると、遅いときや結果がおかしいときに原因の見当が付けやすくなります。
在庫チェックを擬似言語で書いてみる¶
表の2行目にある、在庫切れの商品があるかを調べる処理を擬似言語で書いてみます。これも実務の処理をもとに作った例です。
○論理型: hasSoldOut(整数型の配列: stocks)
整数型: i
論理型: found ← false
i ← 1
while ((i ≦ stocksの要素数) and (found が false と等しい))
if (stocks[i] が 0 と等しい)
found ← true
endif
i ← i + 1
endwhile
return found
見つかった時点でループを抜けるので、商品が何千件あっても、先頭の近くに在庫切れがあればすぐに終わります。科目Bの探索問題で見る形と、そのまま同じですね。
現場のコードレビューでは、見つかったあとも最後まで回り続けていないか、という点をよく指摘します。試験で身につけた、ループがいつ終わるのかを確かめる目は、こうした場面でそのまま役に立ちます。
実務では別に学ぶ必要があること¶
ここまで役に立つ面を見てきましたが、擬似言語だけで仕事ができるわけではありません。正直に、足りない部分も整理しておきます。
現場で必要になるのに、擬似言語の勉強ではほとんど触れないものを表にまとめました。
| 実務で必要なこと | 擬似言語との関係 |
|---|---|
| 特定の言語の文法と書き方の作法 | 考え方は共通だが、細かい書き方は言語ごとに覚える |
| ライブラリやフレームワークの使い方 | 擬似言語には出てこない。現場で使うものを個別に学ぶ |
| データベースの操作 | 科目AのSQLの知識とつながるが、実際の操作は別に練習する |
| バージョン管理やチームでの開発の流れ | 擬似言語とは関係なく、現場で身につけることが多い |
| 大量のデータや速さへの配慮 | 計算量の考え方はつながるが、実際の調整は経験で覚える |
こうして並べると、覚えることの多さに不安になるかもしれません。でも、上の表はどれも、読む力と手順を組み立てる力があって初めて身につくものです。
言語の文法やフレームワークは、土台があれば後からいくらでも覚えられます。逆に、土台がないまま書き方だけを覚えると、少し形が変わった途端に手が止まってしまいます。
擬似言語を学んだあとに現場へつなぐ順番¶
試験に合格したあと、実務へつなげるなら次の順番がおすすめです。まずは興味のある言語を1つ選び、擬似言語で解いた問題をその言語で書き直してみてください。
慣れてきたら、合計や検索のような小さな処理を自分で作り、わざと境目の値を入れて動きを確かめます。最後に、小さなアプリを1つ作ってみると、ライブラリやデータベースの使い方が自然と必要になって身につきます。
試験勉強を仕事の力に変える学び方¶
同じ擬似言語の勉強でも、やり方次第で実務につながる度合いが変わります。ここでは、試験対策をしながら仕事の力も伸ばせる学び方を紹介します。
一番大事なのは、答えを当てることより、なぜその答えになるのかを説明できるようにすることです。選択肢を消去法で選べても、処理の流れを説明できなければ、現場のコードは読めません。
答えが合わなかったときに、どこで考えがずれたのかを探す練習も効果的です。値がずれた場所を見つける手順は、そのまま現場のデバッグの手順になります。
答えが合わないときの切り分け方は、こちらの記事で具体的な手順として解説しています。
【関連記事】擬似言語の答えが合わないときの直し方|値がずれた場所の探し方
1問ごとに処理を一言で説明してみる¶
問題を解き終えたら、そのコードが何をしているのかを一言で言ってみてください。たとえば、在庫が0の商品を先頭から探して、見つかったら止める処理、という具合です。
この一言が言えるかどうかが、実務で通用する読み方ができているかの目安になります。現場では、コードの意図を短く説明する場面がとても多いからです。
私も後輩のコードを確認するときは、まず何をする処理なのかを一言で説明してもらいます。それが言えないときは、たいてい本人もどこかで流れを見失っています。
逆に、処理を一言で言えるようになると、長いコードでも迷わなくなります。どこが本筋で、どこが細かい調整なのかを見分けられるようになるからです。
試験でも同じで、説明できる問題は、少し形を変えて出題されても解けます。暗記した答えではなく、理解した流れが手元に残るからです。
シミュレーターで動かして確かめる¶
紙の上で考えたら、実際に動かして確かめる。この往復は、現場のエンジニアが毎日やっていることです。
Giji Academyの擬似言語シミュレーターでは、擬似言語のコードを1行ずつ動かし、変数や配列の値が変わる様子を見ることができます。自分の予想と実際の動きを比べる練習は、そのまま現場で動作を確かめる力になります。
おすすめは、この記事の送料の例のように、境目の値を入れて試すことです。4999、5000、5001 と入れて、送料が付くかどうかを予想してから動かしてみてください。
予想どおりに動けば自信になり、ずれればそこが学びになります。まずはGiji Academyの擬似言語シミュレーターから、集計や条件分岐の講座を選んで試してみてください。
まとめ¶
擬似言語そのものを現場で書くことはほとんどありません。それでも、変数・ループ・分岐・関数という中身は、どの言語のコードとも共通しています。
特に、他人のコードを読む力、値を1行ずつ追う力、境目を確かめる癖は、現場で毎日のように使う力です。科目Bの勉強は、その練習をしていることになります。
一方で、特定の言語の書き方、フレームワーク、データベース、チーム開発の流れは、実務に入ってから別に学ぶ必要があります。擬似言語は、それらを身につけるための土台だと考えてください。
試験のためだけと思うと勉強はつらくなりますが、仕事の土台づくりだと思えば、1問1問に意味が見えてきます。今日の1問が、未来の現場で必ず生きてきますよ。