00:07
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェビ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日は、タイトルになります、「モノを作るときは枠から作る話」みたいな、雑なタイトルにしてるんですけど、
あの、僕の好きな漫画の中に、ハチミツとクローバーって漫画があるんですね。
まあ、好みすごい分かれる作者、海の地下さんの漫画ですけど、その中でですね、主人公が一回瞑想することがあって、
で、いわゆる美大に行かれている主人公が、自分探しをする旅に出て、その中で、なんだっけ、古い建物とかを修理する仕事を、
全国のですね、物価もそうですし、自社とか、普通の建物もありますし、歴史的な建物とかの修繕をする仕事をしている方々に偶然出会うんですね。
で、その中で、ちょっと手伝わせてくれって言うので、ガンガンやるんですけど、彼はそういう都備職だったりとか、建築系のお仕事っていうのを全然やったことがないので、本当にど素人です。
ただ、木を触るのはものすごく好きだし、物作り自体も彼は好きなので、どうせなら関わっていきたいなっていうところで、
で、彼の得意分野が料理だったので、まずはお料理周り、ところから皆さんのサポートをしつつ、お仕事をさせてもらいつつ、お金をもらって次の旅に出るみたいなお話があるんですね。
で、その中で感じたこととかがすごく僕には刺さっていて、彼はその経験値も得てからまた戻ってきて、卒業制作にもう一回入るんですね。
で、制作する中での彼のお話で、僕が一つ、これはエンジニアにも刺さるというか、適応できるお話だなって思ったことが一つあって、
彼はですね、作中で一つの大きな塔を作ろうとするんですね。美大なのですごく変わったデザインの塔なんですけど、
その塔を作る時に、昔はもうずっとひたすらまず土台、下から作って上にどんどん伸ばしていくみたいなやり方をやってたんですけど、
建築とかって、家を作るんですけど、まず最初に作るのって足場を作るじゃないですか。
で、彼がその中でついたのは、建築家の人たちは物を作る時、その物より大きな土台から作るところからスタートするって話をしてるんですね。
そういうふうな実感を得て、今まで気づかなかったことを気づいたって話がしてて、これがすごく面白かったですね。
土台というか、今回のタイトルは枠って言ってるんですけど、枠は同じ話をしてるなっていうふうに感じました。
ソフトウェアでも全体設計とか詳細設計もしますし、基本設計もしますし、画面設計したり、いろんな設計はもちろんするんですけど、
その中で実際僕らアプリケーションエンジニアのアプリケーションを作っていきますが、何から作るかっていうところがすごく悩ましいですね。
ですけど、ここはやっぱり枠から作るのは本当その通りだなと思ったりしてます。
例えば僕はフロントエンドエンジニアなので、HTMLを書いていくんですけど、もちろん開発するときは先に開発環境から作るのはその通りだと思います。
03:04
土台から作るっていうのはまさにそこですね。
メインとなるフレームワークを決めます。周辺ライブラリーで今回必要なものは必ず入れますとか。
リンターフォーマッター入れますとか。
あとハスキー入れてコミット周りのところもちゃんとチェックするようにします。
たくさんその辺の環境整備っていうのはしますね。
最近はフレームワークがCLIを用意してくれて、対話的にこれ環境で良いですよねみたいなテンプレートを使ってからスタートすることがほぼほぼだと思うんですけど。
まずは環境整備をするところは本当によくあると思いますし、
あとCSSとかもデフォルトでブレークポイントを決めたりとか、レスポンシブの値を決めたりとか、各タイポグラフィ周りのフォントの周りのサイズとかのデフォルトを決めておくとか。
それをベースCSSとか何たらCSSみたいなもので先にガーッと定義しちゃうんですね。
みたいなことをやったりします。
デザインシステムも作っていく案件があればそこのデザインシステムの値をそのままCSSファイルに落とし込んだりとかしますけど。
ような感じでまず土台とかワークを作ります。
で、実際にHTMLで書くときもざっくりディブタグをどんどんどんどん放り込んでいくんですね。
これサイトバー、これヘッダー、ここはメインで。
メインの中にもこの要素この要素みたいなのをとりあえずディブタグでガッと置いていって、
その中にとりあえず何のコンポーネント後で整備しますみたいなテキストをベタで書いていって、中をどんどんどんどん修正をしていくみたいな感じですね。
先にそうディブタグ置いていくと後でレイアウトするのも簡単になってくるんですよね。
先にディブタグの中に書くレイアウトの文字だけじゃなくて一応バックグラウンドで色だけ付けておいて、
先にレイアウトだけ決めて中のコンテンツはどんどんやっていくとかやりますね。
そこを作ったらその先に僕だったらですね、アプリを作るときに先にデプロイフローを僕は決めちゃいます。
作るに作っていって最後にデプロイするときにこけるのが面倒くさいのと、
一回正常系でビルドが通りました。
テストはその先にやるんですけど、できるのはテストも書いて、
ギルドしてデプロイして少なくともブラウザから見れたりとか、
アプリから見れたりみたいなところまでをやってから中身のコンテンツを僕は作ったりします。
本当はその枠を先に作る方がいいんじゃないかなっていうのが僕の感じたところであります。
実際のプロジェクトでは役割分担をしてインフラは別の方やったり、
僕はさっき言った通りフロントエンドエンジニアでフロントエンドからやったり、
そういう細かな設計だけ先にやってしまって、すぐにアプリ作り始めるとかもやったりしますし、
プロジェクトによってはいわゆるATOMSレベルのコンポーネントから作り始めたりとかもしますけど、
ATOMSも僕の中では枠のカテゴライズに入りますね。
細かな微調整は作りながらやっていくんですけど、
大枠として必要な粒ってのはこれだよねみたいなのを作ってからやるんですね。
このように枠を作るのが先に入ってくるので、
プロジェクトマネジメントの観点からすると物を作っているように見えているけど、
実は枠しか作っていないので、実際に本来プロジェクトで作りたいものじゃないじゃんみたいなのがあったりするので、
06:03
ここはビズサイドの人たちの見え方が難しいかもしれないですけど、
ビズサイドの方々にもエンジニアとか技術者ってそういうものから、
枠から作って中身に入っていくっていうのをご理解いただきたいなっていうのはあるかもしれないですね。
なんでこれが大事かっていうと、中身とか細かなところから作っていくと、
最後に微調整するとき、微じゃなくなるんですよね。
超無理やりな真改造をしないと、最終的にガチャンとマージすることができなかったりするんですよね。
だから先に大きな枠を作って、その中を微調整するような形にしていかないと難しいと思うんですよね。
よくある役割分担をしていって、最後に接合していくと、
接合をタイミングでてんやわんやしたりとか、エラーの音パレードが出たりとか、
よくあるのはフロントエンドとバックエンドのAPI接続とかをやるときに、
全然うまくいかんじゃんみたいなのがよくあったりするので、
先にちょっとずつ繋ぎながらやれたら一番いいんですし、
繋がるっていう正常形1本でも先に作っておけば、
あとはそれに乗っかりながらとか、それを参考にしながらやればいいっていうので、
ベースとなる枠とか土台を作る方が最優先でしょっていうのは僕は思ったりします。
とにかく正常形が1つちゃんと通るっていうところですね。
デプロイのところまでの正常形を作るのが大事なんじゃないのかなっていうのが、
僕の感じるところであります。
っていうのを最初に挙げた漫画のキャラクターの発言からそうだよなって思ってて、
言われないと確かに枠から作るって無意識にやってたり、
そもそも意識できてなかったりするなってすごく思ったので、
改めて言語化していただいたのはすごくありがたかったなっていう感じです。
というので今日はちょっと短いですけど、そういうような枠から作るっていう話でした。
また参考になれば幸いです。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
