株式会社クイックのWebサービス開発blog

HAPPYなサービスプランナー・エンジニア・デザイナーのブログです。

大量のデータを移行して大変だったこと

こんにちは!なししです。

ブログ書くの久しぶりだなぁと思ったら、なんと一年ぶりでした!

aimstogeek.hatenablog.com

(今年も花粉には悩まされています‥)

さて今回は、データ移行のお話をしていきたいと思います。
というのも普段は、設計・開発・保守運用というところを主に担当しているのですが、ありがたいことに大きい規模のデータ移行を任せていただきました。 小規模なデータ移行は行ったことがあったのですが、何十万件あるデータの移行作業は初めてでドキドキの毎日でした。

たくさんの学びがあった中で、今回はデータ移行を行うにあたって大変だったことを中心に共有できればと思います!

ミッション

業務システムのリプレースを行うにあたって、旧システム(外部システム)のデータを新システム(内部システム)にデータ移行するというものでした。

初めて大きなデータ移行に携わる中で「成功するかな。大丈夫かな。不安だな。」っていう気持ちがありつつも、「やってやるぞ!成功させるぞ!」という強い気持ちを持って取り組みました。

データ移行で大変だったこと

不整合データのチェック

旧システムでは不整合になっているデータがわかりづらく、移行テストをしてみたら
「ここデータ不整合でシステムがうまく動かない!画面が表示されない!」
というケースが何件かありました。

旧システムのDBをみることはできなく、データ移行テストをして初めてデータ不整合に気づくという流れだったので気づくのに時間がかかってしまいました。 画面がうまく動かない、表示されないのはアプリケーションバグであるかどうかという切り口で入って調査していたので、その分の時間もかかってしまったというのもあります。

旧システムの画面上からデータ不整合に気づくことはかなり難しく、すごーく注意して画面を遷移しながらそれぞれのデータを見比べる作業をしなければ気付けない、かつデータが何十万件もあるので、旧システムからデータ不整合を見つけるのは時間的にも厳しい状態でした。

新システムにデータを入れてみて、データ不整合になってしまう根本原因を探り、移行したらデータ不整合が発生してしまうデータ一覧を出し、旧システムで修正していくという手順で解決することができました。

データ移行テスト

データ移行テストについては、正直なにが正解だったかまだ答えはみつけてられてないです。

データ移行テストは、何十万件とデータがある中ですべてのデータパターンをチェックすると膨大な時間がかかってしまうというところもあり、完璧なテストをすることは難しかったです。 旧システムの項目1を新システムの項目2に移行した結果をチェックするのは簡単なのですが、項目の値だったり、データが入ってるか入ってないかなどで条件分岐し、データを入れてくというのも多かったので、すべてをチェックするのは残された時間や人力も足りず難しい状況でした。

今回は旧システムの項目と新システムの項目のマッピングが期待通りになっているかということを確認すること、またここが移行できてなかったら業務が止まってしまう!というところをメインに目視チェックをしデータ移行が期待通りに行われているかというのを確認しました。

CSVで出力することにより改行後が1行とみなされる

移行方法として、旧システムからCSVデータをエクスポートしてそれを私たちが普段から使ってるETLツールを使って移行作業を行ったのですが、改行が含まれていると改行後の文字列が1行としてみなされてしまうので、移行処理がうまくいかないということがありました。

これについては、時間を作って調べれば解決できたかも‥と思うことではあるのですがそれよりも優先することが山のようにあったので、エクスポートしたCSVをエクセルにすることでなんとか乗り越えました。 エクセルにすることによって、文字コードを変換するという作業も発生したのですが、特殊文字が入ってる項目がそんなに多くなかったこともあり別途移行処理を追加することで解決しました。

まとめ

今回は大きいデータ移行を経験して、大変だったこと3つあげてみました。
大変の裏側には得るものも多く、貴重な経験ができて本当によかったです。

予定通り新システムはリリースでき、リリース後業務が止まってしまうようなデータ不備もなく大成功に終わりました!
(残念ながら軽いデータ不備は何件かありました‥が、すぐ対応しました)

リリース当日は寝坊してデータ移行が失敗する夢を見てヒヤヒヤしましたが、無事終えられてよかったです!

