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

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

Laravel+Sail+Vite+React(tsx)の環境を用意する

ソフトウェアエンジニアの王子です。

オリンピックのカーリングを見すぎて、投げる前にどこを狙うかがわかるようになってきました。

コーナーガードは攻撃的な戦術です。

さて、前回の私の記事はこちらです。 aimstogeek.hatenablog.com

出来上がるプロダクトや記法の問題であればReact/Vueはどちらでも良いと思っています。

ですが、Vue3に対応したUIフレームワークや周辺ライブラリの充実度合いの状況などを考えるとあと1〜2年はReactの方が有用でしょうか。

そこで今回は前回のLaravel+Sail+Vite環境にReactを入れてみます。

dockerコンテナの準備

  • Windows
    • Docker for Desktopをインストール
    • WSL2を有効にして、ストアからubuntuを導入
    • ¥¥wsl$以下のubuntuのフォルダに適当な新規フォルダを作成
  • Mac
    • Docker for macをインストール
    • 適当な新規フォルダを作成
# curl -s https://laravel.build/react_test_blog | bash
# cd react_test_blog
# alias sail='[ -f sail ] && bash sail || bash vendor/bin/sail'
# sail up -d

http://localhostへのアクセスにより初期画面が表示されます。

f:id:aimstogeek:20210819132127p:plain
laravel初期画面

Vite環境の用意

前回同様Laravel-Viteというパッケージを利用します。 バージョンが上がり初期化方法がアップデートされています。

laravel-vite.innocenzi.dev

  • 導入手順
# sail npx @preset/cli apply --debug laravel:vite --no-ssh
  • package.jsonの修正
"scripts": {
    "dev": "vite --host",
    "build": "vite build",
},
  • Laravel用のconfigの用意
# sail php artisan vendor:publish --tag=vite-config
  • react_test_blog/config/vite.phpの修正
'entrypoints' => [
  'ssr' => 'resources/scripts/ssr.ts',
    'paths' => [
      'resources/scripts/Index.tsx',
    ],
    'ignore' => '/\\.(d\\.ts|json)$/',
],
dev_server.ping_before_using_manifest => false (デフォルトはtrue)

※こちらを変更しないと、HMRのための変更を検知してくれない

  • docker-compose.ymlの修正
ports:
    - '${APP_PORT:-80}:80'
    - '3000:3000'
  • reactパッケージの導入
# sail npm install --save-dev react react-dom @types/react @types/react-dom @vitejs/plugin-react-refresh
  • vite.config.tsの修正
import { defineConfig } from 'vite'
import laravel from 'vite-plugin-laravel'
import reactRefresh from '@vitejs/plugin-react-refresh';

export default defineConfig({
    plugins: [
        laravel(),
        reactRefresh()
    ],
})
  • react_test_blog/resources/views/welcome.blade.phpの修正
<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Laravel</title>
    @react
    @client
    @tag('Index')
</head>
<div id="index"></div>
</body>
</html>
  • react_test_blog/resources/scripts/Index.tsxの作成
import * as React from 'react';
import * as ReactDom from 'react-dom';

const Index = () => {
  return (
    <div>
      react test blog.
    </div>
  );
}
ReactDom.render(<Index />, document.getElementById('index'));
  • 一度再起動
# sail down
# sail up -d
# sail php artisan view:clear  #キャッシュが残ってると@viteのディレクティブが動作しない
  • ビルド
# sail npm run dev

動作確認

上記の手順を実施後、localhostにアクセスすると「react test blog」とだけ書かれたシンプルなページが表示されます。

f:id:aimstogeek:20220214142200p:plain
ビルド結果

ViteのHMRが正常に動作するかを確認するために Index.tsxの「react test blog」を「Hello world」などに書き換えてみてください。

f:id:aimstogeek:20220214142224p:plain
ビルド結果にHMR適用

ブラウザのリロードを行わずにコンポーネントの再描画が行われていれば環境の構築は成功です。

HMRを行わずに静的ビルドを確認する場合は

# sail npm run build

を実行した後にreact_test_blog/config/vite.php

  • dev_server.enabledをfalse
  • ping_before_using_manifestをtrue

のどちらかの対応で、localhostで確認できます。 ちょっとデプロイや作業がしづらいので、どう使うのが正しいのかは追い追い調査します。

最後に

最近はViteの速度と手軽さに満足し、環境構築で少し苦労しようともwebpackには決して戻るものかと推進活動に力を入れています。

Vite未経験の方は是非導入してみてください。

