1
/
5
This page is intended for users in Hong Kong. Go to the page for users in United States.

技術者の本音爆発!本当に良いサービスを開発するために欠かせないフェーズとは?

今回は技術者による座談会を開催したのでその様子をご紹介します!

テモナで働く技術者ならではの話もあれば、技術者にとって大切な考え方などの話も出たので有意義な時間になりました!


まずは参加者のご紹介!TOP写真左から、

清水 一那 たまごリピートNextチーム エンジニア (入社2年目)

竹井 彰平 たまごリピートNextチーム エンジニア(入社6ヵ月目)

溝上 雄太 たまごリピートチーム デザイナー兼エンジニア(入社1年目)



設計情報をスムーズに伝えるのって難しい!

竹井 テモナってオフショア開発を取り入れているけど、設計を担当している二人は何か気を付けていることとかある?

清水 私は入社当初は設計ではなく開発として業務を行っていたので、設計の情報を送って開発をしてもらう今とは逆の働き方をしていました。開発の経験を積んでから今の『たまごリピートNextチーム』で設計などの業務を行っていますが、私が設計情報をもらっている時には到底気づけなかった情報伝達の難しさを体験しました。日本とベトナムではアプリケーションツールが違うなどのギャップはもちろんあるので、行ってもらう開発はピンポイントに拘わらず、何処まで情報伝達をして的確な指示をすればいいのか迷った時期がありました。必要以上に情報を伝えたくなってしまう。そこが難しかったな。

今はチームメンバへ最初に設計図を見せて、全体図を把握してもらってからは必要最低限の情報を伝えるようにしているけどそこのバランスもまだ難しいです。

竹井 僕はすごいふわっと情報渡してましたよ(笑)入社間もない頃は、どこまで説明すればいいですかー?って聞くようにしてました。向こうが欲しい情報教えてもらうことが1番良いかもしれないよね。こればっかりはルール決めも難しいからパターンによって変えるようにしてます。機能説明しないこともあるし、本当に必要な情報だけをヒアリングして共有していたね。溝上君はまだオフショア開発のフランジアさんと直接やり取りしたことないよね?

溝上 僕はまだ直接のやり取りはしたことないですが、社内でエンジニアサイドとデザインサイドで画面設計の話でやり取りすることはありました。まだ新卒1年目ということもありますが、お客様が何を求めているのかわからない時期がありました。機能画面を設計する時に僕の思った使いやすいとお客様の思う使いやすいに差異が生じることがあったので、コンサルの方に細かくお客様の要望、要件を聞いてもらうことで徐々に各機能画面ごとのデザイン志向が理解出来てきたと思います。この時に相手の求めている要望をしっかりとくみ取ることが如何に大切な事なのかを強く実感しました。

清水 確かにそうだよね。そもそも竹井さんってECの開発経験が無いにも関わらず、入社後スムーズに設計入ってましたよね?どうして出来たのですか?

溝上 僕も思いました。竹井さんどうして急に設計出来たんですか?不思議で仕方ないです。

竹井 そんなに?(笑)きっと相手の考えに寄り添う姿勢を心掛けているからだと思います。最初にお客様の要望を正確にヒアリングした状態で、お客様が何をしたいのかを一度構想する。希望をしっかりと把握してコミュニケーションをとるとスムーズに進みやすいかもしれないです。

清水 竹井さんは感覚で適正な判断が出来るから苦労しなさそう!全部スムーズに進めそうで羨ましいです!


結局開発工程ってどこが重要だと思う?

溝上 設計の話が多く出てきてますが、お二人が開発工程で気を付けなければいけないと思っているフェーズってどこでしょうか?

清水 やっぱり要件定義のフェーズは気を使うかな。要件定義を抑えていれば開発チームで進めていけますが、要件定義の部分ではコンサルの方とお客様要望を入念に行うことが重要になってきますよね。もし妥協して進めた場合、後戻りが出来ないことも多いです。多くの人とコミュニケーションを取りながら慎重に進めていくのが要件定義のフェーズです。本当にすごい確認します。(笑)

溝上 僕も同じく要件定義です。要件定義が正確に定まっていないと画面設計をストップしなければいけないことになります。設計した後に要件が変わると画面仕様が大きく変動してしまいますから。。。既に組まれた要件定義に関しても「これで最終判断ですよね?」って再三の確認をするようにしています。まだ要件定義をしっかりと経験したことは無いのですが、心掛けようって今から思います。

