個人開発でマッチングアプリ作るぞ が 同人チーム開発でオタク専用SNS作るぞ になった話(後編)
表題の件です。前編はこちらです。
今から後編(個人開発から同人チーム開発になった経緯)を書いていくところなんですが、 おそらくこの記事の次に「社長を募集してみた」という、この話しの続編を書くことになるとおもいます！お楽しみに！(冒頭で突然の予告)
あと、開発のモチベになるのではてブ、スター、SNSでの拡散などしてやっていただけますと嬉しいです。
なぜ個人開発じゃなくなったのか
シンプルにわたしがプログラミングわからない、だからです。
nabettu さんの Vue.jsとFirebaseで作るミニWebサービスを積んだまま「いつか本気だす！！！(ベッドに横たわりながら)」となっていたり、「寝て起きたら突然サービスリリースされたりしないかな」と思ったりしていました(実際そうなったとしても、それは競合他社のサービスリリースですよ、わたし！)。
というのは半分冗談で、nabettuさんの本を本棚に飾りながら、一緒に作ってくれるエンジニアさんをbosyuで募集したり(30人ちょっとぐらい応募がきました)、 知り合いのエンジニアさんに声をかけたり(断られたりすっぽかされたりしました)、知り合いのエンジニアさんが「手伝おうか」といって協力してくれようとしたりなどありましたが、いろいろあって、やっぱ1人でやっていくか〜というのを何回か繰り返していました。
ら！突然、何も考えず参加した忘年会で話した初対面のエンジニアさんが「よかったら手伝いますよ、Flutter好きなんで」と声をかけてくれて一緒にやることになったのが今一緒にチームで開発やってくれてるながのくん(神)です。
「え、コード書いてくれるんですかやったー」という気持ちと「え、Flutter！！！(Webでやる気だった)」という気持ちと「で、この方名前なんていうんだったっけ…」という気持ちで忙しかったのを昨日のことのように思い出します(名前はFacebookのともだちになってもらうことで取り戻しました)。
「初対面の人の自己紹介で名前が聞き取れなかった」(初対面だと聞き取れなかったって言いづらいですよね！)とか「人の名前を覚えるのが苦手」という方はFacebookのともだちになっておくというライフハックおすすめです、ぜひご活用ください。
ちなみに、ながのくんの場合は「聞き取れなかった」ではなく「忘れてしまっていた」ですが、今では(多分)フルネームが言えます。
チーム構成と役割
先日、エンジニアさんが1人卒業してしまったので今は3人でやっています。
- むろ(わたし): UXデザイン、UIデザイン、ネイティブアプリの実装(UI)、PM業など
- ながのくん(イケメン): ネイティブアプリ、サーバーサイドの実装など
- Nくん: イケメン
という感じです。Nくんについては「社長を募集してみた」という記事にすると思います。
で、あとエンジニアさんがもう1人いるとながのくん(仕事できる)が助かるので、「一緒にやってもいいよ」っていう方いらっしゃったらぜひ… (というリクルーティング目的もあってこの記事を書いています)
で、同人チーム開発ってなに
個人開発ではなく複数人で開発することになって、ひとに「個人開発っていってもエンジニアさんと一緒にやってて〜」と話す度に「(個人開発とは)」となっていたんですが、先日ながのくん(天才)がわたしたちの関係について
「同人ってことだと思うんですよね。同人ゲーとかあるじゃないですか。あれがゲームじゃなくてアプリ開発になってるだけで」
と言ってくれたので「同人チーム開発やってます」って言うようにしました。
というわけで、有志でチーム組んでアプリ開発やってます、という感じです。
ちなみに、開発は Flutter + Firebase + GraphQL(hasura.io) という構成でやってます。
同人チーム開発ってどんな感じ？
週1で定例MTGをしつつ、SlackとGithubでコミュニケーションをとりながら、個人のプライベートの時間を使って作業しています。
完全リモートでやっていて、実際、Nくんには会ったことがないのでワンチャンAIの可能性があると思っています。
3人ともアプリケーション開発の実務経験があるのと、ながのくん(厳格)が「やるならちゃんとビジネスとしてやりたい」ということなので、仲良し3人組でキャッキャしてますというより、リーン・アジャイルな開発をちゃんとやっていますという感じです(多分…)。
ながのくん(先生)から「むろさんはPMとしての動きをちゃんとしてほしい」と言われ、PM業を勉強しながらやっているので、少しちゃんとしていないかもしれないですが(すみません…)。
と、わたしの至らないところは多々あるんですけど(そこは目を伏せつつ→わたしが)、3人が「実務経験スキルを活かしながら実務外のスキルも発動する」を活用しながらやっています。
同人チーム開発の利点
- 自分１人では成し遂げられないものを自分にないスキルを持っている人と一緒につくりあげていくことができる
- 実務で経験できないところ(自分の知らない分野)を趣味感覚で実践・勉強できる
に、大きくあります。
今回の同人チームでいうと、ながのくん(先生)から「この本を読んだほうがいい」「この動画勉強によさそう」「このアニメ見といたほうがいい(UIの参考に)」といろいろ教えてもらっていて、開発タスクというより勉強タスクが積み上がっててたいへ…充実した毎日を送っています！！！！！！！です！！！！！！！
知らない分野を勉強しながらアプリケーションという形にしていくのは、とても楽しいですし、1人じゃないという安心感がありがたいです(ながのくんいつも色々教えてくれてありがとう〜)。
そういう意味では駆け出し(デザイナー・エンジニア)のみなさんにはおすすめです。わたしも人類駆け出してるホモサピエンスなので、一緒にがんばっていきましょう！！！！
あと、「最近は業務以外で何もチャレンジしてないな〜」っていう方にも、個人開発・同人チーム開発、おすすめです！
同人チーム開発やりたいけど、どうしたらいいの
「どうやってながのくんみたいな人を見つけたの？」というのをめちゃくちゃ聞かれるんですが「とにかく自分がやりたいと思っていることを他人に伝える」で、共感してくれる人を見つける、です。
例えるなら、今あなたが読まれている今この記事がそれです。自分がやりたいことを他人に伝えましょう。
というわけで、再度宣伝となりますが、これを見て「楽しそうだし一緒にやってやってもいいよ」というエンジニアさん(Flutterに興味があってサーバーサイドの知識もあればなおありがたいです)を募集してます〜
Meetyこちらです！ meety.net
個人開発でマッチングアプリ作るぞ が 同人チーム開発でオタク専用SNS作るぞ になった話(前編)
未経験から人類やってる駆け出しホモサピエンスこと、むろです。
表題の件についてです。
こまごまとSNSなどでアウトプットしてましたが、そろそろ記事にすることで自分を 絶対リリースする に追い込んでいくことにしました。
マッチングアプリからオタク専用SNSに方向転換の経緯
なぜマッチングアプリを作ろうと思ったのか
わたし自身がマッチングアプリで婚活していた時のユーザー体験であった「なんか違う」を解決したかったためです。
なぜオタク専用SNSに方向転換したのか
なんか違う、を確かめるためにアマゾンの奥地にいった(市場調査のため婚活アプリを使ってみたけど失敗した方へのユーザーインタビューをした)結果、見えてきたのが
- 女性上位の構図になっているのが起因の男性の「いいね連打ゲー化」によるミスマッチング
- ステータス(見た目、年収、学歴など)重視の選定をするトレンド傾向由来のカルチャーフィット軽視問題
でした。 どちらも、「会ってみたらなんか違った」「会話(メッセージ)が続かない(盛り上がらない)」などのよくある問題に繋がります。
そして、このペインのうち、カルチャーフィット に焦点を当てた結果、「出会いが入り口ではなく、趣味嗜好の合うともだちからの発展」が、パートナーとして最適な人との出会い なのではという仮説に至りました。
ともだちから始まる恋愛→結婚が正解なのかの仮説を確認する意味で恋愛心理学の本を読み漁ったのが前回の記事です。
で、記事内には書いてませんが、一番参考になったのが恋愛の科学です。
下記は恋愛の科学を抜粋して開発チームに説明するためのmiroの様子です。
詳細を省きますが、仮説はおおむね間違っていないとしました。
そこから、カルチャーとはオタク文化なのでは、となり、「オタク専用SNSサービスを作ろう」に発展しました。
それで、オタクと一言でいっても最近は好きな対象を「推し」と表現するぐらいにカテゴリが幅広くなってきているので、
オタクのカテゴリと深度による違いなどの分析もしたりし(論文まで読んだりしました)、
そして、ここからカテゴリによって私の作りたいサービスのニーズがあるのかどうかのインタビューもしました
(結果、ジャンルによっては既存SNSの活用でいけるものもありました)。
など、色々やっていった結果、完全に「オタク専用SNSを作るぞ！！！」になってしまい、 そこから「出会い厨許さない」(健全にともだちになって欲しい)になぜかなってしまったので わたしがマッチングしたくて作ろうと思っていた部分は消え去りました(ここ重要)。
というわけで、長くなってきたので後編に続きます。 後編で個人からチームになったことを書きます。
マッチングアプリを作ろうと思って恋愛本読み漁ったわたしのオススメの本2冊
こんにちは、むろです。 表題の件です。
タイトル画像とtitleにある通りなんですが、1月中、マッチングアプリを作ろうと思って恋愛心理学や恋愛周辺の本を読めるだけ読んだ(遅読なのでたった8冊なんですけど…)ので、その中から「恋愛心理学とか難しいことはいいので、手っ取り早くしあわせになる方法教えてほしい」という人にオススメの本2冊を紹介します。
どちらも恋愛心理学で提唱されている理論がエビデンスベースにあるので、「100人の女抱いた俺が実践から解く女の落とし方」「ホステスやった私が男をトリコにする女とは」のような、統計学的に実証されていない1人(モテる人が独自の視点で)が自分語りするものと違って信頼性が高く、恋愛心理学を説いてくれているだけの本と違って実例や解決策も提示してくれているので読了に謎の達成感(恋愛完全に理解した => エンジニア仕草の「完全に理解した」=「概要理解した=詳細は知らんけど」)がでます。
自分の恋愛に当てはめる事もできるし、わたしみたいに「今とくに対象がいない」方でも「Aくん(ちゃん)じゃんこれ…」みたいに周りの人の恋愛に当てはめて読むことができて楽しいと思います。
異性の心を上手に透視する方法
- どんな人が読んだらいいか: 恋愛交際に悩みを持つことが多い、長続きしない(自分は結婚を見据えた長期交際なのに相手がそうならない)などの問題があるひと
恋愛タイプの分類をアタッチメント・タイプの角度から、人類をたった3つに分けて提唱されている理論がベースです。
Sタイプ(安定型)、Nタイプ(不安型)、Vタイプ(回避型)が、交際においてアタッチメント(愛情の対象との距離)をどう捉え、どう対処しようとする傾向があるのか(が、問題の鍵です)を、実例を挙げながら説明してくれています。
Nタイプ(不安型)は日本で属にいう「メンヘラ」のことですが、なぜNタイプの人が「メンヘラ仕草」を爆発させてくるのかが理解できるので、 交際相手がその傾向が強い人が読むにはとても参考になると思います。 が、個人の感想としてNタイプ(不安型)をどうやってなおしたらいいのかの部分が「それができるなら安定してるのでは…(できないから不安なのでは…)」となったので、自分がNタイプだと思う方は2冊目も読むのがオススメです。
Vタイプ(回避型)は「一人の時間が絶対必要。人との距離が近いとつらい。同棲も結婚も想像できない。」みたいな人のことで、このひとは恋愛対象ではなく自分自身に問題を持っているタイプなんですが、それをなおす方法も挙げられているので、自分がVタイプではない場合は交際相手のためにも、自分がVタイプの場合は自分の今後の人生のためにも読むのをオススメします。
ちなみに私はもともとVタイプ(回避型)で、Sタイプ(安定型)に修正しようとしていた(名前がついてることは知らなかったけど現象を問題として自覚していた)ところだったので、とても参考になりました。
ベストパートナーと宇宙一カンタンにつながる方法
- どんな人が読んだらいいのか: 今の恋愛(片思いも含め)を成就させたい、(前述の本で)Nタイプ(不安型)なのをなおしたい人
この本は前述の本と違って、恋愛心理学の理論やそれの説明は全くなく、男性と女性それぞれの目線(性質)からストーリーを追いつつ問題の解決方法を教えてくれる物語形式の本です。 「好きな人へのアプローチをどうしたらいいのかわからない…(自分に自信がなくて)」という人は背中を押してもらえるし、「彼(彼女)からの連絡を待ち続けてしまう(依存してしまう)のをどうにかしたい」という人は自我の取り戻し方とかが書かれていて、前述の本のNタイプ(不安型)の人はとても参考になる本だと思います。
男性性・女性性について特性と傾向について説明されていて、流れに沿って双方を読み解くことができるので、ベストパートナーを見つけやすい人になる・自分がベストパートナーになることができるんじゃないかなー(だといいね)ということでオススメです。
どちら(男性性、女性性)にしても、自分の気持ちを素直に表現することが魅力的な人物であることになるので成就率も高くなるんだな〜というのが大きな感想でした。
あと、個人の感想ですが、この本の直前に読んでいた「 恋愛心理学特論: 恋愛する青年/しない青年の読み解き方 | 康雅, 高坂 |本 | 通販 | Amazon」で言及されている「アイデンティティのための恋愛」、「エネルギーで捉える青年期の恋愛」(エネルギーとはリビドーのことを指します)あたりの内容とリンクしていたので「まさにアイデンティティの確立とエネルギー奪い合いなー」と、楽しく読めました(この本はストーリー重視なので、ガチの恋愛心理学論 = エビデンスについての説明、は省かれているけど、それらから大きく外れてもいないと感じたので楽しかった)。
他にもおすすめの本はあるんですが、とりあえずこの2冊は面白い(平易な表現なので読み解きやすい)のと実践に適用できるコスパの良さからオススメです。
もくもく寺でオフライン・オンライン合わせてイベントを197回やりました
こんにちは、むろです。 表題の件です。
先日、【勉強会の勉強会】大人のホームルーム 職員会議の自己紹介で、わたしがやってる勉強会(寺)について説明した時に「140回以上やってるのすごすぎるのでは」という感想をいただき、「たしかに…！」となって嬉しかったのでブログを書くことにしました。あと、オンラインのもくもく回が今回で開催100回目になりました！すごい！！
寺(以下、コミュニティのことを略して寺と表します)をはじめてから4年目(多分…)で、オフライン・オンライン含めて今日で197回のイベントを開催したことになります。
「はじめるだけなら誰でもできる。はじめるからには継続させていく。」というのをひっそり目標として持っていたので、ここまで続けることが出来たのはほんとに良かったです。ひとえに参加してくださる皆さん、運営メンバーの方々のおかげです。ありがとうありがとう！！
寺の中には寺経由で転職先を見つけたり、交際相手を見つけたりしている人もいて、ライフイベントに寄与することが出来てるのって何だかコミュニティだな〜という感じうれしいです(雑な感想)。
途中で疲れてやめようかなと何度も思ったんですが、結局ここまでやってこれましたし、あともう少し頑張れそうな感じなので、「私なりに運営を継続していく秘訣(2つ)」と、今後の展望とこれまでとこれからのお気持ち(つまりポエム)を書いてみようかなと思います。
1, 運営にかかるコスト(費用ではなく手間)を最小限にする
イベントを開催すればするほど新たな参加者は増えていきます。
最初のころはSlackの使い方についてや、Github(で自己紹介用のリポジトリがあります)にPR出してくださいねなどのオンボーディングを口頭やSlackなどでいちいちしていたのですが、Slackの使い方については、チャンネル名を適切なものにすることで説明を省き、Githubへの案内はSlackBotに任せることにするなどで省略することにしました。
ちなみにSlackのチャンネルについて最初のうちは「みなさん適当に作ってください」という運営方針だったのですが、 チャンネルが乱立する・チャンネル名を見ただけだと何を話したらいいのかわからないなどの問題があったため、途中で
- 基本的に日本語を使用する(よくわからない英語単語を使うことで個々の解釈の違いを生まないようにする)
- チャンネルに入る前に用途が伝わる名前設計にする
という事を運営メンバーで協議して決め、整理しました。ちなみに現状こんな感じです。
それと「初回でこれだけ多くのチャンネルに入ってしまうと混乱してしまうのでは」ということで、デフォルトで参加するチャンネルは下記だけに絞っています。
これをするだけで、新たな参加者が表示されるたびに私や他の方が説明していた手間が省け、Slackからの通知に縛られる事がなくなりました。
Githubへの誘導は毎週Botに「PRだしてくださいね〜」と言わせているだけなので、あまり即効性はないのですが、今の所これだけの人の自己紹介が集まってるのでまあヨシ！(現場猫)という感想です。
あとまだまだ少し細かい問題があるんですが、DocBaseさん(KRAYさん)にツールスポンサーとしてご協賛いただいてる(ありがたやあああああ)ので、Docbaseを活用して解決していこうと思ってます。
2, 1人でがんばらない(運営チームを作る)
2年近く1人でオフラインのもくもく会を開催していたのですが、1人でがんばることに限界を感じ始め、寺をたたむか続けるかで悩んだ結果、2年前から運営チームを作り、複数人で運営する体制にして続けることにしました。
運営チームをつくることで
- 相談する相手がいることで悩む時間が減った(コスト削減)
- 運営についての知見を与えてもらえる(意見だけではなく、他ではこうやってましたよなどの有益情報がもらえる)
などなど、他にもいろいろ細かい「運営チームありがたい…」がたくさんあって、色々と気づかなかった「1人でがんばってた」部分をフォローしてもらえて、継続についての精神的な負荷がかなり軽減されましたし、みんながいるので「寺、たたむか」と思うことはなくなりました。
ちなみに、いま運営にいる人はほとんど私が声をかけた人なんですが、わたしが独断で運営してくのを防ぐため、運営についての提案(この人を運営チームにいれたい、も提案です)はすべて「運営チームから5人以上のApproveをもらう」というルールでやっています。
提案内容によっては協議というかガチ口論に発展することもあるんですが、みんなオトナなので主観で意見を述べながら客観視も持ってくれているので議論はそんなに破綻せず、折衷案を受け止めてくれるので若干成り立っている、という感じです(多分…)。。
今後の展望
継続していきたいし、もっとよくしていきたいところ
- どこでもいつでも、場所も時間も関係なく人の繋がりを持てる場を提供していきたい
- 初学者も上級者も関係なく意見交換できる場にしていきたい
新たな挑戦
- 何かしらのOSS活動的な何かをはじめる(これは今運営で相談してます)
これまでとこれからのお気持ち
で、以下ポエムです。
もくもく会を自分で初めようとした時に、ようちゃんさんに聞かれた「むろさんはどうしたいの？」に対しての答え「わたしは昔のわたしみたいな人を救いたいと思っています」をいつでも持っています。
「昔のわたし」は、ひとりでわからない分野をもくもくと勉強していて辛い、という状態でした。 フリーランスなので頼れる先輩もいなくて、ひとりでわからない分野を地道に勉強してくのは辛いし、わからない事がわからないのがとても辛い。
なので、寺は「わからない分野をもくもくしているけど、もくもくしているのは一人ではない。」という環境を構築していきたいと考えて、運営チームを作る当初にわたしの思想として説明していたのが「オンラインゲームをやっていた頃のようにしたい」でした。
ひとりで狩りにいって、欲しいアイテムをgetしたらチャットで「完全に理解した」を言う、狩りにいったけど虚無だったわーの時は「生産性ゼロだった」、再び狩場にいってレアアイテムがとれた時は「コントリビュートした」などの報告をしあい、その報告をお互い「おめー」と言いあう、違う場所で違う事をしながら共有してるのは時間と成果だけなんだけど、なぜかチーム感がある世界観、です。
何気なく、つらいことやうれしかったことを報告しあい、成長を讃えあえる「仲間」を形成する場、それがコミュニティなんだと思っていて、寺はそれになっていてほしいし、そうなりたいなーと思っています。
「エンジニアになりたい」「デザイナーになりたい」、という気持ちはとてもすてきで大切にしていて欲しい目標ですし、それを「どうしたらいいのかわからない」という人たちの駆け込み寺でありたい、というのが「寺」を名前にいれている根底です。ここは私がいる限り、変わらない思想です。
「フロントエンド」を銘打ってるのは、わたし自身が「結局どんなサービスも結局ブラウザで表示することになる」と思っているというだけで、根本は「使う人がいるアプリケーションサービスの見える部分の技術をフロントエンドと呼ぶ」だという解釈です。つまり基本的にWebサービスに限らず、アプリケーションのレンダリング部分に携わる人を対象にしていますし、それはエンジニアに限らず、デザイナー、経営者、PM、マーケティング担当などなど、主業種は限定していません。
限定するなら、ただ勉強会・コミュニティに参加しているという自己満足だけで所属し、自己を研磨する(=もくもくする)努力をしていない人(短絡的に言うとワナビー)はお断りしたい、というのはありますが…(小声)。
というわけで、TLで「わからなくてつらい」って言ってる人がいなくなるまで続けていこうかなと思います。
新規参加者も運営をお手伝いしてくださる方も募集中です。一緒に楽しくもくもくしていきましょう😃✨
長文、失礼しました。
新型コロナのアレコレをポジティブに捉えようとした結果、カジュアルにホクロ除去した
なんで書くことにしたのか
顔の中心あたりにあったものが突然なくなるので、周りの方々に「おそらく次回あった時に顔が変わっています」を宣言しておこうと思ったからです。
なにをしたのか
美容外科で、鼻にあったホクロ(というかイボ)をレーザーで除去してきました。
なんでやったのか
タイトルの通りなんですが、人と会う機会が減ることをポジティブに考えてみようと思ったところ、たどり着いたのが「プチ整形やってみよ」でした。 (それと、先日あった方から「今ならダウンタイム中もマスクで隠すことも可能！」と教えていただき「ほんそれ」となった、というのもあります。)
あと、美容系Youtuber(や、その周辺のYoutuber)の方々の動画を見ていて、整形についての偏見がなくなるどころか、若干プチ整形に憧れを持ち始めた、というのもあります。
なんでホクロ除去なのか
プチ整形するならどこをやろう〜というのは色々考えたんですが、「とりあえず鼻のホクロ取るのが先だろ」って身内から言われるな絶対と思ったので、今回はホクロ除去することにしました。
ちなみに、個人的に鼻のホクロについては特に何の感情も持ってなかったのですが、親戚から取れと言われることが多かったのと、ホクロのおかげで人から記憶されることが多いのが面倒(特に覚えてほしいと思ってない人から覚えられるのを面倒に思うぐらいに覚えられる)だったというところからです。
手術までの流れ
クリニック選び
元来わたしはおそろしく優柔不断なので、ここに一番時間が奪われてしまうと思ったので、あえて「{駅名} ホクロ除去」ぐらいの雑なキーワードで一番に出てきたクリニックに予約しました(検索から電話までおよそ5分)。 あと、これは憶測でしかないですが、SEMあたりにお金をつぎ込むことができる病院は技術的に遅れたことやってないんじゃないかなと思ってるのと、口コミの書き込みなどもお金次第でどうにでもなる世界=信頼できないと思ってるので、あえて見ないようにしました。
予約
問い合わせフォームもあったんですが、電話で予約しました。 「ホクロ除去で検索して出てきたページ見て電話してます、診察の予約したいです〜」ということで、直近の予約可能日(3日後)にわたしも予定がなかったので予約しました。 「特にご用意していただく物はないので、お時間にお越しください」と言われたので、特に準備もせず適当に向かいました。
診察から手術まで
問診票に記入→診察→手術の流れとホームページにあったので、診断と手術の日は同日とは限らない感じだったんですが、「今日やっていきますか？」「あ、はい」ぐらいの感覚でやってきました。
問診票の内容は普通の病院とほぼ同じ内容(薬のアレルギーあるか、麻酔で何かあったことあるか、妊娠してないか)で、診察はお医者さんから「ホクロ、ちょっと大きそうだけど切開するってほどでもないし、レーザーでいいんじゃないかな」と言われたぐらいでした。
手術することにしたら、支払いをし、5分も立たないうちに看護婦さんに手術室に連れていかれて、麻酔を打ち、麻酔が効いてくるまで待つ、レーザーで患部をジャッ焼かれる、おしまい。
という、説明が完結すぎる気がしますがこれ以上特に情報もないというぐらいシンプルに終わりました。
あえて書くなら、麻酔が思ったより痛かったので「いたい…」という内なる声が外に出た、ぐらいです。あと、ちょっと涙がでました。
やってみてどうだったか
まだ当日なので感想は特にないんですが、事前に調べていた情報から想定していたよりも恐ろしく早く終わったので、やろうかなと思ってる方はとりあえずやってみてもいいんじゃないかなと思います。
こちらからは以上です。
デザイナーが開発チームの一員としてcommitしていくための知識(開発手法これ押さえてこ編)
こんにちは、むろです。
未経験から人類やってる駆け出しホモサピエンスです。
このエントリーはbosyuアドベントカレンダーの21日目のやつです。前日はめろたんのJavaScriptの不思議なやつで、明日はnaoさんがなにかかきます。
それで、今回わたしは デザイナーが開発チームの一員としてcommitしていくための知識(開発手法これ押さえてこ編) ということで、デザイナーでも読みやすいおすすめ本をご紹介します！！
どんな人に読んでほしいか
- 駆け出しWebデザイナーさん
- 受託系から事業系(インハウスデザイナー)に転職したいなと思っているデザイナーさん
- デザイナーと仲良くなりたいなと思ってくれてるエンジニアさん
押さえとくポイント
最近の事業開発はさまざまな思想だったり開発手法だったりがあるんですが、だいたいこの4つの単語の意味を知っておくと、 チームの一員として最適な振る舞いが出来るようになります。
- リーンスタートアップ
- アジャイル
- スクラム
- スプリント
というわけで、以下おすすめ本なのですが、わたしまだ上の2冊しか読んでなくて、それ以降は寺で教えてもらった本です。 (注: リンクにはたぶんhatenaのアフィリエイトIDがついてます)
個人的に、上2冊だけでも事前知識として持っておくには十分だと思いますが、お時間あるときに読んでみてください！
- 作者:Jonathan Rasmusson
- 出版社/メーカー: オーム社
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
表紙の雰囲気だと「エンジニアさん向けのむずかしい本なのでは」という印象を持つ人も多いかもしれませんが、 内容は自体はとても優しく、わかりやすい言葉で表現をしてくれているのでとても読み進めやすいです。 マスターセンセイが楽しくアジャイルを教えてくれます。
タイトルにUXがついてますが、ほとんどリーン→アジャイルの本です。 イテレーションにUXデザインを組み込むにはどうしたらいいのかがわかりやすく書かれていておすすめです。
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 作者:市谷聡啓
- 出版社/メーカー: ビー・エヌ・エヌ新社
- 発売日: 2019/06/14
- メディア: 単行本
スクラム関連の本あんまり読んだことないですが、この本は実際の事例とか体験を踏まえてプロダクト開発全般について触れているので面白かったです
とのことです！
- 作者:ジェフ・サザーランド
- 出版社/メーカー: 早川書房
- 発売日: 2015/06/24
- メディア: 単行本（ソフトカバー）
腹筋さんからのオススメです。ありがとうございます！
スクラムの概念的なものが知りたければこちらもおすすめです。
とのことです！
matsuhisaさんからのオススメです。ありがとうございますー！
これがわかりやすくて、読みやすくて、使いやすかったです。
とのことです！
第一部だけ読むだけでも価値のある本かなと思ってます。 案外薄くてサクッと読めるのも良い点
とのことです！
他にも、おすすめの本があったら教えていただけると嬉しいです。
こちらからは以上となります。
PR
bosyuではデザイナーをbosyuしているようです！
デザイナーが開発チームの一員としてcommitしていくための知識(インブラウザデザイン編)
こんにちは、むろです。
未経験から人類やってる駆け出しホモサピエンスです。
このエントリーはbosyuアドベントカレンダーの15日目のやつです。前日はluluさんの整数→クウェンヤ数字の変換を実装しながらRuby2.7のNumbered Parameters使ってみるで、明日はkoyoがなにかかきます。
で、今回わたしはデザイナーが開発チームの一員としてcommitしていくための知識(インブラウザデザイン編)として、 普段インブラウザでデザインしている様子を動画にとったのでみなさんに見てもらえたらなと思います。
どういう人に見てほしいか
- 駆け出しWebデザイナーさん
- 受託系から事業系(インハウスデザイナー)に転職したいなと思っているデザイナーさん
- デザイナーと仲良くなりたいなと思ってくれてるエンジニアさん
今回の動画でやっていないこと
- 正しいマークアップ
あくまで、ブラウザ上でデザインを試行錯誤する様子をお伝えすることに注力しているので、HTMLとCSSは適当です。
CSS警察のみなさんからの「僕(わたし)ならこう書く」などのマウントをお待ちしています〜
普段、仕事でやる場合はちゃんと書いてます…というか、今回のやつだとdisplay: flex; でもう少しいい感じに書くと思います…
インブラウザデザインとは
XD, Sketch, Figma などのデザインツールを使わず、ブラウザ上でCSSを書きながらデザインをする手法です。
デザインの作成とコーディングが同時に行えるので、工数削減が出来て便利ですが、HTMLとCSSの事前知識がある程度必要になります。
今回は適当にさらさら書いていますが、普段はCSSのプロパティをぐぐりながら書いてます。
※: すべてのデザイン作業をインブラウザでやっているわけではありません。わたしの場合の使い分けは後で記述しますね。
インブラウザデザインの様子
まずはこちらをご覧ください。
動画初めてなので編集を全然していないのと、ゆるふわなので少し長くなってます。すみません。。
https://drive.google.com/file/d/1QUfIBiLKDuy8aeryETRi0CrVP09eGHHO/view?usp=sharing
解説
bosyu.me から、2019/12/15現在、TOPページに置かれているHTMLとCSSをダウンロードしてきたものをソースとして使い、SlimとScssで書いています(なので、SlimもScssも実際のコードとは別物なので中の人、安心してください！！！！)。
今回は、bosyu.meのヘッダーに検索窓をつけてみるデザインをやってみています。
作業の流れ
動画になっていない部分
- Githubからブランチをもってくる
- ローカルでサーバーを起動する
動画になってる部分
- Chromeのdevtoolで見た目を確認しながらデザインをする
- SlimとScssを書く
- Gitでdiffを確認してcommitする
という感じです。
途中で黒い画面とGitを使っていますが、こちらについてはすでに記事にしているのであわせて読んでもらえると嬉しいです。
補足
- Devtoolで編集した分の差分はdevtool上で確認することもできます 方法はこちら
こらちは@hanachin_さんから教えていただきました！ありがとうございます！！！！！
いただいた質問
実装のエンジニアとCSSコーダーで分業する際に注意していること（作業スコープって実際きれいに分けられるもの？など)
- CSSコーダーというかマークアップエンジニアさんの役割を担ってる感じなので、作業の切りわけについては機能の規模や、わたしがアサインされるタイミング、エンジニアさんのスキル(フロントエンドスキル)によって変わってくるので、作業前に確認します。大体はわたしが「HTMLとCSSしか書かない」と決めているので、Railsなどの場合はだいたいきれいに分けられるのですが、フロントエンドがSPAだったりする場合は事前に相談してからやってます。
毎回このようにdevToolで直接デザイン＆コーディングしていくかたちなのか？
以上です。
今回わたしはbosyu.meさんを使ってデザインしてみましたが、みなさんもいつも使っているWebサービス(Twitterだったり)で試しに遊んでみたりしてみてください！
ちなみに、bosyuをテーマにしたのでわたしがbosyuでもこういう作業をしているように思われたかと思うんですが、実はわたしはbosyuでUIデザインはほとんどやってません。なので、もしかしていつかbosyuに検索窓が現れたとしても、おそらくデザインは他の方がされたやつです…！！！！
PR
bosyuではデザイナーさんを募集していますよー！