今後またデータ移行に携わることがあれば、今回の経験を生かして頑張りたいと思います!


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp

Next.jsでプリレンダリング機能を使う

こんにちは。ソフトウェアエンジニアのやぎーです。

暖かくなってきましたが、みなさん花粉症は大丈夫でしょうか。

今回は、Next.jsで使えるプリレンダリング機能についてお話ししたいと思います。

Next.jsとは

Next.jsは、Reactをベースに作られたWebフレームワークで、Node.js上で実行されます。
ファイルベースのルーティングやプリレンダリング機能を提供しており、
開発元であるVercelのプラットフォームを利用すれば、デプロイ〜配信を簡単に行うことができます。

プリレンダリング(Pre-rendering)機能について

プリレンダリング機能は、ウェブサイトを表示する際に必要な
データ取得やJavaScriptをWebサーバーで実行し、HTMLの生成を行います。

Next.jsでは、ページ毎にレンダリング方式を指定できるため、
SSGとSSRを用いたハイブリッド構成のアプリを作ることもできます。

SSR(Server Side Rendering)

クライアントからWebサーバーにアクセスした際に、サーバー側でHTMLの生成を行います。 動的なコンテンツや即時反映が必要なページに利用できますが、Webサーバーを常時稼働させておく必要があります。 f:id:aimstogeek:20220330141918p:plain

メリット

  • Webサーバーでレンダリング処理を行うため、コンテンツ表示が速い

デメリット

  • リクエスト毎にページを生成するため、Webサーバーの負荷が増加する

SSG(Static Site Generator)

ビルド時にHTMLファイルが生成され、リクエスト時に生成済みのHTMLを提供します。 HTMLとJSファイルを置けるホスティングサーバーがあればページ配信が可能。 静的な HTMLファイルを返すだけなのでパフォーマンスが非常に高い。 f:id:aimstogeek:20220330141927p:plain

メリット

  • 静的なHTMLファイルを返すだけなので、コンテンツ表示が非常に速い

デメリット

  • ページ数が多いとビルド時間が長くなる
  • データ更新毎に再ビルドが必要なため、更新頻度が高いページには不向き

つかってみる

Next.jsのインストール方法や、簡単な使い方について

インストール

  • Node.jsがインストール済みであること

npxコマンドを使用して、最新のNext.jsをインストールする。
TypeScriptでプロジェクトを作成する場合、--typescriptオプションをつける

npx create-next-app@latest --typescript

? What is your project named? › my-app #プロジェクト名を入力する

最新のNext.jsがインストールされます(執筆時のVersionは12.1)
インストールがすべて完了したら、作成されたフォルダに移動しWebサーバーを起動する。

cd my-app
npm run dev

http://localhost:3000をブラウザで開くと、Welcomeページが表示されます。

ルーティング

/pagesにファイルとフォルダを設置することでルートを定義できます。
例)/pages/test/index.tsxを配置した場合http://localhost:3000/testでアクセスできるようになります。

ダイナミックルーティング

/pages/test/[id].tsxのようなファイルを設置した場合に下記のようなアクセスができるようになります。

  • /test/1
  • /test/2
  • /test/3 ...

SSR/SSGで使用するAPI

