00:00
みなさんこんにちは、TRY-CATCH FMです。このポッドキャストは、新卒で同期入社した中堅エンジニアの2人が、プログラミング学習、最新の技術、働き方、転職などについて緩く話していきます。
毎週2回のペースで配信しているので、アップルポッドキャストもしくはスポーティファイルお聞きの方は、ぜひフォローお願いします。
やっていきましょう。2〜3週間前に菅総理が総裁選に出ませんとなって、今9月末の投票会議に向けて4人の候補者の人がいるじゃないですか。
河野さん、岸田さん、高市さん、野田さんの4人がいて、最近、NHKとかいろんなところで討論会をやってるけど、今回そういうのを見てて、恥ずかしい話。
俺、あんまり20代前半とか、政治に興味なかったんですよ。その時に比べて、今回すごい見てる気がして、単純に年をとったっていうのもあるのかもしれないけど、そうじゃない理由もそれなりにある気がして。
何でなんだろうね。今回結構盛り上がってるって言ったらあれだけど、僕の話してる人が多い。いつもより多い気がする。
それをちょっと考えた時に、一つあるのは、コロナで菅さんが、コロナ対策、良かったか悪かったかっていう話をちょっと置いといて、国民への説明不足みたいなところは少なからずあったと思うんでしょ。
そうなって、今までは政治に無関心で、ある程度誰が総理大臣とか日本の国を引っ張っていっても、自分には関係ないしと思ってた側面もある人多いと思って。
でもなんか今回は、今回限りはちょっと命に関わるみたいな状況になって。
だからちょっと自分でちゃんとした総理大臣を選べないんだけどね、実際は。
そう、出して待つしかない。
03:03
やっぱりそこにすごい興味が湧くようになったんじゃないかな、そこが一番大きい理由なんじゃないかなと思うんだよね。
そうだね、割と、何だろう、ことは複雑なんだけど、議題としてはシンプルにみんなが同じものを語れるように。
もともと経済がどうのとか、社会福祉がどうのとかっていろんな話をしてたんだけど、最近もうコロナドーン、オリンピックドーンで、なんかそういう感じでドカッとみんなで同じ話題を話せるっていうのがあるんじゃないかなってちょっと思って。
それはあるね。
何だっけな、ずっと前に麻生太郎さんがなんか語ってるのをYouTubeで見た記憶があるんだけど、要はあまりにも平和すぎると若者は政治に関心持たないみたいなね。
ある程度治安が悪かったりとか、その国の情勢が悪かったら政治にすごい関心を持つというか、自分たちで選挙行って選ばないといけないみたいな話になるから、逆に無関心なのはいいことなんだみたいなことを言ってたな、麻生さんが。
それはなんか昔から、僕は子供の頃にもなんかそんな話を聞いたような気がするね、日本の話かは置いといて。
そうだね、実際あれだもんね、感染症対策をどうするのかみんなピリピリしてたりとか、飲食店とかが緊急事態宣言っていろんなところが勝つ問題になったりとかするから、やっぱりみんな興味もたざるを得ないみたいになってるんだろう。
もうまさにね、総理大臣の意思決定によって自分のところのお店が潰れるか潰れないかみたいな状況になってるから、本当に興味を持たざるを得ないんだと思うね。
そういう機会が1回ぐらいあるのは、環境が悪いのは置いといちゃあれだけど、置いとくとしたらいいことなんだろうね、考えた経験みたいな。
個人的な話をするとやっぱり、菅さんが操作船出ないことによって河野さんが出てくれることになったんで、ちゃんと河野さんは情報発信力もあるし、俺の好きなリーダーのタイプっていう感じがするな。
ある程度、無茶を承知でガシガシやってくるタイプの人だと思ってるかな。
そうだね。防衛大臣の頃からもうすでにいろいろ推理がバシバシに反映していく感じの人だったもんね。圧倒的なスピードで反抗なくなったし。
06:00
それが嫌いな人もいるかもしれないけど、結果としては河野さんが言っていると日本を前に進めるっていうね、それを実現してくれるんじゃないかなっていう気はしてますね。
もうね、何かしら前には進むんじゃないかな。去年、今年か。今年の前半に確定申告をやった時さ、反抗いらないって書いてあって。
そうかと思って、本当になったんだと思って感動した思いがある。やると進むんだなっていう感じがした。
そういう実感をね、いろんなところにもしかしたら出してくれるかもしれないっていう期待があるよね。
今月末くらいには決まるらしいので、ちょっとその注目していきたいなと。
はい。
はい、じゃあそんな感じで本題に入っていきたいんですが、今日の本題が仕事でウェブアプリとか、ウェブアプリに限らずアプリとか作ることってあるじゃないですか、普通に。
その時の開発の段取りってどういう感じでやってるかっていうのをちょっと今日話そうと思うんですけど。
個人的にはもう3、4年くらい変わってない段取りはあって、大須田流と三八流をちょっと共有したいなと思うんですけど。
ちょっと俺の方から話していきますか。
まず最初にアイデアがあるじゃないですか。こういうものを作りたいみたいな。
それだけだと用件定義とは言えないので、ビジネスサイドの人とかアイデアを持ってきた人に対して実際どういうものが作りたいのっていうふうに聞いてもいいんだけど、
多分ほとんどの場合具体的なイメージって決まってないかな。
俺がやるのはデザインをまずは作るというか画面を作って、ここのボタンを押したらこういうリストが出てきて、
その中から選んでこうやると最終的にこの結果が出てきますけど、そんな感じですかみたいな感じのものを用意するんですよ。
HTML、CSSで書くなり、デザインツールなりで書いたりしてプロトタイプを作る感じかな。
それに対してフィードバックをもらうっていうのを2、3回くらい繰り返すと、それなりに妥協点というか、
こういうものが第一弾としてできたらいいねみたいなところに落ち着いてくるんで、
09:01
それをある程度文書化して要件定義書、使用書にします。
その次にフォン開発みたいなところに入っていくんだけど、
基本はフロントエンドとバックエンドで分けて同時進行でやるみたいな感じかな。
インフラは誰がやるかちょっと置いといて、またバックエンドの人とかがクラウド環境とか作ってくれたりして。
その前にやらなきゃいけないのがAPIインターフェイスの確定とデータベース設計。
要はテーブルにどういうデータをどういう構図を置くのかっていうところと、
それよりもAPIインターフェイスのほうが大事で、
要はバックエンドからフロントエンドにどういう形でデータを引き渡すのかっていうところを、
まず一番最初に確定させるっていう感じかな。
具体的に言うと、最近だとVue.jsとかReactとかで実装するから、
タイプスクリプトでこのAPIインターフェイスを定義する。
例えばサーチリスポンスみたいなタイプスクリプトのインターフェイスを作って、
そこにはどういうキーバリューがあるかみたいな、
どういうプロパティがあるかみたいなのを定義して、
それでサーバーサイドを実装する人と合意をするんですよ。
そしたらあとはおのおので開発していく。
フロントエンドはバックエンドからこういうデータが返ってくる前提で、
JavaScriptを書けばいいし、
バックエンドの人はこういうふうにフロントエンドに返せば、
あとはヨシナにやってくれるっていう前提で、
APIを開発していけばいいから、
本当に同時進行で実装できるっていうメリットがあるかなと。
それがある程度終わってきたら、
完璧に終わるちょっと手前くらいのところで疎通確認をするみたいな感じだね。
実際最初にこういう形で返してくれるって約束したけど、
本当に大丈夫かなみたいな確認をするようなイメージかな。
それをAPI疎通確認みたいな感じでいってて、
そこで実際にやってみると、
大体の場合でうまくいってないんですよ。
だからここはストリングの配列にしないとダメですねみたいな話がいろいろ出てきて、
それを最終調整かけて、
12:01
APIの問題ならバックエンドエンジニアの人に書いてもらったり、
フロントエンドで打ち取ったデータがうまく表示されてないんだったら、
フロントエンドで修正したり。
そこは結構密にコミュニケーションを取りながら調整していくみたいな感じですね。
その後はある程度エンジニアで一通りの動きが確認できたら、
QA担当、テストしてくれる人に引き継いで、
テストケースとかを一緒に書き上げた後にQAをしてもらって、
最後リリースするというのが大まかな流れで、
これが一番無駄なくできる段取りなのかなと思っている。
モダンというか、スッキリスピーディーに進めたいというのを実現していくとこうなりそうな感じがするよね。
なのでこれはREST APIでやるっていうのが前提なのかな。
でもRESTじゃなくても、インとアウトがちゃんと全部決まっていて、
GRPCとかでもなんでも。
そうだね。
さらに具体的な話をすると、
タイプスクリプトでAPIインターフェースを決めるところは、
オープンAPIというツール、
昔スワッガーと呼ばれていたものだけど、
それを使って、
オープンAPIなら、YAMLファイルからタイプスクリプトをジェネレートしたり、
YAMLファイルからサーバーサイド側のクラスファイルを
前後に合わせて出力したりだとか、
あと、クイックタイプっていうタイプスクリプトから
サーバーサイド側のモデルを作ってくれるってやつもあるんで、
ちょっとライトにやりたい場合はクイックタイプを使ったりするかな。
要はオープンAPIってモデルだけじゃなくて、
メソッドとかも自動生成するんで、
フロントからAPIを呼ぶためのメソッドとかも作ったりするんで、
ちょっと厳密に定義が必要になってくるイメージ。
でもAPI決めて、それのYAML作って、
あとは各言語のジェネレーターで発行してるのが一番、
そこがなくていいかなと僕は思うけどね。
またGoogleが何か喋っております。
逆に言うと、最初のこのインターフェイス定義、
15:06
APIインターフェイス定義をちゃんとやらないと、
お互い違った方向で走っていくみたいなことになるんで、
合流できなくなるんですよ。
そうね。
疎結合にした上にそこが合わなかったら、
それは絶対合わないよね。
だからそこはね、一番重要と言っても過言ではないかなっていう気がするね。
COSDAの場合はどう?
僕はあんまり個人開発みたいなのやってないから、
もともとあるシステムを一緒に回収していくとかはやったりするけど、
それってあんまりこうならない。
とはいえ、一応たぶん、たぶんじゃないな。
手伝っているところとかだと、
UI側は別でやってくれる。
やりたいことは決まってると。
だから同じようにAPIをこんな風なものを受け取って、
これを返しますよっていうAPIだけ決まってるから、
それをYAMLで出して置いておいてプッシュしておけば向こうも使ってくれるから、
あとはこっち側でそれをジェネレートして、
僕はそのときGoでやってたからGoのやつ。
Goで自動生成したやつ。
その定義に合わせてどんどんクラスとかパッケージを作っていくっていうのをやってた。
これのバックエンド側をポチポチやってた感じになるかな。
QA担当っていうのがそのときそこいないので。
疎通のテストは正直、
もうちょっと上のレイヤーのテストとしてまた別でやってたはずだけど、
バックエンド、フロントエンドの中に閉じたテストは自分たちで書くって感じだったな。
会社でやってたやつはSEというか外部委託、SIRだったのもあって、
ここまでシンプルにできないというか、
お客さんにマイフェイス出さないといけないとか、
成果の予想を提出しないといけないとかだったのもあって、やっぱりVGですよね。
VG開発ですね。
ウォーターフォールでっていうことよね。
そうだね。
になっちゃうな、どうしてもな。
このステップってウォーターフォールでできないのかな。
ウォーターフォールでやるとしたら、実現したいことを決めるで、
UIは要件定義として、そこからUI決めるところが要件定義プラス基本設計みたいな感じになって、
バックエンドの動きも少しそこで決めとくことになって、
18:04
APIのところは詳細でもいいのかなって感じがする。
APIインターフェイスの定義とかが、
内部設定とか詳細設定みたいなフェーズになって、
開発コーディングでしょ。
コーディングのところでフロントエンドとバックエンドと同時開発。
その後疎通確認。
いけそうな気もするけどね。
いけそうな気もする。
いろんなこと言われてスムーズにいかないからうまくいかないイメージがあるだけで。
形としては確かにできそうな気がするね、ウォーターホールで。
そうだね。
生化物って言われたときに、
普通にAPI単体で納品してもいい気もするけど、区切りとして。
こういうレスポンスを返すAPIまでできてます。
お客さんのIT、
お客さんのシステム部門のIT知識とかがすごく高ければ、
共通の意識で、よしじゃあこれ行こうとかになるかもしれないんだけどね。
説明のための資料のためにめちゃめちゃ重厚なものが入るようになるとか。
資料があるな、確かに。
うちの会社とかもITコンサルみたいなところだから、
お客さんにできるだけわかるようにみたいな感じで、
結局PowerPointとExcelが大量に積まれていくんでね。
そういうのをプリムにしたらこうなるかも。
フロントエンドとバックエンドの疎通作業をしなくても、
例えばフロントエンドにデータハードコードして、
それで動いているように見せたりだとか、
あとはバックエンドの方で、全然ロジックとか書いてないんだけど、
ハードコードのものを返すとかして、
いわゆるMock APIみたいな感じにして、
クライアントに見せるみたいなのもあり得るかなっていう気がする。
そうだね。
割とMockの段階を見せないとお客さんもどうしたいかわからないというか、
こうやりましょうねみたいなよくある本質の業務フローを作ったとしても、
画面にしてみたらちょっと違いましたねとか言いますから。
そういうのは結局いるよね。
基本やっぱり理想はそれを最初のUI決めのところでやりたいんですよ。
なので一番最初からHTML、CSSで、
本番リリース後と見た目はほぼ一緒なものを作る感じで認識合わせをしておいて、
21:02
そしたら途中でできているものを見せる必要もないと思うんだよね。
見せたとしてもこれ最初と同じやつですよみたいな。
だから最初の方でそれなりに角度の高いものを作る。
なんかPowerpointとかで見せないみたいな感じだね。
パープルオブジェクトの四角とか組み合わせて画面を作らないってことだね。
それを追うだけのフロントエンドエンジニアがいっぱいいないっていうのが、
うちのそれができない理由だね。
まあね、確かに。
それこそだってみやちと一緒にいた頃ってみやちがそれやってたじゃんって話で、
他のところではやってないのはみやちがいないから。
だからこそすごい重宝された記憶がある。
なんか画面イメージ作ってくださいって言って。
だって何だったら画面設計者のいつものExcelに画像を貼ってウェーってやってるやつ、
あれみやちが作った画面スクショして貼ったらすごく分からない。
まあそうだね。
そういう意味でも結局Excel作んなきゃってなった時でも画像はすげえ楽になるし、
お客さんも動作イメージワクシーみたいなね。
だから変にPowerPointで使いづらい視覚を重ね合わせてとか、
それ何回もやるくらいだったら、
最初からHTML、CSSで、
Tailwind、CSSとか使ってサクッと作っちゃった方が、
長期的には便利だと思うけどね。
SIRの皆様、
デザイナー、フロントエンドエンジニアをそういう使い方してみるのもいかがでしょうか。
本当真剣な話、
まさにTailwindとかこの間のノンデザイナーズデザインブックとか読んで、
サクッと画面を作れるようになると、
僕もまだまだですけど、
ことが柔軟に運べれるような気もするけどね。
画像をグリグリしながら、
こうかな、こうかなってお客さん会議やってるけど、
見せられる画面って話なんだよね。
それが一番用件定理が早く進むかなと思います。
やっぱり宮地が言ってたこのやり方がシンプルというか、
いろいろ削ぎ落とした結果みたいな感じで、
やっぱりこれからも使えそうな形をしてるよね。
そうは言っても、どっかでひともんちゃくあるけどね。
まだまだ改善の余地はあると思いますよ。
24:03
という意味では、削りは削ったから、
今度は出していく番なのかもしれないね。
なるほど、確かに。
ちょいちょい起きるこれを防ぐためには、
ここにこれをくっつければいいんだみたいな。
あるかもしれない。
じゃあこんな感じでしょうか。
今日はこんな感じで終わりたいと思います。
ありがとうございました。
ありがとうございました。またね。
