ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

分かりそうで分からないでも分かった気になれる午睡チェックの仕組み補足

みなさんこんにちは。

午睡チェックのディレクター/スクラムマスターをしている保坂です。

この記事は、UniFaアドベントカレンダー 18日目の記事となっております。

先日AWS Startup Architecture of the Year Japan 2020 Live Finaleで、ルクミー午睡チェックのアーキテクチャが評価され、ユニファが優勝することができました。

tech.unifa-e.com

当日の生中継を見ていて優勝とった瞬間、とても興奮してslackに画面キャプチャを貼りまくっていたことを思い出します。 Well-Architected な仕組みに関してブログを見てください。

tech.unifa-e.com

さて、今回のブログでは、午睡チェックの仕組みの補足と、施策を実装してからの失敗談を書きたいと思います。

■センサーとタブレットの間

f:id:unifa_tech:20201215133816p:plain
その昔、冷静と情熱の間 って映画がありましたね。。

午睡チェックの構成は大きく分けると、

続きを読む

すき焼き鍋からタスク並列処理

この記事はユニファAdvent Calender 2020の17日目の記事です。

こんにちは、プロダクトエンジニアリング部のちょうです。最近天気は段々寒くなってきましたね。こんな時期欠かせない料理といえば鍋でしょう。鍋は煮ながら食べる料理ですゆえ、準備の手間はかからないし、好きな食材をどんどんいれることができます。

どころで、最近どれぐらい早く鍋をできるのを考えていました。例えば、炊飯器を15分でご飯を炊けるとする。その15分で鍋の食材を何も処理していない状態からホカホカの鍋にできるのでしょうか。

ここで、この鍋を人気のすき焼き鍋にしましょう。すきやき鍋は必要な食材はこちらです。

レシピから抜粋

  • 牛ロース肉(薄切り)
  • ねぎ
  • しらたき
  • えのきたけ
  • 焼き豆腐
  • しいたけ
  • 白菜
  • サラダ油

割り下については、市販のすき焼きのたれを代用。

ざっくりな料理の流れは

  1. 具材の下処理
  2. サラダ油でねぎと牛肉を炒めて、すきやきのたれを回しかける
  3. 鍋に具材を入れて煮込み

家に二口のコンロはあれば、炒めるのと鍋の煮込みを同時にできます。そして下処理も同時にします。フライパンが熱くなるまではちょっと時間がいります。鍋に水とすきやきのたれを入れて沸騰するまでは5分ぐらいかかります。なので

  • 鍋に水とすきやきのたれを入れて煮る
  • ねぎを下処理する
  • フライパンにサラダ油を入れて中火にする
  • 牛ロース肉を下処理する
  • フライパンが熱くなったらネギをフライパンにいれる
  • ネギに焦げ目がちょっとでたら、牛ロース肉をフライパンいれる
  • のこり時間でほかの具材を下処理する(硬いから柔らかいもの順)
  • 硬いものから柔らかいもの順で鍋にいれる

が一番効率でしょう。

すきやき鍋料理の流れ
すきやき鍋料理の流れ

この料理の流れを技術的な視点からみると、コンロ2口プラス料理する人で実質三プロセッサーです!言い方はちょっと変かもしれませんが(料理する人はコンロではない)、同時に処理することでスピードが上がったのはたしかです。

並列処理の中で、これはタスク並列処理と分類されると思います。もうひとつ、データ並列処理がありますが、それはすべてのプロセッサーはが別々のデータに同時に同じ処理を行うというタイプです。

タスク並列処理では、各タスクの間依頼関係があると、その前後関係が決められます。逆に依頼関係がないと、タスクは同時に行うことができます。例えば、フライパンでネギと牛肉を炒めるのは、先にネギをいれるのです。牛肉はあとなので、 ネギ > 牛肉 という関係があります。そして、フライパンが熱くなるまでネギをいれないので、 フライパンが熱くなる > ネギ という関係があります。最後、ネギを下処理しないと、フライパンにいれないので、 下処理前のネギ > ネギ という関係があります(同じく 下処理前の牛肉 > 牛肉 )。まとめると

  • ネギ > 牛肉
  • フライパンが熱くなる > ネギ
  • 下処理前のネギ > ネギ
  • 下処理前の牛肉 > 牛肉

並列処理では、この関係を満たされば問題ないです。一つの答えは

