エンジニア女子の日常

エンジニア女子が本、映画レビュー、ダイエット、仕事、技術について書いているブログです。

活用例で簡単にブロックチェーンを理解する〜ブロックチェーン初心者エンジニアが勉強会に参加したレポート〜

こんにちは。WEBエンジニアのrokoです。

 

近年、話題のブロックチェーン。言葉は知っているが、具体的にどういうものなのか、何かそんないいのかが、分かっていませんでした。つまり、ブロックチェーン初心者中の初心者です。

 

そこで、

oracle-code-tokyo-dev.connpass.com

に参加しました。

 

参加して学んだことをまとめていきたいと思います。

ブロックチェーンとはを簡単にまとめる

郵便に例えて、ブロックチェーンの流れをざっくり説明します。

ブロックチェーン図解

ブロックチェーン図解

まず、宛先を書き、カーボンコピー複数枚をあること想定してください。

電子署名

カーボンコピー全てにハンコを押します。郵便を信頼できることを認証します。

データ共有

関係がある人にカーボンを配ります。カーボンの内容を複数で共有します。

分解

複数あるカーボンコピーを切り離します。カーボンコピーを他の場所に保存しておき、

カーボンコピーがなくなって時でも、問題ないようにします。

台帳

カーボンコピーを順番は固定でどんどん収納していきます。このデータは外からは変更できないが、見ることは可能です。

 

なんとなくブロックチェーンの流れはイメージできましたかね?

ここで、カーボンコピーこそが、ブロックチェーンにおけるデータのことです。

ブロックチェーンとして再度、置き換えて説明すると、、、。

電子署名

鍵を使って、データを作成することで信頼あるデータを作成する。

データ共有

参加している企業に配ることで、他参加企業と共有ができます。

分解

データを複製し、他のシステムに保存しとき、データがなくなった場合を対策をしとく。

台帳

固定の順番で、不変のデータとして保存します。

 

って感じです。 

ブロックチェーンは、信頼性がある共有場所を作るイメージです。

なので、データベースというよりかは、ネットワークに近いかと思います。

ブロックチェーンを活用するとどんなことができるの?

色々な活用例が勉強会でも紹介されていました。

ブロックチェーンは、

  • 為替
  • 輸出、輸入
  • 製造工程

など色々と使われているようです。

個人的には、飛行機での旅行ツアーでの活用例として、とてもわかりやすかったので、紹介したいと思っています。

  

ユーザが飛行機を予約した場合、飛行機会社が電子署名を行います。

その後、

分離で飛行機予約情報を別のシステムに保存、

データ共有で、レンタカー会社やホテル会社に共有します。

そして、ブロックチェーン上の予約台帳に記録します。

 

このように飛行機予約情報を共有しておくことで、ユーザが乗った飛行機が遅延した場合などに、レンタカー会社やホテルに通知をいく仕組みを作ることができます。

 

すっごく便利ですよね?ブロックチェーンすごいって思いました!

プレゼンターへの質問と回答

初心者向けのQ&Aをピックアップして紹介します。他にも興味深い話がちらほら、、。

ブロックチェーンのデメリットって何?

便利でなんか凄そうなブロックチェーンですが、デメリットがあります。

DBと比べると、データを保存する処理、読み取り処理が遅くなります。

APIを叩いて、データを保存や読み取る処理と比べると、分離したり、データを共有したり、手順も多いですし、複雑だからです。

ブロックチェーンの勉強方法は?

ブロックチェーンでどこの部分に関わりたいかによります。

アプリケーションのレイヤーから、触ることが多いです。

1つわかると分かってくるので、とりあえず1つ触れてみるのがおすすめです。

(説明してないですが、ブロックチェーンにも色々なモデルがあります)

ブロックチェーン初心者がブロックチェーンの勉強会に参加した感想

とってもわかりやすい内容で、話を聞いているとしっくりくるものが多かったです。

どんどん実装しやすくなっているぽいので、簡単なモデルは作成してみようと思います。

 

今後も注目していきます!ブロックチェーンエンジニアの需要も高まってきてますしね!