getServerSideProps(SSR

ページアクセス時に呼び出され、戻り値のpropsの値がページコンポーネントに渡される

export const getServerSideProps: GetServerSideProps = async context => {

  // ページコンポーネントに渡すpropsを作成する
  const props = {
      ...
  };

  return { props };
};

getStaticProps(SSG)

ビルド時に呼び出され、戻り値のpropsの値がページコンポーネントに渡される

export const getStaticProps: GetStaticProps = async context => {

  // ページコンポーネントに渡すpropsを作成する
  const props = {
      ...
  };

  return { props };
};

getStaticPaths(SSG)

ダイナミックルーティング使用時に、生成するページのパス(ID情報など)を指定する

export const getStaticPaths: GetStaticPaths = async () => {

  return {
    paths: [
      // /test/1 〜 /test/3のページを生成する場合
      { params: { id: '1' } },
      { params: { id: '2' } },
      { params: { id: '3' } } 
    ],
    fallback: false  // 上記以外は404
  };
};

おわりに

コンテンツに合わせてレンダリング方法を最適化できることで、
ページ表示速度の向上 → ユーザー体験の向上 → SEOの向上
につながるのではないかと思います。

インフラやネットワークの知識がない方でも手軽に環境を作れるので、これからフロントエンドの勉強をしようと思っている方などにもおすすめです。

他にも便利な機能がたくさんあるので、興味のある方は公式ドキュメントを参照してみてください。

nextjs-ja-translation-docs.vercel.app

最後までお読みいただきありがとうございました。



\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp

若手デザイナーの方達に意識してほしい3つのこと

こんにちは。デザイナーのタニモです。
三寒四温の日々が続く中、皆さんはいかがお過ごしでしょうか。 在宅勤務にもすっかり慣れてしまった私は、昼休みには必ず外に出かけて 一人ランチをしたり、日用品の買い物をしたりして、この働き方を満喫するようになりました。 街では各所で桜を見かけるようになり、いよいよ春が来るなあという感じですね。 入学や就職など、新生活に向けて準備を進めている人も多いのではないでしょうか。

今回は、この春からデザイナーとして社会人デビューする方々、 デザイナーとしてまだ経験の浅い方々に向けて、私が普段デザイナーとして意識していること、 ぜひ取り組んでほしいと思うことについて少しご紹介したいと思います。

目を肥やす

シンプルですが、私がデザイナーとして最も取り組んでほしいと思うことです。
例えば、あなたがある作品に対して品質チェックをした時、 その作品の完成度が低ければ、足りていない要素を発見してブラッシュアップすることは 比較的容易だと思います。では、既にあなたが良い!最高だ!と思っている作品に対して「もっと品質を上げられないか」と クライアントから頼まれたらどうでしょう?‥ちょっと悩んでしまうかもしれませんね。

ここで悩んでしまうのは、その作品の品質が、あなたが考える「最高の品質」の基準に 既に達していることで、それ以上のゴールイメージがすぐには湧かないからだと思います。 (もちろん、他の要因もあるかもしれませんがw)
ここでポイントなのは、あなたの「最高の品質」の基準がどこにあるのかということ。 そして解決策は至ってシンプル。その基準を、その作品よりも高くしておけばよいのです。

‥少し強引な話ですかねw ここで私が伝えたいのは、とにかく目を肥やしてほしいということです。 目が肥えていればいるほど、瞬時に足りない要素やブラッシュアップの要素が見えてくるようになります。
日々、他者の素晴らしい作品に多く触れたり、常にアンテナを張って市場のトレンドを追う。 良い作品に対しては、何の要素が自分の心を動かしているのかをよく観察し、分析する。 そして自分でもトライして身につけていくことで、それを「普通」にしていく。
そんなことを意識的に取り組んでいき、自分が「素晴らしい」「最高だ」と思える基準を、人並みの状態からプロとして 極限まで高めていけると良いです。品質を見極める力が備われば、自然と自分自身のゴールイメージも高いレベルのものになり、 アウトプットの品質もぐっと上がってくるはずです。

プロジェクトメンバーやクライアントは、担当するデザイナーのアウトプットに期待します。 その期待に応える‥に留まらずに超えるつもりで、まずは誰もが唸る最高の品質を思い描けるようにしておきましょう!

ラスボス意識を持つ

ラスボス意識を持つ。つまり、自分が作った制作物に対しては最高責任者として 品質の管理を徹底するということです。新卒の方などは特に、学生の頃の作品作りや趣味で作品を制作する範囲では、 なかなかここまで高い意識を持つことは少なかったかもしれませんね。

プロジェクトメンバーの中のデザイナーは、ビジュアルやデザインに関する 知識・スキルを最も備えているべき存在であり、他のメンバーもそこに期待します。 それだけ専門職としての発言力があるわけです。デザインに関しては、デザイナーがOKを出せばそれがそのまま プロジェクトの品質・成果物になります。(実際は上位者のチェックなどもありますが‥) それが素晴らしく評価されるものであれば良いのですが、ユーザーに与える印象が悪かったり、何か問題が起きた場合なども、 そのままサービスや会社の評判・イメージにつながっていきます。
組織の一員としてプロジェクトに参画し、そこで制作したものは全て会社の看板を背負って世に放たれる。 その意識と責任感をしっかりと持って仕事に取り組んでいきましょう!

自分に満足はしない

これまで何人もの偉人達が一度は口にしたかもしれない言葉で、もはや使い古された言葉かもしれませんね、、w これはもちろんデザイナーにも言えることです。
自分が作った制作物や成果に対して、やりがいや達成感はどんどん感じてほしいです。 それはモチベーションや成長につながっていきます。
ただ、自分が作ったものに満足はしないでほしいです。自分に満足した時点で自分の成長はとまってしまいます。
今回プロジェクトで求められた品質は達成した。‥けれど、もっとスキルがあれば、もっと時間があれば 更に品質を上げられた‥。次はもっと良いものを作ってやるぞ!
このハングリー精神をいつも持っていてほしいです。この感覚が続く限り、あなたは成長し続けることができると思います!


以上の3点が、私が若手デザイナーの方々に意識して取り組んでみてほしいことです。 簡単なまとめ方ではありますが、是非、業務を通じて実践してみて下さい!

最後までお読み頂きありがとうございました。 イラストやデザインの力で私たちと一緒にクイックの事業発展・拡大に貢献してくれる方、 いつでもお待ちしております!


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp

個人の勉強時間を業務時間として用意する取り組みを始めました

こんにちは、ソフトウェアエンジニアのiwateaです。

みなさん勉強はしてますか?

エンジニアは会社でもプライベートでもずっとプログラムを書いているイメージがあるかもしれませんがそんなことはありません。
かくいう私もエルデンリングという沼にハマってしまい、中々そういった時間は取れておりません。。

そんな多忙な現代社会でも世の流れにおいていかれないよう、業務時間を使ってスキルアップのための勉強時間を確保できる制度を最近エンジニアチームで導入したのでご紹介したいと思います。

なぜやり始めたのか?

エンジニアリングのスキルは多岐に渡る&日々更新されているため、強いエンジニア組織を作り、維持するためには個々のメンバーが継続的にスキルをアップデートしていく必要があります。

ただ、プライベートの時間を使うとなると、家族との時間や趣味の時間などで時間が取れないことも多いため、業務時間として確保することにしました。

どんな運用か?

手探りというのもあり、まずは以下のルールで運用してみることにしました。

  • 月最大16時間まで
  • 業務に直接関係ない内容でもOK
  • スキルアップが目的なのでアウトプットにはこだわらない

メンバーにはそれぞれメンターがついているので、相談もしやすい状態にしています。

実際にやったことの一例

  • まだ触ったことのない新しい技術を使ってみる
  • 過去に研修の一環で作ったシステムを改良してみる
  • 普段アプリケーション側を担当している人がAWSでインフラ構築をする
  • 普段インフラ側を担当している人がアプリケーション構築をする


AWSは検証専用アカウントを用意して予算も確保しているので、強いスペックでなければある程度自由に使える状態にしています。
プライベートだと料金が気になって敬遠していた人でも、これを機会に触ってみようというモチベーションになっている人もいます。

実際取り組んでみて

よかった点

  • 新しい技術の知識を得る時間に使える
  • 業務だと携わる機会の少ない0からシステム構築をする機会になる
  • 過去に作って以来、中々触る機会のなかったシステムを改善する機会になる

課題点

  • PJが忙しいと時間確保が難しい


課題点については事前にある程度予想はできていましたが、実際にやってみると想像以上に多くのメンバーの時間確保が難しい状態でした。

この取り組みに時間を使ったがために残業に繋がってしまうのは望むところではないので、自然と時間が確保ができるようにエンジニアチームとして改善を進めているところです。

最後に

始めたばかりの制度で課題も多くありますが、改善を繰り返しながら軌道に乗せていければと思っています。

組織を強くするためにはまだまだ多くの課題がありますが、仲間たちと協力して一つ一つ解決に向けて奮闘中な日々です。
そんな組織作りが大好きな仲間を絶賛募集中ですので、我こそはという方は↓↓からご応募をよろしくお願いします!


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp

UIは小さく変えて繰り返す

UIは小さく変えて繰り返す

こんにちは。リードデザイナーの佐藤 宜也(ヨシナリ)です。
クイックの業務では転職Webサービスのデザインをしています。

みなさんはWebサービスのデザインリニューアルって、どんなタイミングでやっていますか?
デザインリニューアルはとっても楽しいけど、正直、なかなか大変なことだと思います。
複数のページが存在するのでその影響範囲を考えなくてはいけないし、ユーザーが慣れ親しんでいるデザインを大きく変えたら変えたでユーザーがついてきてくれないというリスクも伴うと思います。

リニューアルといっても規模は様々で、例えば、ユーザー体験を見直した根底の情報設計からのリニューアルは、慎重に時間をかけて計画していく必要があるので、気軽に手を出すのは難しいと思います。

それならせめて、UIなどユーザーが目に触れる点のデザインだけでもスピード感を持って刷新していきたい。
UIの小さなリニューアル。つまりUIアップデートはサービスデザインにおいて小さく早く変えていけるほうが、より良いユーザー体験に繋がるんじゃないかなーと。
今回はそんなことを書いていきたいなと思います。

なぜ、やった方いいか?

トレンドの変化が早い昨今、手付かずのままではアッという間にデザインの鮮度は落ちてしまいます。

ユーザーの目に触れるUIが古い印象になってしまうのは、Webサービスとしては致命的です。
ここのサービスの情報は古いのかな?
サービスの運営は止まってしまっているのかな?
このような印象をユーザーが感じてしまう可能性も高いと思われます。
せっかく良いコンテンツをつくっていても、そういう印象を持たれてしまうのは悲しいですよね(TT)

だからこそ、コンスタントなUIのアップデートは大事です。
運用しているサービスだからこそ、デザインを止めるわけにはいけません。
デザインを止めるな!(ネタが古いですね><スイマセン。言いたいだけですmm)

機が熟すのを待つことは大事ですが、待っているだけでは熟していることを見逃してしまうこともあります。
デザインをするという行為を役割として任されているデザイナーだからこそ、
アップデートできる「機」を見逃さず、刷新していくことを主体的に実行していく。
そんなデザイナーを僕は目指しています。

スマートフォンの中の体験を意識する

Webサイトとしての今の主戦場はスマートフォンです。
スマートフォンOSのUIとWebサイトのUIとの親和性が弱いと、ユーザー体験として好ましくない違和感が出てしまうかなと思います。
PCOSのUIももちろん大事ですが、スマートフォンの方が画面密度が高いことからその影響はより大きいと考えます。)

