Photoruction工事中!

Photoructionの開発ブログです!

CREチームへインタビューしてみた。

みなさんこんにちは、CREチームのとよかずです!

運営担当である僕がアドカレ1本目の記事を執筆していくことになりました(緊張)

どんな記事にしようかあれこれ悩んでいたのですが、自分が所属してるチームのことを改めて知ってもらう機会を設けてもいいのかなと思い、今回はCREチームへのインタビューを記事にしてみました!👏

✨CREチームへのインタビュー✨

とよかず:それでは早速始めていきたいと思います!自分が所属するチームに対して、インタビューするのはなんだか不思議な気分ですが、最後までお付き合いください(笑) まず始めに、各メンバー自己紹介をお願いします🙇‍♀️

田中(以下、よしき):CREグループのチームリーダーを務めます田中です。

未経験エンジニアとしてフォトラクションに入社しており、1年半ほど改修や案件をこなしたりしたのち、去年の11月からCREのチームリーダーを務めています。現在、フォトラクションに勤めて3年目になります。

豊田(以下、とよひろ):CREグループの豊田です。

新卒で住友林業に入社し、3年間の営業経験を積みました。タジくんと同じく、当時同業界への課題感を感じていました。以前は全く異なる分野でエンジニアとして活動していましたが、建設業界における社会への貢献と課題解決への志から、フォトラクションに転身しました。

田島(以下、タジ):CREグループの田島です。

元々、サブコンで施工管理者として働いており、同業界への課題感を感じたこと、またエンジニアの職種に興味を持ったことからフォトラクションへ入社しました。とよかずさんと同じく未経験からエンジニアとしてCREチームに入りまして、ちょうど半年たったくらいになります。

※とよかず入社エントリーはこちら↓↓↓

kojichu.photoruction.com

Q.CREチームでの業務について教えて下さい!

よしき:主な業務としては、お客様からの問い合わせ内容(仕様の確認・調査依頼など)に対して、『どんな事象が起きているのか』『どういう操作をしたら再現がするのか』『なぜそのような不具合が起きているのか』などの1次切り分けをするのが私たちの業務になります。

また、弊社では運用レポートというものをお客様に提出していますが、こういったデータの抽出や修正なども対応しております。なので、カスタマーサポート(以下、CS)とSaaSチーム(開発チーム)との架け橋的な存在がCREになります。

CREチームリーダー よしきさん

Q.そもそもなぜ、CREというチームが必要なのでしょう?

よしき:お客様からの問い合わせへの対応が主な業務になるとお話ししましたが、問い合わせって不確実性の塊だなと思っていてそこにCREチームのような一定のエンジニアリング知識を持った人たちが、介入することによって、不確実なものを確実なものにしていくということが必要になってきます。そうすることで、CS側からの不具合の問い合わせをスムーズにSaaSチームにお渡しすることもできますし、そもそもCREチームで解決できる内容であれば、ユーザー様へのレスポンスも早くなるため結果としてユーザー様の知りたい情報を素早く提供でき、顧客満足度向上に影響を与える事ができると考えています。そのためユーザー様に少しでも長くフォトラクションというプロダクトを使用いただくためにも、CREというチームが必要だと考えています。

とよかず:ユーザー様からしたら、とにかく早くレスポンスが欲しいですもんね。仮にCREというチームが存在しないことを考えるとユーザー様への影響しかり、社内関係各所でも色んなところで、悲鳴の声が上がりそうです…

ちなみに、CREポジションで働く皆様に質問があるのですが…

Q.ずばりCREの業務について、意識してることを聞かせてください!

よしき:意識してることとしては、バランスよくタスクを振るような心がけをしています。現在CREに所属してるみなさんは、いずれSaaSチームに送り出す事が開発組織で決まっているので、そのためにも調査タスクだけでなく改修タスクもこなしていってもらうことで、プロダクトの理解を深めつつ、技術力向上を目指していってほしいので、そういった意味合いから、偏りがないように気をつけてはいます。

