【イベントレポート】パズルを解いてプログラミング的思考力や課題解決力を養おう

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

12月21日のクリスマス前に開催されたイベントはその名も「クリスマスなのに（？）パズルを解いてエンジニア力をアップしよう」。このイベントのために作られたオリジナルのパズルをワーク形式で解いていきます。

パソコンを持参して、ソースコードを書いたり、インターネットで調べ物をしたりしながら、問題を解いていきました。ぜひ記事を読みながら、パズルに挑戦してみてくださいね。

▲【講 師】増井敏克さん
増井技術士事務所代表。技術士(情報工学部門)。情報処理技術者試験にも多数合格。ITエンジニアのための実務スキル評価サービス「CodeIQ」にて、アルゴリズムや情報セキュリティに関する問題を多数出題。また、ビジネス数学検定1級に合格し、公益財団法人日本数学検定協会認定トレーナーとしても活動。著書に『おうちで学べるセキュリティのきほん』（翔泳社）、『プログラマ脳を鍛える数学パズル』（翔泳社）、『シゴトに役立つデータ分析・統計のトリセツ』（ソシム）、『エンジニアが生き残るためのテクノロジーの授業』（翔泳社）がある。

事前に解いてきてもらっていたサンプル問題を解説

参加者には事前にサンプル問題を配ってあり、解いてきてもらいました。チーム内の自己紹介が終わると、増井さんがその解説から始めます。ちなみに、クイズを解く際には、インターネット検索などはいくら使ってもよいというルールです。

■事前に出題していた問題1（プログラミング問題）

　桁数が同じ2つの素数を掛けてできた数を真ん中で区切ったとき、前半と後半のいずれもが素数で構成されている数を考えます。例えば、31と37という2つの素数をかけたとき、31×37=1147となり、その前半である11と後半の47はともに素数です。なお、できた数は桁数が必ず偶数のもののみ考えるものとし、真ん中で区切れないものは考えないものとします。
　このような数を小さな方から順に探した時、上記の1147は初めて4桁になる数で全体の3番目、初めて6桁になるのは131×773=101263で全体の20番目の数、初めて8桁になるのは10091051で全体の372番目の数です。では全体の3976番目の数を答えてください。

考え方は次の2通りあります。

1. 素数を掛け算して、上位と下位が素数になるものを探す
2. 上位と下位の素数を決め、素因数分解して同じ桁数の素数になるものを探す

増井さんは、2のほうでプログラムを作成しました。その場合、以下のような手順になります。

1. 桁数に応じた素数のリストを生成する
2. 桁数を増やしながら、上位と下位を決め、素因数分解する
3. 素因数分解の結果画素数2つになった時と、素数1つの2乗になった時カウント
4. 3976番目になれば終了

Rubyの場合は次のようなソースコードになります。

これを実行すると、答えは20171117という数字になります。

■事前に出題していた問題2（暗号問題）

暗号文と国名の間に以下の対応があるとき、AとBに当てはまる国名を答えてください。

考え方としては、よく出てくる文字に注目します。@がよく出てくることがわかります。@が入る国は、濁音が入っていることに気が付くかもしれません。また、アメリカとアルゼンチンは両方とも「ア」で始まり、暗号文は「3」で始まっています。3のキーボードを見てみると、日本語キーボードを利用している人は「あ」と表記されているはず。そのため、英語モードのままかな入力したものが暗号文だとわかります。ここまで気が付けば、Aは韓国、Bは台湾だと解けるでしょう。

■事前に出題していた問題2（パズル問題）

以下の覆面算を解いたとき、60826033という数字に対応する文字列を答えてください。なお、覆面算では、0から9の数字がそれぞれ対応する別の記号に割り当てられ、同じ文字には同じ数字が入ります。
BOOKS+PANEL=TABLET

わかりやすいように縦に並べてひっ算してみましょう。

BOOKS ＋PANEL ―――――― 　TABLET

