Photoruction工事中!

Photoructionの開発ブログです!

社内イベント「photoruction Labo」始まりました!!!

はじめまして、CREチーム所属のトヨカズです!

突然ですが、皆さんは開発組織向けの取り組みを実施していますか?

「これから実施したいけど、どんなコンテンツを考えればいいかわからない…😵」となったり「企画検討段階だけど、進め方がわからない…」だったりと企業ごとに抱えている悩みはそれぞれあるかと思います。

かくゆう弊社もそのうちの1社であり、組織力向上を図るために何をすべきか模索していました。

今回は、もがいた末に見つけた弊社なりのイベントのあり方について皆さんにお伝えできればと思います💪

photoruction Laboって何??

フォトラクションでは、社内開発イベントとして「photoruction Labo」というイベントを企画してます。

目的としてはこんな感じ↓↓↓

「3人1チームで、プロダクト作りをし、各チームメンバー同士の関係性を深めつつ、新しい技術を身につけスキルアップ向上を目的とするイベント」

いわゆるハッカソンみたいな感じです🕺

ただ、この企画他と違う点としては、長期スパン!!!

1年弱の開発を想定しています。

理由としては、あくまで新しい技術を触って欲しいという思いがあり、短期的だとどうしてもキャッチアップが難しい。また、各メンバー同士の関係性を深いものとするには、何か一つ同じ目標に向かって進んでいく時間が長い方が、関係性向上に寄与するものと考えたからです。

企画に至った背景

この企画の発端は、昨年まで続いていたAdvent Calender(通称アドカレ)に代わる別のイベントはないかと模索しているところから始まっています。

12月になると始まる、IT界隈1つの行事でもあるアドカレ。12月ってどこの部署も忙しく、正直アドカレを書いてる時間がないんですよね…けど、運営としてもやるからには強制力を働かせて書いてもらう必要もあり運営・執筆者、両者にとって負担となるイベントとなっていました💦

何とかやり切ったイベントも、みんなでやりきった感がなくては、達成感はあれど充実感はありません。この経験を元に、「もっとみんなが参加したくなる、楽しい雰囲気で進められるようなイベントを開催したいよね」という事になり、発案されたのがphotoruction Laboです✨

photoruction Laboの目的って…

企画を本格的に進めていくにあたり、目的を明確にしようという事になりました。

この企画は、アドカレの運営メンバーのまま、中村CTO、CREリーダー田中、CREメンバーの豊田(トヨカズ)で、運営を行っているのですが、企画検討段階の時に、様々な議論を行いました。

その中で、以下のような課題が見えてきました。

  • フルリモという働き方の中で、テキストベースのコミュニケーションが主体となっており、チーム間でのコミュニケーション・個人同士の仲間意識の希薄化

  • 開発組織におけるチーム間での連携力

また、中村個人の想いとして、このイベントを通じて、個人のキャリアに広い選択肢を与えたいという想いもあり、この企画はグループでの技術開発イベントとして方針が決まりました。

やりたいことや課題に対する目的が見えてきたところで、次は企画の施策について考えていきます。以下は、イベントを企画する際に、実際に考えた内容です。

  • イベントの目的に対する目標設定
  • イベントのコンセプト
  • スローガン決め
  • スケジュール見積もり
  • どんなプロダクト作りをしてもらうか
  • photoruction Laboデザイン決め

こんな感じで、具体的にどういうイベントにするかを一つ一つ決めていきました!実際に決めた内容がこちら💁‍♀️

企画についての概要

イベントを開催するのに、大事な事!!!

イベント運営において大事な事は2つ。

  1. イベントを楽しむ
  2. 協力してくれる仲間を作る

1. イベントを楽しむ

まず、イベントを開催する上で、大事な事がイベントを企画してる人が楽しむという事だと思います。

何かをやろうという時に、惰性でやっても良いものは生まれませんし、真面目なイベントは、雰囲気も堅苦しくなるので、参加しても楽しくなかったりします。

運営が楽しそうに作ってる企画は、アウトプットも楽しいものになっているはずです。それが、参加者にとって楽しそうに見えないのであれば、ヒアリングして、楽しそうなものに作り変えていけば良いと思います。

ワクワクするもの、胸が躍るものであれば、自ずと参加したくなると思います。

僕らも企画を発表した時は、「人が集まるだろうか…」と考えたりしてましたが、結果的に9人参加してくれました👏

これから先も、越えねばならない山がたくさんありますが、失敗も成功も、道中楽しみながら歩んでいければと思います。

2. 協力してくれる仲間を作る

「いざ、企画を作りました!」となっても、この企画にGoを出す人がいないと何も始まりません。あくまで、組織としてイベントを実施するため、上の偉い人に許可を取る必要があるのです。

そこで、大事な事は「協力してくれる仲間を作る」事です。