料理する人 コンロ
ネギを下処理する
牛肉を下処理する サラダ油を入れ、中火
ネギをいれる
牛肉をいれる

タスク並列処理ではどれぐらい早くなるのは、依頼関係の洗い出し及びプロセスの設計が重要です。

ネギの下処理とコンロの中火を一緒やってしまうと、下処理に時間がかかって、コンロに警告が出て自動的に止まることもあります。安全のために、ネギを先に処理するのがおすすめです。こういうタスク間で直接ではない関係性も含めて考慮しましょう。

ではプログラムでシミュレーションしましょう。

import org.junit.jupiter.api.Test
import java.util.concurrent.CountDownLatch
import java.util.concurrent.TimeUnit

class SukiyakiTest {

    class StoveCell() : Cell() {
        private var waitingForBeef = false

        override fun receive(context: CellContext, event: Event) {
            when (event) {
                TurnOnStoveEvent -> context.schedule(500, TimeUnit.MILLISECONDS, FryingPanReadyEvent)
                FryingPanReadyEvent -> context.parent.tell(event)
                AddLeekToFryingPanEvent -> {
                    waitingForBeef = true
                    context.schedule(2000, TimeUnit.MILLISECONDS, WaitingForBeefEvent)
                }
                AddBeefToFryingPanEvent -> {
                    if (waitingForBeef) {
                        waitingForBeef = false
                    }
                    context.schedule(4000, TimeUnit.MILLISECONDS, DoneEvent)
                }
                WaitingForBeefEvent -> if (waitingForBeef) {
                    context.logger.info("牛肉を待つ")
                }
                DoneEvent -> context.parent.tell(event)
                PoisonPill -> context.stopSelf()
            }
        }
    }

    class ChefCell(private val latch: CountDownLatch) : Cell() {
        private var _stove: CellRef? = null

        private val stove: CellRef
            get() = _stove!!

        override fun start(context: CellContext) {
            _stove = context.startChild(StoveCell())
            context.logger.info("ネギを下処理する")
            context.schedule(1000, TimeUnit.MILLISECONDS, TurnOnStoveEvent)
        }

        override fun receive(context: CellContext, event: Event) {
            when (event) {
                TurnOnStoveEvent -> {
                    stove.tell(TurnOnStoveEvent)
                    context.logger.info("フライパンにサラダ油をいれ、中火")
                    context.logger.info("牛肉を下処理する")
                    context.schedule(2000, TimeUnit.MILLISECONDS, AddBeefToFryingPanEvent)
                }
                FryingPanReadyEvent -> {
                    context.logger.info("フライパンにネギをいれる")
                    stove.tell(AddLeekToFryingPanEvent)
                }
                AddBeefToFryingPanEvent -> {
                    context.logger.info("フライパンに牛肉をいれる")
                    stove.tell(event)
                }
                DoneEvent -> {
                    context.logger.info("できあがり")
                    stove.tell(PoisonPill) // to stop stove
                    latch.countDown()
                }
            }
        }
    }

    object TurnOnStoveEvent : Event
    object FryingPanReadyEvent : Event
    object AddLeekToFryingPanEvent : Event
    object WaitingForBeefEvent : Event
    object AddBeefToFryingPanEvent : Event
    object DoneEvent : Event

    @Test
    fun test() {
        val latch = CountDownLatch(1)
        val system = CellSystem()
        system.add(ChefCell(latch))
        system.start()
        latch.await()
        system.stop()
    }
}

CellSystemが私が作ったActorモデルのスケジューラーシステムです。Actorモデル自体もタスク並列処理にピッタリするモデルです。コードの中各ステップの時間:

  • ネギ処理 1
  • 牛肉処理 2
  • フライパン熱くなるまで 1
  • ネギを入れてから牛肉を入れるまで 2
  • 牛肉をいれてからできあがり 4

単位は秒ですが、実質は10秒20秒単位と思ってください。

結果

2020-11-30 16:42:32.888 [worker-0] INFO  cell://ChefCell - ネギを下処理する
2020-11-30 16:42:33.897 [worker-0] INFO  cell://ChefCell - フライパンにサラダ油をいれ、中火
2020-11-30 16:42:33.897 [worker-0] INFO  cell://ChefCell - 牛肉を下処理する
2020-11-30 16:42:34.400 [worker-1] INFO  cell://ChefCell - フライパンにネギをいれる
2020-11-30 16:42:35.902 [worker-1] INFO  cell://ChefCell - フライパンに牛肉をいれる
2020-11-30 16:42:39.908 [worker-1] INFO  cell://ChefCell - できあがり

