見出し画像

「提案」のできるエンジニアのススメ

凪

こんばんは、凪です。
偉そうな2日目のタイトルになってしまいました。退職するにあたり、後進に向けて案件の情報だけではなく、私の仕事論やTIPSを書き残そうと思って今日の筆を執りました。これは社内向け要素を省いた二番煎じです。

改めて、私のエンジニアとしての自己紹介を簡単にします。
現職は新卒から数えて8年目、いわゆる大手SIerの中のフルスタックエンジニア兼PL/PM（という名の開発・管理・営業・人事もやる何でも屋）です。
フルスタックを名乗るのは毎度誇張が過ぎる気がしてしまうのですが、やってきたものとしてはこんな感じの人です。

  • フロントエンド：主にReact.js・React Native

  • バックエンド〜アプリ基盤：AWS・GCPなどのクラウドベース
    （時効ですがAWS Developer Associateは昔取りました）

  • CI/CD：Gitlab CI/CD、Jenkins

  • 仮想化：Docker・K8s
    （マルチマスタ/クラウドオンプレハイブリッドの冗長化構成の設計を昔やりましたが正直ドインフラは好きじゃない…）

得意なことはアプリ開発ですが、その中でも、お客様の課題について前に前に提案しながらスプリントを回していく、「主体性と提案力のあるリーダーシップ」がお客様にご好評頂いている部分のようです。
と、いうことで、もはや今では脊髄でしか話していないと公言している私が、その実一体どういうことを考えてそんなことをしているのだろうか、というのを言語化した記事を書いていきます。

前もって予防線を張りますが、記載している内容は、読む人が見れば当たり前のことの繰り返しであり、主に私のチームメイトの課題に対しての指摘・アドバイスです。従って各用語などを全て解説する構成にはしていません。また、デザイン思考関連については聞き齧り程度の知識でなんとかしてきた人間の記述です。
そんな有様でも「なんだかバイネームで長年ご指名を頂けるくらい評価頂いているぞ？」という人間の仕事論です。そのくらいの気分でご査収ください。


提案型リーダーシップの心得

これは、私が自分の仕事の進め方について勝手に称してみた俗称です。ただし、これは「リーダー」がおこなうものではなく、自己組織化された開発者が全員目指すものと考えます。
汎用的な言葉で置き換えると、以下の用語・要素を含みます。

  • アジャイル思考（スクラム）

  • ファシリテーションスキル

  • 仮説思考でのユーザーインタビュー設計

  • サービスデザイン思考

  • 人間中心デザイン

一つずつ紹介します。

アジャイル思考

ウォーターフォール型で取り組むにせよ、アジャイル・スクラムイベントに含まれる思想・メンバーの生産性を高めるための仕組みは知っておくと良いでしょう。
参考）https://www.unprinted.design/articles/scrum/

「YESマン」になるな

「アジャイル宣言の背後にある原則」の一文目にある、「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」を第一に考え続けましょう。
従って、顧客の指示・上司の指示に違和感がある場合はそれを解消せねばならないし、より良いアイデアがあるならば議論をすべきであり、停滞するならば自ら前に進めなければなりません。

そのために必要になるのが、主体性のある提案型リーダーシップであり、これを独善的なものにしないための「チームメイトの自己組織化」です。

スプリントは「一区切りの期間」 ではなく、ブラッシュアップのための区切りである

「継続的な改善」を図るのが「アジャイル」と「ウォーターフォール」の大きな違いです。
従って、検討し、実装（プロトタイプ作成）し、レビューによって課題を洗い出す、というサイクルを回すことが本質であることを忘れないようにしましょう。そのために「動くソフトウェア」に触れて、よりリアルな手応えをもとに課題を見つけることが重要視されるのであって、「1週間ごとに新機能が出来上がる素晴らしい仕組み」ではありません。

スクラムは自己組織化を求める考え方である