幸い、弊社に関してはアドカレの段階から、CTOとCREリーダーと一緒に運営してたこともあり、その辺はすでにクリアしていましたが、実際に始めるとなると、1人からになる事が多いと思います。

この場合、ただひたすら運営に協力してくれそうな人を探すしかありません。とりあえず、企画書の草案くらいを片手に、自分の熱量を伝える事をしてると自然とそれに協力してくれる人が現れるはずです。

以上の2つが大事な事でしたが、兎にも角にもパワーをかけてイベントを進めようとする人がいないとイベントは始まりません。そして、イベントを練るのにしっかり時間を取る事をお勧めします。

この企画も実際に、動き出すまでに2~3ヶ月かかっています💦それくらいに、前準備に時間がかかりました。※本業がある中で、この企画に充てられる時間として週1のMTGだけだったので、進捗としては上記の感じでした。

🚧企画でつまずいたポイント

コンテンツイメージの共有


イベントを考える上で、必要になってくるのが、どんなコンテンツにするかということ。

目的は既に見えていたので、とりあえずチーム間での開発と今後の成長、キャリアの選択肢を増やすことを考慮して、運営で壁打ちしながらイメージの具体化を進めていきました。

特に、イベントが開催されたと仮定した時のチームの雰囲気、イベントの雰囲気などは、運営側でイメージの共有ができていないと、足りない部分が出てきたりするので、限りなく具体化することを意識していました。

参加者が参加したいと思えるコンテンツにするには


第一にコンテンツを評価するのは、参加者であるということ。参加するのも、参加者であるということ。そして、イベントに強制的に参加させるのではなく、自発的に意思決定を行い参加してもらうこれがいちばんのポイントだと思います。なので、この企画は、強制ではなく、有志での参加になっています。

またコンテンツについてお話をすると、運営が思う「面白い」と参加者が思う「面白い」の差異を可能な限り無くすことも重要になります。

もちろん全ての意見を取り入れることは難しかったりもするので、そこはバランスを見ての判断になると思います。

試行錯誤した結果、プロダクト例をいくつか提案して、その中から選んでもらう、またはそれ以外のことをやるでもOKという形で、会社でできる範囲の例を挙げることで、選択の幅を持たせ、自発的に選んでもらおうということになりました。

実際に挙げた例がこんな感じ↓↓↓

💡 Web/モバイル

💡 VR

  • VRを利用して、フォトラクションの機能を触れるプロダクト作成

※アイディアについては、条件などなし

参加者をどうやって巻き込んでいったか


イベントを開催する前から、文面じゃ伝えきれない部分を会った時に「今度、こういうイベントやるんですけど〜🥺」みたいな感じで、宣伝をしました。

「どんなイベントだったら、参加したいと思いますか?」みたいな相談ベースで、ヒアリングを行いその際、参加してくれそうな人にも声をかけていきます。(遠方に住んでる方は、DMでも聞いたり)

また企画告知によって、認知を広めることも必要だと思っていたので、以下のように社内の至る所で、発信するようにしていました。

こういう1つ1つの行動を参加する人は無意識的にも見ていたりすると思うので、企画の本気度を伝える上でも重要だと思います。

まとめ

弊社でも、まだ走り始めたばかりで今後どうなるかわかりませんが、組織を盛り上げるためにもこういう施策は必要だと思います。チームビルディングに対するアプローチを別の角度からするのもありだと思うので、ぜひ参考にしてみてください✨

建設DX展に参加してみた。

はじめまして、CREチームのトヨカズです!

今回は、12/13(水)~12/15(金)に東京ビックサイトで行われた、建設DX展についてのレポートになります!初めて展示会スタッフとして参加しましたが、色々な気づきがあったので感想を交えながら現場の雰囲気もお伝えできればと思います🫡

そもそも建設DX展とは

建設DXの専門展示会のことで、BIMやCAD、現場管理システムや工程管理システム、建設業向けのSaaSなどの製品や技術を展示するイベントです✨

関西でも開催してまして、フォトラクションはどちらも出展しました!

東京ビックサイト

※以下は、建設DXに関するサイト

https://www.japan-build.jp/tokyo/ja-jp/visit/kdx.html?gad_source=1&gclid=Cj0KCQiAyeWrBhDDARIsAGP1mWQaDpVxExNvnTI3XQwJHGC223WuU9Z5weYKIK_Hsjj9Z_pgThiixnYaAlvuEALw_wcB

建設DX展に行って、どんなことをしたのか

建設DX展で僕がやった事としては、ざっとこんな感じ↓

  • 声かけ
  • パンフレット配り
  • プロダクト(フォトラクション)の紹介

普段エンジニアをしてますが、こういった場でプロダクトの説明をすることがないため、相手に刺さるワードを短時間で探す難しさを痛感😭前職では営業をしてましたが、やはりこういうのは回数をこなす事がとても大事だなと思いました。