ブロックチェーンについてもっと知りたい方は?

今日まとめた内容は、プレゼンが公開されていたので、ぜひこちらの資料をご覧ください!

(発表者も共有OKとのことでした)

 
また、同じ内容で、勉強会が開催されるということです。ぜひ参加してみてください。
 

AWS本著者に聞く!AWS初心者の質問「AWSをどう学習する?」〜オンラインイベント参加レポート〜

 

4月に以下のオンラインイベントに参加しました。

connpass.com

 

このイベントは、

の著者が集まって話すといったものでした。読んだら、書評かきますね!

 

早速内容をまとめようと思ったら、開催元でまとめてくださってました!

dev.classmethod.jp

 

せっかく参加したので、

Q&Aでまとめられていない話で印象に残っていること、参加してみた感想を書いて以降と思います。

AWS本イベントでのちょっとしたまとめ

Q.AWSの学習で困ったことはなんですか?

AWS公式は英語ドキュメント

公式の最新は英語のドキュメントで、英語が苦手で読むのが大変でした。

もちろん、日本語のドキュメントもあるのですが、変な日本語で理解するのが大変だったり、、、。

AWSの機能が多すぎる

AWSのが多いすぎて、どこから学んでいいか困りました。触っていく内にどんどんわかっていくのですが、最初は戸惑いますね。

クラウドデザインパターンが使えない

最近のAWSは機能が増えたこともあって、元々あったクラウドデザインパターンに当てはまらないケースも多々あります。

Q.AWSをどうやって学習するのがいいですか?

学習する目的をはっきりすることが大事です。

資格にとるにしろ、サービスを作るにしろ。

 

機能が多いので、実際に触って全てを勉強するのは難しいです。

だから、サービスをイメージしてアーキテクチャ設計していくのがおすすめです。

 

あと、AWSの公式のトレーニングに参加するのも。

aws.amazon.com

 

Q.AWSって最新のサービスがどんどん出ているがどうやってトレンドを追えばいいの?

学ぶのに近道はありません。

 

ある程度、AWSのサービスの歴史をみないと、最新のAWSサービスの目的が見えてこないです。

なので、最新のサービスができた経緯を知ることが大切です。

 

おすすめの方法としては、好きなサービスの1つ決めて、リリース情報を常に追うことですかね!

自分が知っているAWSのサービスであれば、どんな経緯でアップデートや、違う最新のサービスができたかわかると思います。

自分で知らないAWSのサービスであっても

などで情報収集しておくことが大切です。

 

reviews.hatenadiary.jp

AWS本イベントに参加してみた感想

AWS本を発売するような方でも、最初の悩みは同じなんだなって思いました。

私も、何度も学習し、機能が多すぎ、最新アップロードについていけないって挫折しています。

 

資格を目的にするより、作りたいサービスのイメージを目的にするっていう方法が自分の中でしっくりきたので、

AWSアソシエイトの資格の勉強しながら、サービスのイメージを目的にアーキテクチャ設計できたらいいなって思っています!!

 

頑張ります!

AWSを学習する初心者エンジニア

AWSを学習する初心者エンジニア



 

 

 

セキュリティ初心者のWEBエンジニアがセキュリティ勉強会に参加したレポート(メモ)

 

だいぶ遅くなってしまったのですが、4月にセキュリティのオンライン勉強会に参加しました。

ebisecboys.connpass.com

WEBエンジニア×セキュリティ初心者視点で、

  • ためになった内容
  • 面白いと思った内容

について簡単にまとめたいと思います。

 

セキュリティ勉強会の内容

セッション1:  初心者のあなたに捧げる Cloud Security ~何からはじめる?どうやって対策する?そしてCyber Security Sauna~

AWS×セキュリティに関するおすすめのスライド

私も読みましたが、セキュリティ初心者にも理解しやすいです。

AWSを使っていてもセキュリティを意識しないといけないのか?

責任共有モデルという考え方があります。

 

aws.amazon.com

責任共有モデルとは、簡単に言えば「AWSと利用者側が役割を分けて、セキュリティを担保しよう」って考え方です。

 

