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

越境とは?
越境するとはなんでしょうか? 国語辞典 によると「(スル)境界線を越えること。特に、法的に定められた領界を無視して侵入すること。「越境して亡命する」」というようです。
私は「 前提や制約などを置かず目的に忠誠を誓い、その目的のためにあらゆる活動をしていくこと 」と定義しています。
今回は昔に体験した越境の話です。
最初の越境:お客様常駐時代
200X年頃、ある精密機器メーカー様の情シス部門に常駐して、購買管理システムなど社内で使われるシステムの機能追加や改修などを行っていました。
当時の開発のやり方は誰かがヒアリングし、書き起こした要件定義、設計書を元にプログラミングをするというものでした。それからしばらくして、自分自身も同じ様にヒアリングして作るようになりました。この時は「システム開発とは要件を満たすように作れば良い」と何も疑問に思っていませんでした。
そんなある日、そのシステムを 日常の業務で実際に使っている人 と話す機会がありました。すると、最近リリースしたある機能はほとんど使われていないことがわかりました。自分達がヒアリングしていた相手は実際に使っている人の上司であり、その ソフトウェアを使って実際に業務を行っている本人ではなかった のです。
使われない機能を作っても仕方ないと思い、実際に業務を行っている利用者とそのヒアリングしていた上司に利用者の横でしばらく作業をさせてもらうお願いをし、同席して仕事をするようになりました。1週間もする頃には、利用者がソフトウェアを使うタイミング、その時の環境、どんな風に使っているのかがおぼろげながらわかってきました。
そういう中での機能開発はこれまでのやり方とは違い、作ったものを隣にいる 実際の利用者にすぐに試しに使ってもらってフィードバックをもらう というやり方になりました。同席するようになって知ったことなのですが、この利用者は最初ヒアリングしていた上司よりも業務や現場の目指す姿をより理解していました。
当時は XPの白本 で オンラサイト顧客 というプラクティスをうっすらと知っていたと思いますが、実際の利用者の行動を観察し、どのように過去をしたかを聞いて、一緒に作ってすぐにフィードバックをもらうというユーザーフィードバックのサイクルが回せていたと思います。
要件定義書、仕様書通りに作るのが仕事(作ったものが実際に使われなくても)ということが当時の自分の周りでは当たり前の行動だった中では珍しい行動だったようです。これが今思うと実際の利用者に引っ張られる形とはいえ、越境の1つだったと思います。
この「 実際の利用者に聞いてみないと何もわからない 」という体験は鮮明に残っています。
次の越境:SIer時代
それから数年して、大規模なシステム開発に携わってみたいと考え、大きめのSIerに入りました。
そのうち、社内向けのJavaのフレームワークとその周辺ツールを作るチームを立ち上げるという話があり、その立ち上げから加わることになりました。当時、提供されたそのようなフレームワークを使っていた立場の時には「今の現場のことを知らない人達が想像で作ったもので、使いやすくない」と否定的に感じていました。
どういうものを作っていくのが良さそうか?はなんとなくは見えていましたが、どんな風に作っていくのが良さそうかはまだわかっていませんでした。そこでみんなでインセプションデッキを書きました。
※参考: インセプションデッキを書いてみた – サウスポーなエンジニアの独り言
「 使わせるのではなく、使ってもらいたくなるようにするにはどうすればいいか? 」を突き詰めた結果、 頻繁なリリース 、自分達自身のツールもそのフレームワークを使って作る ドッグフーディング 、そして、このフレームワークを実際に使ってくれるチームと一緒になってそのプロジェクトに参加してユーザーフィードバックを得ていく( オンサイト顧客 )という3つの方針を決めました。
使ってくれるチームもフレームワークの効果を期待してプロジェクトを計画しているため、様々なフィードバックを得ることができました。そのチームと一緒になってプロジェクトを進めているからこそ切実さもわかる一方、フレームワークが目指すところとのバランスを取りながら、取捨選択しつつ、目の前のクライアントのためにできるだけ早くいい形で届けるという強い気持ちでやっていました。
このプロジェクトはアジャイルなふるまい、考え方、Scrum、Redmineによる見える化、東阪という別れた拠点での開発などその組織ではそれほど前例はなく、どうすればよいのか悩むことも多くありました。
そんな時に頼りになったのが、すでにその道を歩んでいた先達や同じように道を歩んでいる同志でした。「こういう考えでこういうことをやろうとしている」と声をあげると、アドバイスや体験談を得られました。その声に勇気づけられて、越境することができました。
まとめ
越境しないといけない人にとっては、その境界を越えようとしているのは自分だけで誰も他にはいないと思うかもしれません。
しかし、多くの場合は先にその境界を越えた人がいるので、安心して越境してみればいいと思います。
自分がその境界を飛び越えた後は、後に続いて越境してくる人を勇気づける声をかけ、時には手を差し伸べることをすることも1つです。
これは ギルドワークスのアドベントカレンダー2018 の12日目の記事です。
この記事もどうですか?
-
状況判断で駆動する「機略型のアジャイル開発」
見積もりができない。どうする? 見積もりって大事ですよね。見積もりは何のために行なうものでしょうか?開発が終わるかどうかの見立てを立てたい。そうですね、たいてい使えるお金と時間には制約があるので、やろうとしていることが本当に完了できるのか、…
- DRR
- 正しいものを正しく作る
- アジャイル開発
- OODA
-
ギルドワークスでは仲間を見つける時にお互いどういう点を確認しているか?
この記事は ギルドワークスのアドベントカレンダーの18日目 です。 要約 ・ギルドワークスの採用プロセス ・どういう点をお互い確認しているか? ギルドワークスの採用プロセス 時々「ギルドワークスってどんな採用のやり方をしているの?」と採用プ…
- 仲間探し
-
なぜ我々は継続的インテグレーション、継続的デリバリするのか
なぜ我々は継続的インテグレーション、継続的デリバリするのか これは ギルドワークスイベントカレンダー 3日目の記事となります。 ギルドワークスでは、プロジェクトを開始したときに、多かれ少なかれ、継続的インテグレーションや継続的デリバリの仕組…