また、エンジニア以外にもマーケティング部や営業部、CS(カスタマーサポート)もいましたが、展示会ではチームプレイが不可欠なんだなと実感。如何に営業部隊にホットリードをお渡しできるか、そのためにどういう動線の元動いていくのか、そのために自分がどんな動きをする必要があるのかチームとしての連携がないとこの展示会は成立しないんだなとしみじみ感じました。

✨フォトラクションのここがすごかった ✨

1. 大画面液晶&実演販売士によるプレゼン

フォトラクションブース

こちらを見てもらうと分かりますが、なんと言ってもこの大画面液晶のインパクトがすごい!大画面の液晶を用意してるのは弊社以外どこもありませんでした🙄(マーケチーム凄すぎます)

そして、柱のない広々とした空間!柱がないことで、背面以外の部分からお客様の出入りが可能となっており、気軽にブースへ足を運べるような作りになっています。

フォトラクションブース

先ほどの大画面液晶は、ただデモ動画を流すだけではなく、実演販売士・藤本さんによるプレゼンにも使用されています!

実演販売士・藤本さん

通常のMC・ナレーターは原稿用紙をベースにプレゼンを展開していくところ、藤本さんはなんとご自身で原稿を作成しており(※時と場合にもよる)、フォトラクションのプロダクトについて事細かに説明してくれていました🕺「お客様へどうやったらプロダクトの良さが伝わるのか」ここに集約したプレゼンはまさに圧巻の一言です!

ストーリー展開の仕方やお客様を飽きさせない言い回し、現場に合わせた柔軟な対応はぜひ見習いたいです🥺

2. イケてるノベルティ

とにかく、フォトラクションのノベルティがイケてました!!!

エナジードリンクを配ったり、プレゼンを最後まで聞いてくださった方には、ウォータープルーフバック・DX推進秘話を配布したり、どれもお客様に好評でした!ちなみに、エナジードリンクアサイー味で、人によって好みは分かれるかもです。笑

(ウォータープルーフバックのいい感じの写真が見つからず…😭)

エナジードリンク

3. フォトラクションスタッフの熱がすごい

とにかくフォトラクションスタッフの熱量がすごい!これは、現場にいてめちゃくちゃ感じました!終わった後に、フィードバックをみんなで出し合うのですが、1日目の改善ポイントを2日目には修正し、2日目の改善ポイントを3日目には修正して、フォトラクションの魅了をいかに伝えるか、そのためにはどういう立ち回りをすればいいのか、各々が「役割を果たすためにはどうすればいいのか?」と常に考え行動していたので、この辺の意識の高さと熱量は本当にすごかったです!

それが結果にも結び付いたので、まさに職務洗練👏

建設DX展に参加してみて

僕は初めての展示会という事で、何も分からないところから始まりましたが、終わってみたらいろんな気づきを得る事ができました!

他社もいる中で、フォトラクションにどうやって目をつけてもらうのか、そのためにブースの位置どりをどうするか、どんな作りにしたらお客様が入りやすいのか、ただ大画面液晶を用意するだけでなく、それを引き立たせるプレゼンが必要だったり、プレゼンが終わった後にお客様との接点を持つ方法を考えたり、こだわり抜かれたブースだったと思います(次回も期待✨)

また、今回の建設DX展を通じて思ったことは、フォトラクションの結束力の強さです!

普段、フルリモで会う回数が少ないですが、こういった場面でチーム一丸となって目標に向かっていける推進力、お互いを支え合う力には底知れぬものを感じました…間違いなくこれはフォトラクションの良さの一つであると思うので、それを肌で感じる事ができたのは本当にラッキーな体験でした!

是非また参加したいと思います!

ご一読ありがとうございました🙇‍♀️

プレゼン中の実演販売士・藤本さん

株式会社フォトラクションでは一緒に働く仲間を募集しています

Atomic Design

エンジニアの秋山です。

プロジェクトのコンポーネントの管理にはある程度共通の認識を持ちたいので、Atomic Design を採用しています。

Atomic Design について

Atomic Design はアメリカの Web デザイナーである Brad Frost 氏が提唱したデザインシステムの設計方法です。

https://atomicdesign.bradfrost.com/

Atoms、Molecules、Organisms、Templates、Pagesという5つのレイヤーにわけて管理しましょうというものです。

具体的に実装していく上で、デザインシステム設計なので、コンポーネントの実装にそのまま当てはめることができない場面がでてきます。

今回は、Nuxt3でのプロジェクトでの管理としていく上での運用のルールを設計しました。

Templates、Pagesに関してはそれぞれ、layouts、pagesという概念が存在しますので、それ以外をコンポーネントとして管理することにします。

運用ルール

