派遣で働くエンジニアのスキルアップを応援するサイト

PRODUCED BY RECRUIT

【イベントレポート】Androidエンジニアとして自身の価値を高めるために、今おさえるべきこととは

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

2018年3月2日のイベントでは「Androidエンジニアとして自身の価値を高める極意」を開催。独立系システムベンダーでエンジニアとしてモバイル向けアプリケーション開発を中心に活躍しており、Androidアプリ開発の著書も持つ木田学さんが、エンジニアが自身の価値を高めるための材料として、最新のAndroid開発のトレンドについて紹介してくれました。

【講 師】木田学さん

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

・なぜ自分の価値を高めるのか?
・Androidの現状
・Android開発技術要素の拡大


【講 師】木田学さん
▲【講 師】木田学さん
テックファーム株式会社。開発エンジニア。iOSやAndroid等、モバイル向けアプリケーションを中心に開発。健康支援アプリ、音声認識アプリ、ドローンアプリなど幅広い領域の開発を手掛けている。共著に『Androidアプリ 開発の極意』(技術評論社)などがある。

なぜ自分の価値を高めるのか?

テックファーム社のエンジニアとして、顧客である生命保険会社のスマホアプリ、音声入力の名簿検索アプリ、ドローン制御アプリなど様々なアプリを多数手掛けてきた木田さんは、冒頭で「なぜ自分の価値を高めるのか?」について、マズローの5段階欲求説に基づき、紹介してくれました。そして、自分の価値を高めるのは自己実現のためであると説きます。

f:id:itstaffing:20180418114301j:plain
▲自分の価値を高めることで、自分が本当にやりたいことをやり、本当に欲しいものを手に入れる自己実現が達成できる。

スマホは利用頻度が高く、人に影響を与えられる素晴らしいツールで、スマホアプリを作れることはすなわち多くの人に影響を与えられる素晴らしい仕事と考えているそうです。

多くの人に使われるAndroidアプリ開発を極めていくことは、エンジニアの価値向上につながると考え、今回のイベントも「皆さんの価値を高める材料を増やす」ためになればとのこと。

Androidの現状

まずはAndroidのシェアから。2008年に世界初のAndroid端末が登場し、現在は世界で75%のシェアを獲得。ライバルであるiOSは20%なので、数の上では圧倒しています。

でも、これはあくまでも世界規模で見た場合のお話で、日本国内はちょっと違います。

2011年時点の調査ではありますが、日本国内ではiOSが約6割、Androidが約4割という結果が示されており、国内におけるiPhoneの人気の高さがうかがえます。

f:id:itstaffing:20180418114230j:plain
▲バージョン5.0(Lollipop)、6.0(Marshmallow)、7.0(Nougat)が、まだ多数稼動しており、最新版の8.1(Oreo)は少数にとどまっている。

また、Android OSの最新バージョンは8.1ですが、市場ではバージョン5.0、6.0、7.0の3つのバージョンが8割を占めています。複数バージョンの存在は、Androidアプリ開発でも注意が必要かもしれません。

Android開発技術要素の拡大

では、いよいよ本題です。Androidアプリ開発に求められる技術にはどのようなものがあるのでしょうか。

「多様化する社会のニーズに向けてアプリやサービスを開発していくにあたり、開発の現場においても、幅広い知識が必要とされてきています」(木田さん)

実際にAndroidアプリ開発にも、さまざまなニーズがあり、品質重視、スピード重視、外部サービス連携、クラウド連携、複数ベンダーとの連携などが求められています。

こうした多様化するニーズに対応するため、Android開発の技術もすそ野が広がっています。その中でも重要な技術を6項目に分けて紹介してくれました。

f:id:itstaffing:20180418114234j:plain
▲Androidアプリ開発においても多様化するニーズへの対応のために基礎以外の技術知識やスキルが求められている。

開発環境

まずは開発環境について。IDE(統合開発環境)にはGoogle社が提供するAndroid Studioがよく使われています。

プロジェクトのビルドには、gradleが使われることが多いのですが、元々Google社内で使われていて今はOSS化されたbazelというビルドツールも使われ始めており、「今後はbazelに置き換わるのではないだろうか」(木田さん)とのことでした。

その理由として、Android OS 8.1から端末上の人工知能を加速させるNeural Networks APIが実装されており、TensorFlow Liteが使用できるようになりましたが、TensorFlow Liteのサンプルプロジェクトをみるとビルド方法にbazelが使用されており、これから出番が増えていくだろうというのが木田さんの見立てです。

また、プラグインや、メモリリークをチェックするアナライザーなどについても、開発現場で使われているものをいくつか紹介してくれました。

開発言語は、現在はJavaが主流ですが、今後はkotlinが使われるようになるのではないか、とのことでした。

OSS

Androidアプリの開発においてもオープンソースソフトウェア(OSS)が、いたるところで利用されています。

f:id:itstaffing:20180418114237j:plain
▲メジャーなアプリで使われている主なOSS。

「OSSを利用することで開発工数が大幅に減り、バグが出にくくなります。ただし、デメリットもあり、バージョンアップで動かなくなったり、そもそも(設計上の)バグを含んでいたりというケースもあります。しかし、それらを差し引いてもメリットのほうが大きいと言えます」(木田さん)

そして、イベント通知ライブラリEventBus、RESTクライアントライブラリRetrofitなど、OSS利用に有用なライブラリも紹介してくれました。

BaaS

BaaS(Background as a Service)とは、バックエンドの機能を提供するサービスのことで、Webアプリケーションで言うサーバサイドに相当します。

主要なものとして、AmazonのAWS、MicrosoftのAzure、GoogleのFirebaseなどがあります。FirebaseはGoogleのサービスなので当然ですが、AWSにはAWS SDK for Android、AzureにはAzure Mobile Access SDK for Androidという、それぞれを利用するためのAPIを実装したライブラリが提供されています。

そのほか、バックエンドの負荷考慮についても、いろいろなノウハウがあることを教えてくれました。

