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

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

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

 

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

 

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

システム構想は、プロジェクトとしてきちんと予算を取り、必要ならばプロトタイプでしっかりとテストを行うべきで、できれば経営企画や情報戦略部門が担当するのが好ましいそうです。プロジェクトでは、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は何をするのでしょうか？一般的に『ディレクトリサービス』というと、案内状のことを指します。デパートの案内や、電話帳など。したがって、各情報の一元管理を担います」

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

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

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

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

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

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

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

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

基本機能のおさらい

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

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

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

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

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

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

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

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

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

トラブルシューティング

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

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

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

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

1．バージョン（変更回数）
2．更新時刻
3．GUID

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

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

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

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

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

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

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

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

新機能として、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に設定します」

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

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

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

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

---

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

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

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