Atoms、Molecules、Organismsについては、以下のシンプルなルールを適用します。

ドメイン依存とは、プロジェクト固有や、フレームワーク固有のものを利用する場合。

コンポーネント依存というのは他のコンポーネントを利用しているかどうかというものです。

実際に運用する上で出てきた時のQ&A


条件としては必要十分かと思いますが、状況で悩む場面がでてくるので、具体例を以下に上げます。

Q.コード量が多くなったけど、他のコンポーネントに依存していないのでMoleculesですか?

Moleculesです。ただ、コード量が多いと思うのであれば、Atomsに分割できるところがないか検討ください。

Q.VuetifyのようなUIコンポーネントを利用したいのですが、利用したコンポーネントはOrganismsでしょうか?

Vue3のコンポーネントであるならMoleculesに含めても問題ありません。Vue3以外を含む場合はOrganismsにしてください。

Q.Composition APIを利用する場合はOrganismsでしょうか?

ref watch といったComposition APIはVue3の機能になるので、Molecules、Atomsでも大丈夫です。

Q.Atomsで Nuxtの useState を利用したいのです。

Nuxtというフレームワークに依存しているのでOrganismsにしてください。コード量やサイズは関係なく、Organismsです。

Q.ファイルがいっぱいになって管理がしにくいです。

適宜サブディレクトリを作成して管理してください。

Atoms、Moleculesであれば、UIフレームワークの分類が参考になるでしょう。

Organismsはプロジェクトの機能単位でつけてください。

common は使わないでください。

「ぜんぜん違うじゃん!」 『……』 「言ったよね!?シンプルなルールで必要十分ですって…なのに、この結果は何!」

最後に

実際のところ、Atomic Designは昔持て囃されましたが、運用つらい、そこまで必要としていないと代替がでないまま廃れ気味ではありますが、とっかかりとしては悪くないと思います。

他のプロジェクトで再利用しないのであれば、Molecules、Atomsまでわけなくてもと思いますが、後でデザイン変更や管理するときに便利だったりします。

やりすぎないことが大事で、手段が目的にならない程度にみんなが納得できるルールづくりが大事かなと思います。

よきよいコーディングライフを。

株式会社フォトラクションでは一緒に働く仲間を募集しています

【入社エントリ】 PMとしてフォトラクションに転職した経緯

こんにちは、フォトラクションでPdMをしている平塚です。2023年8月に入社して、4ヶ月が経ちました。

今回は僕自身が「なぜ、フォトラクションを選んだのか」という点について記事を書いていこうと思います!プロダクトマネージャーやデザイナーの方々向けになると思いますが、社内の雰囲気やカルチャーを少しでもお伝えできたらと思います!

入社した理由

1. Mission, Visionへの共感

製造、小売といった業界でPdMやUXデザイナーとしてのキャリアを積み、今後のチャレンジに関して考えていました。その中でフォトラクションの選考を受け、建設業は多様な役割の人たちが関わり、業務フローも煩雑性が高いと聞きました。そのように複雑だからこそ、やりがいのあるテーマだと思い、興味を持ちました。例えば図面作成ひとつとっても、様々な専門性を持った設計士が関わったり、営業が施主プレゼンに用いたり、現場監督や協力会社の職人さんが図面を閲覧し現場作業を行ったりします。このように多数の職種の方が関わっているため、皆んなに適したUXを作る難易度が高いです。また、書類作成も膨大な量の書類を作成し、種類も様々あります。システム化するにあたってそれらを効率よく運用できる仕組みが必要です。こういった複雑な問いを紐解いて、最大限にシンプルでしっくりくる機能を作っていくことに、今までのキャリアを活かしていけると思いましたし、チャレンジングなテーマだと思いました。 また、建設業界のDXという大きなテーマに挑戦していける点も魅力に感じました。世界で1,400兆円のマーケットと言われる、建設産業。ITの活用も実はとても盛んであるものの、そのポテンシャルを最大限発揮できている状態ではありません。業界の課題を本質的に解決できるプロダクトを創り、建設の世界を限りなくスマートにしていきたいと思いました。

2. 働く人の素直さ

粗削りでも良いので「えいや」でどんどん形にしていく。他の人にも伝えながら、ブラッシュアップしていく。物事を前に進める上でとても重要だと思っています。それには、スポンジのように色々なものを吸収できる素直さ&困難なことがあっても前向きに乗り越えられることが大切だと思います。そういった素直さや前向きさを持った方々と働き、一緒に自身も会社も成長させていきたいと考えました。

フォトラクションの選考で営業、人事担当者、開発と多くの社員とお話をした際、ありのままに事業や組織がこういう状況であることを伝えてくれました。率直かつ誠実で、気持ちよく仕事ができるのではないかと感じました。あと、各メンバーが何事にも楽しむ姿勢を持っていると思います。会話の中でアイデアが広がり「こんなことできると良いね!」とテンションが上がってくる瞬間がよくあります。スタートアップなので大変なこともありますが、一緒に楽しみながら高い壁を乗り越えていきたいと思いました。