f:id:itstaffing:20180418114240j:plain
▲最先端の現場での経験をもとに木田さんが紹介してくれるAndroidの技術トレンドは多岐にわたる。

Googleサービス

アプリを公開するなら、Google Play Consoleで、できること(やるべきこと)を知っておくと良いそうです。同Consoleからは機種制限、レビューコメント、公開制限事項などの設定が行えます。

また、AndroidアプリがGoogleマップやGoogleドライブなどのサービスにアクセスするためのAPIを提供するGoogle Play Servicesの機能も、知っておくと良いとのことでした。

試験

バグレポートでは、リアルタイムクラッシュレポートツールFirebase Crashlyticsが便利とのこと。また、試験の自動化では、Googleが公開しているAndroid用UIテスト自動化フレームワークEspressoをよく利用しているそうです。

CI(継続インテグレーション)では、他の分野でもお馴染みのJenkinsや、Concourse CIなどが使われており、また、外部サービスとして、前述のFirebaseや、OpenSTFというツールを利用することもあるそうです。

デザイン

多様化するニーズに対応するには、デザインソフトの知識も求められます。木田さんのお勧めはSketch。モバイルに特化した機能があり、異なる解像度の機種に向けたデザインを作成するのにも便利だとか。

また、iOSアプリとの比較も重要で、コンポーネント(ボタンやテキストボックス等)や、フラットデザインとマテリアルデザインの違いを押さえておくことで、同じアプリのiOS版とAndroid版のUIの整合性が保てるなど、メリットも多いといいます。

f:id:itstaffing:20180418114244j:plain
▲自身のエンジニアとしての価値向上のため、Android開発技術スキルを身につけてみるのもよいかもしれない。

以上、充実した1時間半のイベントでした。今回のイベントで、Android開発の最新事情の一端を垣間見ることが出来ました。エンジニアとしてやりたいことがあるなら、自己実現のためにも、最新技術のトレンドを常にキャッチアップしておくことが大切ですね。

【イベントレポート】「人を行動に導く」効果的なプレゼンのテクニックを学ぼう

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。2018年2月23日のイベントでは「直感に刺さるプレゼンテーション」を開催。

大手玩具メーカーでヒット商品のマーケティングを手掛けた後、映像配信会社やゲーム会社などを経て、プレゼンテーションの専門会社を設立し、プレゼンテーションの研修やコンサルティングを行う望月正吾さんに、効果的なプレゼンテーションのテクニックについて紹介していただきました。

【講 師】望月正吾さん

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

・プレゼンテーションはコミュニケーション
・ビジュアルには図解とイメージがある
・タイトルスライドはプレゼンの顔
・聞き手を動かす話し方のポイント


【講 師】望月正吾さん
▲【講 師】望月正吾さん
PreZenDou LLC.代表。玩具メーカータカラ(現タカラトミー)にて、マーケティング部門を担当。タカラトミー合併後は、映像配信ベンチャーCOO、ゲーム会社を経て2011年プレゼンテーションの専門会社PreZenDou LLC.を設立。プレゼンテーション研修、制作、コンペ、個人指導と業務コンサルを行う。専門はプレゼンテーション&コンセプトメイキング。コミュニケーション戦略、新規事業プランニング、商品&サービス企画を得意としている。著書に『直感に刺さるプレゼンテーション』(技術評論社)『最速で最高に魅せるPowerPointプロフェッショナルテクニック』(技術評論社)がある。

プレゼンテーションはコミュニケーション

長年、玩具メーカーのマーケティング部門で活躍し、さまざまなプレゼンを手掛け、その後、いくつかの企業を経て、現在は独立し、各種プレゼンのコンサルなどを手掛けている望月さん。今回のセミナーでは、その豊富な経験をもとに「心を揺さぶり、行動してもらうビジュアルプレゼンテーションの原理とテクニック」を、事例を交えながら紹介してくれました。

望月さんのミッションは「世の中から退屈なプレゼンを無くそう」というもの。なんだかワクワクします。

まず、最初に示されたスライドは「禁煙促進」を呼び掛けたもの。そのスライドには、喫煙者の肺がん発生率が高いことがズラズラと「説明」されていて、どこかで一度は見たような、というもの。

このスライドについて望月さんは「言っていることは正しいし、理解もできる。でも、これではタバコをやめさせることはできない」と断言します。

「プレゼンの目的は行動してもらうこと。行動してもらえなければプレゼンは失敗です。残念なことに人は理解しただけでは行動してくれません」(望月さん)

f:id:itstaffing:20180412102434j:plain
▲行動してもらえなければプレゼンは失敗。そのためには「感情的アプローチが有効」と訴える望月さん。

プレゼンにおいては聞き手にも次のような階層構造があり、それを図にして紹介してくれました。ピラミッド状の図の下から順に、

・雑音(寝ているのと同じ)
・認知(何か話しているなぁ、程度)
・理解(なるほど、わかった→論理的に正しい)
・共感(自分もそう思う→意思決定は不要)
・行動(やってみよう→意思決定が必要~ビジネスプレゼン)

となっています。そして、頂上に近い共感と行動の2つには「感情的アプローチが有効」だと望月さんはいいます。

では、その感情的アプローチを行うにはどうすれば良いのでしょうか。

ビジュアルには図解とイメージがある

プレゼンテーションで感情的アプローチをするには、ビジュアルで伝えることが重要。ビジュアルには図解とイメージの2種類があり、図解は論理的、イメージは感情的であるという、それぞれの効果を紹介してくれました。

さらに、「理解できないイメージは混乱を招くだけです」といい、失敗例となる1枚のスライドを示してくれました。

f:id:itstaffing:20180412102438j:plain

そこには人の横顔の写真がイメージとして使われているのですが、その鼻の部分が画像修正をほどこされており、ニョキっと長く前に突き出ています。ここからイメージするのは「傲慢」(天狗)か、あるいは「嘘つき」(ピノキオ)か、人によって受け取る印象が異なるという例だそうです。

「いかにして言葉とイメージをシンクロさせるのかが重要です。イメージを使いこなすには、慣れやコツが必要なので、いろいろと試してみるとよいでしょう」(望月さん)