ここでworker-0は料理をする人です。worker-1はコンロです。

いかがでしょうか。普段の生活からも並列処理に関する知識も潜んでいますね。並列処理が人間の生活をモデルにしたといっても過言ではありませんね。時間があったら、ぜひまわりのことをタスク並列処理で考えてみてください。

最後に、ユニファが一緒に働いてくれるメンバーを募集しています。興味がある方ぜひ見てください。

採用情報 - ユニファ株式会社

Local Development with LocalStack

こんにちは。プロダクトエンジニアリング部の杉本です。

この記事は、UniFaアドベントカレンダー2020 の16日目の記事になります。
(私事ですが、2020年6月にユニファにjoinして半年がたち、初めてのブログ投稿です!)

皆さんは、AWSマネージドサービスに依存する機能を開発する場合、ローカルでどのように動作確認をされていますか?

  • 実際のAWS環境にローカルから接続する
  • レスポンスをスタブ化する*1
  • ローカルはそこそこに、とりあえず検証環境にデプロイして確認する

他にも様々あり、プロジェクトのフェーズや事情によっていずれも選択肢になりえると思います。
でもそれに相まって、多少なりともかかるコスト誤接続や誤操作によるリスク動作確認不十分な品質 など課題もでてきますよね。。。

今回は、そんなときにオススメな LocalStackを紹介したいと思います。

続きを読む

7月から始めた英会話のお話

こんにちわ。プロダクトマーケティングに所属している鈴木です!

この記事は、UniFaアドベントカレンダー 15日目の記事となっております。

そろそろ新しい年をお迎えすることになりますので、新しいことを始めたいと考える方も増えそうということで、 少し前に英会話を始めまして、今までのことを書かせていただければと思います。 英会話を始めようと思っている方の役に立てば幸いです。

私はDMM英会話を使っており、その前提でお話をさせていただきます。

また、英会話レッスン25分+15分の予習や復習で1日の英会話に使う時間は40分ほどです。

ちょっと先生が怖そうな描写もありますが、基本的に先生方はとてもやさしい人が多いです。

始める前の状態


質問されても言っている意味がわからないし、なんて返答すればいいかもわからないレベル。

辛うじて読むことはできる。がしかし単語力がほぼ失われている状態。

はじめの1週間 


先生の困惑した表情とため息に何度も心が砕けそうになります。

こんなに話せないものなのね。。。と愕然しました。

このタイミングでやったレッスン内容は写真を英語で描写するというものです。

言いたいことをグーグル翻訳使って翻訳し、それを伝えるので精一杯でした。

始めてから1か月


はじめの1週間でやることが何となくわかってくるので、すこし予習(ズル)をするようになりました。 レッスンで使いたい教材は事前に選べるのでグーグル翻訳を使って写真を描写してメモしてました。

そのメモを読むときは自信満々なのですが、それ以外は急に勢いが無くなるイメージです。 だた、やっと自力で頑張って伝えてみたりするようになります。間違っているので伝わらないのですが。

来る日も来る日も写真の内容を英語で描写する毎日です。

始めてから2か月


2か月目も写真を描写し続けました。 写真題材にレベルがあり、ちょっと難しいのを選んでみようと思えるようになります。 そして、もちろん完ぺきではないのですが写真描写に飽きるという状態がやってくるのです。 写真を描写するのは伝えたい文章を自分で作るトレーニングになるのですが、日常生活であんまり話すイメージが湧かず、もっと会話の方を鍛えたいと思いました。

最初では考えられない状態です。

始めてから3か月


3か月目からは、デイリーニュースという長文の文章を読むレッスンに切り替えました。 これは先生が読んでくれたあとに、自分も後に続いて読むというのを行い、内容確認のための質問や自分の考えを聞くような質問をされる内容です。

これが、中学校の授業のような感じで私としては非常に面白くなかったので1週間ほどでやめました。 次に、選んだのがフリートークになります。英語を話せるようになりたいのであれば話さないとだめだろう。であればフリートークだよね。という考えでした。

ただ、フリートークが思っていた以上にハードルが高く、いかにまだまだなのかと思い知らされる結果になりました。