フォトラクションで働く魅力

建設業界に関わりがない方には、弊社の事業領域はとっつきにくいのではないかと思います。私自身、建設業界は初めてであるため、毎日学ぶことばかりです。弊社には業界知識が深いドメインエクスパートが多く在籍しています。プロダクトを開発する上でユーザーの業務フローに沿ったUXを構築する必要があると思いますが、彼らの声はとても参考になります。さらに、みんなが毎回丁寧に熱量高く答えてくれますので、顧客解像度を高められ仮説の解像度を上げていけると思います。

また、弊社ではアプリケーション(SaaS)、オペレーション(BPO)、マネジメント(MSP)を各フェーズ(設計、調達、施工、維持管理、経営)で標準化し、産業全体の生産性向上を目指しております。建設業界はバリューチェーン重厚長大であり、弊社で提供できる価値も未だ一部分です。「建設の世界を限りなくスマートにする」というミッションを達成するために、まだまだやらなくてはいけないことが多いです。そういったフェーズだからこそ、目指すべきプロダクトの未来を自ら創っていけるという点も魅力的だと思います。

まとめ

いかがだったでしょうか?

少しでもPdMやデザイナーの方々にとってフォトラクションで働く魅力が伝われば嬉しいです。

フォトラクションのMissionやVisionに共感いただき、会社の成長を牽引していきたい人と是非一緒に働きたいです!

株式会社フォトラクションでは一緒に働く仲間を募集しています

エンジニアになってから、エンジニアがしなそうな事をしてみた。

はじめまして、CREチームのトヨカズです!

CREの業務にも徐々に慣れてきて、プロダクトの事も少しずつわかるようになってきた9ヶ月目。今回は、この半年程度でCRE以外の業務&プライベートでやってきた他エンジニアがしなそうなことをやったので記事にまとめてみました🕺

そこで感じたことや学んだこと、気づきなどを振り返りながらつらつら書いてこうと思いますので、気になる方はぜひ見てください!

CREの業務について気になる方はこちらをチェック↓↓↓

kojichu.photoruction.com

CREチームについて気になる方はこちらをチェック↓↓↓

※この記事では、エンジニアとしての業務以外の事とプライベートで取り組んだ事について記載しています。技術に関する内容ではないので、予めご了承ください🙇‍♂️

業務において

自分の部署/他部署の方と積極的にコミュニケーションをとる


入社してからまず初めにやった事は、自分の部署/他部署の人とコミュニケーションを取る事でした!具体的な行動としては以下2つ。

  • 社内のイベントに積極的に参加
  • プライベートで、飲みのお誘い ※一滴も飲めないけど

理由としては、

  • 自分が所属する会社の雰囲気をより深く知るため
  • 今までの会社の変遷を知ること

上記2つが建前的な理由として挙げられますが、何よりも「一緒に働く仲間がどんな人達なのかもっと知りたい」というただの好奇心です(笑)

色んな部署の方とコミュニケーションを取ることで、それぞれの視点から見た組織が浮かび上がってくるので、異なる視点を知れる楽しさがあります!他にもビジネスサイドの話を聞くことで、ユーザーさんがどんなものを求めていて、プロダクトがどんな使われ方をしてるのか知ることができたり、自分の部署にいるだけでは知り得ない情報を拾えたりするので、意外とおすすめだったり?※後はシンプルに楽しい!これに尽きます。笑

SNS運用


転職活動中、フォトラクションではどんな人が働いているのだろうと思い、SNSWantedlyなどで検索してたのですが、インタビュー記事などは見つかるものの人物のキャラクターまでを知る事はできず、実際入るまでどんな人が働いているのかはわからずでした。そんな体験から、「もっとフォトラクションの中の人を知ってもらおう」ということで、SNS運用チームを発足!

「これをやりたい!」という願望から、具体化するまでのスピード感を体験し、これが「スタートアップか」と思った記憶があります(笑)

本業と折り合いをつけながら運用してる関係もあり、meetingの時間が限られるので話す内容は事前に決めて、要点を絞ることでゴールを見失わないかつ生産性のあるmeetingを心がけています。

アドカレ運用


毎年、クリスマスまでのカウントダウンとしてアドベントカレンダーを実施してますが、2023年は自分が運営担当をしてました!

事前のタイムスケジュール組みやアポどりなどその他コミュニケーションを含む面で、始まる前に色々苦労しましたが、なんとか軌道に乗せることができてるので一安心です。(終わるまで油断はできない)

ただ学びも多くあり、タイムスケジュールしかり、工数管理しかり、何より他のチームの方々と交流できた事がいい経験でした🥺