タイトルスライドはプレゼンの顔

プレゼンスライドと企画提案書は全く別のもの、「プレゼンスライドは魅せるための資料」「企画提案書は読んでもらうための資料」だそうです。いずれの場合も、大切なのはタイトルスライドだそうです。

構成立案やスライド制作で力尽きて、タイトルスライドには文字だけ入れて名前を書くという人が多いけれど「タイトルスライドで『聞きたい』と思わせられなければ、それは負けプレゼンです」(望月さん)とのこと。

f:id:itstaffing:20180412102441j:plain
▲企画提案書もプレゼンスライドも、タイトルを見て「読む気にさせる/聞く気にさせる」ものでなければダメ。ただし、中身の作り方は企画提案書とプレゼンスライドで、それぞれ異なる。

ただ単に「〇〇のご提案」と書くのではなく、「現在の状況に対する問いかけの言葉」や「提案を実行した後に訪れる明るい未来」、「解決すべき課題を放置しておくと起きる悲惨な未来」など、シンプルかつ聞きたくなるものを、パターン別に事例と共に紹介してくれました。

聞き手を動かす話し方のポイント

最後は話し方について。展示会のブースで説明をするナレーターは、話し方はとても上手ですが、自分が興味を持つテーマでない限り、なかなか足を止めて聞き入ろうとは思いません。それは「自分の言葉で話していないから」だそうです。同様の理由で、プレゼンにおいて、読み原稿を持つ、話す内容を丸暗記する、プロっぽく話そうとするというのもダメだとのこと。

f:id:itstaffing:20180412102446j:plain
▲読み原稿はいらない。普段から話している「自分の言葉」で話すことが伝わるプレゼンの秘訣。

「スライドを真剣に作っていると、いつの間にか話せるようになっています。会話するのに原稿を見て話さないでしょう。それと同じです。だから読み原稿は必要ありません。」(望月さん)

もし原稿なしでは話すことができないのであれば、それは構成かストーリーが間違っているかもしれない、と疑うべきだそうです。また「1スライド1メッセージ」「箇条書きのメモは手元に置いておいても良い」「普段の言葉で話す」など、コツを教えくれました。

とても中身の濃い1時間半のイベントでしたが、最後に望月さんは参加者に向け、「プレゼンテーションを楽しんでいただきたい」というメッセージで締めくくってくれました。

今回のイベントでは、反面教師となる残念な事例と、望月さんのテクニックを用いた洗練された事例とを見比べることができ、プレゼンをより良くするためのポイントがよく分かりました。自分でプレゼンする機会があれば、ぜひ試してみたいものです。

そして、そんな自分を客観視したときに、「あ、このイベント自体が『行動させるプレゼン』だったのか」と気づかされた方は、望月さんのプレゼンの凄さが分かったことでしょう。

【イベントレポート】なぜ要件定義がうまくいっても、使えないシステムができてしまうのか?

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。2018年2月8日のイベントでは「お金をドブに捨てないシステム開発の教科書」を開催。

「公認会計士でシステムコンサルタント」という異色の経歴を持ち、書籍『お金をドブに捨てないシステム開発の教科書』の著者でもある中川充さんに、要件定義がうまくいっても、使えないシステムができてしまう、その問題点と解決策を紹介していただきました。そのイベントの様子をご紹介します。

【講 師】中川 充さん
 

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

・システム構想こそ、システム開発成功のカギになる
・事例:資金が6億円も悪化するシステム
・システム構想の8つのステップ、コツとツボ

 
【講 師】中川 充さん
▲【講 師】中川 充さん
システムコンサルタント・公認会計士。公認会計士中川充事務所代表。システム・業務・会計を統合し、企業経営のしくみを改革することを得意とする。上場会社、中堅企業、ベンチャーへのシステム開発や業務改革のコンサルティング実績は全国50社以上。そのほか、システム選定委員やパッケージ製品の開発助言なども行う。

システム開発失敗の理由は本当に要件定義か?

日本情報システム・ユーザー協会が実施する「ソフトウェアメトリックス調査」によれば工期遅延や総費用増大の理由は、要件定義が4割、プロジェクトマネージメントに関するものが6割という結果が示されているそうです。

要件定義は理由の4割を占めていますが、「でも、要件定義のせいだけじゃないよね」(中川さん)というのが、今回のテーマとのこと。

中川さんは冒頭で、上場企業が公開している有価証券報告書から、システムがらみで減損損失や特別損失を計上している会社をいくつか拾い上げ、紹介されました。

f:id:itstaffing:20180322140841j:plain
▲有価証券報告書には、システム開発が減損損失になった理由もきちんと書かれている。普段目にすることがないので新鮮だ。

あるエレクトロニクス企業は、基幹システムの開発にかかった7億2千万円を減損損失に計上。その理由に「基幹システム導入の見直しを行った結果、当初想定した費用削減効果が見込まれなくなったため」と記されていました。中川さんによれば「あくまで推定ですが、買ったもののダメになり、結局稼働しないイメージ」だそうです。

ほかにも、「自社利用のソフトウェア(開発中)の一部に、システム開発の変更が生じたこと等に伴い、使用が見込まれなくなった」として8億7千万円を減損計上した医療系ホールディングス企業や、基幹システムの「導入規模・範囲を見直したため」に42億円もの損失を計上した機器メーカーもありました。

これらの原因は本当に要件定義なのでしょうか?

システム構想こそ、システム開発成功のカギになる

中川さんは、「要件定義が上手くいく = 使えるシステム」とは限らない、と訴えます。

なぜなら、業務要求に基づいて要件定義が行われますが、時間の経過とともに業務要求そのものが変わることがあるからです。このとき「手戻りして修正できればいいのですが、そうはいかないケースも多い」といい、特に全社システムでは、その傾向が強いそうです。

全社システムは、関係者も部門システムに比べると格段に増えます。部門間の要求の違いや、部門間の隠れた利害の衝突が起きてしまうことも多く、単純に各部門の業務要求を寄せ集めても、全社システムの業務要求にはなりません。