5桁と5桁を足して6桁になっているので、一番左の位が繰り上がっていることがわかります。つまり、「T」は1であると分かります。次に、1の位を見ると、SとLを足してT（＝1）になっていますから、ここも繰り上がっています。十の位では、「1+K+E=E」なので、Kは9だと分かります。このようにしてひとつずつ順番に文字に数字を当てていくと、答えは60826033＝BASEBALL、ということになります。

最後に、この3つの解答をキーワードとして浮かび上がる「場所」を見つけます。

「20111117」は2011年11月17日のこと。その他「韓国」「台湾」「BASEBALL」に関連するのは、「ENEOSアジアプロ野球チャンピオンシップ2017」でした。行われた場所は「東京ドーム」。とても凝っているクイズです。

いよいよ、参加者が考えるクイズ演習のスタート

参加者はチーム対抗でクイズを解いていきます。問題は6問。本番の問題にも、サンプルの問題のように答えから導き出されるキーワードがあります。それぞれ、解けた人から答えをネット上のフォームに書き込みます。それを随時、増井さんがチェックしていきます。

勝敗の決め方は、6問の解答から導き出されるキーワードを最初に正解したチームが優勝。どのチームもキーワードを導き出せなかった場合には、解けた問題の多いチームが優勝。解答数が同じ場合には、早かったチームを優勝とします。

問題は、次のように出題されました。

問1 プログラミング問題
問2 暗号問題
問3 論理パズル問題
問4 プログラミング問題
問5 暗号問題
問6 論理パズル問題

各チームで、プログラミングが得意な人、暗号問題をやりたい人、などと担当分けをして解いていきます。話し合いながら解くチームもありました。

45分ほど時間を取りましたが、問題が難しかったのか、解けたのは数名。6チームのうち、4チームが1問を解くことができました。そのうち最も早かったEチームが優勝となりました。

意外と難解だったオリジナルクイズの答え合わせ

ここではすべて紹介することはしませんが、1問目のプログラミング問題を解説していきます。

■問1　プログラミング問題

3つの球とそれぞれに外接する立方体があるとき、立方体の体積の和を考える。
球の半径はいずれも素数で、すべて異なっている。

例）素数を小さい方から3つ選ぶと2, 3, 5
半径が2, 3, 5の球に外接する立方体の一辺の長さはそれぞれ4, 6, 10であり、その体積の和は
4^3+6^3+【10】^3=64+216+1000=1280
3つの素数の組み合わせをすべての素数に対して考え、体積の和を小さい方から順に並べる。
4187番目の値は？

考え方は、次の通りになります。

1. 素数を小さい方から順に生成する。
2. それらの組み合わせを考え、体積を計算する。
3. 体積をキーにした配列を作成し、小さいほうから順に調べる。

Rubyで作成したソースコードは次の通り。

require 'prime' primes = Prime.each(300).to_a cube = {} primes.combination(3) do |a, b, c| 　cube[a ** 3 + b ** 3 + c ** 3] = 1 end sorted = cube.keys.sort puts sorted[0]*8 puts sorted[4186]*8

Prime.eachのeachメソッドで、素数を生成しています。primes.combinationのcombinationメソッドで、素数a、b、cの重複を許さない組み合わせを生成。次のcubeは、体積の和（の1/8）をキーにした配列になります。キーでソートし、1番目と4187番目に8を掛けて出力しています。

簡単なパズル問題と思いきや、プログラミングの知識も含む頭の体操となりました。参加者からは、苦戦したものの楽しかったという声が多数聞こえてきました。うまく解けず「すっきりしない」という人もいたかもしれませんが、論理的に考えたり、工夫してみたりすることは、日常の仕事にも役立つことでしょう。

【本音座談会】社外の知見やノウハウを伝えられるのは、経験のある派遣エンジニアだからこそ