今回はここまで。

読んで頂き、ありがとうございました!


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

Three.jsでWebGL入門

こんにちは、システムエンジニアのponです。
ここ数日「Pokémon LEGENDS アルセウス」にハマっているのですが、3D酔いしてしまって1日1時間しか遊べないのが悲しいです。

車酔いする人は車運転すると酔わないよ!と言いますし、
自分で3Dコンテンツ作れば3D酔いが軽減するのでは?ということで今日は遅ればせながらThree.jsで立体物を動かしてみようと思います!

Three.jsとは?

three.jsは、ウェブブラウザ上でリアルタイムレンダリングによる3次元コンピュータグラフィックスを描画する、クロスブラウザ対応の軽量なJavaScriptライブラリおよびAPIである。 Three.js - Wikipedia

web上で手軽に3Dコンテンツを作成できるライブラリです。
昨年話題になった「Yamauchi No.10 Family Office」のコーポレートサイトでもThree.jsが使用されています。 y-n10.com

公式にドキュメントやサンプルコードがたくさんあるので面白そうなものを写経するだけでもかなり勉強になります。 threejs.org

今回立体にするもの

看護roo!ロゴの

f:id:aimstogeek:20220210101704p:plain:w300
2つ目の「o」を立体にします。
f:id:aimstogeek:20220210101421p:plain:w300
(かわいい・・・!)

下準備

SVGを用意します。
Adobe XDでSVGを作るとなぜか取り込めないのと、
取り込むとなぜか天地が逆転するので上下反転したシェイプをPhotoshopで作成してSVGを取得します。

f:id:aimstogeek:20220210103548p:plain
ぺジェ線引くのたのしい

discourse.threejs.org

表示してみる

See the Pen three.js test by QUICK Web Service Development (@quick-engineers) on CodePen.

 

Three.jsはシーン(空間)を作成してとメッシュ(物体)とそれを映すカメラを空間に配置してレンダリングするとcanvas上に表示されます。
文章にしてみるとなかなか難しいですがこちらのサイトが図解で説明されていて大変分かりやすかったです。 ics.media

メッシュはマテリアルとジオメトリから構成されるので、今回はSVGLoaderを使用してSVGのパスからジオメトリのシェイプとマテリアルに設定する色を取得しています。

const loader = new THREE.SVGLoader();
const svgMarkup = document.querySelector('#logo').outerHTML;
const svgData = loader.parse(svgMarkup);

const svgGroup = new THREE.Group();
svgData.paths.forEach((path, i) => {
  // パスからシェイプ作成
  const shapes = path.toShapes(true);

  shapes.forEach((shape, j) => {
    const material = new THREE.MeshBasicMaterial({
      // pathに設定している色を取得して設定
      color: path.color,
      side: THREE.DoubleSide,
          depthWrite: false
    });
    const geometry = new THREE.ExtrudeGeometry(shape, {
      // 奥行き30で押し出しします
      depth: 30,
      bevelEnabled: false
    });

    const mesh = new THREE.Mesh(geometry, material);

    svgGroup.add(mesh);
  });
});

以下のサイトがとても分かりやすかったので参考にしました。 muffinman.io  

出力はされたもののこれだと立体かどうかよく分からないですね・・・

回してみる

See the Pen three.js SVGloader test by QUICK Web Service Development (@quick-engineers) on CodePen.

 

動きがあると厚みが見えるので立体感が出ますね!
回すのは意外と簡単で、レンダリングの部分を以下コードを変更するだけで回り出します。

tick();

function tick() {
  // フレームごとにy軸回転する
  svgGroup.rotation.y += 0.01;
  renderer.render(scene, camera);
  requestAnimationFrame(tick);
}

マウスに合わせて動かしてみる

See the Pen Untitled by QUICK Web Service Development (@quick-engineers) on CodePen.

 

マウスに合わせて動かす挙動は公式のこちらを参考にしました。 threejs.org

ついでにマテリアルをMeshToonMaterialに変更しつつ、メッシュを追加して前方にステンドグラスみたいに光が落ちてる感じにしました。
(でもライトが正面から当たっている矛盾)

まとめ

今回は簡単ですが、three.jsを使って立体表現に挑戦してみました。
普段の実務ですとこういった動きのある実装をすることはあまり無いのですが
LPや診断ページなど読み物コンテンツに導入してみるのも華やかで良いなと思いました。
表現の幅を広げて親しみのあるサイトを作成していければと思います ٩( ᐛ )( ᐖ )۶


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