まずフリートークなので話題が必要になります。「で?何について話したい?」と言われたりすることがあるのですが、正直こちらとしては何でもいいんですよね・・・。うまい先生は話題を広げたり、質問してくれたりするのですが、なかなかうまくいかないこともあります。 この時の対処法としては、後々思いついたのですが最近自分に起こったことを話す。というものです。 そうすると、自分事で作文するので良いトレーニングになります。

次に先生が何言っているかわからないです。テキストがないので。 正直笑顔で、わかったふりもたくさんしました。今でもしてます(笑)

最後になんて言っていいかわからないです。すぐに文章なんて作れないので。 なので、聞いた単語で言いたいことを何となく把握して、グーグル翻訳で翻訳して伝えるということを繰り返してました。

ただ、あまりにもスムーズじゃないので、「レッスンのテキスト使った方がいいよー」と言われることが良くありました。

やっぱりフリートークもやめようか・・・写真を描写に戻ろうか・・・ と何度も脳裏を過りますがここは踏ん張りどころだな。と思い耐えました。 話したいなら話し続けなければと。

始めてから4か月


なかなか難しいな・・・。と思っていたのでどうしたらいいかといろいろ悩んだ末、このころから取り入れたのがシャドーイングというトレーニング方法でした。英語の音声を追いかけて読むようなトレーニングで、同じ文章を何回も読みます。YouTubeなどで無料のがあるのでそれを使ってます。1日10分とか15分程度ですが...。 これの効果も相まって?耐えたから?少し話すのが楽しくなる場面が出てきます。 全然拙いのですが、先生もうんうんと聞いてくれて「つまりこう言いたいんだよね?」 と教えてくれることが多くなった気がします。 コロナで仕事以外では誰とも話さないことも多いので、ちょっとこの時間がたのしみ。とすら感じるようになります。

始めてから5か月


5か月目もひたすらフリートークを続けました。 4か月目よりは少しまともな会話はできてきたかなと感じます。 先生とコロナの状況を話したり、いろいろな国のことを聞いたり、女性の先生から彼氏の愚痴をずっと聞いたりもました。「ケンカ中で、彼の言い方がムカつく」のだそうです。 一番面白かったのはスターウォーズの話から宇宙の話になり、「もしこの宇宙で生物が存在するのは地球だけだとしたら孤独だよね」という話をして「同じ地球人なんだからみんな仲良くしないとですね」という会話もしました。グローバル感が凄いですね。(笑)

ちなみに、先生の多くはネットフリックスユーザーが多いのでネットフリックスの話題かアニメの話(ジブリと新海誠)や漫画(ワンピース・ナルト・鬼滅の刃)の話はとても盛り上がります。 日本のことを聞かれたり、今まで行った海外旅行の話なんかも良く聞かれます。

まだまだ拙い英語力で単語の一点返しで伝えてしまうこともありますが、極力文章を組み立てながら話そうと努力しています。

最後に...


学習って大体同じような工程だなぁと思っています。よくRPGなどに例えられていますよね。 進め方も攻略も自分次第。 Pythonも鋭意勉強中なのですが、何度も壁にぶつかってやっとほんのり使えるかも。となってきた次第です。また高い壁が見えてます。 道のりは長いですがPythonも英会話もその工程も含めて楽しみながらマスターできればと思います。


ユニファでは保育現場の課題解決のため家族コミュニケーションを豊かにするために一緒に働いてくれる仲間を募集中です!!

www.wantedly.com

転職して約半年、振り返ってみるとチームの良さが見えてきた

こんにちは。QAの坂口です。 この記事は、ユニファAdvent Calender 2020の14日目の記事になります。

私は今年8月にユニファへジョインしまして、品質保証業務に携わらせていただいています。 本投稿では、私の業務内容、弊社QAチームの魅力、そしてユニファの社風について書いてみようと思います。

続きを読む

スキルマップ作って採用につなげた話

こんにちわ。ユニファでUIデザイナーをしている中村です。
この記事は、UniFaアドベントカレンダー 13日目の記事です。

まだ入社して3ヶ月程度で、つい先日試用期間が終了いたしました。特に何も変わらないのですが、試用期間をぶじに生き抜くことができてホッとしています。

さて、いきなり本題ですが、先日チームメンバーみんなで「スキルマップ」というものを作りました。

もともとこういうのは作りたいよね、みんなの得意不得意がわかるといいよね、最近新しい人も入ってきたしね(ぼくですね)、などとは話していたのですが、新しいメンバーを採用する際に、いよいよチームとしてどういう人を採っていきたいのか、という課題が浮き上がってきまして。