エンジニアとしてのキャリアを考える上で、スキルアップに不安を持つ方は多いのではないでしょうか。株式会社リクルートスタッフィングが運営するITSTAFFINGでは、スキルアップのために努力されている登録スタッフにインタビューをし、普段のお仕事で気を付けていることや、スキルアップのための取組み方について、定期的にご紹介します。エンジニアとしてのキャリアを積む方はもちろん、これからエンジニアになりたいと考える方にとっても、行動のヒントになるはずです。

今回は、11月、12月にご紹介した派遣エンジニア2人の就業先が同じ会社であることから、座談会を企画。それぞれの就業先の担当者を交え、4人に職場での仕事の進め方、気を付けていること、お互いへのリクエストなど、率直に話を伺いました。派遣エンジニアとして働く上で、スキルを発揮するためのヒントもまとめましたので参考にしてください。

座談会参加者

派遣エンジニア　鎌田仁子さん
開発経験豊富なベテラン。銀行や官公庁などのシステムを手掛けた経験もあり。
インタビュー記事はこちら＞＞

FITEC株式会社　後藤隆史様
開発担当

派遣エンジニア　保坂健さん
保守・運用などを中心に、エンジニア歴は18年ほど。
インタビュー記事はこちら＞＞

FITEC株式会社　宮武邦広様
保守・運用担当

---

―― 気持ちよく仕事をすすめるため、お互いに気をつけていることはありますか？

最初は仕事の仕方がわからず大変なこともありました。でも、慣れてきたので後藤さんが言わんとしていることや、思いが理解できるようになってきました。なるべく、できることは先回りするようにしています。
作業した内容は、資料を作るようにしています。もしかしたら無駄になるかもしれませんが、備忘録として。細かい作業内容は忘れてしまうこともあるので、振り返りができるようにしています。

ひとつお願いをすると、周囲の部分もまとめていただける。席が離れており、なかなか話す時間もないため、助かっています。

疑問点などは、ある程度まとまってからメールやチャットで聞くようにしています。後藤さんのご都合のよいときに見ていただければ済むようにしていますね。

私も鎌田さんと同じように、宮武さんの時間を奪わないように気をつけています。席が近いのでつい聞いてしまいがちですが、できるだけ邪魔にならないタイミングでお伺いします。ただし、直接の指示系統は別の方で、細かい作業内容はその方からお伺いして、宮武さんには承認していただく流れ。作成した細かな手順書などは、直接指示いただいている方に提出しています。

そうですね。保坂さんには運用担当として、別のシステムの保守担当とやりとりをお願いしています。私は、保坂さんとその担当者の間に入り、業務が円滑に進むように、互いに気にかけています。具体的な仕事の内容はわからないので、ストレスが高そうなときに声掛けをし、担当者と調整するのです。
また、保坂さんは細かい仕様書を作ってくださるので助かっています。社員が担当すると後回しにしたり、雑になりがちだったりするところなのでありがたいですね。

派遣エンジニアTips：

・担当者との理解が進めば仕事を先回りして処理できる。
・丁寧なドキュメントを作って価値を提供する。

―― 派遣スタッフがミスをしたら、どのようにフォローするのでしょうか？

開発をしていると、ミスはよくありますよね……（笑）。

パートナー（派遣スタッフ）だから、社員だから、といった区別はありません。事象と原因を突き止め、どうすれば二度と起きないか落とし込んで周知します。ある意味システマチックに、当たり前のことをこなすだけですね。

後藤さんや鎌田さんの開発チームと異なり、保守の場合は扱っているのがお客様の本番システムなので、ミスをすると大ごと。そのため、ミスをしないように万全の準備をします。細かく資料を作成し、危ない個所を残さないように担当者にレビューしていただくのです。内容によって、誰に聞けば安心か教えてもらいながら進めています。

そうですね。開発ではないので1000回に1回のミスでも大変なことになります。人間がやるのでミスはつきものですが、メンバーも保坂さんも、石橋をたたいて、時間がかかってもいいからミスをしないというやり方で進めてくださっています。それでもミスが起きてしまったら、後藤さんと同じように原因を突き止めて、再発しないような対策を取ることが大切です。