919.jp

リモートワーク期間に転職して助かったこと&ちょっと困ったので改善したこと

こんにちは! クイックに転職して早1年半が経ちました。ソフトウェアエンジニアのたろーです!

私がクイックに入社した2020年の6月は第1回目の緊急事態宣言直後。
我らがWeb室はリモートワークでの勤務体制となっていました。

もともと前職で請負開発や常駐エンジニアとして多くの企業様の文化風土に触れ、様々な開発体制の中でお仕事させていただく機会は多かったので環境の変化には慣れているつもりでしたが、
それでも初めての転職でいきなりリモートワーク、正直色々と不安でした。

しかし!Web室やプロジェクトで行っている取り組みや制度に助けられ、そんな不安はすぐに払拭されました。

ここでリモートワーク真っ盛りな中入社し、「あれは助かったぜ!」と感じた制度や取り組みを紹介していきたいと思います。

逆に自分が入社したときに「困ったな〜」と思い、後にチームで改善したことも併せて紹介したいと思います!

リモートワーク環境で新たにメンバーを受け入れる際の参考にしていただければ幸いです!

1. メンター制度

まずはメンター制度です。
メンター制度については下記記事で紹介していますので是非ご一読ください! aimstogeek.hatenablog.com

元々リモートワークが始まる前から導入されていた制度ですが、リモートワーク期間に入社した自分にとっても本当に心強い制度でした。

プロジェクトで発生した疑問や課題については、プロジェクトに常設されているチャットやオンラインミーティングルームで相談し解決することができていたのですが、

「他プロジェクトのメンバーと話してみたいけど、会社で顔を合わせる機会が少ないからどのようなきっかけで交流すればいいかわからない・・・」
「会社や自治体に行う届け出とか事務処理をいつどのようなタイミングで行うかわからないし、誰に質問すればいいかもわからない・・・」
「とりあえず何か話をきいてほしい!話しながら思考整理をしたり、行動のきっかけになるような話をするような時間がほしい・・・」

といったプロジェクトの枠を超えていたり、特定のカテゴリに収まらないような不安や疑問を相談できる場があるのはとても心強かったです!

出社の際にはちょっとした雑談がてらそのような話をする機会が取りやすいですが、リモートワーク期間中はそのような機会が少なくなりがちです。
また、入社して早々に自分発信での相談を行うことにハードルを高く感じる方も多いのではないでしょうか。

そのような時に、組織に馴染むためのコミュニケーションをとる仕組みがあると入社時の心の支えにもなりますし、環境に慣れる助けになると思います!

2. デイリーミーティングでのコミュニケーションゲーム

2つ目はデイリーミーティングでのコミュニケーションゲームです。

こちらの記事でも紹介していますが、 aimstogeek.hatenablog.com

私が所属しているプロジェクトでは毎朝、デイリーミーティングを実施しており、
全体連絡、進捗報告、課題報告とあわせてコミュニケーションがとれるようなゲームを行っています。

ゲームを行うことのメリットはざっくり括ると3つあると感じています。

  • チーム内のコミュニケーションハードルを下げる
  • メンバーの相互理解、親交が深まる
  • 朝行うことで頭のウォーミングアップになる

特に、入社してすぐにリモートワークとなった自分にとっては1つ目の
「チーム内のコミュニケーションハードルを下げる。」
というメリットが大きく響いてくれました。

ゲームが1日の業務のアイスブレイクとして機能してくれ、さらに短時間でチーム全体とコミュニケーションをとれるので、チームメンバーと仕事をする上でのコミュニケーションをとるハードルがグンッと下がりました。

「新しく参画したメンバーの緊張がとけないな〜」
「毎日のデイリーミーティングして顔合わせる場を作ってるのに、あまりコミュニケーションが活性化しないな〜」

といった悩みをもたれてる方には是非お勧めします!

3.プロジェクトポータルサイトの作成

3つめはプロジェクトポータルサイトの作成です。
こちらは自分が入社当時に少し困ったので、チームで改善したことになります!

入社してすぐは色々なドキュメントを読みあさり、業務理解を深め、ドキュメントに沿ってタスクをすすめる機会が多いと思います。
また、リモートワークの実施に伴いドキュメントの充実化を推進しているチームも多いと思います。

私が所属しているプロジェクトでも開発を行う上で必要なドキュメントがしっかりと準備されており、リモートワーク環境下でもドキュメントを読めば大抵のタスクは遂行できる状態でした(素晴らしい!)