また、エンジニアとしての成長という観点からCREチームでは2週に1回、勉強会という時間も設けています。各々がわからない部分やもっと深掘りしたい部分などを共有し、それについて議論したり、お互いの技術力を向上させていこうという目的のもと、教材となる本をチームで読み進めたりしながら、技術の理解を深めたりしています。

僕のは、どちらかというとリーダー視点の話しですね(笑)

←とよひろさん よしきさん→

とよひろ:CREでは「こういうバグがありました、不具合があります」という問い合わせが来てそれに対応するフローですが、その問い合わせから「ユーザーが本当に求めていることは何か」、「機能としてはこうなった方がいいんじゃないか?」などユーザー目線に立って、考えるように意識はしています。また、ユーザーに近いからこそSaaSチームにも見えない部分を見ることがCREの業務の一つかなと思っています。

タジ:UIパーツの呼称がそれぞれのユーザー様で異なるので、その点を汲み取る事を意識してます。例えば、UIパーツにオン/オフするボタンをエンジニアだとトグルボタンと言ったりしますが、人によっては「スイッチ」といったりするので、呼称の違いを確認し、事実がなにであるかを確認していくことを意識しています。

もう一つ、ユーザーの操作動線の確認も意識してるポイントになります。自分たちはコードベースで動線を考えるため、「前提としてこうだよね」って考え方があり、そこがユーザー様の動線と異なる事があるので、その点も意識してたりします。

とよかず:CREって、プロダクト探偵っぽいですよね〜

問題があって、仮説を立てて検証して、原因を特定していくって、まさに探偵っぽいなと思ってます(笑)

ちなみに僕が意識してることとしては、CSとSaaSとの間に僕らのチームがいるので、CS側に伝わる話し方とエンジニアに伝わる話し方を分けるようにしていて、認識の齟齬が出ないように余分な情報を取り除くことでクリアなコミュニケーションを意識してたりします。

タジ:確かに、通訳っぽい面もありますね

よしき:探偵兼通訳ですね…(ボソッ)

とよかず:職種増えましたね(笑)

業務については、お話しいただけたので、今度はチームについて伺いたいのですが…

Q.チーム作りにおいて意識してる取り組みなどありますか?

考えるよしきさん

よしき:CREには現在、業務委託の方を含め7名在籍しているのですが、各々別々の調査タスクをやっているため、そこで分かったことや詰まっていることなどを朝のデイリーの時間で共有してもら

うことで、一人で抱え込まないチームづくりを意識してはいます。またその時間で、他の人が触った機能についてのシェアをするなどして、情報共有を活発にするような取り組みを行っています。

とよかず:確かに、デイリーがあることによって、自分が触っていないタスクについても、頭の片隅には置いてあって、自分がその機能触る時に初見じゃない感はありますね〜

タジくんはその点、意識してることなどありますか?

タジ:質問内容とは少し違うのですが、デイリーについて話しをすると、CREメンバーが増えたことで、デイリーの時間が延びてしまっている問題はありますね。

一同:(確かに!!!)

よしき:個人がこなしてるタスクについては共有をして、それ以外の個人で共有したい事項については、また別の時間で共有する方がいいかもね〜

ということで、早速これをデイリーで取り入れていこうと思います!

とよかず:(まさに、最速挙動💨)

こういった疑問に感じたことや思っていることをその場で発信して、それをすぐに実行→改善できるのがCREチームの良さかもですね。お互いに敬意尊尚という価値観を持っているからこそ、職位関係なく自分の思っていることを伝えられる気がします。

Q.チーム内でのコラボレーションや情報共有の取り組みはありますか?

よしき:時たま発生するイレギュラータスクで、チームの絆というか、コミュニケーションが促進されている感じはありますね〜