「自分のところは、自分たちでセキュリティやろうねー」

みたいな感じです。

だから、AWS利用者側もセキュリティ対策する必要性があります。

外部からの攻撃がAWSに!?

例えば、標的型攻撃(特定のターゲットに向けて、目的を持った攻撃)です。

標的型攻撃で社内ネットワークに攻撃され、その後利用しているAWSへ攻撃されて、、、。

ランサムなどのマルウェアが知らない内に、手元に入っていて社内ネットワークを攻撃していることも考えられます。

外部からの攻撃の対策は?

マルウェアは、OSやミドルウェアの設定の脆弱性を攻撃してくるケースが多いです。

だからこそ、サーバなどは常に最新化しておくべきです。

脆弱性診断自動化ツールなどを使って管理しましょう。

セッション2: セキュア・アーキテクティング入門

このセッションが1番勉強になりました!ぜひ、ここだけでもみることをおすすめします!

セキュリティマインド

セキュリティ対策は、

「コストや掛け捨て要素」ととらわれるがちですが、将来へ投資と考えるべきです。

 

個人情報が含まれているデータも存在します。

なので、リスクベースアプローチで

「漏洩したらどうなるのか」「漏洩したあとの工数はどうなるのか」

を想定して考えていくことが重要です。

ビジネスにも影響がありますしね、、。

セキュリティ設計において意識すべきこと(DevSecOps)

セキュリティは、ビジネスとも密接に関係してきます。

なので、

ビジネスの視点を入れて設計をしていかないと、思っていたのと違うもの

ができてしまう。このケースはよくあります。

 

リスクを考えた上で、どういう運用していくかを想定しての設計が大事です。

Cloudのどこにセキュリティ対策が必要?
  1. Security IN Cloud(利用者側で講じる領域)
  2. Security BY Cloud(クラウドベンダーやセキュリティベンダーが提供するサービス)
  3. Security OF Cloud(クラウドベンダー側の責任範囲)

の3つに分類が可能です。この3つの分類を先ほどの責任共有モデルと合わせると

  1. Security IN Cloud(利用者側で講じる領域)
    従来のサーバ管理と同じ。
  2. Security BY Cloud(クラウドベンダーやセキュリティベンダーが提供するサービス)
    AWSなどのセキュリティグループ(SG)やアクセスコントロールリスト(ACL)

がカスタマー側の責任範囲です。

 

セキュリティのリスクを下げるには? 

一般的な対策を講じるのはもちろん、早い段階での対策が重要です。

あとになればなるほど、セキュリティリスクが上がってきます。

 

セッション3: RSA カンファレンスの振り返り

YouTubeRSAカンファレンスの様子がみれる


RSA Conference Celebrates 15 Years of Innovation Programs

発表者おすすめのセッション

RSAカンファレンスでのおすすめまとめ|kaburimono-kyokai|note

 

セッション4:Building Secure & Reliable Systems の「敵対者を理解する」を読んだ

の1部の内容の紹介でした。攻撃者がどんなことを考えているかなど、、、。

 

セキュリティ初心者がセキュリティ勉強会参加してみた感想

よかったこと

  • プロの考え方に触れることができた
  • 新しい知識が増えた

悪かったこと

  • 正直興味が持てないセッションもある(オンラインだったので、今回はラジオ感覚で聞けたけど、、、。)
  • わからない言葉があると、調べながらになってしまい、メモが大変

 

オンライン開催ってこともあり、聞き取れなかったところや理解できないところは一旦止めて、自分のペースで聞くことができました。

 

新しい知見になるし、オンライン勉強会が多い今、ぜひ参加してみてはどうですかね、、?ぜひ一緒に!

エンジニアがオンラインセキュリティ勉強会に参加

オンラインセキュリティ勉強会

 

エンジニア志望の学生によく聞かれる3つの質問にWEBエンジニア3年目が回答してみた

私は、学生時代に、プログラミングをかじり、自分に向いているかもって思って、エンジニア就職をした、ごく普通のWEBエンジニアです。

詳しくは reviews.hatenadiary.jp