ただ困ったことに、
どこにドキュメントがあるかわからない!
情報の格納場所が分散している!
と、情報にたどり着くまでの時間がかかってしまうという問題がありました。

この課題を解決するために
プロジェクトのポータルサイトつくって情報に到達するまでの経路を整えよう!
という施策を実施することになりました!

実際に作成されたポータルページです! f:id:aimstogeek:20220203165258p:plain

もともとチームでつかっていたプロジェクト管理ツールにwikiの機能が搭載されており、そちらをポータルwikiとして利用することも案として上がったのですが

  • プロジェクト管理ツール付随のwiki機能が、ページを階層構造にした際にURL体系が使いづらかったこと。
  • 自分たちでデザインも含めて含めて作って、とっつきやすい雰囲気のページにしたかったこと。
  • せっかくなので今までチームで使ったことのなかったGoogle Sitesをお勉強がてら使ってみたかったこと。

等々を考慮してプロジェクト管理ツール付随のwiki機能ではなく、google sitesを利用してポータルサイトを作成することになりました!

実際作成してみた結果、各情報がカテゴリーやパターン毎に整理、インデックス化されたことですぐに必要な情報へのアクセスできるようになりました!とりあえずポータルをブックマークしておけば大抵の情報にはすぐアクセスできるようになっています!

情報が集約、体系化され、経路も整備されていることで、情報を使う側のみでなく展開する側のコストも低減されますね!
いろんな格納場所(ファイルサーバやクラウドストレージやgit等)に散らばった情報をお引っ越ししながら整理していくのはかなり骨が折れる作業にはなりますが、とりあえずポータルにリンク集約して分類分けするだけであればそこまでコストもかかりません!

ドキュメント作成はしたけどうまいこと活用されてない、とお悩みの方はお勧めです!

最後に

以上、リモートワーク期間に入社してという軸でピックアップして紹介しましたが、いずれもリモートワークに限らずオンボーディングやエンゲージメントの向上、開発の効率化等、組織力を高める上で有効な取り組みだと感じました。

リモートワークということにフォーカスしすぎず、普段から組織や開発体制の課題解決に取り組み、変化に強い基盤をつくっていくことが重要だと思います!
私も自分が入社した時以上にいい組織にしていくぜ〜!という気持ちで課題解決や改善に取り組んでいきます!

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


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

919.jp

2年くらいマネージャーやったからそろそろ振り返る

マネジメントなんてできないよお!!と言いながらチームをマネジメントする立場になって(※)早2年ほど経ちました。ねこです。
※正確に言うとPO(Product Owner)という立場なのですが、マネジメント業務でぶちあたった壁の話をするのでマネージャーとして語ります。

マネジメントについていろいろ悩んだ中でも、悩みに悩んだ

  • 絶対向いてないのにどうしよう!
  • メンバーが何考えてるのかわからない!

の2本についてお届けしようと思います。
これからマネージャーに任命されてて不安だよ〜〜!!っていう人や、
最近マネージャーになったけどもうやだよ〜!!ってなってる人たちに、
こんなことで悩んでるマネージャーもいるんだな……ってほっこりしていただければ幸いです。

🐣 絶対向いてないのにどうしよう!🐣

なんで絶対向いてないと思ったかというと、他人に対してキレるかキレないかで世界の人間を2つに分けたら間違いなくキレる側の人間です。怒ります。みんなよく穏やかに生きてるなあと思います。
ねこは恥ずかしながらつい数年前まで、プロジェクトのタスクで予期せぬことをやられるとカッとなってbacklogのコメントでキレ散らかしたり、もろに態度が不機嫌になったりして、査定がしっかりアレなことになったこともありました……うう、本筋から外れて謝罪せずにはいられない。あの頃のみなさんすみません。

そんなキレる人間が上に立つの嫌すぎだろ!!と思いましたし、怒りのコメント書いたあと秒で自己嫌悪に陥りめちゃくちゃ落ち込んだりしてたので真面目に対策しました。
秒で落ち込むならやるなよって感じですが怒りという感情はそういうものなのです。合掌。

幸いなことに私の怒りは理不尽にキレ散らかすものではなく、ちゃんと理由がありましたので、自分怒ってるな〜!と思ったら10秒天井を見つめたり、一度感情のままとりあえず文章書いてから全消ししたりして気持ちを落ち着かせ、言い方が怖くならないように気をつけつつ理由を丁寧に説明する……といういわゆるアンガーマネジメントをするようになりました。本当、天井にはいつもお世話になっています。