それ以外にも最近は、一人がタスクを抱え込まないようなやり方も試していて、2人1組でタスクにあたってもらうようなことも試していたりします。調査といえど、それぞれのやり方や着眼点があったりするので、そういったところはお互いに刺激しあって、学んでいってもらいたい点になります。

とよかず:実際、自分以外の人のやり方って知る機会があまりないので、2人1組の取り組みはありがたいです。

Q.今後のCREチームとしての展望や目標について教えてください。

よしき:度々いってることになるのですが、チームの目標として「安定化」と「成長」というのを掲げており、安定化については「三方良し」を実現できればいいなと思っています。CREにおける三方良しとは、CRE・SaaS・CSかなと思ってまして、CS側については社内での体制変化もあり、注力してた部分はあるのですが、SaaSチームとの連携がうまくいかない部分があったので、その点を今後は注力しながら、お互いにスムーズに仕事を進めて行ければいいなと思います。

また成長については、チームとしての成長を目指しつつもメンバークラスの方々の成長を第一に考えています。CREチームでプロダクトへの理解を深めつつ、改修タスクなども行い、その中でエンジニアとしての成長を目指してもらい、最終的にはSaaSチームの一員となって第一線で活躍してもらいたいと考えています。そのためにも、一定の水準までスキルを伸ばせる仕組みを作っていくことが、今後の課題かなと思います。

最後は競馬の話で盛り上がっていました〜(笑)

おわりに

今回は自分のチームに対して、インタビューしましたが、改めて他のメンバーが意識してることを聞くことができ、自分の中での新しい気づきが増えました!その気づきを今後の業務の中でも積極的に意識していこうと思います!

これからもCREチームでは、ユーザー様に寄り添っていけるプロダクトを作れるようにチーム一丸となって業務に取り組んでいきたいと思いますので、応援のほどよろしくお願いします🙇‍♀️

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

Zapierを使ってSlackのメッセージからNotionのDBにタスク追加

はじめまして、CREエンジニアの田島です。

今回は、Zapierを用いたNotiion⇄Slack連携について紹介したいと思います。

背景


弊社ではチャットツールとしてSlackを使用しています。当然、業務上のコミュニケーションはSlack上で交わされるわけですが、そこでタスクを振られることがあります(上長からだったり、他部署からだったりと状況は様々ですが)。

振られたタスクの優先度が低いなら、とりあえずブックマークしたいところですが、Slackのブックマークでは後々の管理がしんどいですよね。

だからといって、JIRA等のツールで管理するほどでもないしなーってとき、NotionのDBにタスクを投げ込みたい、そんな方のための記事になっています。

事前準備


各種ツールのインテグレーションは割愛します。

NotionでDBを配置するページにZapierコネクトが追加されていることを確認してください。

概要(動作イメージ)


Slackのメッセージに対してリアクションをすると、そのメッセージの内容をNotionのDBに追加できるようにします。

タスク投げ込み用DBの作成(Notion)


DBを用意します。DBには名前をつけておいてください(この場合、個人TASK)

プロパティは任意ですが、今回は上記画像のようにしました。

Zapを作成(Zapier)


1. Triggerを設定する

今回は、メッセージに対してリアクションが追加された時、をトリガーとします。

EventにNew Reaction Addedを指定します。

続いてトリガーの条件を指定します。

どのチャンネルに、誰が、どんなリアクションをしたとき、のような設定が可能です。

2. Formatterを適用する

Slackのメッセージが投稿された時間を依頼日としてDBに保存するため、日時をフォーマットします。

3. NotionのDBに追加する

EventはCreate Database Itemを指定します。

Databaseには、用意したNotionのDB名を指定してください。

後は、NotionのDBプロパティに合わせて設定を行ってください。

4. Zapを公開する

🎉Publishで完了です🎉

まとめ


業界的に、業務上使用するツールが多いですよね。

NotionやSlack単体でも各種ツールと連携することは可能ですが、間にZapierを挟むとかゆいところに手が届くかもしれません。