社会人となり学生の繋がりがなく、

「今の学生はどんなことを考えているんだろう」

という好奇心を抱き、OG訪問のサービスに登録し、エンジニア志望の学生と10人以上と直接話しました。

その中で、よく聞かれる質問があったので、自分なりの回答しました。

エンジニア志望する学生さんからよく聞かれる質問内容

質問1. 未経験でもエンジニアになりますか?

  1. エンジニアになれると思います。

経験がなくても採用してくれる企業や、研修が充実している企業もあります。

実力があればあるほど、企業に重宝される可能性がありますが、未経験だからなれないわけではないと思います。

また、いつからでもエンジニアに必要な学習ができる環境があると思います。

自分にあった学習方法でいいと思いますが、

といったプログラミング学習サービス、

といったプログラミングスクールなど、未経験でも気軽に技術を学習できるサービスがたくさんのあります。

結局のところ、

エンジニアになれるかではなく、なりたい

という気持ち(=やる気)があるかかなって思います。

質問2. ITエンジニアに必要な素質ってなんですか?

  1. 私は、探究心と論理的思考かなって思っています。

どんな仕事でも上記の2つは求められることは多いと思いますが、ITエンジニアは特に求められるかと思います。

課題の本質を見極めて、技術的アプローチを考えなくてはならないと考えているからです。

そこに、プログラミングや最新技術の活用が方法として生まれてくるため、基盤としてそうしたスキルや知識そして、常に進化していくITに対しての情報収集することももちろん、大事だと思っています。

ここは、エンジニア個人の思考性によるところだと思うので、一人一人違うと思いますが、、、。

質問3. ITエンジニアになるために、何を学習すればいいですか?
  1. まずは興味を持ったものから取り組むのがおすすめかなって思います。

すでに、こういうエンジニアとしてなりたいと決まっているのであれば、それに沿った学習をするのがいいと思います。

ですが、まだそうした将来像が決まっていないのであれば、

「こんなの作ってみたい」

「WEBの仕組みってどうなっているんだろう」

っていった興味から派生して、とりあえず取り組んでみるのがいいのではと思います。

これからエンジニアになろうと思っている方へ

IT業界は、流れが早く、エンジニアとして学ぶことが多いと思います。

大変だと思うかもしれますが、学びことが多い、学びが多いことこそ、エンジニアの魅力だと思います。

私もまだまだエンジニアとして、未熟ですが、日々学びを止めず、頑張ってます!!

お互い頑張りましょう!

エンジニアとして学習中の様子
エンジニアとして学習中の様子

エンジニアが障害を起こさないために学ぶミスしない人の思考法〜「なぜかミスをしない人の思考法」を読んだみた〜

 

エンジニアにとって、障害は恐いものですよね?

私も以前、テストケース漏れがあり、サービスリリース後障害を起こしたことがありました。( i _ i )

 

緊急で対応したのですが、冷や汗でましたね。。。

もう障害が起こしたくないなって思いました。

 

原因は、テストケースが足りてなかったことになったのですが、根本として

「なぜミスを起こしてしまったのか」

「ミスを起こさないためにどうしたらいいか」

を考えました。

その時に出会った本が

です。本書の内容に触れていきながら、障害を起こさないように何ができるかを考えた結果を共有したいと思います。

 

「なぜかミスをしない人の思考法」の内容

最初に、「なぜかミスをしない人の思考法」の内容に触れていき、その内容を受け、エンジニアとして障害を生まないように何ができるかの考えを書いていきたいと思います。

1章. ミスをしない人の基本ルール

基本ルールは以下の内容です。

  • 失敗シナリオから共通点を導く

  • 人のせいにしない人はミスが少ない

  • 大丈夫と思ったときこそ、慎重に

  • 無知、無視、過信は「失敗の3悪人」

  • 悪事は後悔して謝った方が損失は小さい

失敗シナリオから共通点を導く

似ている失敗のシナリオを理解していれば、7割のミスは事前に防げます。そのため、失敗シナリオを集約していくことが重要です。

人のせいにしない人はミスが少ない