スクラムにおいて、「リーダー」はいません。
開発者は自由に発案し、相互に提案し、「より良いソフトウェア」を実現することが求められます。しかし、従来のウォーターフォール制や上司部下の関係性のイメージが強いメンバーは多いため、「リーダーがいない」という考え方を浸透させるのは難しいでしょう。
可能であればスクラムイベント（特にスプリントレビュー）では話し手を交代制とするようにして、「話し手（リーダー）と聞き手（部下）」のようなイメージの固定化を避けると良いでしょう。

注意するべきは、価値観のアップデートは「仕組み」だけで可能となるものではなく、「心理的安全性」「心理的余裕」「変化への柔軟性」が必要となるということです。
チームの生産性を最大化するというスクラムマスターのミッションを念頭に入れ、メンバーに役割を強制することのないようにしましょう。

リファインメント手法を活用して当事者意識をもたせ、
認識相違を回避する

「指示した内容と出来上がったものが乖離している」「想定外の作業量になっている」「チームの他担当者がやっていることを理解していない（他人事になっている）」などといったことが頻発する場合ほど、チーム全体でのリファイメントを積極的に取り入れましょう。

こういったトラブルの原因は（根本原因は多種あれど）タスクの内実が見えていない/共有出来ていないからです。参考値としての「SP」を活用することで、認識相違がどの程度あるかをざっくりと把握することができるため、トラブルの発生リスクを低減させることが出来ます。

例えば、あるタスクについて検討し、SPを出したとします。

  • Aさん： SPは5。

  • Bさん： SPは3。

  • Cさん： え！？ 私は10くらいかと思った。

  • Bさん： そんなにやることある？

  • Cさん： あるよ、xxに、xxに…、こういう調査も必要だし…

  • Aさん： じゃあ、それぞれでやらないといけないと思ったタスクを洗い出してみよう

SPとは、それぞれのチームでのタスクボリュームの肌感覚を数値化したものであるため、各自の技量は影響しません。
※ 天才コーダーは1週間に30SPを消化でき、新人は5SPを消化出来る、という違いはあっても、そのタスク自体の規模は変わらないため

BとCが大きく乖離のあるSPは、想定しているタスクが大きく異なっていることを示しています。
スクラムイベントはそれぞれ1つにつき1分程度しか考える時間を与えません。大量なタスクのサブタスクを全て洗い出して見積もるわけではないため、全タスクのSPを出したとしても、短い時間での見積もり算出・「想定外」の発見が可能となります。

また、全員がざっくりとチーム内タスクのことを考えることになるため、「他作業者がやっていることが何もわからない」事態を避けることができます。

ファシリテーションスキル

スクラムイベントでは必ず訪れる「ファシリテーター」。
履き違えている人が多いですが、「話をする人」ではなく「話をさせる人」です。

「話をさせる人」にならなければならない理由

日本の多くの人はディスカッションが苦手であり、聞かれなければ（聞かれても）発言しない人が大多数を占めます。

  • メインスピーカーのみが意見を出し、あたかもそれがマジョリティであるかのように設計が進み、後から「実はそんな作りは嫌だった」の手の平返しを喰らう

  • 発言者（お客様）自身がベストプラクティスを理解してはおらず、意思決定が遅くなる（結果開発着手が遅れる・スケジュールが逼迫する、など）

このようなリスクを顕現させないために、「発言しない人」を如何に「話をさせる」か、が重要となります。私がよくやる小技を3つほど紹介します。

1人だけが注目されない場作りをする
特に4〜5人以上の場や、役職・年功序列意識などがある場では、立場の低い人が喋り辛い心理的抑圧が発生します。

  • 全員が「喋る」のではなく、それぞれが付箋に記載する

  • 書かれたものを、本人ではなくファシリテーターが読み上げる

など、注目を逸らす工夫が有効です。