じゃあ、それを解決するにはみんなのスキルを可視化する必要があるよねということで、そんなこんなでチームスキルの可視化プロジェクトが人知れずぼくの手に渡りました。

スキルマップづくり

f:id:unifa_tech:20201208211709j:plain
マップで使う用にとりあえずスキルいっぱい並べてみた。クリックで拡大します

スキルマップと一口にいっても、様々な方法論、アウトプットがあります(スプレッドシートで◯Xつけるとか)。今回はどうしようかと思ったのですが、ちょうどこの話の前後でMiroの話題が出ており、みんな興味ありそうだったのでMiroでやってみることにしました。Miroの説明は割愛しますが、オンラインホワイトボードです。あ、説明してしまいました。

f:id:unifa_tech:20201208212123j:plain
ぼくのスキルマップです。JSまわりは苦手ですが好きです。プレゼンは機会あったのでわりと得意ですが好きではないです。
大きな画像はこちらです。

どこかで見たスキルマップの記事を参考にしながら、上記の画像のように好き/嫌い、得意/不得意の軸をつくり、事前にマップにぺこぺこスキルを貼り付けていってもらいました。その後、みんなでわいわいそれについて会話してみたんですが、もうこの時点でちょっと面白かったです。

  • Aさん、ここの領域じつは強かったんだ?
  • ここの部分ってすごい得意そうだけど、好きではなかったのか…。
  • こういうのBさん本当に興味ないですよね知ってました。
  • Cさんそのスキル、もっとずっと得意でいいと思う。

みたいな話がたくさん出てきて、単純にチームの相互理解につながるというか。特にぼくは入社して3ヶ月の新米ですから、みなさんのスキル傾向が知れるだけでもありがたい。そしてきっと、今後入社してくれる方にも、このスキルマップを見せればもう誰がなにが得意なのかまるわかり!やった!そういう意味でも有意義なマップを作ることができました。

個人のスキルマップから、チームのスプレッドシートへ

スキルマップを作ったことにより、みんなのスキル傾向はわかりました。でもそれって、結局は個人のマップでしかなく、チームとしてどうなのかは把握できないんですよね(人数多くないのでふんわり把握できるんですが、それはそれ)。なので、スプレッドシートでカウントして、得意な人が多いスキル、得意な人が少ないスキルなどをピックアップしてみました。

f:id:unifa_tech:20201209010635j:plain
赤裸々すぎるので詳細はボカしました

結果としては

  • AfterEffectsやアニメーションなどは、業務として使えてないのでほぼみんな「苦手」ですが、興味や課題感はありそう。5名中、3名が伸ばしたいスキルに。
  • ディレクション系は「得意」な人が複数名いますが、好きな人は少ない。基本的に、やりたくないみたい。
  • パーソナリティ部分の好きはみんなかぶっているので、チームメンバーの気は合っていそう

などの所感が得られました。
いや、実際にはもっといっぱい所感は得られたんですがはしょりました。

AfterEffectsなどは、AdobeMaxでもセッションありましたが、マイクロインタラクションやモーションがみんな興味ありそうですね。つい最近、チーム内の発表でもありましたし。

チームとしての特性もぼんやり見えてきたところではあるので、このシートについてみんなで少し会話をしつつ、ではどんな人が来てくれたら嬉しいのか?という点でディスカッションを重ねます。スキルマップをここでも活用していて、来て欲しい人のイメージを浮かべながら、UIデザイン強い人がいいよね、コードは無理にわからなくてもいいよね、などと言いながら、架空の誰かのスキルマップをつくり、人物像を作り込んでいきます。

言語化してペルソナ化

チームメンバーと会話していくうちに、だんだんこんな人かなぁという像は見えているのですが、それをきちんと言語化して、対外的にもわかりやすくするために最終的にペルソナに落とし込んでいきました。ペルソナの作成法もいろいろ手法あるかと思うのですが、今回は古典的な手法である「想☆像☆力」でつくりました。

新デザイナーさんのスキルマップを見ながら想像していきます。ビジュアルデザインがこれだけ強いということは、事業会社よりも制作会社でデザイナーやってたんじゃないかな。チーム開発がこの位置だから、きっと事業会社の経験もそこそこあって。昔はSketchを使ってたけど、最近ではXDで……などなど。

結果、こんな感じの方をチームでは求めているということに。