自責感情を持ち、誰かが起こしたミスに対して明日は我が身と思うことで危機感を持てます。

大丈夫と思ったときこそ、慎重に

いつもやっていて大丈夫と思うことでも、慎重に見直すことでミスを防ぐことができます。

 

無知、無視、過信は「失敗の3悪人」

知らないこと(無知)でミスすることも

ルールがあると知っていても重要でないと判断し(無視)ミスすることも

証明がないのに絶対大丈夫(過信)と思ってしまうことも

ありますよね?

悪事は後悔して謝った方が損失は小さい

悪事に対して責任放棄したりすると、今後の信頼に関わる問題になります。今だけではなく、将来を見つめた行動をとりましょう。

致命的なミスはどうやって防ぐ?

ハインリッヒの法則はご存知でしょうか?

 

ハインリッヒの法則

引用:https://www.motivation-up.com/know/heinrich.html

 重大な事故:軽微な事故:小さいなミスが1:29:300で起きるというものです。

 

ハインリッヒの法則でわかることは、日常的なミスにはないところで、致命的なミスを起こす可能性が高いということです。

だから、作業で普段と違うことをする時は、致命的なミスが起こりやすいので注意することが重要です。

 

もしミスが起こった場合に対しても準備

リーダーがミス防止に強い関心を持っているだけで3分2の失敗は消えます。

もし自分がリーダーでもリーダーでなくても

  1. 希望的観測が入ったシナリオ
  2. 現実的シナリオ
  3. 最悪のシナリオ

を描くことで、万が一ミスがおきた場合も対処がスピーディーに行うことができます。

 

ミスから学ぶことは?

仮説から検証までを頻繁に行うことで、思い込みを打破することができます。

だから、ミスはすぐに捨てるのではなく、分析や検証を加えて、活用方法を考えていきましょう。

 

ミスを起こらない仕組み作り

人間であれば、ミスを起こしてしまうのは仕方がありません。

少しでもミスを起こさないために、機械による作業の自動化や、チェックツールの導入がとても効果的です。

また、個人で作業を完結するのではなく、複数人でチェックすることも大切です。

 

「なぜかミスをしない人の思考法」の内容をエンジニア業務で生かせること

1, 失敗(ミス)DB化し、知見を溜める

ミスへのシナリオの分析のためにも、ミスの事例をまとめる必要があります。

個人としてミスをDB化することも大事ですが、組織でミスの事例を集約できると尚良いです。

私の場合は、自分が「ミスしたな」って事柄に関しては、メモを残し、1ヶ月1回見直すようにしました。

 

2, 既存の仕組みであっても過信せず、丁寧に検証を行う

どうしても既存のシステムで起動しているものだど、流用しても問題ないと過信をしまいがちです。

ですが、その時に1歩立ち止まって振り返ることをしています。

既存を流用するのが、本当に正しいのかと、、、。

3, ミスを防ぐための自動テストツール、他者のチェック制度を導入する

個人ではないですが、組織として自動テストツールやエンジニア同志でのチェック制度は重要ですよね。

もし、自動チェックの仕組みがないのであれば、自動テストの導入を考えてみてはいかがでしょうか?

今後の運用コストやミスのリスクを考えた上で、 自動チェックツールを自分たちで開発してみるのもいいかもしれませんね。

 

弊社も、自動テストツールなどの導入は行っています。

エンジニアとして障害(致命的なミス)をしないためには?

小さいミスの知見をため、ミスの分析をすること

最悪の場合のケースを考えておくこと(リカバリーしやすい実装)

が大事なのかなって思いました。

 

エンジニアが障害を起こし、ミスしないと思っている様子

エンジニアが障害を起こし、頭を抱えている姿

 

 

 

仕事が早い&マルチタスクができる人の脳を理解したら、残業時間が減った話〜「人間とは何か」はすべて脳が教えてくれるを読んでみた〜

 

仕事ができる人ってどんな人だろう?

仕事ができる人って聞くとどんな人をイメージしますか?

それぞれの仕事できる人のイメージがあると思います。

そのイメージの中に

が思いついた人も多いのでしょうか?

 