オープンクエスチョンではなく、クローズドクエスチョンから始める
その場で考えるような回答を、衆目の中で反射的に答えられる人は少ないです。
従って、誰かに回答を振らなければならない場合はクローズドクエスチョンをベースにして発話者の思考を纏めていくと良いでしょう。このとき、発話者の回答を反復するようにして次の質問に繋げていくと、より本人の思考が整理されやすくなり、自然とオープンな回答が出て来やすくなります。

回答者の自尊心を高める
回答を得られたことに対して必ず感謝をしましょう。普段スピーカーとならない人が回答した場合ほど、その回答を雑に扱わないように重々心掛けることが大切です。下手な回答だったと恥じてしまうと、以降その回答者は更に口を閉じてしまいますよね。
お礼を言う・その回答を次に繋げるように間を保たせるなど、回答者が「意見を言って良かった」と思える進行を心掛けましょう。

議論を収束させるための舵取りをする

収束点が自分の中にないものであったとしても、複数人が集まる議論である以上は、着地点に誘導することがファシリテーター（主導者）の役目です。従って、以下のポイントを念頭に置き、場の舵取りをおこなう必要があります。

  • 会議の目的と、ゴールを明確に設定すること

  • 目的の達成に必要最低限の関係者だけで会議体を構成すること

  • 目的・ゴールに関係しない話題はバックログとし、別の場を
    設けること

  • 発散と収束のプロセスを踏むこと

仮説思考でのユーザーインタビュー設計

ファシリテーターは良いインタビュアーとなることが重要となります。目前のYES/NOを聞くだけではなく、より深く相手を理解し、相手が本当に求めているものを聞き出せるようになりましょう。
参考）https://www.unprinted.design/articles/user-interview/

仮説思考質問の必要性

「聞いて終わり」「指示されて終わり」の受動的な対応は、結果として多くの手直しの原因となります。これは実装に限らず、さまざまな場面に適応される考え方です。
ただし、これは闇雲な仮説を立てることでも、１パターンに固執した仮説を立てることでもありません。もちろん、仮説を立てて質問して終わりにするということでもありません。

仮説に基づくアクションプランの準備

「xxを実装してください」「はい」だけで開発を進めると、その機能の必要性や目的を無視した実装となり、UXが低下したり、「顧客が本当に求めていたもの」から乖離してしまう原因となります。
必要性や目的を正しく理解し、その上でのアクションを起こせるようになるまで、複数の質問を用いて検証することが重要です。

そこで必要となるのが「仮説思考での質問」となりますが、仮説を立てるためには、目先の物事だけではなく、対象に関わる広範な内容を知ることが必要です。

「広範」というのはどこまでを指すのか？ に対して、世の中には便利な言葉がありました。それが、「サービスデザイン思考」です。

サービスデザイン思考

サービスデザインとは、「顧客に提供するサービス全体の体験をデザインし、実現するための方法論」を指します。アプリケーションに閉じたものではなく、アプリシステムに関わる全ての人・全ての体験を考慮に入れた、包括的な検討が必要となります。
参考）https://www.exa-corp.co.jp/blog/what-is-service-design.html
　　　https://www.unprinted.design/articles/service-design/

「ビジネスデザイナーになれ」ではない

大前提として、私たちはエンジニアであり、SIerです。
従って、ここで求めるのは「サービスデザインのプロになれ」という話ではありません。
しかし、サービスデザインという視座をもって提案するエンジニアと、これをもたずにいるエンジニアでは、前者の方がより顧客目線での提案をおこなえる（顧客にとって良き理解者となれる）人材であることは間違いないでしょう。

特に心掛けるべきことは、「全てのアプリ利用者の目線で開発する」ということです。

アジャイルの原則を活かす

サービスデザインの6原則のうち、

  • 「② 共働的であること」

  • 「③ 反復的であること」

  • 「⑤ リアルであること」

以上はまさしく、

  • 「② ステークホルダーを全員巻き込んだチーム」として

  • 「③ 継続的な改善」によって

  • 「⑤ 動くソフトウェア」を開発する