怒りの感情ってエネルギー量としてはきっと他の感情よりも多くて、向ける方向を間違えなければなにか行動を起こすときには大いに助けになってくれるものなのではないかと思っています。
人に対して怒らず、仕組みや環境に対して怒ったり、失敗を防げなかった自分に対して怒り、「現状が許せんから私が変える」みたいな怒りをもとにしてなにか行動を起こすアンガードリブンは意外と成果が出て悪くないです。(制御が大変なのでおすすめはしません)

🐣 メンバーが何考えてるのかわからない!🐣

いやまあそう……そうなんですけど……。エスパーじゃないので……。
ただ、同じメンバーだったときはやることは違えど、ある程度動きが見えるしいろいろ話すので、何が好きでどんな考え方をする人で……みたいなことがなんとなくわかるんですけど、マネージャーとか管理する人間になると結構なんも見えなくてこわい!!です!!

マネジメント業務、メンバーと業務内容の性質が変わってきて、作業だけ真面目にしてるとメンバーと話さなくなるんですよね。そうすると何が楽しくて何が得意でどこを伸ばしたいと思っているのか、何が苦手でやりたくなくて悩みがあるのかないのか、いまなにがアツくてどんな気持ちで生きてるのか……みたいなことがなんにもわからなくなります。
どんな人かがわかると伝え方を変えることができるんですが、なにもわからないと言わなきゃいけないことをどう伝えればいいのかがわからないし、でも間違って伝わってほしくないし、とか考えてたら時間が経って余計話しにくくなるという悪循環に……。

これはもう改善のため単純に、「時間作ってメンバーとしゃべる」ようにしました。
1on1という名前の取り組み、私はめちゃくちゃ苦手意識があって逃げがちだったのですが、どう考えてもやらんとあかん……これしかない……と思ったのでとってもラフに取り組めるように、「1on1」と呼ばずに「雑談」と呼んだり、近くのドトールやオフィスのランチスペースでコーヒーを飲みながらメンバーとサシで話してます。
この記事を書いてる日のちょうど前日に会社から「1on1研修」というものが開催されて、ちょっとできる気がしてきたのでこれからもうちょっといい感じの1on1ができるように頑張りたいと思っています。

🐔 おわりに 🐔