私も、エンジニアとして業務をしていると

スケジュールが決まっているタスクがあり、早く仕事をしないといけない時、

メインのタスクがあるが、他部署から依頼や、緊急度が高いバグ修正の依頼が来た時、

など、仕事の的確で早くかつ、マルチタスクをおこなさないといけない場面が多々存在しますよね>

 

仕事を早くしないといけない時やマルチタスクの時に、どのようにすれば、スムーズに仕事ができるのか、、、、。

そのヒントが、たまたま読んだ

にあったので、共有したいと思います。

脳科学から見た仕事をバリバリこなす人の脳とは?

人間誰しも、めんどくさいことなどを先のばしにする脳が備わっています。

だからこそ、課題に対して理論的にアプローチするには、自制心が必要です。

また、繰り返しが多い課題には、我慢が必要になります。

 

システム運用をしていると、定期的に繰り返すタスクが存在しますよね。退屈だとしても、割り切って我慢、我慢。

でも、繰り返すタスクほど、他のタスクと並列になるケースが多いですよね。

運用対応していたら、別のタスクがくることも、、、。

 

先のばし脳に対して、仕事できる人はどうしているのか?

大きな課題を先延ばしにする前に、それを小さい目標に分解するということをしています。

小さい目標に分け、目標達成にご褒美を設ける。

そうすることで、目標達成に向けて、ドーパミンを出すことができ、やる気を維持できます。

マルチタスクをするコツは?

そもそも、脳は2つのことを同時に実行できません。1つ1つの処理が細分化されて、脳は処理しています。

だから、1つ1つのタスクを集中してことが大切です。

 

まとめると、タスクを細分化し、細分化したタスクに集中することが大事です。

 

実際に、脳科学で学んだコツを生かして業務をした結果

コツを意識する前

残業時間は月約5時間程度

 

コツを意識した後

残業時間が月1時間以下

 

と残業時間を減らすことができました。もちろん、担当しているタスクにもよりますが、業務を効率的に行えるようになりました。

残業時間を減らしたい方、マルチタスクに悩んでいる方はぜひ実践してみてください。

 

 

マルチタスクの仕事を早く行う女性

マルチタスクの仕事を早く行う女性


 

 

 

エンジニアが交渉術を学んだら、要件定義が楽になった話〜「大学生のための交渉術入門」読んでみた〜

なぜ営業でもないエンジニアが、交渉術に興味持ったのか?

私が以前、自己紹介のブログでも書きましたが、WEBエンジニアとして働いています。

 自己紹介ブログ↓

reviews.hatenadiary.jp

 

WEBエンジニアの私がなぜ、交渉術に興味を持ったかというと

 

企画者(=依頼主)とのコミュニケーションをもっとうまく取りたいと思ったからです。

 

というもの、新しくアサインされたPJでは、企画者はいたのでですが、ほぼ仕様という仕様はなく

「〇〇みたいのを作って欲しい」

といった要望のみでした。

だからといって全てを仕様の決定を全て託されるわけではなく、、、。

エンジニア側が仕様を考えて、企画者に提案していかないといけませんでした。

 

そこで、少しでも企画者とのコミュニケーションを円滑にし、エンジニアとしてやりやすい形に持っていきたいと考えました。

 

そのため、交渉術を学ぶことにしました!!

ですが、交渉術を学んだことがなかったので

を読んでみることに。大学生向けだし、分かりやすいかなっと。

 

 

「大学生のための交渉術入門」の内容

先に、「大学生のための交渉術入門」の内容について軽く説明したいと思います。

交渉で目指す理想像とは?

交渉とは、何かしらの問題を解決するために行われます。

ですが、問題解決には、自分と相手の対立や衝突が起き、葛藤が生まれます。

 

その葛藤を理解するのに、「シュミットの葛藤処理モデル」がヒントをくれます。

コンフリクト対処モード, シュミットの葛藤処理モデル

引用:https://accreteworks.com/publicseminar-latestinformation/conflictpattern

シュミットの葛藤処理モデルでは

縦軸が、「どれくらい自分の利害を主張するか」、