スマートフォンのたくさんのアプリの中にブラウザアプリがあり、そのブラウザの中に僕らのWebサイトが存在します。
なので、スマートフォン自体のOSやブラウザのUIを意識して、WebサイトのUIを考えることはとても大事なことだと考えています。

スキューモーフィズムからフラットデザインへの変遷がIT全般のデザインの大きなマイルストーンだと思いますが、それくらいOSのデザインの影響は大きいです。
OSのデザインとWebサイトのデザインとの乖離が大きければ大きいほど、「今」のデザインから離れちゃっている可能性は大きいと思います。
その違和感を埋めるためにも、定期的なアップデートは大事だと思います。

UIは日々の業務の中で小さく変える

OSのUIってアップデートのたびにマイナーチェンジを繰り返しています。例えば、角丸のR半径を微妙に変えていたりとか。
それと同じで、サイトのUIも少しずつマイナーチェンジを繰り返してくことは必然だと考えます。ユーザーが気づかないような変化の尺度で。

それを繰り返していって1年くらいたって振り返ってみると、大きく変わってる!
こういう感じにできると、トレンドに沿いつつも自然なサービスの成長を実現できるんじゃないかなーと思います。

実行するタイミングは、日々の業務の中にあると思っています。
僕らの主業務は、サイトをグロースするための施策デザインです。
その中で、特にサイト自体の大きな機能追加施策のタイミングに合わせることが多いです。