以前の上司の受け売りなのですが「パートナーの失敗は、そのパートナーとやり取りしている社員のミスだ」という考えでやっています。作業者が寝てしまった、というような個人の問題であれば別ですが、通常はさまざまな要素がからむ仕組みの問題であることが多いのです。

開発の場合も、基本的に単独で作業することはなく、ほかの方と一緒に確認しながら進めていくので安心できます。みんなで間違えることはときどきありますが、ミスを前提として、その後の対処を大切にしていますね。

そうですね。

派遣エンジニアTips：

・わからないことは、内容によって詳しい人に聞きながら進める。
・ミスをしたら担当者と情報共有し、原因究明と再発防止に努める。
・開発と保守では進め方が異なる。保守はミスをしないための事前レビューが肝。

―― 派遣スタッフがいて、よいと思うことはなにかありますか？

弊社にはもともと親会社があり、そのシステム部から変遷してきました。したがって、ほかの会社と一緒に仕事をすることが少なく、知識も偏っています。メーカーのシステムに関してはノウハウがありますが、新しいWebのシステムなどに精通しているとは言えません。

鎌田さんは、銀行などで働いてきた経緯から、リアルな知見をたくさんお持ちです。私たちにない知識を教えてもらうこともあり、社外のノウハウを自社に投入してくれるのはとてもありがたいと思っています。

社内だけでやっていると、自分たちの考え方が当たり前になってしまいます。ところが、実は一般的で効率的なやり方とずれていることも。それを遠慮なく提案していただけると嬉しい。もっと言っていただきたいくらいです。

―― 派遣エンジニアのお2人から、担当のお2人に伝えたいことはありますか？

私としては、もう少し「無茶振り」されても大丈夫だと思います。一応ベテランなので……。まだ遠慮されていたり、気を使われていたりするのではないかと思っているのです。

では明日から「無茶振り」を……（笑）。

こういう仕事が来そうだよ、と事前に情報をいただくだけでもいいと思っています。情報をいただければ、準備ができますから。

そうですね。あらかじめ開示できる情報は、ほかのメンバーにも共有していこうと思います。ただ、案件自体がなくなってしまうこともあります。そうなったら申し訳ないという思いも……。

それはもう仕方ないですよね。

私の場合は、作業負荷がやや大きかったことがありました。その時に宮武さんが間に入って止めてくださり、ありがたく思っています。

派遣エンジニアTips：

・職場の「あたりまえ」を疑ってみる。他社で培った知見が役立つこともある。
・仕事の事前情報をもらっておけば、調査や準備ができる。

和気あいあいとした雰囲気は、普段からの関係性のよさが見て取れます。ミスを平等に扱ってくれるスタンスは、働く側として安心できるのではないでしょうか。

これまで培った社外のノウハウを伝えたり、社員だけでは手が回りにくいドキュメントをしっかりと残したりと、派遣エンジニアの価値はしっかりと発揮されているようす。疑問点がまとまってから質問する、先回りをして作業するといった工夫も、できるところから参考にしたいものです。

【イベントレポート】要件定義にはビジョンがマスト！わかりやすい例で学ぶ「要件定義の基礎と肝」

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。

12月1日に開催したセミナー「AI時代も大丈夫！あらゆる仕事に活かせる要件定義の基礎と肝、教えます。」では、『はじめよう！要件定義 ～ビギナーからベテランまで』の著者である羽生章洋さんをお迎え。わかりやすいスライド構成に時折笑いを交え、あっという間の1時間半となりました。

■今回のイベントのポイント

・要件は「UI」「機能」「データ」の3要素からなる
・仕事とは、「活動」により「成果」を出すものである
・ビジョンファーストで未来図を作ることが大事