横軸が、「どれくらい相手の利害を考えられるか」

を表しています。

 

シュミットの葛藤処理モデルからヒントを得ると

エンジニアと企画者共に、目指したい理想像は「協働」状態ですよね。

 

「協働」という交渉での理想状態になるには

「自分のことだけではなく、相手を考える」

が重要そうです。

 

交渉で具体的にどういうことをすれば、協働の状態になるのか?

相手のことを考えることが重要とわかったところで、

どうすれば、相手の利害も尊重をしながら、自分の利害も捨てないようにできるのでしょうか?

 

 

それは「協調する」ことです。

協調とは、利害が対立したもの同志が、穏やかに問題解決すること指します。

(以後、協調する交渉のことを、「協調交渉」と呼びます。)

 

協調交渉での重要なことは?

協調交渉では

  1. 相手の考えに同意をする必要はないが、相手を尊重し、相手の能力を認める
  2. 相手の考えや価値観を理解する
  3. 双方で協力して相違点を明らかにし、様々な見方・考えを統合して解決策を導く

がことが重要です。

そこで、協調交渉での取るべき具体的な行動は

  1. 友好的な雰囲気作り
  2. 争点を明確にする
  3. 問題を見直し、最優先事項を絞り込む
  4. 代替案を提示し、双方が合意する

です。

こうした協調交渉での具体行動をする時には

  1. 相手との信頼形成に不可欠となる相手の考えにノーと言うべきときは言い、しかも、相手の能力を認める
  2. 双方の問題を合意に導くプロセスで必要となる、相手の見方を理解しようとする
  3. 意思決定や問題解決に不可欠な相違点を明らかにし、双方の考えを統合する

を意識することが大切です。

 

「大学生のための交渉術入門」読んで、要件定義に生かしたこと

「大学生のための交渉術入門」の内容はなんとなくわかってもらえたと思います。

では、私はどうやって交渉術を生かして、要件定義をしていったのかを共有します!

 

1. 企画者からヒアリング

交渉では、相手を理解することが大切なため、ヒアリングをたくさん行いました。

ヒアリングでは、

「〇〇みたいのを作って欲しい」

という要望を噛み砕くため、「どうして〇〇みたいのが欲しいのか」「なぜ〇〇みたいのがいいと思ったか」など、細かくヒアリングを行いました。

 

その結果、「〇〇みたいのが欲しい」のではなく、「こういった機能があるツールが欲しい」という本質的なニーズを知ることができました。

 

本質的なニーズを知ると、必要な要件(=最低要件)が見えてくるだけではなく、企画者の価値観を理解することができました。

 

2, ヒアリング結果から要件をまとめて提案からの合意

ヒアリングから最低要件をドキュメント化を行いました。

ドキュメントにまとめることで、ヒアリングが不十分だったところが可視化することができました。

 

不十分だったところに関しては、

「争点」として定義し、交渉を行いました。交渉の中では、優先度を定め、優先度に沿った代替案を提案しました。

 

交渉をした結果、エンジニア側も企画者側も「この要件にしよう」といった感じで、合意することができました。

 

システム開発の外注なら、複数社を完全無料で比較できるシステム開発一括.jpで。

 

交渉術を使って、要件定義をしてみると、、?

最初に「〇〇みたいのを作って欲しい」と言われた時は、「まじか、、」と思いました。ʅ(◞‿◟)ʃ

ですが、交渉術を知ると、要件定義が楽に行うことができました。

 

エンジニア側の利害を無視し、企画者側の利害を優先し、「順応」することや

エンジニア側も企画者側の利益も中間をとって、どちらか「妥協」すること

は簡単ですが、お互いが「協調」を意識して、交渉していくことで、

コミュニケーション工数を減らすだけではなく、精神的なストレスの軽減に繋がったと思います。

 

サービス開発をするエンジニアの多くは、企画者との調整は必ず存在すると思います。調整する際は、交渉術を生かし、話し合ってみたらどうでしょうか?

 

エンジニアと企画者の要件についての交渉中の様子

エンジニアと企画者の要件についての交渉中の様子