ここまで書いて振り返ると甘ちゃんが周回遅れで大人になっただけなのでは……(´ω`)というかんじですが、

  • 自分の癖、弱み強みを知る
  • それにたいして自分に合った対策を練る
  • やってみる

の繰り返しで改善してきました。

改善の最初の一歩として、自分を知るのにはストレングスファインダーがかなり為になりました。
資質が34個に分けられ文章化されていて、自分の強み順に並べられて納得感がありおもしろかったですし、「これ苦手な人いるんだ……!!!」という他者への理解ができたことも大きかったです。(盲点として「こういうことしてませんか?やめましょう。」って書いてあること見事にやってたり……)

まだまだいろいろ至らないところも悩んでることもありますが、これからも考えることをやめず、マネージャーもリタイアせず、よきチームにしようと励みたいと思います!
それでは!!


\\一緒に悩みながらチーム作りしてくれる仲間を募集中です!! //

919.jp

クラス設計が重要だと実感した話

あけましておめでとうございます。
エンジニアのみっきーです。

昨年、既存システムをカスタマイズして、新しいシステムを作成するプロジェクトに携わりました。 その際にクラス設計で得られた効果が絶大だったので、お伝えしたいと思います。

前提

  • 似て非なるシステムだったのでカスタマイズ箇所は全体
  • 既存システムはメンテナンスの難しさが課題に上がっていた
  • メンテナンスの難しさも改善することをプロジェクトで決めた

※勝手にやってたわけじゃないよ!

対応内容

まずはこの二つ

ECサイトを例に前後比較をすると以下の図の通りです。

f:id:aimstogeek:20220107150913p:plain
ユースケース
f:id:aimstogeek:20220107152347p:plain
クラス図 前後比較

アクターが管理者とお客さんで、それぞれに商品に関する機能を提供するシステムだとします。※実際はもっと複雑だと思いますが説明のために簡略化

既存システムでは「商品」というくくりでクラスを切り分けています。
この時、税率が変わって合計金額に関する処理を変更したいとします。
修正対象を探すには「商品サービス」の中から、合計金額に関する処理を見つけ出す必要があります。
変更後のテストは「商品サービス」クラスの全てを確認する必要が出てきます。

少しの変更に対して、行わなければならない作業が多いですね。
めんどくさーと思ってしまう

商品に関する操作を増やす場合も、1クラスがさらに大きくなってしまうことがわかると思います。

一方、新規システムではアクターへ提供する機能ごとに切り分けを行なっています。
クラス図には購入処理のみを記載しましたが、他の処理も同じような切り分けをしています。

合計金額に関する処理を変更する場合、ドメインの「合計金額算出」クラスを見にいけばいいんです。
変更後のテストも「合計金額算出」クラスのみ実施すればいいのです。
もっというと税率はマジックナンバーからオブジェクトに置き換えたので、該当の数値を変えてあげるだけで修正は完了します。 かんた〜ん!

機能を追加するときは、新たに1つクラスを追加するだけです。
追加内容がわかりやすいのがイメージできますでしょうか!!

次にこの二つ

  • アプリケーションサービスとドメインサービスを切り分けた
  • データ操作をリポジトリに押し込めた

既存システムではデータのやり取りがサービスにはみ出している箇所がありました。

商品サービスを例に挙げるとこんなイメージです。

namespace App\Services;

class GoodsService
{
    public function add()
    {
        // 商品追加処理
    }

    // ... いろんな処理のメソッドが入ってる
    
    public function update(array $goods): 
    {
        if(){
            // 引数の妥当性チェックして〜
        }
        
        // 商品情報を更新するかチェックして〜
        
        $queryBuilder = new queryBuilder();
        
        // 商品情報更新して〜
        $query = $queryBuilder
            ->update()
            ->whereXXX($goods['xxx'])
            ->whereYYY($goods['YYY'])
            ->whereZZZ($goods['ZZZ']);

        // 関連テーブルも更新して〜
        
        // 更新が成功したかどうかチェックして結果を返却〜
    }
}

これではサービスが肥大化してしまって、何をしているのか読み解くのが大変です。
各サービスで同じ操作をしたい時に、同じものを書くことにもなってしまいます。
プログラム量が増えてメンテナンスしづらそうですね。

新規システムでは、データ操作を全てリポジトリに移しました。
業務に必要な知識はドメインサービスに移して、引数も商品オブジェクトを用意することで更新処理のみに集中できるようにしています。
商品更新サービスでは何が行われるのかパッと確認できちゃうんです!

namespace App\Services\Goods;

use App\Domains\Goods\UpdateService;

class UpdateService
{
    private $updateService;

    public function __construct(UpdateService $updateService)
    {
        $this->updateService = $updateService;
    }
    
    public function update(Goods $goods): bool
    {
        // 更新処理はドメインに委譲してるので呼び出すだけ
        return $this->updateService->update($goods);
    }
}

実感した効果

クラス設計がされていることによるメリットは以下のようなものがありました。

  • 不具合が起きづらくなった
  • 修正範囲の確認のためにプログラムを追う時間が減った
  • 影響範囲が1機能内に収まっているので、改修時の確認時間が減った
  • 改修時のテスト範囲を適正量に減らせた
  • エンジニアの実装スキルが上がった

要因は他にもあるのですが、クラス設計は確実に影響があったと思います。
メンテナンスがしやすくなったので、開発陣も利用する側もみんなハッピー。

大変だったこと

ここまで良かったことばかり記載しましたが、改修自体はとても大変でした。
個人的に大変だった部分は…

  • 設計書を読んだだけではクラス設計ができないので、仕様や業務知識を把握する必要があった(当たり前かもしれないけど)
  • 差分確認しつつ要件満たすように修正しつつリファクタの実施は、限られたスケジュールの中で作業量が多く、焦りを感じた
  • リファクタするための知識が0の状態からスタートしたので、レビューで鬼のようにダメ出しされた(めげない心大事)
  • 勉強の嵐
  • コンフリクトした時の絶望感

など

まとめ

クラス設計はみんなを幸せにする!

PS

経験豊富なテックリードを始め、改修にGOを出してくれたプロジェクト、調整を引き受けてくれたプランナー陣、めげずに進んだエンジニア陣、みんなで成し遂げられたプロジェクトだったなと改めて実感しています。
まだまだ課題は残っていますが、今回メンテナンスのしやすいシステムになったことで要望により答えやすくなりました。
なんでもかんでも改修すればいいわけじゃないけど、関わったプロジェクトでは少しでもメンテナンスがしやすく役に立つシステムを作っていきたいです。


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

919.jp

自分たちでオフィスをデザインする上での注意点

こんにちは。 コピーライター兼デザイナーとして働いています、ケイです。

ふだんは広告を中心としたwebまわりのクリエイティブが主戦場のわたくしですが、 趣味のDIY・リノベが高じ、われらWeb室のオフィスインテリアをデザインさせていただきました。

f:id:aimstogeek:20211222180026j:plain

f:id:aimstogeek:20211222180040j:plain

自分たちのオフィスを自分たちで考える体験は、とても楽しく有意義なものです。 ですが、思い描いたものを即座にカタチにできるかというと…そこには様々な制約がつきまといます。

予算や納期や…メンバーそれぞれが考える「働きやすいオフィス像」の食い違い。 さらに最大の障壁と言って良いのが、法律やビル側の規約といったハード面の制約です。 これがなかなかに手強いもの。

どれほど手強いかというと… 「ウッド調にしたいから木の板を壁に貼ろう」 「ブラインドの色を変えよう」 といった、一見なんの問題もないことさえ、NGになってしまうケースがあるのです。

今回は(どのくらい需要があるのか謎ですが)、そんなオフィス空間を作る上でぶつかりがちなハード面の制約について、ご紹介したいと思います。

建築基準法・消防法により素材が制限される

建築基準法って、建物の強度や外観といったビルそのものを建てるときの話じゃないの?」 …と思いがちですが、消防法の内装制限という決まりとともに、内装に使用して良い建材を定めています。 簡単に言うと、火事にそなえて燃えにくい素材を使いましょうね、ということ。

ですから、上でお話したように天然の木板をそのまま使用するのは不可。

一見、壁や床に木目を多分に取り入れているこのオフィスですが、この基準を満たすために、

  • 難燃性のビニール素材でできたフィルム

  • 塩ビタイル

  • 燃えにくく特殊加工された天然木

の3種類を使い分けています。

f:id:aimstogeek:20211222180002j:plain

ビル側にもルールがある

法律だけでなく、ビル側にも当然ルールがあります。 「そんなの当然でしょ」と思うかもしれないですが、ルールはビルによって様々で、隣のビルならOKなことが、このビルではNG…ということも少なくありません。

賃貸アパートであれば、勝手に壁を塗ったり、壁に小さい穴を空けたりできないことは想像できますが、オフィスの場合どこにNGラインがあるのか、ちょっとわかりづらいですよね。 確認すると意外と「えっ、これダメなの?」というルールがあるため、なるべく早く契約内容やオーナーの意向を確認しておくことが大切です。

参考までに、私たちがオフィスを作る上で直面した事例の一部をご紹介します。

どんなに小さな穴も壁には空けちゃダメ

壁に時計をかけている、というのはよくあるオフィスの風景です。 なので原状復帰さえすれば壁に釘を刺したりするのはOKかと思いきや…私たちの入居しているビルでは、ビル壁に釘やネジや画鋲を打つことは禁じられていました。 時計を掛けたり、本棚を固定したりする予定がある場所には、ビルの壁の上に板を貼ったり、ふかし壁を別に建てることが必要です。

f:id:aimstogeek:20211223090450j:plain
後から時計を取り付けると決まっていたので、ピンを刺せるようビル壁の上に板を貼り付けています。

ブラインドやカーテンの色にもご注意を

テナント入居者である私たちは内観ばかりに気を取られがちですが、ビルオーナーは建物の外観にも気を配っています。 意外と盲点になるのはブラインドやカーテンの色。 外から見た際の窓の見た目が変わってしまうため、オーナーによっては快く思わないこともあると言います。 私たちのオフィスでは、すべてのテナントが同じ白いブラインドを使っていたため、木目ブラインドに変更するにあたって、慎重にビル管理会社と協議を重ねました。

f:id:aimstogeek:20211223090447j:plain

天井パネルを外してスケルトン天井にするのは意外と簡単ではない

天井のパネルを外し、配管剥きだしにする。 たったそれだけで、頭上の圧迫感がなくなり、雰囲気も一変。 インダストリアルな空間には欠かせない天井のスケルトン化ですが、意外と板を外すだけ…ではありませんでした。

難燃素材でできた天井パネルを撤去するため、防災の観点から様々な調整が必要になります。 スプリンクラーの位置や数だけでなく、会議室等の個室を設ける都合上、一部の天井パネルは残さざるを得ないのですが、その場合、隙間からパネル裏に火が回らないような処置も必要になります。 また、梁に吹き付けられた耐火皮膜が剥がれ落ちることがないよう、コーティングや補強が必要になるケースも。

このため、施工の前例がないビルでは、オーナーが難色を示すケースもあります。

f:id:aimstogeek:20211222180020j:plain

ここに挙げたのはあくまで一例ですが、まさかこんな制約があろうとは…素人には思いも寄らないことの連続でした。 せっかく考えたプランを1から練り直すのは大変極まりないですから、早い段階からビル側と緊密に連携していくことが肝心です。

f:id:aimstogeek:20211222180031j:plain

さて、そんな自分たちのオフィスをも自分たちでデザインしちゃう クイックのWeb室のデザインチームに興味を持ったあなた、 まごころ込めて作ったオフィスでお待ちしています♥


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

919.jp

Chrome拡張機能を使ってGoogle Meetで「脱線してません?」とツッコミ入れられるようにしてみた

最近焼き鳥は「ねぎ間(タレ)」が一番うまいのではないかと思っているhamanokamiです!

いきなりですが、私が所属しているユニットでは毎日17時〜17時15分に夕礼を開催しており、 前半は「本日のタスク実績」「共有事項」、後半は持ち回りで「まじめな話」を発表するという時間があります。

いつも「ブログネタ何にしようか?」ともがき苦しんでるのですが、 ちょうどこのブログ記事を執筆する前週の夕礼で話されたチームメンバーの「まじめな話」が天の恵みとなりました。

どういうお話か簡潔にいうと、MTGで議題から話が脱線していると思うけど、 「脱線してません?」とか「議題変わりました?」などとつっこめないというものでした。

そこでひらめいたのです!!!

コロナウィルスが蔓延して以降Web会議が増えたので、 Web会議であればWeb技術を使ってこの問題を解決できるのではと。

そこで、このブログのタイトルであるGoogle Meetでつっこみを入れることができるChrome拡張機能をつくってみることにしました。*1

システムの仕様

  • Google Meet上でのみChrome拡張機能が動作する
  • Google拡張機能で表示するボタンを押下すると、ボタン押下したユーザーが参加しているMeetの参加者全員に画面上でメッセージが通知される*2
  • メッセージはニ○動っぽく表示される
  • ボタンを押した人は誰かわからないようにする*3

完成版デモ

上記仕様からつくったものがこちらです!

f:id:aimstogeek:20211216101936g:plain

要件どおり、ニ○動っぽくメッセージが流れてますね!

システムの全体像

今回の仕様実現にあたって、下記のようなシステムを組みました。

f:id:aimstogeek:20211216115839p:plain

使用技術

Pusherとは、WebSocketを使ってリアルタイムかつ両方向の通信機能を簡単にWebサイトやモバイルアプリに組み込むことができるサービスです。(めっちゃ便利

ソースコード

こちらで公開しています。

Chrome拡張

github.com

API

github.com

注意点

  • 「とりあえず動くものつくる」をゴールにしたため、セキュリティ面や実運用面は十分に考慮されていないです
  • 今回manifest.jsのバージョンを2にしていますが、2023年にサポートが切れて使えなくなります

実装で困った点

注意点にも書いているのですが、今回manifest.jsのバージョンを2で作成しています。

その理由がバージョンが3だと、content_security_policyの設定で外部ドメインの指定ができなくなり、それに伴いバックグラウンドで動いているJSでPusherとの通信ができなくなったためです。(ここで2時間くらいつまった

「とりあえず動くものつくる」を優先していたため、調べきれていない部分もありそうなので、引き続きmanifest.jsのバージョン3で動かすことができないかは検証してみようと思います!

まとめ

今回、Chrome拡張・Pusher・GAEとこれまで使用したことのない技術・サービスを使いましたが、 とりあえず一連の動きをつくるのに約8時間くらいでできたので、 便利な世の中になったなぁ、としみじみしました。

つくったものに関しては、そもそもチームや個人が遠慮なく直接言い合えるほうが健全なので、 ブラッシュアップして使うことはない*4ですが、 Chrome拡張機能の可能性に気付かされたので、つくったことが無駄にならずよかったです!

では良きエンジニアリングライフを!


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

919.jp

*1:最初はTwilioでビデオ会議のSDKAPIもあるし、それを使ってつくってみようかなと思ったけど、せっかく作るのであれば普段から使っているGoogle Meetでやりたいことを実証したほうが生産的だと思ったから

*2:拡張機能がインストールされていることが前提

*3:極限につっこむハードルを下げるため

*4:ネタでつくってみたので