セミナーがスタートするや否や「今回の話は必ず何かしらの役に立ちます」という羽生さん。内容は、要件定義の基礎だけにとどまらず、最後には自分のビジョンの見つけ方にも及びました。最後に紹介した短いワークは、日を改めてひとりでも取り組めるもの。ぜひトライしてみましょう。

▲【講 師】羽生章洋さん
2社のソフト会社にて、パンチャー、オペレータ、プログラマ、SE、DBA、PMを経験したのち、アーサーアンダーセン・ビジネスコンサルティングにてERPコンサルタント。トレイダーズ証券にて創業メンバー・情報システム部のディレクター。日本で初めてのRIA＋OSSによるオンライントレーディングシステムの企画・設計・開発・運用に携わる。その後、マネースクウェア・ジャパンにて創業メンバー・IT担当取締役。その後独立し、経営とITのコンサルタントとして活動。現在の中心活動は、エークリッパー・インク代表。琉球大学　非常勤講師、NPO法人原爆先生　理事。

正しい要件とは、合意ができていて「これなら作れる」と思えるもの

羽生さんはまず、要件定義に関する有名なイラストを紹介しました。顧客が説明した要件に対して「本当に必要だったもの」が実は違った、というケースをおもしろおかしく描いたもの。同時に、「プロダクトリーダーの理解」「アナリストのデザイン」「プログラマのコード」「営業の表現、約束」といったあらゆる側面で、すべてのイメージ図が異なっているという状況を揶揄しています。

システム開発のプロジェクトにかかわったことのある人なら苦笑いすることでしょう。それくらい、伝言ゲームによってイメージと実装がずれてしまうことはままあります。

「昨今、要件定義がプロジェクト遅延の大きな要因を占めています。20年前はそうじゃなかった。『できること』が少なかったため、要件定義よりも技術的な問題で遅延することが多かったのです。ところが今は、『できること』が広がっています。『AIを使って働き方改革を』と謳っても、具体的なシステムを思い描くのが難しいのです」

また、要件定義は、「こんなことを実現したい」というビジネスサイドと、「技術的にはこのように実現する」というエンジニアサイドの間にあるもの。実現したいことを技術的な内容に置き換えなくてはならないので、両方を知っておく必要があるのです。

「プロジェクトが始まったら最初にやるのが要件定義ですが、その前に営業や調達の活動があります。その際に『こういう未来を約束します』と契約してしまっているのです。その後に要件定義をするのっておかしいと思いませんか？」

と羽生さんは問います。そのため、そもそもの要求に対して、実現できない場合もあります。それをすり合わせるのが、負荷の高い問題になるのです。

ここで、「正しい要件」の定義がスライドで示されました。

正しい要件とは、「1.合意できている！」「2.これなら作れる！」の2点が揃っていること。それぞれ「UI」「機能」「データ」の3つの要素が必要になります。

「こんな風に業務をできるようにしたい」に対して「そのためには、こういうソフトウェアが必要」という内容が、「UI」「機能」「データ」のそれぞれで揃っていなくてはならないのです。

ビジネス要件が決まってからソフトウェア要件が決まる

「こうしたい」というビジネス／業務要件と、「これならできる」というソフトウェア要件を、ラーメン店に例えて説明しましょう。

ラーメン店の業務では、ホール係が注文を聞き、受注。その後キッチン係が調理して、ホール係が配膳した後、お客さんが食事をします。この流れを円滑にし、さらに、受注するときにオーダーの取り違えをなくしたいというニーズがあるとします。

「そのためにはソフトウェアで実現したいことを決める必要があります。例えば、注文端末があれば、使い勝手や操作性がいいかもしれません。また、お客様が自ら端末で注文する『セルフオーダー』という方法も考えられます」

まず、実現したいことが決まらないと、ソフトウェア側の必然性が揃わないというわけです。

要件定義とは、「仕事」の定義と言い換えることができます。「（顧客を含めた）人がどんな仕事をするのか」「コンピュータにどんな仕事をさせるのか」を決めればよいのです。ところが、ここで言う「仕事」とは何でしょうか？