ユーザーヒアリングのため、現地に足を運ぶ


ユーザー様の元へ足を運び、実際にフォトラクションがどのように使用されているのかを目で見る事ができ、リアルなユーザー体験を知る事ができました。また、仕様について「こういった機能があるといい」など改善要望も聞く事ができたので、その点も今後CREという立場を活かしながらユーザー様からの声を反映させられればと思います!

プライベートにおいて

他社のイベントに参加しまくる


友人から誘われたイベントだったり、自分で見つけたイベントに足を運びひたすら横のつながりを増やしていました!他社の方と絡むことで、自社以外の取り組みを知れたりするのでとても参考になります。また、企業・組織・ポジション・職種によって視野・視座・視点が全く異なるので、そういった意味でも思考やマインドがどんどん広がっていくのでとても楽しいです💡

情報に疎い僕ですが、こういった取り組みをしてると一次情報が勝手に入ってきたりするので、そういった意味でも、オススメアクションの一つです!

エンジニアコミュニティで、輪読会実施


いざ技術書を一人で読み進めようと思っても、難しい本だと中々捗らず…

でも、他の人とやれば読み進めながら議論し合い、情報を持ち寄ることで補完ができるのでは?と考え、とりあえず声をかけて輪読会がスタート😂※適当

1冊終えた感想としては、やはり一人でやるより効果が高い。自分一人だと調べきれなかったり、理解につまづく事があるので、その辺をいい感じに補完し合えるのが輪読会の良さだなと思いました!また、人に伝えるためには自分が理解しないといけなかったりするので、インプット・アウトプットの両方で、効果が期待できると思います。

調査タスクや仕様の確認などをひたすらドキュメント化


言語化したものを可視化しないと理解が追いつかないことが多々あるので、ひたすらドキュメント化を行なっていました。相手に伝える手段としても使いやすく、自分の理解の助けにもなるので、個人的には効果を感じています。同じようなタスクを振られた際に振り返れる情報があるのは時間の短縮や改善も期待できるので、引き続きやっていきたいです!

未経験エンジニアへのキャリアアドバイス


キャリアアドバイザーをしていたこともあり、時々未経験エンジニアや現役エンジニアからキャリアについての相談を受けたりします。自分以外のキャリアを知ることは自分のキャリアを構築していく上でとても重要なので、キャリアチェンジしてからもキャッチアップを積極的に行なっています。

読書の習慣化


エンジニアになる前から読書(技術書含む)はちょいちょいしてましたが、どうせ技術書をたくさん読むならそもそも読書を習慣化してしまおうと思い仕組み化。技術書を除くと、ビジネス書・自叙伝・思考系・マインド系などジャンルは様々。とりあえず気になった本を図書館で借りて、2週間で1冊借りてくるのと、自分で購入した本、会社で借りた本などを適当に乱読。※技術書以外は、基本ただの趣味。

結果、引きこもりの完成です🙄月に4-5冊読めるようになったので、よしということで…

まとめ

他にも業務内容やプログラミング言語のキャッチアップなどありましたが、普通にやりそうなことだと思ったので、今回は取り上げませんでした。

1つ気づいたことは、多くの人やコミュニティに関わることで得られる情報の量が違うなと感じました!思わぬところで、思わぬ繋がりもあったりするので、個人的には対外的に交流することは続けていこうと思います!

株式会社フォトラクションでは一緒に働く仲間を募集しています

Fishシェルを使いましょう

Fish(フィッシュ・シェル)はFriendly Interactive SHellの略で、UNIX系システムのシェルであり、UX(ユーザーエクスペリエンス)に長けたシェルです。そのため他のシェルに比べて仕事が効率的に出来ることが多いです。

FishのASCIIロゴ
FishのASCIIロゴ

Linuxディストリビューションの兼ね合いでBashシェルを使用する方は多いかもしれません。そこからもっと使い勝手のいいZshに移った方や、macOSのアップグレードでデフォルトシェルがZshを使用されている方はいらっしゃると思いますが、それもオワコンと断言できます!

Fishはホームページには90年代のためのシェルと書いてありますが、私は21世紀のシェルであると盲信しています。他のシェルを使用する中でFishを使い始めたらもう手放せません。

BashZshの時にコマンドを打つたびにmanページ(ターミナルからアクセスできるUNIX系マニュアルコマンド)を読んだり、ググったりしていましたし、なんとかcompletionのパッケージをインストールしたりしていましたが、Fishではそれをきにすることなく、manページから自動的に解析し、コマンドの先頭文字を書きながらTabキーを押すことでコマンドの説明やオプションやサブコマンドをわかりやすい色使いで、表示してくれます。過去に入力したコマンドを薄いグレー色で表示し、キーを押すと保管してくれます。シンタックスハイライトも美しいですし、右側のプロンプトの設定などもできます。