(NotionやSlackの今後のアップデートによっては、わざわざZapierを間に挟まなくても、やりたいことが実現できるようになるかもしれません。もしかしたらもうできるのかも。。。。)

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

PDFの生成ができるライブラリReportLabの使い方

はじめに

こんにちは、AIエンジニアの志賀です。

このたびはPDFの生成ができるライブラリReportLabの使い方についての技術ブログをご覧いただきありがとうございます。

PythonReportLabというライブラリを使用すると、プログラムからPDFドキュメントを生成できます。

この記事では、ReportLabの基本的な使い方を解説します。

ReportLabを使ってPDFを生成する

環境のセットアップ

まず、PythonReportLabをセットアップします。

Pythonをインストール済みであることを確認し、ReportLabを以下のコマンドでインストールします。

pip install reportlab

基本的なPDFの生成

基本的なPDFの生成は以下のステップで行います。

まず、Pythonスクリプトを作成し、必要なモジュールをインポートします。

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas

# PDFドキュメントの生成
c = canvas.Canvas("basic_pdf.pdf", pagesize=letter)

テキストを追加するには、以下のように drawString メソッドを使用します。

c.drawString(100, 750, "ReportLab")

このコードは、座標 (100, 750) にテキストを追加します。

次に、新しいページを追加するには以下のコードを使用します。

c.showPage()

これにより、新しいページが生成されます。テキストの他にもさまざまな要素を追加できます。

フォントとスタイルの設定

フォントとスタイルを設定することで、テキストをカスタマイズできます。

フォントの設定は以下のように行います。

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas
from reportlab.lib import fonts

c = canvas.Canvas("styled_pdf.pdf", pagesize=letter)
c.setFont("Helvetica-Bold", 12)
c.drawString(100, 750, "Customized Text")

このコードは "Helvetica-Bold" フォントを使用してテキストを表示します。

テーブルの作成

テーブルはデータを整然と表示するのに役立ちます。

以下はテーブルを作成する基本的なステップです。

from reportlab.lib.pagesizes import letter
from reportlab.platypus import SimpleDocTemplate, Table, TableStyle
from reportlab.lib import colors

doc = SimpleDocTemplate("table_pdf.pdf", pagesize=letter)
data = [["col1", "col2", "col3"],
        [1, 2, 3],
        [4, 5, 6]]

table = Table(data)
table.setStyle(TableStyle([('BACKGROUND', (0, 0), (-1, 0), colors.grey),
                           ('TEXTCOLOR', (0, 0), (-1, 0), colors.whitesmoke),
                           ('ALIGN', (0, 0), (-1, -1), 'CENTER'),
                           ('FONTNAME', (0, 0), (-1, 0), 'Helvetica-Bold'),
                           ('BOTTOMPADDING', (0, 0), (-1, 0), 12),
                           ('BACKGROUND', (0, 1), (-1, -1), colors.beige),
                           ('GRID', (0, 0), (-1, -1), 1, colors.black)]))

elements = [table]
doc.build(elements)

このコードは、データを含むテーブルを生成します。

図形の追加

ReportLabを使用して、PDFに図形を追加できます。

以下は簡単な例です。

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas

c = canvas.Canvas("shapes_pdf.pdf", pagesize=letter)

# 線の描画
c.line(100, 100, 200, 200)

# 円の描画
c.circle(300, 150, 50)

# 四角形の描画
c.rect(400, 100, 100, 50)

c.save()

このコードは、線、円、四角形を描画し、PDFに保存します。

画像の挿入

画像の挿入も簡単です。

まず、PILライブラリを使用して画像を読み込みます。

from reportlab.lib.pagesizes import letter
from reportlab.pdfgen import canvas
from reportlab.lib.utils import ImageReader
from PIL import Image

c = canvas.Canvas("image_pdf.pdf", pagesize=letter)

# 画像読み込み
image = Image.open("example.jpg")

# ReportLab ImageReaderに変換
image_reader = ImageReader(image)