こうした課題をあらかじめ見つけ出し、解決しておくことが重要だと中川さんは強調します。この工程がシステム開発を成功に導く「システム構想」なのだそうです。これはシステム開発の一環というより、ビジネスモデルを設計していくのに近いとのことでした。

f:id:itstaffing:20180322140848j:plain
 
▲各部門の業務要求の隠れた利害関係の衝突などをあらかじめ顕在化させ、衝突を回避しつつ、ビジネスモデルを考えていくのがシステム構想というフェーズ。要件定義の前段できちんと行う必要がある。

システム構想においては、経営・会計・業務・システムの4つの視点が重要で、いずれかが欠けてしまうと、いくら要件定義が上手くいったとしても、後から業務要求が変わったときに、使えないシステムになってしまう危険性があります。

f:id:itstaffing:20180322140851j:plain
 
▲ビジネスモデルを設計するからには、経営・会計・業務・システムといったそれぞれの視点が必要。ビジネス(全社システム)を見渡して、部分最適でなく、全体最適を図る。

では、実際に後から業務要求が変わるケースとは、どのようなものがあるのでしょうか?

事例:資金が6億円も悪化するシステム?

会員向けオンラインサービスを提供している会社を例として採り上げました。

f:id:itstaffing:20180322140854j:plain
 
▲会員管理と課金方法の異なる事業の売上管理、そして予算上限という業務要求が課せられたこのプロジェクトに、情報システム部は果たしてどのようなシステムを考えるのか?

この要件に対してシステムベンダーが提示してきたのが、年払い機能の無いA案と、年払い機能ありだが予算を大幅に超えるB案でした。

f:id:itstaffing:20180322140858j:plain
 
▲売上の最も少ないパイナップル事業のためだけにプラス3000万円のシステムを開発するよりも、パイナップル事業の課金方法を変えたほうが、システムも業務もシンプルになるというが……。

年払いのパイナップル事業は売上も15億と少ないので、これを他の事業と同様の月払いに変更するというのがA案の提案ポイントです。請求データが売り上げになるので、業務もいたってシンプルになることがわかります。

B案は予算を大きくオーバーしているし、会員管理部も課金方法の変更を承諾したので、情報システム部の見解は A案でいいのでは? と、なりかけましたが、そこには大きな問題があったのです。パイナップル事業を月払いに変更してしまうと、会社の現金が足りなくなり6.6億円も資金が悪化してしまうことが判明しました。

f:id:itstaffing:20180322140901j:plain
 
▲月払いにしてしまうと、これまで前受分として会社が預かっていた現金が6.6億円減ってしまうため、最悪の場合、資金がショートして経営が立ち行かなくなってしまうかもしれない。

当然、経営者から「待った」がかかり「年払いへの変更は認められないのでB案を予算内におさめよ」という指令が下りました。

システム開発の要件で「PL(損益)まで考える人はいますが、CF(キャッシュフロー)まできちんと考える人は、あまりいません」(中川さん)

経営者の指示でしたが、B案を予算内におさめるのは金額に開きがあり難しいので、経理部も巻き込んで再検討します。そしてA案をベースにしながら、年払い分は入会月別明細を参照して、前受金を毎月手入力していく――すなわち経理部が自動仕訳の一部を諦める修正A案で落ち着きました。

システム構想の8つのステップ、コツとツボ

システム構想を要件定義の前段のフェーズと捉えるのではなく、1つのプロジェクトとして、切り離したほうがうまくいく、と中川さんは説明します。

「システム開発の流れの中に組み入れてしまうと、開発時間が足りないときに、システム構想かテストのいずれかの工程が、真っ先に切り詰められてしまう。しかし、システム構想はビジネスモデルデザインと呼ぶべきもので、通常、中堅企業でも6カ月はかかります。本当は6カ月でも足りないぐらいかもしれません。これをしっかりやるためには、システム開発プロジェクトのスケジュールに左右されないように、1つの独立したプロジェクトとしておくべきなのです」(中川さん)

f:id:itstaffing:20180322140906j:plain
▲システム構想は独立したプロジェクトとして行われるべき。きちんとやっておけば、せっかくのシステムをドブに捨てるようなことにはならないはず。

システム構想は、プロジェクトとしてきちんと予算を取り、必要ならばプロトタイプでしっかりとテストを行うべきで、できれば経営企画や情報戦略部門が担当するのが好ましいそうです。プロジェクトでは、4つの視点をしっかり持つために各部門から人を集めますが、誰でも良いというわけではありません。

会計の担当はシステムと業務のことも、業務の担当はシステムと会計のことも、システムの担当は会計と業務のことも、それぞれある程度は理解している必要があるといいます。

エンジニアとして、自分が心血を注いで作り上げたシステムが、実際に使われないことほど悲しいことはありません。すでに要件定義を手掛けている人はもちろん、これから要件定義のフェーズを学んでいく人も、目の前の業務要求だけでなく、システム構想がどのようになっているのかを意識していくべきだと感じました。

【イベントレポート】前回のイベントからさらに情報追加!今さら聞けない!Windows Server 2016 Active Directory ドメインサービス入門

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

2月2日に「今さら聞けない!Windows Server 2016 Active Directoryドメインサービス入門」を開催。トレノケート株式会社の横山哲也さんのセミナーは、ニーズに応じて、これまでも何度も実施しています。

■今回のポイントは

・Active Directoryドメインサービスの役割を知る
・Active Directoryドメインサービスの基本構造を理解する
・Active Directoryドメインサービスの構築についてデモを通じて学ぶ

