DebTab

  • ホーム
  • DevTabとは
  • 記事一覧
    • きたえる
    • かえる
    • つくる
    • みちびく
    • たばねる
    • つたえる
かんたんログイン
Githubでログイン
Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

DebTab成長しつづけるデベロッパーのための情報タブロイド

DebTab

ログイン

検索 検索

「実際の利用者からフィードバックをもらう」ことを体験した話

写真中村 洋

きたえる

つくる

  • #DRR
  • #アジャイル開発

2018.12.12

ポイントポイント

0

 ギルドワークスで現場コーチとしていろいろな現場が変わっていくことや改善を支援している中村 洋です。
 ギルドワークスは「越境」を価値としています。


越境とは?

 越境するとはなんでしょうか?国語辞典によると「(スル)境界線を越えること。特に、法的に定められた領界を無視して侵入すること。「越境して亡命する」」というようです。

 私は「前提や制約などを置かず目的に忠誠を誓い、その目的のためにあらゆる活動をしていくこと」と定義しています。
 今回は昔に体験した越境の話です。

最初の越境:お客様常駐時代

 200X年頃、ある精密機器メーカー様の情シス部門に常駐して、購買管理システムなど社内で使われるシステムの機能追加や改修などを行っていました。

 当時の開発のやり方は誰かがヒアリングし、書き起こした要件定義、設計書を元にプログラミングをするというものでした。それからしばらくして、自分自身も同じ様にヒアリングして作るようになりました。この時は「システム開発とは要件を満たすように作れば良い」と何も疑問に思っていませんでした。

 そんなある日、そのシステムを日常の業務で実際に使っている人と話す機会がありました。すると、最近リリースしたある機能はほとんど使われていないことがわかりました。自分達がヒアリングしていた相手は実際に使っている人の上司であり、そのソフトウェアを使って実際に業務を行っている本人ではなかったのです。

 使われない機能を作っても仕方ないと思い、実際に業務を行っている利用者とそのヒアリングしていた上司に利用者の横でしばらく作業をさせてもらうお願いをし、同席して仕事をするようになりました。1週間もする頃には、利用者がソフトウェアを使うタイミング、その時の環境、どんな風に使っているのかがおぼろげながらわかってきました。

 そういう中での機能開発はこれまでのやり方とは違い、作ったものを隣にいる実際の利用者にすぐに試しに使ってもらってフィードバックをもらうというやり方になりました。同席するようになって知ったことなのですが、この利用者は最初ヒアリングしていた上司よりも業務や現場の目指す姿をより理解していました。

 当時はXPの白本でオンラサイト顧客というプラクティスをうっすらと知っていたと思いますが、実際の利用者の行動を観察し、どのように過去をしたかを聞いて、一緒に作ってすぐにフィードバックをもらうというユーザーフィードバックのサイクルが回せていたと思います。

 要件定義書、仕様書通りに作るのが仕事(作ったものが実際に使われなくても)ということが当時の自分の周りでは当たり前の行動だった中では珍しい行動だったようです。これが今思うと実際の利用者に引っ張られる形とはいえ、越境の1つだったと思います。

 この「実際の利用者に聞いてみないと何もわからない」という体験は鮮明に残っています。

次の越境:SIer時代

 それから数年して、大規模なシステム開発に携わってみたいと考え、大きめのSIerに入りました。

 そのうち、社内向けのJavaのフレームワークとその周辺ツールを作るチームを立ち上げるという話があり、その立ち上げから加わることになりました。当時、提供されたそのようなフレームワークを使っていた立場の時には「今の現場のことを知らない人達が想像で作ったもので、使いやすくない」と否定的に感じていました。

 どういうものを作っていくのが良さそうか?はなんとなくは見えていましたが、どんな風に作っていくのが良さそうかはまだわかっていませんでした。そこでみんなでインセプションデッキを書きました。
 ※参考:インセプションデッキを書いてみた – サウスポーなエンジニアの独り言

 「使わせるのではなく、使ってもらいたくなるようにするにはどうすればいいか?」を突き詰めた結果、頻繁なリリース、自分達自身のツールもそのフレームワークを使って作るドッグフーディング、そして、このフレームワークを実際に使ってくれるチームと一緒になってそのプロジェクトに参加してユーザーフィードバックを得ていく(オンサイト顧客)という3つの方針を決めました。

 使ってくれるチームもフレームワークの効果を期待してプロジェクトを計画しているため、様々なフィードバックを得ることができました。そのチームと一緒になってプロジェクトを進めているからこそ切実さもわかる一方、フレームワークが目指すところとのバランスを取りながら、取捨選択しつつ、目の前のクライアントのためにできるだけ早くいい形で届けるという強い気持ちでやっていました。

 このプロジェクトはアジャイルなふるまい、考え方、Scrum、Redmineによる見える化、東阪という別れた拠点での開発などその組織ではそれほど前例はなく、どうすればよいのか悩むことも多くありました。
 そんな時に頼りになったのが、すでにその道を歩んでいた先達や同じように道を歩んでいる同志でした。「こういう考えでこういうことをやろうとしている」と声をあげると、アドバイスや体験談を得られました。その声に勇気づけられて、越境することができました。

まとめ

 越境しないといけない人にとっては、その境界を越えようとしているのは自分だけで誰も他にはいないと思うかもしれません。
 しかし、多くの場合は先にその境界を越えた人がいるので、安心して越境してみればいいと思います。
 自分がその境界を飛び越えた後は、後に続いて越境してくる人を勇気づける声をかけ、時には手を差し伸べることをすることも1つです。

 これはギルドワークスのアドベントカレンダー2018の12日目の記事です。

共感した

ポイントポイント

0

取り消す

この記事に共感したら、何度でも押してこの記事のポイントをみんなでアップしよう。

自分の感想を残す

この感想は、サイトに公開されることはなく自分にしか見えません。自分の考えのログを残すために感じたことを登録し、のこしておきましょう。あとで振り返ったときに、あのとき自分はこう考えていたのかということを知ることにより、あなたの成長へとつながります。

Githubでログイン

Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

  • ひとつ前の記事

    AWS Amplify を利用して最速で会員登録をつくる

  • ひとつ後の記事

    GitHub最新人気リポジトリ【2018年版】

この記事もどうですか?

カスタマージャーニーマップ、失敗のすゝめ

カスタマージャーニーマップとは、ウェブサイトやサービスを利用する顧客がどのようなプロセスで、どのよう…

つくる

2016.04.13

ポイント
0

現場コーチがよく使う会議のアジェンダ

状況 アジェンダがない会議。 困り事 その会議の目的が果たせない。 果たすまでに余計な時間がかかった…

きたえる

2018.08.29

ポイント
3

デザイナーもスキルマップを用意しよう

本記事は ギルドワークスAdvent Calendar 5日目の記事です。 世の中にあるは「〇〇デザ…

つくる

2018.12.02

ポイント
0

シェア
  • Twitter
  • Google Plus

ログインして
ブックマーク

  • Twitter
  • Google Plus
  • ログイン
LINE@

新しい記事が出たときや、注目の記事などを
定期的にLINEでお知らせしていきます

LINEで登録

LINEイメージ

DevTab
成長しつづけるデベロッパーのための情報タブロイド

株式会社ギルドワークス
https://guildworks.jp
  • プライバシーポリシー
  • お問い合わせ

Copyright © GuildWorks Inc. All Rights Reserved.

ページのトップへ