# 画像を描画
c.drawImage(image_reader, 100, 100, width=200, height=150)

c.save()

このコードでは、"example.jpg" という画像をPDFに挿入しています。

PDFファイルの保存と出力

生成したPDFを保存するには、 save メソッドを使用します。

既にいくつかの例で使用していますが、以下に再掲します。

c.save()

終わりに

以上が、PDFの生成ができるライブラリReportLabの基本的な使い方の解説でした。

いかがでしたでしょうか。

是非、Python開発でReportLabを使って、PDFの作成をしてみてください。

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

【tqdm】Pythonでコードの進捗を可視化!

こんにちは、エンジニアとして株式会社Photoructionでアルバイト中の伊藤純平です!

秋も深まり、「学びの秋」とも言われるこの時期は学びを深める絶好のチャンスかもしれません。今回は、Python開発で役立つプログレスバーのライブラリ、tqdmを詳しくご紹介します。

私のチームではPDFを扱うことが多く、PDFの分析や可視化などにおいて一つの処理が長くなってしまいます。コードがいつ実行し終わるのか、わからないと不安になりますよね。。。そんなときに便利なのがtqdmです。このライブラリを使えば、進捗を簡単に確認できます。

この記事では、tqdmの基本から便利な使い方までを解説します。機械学習や統計など一つの処理に時間がかかるコードが必要なプロジェクトに取り組んでいる方、またこれから取り組む方も、ぜひお読みください!

tqdmとは

概要

tqdmアラビア語で"進捗"を意味する"taqaddum"から来ています)は、Pythonで使える簡単で拡張性のあるプログレスバーのライブラリです。Pythonファイルだけでなく、Jupyter Notebookやgoogle colabでの利用も可能です。また、tqdm.autoというモジュールを使えば、実行環境に合わせて最適なプログレスバーが自動で選択されます。

下準備

はじめに、tqdmをインストールしておきます。以下のコマンドでtqdmをインストールできます。

pip install tqdm

基本的な使い方

基本的にはforループにtqdm関数を適用するだけで、プログレスバーが表示されます。

さらにtqdm.autoをインポートすると、コードが動作する環境に応じて適切なプログレスバーが自動で表示されるため、手動で環境を指定する必要がありません。

# tqdmライブラリをインポート
from tqdm.auto import tqdm
import time

# tqdm関数でプログレスバーを表示
for i in tqdm(range(100)):
        # この部分に実際の処理が入る
    time.sleep(0.1)

プログレスバー

このコードでは、0から99までのループを行い、各ステップで0.1秒待機します。この間、進捗バーが表示されます。進捗バーは以下のように読むことができます。

  • 72**%**: 現在の進捗をパーセンテージで表示します。
  • ██████████████: 完了した進捗を表すバーです。
  • 72/100: 処理が何回完了したかと、全体で何回の処理があるかを表示します。(画像では: 72回完了、全体は100 回)
  • 00:07<00:02: 経過時間と推定残り時間を表示します。(画像では: 経過7秒、残り**2**秒)
  • 9**.88s/it**: 1ループ処理にかかる平均時間を表示します。

様々な使い方

ネストされたループ

tqdmはネストされたループでも使えます。以下の例では、外側と内側の2つのループがあります。descオプションを使って、各プログレスバーに説明文('外側のループ''内側のループ')を追加しています。

# tqdmライブラリをインポート
from tqdm.auto import tqdm
import time

# descオプションで説明文を設定。
for i in tqdm(range(3), desc='外側のループ'):
    # descオプションで説明文を設定。
    for j in tqdm(range(3), desc=' 内側のループ', leave=False):
                # この部分に実際の処理が入る
        time.sleep(0.5)

コード内情報の表示

プログレスバーにはコード内の情報も表示できます。進捗情報だけでなく、現在の処理に関する追加の情報を表示するのに便利です。

# tqdmライブラリをインポート
from tqdm.auto import tqdm
import time