そのタイミングで新たなUIが必要になると、それに影響される既存UIの調整も必要になることが多いです。
その調整と合わせてアップデートをしていくことで、施策自体のスピード感を遅くせずにサイトのUIもすこーしだけ良くできます。
そして、それを施策のたびに繰り返していくことで、少しの変化が大きな変化につながっていきます。
もちろん、変えてはいけない点や影響範囲に対するコスト感などは、メンバー同士で議論して慎重に決めていっています。

デザインのリニューアルは、小さく変えるべきものと大きく変えるべきものを切り分けて進めていけると良いなと思います。
その中で、小さく変えるべきものは日々アップデートを繰り返すことで、サービスの大きな成長につなげていければと思います。

余談ですが、最近、メンバーとも話すのですが、この考えってご飯屋さんの話に似てるなーと。
特に名店と言われるご飯屋さんの話で「客が気づかないレベルで、実は季節や時代に合わせて味を少しずつ変えている」という話をよく聞きませんか?
ビールの広告コピーでもよく見ますよね!「○○ビールがさらに美味しくなった!!」みたいな。
UIもまさにその感覚が大事かなと。

実現するための制作体制

最後にもう少しだけ。

これらを実現するためにもUIのコンポーネント化は必須です。共通パーツとして全ページ一気に変更を反映できますからね。
効率化して時間を短縮することで変更コストを抑えられるからこそ、コンスタントにアップデートを実現できることなので、サイト構造が本当に大切。
そんな構造を実現してくれていてるエンジニアのみんなには、いつも感謝感激です。