f:id:unifa_tech:20201209011445j:plain
赤裸々すぎたのでボカしました

採用にペルソナがあるとはかどる?

一般的なペルソナの効果として、複数の関係者のイメージが共有される、判断に迷ったときの指針になる、などがあるかと思いますが、これは採用でも効果があります。

こちらからアプローチをかける際にも、イメージが統一しているのでブレがない。書類選考でも、必要なスキルレベルがはっきりしているので、判断に迷いがない。旗をたてる効果のあるペルソナ作成は、採用でも有効に作用しました。

ただ、ペルソナはあくまでもその時ほしい人材のイメージでしかないため、今後はペルソナも更新をかけていく必要があります。このペルソナを作ってから時間も少し経ち、ぼく個人としても違う印象を持っています。また、スキルマップそのものも、同じスキルで3年後もいるわけがないと思うので、定期的に見直しが必要です。今まで好きだったスキルが、なぜか嫌いに落っこちているケースもあるでしょう。人には歴史があります。

ペルソナ作成はそれなり時間がかかりますが、指針を決めておくことは大きな意味があると思います。広く採用活動をはじめる際には、少し時間をとってチーム内で対話してみるのはいかがでしょうか? 副産物として、チーム内の理解が深まります!

最後ですが、これずっと採用の話をしていたわけなので、つまりデザイナー募集しています。デザイナーだけじゃなく募集しています。詳しくは下記からご確認ください。

それではよいお年を!

unifa-e.com

上司「たじーには恐怖心が足りない」

f:id:unifa_tech:20201208014321p:plain
※「間違っているかもしれない」と自問自答によってアウトプットの質を高めよ、というフィードバックです。
こんにちは、プロダクトマネージャーの田嶋(たじー)です。
この記事は、UniFaアドベントカレンダーの12日目の記事となります。

今回のテーマは、「意思決定に伴う責任と、向き合い方」についてです。タイトルにある通り、今回は上司からのフィードバックを基にした振り返りです。まだまだ至らないことばかりですが、自戒のために記録します。

ちなみに本ブログのイラストは、#ジブリ字幕メーカー を活用しており、フィードバックの場のマイルドな空気感を再現しています!笑

【目次】

■0.はじめに

入社してわりとすぐ、上司から頂いたフィードバックがありました。
f:id:unifa_tech:20201208014620p:plain

・たじーは、上役の言ったことを信じすぎる傾向にある。
・正攻法が確立された領域においては、その分野の専門家・ベテランの意見が正しい可能性は高いが、そうではない可能性、特に移り変わりの激しい領域においては正しいとは限らない可能性もある。
・専門家やベテランの発言には一定の信頼と、敬意を示した上で、「なぜそれが妥当といえるのか?」「どうしてそのようになるのか?」というメカニクスを理解・検証しようとする姿勢が大切。
・また権威に限らず誰が言ったことでも同様に、自分の頭で考えるようにしましょう。

上役からすれば、部下が自分の指示通りに動く方が都合がいいのに、中長期的な目線を持ってフィードバックいただけたことを嬉しく思った記憶があります。

そんな最初のフィードバックから今日にいたるまで、数々の失敗・ご迷惑と、それら私の行動に対する有り難いフィードバックを頂いてきました。

今回はその中でも、ハッと心に刺さった「意思決定に伴う責任と、向き合い方」について自戒のために振り返ります。

■1.上流工程は、意思決定に大きな責任を伴う

※「上流/下流」の表現は、物事を進める初期/後期の過程を指しています。
f:id:unifa_tech:20201208014642p:plain

上司から、「上流の仕事とは、決して”自分の思う素敵なアイデアを下流の人たちに作ってもらう”ではないよ」と言われて、かなりハッとしました。

続けて、「上流工程ってね」と、例として、上司が実際に意思決定をする際に集めた膨大なデータを見せてくれました。(スプレッドシートを横スクロールし続けてもシートの終わりが見えないの初めて見た)

・何故こうまで泥臭いファクトの確認、情報整理に時間を費やしているか?「責任感だよ。」
・自分のお願いの先で動いてくれる沢山の方々がいる。彼らの時間を無駄にしないためにも、上流工程には最適な意思決定に責任がある。
・そのためにはファクトを集め、誰が見てもそうだと納得できる論理を組み立てなければならない。