# postfixで初期の「現在の値」を0に設定
with tqdm(total=100, postfix={'現在の値': 0}) as pbar:
    for i in range(100):
                # この部分に実際の処理が入る
        time.sleep(0.1)
        # プログレスバーを1進める
        pbar.update(1)
        # プログレスバーの「現在の値」を更新
        pbar.set_postfix({'現在の値': i+1})

処理速度と残り時間

デフォルトで処理速度や推定残り時間も表示されます。これで処理がいつ頃終わるのかがわかりますね。

終わりに

tqdmは、コードに数行追加するだけでプログレスバーを表示することができ便利です。

バーのデザインやコード内の情報の可視化も**tqdm**のライブラリを用いることで実装できます。

是非Python機械学習などの時間がかかる処理が必要な際には、このtqdmライブラリも試してみてください!

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

DroidKaigi2023にゴールドスポンサーとして参加しました。

Androidエンジニアの藤井(@kusakabe_dev)です。

9/14(木)-9/16(土)にベルサール渋谷ガーデンにて開催された DroidKaigi 2023 にオフラインで参加してきました。

今回は当社がブース出展を行うとのことで、出展スタッフ兼一般参加者という立ち回りでした。

出展スタッフとしてやったこと・感想

出展スタッフとしては2,3人体制で時折私がセッション聴きに抜けつつ、

ブースに来てくれた方々に当社が開発しているアプリについて説明をさせていただきました。

https://x.com/DroidKaigi/status/1702522134185300384?s=20

出展ブースの様子

感想としては、

  • 当社のことを知っているAndroidエンジニアは思ってた以上に少ない
  • アプリを見せる以外のコンテンツも用意しても良かったかもしれない
    • アンケート・くじ引き等
  • 配布したノベルティの感触は良かった
  • アプリの説明で割りと喉を酷使するので、飲み物・のど飴は持ち込んでおいたほうが無難
  • ブースエリアと隣接しているセッションスペースが有ったので、ある程度はブース対応しつつもセッションを垣間見ることは出来た

…と、いった感じです。

いくつか良かった点と改善したい点がありますが、来年も機会があれば改善できるところは改善できれば良いかなと思っています。

一般参加者としての感想

出展対応の関係上、参加者として聴講したセッションは正直限られてくるのですが、主にパフォーマンス改善に関わる内容や開発環境周りなど、すぐにでも取り入れられそうで且つ興味を持ったものを選択しました。

聴講したセッションは下記のとおりです。

各セッションに関する詳細な感想は割愛しますが、いくつかすぐにでも実業務で取り入れられそうなものもあり、見れなかったセッションも含めスライドを見返そうかと思っています。

また、DAY1のアフターパーティでも他社のAndroidエンジニアの方々や普段リモートでお世話になっている方と交流することが出来たのが楽しかったです。

最後に

DAY1,DAY2とブース出展スタッフとしての参加は今回が初でしたが、当社やプロダクトの認知度向上には一役買うことが出来たのかなと思います。

来年も機会があれば、当社の認知度向上に貢献しつつ、登壇内容も腰を据えて聴講できればと考えています。

余談

今回、DroidKaigiに参加するにあたって、カンファレンスアプリにも微力ながらContributさせていただきました。

今回は以下のPRを出していました。

https://github.com/DroidKaigi/conference-app-2023/pull/985

正直なところ、普段の業務ではJetpackComposeを本格的には導入できていないため、実装自体は苦戦しましたが、アプリ公開までにマージできてよかったです。

ただ、今年は実装にあまり時間が取れなかったので、もう少し貢献できていればというのが正直なところではあります。

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

SNS運用チームのリーダーに抜擢⁉️

はじめまして、フォトラクションに4月から入社しましたトヨカズです!

入社してから早いもので、5ヶ月が経ちました(時の流れが早い…)。CREチームでのタスクにも慣れ、プロダクトへの理解も少しずつ深まってきているフェーズになります。※まだまだ、わかんない事の方が多いですが…

