【イベントレポート】ますますニーズが高まる分野に注目！「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に設定します」

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

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

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

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

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コマンドが使えます。

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

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

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としました。次の再起動から、スワップが使われることになります。

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

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

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

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

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

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

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

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

sudo waagent -deprovision+user

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

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

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

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

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

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

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日には「成功するシステム開発は裁判に学べ！」を開催。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

株式会社リクルートスタッフィングが運営する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

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

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

---

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

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

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