Fishでのlsで始まるコマンド補完挙動
Fishでのlsで始まるコマンド補完挙動

Fishでのlsコマンドのオプション補完挙動
Fishでのlsコマンドのオプション補完挙動

Zshでもそんなことができるぞ」とおっしゃる方はいらっしゃるかもしれませんが、これはいわゆる「Out of the Box」(何のカスタマイズもない)Fishの振る舞いです。

では導入方法を見ていきましょう:

Fishを導入

インストール

各プラットフォームのインストール方法は公式ホームページから確認できます。

fish shell

macOS

Homebrew:

brew install fish

権限がない、もしくはシステムに痕跡を残したくない方は単独のアプリ(Automatorを使用しラッパー(Wrapper))をダウンロードし起動することができます。

Linux

Homebrewを導入していれば上記macOSのコマンドでも導入できます。

ディストリビューションが多くて、代表的なものですと:

sudo apt-add-repository ppa:fish-shell/release-3
sudo apt update
sudo apt install fish
dnf install fish

Unix

pkg install fish
pkg_add fish

Windows

MSYS2を導入している方は:

pacman -S fish

Fishをデフォルトシェルとして設定

インストールが成功したら、Fishをデフォルトシェルに設定することがおすすめです。多くのシステムではFishは同梱されていないことが多いので、システムにFishコマンドの場所を教えてあげる必要があります。

システムレベルで現在のログインしているユーザーのシェルをFishにするのにやることは二つ。

  1. /etc/shellsというデフォルトシェル一覧ファイルにFishコマンドの場所を追加
sudo sh -c 'echo $(which fish) >> /etc/shells'
  1. 現ユーザーのデフォルトシェルを設定
chsh -s "$(which fish)"

上記はUNIX系の環境であれば動くはずですが、つまづいたらググるもしくはチャチャる(ChatGPT)で調べてみてください。

Fishで出来ること

基本的に他のシェルで出来ることはFishで、もっと優雅にできます。

シェルスクリプトをプログラミングすることもできますし、シェルのプロンプトをカスタマイズすることができます。

Fish言語

シェルスクリプトのようにFishでプログラミングするためのFish言語が存在します。

細かくみたい方はこちらをご参考ください。

The fish language — fish-shell 3.6.1 documentation

この記事では代表的なところをご紹介します。

変数

全ての変数は配列です。Fishではリストとも呼びます。Bashと同じく配列メンバーをスペースで分けますが、ダブルコーテーションもしくはバックスラッシュでスペースをエスケープすることができます。

set var "foo bar" banana
set var foo\ bar banana # バックスラッシュでも同じ結果
printf %s\n $var

結果:

foo bar
banana

変数の代入時にコマンド結果を使用してもいいし、実値とコマンドを混ぜることができます。

set numbers 1 2 3 (seq 5 8) 9
printf '%s\n' $numbers

結果:

1
2
3
5
6
7
8
9

配列の一部を表示:

echo $numbers[5..7]

結果

6 7 8

関数

Fishの関数はコマンドのように使用ができ、補完するときの説明も追加することができます。

function hoge --description "関数の説明はこちら"
    echo $argv
end

Fishでの関数補完時に説明も表示されます
Fishでの関数補完時に説明も表示されます

Fishでの関数補完時に説明も表示されます

$argvは他のPOSIXシェルで使われる位置パラメータ($1,$2, …)の代わりであり、上記のように配列になっています。

ユニバーサル変数

これは他のシェルに見当たらないすごい機能であり、ユーザが起動中の全てのFishシェルに対して横断的且つ永久に変数値を設定することができるすごい機能です。つまりシェルの設定ファイルなどを手動で編集することなく、マシンを再起動しても残る変数です。

# このコマンドは、全てのfishシェルに対してプロンプトを青色に設定するものです。
set -U fish_color_cwd blue

上記のコマンドで設定された変数は~/.config/fish/fish_variablesに書き出されることがこの挙動の秘密のようです。

FishではPATH変数がユニバーサル変数として定義されています。

注意事項