前回は、なぜフォトラクションを選んだのかというタイトルの元、僕がフォトラクションを選んだ理由についてつらつらと書きました!

今回はそんなひよっこエンジニアが、SNS運用チームのリーダーに任命されてから運用に至るまで、どんな経緯でそうなったのか、実際の活動についてのお話しをさせていただければと思います🫣

スタートアップのスピード感他部署との連携スタートアップならではの裁量権など弊社の内部的な話しが気になる方はぜひ見ていってください✨

そもそもなぜ、SNS運用をすることになった?


転職活動中から気になっていたことの一つが社外への情報発信の少なさです。転職活動を進める際、企業選びはマストのアクションですが、その時に重要になってくるのが、どんな企業であるかを知るということ。それは、単に資金調達をしているとか、会社の規模だけに限った話しではなく、内部で働いてる人がどんな人なのか社内の雰囲気など実際に働いている人/組織内部のことをイメージできるかは、入社後ギャップをなくすのに必要な情報であると思います。

前職のSES営業ではSNS運用をしていた経験もあったのでその経験を活かす事もできそうだなと考え、至る所で上記内容について色んな人にお伝えをしていました。そんな中で、偶然にも僕と同じような思いを抱いている人たちを見つけ、「Xやりましょっ!!!」とお誘いをしたら、とんとん拍子で話が進んでいったわけです。

社内稟議を上層部に提出し、承認を得るまでのプロセス、そこから発足に至るまでの早さはまさに最速挙動👏(さすが人事部の要、増田さんです!)

SNS運用チーム発足後、初めてのMTG


初めてのMTGでは、僕が前職でどんな風にSNSを活用していたか、これからどうやって社外に対して発信していくかなど短い時間の中で、必要なことを共有しました。その中で、増田さん・青出木さんの方から「リーダーやってみない?」一杯どう?的なノリで(こんなフランクな表現ではなかった笑)打診されたので、二つ返事ではいと答えたのが、PJリーダーの始まりです🕺

フォトラクションのSNS運用チームでの活動


SNS運用チームは、現在4人で活動中で、人事・営業・マーケ・エンジニアという各部署のメンバーから構成されています。マーケ所属の宗田さんが、前職でも顧客のSNS運用などをしていたこともあり、その知見を活かして毎月の目標値を設定してくれたり、Xの基本運用方法を共有してくれたり職務洗練を体現してる一人です。(ほんとうに感謝🙇‍♀️)

Xは始めたてのフェーズが一番伸びづらいので、他ユーザーにとって価値あるツイートをしないと中々フォローまで結びつきません。そんな中で、あーでもないこーでもないと入社間もない人間の意見も聞き入れてくれる環境には感謝しかありません。

話がそれましたが、何がお伝えしたいかというと、フォトラクションにはスタートアップならではの柔軟さスピード感今までのキャリアの知見を積極的に活かそうとしてくれる姿勢などいいとこが盛りだくさんです👏

こちらが実際のツイート↓↓↓

社内のことをツイートしたり...

転職活動について触れていたりもします。

まとめ


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

今回は、弊社のスピード感と柔軟性について触れながら、SNS運用チームが発足するまでを記事にしてみました! チームリーダーとして至らない点が多々ありますが、フォトラクションという会社を一人でも多くの人に知ってもらえるように引き続きチームのみんなと頑張っていこう思います💪

最後にXのアカウントについて気になるかたはこちらをチェック↓↓↓



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

JPEG XL

SaaSチームのギヨームです。

今回はJPEG XLについての記事を書きました。

ぜひ拝見していってください。

JPEG XLとは何ですか?

その名前が示す通り、これは別の画像フォーマットです。

もちろん、画像のための多くのフォーマットがすでに存在しています。なぜ今、新しいものが必要なのでしょうか?

XKCD 927:新しいスタンダード