清水 要件が変動すると次回の開発工程に先延ばしすることもあるし、お客様との調整をしてボリュームディスカウントをする必要も出てくるからね。

竹井 やっぱり要件定義は重要だね。2人とも開発経験を積む中で要件定義の大切さに気付いたと思うけど、自信に繋がった業務ってある?


成長を感じれる瞬間は日常茶飯事

清水 私は大学生の頃は開発未経験でしたが、テモナに入って開発~設計を経験していきました。その中で1つ1つの工程を経験出来ていること自体が自信に繋がってます。どんな工程でも疎かせずに知識を蓄えないとどこかで躓くし、支障が出てくると思います。

溝上 僕は大学生の頃、情報デザイン学科でUI/UXを経験していたので、テモナでのデザイン業務は全くの未経験だった訳ではないです。ただ業務上で画面設計をするのは初めての経験だったので最初は勉強することだらけでした。ましてや企業様向けではなく個人向けのデザイン経験が多かったので、自己感性の画面設計ではなくお客様マターの画面設計をするように考え方を変えれた事が自信に繋がりました。言われたデザインを反映するだけではなく、画面設計の意図をお客様に伝えることで責任を持つこともいい経験になっています!

竹井 やっぱりどんな業務でもステップアップをすれば自信に繋がるよね。直近も調査工程でエラーが出たときにお客様のログ確認や細かくトレースをしたりしたけど、今までに経験したことが無かったので1つ自信に繋がりました!うん、いい経験をした(笑)

溝上 先ほど責任という言葉を僕が言いましたが、責任をとれるエンジニア像ってイメージ湧きますか?


チーム開発の責任って誰が取るべき?

竹井 責任は自分一人では取りたくない! だからこそ他の人が書いたソースも皆で確認するし、自分が書いたソースもみんなで確認してチーム全体で責任を負う。他の人の開発業務でもみんなで責任を負う意識を持つのが良いと思う。一人で責任を負うとなると心が壊れてしまうと思う。他の人の開発業務でもみんなで責任を負う意識を持っていないと心が壊れてしまうと思いますね。

清水 私も1人に罪を押し付けるようなことは絶対にしたくないです。スクラムマスター1人に責任を負わせることは避けたくて、リリースするときに全行程の情報を認識しているのがスクラムマスターだけだとメンバーが対応できなくなります。リリースしたらみんなの責任。情報をキャッチアップ出来ていないのが罪だと思います。みんなで主体的意識をもって開発をすることが理想ですよね。一定の期間を経て、全体のソースを見直すことも行っていきたいです。

溝上 デザインチームも各機能の画面設計を揃えなければいけないです。機能毎に縦割りのチーム体制なので画面設計にずれが生じる可能性はあるので全体通して管理している体制をとっています。

清水 開発後のサービスって仕様がどんどん古くなっていくから期間が経った後でも使いやすいように先を見越したサービスを設計していくことも大切だよね。そう考えると本当に良いサービスって何だろう?


本当に良いサービスは人それぞれ


竹井 根本の話になるけどお客様やユーザーの期待を超えるサービスだと思う。要件を満たすのは最低限かな。

溝上 お客様が要望したサービスを開発することがゴールでは無くて、お客様の売上や生産性が上がることが本当にお客様のためになるサービスかなって思います。

清水 サービス開発後の保守運用業務のことまで考えて作られているサービスも良いサービスだと思います。使い易さ、品質整備を本当に考えられたサービスってお客様にとって良いサービスだと思うかも。

竹井 もちろん人によって良いサービスは違う。だからこそお客様の声を正確に反映できるよう要件定義が重要になってくるのかもね。


皆さんの話を聞いてる中で良いシステムや残念なシステムって捉え方や見方によっても変わってきますよね。あなたの思う残念なシステムとは何でしょう?

そのお話を是非聞かせて頂けませんか?


弊社では2/20(火)19:00~21:00でセミナーを開催します。

題材は『CTO・CIOが語る 明日から使える! Webアプリケーションの失敗学』でざっくばらんに意見を交換できる場を設けています。

少しでも興味のある方は是非お越しください!

お申し込みは下記URLからお願い致します!

『CTO・CIOが語る 明日から使える!Webアプリケーションの失敗学』予約フォーム

皆様にお会いできること弊社一同心待ちにしております!

テモナ株式会社's job postings
24 Likes
24 Likes

Weekly ranking

Show other rankings