違和感が出ない変更の尺度の認識合わせやその定義。それを加味したサイト全体の設計。
そしてそれをチームで維持していくためのデザインシステムはマスト。

こういった制作環境をみんなで着実に整えてきてきたからこそ、アップデートのしやすさだけではなく、より柔軟に堅牢にサービスデザインを運用できる制作体制になってきていると実感しています。
目指している目的はまだまだ先ですが、そこに辿り着くために、メンバーみんなでもっともっと良くしていきます。

一緒にデザインしませんか

デザインのリニューアルに対して、みなさんはどんな対応をしているのでしょうか。
この考えは、ひとつの考え方にすぎません。
もっともっと良くして、最善を目指したいです!
こんなやり方でやってるよー!とかあれば、是非とも教えてください。

一緒に「今」に向き合い「未来」をデザインしていきませんか\(^o^)/

読んでいただきありがとうございました。


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp

Vue.jsの属性継承でハマってHTMLタグのidが重複しちゃった話

こんにちは、システムエンジニアのちーかまです!
エンジニア歴=クイック在籍歴(2年4ヶ月)ということもありビビってブログのネタに技術系を選ばなかった私ですが、 今回は業務中にハマったことをお話できればと思います。

(ちなみに入りたてホヤホヤだった頃の記事はこちら!) aimstogeek.hatenablog.com

問題となった事象

それはとある入力フォームの動作確認をしていたときのことでした。
期待する動きは
「idを元にinputタグを取得し、入力フォームが画面上部に表示されるようスクロールしてフォーカスを当てる」
だったのですが、スクロールするもののフォーカスが当たらない...

デベロッパーツールで確認したところ、なんと目当てのinputタグ以外にdivタグにも同じidが付与されていることが発覚しました。

<div class="font-set-tooltip-wrapper" id="input-0">
  <input type="text" class="comma-num" maxlength="12" id="input-0">
</div>

コード

該当箇所のコードはこんな感じです。

Form.vue

<InputKingaku :id="`input-${index}`"/>

InputKingaku.vue

<template>
  <div class="font-set-tooltip-wrapper">
    <InputCommaNum v-model="num" v-bind="$attrs" maxlength="12" />
  </div>
</template>
<script>
import InputCommaNum from '../common/InputCommaNum.vue'

InputCommaNum.vue

<template>
  <input class="comma-num" type="text"/>
</template>

原因

タイトルにも採用しているためなんとなく察している方もいるかもしれませんが、原因はVue.jsの属性継承にありました。
Vue.jsで属性の継承をする方法は2つあります。

  1. $attrsを渡してあげる
  2. inheritAttrsをtrueに設定する(デフォルトでtrueに設定)