というアジャイル開発そのものといえます。
従って、以下の観点を追加で考慮できれば、それがサービスデザインの一歩となり得ます。

  • 「① 人間中心： サービスの影響を受けるすべての人の体験」や

  • 「⑥ ホリスティック（全体的）な観点： サービスに関わるすべてのステークホルダー」について、

  • 「④ 連続的であること： サービス利用時の一時だけではなく、サービス利用前後の連続的な行動」の

  • 「⑤ リアルであること： 現実にあるニーズを調査」して検証・改善する

さて、「人間中心」について考えるためには、「人」を知らなければなりません。

人間中心デザイン

「デザインをする」ことは、人を知らなければ始まりません。
デザインの専門家でない私たちは、まず身近な利用者に向けたものづくりを考慮すべきです。

ペルソナ分析

「誰が」「いつ」「どこで」「どのように」使うのか。
ペルソナとするイメージはユーザーシナリオを考えられる程度の十分さで良いですが、アプリに関わる全ての人のペルソナパターンを考えられるだけ考えてみましょう。

ペルソナパターン例

  • アプリ利用者

    • エンドユーザー

    • スタッフ

  • アプリ開発者

    • 開発チーム

    • 保守チーム

    • データ分析チーム

  • お客様

    • データ入稿者

    • プロデューサー　etc…

ペルソナ分析を開発に活かすポイント

利用者が変われば、UI考慮に必要なポイントも変わります。

  • メインユーザーが男性高齢者

    • 文字サイズを大きめにする

    • コントラストをハッキリさせて視認性を上げる

    • スワイプやドラッグなど、物理的ではない操作を避け、
      見えている範囲のオブジェクトを押下するようなUIとする

  • メインユーザーが若年層

    • スマホの操作性に合わせたUI/UXを中心とする

    • デザイントレンドを踏襲し、ユーザーの経験則を適用させる

　などなど。

UI/UXデザインは「センス」ではなく、人間工学に基づく知識経験で対処するものです。エンジニアたるもの、理論でデザインを考えましょう。
※ 色彩の分解能の男女差など、人間の生物学要素を前提に物作りをするのが「人間工学」です。（と、私は習いました）

ユーザーシナリオ

各ペルソナそれぞれの目線で、アプリとの接点における「行動・思考・ニーズ・課題」を洗い出しましょう。

アプリ利用者における接点の例

  1. ユーザーの注意を惹く

  2. ユーザーが興味関心を向ける

  3. アプリやサービスを検索する

  4. アプリやサービスをインストール/利用する

    1. 会員登録

    2. アプリ内回遊

    3. 商品購買　　　etc…

  5. アプリやサービスの利用を終える

保守チームにおける接点の例

  1. 追加開発依頼を受ける

  2. 対象のソースを探す

  3. 改修方針を模索する

  4. 改修・テストをおこなう

  5. リリースする　　　etc…

ユーザーシナリオを開発に活かすポイント

利用する場面が変われば、UX/CX考慮に必要なポイントも変わります。

商品の購入を目的とするサービスの例

  • ユーザーの離脱を抑制する

    • 商品一覧の視認性を向上

    • レスポンスを高速化

  • 離脱したユーザーを引き戻す

    • リマインド通知を送信

  • 入稿者のコストを低減する

    • 入力アシスト（サジェストなど）を追加

  • 追加改修時のコストを低減する

    • ソースの可読性・保守性を向上
      （メソッド分割・コピーコードの廃止など）

    • CICDの整備

などなど。

総括

アジャイルの原則を念頭におきながら、ファシリテーションスキルによって顧客の要求を深く聞きとり、サービスデザイン思考をベースに広く考察・分析して提案する。

せっかくものづくりをするならば、関わる人がHAPPYになれるものを作っていきましょう。

率先垂範。良いと思ったことは前のめりに行動しましょう。
しかして阿諛追従を良しとせず。他人事思考・他責思考は自分の首も絞める悪手です。

誰かの何かの参考になれたら幸いです。


いいなと思ったら応援しよう！