Fishはユーザー体験や使いやすさに力を入れたシェル環境です。そのため、ZshみたいにBashPOSIXの互換性を維持するというミッションはないので、基本的に多くのBashの書き方は使用できません。バックティック```でコマンド実行することや、シェルの展開・置換(Bash expansion)は使えません。その理由はこういったシェル実装にバグやクセが多いからだそうです。その代変えとなるものはドキュメンテーションに書いてあります。

Bashシンタックスに慣れた方はドキュメンテーションの「BashユーザーのためのFish」(英語)をご参考願います。

Fish for bash users — fish-shell 3.6.1 documentation

Bashの書き方として使えて、Fishで使えない書き方の例(Wikipedia#Bash/fish_translation_table)より)

機能名 Bash Fish 備考
Fishでは中括弧は使えません ${var} $var Fishでは中括弧は使えません
配列の拡張 "${var[@]}" $var Fishの変数は配列なので、そのまま拡張されます。中括弧は使えません。
明示的なサブシェル (expression) fish -c expression サブシェルの呼び出し
プロセス置換 <(expression) (expression | psub) プロセス置換
変数代入 var=value set var value 単純にイコールサインの代入はできません。全てをsetコマンドで通す必要があります。
文字列処理(プレフィックスサフィックス、貪欲パターン、貪欲でないパターン) var=a.b.c
"${var#*.}" #b.c
"${var##*.}" #c
"${var%.*}" #a.b
"${var%%.*}" #a
string replace --regex '.*?\.(.*)' '$1' a.b.c #b.c
string replace --regex '.*\.(.*)' '$1' a.b.c #c
string replace --regex '(.*)\..*' '$1' a.b.c #a.b
string replace --regex '(.*?)\..*' '$1' a.b.c #a
stringコマンドを使用する必要があります。
文字列置換 "${HOME/alice/bob}" string replace alice bob $HOME stringコマンドを使用する必要があります。
変数のエクスポート export var set --export var setコマンドで通す必要があります。
関数のローカル変数 local var デフォルト仕様 関数の変数はデフォルトでローカルです
引数ベクター操作:シフト shift set --erase argv[1]
計算 $((10/3)) math '10/3' expr 10/3は外部コマンドなので、両方のシェルに使用できます
エスケープシーケンス $'\e' \e
環境変数を設定しながら実行 LANG=C.UTF-8 python3 env LANG=C.UTF-8 python3 env LANG=C.UTF-8 python3は外部コマンドなので、両方のシェルに使用できます

まとめ

Fishは大変使いやすいシェルでおすすめです。使いやすいし、Tabキー補完や履歴呼び戻しが直感的です。ぜひ使ってみてください。

株式会社フォトラクションでは一緒に働く仲間を募集しています

【Laravel】bootTraitsメソッドを使用して任意のテーブルのデータ保存をフックに共通処理を行う

こんにちは。CREの豊田(とよひろ)です。

以前LaravelのbootTraitsという便利なメソッドを発見したので記事にしたいと思います。

TL;DR


例えば、slackに通知したいとかアラートを出したいといった時に使えそうな便利な実装方法!

Itemテーブルなど、テーブル保存時に、ログを入れたいなどといったシーンで共通処理をいちいちコントローラー側に書いていくのはかなり大変ですよね。

Traitで共通処理を記載し、LaravelのModel.phpのbootTraits()メソッドをうまく使うと実現できます。

bootTraitsメソッドとは?


自身に使われているtraitの一覧を取得します。

つまり、使用しているクラス内のTraitの中にある「boot + Traitのクラス名」メソッドに対して、処理を行うことができます。

LaravelからEloquentクラスを調査してみる


保存をフックにするので

src/Illuminate/Database/Eloquent/Model.php

この辺を見てみる。

そうすると...

    /**
     * Boot all of the bootable traits on the model.
     *
     * @return void
     */
    protected static function bootTraits()
    {
        $class = static::class;

        foreach (class_uses_recursive($class) as $trait) {
            if (method_exists($class, $method = 'boot'.class_basename($trait))) {
                forward_static_call([$class, $method]);
            }
        }
    }

boot + Traitのクラス名で書くと勝手に呼び出してくれるようです。

なので、これを元にTraitを作れば解決しそうです。

以下実装例


trait Hogefuga
{
    /**
     * 保存時に共通処理をする
     *
     * @return void
     */
    protected static function bootHogefuga()
    {
        static::created(function ($model) {
            // 作成する時の共通処理
        });
    }
}

あとは、共通処理を挟み込みたいmodelクラスにuseしてあげればOK

User.php

class User extends Eloquent
{
    use Hogefuga;
}

Item.php

class Item extends Eloquent
{
    use Hogefuga;
}

作成時以外も対応してみる


trait Hogefuga
{
    /**
     * 共通処理をする
     *
     * @return void
     */
    protected static function bootHogefuga()
    {
        static::created(function ($model) {
            // 共通処理
        });

        static::saved(function ($model) {
            // 共通処理
        });

        static::updated(function ($model) {
            // 共通処理
        });

        static::deleted(function ($model) {
            // 共通処理
        });
    }
}

このようにしてあげることで本来、各コントローラーに記載しないといけないものがbootTraitsによってログを取れるようになります!

ぜひ試してみてください!

終わりに


リファレンスに記載されていないライブラリでも結構面白い、または便利なものがあったりします!!

github散歩等で触れたことのないライブラリを見つけてみるのも面白いかもしれません!😊

株式会社フォトラクションでは一緒に働く仲間を募集しています