振り返ると、「肌感では」「感覚的には」「〜だと思う」という言葉。意思決定の場面でも、私はあまり意識せずに使ってしまっていました。

・上流で仕事をするには、こうした言葉に罪悪感、嫌悪感を持たなくてはならない。
・この感覚がないと、軽はずみな意思決定と”臨機応変”の名のもとに、周囲を振り回すことになる。

前職では、わりと自分の裁量で意思決定できたのに対して、今は殆どの意思決定に上司や先輩が入って下さっていて、それもかなり細かく突っ込まれます。ありがたいと思いながらも、「自分で決めて良ければもっと早く進むのにな」とも少し歯痒く思っていました。

ただ、プロジェクトは、オンスケ進行のリリースがゴールではありません。本当に世の中に価値を生み出すことこそが、真のゴール。このゴールの達成に向けて同じ船に乗ってくださる方々のためにも、1つ1つの判断を、曖昧にやり過ごさない。意思決定を大事にやっていこうと思いました。

■2.責任を全うするために、どう意思決定をしていくか

今回は、フレームワークを用いるようなテクニックではなく、"姿勢"に焦点を当てたフィードバックを中心に振り返ります。

■2−1.悪魔の代弁者を立てる

f:id:unifa_tech:20201208080949p:plain 「たじーには恐怖心が足りない。来週のプレゼン、どうせ通ると思ってるでしょ?」
経営陣への企画プレゼンを控えたタイミングで、企画書の中途半端な出来栄えに対するフィードバックでした。

また別の先輩からもこんなコメントが。

例えば、〜〜ってどのくらい?〜〜ってどんなソース?とか考え始めると無限にでてきて、承認もらうまで不安で、ずっと情報集めたり、資料を作ってました。XXさんもよくおっしゃってますが、自分の中に意地悪な自分をつくって、ぜひスライドつくってください。私は100スライド近くつくって、実際は10スライドくらいしか使わなかったですが、質疑応答のときには、100スライドの中から20スライドくらい提示した印象です。

楽観視すると、備えが疎かになる。「きっと自分は間違っている」という恐怖心がアウトプットの質を上げる。悪魔の代弁者 を立てて、自問自答してみよ、というメッセージでした。

■2−2.クリティカルシンキングを実践する

悪魔の代弁者をより有意義なものにするための思考法として、上司から、以下のコメントと共に勧められた本がコチラです。

健全な批判的思考を自己・他者の両方に向けながら、素直さを発揮できると、もっとめちゃくちゃ良いパフォーマンスが出るんじゃないかと期待してます。

www.amazon.co.jp

ちなみに、本書ではクリティカルな思考法(適切な規律や根拠に基づく、論理的で偏りのない思考)として、大きく以下3つの要素を紹介していますが、この中で最も重要なのは、1.態度だそうです。どうやら、知識/技術の大前提にあることのよう。

1.問題に対して注意深く観察し、じっくり考えようとする態度
2.論理的な探究法や推論の方法に関する知識
3.それらの方法を適用する技術

そして、そうした態度を持ち合わせた人には【10の特性】があるそうです。

1.知的好奇心
いろいろな問題に興味をもち、答えを探そうとすること
2.客観性(★)
何事かを決める時、感情や主観によらず、客観的に決めようとすること
3.開かれた心(★)
いろいろな立場や考え方を考慮しようとすること
4.柔軟性
自分のやり方、考え方を自在に改めることができること
5.知的懐疑心(★)
十分な証拠が出されるまでは、結論を保留すること
6.知的誠実さ
自分と違う意見でも、正しいものは正しいと認めることができること
7.筋道だっていること(★)
きちんとした論理を積み重ねて結論に達しようとすること
8.追求心
決着がつくまで考え抜いたり議論をしたりすること
9.決断力
証拠に基づいてきちんと結論をくだすことができること
10.他者の立場の尊重
他人の方が正しい場合は、それを認めることができること

今の自分に当てはめてみた時、全体的に至らない点ばかりですが、特に★を付けたところ、まとめると「様々な立場からの視点を考慮し、ファクトに基づいて判断すること」を当面意識しようと思います。

そして、今後は意思決定の甘さについて再度フィードバックを頂くことがないように、精進していきます!

以上、ありがとうございました。

ーーーーーーーーーーーーーーーーーーーーーーーーーー
ユニファでは、新たな仲間を積極採用中です。
プロダクトマネージャーも大絶賛募集中!よろしくお願いします! herp.careers