ITの世界は急速に進化する環境です。過去にうまくいったものは現代の要件に対応するのに十分にパフォーマンスがないことがあります。したがって、適応するために周期的にツールを変更することが必要です。

しかし、JPEG XLはどのような特徴を持っているのでしょうか?

まず、画像をエンコードおよびデコードする速度が、JPEGPNGJPEG 2000、WebPなどの先行ツールよりも大幅に高速です。これは非常に良いことです。また、並列処理に適しています。

次に、PNGと同様に、データが失われないロスレスエンコーダーについてです。写真とデジタルアートの両方に適しています。

さらに、圧縮率はPNGよりも大幅に優れており、WebPやAVIFなどの現代のフォーマットと同等の性能を発揮します(ただし、AVIFはロスフォーマットです)。

32ビットの真のカラーとアルファチャネルをサポートしているため、画像で透過性を使用できます。

低解像度の画像をユーザーに提示しながら、データ全体がまだダウンロード中である状態で、逐次的に画像を解読し表示するプログレッシブデコーディングは、ユーザーエクスペリエンスを著しく向上させる特長があります。これは、WebPやAVIFなどの現代の競合製品には備わっていない要素です。

さらに、既存のJPEGファイルから画質の損失なしで生成できます。

全体的に、JPEG XLはすべてのタスクにおいてかなり優れており、高品質画像に特に適しているため、主要な競合製品であるAVIFよりもわずかに優れています。

詳細については、以下のチャートを参照してください。

フォーマット機能マトリックス

なぜ今すぐ使用しないのですか?

このフォーマットはまだ新しく、その価値を評価するための完全なバトルテストが必要です。

最近まで、JPEG XL(またはJXL)サポートを有効にすることができましたが、ブラウザ設定で実験的にフラグをオンにする必要がありました(ChromeFirefoxベースのブラウザでは使用できましたが、Safariでは使用できませんでした)。

さらに、ブラウザで使用する場合は、ソースセットを持つpictureタグを使用する必要があり、すべてのブラウザでサポートされているにもかかわらず、まだあまり流行していません。

<picture>
  <source srcset="something.jxl" /> <!-- JXL -->
  <img src="something.jpg" /> <!-- JXL非対応の場合はこれにする -->
</picture>

サポートが広がると、これは変更される可能性がありますが、現在の時点では、採用と統合にいくつかの困難を引き起こしています。

しかし、Googleは残念ながら、コミュニティからの関心不足を理由に、2022年10月末までにJPEG XLのサポート実験をやめることに決めました。そして、このフォーマットは墓場に近づいていました。

JXLが放棄されているなら、気にする理由は何ですか?

最近、AppleSafari 17ベータ版のリリースノートで(密かに)発表しました。

具体的には、「JPEG XLのサポートを追加しました。 (100641584)」とあります。

AppleJPEG XLフォーマットを完全に受け入れ、Safariだけでなく、コンピューターやモバイルオペレーティングシステム、開発スタックにも取り入れる予定です。Googleは遅れているのを見られることを好まないため、Appleのような大手プレーヤーがこのフォーマットを採用する場合、手を打つ可能性が高いです。

要するに

私たちは、現代の世界で使用するためにほぼすべてのボックスをチェックするまともな画像フォーマットをついに手に入れる寸前にいます。ただし、現在のインターネットで使用されている主要なブラウザ(つまり、Chrome)でフォーマットのサポートを停止するGoogleのわがままでデジタル世界が左右されやすいです。(消費者の視点から言えば、競争は良いことです。)

幸いなことに、Appleはこの規格に救いの手を差し伸べ、現実化するチャンスを与えました。

簡単に言えば、損失なしで、高速、軽量、真の色、透過性、HDRプログレッシブデコーディングを持つ画像フォーマットになる可能性があります。

「壁のある庭」のAppleに、ユーザーにとって良いことをすることに感謝するとは思わなかったので、初めてのことでした。

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