v3.ja.vuejs.org

これを踏まえて該当のコードの属性継承を整理すると、下記の通りになっていることがわかります。
f:id:aimstogeek:20220304163732j:plain

  • InputKingaku.vueでinheritAttrsがデフォルトのtrueに設定
    →InputKingaku.vueのルート要素であるdivタグに属性が継承される

  • InputKingaku.vueでInputCommaNum.vueに$attrsを渡す
    →InputCommaNum.vueのinputタグに属性が継承される

でdivタグにもinputタグにも同じidが振られていたのです...

ということでdivタグに属性継承されないよう、InputKingaku.vueのinheritAttrsをfalseに設定して無事問題は解決しました。

修正後のInputKingaku.vue

<template>
  <div class="font-set-tooltip-wrapper">
    <InputCommaNum v-model="num" v-bind="$attrs" maxlength="12" />
  </div>
</template>
<script>
import InputCommaNum from '../common/InputCommaNum.vue'
export default {
  inheritAttrs: false,
}

最後に

コンポーネントの構成によっては、$attrsとinheritAttrsを併用するかつ継承する属性の中にidがあるとid重複もできてしまう、というのを身を持って学びました。
今後id重複のチェックを強化しようと思います。

拙い文章でしたが、最後までお読みいただきありがとうございました!



\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! // 919.jp

【看護師イラスト集】制作者目線で紹介してみる

こんにちは、イラストレーターのネモトマです。

会社では日々色々なイラスト制作を行っているのですが
その中でも手掛けることが多い「看護師イラスト集」について
ちょっぴりご紹介も兼ねてお話したいと思います。


「看護師イラスト集」とは

www.kango-roo.com

看護師🎨イラスト集は、看護師を中心とした、医療系のイラストサイトです。 公開されているイラストは、どなたでも無料・会員登録不要で、ご自由にダウンロードできます。

現在、約2100点のイラスト公開中の 無料イラストサイトですが
リリース当初は約100点程度しか掲載されていませんでした。
それが数年でここまで大きくなるなんて、大変感慨深い・・・。

そんな沢山の医療系イラストを取り扱う本サイトで
イラスト制作する上で気を配っていることがいくつかありますが
特に下記を意識して制作しています。

  • 医療的に問題ないか

  • 汎用性が高いものか


とくに「医療的に問題がないか」は、当サイトでかなり意識していて
医療監修者の方に見ていただくなどチェックに気を配っています。
関係者の皆さんにも違和感なくご利用いただけて、
役に立つことが第一の目的だからです。

看護師さんが使いやすい、ほしいと思うイラストをリサーチしながら
かゆいところに手が届くサイトを目指して
関係者各位、誠心誠意丹精込めて作っております。

あとは個性が強すぎると使いづらいシーンも出てくるので、
絵柄はまるくて優しい色合いを選び
どこでも使える「汎用性の高さ」も意識しています。

デザインを考えたときは、
どんな場所にイラストがあっても優しい印象が残るように
と思いを込めて設計しました。

最近は出先だったりSNSだったりと、
少しずつイラストが各所で見受けられる機会が増え
内心とても嬉しい気持ちになっています。

そんな看護師イラスト集、実用性を意識した内容を意識して制作している一方で
こんな尖ったイラストも掲載しているのをご存知でしょうか。


f:id:aimstogeek:20220225180409p:plain www.kango-roo.com

「えっ、どういうこと!?」


と思われるかと思いますが、
こういった「ユニーク系イラスト」もこっそり掲載しております。
制作陣はかなり大真面目に時間をかけて制作していまして
くすっと笑えたりあるある!と思えるイラストも多数ございますので
お暇なときにでもぜひご覧になってください。

www.kango-roo.com

www.kango-roo.com

www.kango-roo.com


最後に

制作陣側が「看護師イラスト集」について語るのは
はじめての試みでしたが、いかがでしたでしょうか。

少しでもご興味を持っていただけたようでしたら
頑張って作ってたけど没になった「NGイラストまとめ」的なブログを書くのもいいかなと思ったりました。
いつかいつか・・・。

それではここまで読んでくださり誠にありがとうございました!


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! // 919.jp