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

エンジニアとしてのキャリアを考える上で、スキルアップに不安を持つ方は多いのではないでしょうか。株式会社リクルートスタッフィングが運営する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

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

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

---

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

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

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