仕事とは、「何かをする（活動）」と「何かをした結果（成果）」のセットである、と羽生さんは説明します。何らかの活動をしても、成果が出なければ仕事ではないのです。

さらに、成果を次の仕事のインプットにして、連鎖しなくてはなりません。受け渡しをしないと、仕事を終えたことにはならないのです。また、活動するための能力を培うための仕事や、成果を直接受け渡すのではなくどこかに保管してピックアップするという連携も想定できるでしょう。これらは、羽生さんが開発した業務プロセスの簡単高速モデリングツール「マジカ」を使うことで、比較的簡単に整理することができます。

ビジョンファーストで、まず未来図を作る

要件定義にはややこしさがつきまといます。それは「業務をアプリに合わせる」という主張と「業務が決まらないとアプリの要件を定義できない」という主張が相容れないこと。

「これを断ち切るためには、『ビジョンファースト』、つまり『実現したい未来を決める』が有効です。例えば『目玉焼きを作る』という仕事なら、目玉焼きがありありとビジョンとして浮かんでいなくてはなりません。よく『すべてのものは二度作られる』と言われます。まずは頭の中、次は現実です。まず、頭の中で鮮明な絵面が浮かぶことが大前提なのです」

目玉焼きは、いわばプロジェクトのゴールです。その後「半熟である」「醤油をかける」などの完了条件＝要件が決まり、手順や工程といったToDoに落とし込まれるのです。

「ところが、お客様の提示したビジョンが、本当に求めていることとずれているケースがあります。例えば、『生産管理がやりたい』と相談を受け、よく聞いてみたら本来やりたいのは在庫管理だった、ということもあります。本物のビジョンを見つける力が、驚くほど鍛えられていないのです」

ビジョンを見つけるワークをやってみよう

最後に、簡単なワークをしました。自分のビジョンを見つけるためのワークで、「ミライクエスト」という名前です。

---

ステップ1

今の自分の願望を書き出してください

ほしいものや行きたい場所、やりたいこと、なりたいもの、会いたい人など、どんなことでも、いくらでも書きだします。

ステップ2

それぞれの願望が叶ったら、どんな「嬉しい・素敵なこと」が起こるのかを書き出してください

さらに、その「嬉しい・素敵なこと」が叶ったら、どんな「嬉しい・素敵なこと」が起こるのかをどんどん書き出していきます。同じ内容は毎回書くか、正の字でカウントしておきます。

ステップ3

書き出した「嬉しい・素敵なこと」の中で、「何度も出てきたもの」「特に心が強く惹かれるもの」をピックアップしてください

ステップ4

ピックアップした「嬉しい・素敵なこと」を実現している自分をイメージして肩書・名称を自由につけてください

自分がさまざまなことを実現しているという前提で、「起業家」「花屋さん」「大富豪」など、肩書と名称を考えてみてください。

ステップ5

肩書・名称にオーバーな形容を自由につけてください

「デラックス起業家」「ロイヤル花屋さん」「エクセンレント現役プログラマ」などオーバーな形容を付けます。

ステップ6

次の文章を書いてください「＜自分の名前＞は（ステップ5で書いた）『オーバーな肩書・名称』である」

「スーパーな肩書なんだから当たり前のこと！」という意識でどんどん書きましょう。

ステップ7

『野望を達成した』と言うための条件を書いてください

何をもって野望を達成したことになるのか、条件を箇条書きなどで書いていきましょう。

---

これらのワークにより、ビジョンを鍛える練習になります。要件定義をする際、なかなか本来のビジョンへ立ち返るのは難しい場合もあります。だからこそ、「ビジョンがなければ行き先がわからない」という自覚を持ってプロジェクトを進めたいものです。

羽生さんは、最後を次の言葉で締めくくりました。

要件定義とは、「まだ見ぬ新しい未来を設計する」こと。