前回のセミナーはこちら( https://www.r-staffing.co.jp/engineer/entry/20170630_2 )にレポートがアップされています。今回のレポートでは、前回レポートしきれなかった部分や、新しい機能について紹介します。

【講 師】横山哲也さん
▲【講 師】トレノケート株式会社(旧グローバルナレッジネットワーク)横山哲也さん
1994年より、ITプロ向けのWindows Server関連教育に携わる。2003年からマイクロソフトMVP。著書に『ひと目で分かるAzure基本から学ぶサーバー&ネットワーク構築』『プロが教えるWindows Server 2012システム管理』(監修・共著)『グループポリシー逆引きリファレンス厳選92』(監修・共著)がある。

Active Directoryとは各情報の一元管理を担う

講師の横山さんは、「会社などでActive Directoryがあり、管理ツールを使ったことのある人」を参加者に尋ねました。人数にして半分より少ないくらいでした。

「Active Directoryは何をするのでしょうか?一般的に『ディレクトリサービス』というと、案内状のことを指します。デパートの案内や、電話帳など。したがって、各情報の一元管理を担います」

f:id:itstaffing:20180322115445j:plain

前回のレポートにも記載している内容ですが、ここで復習しておきましょう。
Active Directoryは、以下の3つの要素から成り立っています。

・各情報の格納と検索・・・LDAP
・認証・・・Kerberos
・グループポリシー・・・実はActive Directoryではない

グループポリシーは、厳密にはActive Directoryの一部ではないものの、Active Directoryとセットで利用されるため、一緒に扱うことが多いのです。

Active Directoryの認証でトラブルがあったとき、「認証」と「グループポリシー」でトラブルシューティングが異なるので、別であることを知っておくとよいでしょう。

Active Directoryでない環境として、ワークグループがあります。家庭のネットワークなどで採用されています。コンピューターごとに固有のユーザーやグループを登録し、データはSAM(Security Account Manager)データベースに保存されています。この実体はレジストリです。

「企業などでコンピューターごとに登録すると、管理が面倒になります。10人を超えたらActive Directoryにしよう、と言われていますが、私の実感では3人を超えると大変になってきます」

f:id:itstaffing:20180322115451j:plain

Active Directoryは、ユーザーなどを検索することができます。ただ、検索している人は少ないそうです。ここで、デモとして検索画面をモニターに映し出しました。

エクスプローラーの「ネットワーク」タブに「Active Directoryの検索」があります。ダイアログが開くので、文字列で検索すると、属性にマッチしたものが出てきます。電話番号などの検索も可能です。

基本機能のおさらい

その後、前回のレポートにも一部あるように、基本機能の解説をしました。ここで、用語として復習と補足の解説をしておきます。

●ドメインコントローラー
データベースを保持するサーバーのこと。ドメインサーバーともいう。

●オブジェクト
Active Directoryに格納している情報のこと。「ユーザー」「グループ」「コンピューター」「共有フォルダ―」「共有プリンター」「組織単位(OU)」などがある。

●組織単位(OU)
登録情報の分類、管理権限の委任、構成の一元管理などを担う。

●ドメイン
名前を付けるときにDNSの名前を使う。これがドメイン名。ほかの会社とバッティングするようなドメイン名は避けるのが基本。

●ツリー
ドメインには階層構造を作れる。それをツリーと呼ぶ。

●フォレスト
階層の関係がなくても、関連性を持たせることができる。それをフォレストと呼ぶ。

●サイト
ネットワークの単位。拠点ごとに分けることが多い。

●グローバルカタログ
フォレスト内にある全情報のサブセットで、異なるドメインからよく参照される情報を部分的に収集しておく。

f:id:itstaffing:20180322115455j:plain

トラブルシューティング

複数のドメインコントローラーが存在する場合、お互いにデータベースを複製し合っています(マルチマスターレプリケーション)。どのドメインコントローラーが破損しても、機能障害にならないというメリットがあります。

ただし、基本的にはすべてのドメインコントローラーが読み書き可能なため、同時に書き込みや変更があるとデータの衝突が起こる可能性があります。異なる属性が変更された場合は問題ありません。属性ごとに複製をするので、情報の衝突は起こりません。

データを変更した場合、同一サイト内では、変更をトリガーとして、15秒待機してから複製が始まるので、ほぼリアルタイム。そのため、衝突が起こる可能性は非常に低いと言えます。サイトが異なる場合には、最短でも15分に1回しか複製しないため、比較的衝突が起こりやすいと言えるでしょう。その間に変更されたものがまとめて複製される仕組みです。

衝突が起きた場合、以下の項目を優先して複製します。

1.バージョン(変更回数)
2.更新時刻
3.GUID

GUIDはランダムな数字が付くので、どちらが優先されるかわかりません。

「他には、コンテナ(入れ物)の削除と、オブジェクト作成が衝突するケースがあります。オブジェクトを追加したら居場所がなくなった、ということ。その場合には『LostAndFound』というコンテナに格納されます。また、同一名オブジェクトを同時に作成したような場合は、片方が名前を変更され、勝手に削除されたりはしないようになっています。いずれの場合も管理者が発見して対処することになります」

f:id:itstaffing:20180322115458j:plain

通常のドメインコントローラーは読み書きができると説明しましたが、読み取り専用のドメインコントローラー(RODC:Read Only Domain Controller)も用意されています。間違って設定してしまう管理者が時々いるので、用途を知っておくとよいでしょう。

これは本来、物理的に盗まれるなどの脅威があるときに設定するものです。例えば、ごく少ない人数を管理している支店のようなケース。RODCには、その支店に勤務している一般社員のパスワードだけを保存します。物理的に盗まれたことがわかったら、RODCに入っていたパスワードのリストがすぐにわかるようになっているので、他のドメインコントローラーから強制リセットができます。RODCを盗まれて解析されても、システム的にはさほどダメージがないというわけです。

ドメインコントローラーのメンテナンスとAzure AD

データベースの場所を変更するなど、ドメインコントローラーのメンテナンスをすることがときどきあります。その際の手順を説明しましょう。

「msconfig」というコマンドを実行し、「ブート」タブの「セーフブート」から「Active Directory修復」というメニューを選択します。設定を保存して再起動するとActive Directoryが停止した状態で起動しますが、少々手間がかかります。

Active Directoryだけを停止するには、「net stop ntds」コマンドを使います。その後、「ntdsutil」というコマンドでメンテナンスが可能。その後、再度「net start ntds」を実行して起動しましょう。

f:id:itstaffing:20180322115502j:plain

新機能として、Azure Active Directory(Azure AD)も知っておきましょう。クラウドのAzure上でのID管理のことで、認証プロトコルはOAuth 2.0またはOpenID Connect 1.0。ADDS(Active Directory Domain Service)の認証プロトコル(NTLMv2、Kerberos v5)とは異なります。

さらに、Azure ADDSというものもあり、オンプレミスのActive Directoryと同じプロトコルをインターネット上で使います。

「Azure ADDSの用途は、『Azure上で一般的なドメイン機能が欲しい』というニーズに応えるものです。フェールオーバークラスターの構築や、複数サーバーの統合管理、Windows Server構築インフラとして必要、などがあるでしょう。ドメインコントローラーを排除できるので安価に済ませられると考えられます」

Active Directoryドメインサービスは、ここ数年間で機能が大きくは変わっていません。だからこそ、今さらどうやって勉強しようか、悩んでいた方も少なくないでしょう。この機会にしっかりとマスターしておきたいですね。

【イベントレポート】ますますニーズが高まる分野に注目!「Microsoft Azureから使うLinux」

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

1月26日に開催された「Microsoft Azureから使うLinux」では、トレノケート(旧グローバルナレッジネットワーク)の横山哲也さんが登壇し、Azureを用いてLinux仮想マシンを作成する際の概念や手順などを、デモを交えて解説しました。

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

・Azureを使ってLinux仮想マシンを作成する利点を知る
・デモを通してLinux仮想マシンを作成する手順を理解する
・Linux仮想マシンの注意点を確認し、新機能などもフォローする

今回のセミナーで話す内容は、横山さんの著書『ひと目でわかるAzure基本から学ぶ サーバー&ネットワーク構築』にほぼ含まれているとのこと。より詳しく知りたいなら、購入がお勧めです。

【講 師】横山哲也さん
▲【講 師】トレノケート株式会社(旧グローバルナレッジネットワーク)横山哲也さん
1994年より、ITプロ向けのWindows Server関連教育に携わる。2003年からマイクロソフトMVP。著書に『ひと目で分かるAzure 基本から学ぶサーバー&ネットワーク構築』『プロが教えるWindows Server 2012システム管理』(監修・共著)『グループポリシー逆引きリファレンス厳選92』(監修・共著)がある。

デモでLinux仮想マシンを作成

会場の参加者の中に、Linux仮想マシンを使ったことのある人(ログインしたことのある人)に挙手をしてもらうと、1/3程度。AWSを使ったことのある人はもう少し多いようです。

その後さっそく、講師の横山さんがPCの画面をプロジェクターに映し、AzureのポータルでLinuxを作るデモをスタート。細かい手順は一部説明を省略しながら、名称を決め、HDDまたはSSDを選ぶ、など項目を説明しつつ進めていきます。

SSHを使ったログインは、公開キーを使う方法と、パスワードとが選べます。公開キーを利用すれば、毎回パスワードを入力する必要がありませんが、公開キーとそれに対応する秘密キーが必要となります。

「その後、仮想マシンのサイズを指定します。CPUの個数、メモリの容量などです。CPUはデフォルトがデュアルコアになっていますが、この場面ではオーバースペックなので、低い性能を選びましょう。シングルプロセッサで、メモリは3.5GBに設定します」

デモでは、オプションはネットワーク設定も省略して先へ進めました。パラメーターチェックをして、問題がなければ作成しましょう。

f:id:itstaffing:20180308161439j:plain

Azureの管理はWebポータルで行う

Linux仮想マシンのサポートは2014年に本格的にスタートし、3月にはWindows AzureからMicrosoft Azureに名称が変更されました。2015年には「Microsoft Loves Linux」というMicrosoft社員のブログが公開され話題に。2016年にはRed Hat Enterprise Linuxがサポートされたのです。

ここで、AzureがLinuxを動かしている環境について説明しておきましょう。

f:id:itstaffing:20180308161444j:plain

Linuxを動かしている環境はAzureですが、AzureはHyper-Vで動いています。Hyper-Vとは、Microsoftの仮想環境のこと。LinuxはHyper-Vを標準カーネルで基本サポート、Linux Integration Serviceで追加サポートしており、Hyper-Vをフルサポートしていることになります。

Azureの管理は、Webポータルで行います。対応ブラウザーは以下の通り。

・Microsoft Edge(最新バージョン)
・Internet Explorer 11
・Chrome(最新バージョン)
・Safari(最新バージョン、Macのみ)
・Firefox(最新バージョン)

また、Azureの管理コマンドは「Azure CLI 2.0(クロスプラットフォームCLI)」を利用します。実態は、Linuxのshellなので、lsやviコマンドが使えます。

f:id:itstaffing:20180308161447j:plain

デモでは、Webポータルからクラウドシェルを起動し、ブラウザーの下半分にクラウドシェルの画面を表示させました。そこで、Azure CLI2.0を利用します。iPadやAndroidタブレットで動かす場合は、ブラウザーではなく管理用のアプリを利用しましょう。そこから、先ほど作成したLinux仮想マシンへのログインの手順もデモで見せながら解説しました。

スワップは管理者が一時ディスクに割り当てる

f:id:itstaffing:20180308161451j:plain

Azureの仮想マシンには、システムディスク(Cドライブ)と一時ディスク(Dドライブ)があります。実態はそれぞれ、/dev/sda1と/dev/sdb1/です。CドライブはBLOB(Binary Large Object)に割り当てられていますが、DドライブはAzure内の物理マシンに固定的に割り当てられています。

Windowsの場合、規定では、一時ディスクであるDドライブにはページファイルが配置されており、起動時に割り当てられますが、シャットダウン時には不要になります。Dドライブは物理マシンに割り当てられているため、ディスクが障害などで物理マシンの割り当てが変更になるとき、内容は消えるということを覚えておきましょう。CドライブはBLOBに接続しなおすだけなのでデータは保持されます。

Linuxの場合は、スワップなしで作成されるため、管理者が一時ディスクに割り当てる必要があります。これもデモで紹介しました。

AzureのLinux仮想マシンにログインした状態で、/etc/waagent.confという構成ファイルを編集します。

ResourceDisk.Format=y
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=4096

とします。スワップサイズは4096MBとしました。次の再起動から、スワップが使われることになります。

f:id:itstaffing:20180308161454j:plain

仮想マシンをイメージとして保存し、展開する

クラウドの利点は、必要な時だけ利用できるということです。費用を節約するために、使っていない仮想マシンをイメージとして保存し、必要な時だけ展開する方法が考えられました。イメージを展開して、利用できる状態にすることを「プロビジョニング」と呼びます。

OSの指定には、次の3通りがあります

・マーケットプレイスから選択・・・Azureに最初から用意されているイメージ
・カスタムイメージから・・・カスタマイズした仮想マシンを保存したイメージ

(1)OSのインストールと構成
(2)一般化
(3)イメージ作成

・VHDから・・・Hyper-Vで作成した仮想マシンのVHDファイルをアップロード

今回は、カスタムイメージから作成する方法をデモしました。仮想マシンに設定とアプリケーションインストールを施したあと、一般化します。一般化とは、サーバー固有の情報を削除すること。WindowsのSYSPREPの機能に相当します。

f:id:itstaffing:20180308161457j:plain

Linuxの場合、アカウントは展開する際にrootユーザーとは別に追加されます。その際に元あったユーザーとの重複を避けるため、仮想マシンの一般化には、以下のコマンドを利用します。

sudo waagent -deprovision+user

「+user」とすると、前回の展開時に追加したユーザーの情報を削除します。

一般化ができたら、仮想マシンをイメージに保存します。仮想マシンイメージを作成するには、キャプチャの機能を利用します。「キャプチャ」というボタンをクリックするとメッセージが表示され、そのまま進めるとイメージができます。その後、もともとあった仮想マシンが削除され、課金対象でなくなります。その後、何度でもイメージリソースから仮想マシンを展開できるようになるのです。

仮想マシンとネットワーク

仮想マシンを再展開する際には、仮想ネットワーク(VNET)を考える必要があります。VNETとはAzureの仮想マシンの接続先のスイッチのこと。オプションとしてVPNを設定すれば、社内などの外部ネットワークから接続できます。

Azureの仮想マシンは、常にDHCPクライアントになるため、そのままではIPアドレスが予測できません。ただし、IPアドレスの予約は可能。それによって、IPアドレスを固定することができます。帯域の利用料金は、Azureから外に出るほう、つまりアウトバウンドは有料で、インバウンドは無料となります。

「VNETにはさまざまな接続のパターンがありますが、いずれも仮想ネットワークに『ゲートウェイサブネット』と呼ばれる中継専用のサブネットを追加し、その上にサブネットを作ります。作業自体は簡単ですが、構成に40分ほどかかります」

f:id:itstaffing:20180308161500j:plain

Azure内ではVPNゲートウェイを必要としない「VNETピアリング」を使い、仮想ネットワーク同士を接続します。外部、つまり会社などからアクセスする際には、「サイト間接続」または「Express Route」を使います。サイト間接続はインターネットを利用し、Express Routeはマイクロソフトの契約したサービスプロバイダーに直接接続します。そのほか、管理者などが外出先から接続する「ポイント対サイト接続」があります。

ポイント対サイト接続は、もともとWindowsだけをサポートしていましたが、2017年からLinuxとMacのサポートを追加。つまり、iOSとAndroidからも利用できるようになりました。AzureがIKEv2をサポートしたためで、LinuxやAndroidではstrongSwanクライアントというモジュールを使います。

デモで具体的に手順を示しながら、「Microsoft Azureから使うLinux」を解説してきました。Azureの仮想マシンは、2016年の時点で世界の1/4、日本の1/3がLinuxでしたが、昨年の情報では世界の40%がLinuxになったようです。マイクロソフトとしては60%をLinuxにしたいとのこと。今日のセミナーを踏まえて、Azure×Linuxの知見を深めていきましょう。

【イベントレポート】裁判から学ぶ!成功するシステム開発に必要な人材になるには

株式会社リクルートスタッフィングが運営するITSTAFFINGでは、弊社に派遣登録いただいている皆さまのスキル向上を支援するイベントを、定期的に開催しています。2018年1月12日には「成功するシステム開発は裁判に学べ!」を開催。

元東京地方裁判所調停委員で、書籍「成功するシステム開発は裁判で学べ!」の著者でもある細川義洋さんを講師にお招きし、泥沼にはまらないために、エンジニアが知っておくべきこと、やって良いこと・悪いことなどを、裁判事例をもとにわかりやすく紹介していただきました。そのイベントの様子をご紹介します。

f:id:itstaffing:20180222152618j:plain

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

・過去の判例からITプロジェクトにおけるユーザーとベンダーの責任を解説
・ワン オブ ゼムにならないために「踏み込んで意見を言えるか」が重要
・技術者がやってよいこと・悪いことなど、派遣スタッフからの質問を一部紹介


【講 師】細川義洋さん
▲【講 師】細川義洋さん
NECソフト、日本アイ・ビー・エムでエンジニアやコンサルタントとして活躍した後、日本国内にも数十名しかいない「IT事件担当の民事調停委員」に推薦され着任。2017年春まで数多くのIT紛争事件の解決に寄与してきた。『成功するシステム開発は裁判で学べ!』(技術評論社)ほか、著書多数。

「できない」と伝えるのはベンダーの義務

最初に紹介された事例は、ユーザーサイドとベンダーサイドの責任について。システム開発分野では有名な判決事例だそうです。

f:id:itstaffing:20180222152628j:plain
▲東京地裁で公開されている判例からユーザーとベンダーの責任についてよく分かる事例を採り上げて紹介。

ある健康保険組合のシステム開発で、2億5千万円規模の案件だったが、開発が進んでいくうちにユーザーから「画面を変えて欲しい」「登録機能を頼んだけれど編集機能も追加してほしい」など、後から次々と新たな要望が出されました。結果として、開発期限を過ぎても完成せず、ユーザーが代金の返却と損害賠償を請求したとのこと。

「さて、この裁判はユーザーとベンダーのどちらが勝訴したでしょう?」と細川さんが参加者に問いかけると、会場内ではユーザー勝訴が1名、ベンダー勝訴が多数を占めた。

しかし、実際の裁判結果は「ユーザー勝訴」でした。「なぜ?」という参加者の疑問に、細川さんが次のようにわかりやすく解説されました。

「ベンダーはシステム開発の工程をよく知る、いわば玄人です。(システム開発工程の)素人であるユーザーが、いろいろ要望を出してきたら、玄人は『それはできません。この工期と費用では難しい』とあらかじめ伝える義務があります。これを怠った場合、プロジェクト管理義務違反となりベンダーが責任を果たしていないことになります」(細川さん)

f:id:itstaffing:20180222152631j:plain
▲裁判での難しい専門用語はわかりやすい言葉に置き換えて説明してくださるので、参加者にも、とてもわかりやすい。

「できません」と言うのは、権利でなく義務だと認識することが重要だそうです。

また、その反対の事例として、ユーザーの協力義務違反となる事例も紹介。ユーザーも「技術のことはわからないから」の一点張りでは通用せず、わからなければ、人を雇ってでも、既存システムについての調査をして、ベンダーに協力しなければなりません。企業の情報システム部で仕事をする人は、こうした点にも注意が必要です。

大切なのは要件の実現ではなく目的の達成

エンジニアが、いくらでも代えの利くワン オブ ゼムにならずオンリーワンの存在になるにはどうすればよいのでしょうか。そんなヒントも裁判から見えてきます。

近年では、分野によってアジャイルやそれに準ずる開発手法が普及しはじめています。しかし、細川さんによれば、アジャイル開発を進める多くの企業が「外部スタッフにはなかなか頼めない」と悩んでいるそう。というのも「この仕様おかしくないですか? 本当にこれでいいんですか?」と言える人でないとアジャイル開発を任せるのは難しく、外部スタッフだと、そこまで踏み込んでくれる人がなかなか見つからないというのが理由のようです。

その典型例が、旅行会社の航空券予約・決済システムの開発事例で、完成したシステムにPC上からサーバ上のデータベースを操作する「遠隔操作機能」が実装されていなかったため、訴訟に発展したケースです。

f:id:itstaffing:20180222152634j:plain
▲要件定義の内容に疑問を持ち声に出していくエンジニアがワン オブ ゼムにならずに生き残れる。そんな教訓になる事例。

この事例は、ユーザーの勝訴でした。ユーザーによる検収も済んでいるので、ユーザー勝訴の結果に疑問を持つかもしれませんが、細川さんによれば「裁判では検収は重要ではない」とのこと。要件定義書に書かれていなくても、業務に必要なものとして判断されればベンダーの責任になることがあるそうです。

遠隔操作は、旅行業のシステムでは半ば常識とされる機能で、実はこのケース、ベンダーが「自分たちは旅行業のことをよく分かっているから」と売り込んできたという経緯がありました。もし、そのベンダーが本当に旅行業をよく分かっているのならば「要件に遠隔操作機能が盛り込まれていませんが、本当にこれでいいのでしょうか?」と言う必要があったのです。

f:id:itstaffing:20180222152637j:plain
▲時折、自身のエンジニア時代の体験なども織り交ぜながらの講演は、エンジニアにとっても親しみやすい。

「大切なのは、要件を実現することより、契約目的を達成することです。要件にこだわる人は、仕様書に書かれた以上のものは作れません。しかし、開発の目的が分かって開発をする人は、ユーザーにとっても心強い存在。ワン オブ ゼムにならずに、生き残っていけるはずです」(細川さん)

不快であることを、まずは周囲に認識させる!

最後に技術者がやってよいことと、悪いことについて紹介してくれました。

前の勤務先からソースコードを無断で持ち出した例は、もちろんエンジニアの敗訴。しかも知的所有権がからむ刑事訴訟なので結果は重く受け止める必要があります。参加者からの「ソースコードそのものではなく、自分の頭の中にあるアルゴリズムを次の会社で使うのはどうか?」との質問に、細川さんは「厳密にはアウトですが、頭の中を調べることはできないので、厳密に運用することはできないのが実情」とグレーゾーンであるとの見解を示しました。

f:id:itstaffing:20180222152641j:plain
▲調停員として数々の裁判事例に目を通してきた細川さんに質問できる機会は、そうそうないため、参加者からは数多くの質問が寄せられた。

また、エンジニアが自分の身を守るため、過労死に関する訴訟についても紹介。派遣先と派遣元のどちらにも「安全配慮義務」というものがあり、エンジニアに精神的あるいは肉体的に過度な負担があると認識している場合は、負担軽減措置をとらなければなりません。

「もし就業先で精神的・肉体的に過度に不快ならば、それを周囲に認識させるということが大切です。『それぐらい我慢しろ』と言われるかもしれませんが、言って損はありません」(細川さん)

訴訟という、普段は馴染みのない世界にも、エンジニアが生き残っていくためのヒントが数多くあるということが新鮮な体験でした。

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

株式会社リクルートスタッフィングが運営する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の場合は次のようなソースコードになります。

f:id:itstaffing:20180215162604j:plain

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

■事前に出題していた問題2(暗号問題)

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

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

f:id:itstaffing:20180215162607j:plain

■事前に出題していた問題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問。本番の問題にも、サンプルの問題のように答えから導き出されるキーワードがあります。それぞれ、解けた人から答えをネット上のフォームに書き込みます。それを随時、増井さんがチェックしていきます。

f:id:itstaffing:20180215162612j:plain

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

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

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

f:id:itstaffing:20180215162619j:plain

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

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

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

f:id:itstaffing:20180215162622j:plain

ここではすべて紹介することはしませんが、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を掛けて出力しています。

f:id:itstaffing:20180215162626j:plain

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