顧客側としてJPT社員にアプリ開発を依頼してみたら殊の外盛り上がった
こんにちは、JPTの長尾です。
私は日揮グローバル株式会社にも籍を置いており、いわば「身内でありJPTにとっての顧客にもなり得る」存在です。
今回、小型のアプリ開発をゲリラ的にJPT社員にお願いしてみたら殊の外盛り上がりました。
本記事を通して、何故盛り上がったのかや、どうやってJPT社員と協奏すればよいのか、そんな事を考えていきたいと思います。
作りたかったもの
～ToDoとタイマーが一体になったやつ～
私がいる部署には多種多様な業務が存在します。
これらの業務の中でも”面倒なもの”はどんどん自動化、省力化が検討されている一方で実際どの程度時間がかかっているの？という問いに対しては定性的な回答が多い状態でした。
そこで「ToDoとタイマーが一体になったやつ」があれば各作業・業務にかかる時間をユーザーの負担が少ない状態で計測できると考えました。
任せるまでの流れ
今回はHarakazuさんに依頼する事にしました。理由としては「最近自主的にアプリ作っていたから」です。
まずは作りたいものを伝え、その後に画面イメージと簡単な要求を共有しました。どういった技術スタックを選定するかはすべてお任せしました。
すぐにできた！
ちょうどHarakazuさんが担当していた大きな開発業務がひと段落していた事もあり、小型アプリはものの数日でできあがりました。
早速使ってみます..
すごい！僕の言った機能ができている！！
ん..?!自分の要件にないスナップショット機能があるが..これは何だ？
なるほど、ToDoをsnapshotとして保存し、再読み込みして途中から始められるのね。確かに１日で終わらない作業や継続して計測したい業務もあるもんね。便利！こういう機能、確かに欲しかった！！
開発者にインタビュー
という事で、今回のアプリ開発について意識した点などをHarakazuさんにお聞きしました！
自分自身が使いたいシステムにする
長尾：
スナップショットの新機能はどのようにして思いついたんでしょうか？
Harakazu：
自分は開発の際に、「自分が使うんだったらどんなシステムにするだろうか？」ということを常に意識しています。今回のスナップショット機能についても同様でした。
要件段階ではリストが一画面あるだけの画面でしたが、ある程度使っているとタスクリストの画面が多くなって見にくくなってきます。そこで、画面の状態をまとめて整理できる機能があればいいなと思いました。
今回の要件にあった「シンプル性第一」のコンセプトも踏まえると、「現在の画面の状態をファイルで保存する」というシンプルなスナップショット機能で実現できるのではないか、と考えたわけです。
不確定な物事を「モデル化」する
長尾：
単に与えられた要件を実装するだけでなく、自分自身でも要件を深く掘り下げた上で取り組まれていたんですね。
Harakazu：
そうですね。私が仕事をする際のポリシーとして「目の前の物事を自分なりに深く掘り下げて解釈する」という姿勢もあるんです。
以前の私は大学院で海外文学の研究に取り組んでいましたが、そこでは「作品や文献を丁寧に分析する→分析を元に新たな解釈を生み出す→解釈を論文として言語化する」という過程が求められていました。
作家は何かを伝えたい時、その対象を解釈して言語化し、作品を創り上げます。でも、言葉って得てして不確定なものですよね。受け手の立場などの状況次第で、伝える本人には思いもよらなかった解釈をされることもしばしばあります。無数の多様な解釈があり得るんです。
そして、自分は「作品（言葉）の解釈を自分自身で創り上げ、その解釈を言葉で形にする」という行為――いわば解釈を批評として「モデル化」する過程ですね――そこに面白さを感じていたんです。
研究の世界からは離れましたが、今のエンジニアとしての仕事でも同じような面白さを感じています。
開発の仕事でも「要件を丁寧に分析する→分析を元にシステムの構成を構想する→構想を元にコードとして言語化する」という過程を踏みますが、これって文学研究のプロセスと似ているんですよね。
なので、自分は設計含めたプログラミングという行為を「顧客の要件（＝伝えたいこと、やりたいこと）を解釈して、情報システムという形に『モデル化』すること」だと考えていますし、その点で面白さを感じています。
文学研究とプログラミングというと、一見畑はまったく違うように見えますが、今の仕事で研究生活で培ってきた思考の枠組みも間違いなく生きていますね。
ドメイン駆動設計という方法論
長尾：
なるほどです。過去の経験が今の開発者としての芯として生きているんですね。
今回の要件をアプリとしてモデル化するにあたって、具体的にどのようなやり方で行ったんでしょうか？
Harakazu：
これまでの仕事の経験をもとにして、設計などで色々な工夫を盛り込みました。その中でも中心となった枠組みとして「ドメイン駆動設計 (Domain-Driven Design, 以下『DDD』と表記)」が挙げられると思います。
DDDを一言で説明すると、「システムで扱う物事の概念や知識（ドメインモデル）をコードに落とし込む設計手法」と言えます。たとえば今回でいうと、このドメインモデルには「タスク項目」という概念が含まれています。
DDDでは要件定義の解釈や顧客側との対話から、各ドメインにどのような機能や情報が求められているのかを分析し、その分析を動作するコードとしてモデル化していきます。
詳しくは本記事下部にあるスライドおよび私のQiitaの記事に譲りますが（補足：後日公開予定）、先ほどお話しした私自身の思考の枠組みに、このDDDの思想がピッタリはまっている感じがするんです。
顧客の知識から新たな解釈を生み出し、それをコードとして形にする。これってめちゃくちゃ面白いことなんですよ。
モデルは「キャッチボール」を通して洗練されていく
長尾：
今回のアプリですが、予想以上に素早いスピードで仕上がってびっくりしました。しかも新機能追加の工夫まで盛り込まれていましたし！
Harakazu：
ありがとうございます。自分自身でもここまで爆速でリリースできたことに驚いています（笑）
自分も色々工夫しましたが、長尾さんと一緒に相談して作り上げた要件定義がクリアだったお陰も大きいんです。誰でもすぐ使えるように機能を最小限に絞るといった「シンプル性第一」のコンセプトとか、それに基づいた画面のイメージ図とかですね。
長尾：
最初は「タスクごとに時間を計測したい」といったふわっとした要件しかありませんでした。その時点からHarakazuさんと共有を開始し、コミュニケーションの中でアプリ画面イメージ図をつくり、最終的には新機能も加わったものにできあがりました。対話の相互作用の中で、アプリの要件定義が洗練されていくのを感じました。
業務を作業化せずに、顧客に対し向き合って取り組む。これによって顧客の期待を超える成果物に繋がるのだなぁと感じました。
Harakazu：
ですね。これからもこの姿勢は常に意識して実践していきたいです。
JPTの仕事は「一人1プロジェクト」の個人開発が原則ですが、それでも開発は自分ひとりだけで行うものではないと感じています。今回も含めて、顧客やユーザー側と話し合うことで新たな気づきがたくさん生まれるのを経験しました。
顧客との対話というキャッチボールを通して、システムのモデルが洗練されていくのだと思います。今回その過程を長尾さんとの1 on 1で行う中で、改めてその重要性を感じることができました。
インタビューおわり
まとめ
Harakazuさんは「自分の思い」を業務の中で表現していました。また「もっとこうした方が良いのでは？」という提案も常に持ちながら業務に携わってくれています。真摯に向き合ってくれる姿を頼もしく感じることができました。
Harakazuさんに限らず、JPTには業務に真摯に向き合うエンジニア達がいます。今回の企画を通して皆さんの個性をもっと感じたいと改めて思ったので、今度は別の誰かに業務をお願いしようと思います。
Harakazuさんが語った「ドメイン駆動設計」については下記スライドで"たのしく"紹介しております。(Qiitaでも記事化予定)
技術面にも興味がある方はぜひご覧ください！
ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？