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

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

プロファイラ(xhprof)によるボトルネック調査のすすめ

はじめまして!クイックに中途入社して早1年になりますソフトウェアエンジニアのたかにーです。

今回は弊社サイトの高速化に取り組んだ際に、プロファイラを用いてボトルネック調査をした時のお話をしたいと思います。

パフォーマンス改善を行うにあたり、重そうな場所を手当たり次第チューニングしたくなるところですが、まずはプログラムを計測してどこがボトルネックとなっているかを見極めることが重要です。

「Goの父」とも呼ばれるロブ・パイク氏も「Rob Pike's 5 Rules of Programming(プログラミング5カ条)」において、以下のようにおっしゃっていますね。

1. プログラムがどこで時間を費やすかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測でスピードハックを試みてはならない。
2. 測定せよ。測定して、コードのある部分が他の部分を圧倒しない限り、速度の調整をしてはいけない。
(引用元:Rob Pike's 5 Rules of Programming

ということで、ボトルネックを特定すべくプロファイラによる調査を行いました。

プロファイラとは

プロファイラとは、コンピュータプログラムが実行される様子を監視・記録し、プログラム中の各箇所の動作順や実行時間などを集計・解析するプログラム。ソフトウェアの開発環境や実行環境の機能の一部として提供され、プログラムの性能測定・解析を行うことができる。
(引用元:プロファイラ 【profiler】

プログラムをプロファイラにかけることで、各関数の呼び出し頻度やそれにかかる時間を計測することができます。つまりチューニング対象である実行頻度の高い箇所や実行時間の長い箇所を知ることができるわけですね。

世には様々なプロファイラ・ツールが存在しますが、今回は

  • 測定の対象がPHP(Laravel)
  • 目的は解析ではなくその先の高速化なので、導入が容易なもの

ということで、導入事例やドキュメントが豊富で、解析したいコード範囲を容易に指定できるPHPの階層型プロファイラxhprofを採用しました。
※他ツールとの詳細な比較に関しては、ここでは割愛させていただきます。

www.php.net

xhprofの導入手順

解析対象としたい開発環境は以下になります。

環境環境
  • PHP 8.0.*
  • Laravel 9.”
  • Apache/2.4.”
  • Docker Desktop 4.7.*

開発環境にプロファイラを導入するのに加えて、解析結果の表示用環境も用意します。プロファイルビューアとしてはxhprof-htmlを利用しました。開発環境に同居させることも可能だったのですが、出来るだけ余計なコードを含めたくなかったため別環境としました。 github.com

ではxhpforの導入手順について見ていきましょう。

  • 構成
./
 ├ docker-compose.yml
 ├ logs/xhprof/
 ├ dev-app/
 │  ├ Dockerfile
 │  ├ etc/php.ini
 │  └ var/log/httpd/xhprof/
 └ xhprof-viewer/
    ├ Dockerfile
    ├ tmp/xhprof/
    └ xhprof-html/
  • dev-app/Dockerfile

開発環境(dev-app)にxhprofをインストールします。 拡張機能のソースをコンパイルするのに必要なため、php-develもインストールが必要です。

RUN yum update -y \
# install php-devel
 && yum install -y php-devel
# install pickle
 && curl -s -L https://github.com/FriendsOfPHP/pickle/releases/latest/download/pickle.phar -o /usr/bin/pickle \
 && chmod 755 /usr/bin/pickle \
# install xhprof
 && pickle install --defaults xhprof

php拡張モジュールにxhprofを追加し、解析結果の出力先を設定します。

extension=xhprof.so
xhprof.output_dir=/var/log/httpd/xhprof/

次に、解析結果表示用の環境(xhprof-viewer)を準備します。

  • xhprof-viewer/Dockerfile

解析結果を格納するためのログディレクトリを用意し、後述するコールグラフ描画のためにgraphvizをインストールします。

FROM php:7.3-apache

# install graphviz
RUN apt -y update
RUN apt install -y graphviz

#   log  directory
RUN mkdir /tmp/xhprof
RUN chmod 777 /tmp/xhprof/

xhprof-viewerにxhprof-htmlを配置します。

# git clone https://github.com/sters/xhprof-html.git .

最後にそれぞれのコンテナで解析結果を共有するための設定を追加します。

  • docker-compose.yml
# dev-app : 解析対象の開発環境
   dev-app:
     volumes:
       - ./logs/xhprof:/var/log/httpd/xhprof
# xhprof-viewer : プロファイラビューワー
   xhprof-viewer:
     volumes:
       - ../xhprof-html/:/var/www/html/
       - ./logs/xhprof:/tmp/xhprof/

xhprofの使い方

ここではxhprofの使い方について紹介していきたいと思います。

xhprofの使い方自体は非常にシンプルです。
解析したいコードの開始位置と終了位置に以下のコードを入れることで、プロファイル結果を得ることができます。

xhprof_enable(XHPROF_FLAGS_NO_BUILTINS | XHPROF_FLAGS_MEMORY); // 開始位置

〜中略(解析対象のプログラム)〜

$data = xhprof_disable(); // 終了位置. $dataにプロファイル結果が格納される
file_put_contents('結果ファイル名', serialize($data)); // xhprof-htmlを用いるため結果をserialize

xhprof_enableには定義済みの定数を指定して、解析対象を調整することが可能です。 www.php.net 上記の例では
XHPROF_FLAGS_NO_BUILTINS :ビルトイン関数 (内部関数) をスキップする
XHPROF_FLAGS_MEMORY :メモリのプロファイル情報を出力に含める
という設定にしています。

実際の運用では他のメンバーが使いやすいように、プロファイラの開始 / 終了周りの処理をサービスコンテナにしてFacadeを作成し、Middlewareからコールされるようにすることで、APIを含む全てのhttp(s)リクエストの解析を簡単に行えるようにしました。

また、プロファイラを行うか否かはコードに直接記載するのではなく、Redisキャッシュに保存した値によって制御するようにしました。該当のキャッシュ値を開発用のデバッグ機能で操作することで、コードに手を入れることなく気軽にプロファイラを利用できます。

xhprofによる解析結果

ここからはxhprofによって得られる解析結果について紹介したいと思います。

プロファイラ結果をxhprof-htmlで確認すると、以下のような形でリクエストごとの解析結果へのリンクが表示されます。

上記リンクから遷移すると、解析結果の詳細を確認することができます。

それぞれの関数が何回コールされているか、関数自体にどれぐらい時間が掛かっているかを確認することできます。

各項目については以下の通りです。

項目名 内容
Function Name コールされた関数名
Calls 関数がコールされた回数
Incl. Wall Time 関数全体の処理時間
処理をネストした場合、全経過時間を含むことになる
Excl. Wall Time 該当関数からコールされた関数の実行時間を除外した関数の純粋な処理時間(microsec)
Excl. Wall TimeをCallsで割ると1回あたりの処理時間になる

View Full Callgraphのリンクからはコールグラフが確認でき、全体の処理の流れやボトルネックをわかりやすく可視化することも可能です。赤く表示されているのが問題がありそうな箇所です。

またFunction Nameのリンクからは、それぞれの関数のParent function(コール元関数)やChild functions(コールしている関数)を確認することができます。

関数単体の処理時間が大きい場合は関数自体がボトルネックと言えますし、1回ごとの処理時間は短いもののコール数が多すぎて全体の処理時間に与える影響が大きい場合は、Parent functionを辿ることでコール元の処理に問題が無いか?といったアプローチをすることができるわけですね。

実際に見つかったボトルネック

解析結果を通じて、ボトルネックになっているホットスポットあるいはホットパスがいくつも発見されました。

  • ループ内でのDBアクセス
  • マスタデータの重複取得
  • 大量のDB取得値に対する複数回のCollection::whereコール

具体的なパフォーマンスチューニングについてはここでは触れませんが、発見したボトルネックに対して適切に改修していくことで、大きな速度改善に繋げることができました。

まとめ

プロファイラによるボトルネック調査について紹介させていただきました。

パフォーマンスチューニングに限った話では無いかと思いますが、しっかりと計測し原因を突き止めることが結果として効率的な課題解決に繋がるということを実感した次第です。

皆様もぜひプロファイラを用いてご自分の書いたソースコードを解析してみてください。


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

919.jp

一枚岩のデザインチームを目指して

一枚岩のデザインチームを目指して

こんにちは。株式会社クイックWeb事業企画開発室(以下、「Web室」)デザインマネージャーの佐藤宜也です。

僕は今、Web室内に配属されているデザインチームをマネジメントしています。
人材業界を中心に、toC / toBなどのサービス、コンテンツ / 広告クリエイティブ、社内基幹システムなどその対応範囲は広く、メンバーそれぞれの強みを活かしてデザインに向き合っているチームです。

チームとしての歴史は若く、まだまだ小規模です。
そういう状況だからこそ、メンバーの意思統一をはかり一枚岩のチームを目指すことが大事だと考えています。
今のメンバーで一枚岩になることで生産性の向上につながることはもちろん、これからのチームの成長速度の加速につながると思うからです。

ここでは、一枚岩実現のために取り組んだ施策の中で特に印象深かった2つの事例と、実現したいチーム像を綴ります。
社内メンバーはもちろん、僕たちのカルチャーや価値観を知りたい、という方にも楽しんで読んでもらえると嬉しいです。是非、読んでみてください。

事例1:アシミレーションワークの実施

私がマネージャーに着任した時に、まず一番に取り組んだこと。
それが、このアシミレーションのワークです。

※アシミレーションの詳細に関して、ここでは割愛します。興味ある方は下記引用元をご覧ください。

・アシミレーションとは
直訳すると「融和」「同化」の意味。組織開発の手法の一つで、具体的にはチームのリーダーとメンバー間の相互理解を深め、関係構築を促進する仕組みを指します。チームに新しいマネジャーが着任したときなどに用いられることが多く、メンバーと新任のリーダーとの融合を図るために、上司抜きで上司について語り合う場を設け、その議論の内容を匿名で上司にフィードバックするのが、アシミレーションの一般的なやり方です。
(引用元:日本の人事部

私僕自身がメンバーにどう思われているのか。僕がやろうとしていることが、メンバーと合っているのか。まずはここの解像度を上げに動きました。
ここで認識齟齬があると、どんなアクションを起こそうとも、メンバーと僕との溝が知らぬ間にどんどん開いていってしまうと考え、それはどうしても避けたかったのです。

部長のファシリテーションの協力のもと、ワクワクドキドキで行っていただきました。
普段から仲良く色々な話をしているとはいえ、あらためてみんなで僕自身のことを話されるという経験は初めてのことだったので、好奇心と少しの不安がいりまじってました(笑)。
幸い、ネガティブな話はあまりなく、僕が意識できてなかった中でのメンバーとのギャップが見えたり僕への要望がわかったりと、とても有意義なワークになりました。

この結果は、今でも見直すことで初心に立ち返ることに役立っていますし、今後も定期的に行ってアップデートをしていきたいとも考えています。

このアシミレーションというワークですが、もし、マネージャーやリーダーになったばかりの方がいらっしゃったらおすすめのワークです。

事例2:チームメッセージの制作

メンバーと僕との相互理解が深まったところで、次はチーム全体の方針を決めていきました。

Web室のデザインチームとして目指すべき状態、あるべき姿とは何か。それを実現するためにはどういうスタンスや意識が大事なのか。そういったことをメンバー全員で言語化していくことに取り組みました。

チームで掲げたいと思えるメッセージをメンバー自らの言葉で生み出すことで、それぞれが当事者として「チームの方針=自分の方針」という意識を持ってもらえればと思いました。

デザインチームとして目指すべき姿とその実現に必要な要素を洗い出し、その要素に対して、できていることとできていないことの認識を、メンバー同士で合わせていくところから議論をはじめていきました。

その議論をすすめるにあたって意識してほしいこととして、「今いるメンバー全員がコアメンバーと思って欲しい」ということを伝えました。そして、ひとりひとりがチームのコアメンバーとして発言・提案してもらえるような進行を心がけました。

メンバーそれぞれが大事にしていること。課題に感じていること。実現したいこと。デザイナーとしてデザインチームとしてどうしていきたいかなど、メンバー全員の想いを出来る限り正直に自分の言葉で出してもらい、みんなでメッセージを整形していきました。

メンバー自身が誇りと愛着を持てるメッセージにしたかったので、言葉選び、覚えやすく言いやすいフレーズなど、意味はもちろんのことメッセージの表現というところにも時間をかけました。

できる限りの拡散と収束を繰り返し、時には意見が停滞してしまったりしながらも、最後はチーム内コンペという形式でひとつのメッセージに落とし込めました。
(こちらのメッセージは、機を見て公開できればとも考えています。今はまだ非公開とさせてください。)

全メンバーから出てきたメッセージということもあり、メンバー内で愛着をもって使っていきたいと思えるメッセージになったかと思います。

せっかく完成したチームメッセージなので、日常的にどんどん使っていき、染み込ませて血肉化していきたいと考えています。
その取り組みの一環として、メッセージをテーマにしたグラフィックをメンバーごとで制作してもらい、そのグラフィックを大画面モニターに写しながらのチームMTGを実施しています。
デザインはメンバーに完全にお任せ。自由にグラフィックデザインを楽しんでもらう機会にしてもらえたらと考えています。

実現したいチーム像

今、僕たちのチームは、洗い出したひとつひとつに課題に対して打ち手を考え、解決に向けて動き出している状況です。
その解決を通して、目指しているチーム像として2つのチーム像を考えています。それが、以下になります。

  • 学びをつづけ常に成長しつづけるデザインチーム
  • デザイン水準を自分たちで引き上げていけるデザインチーム

この2つのチーム像について説明させていただきます。

まず、実現させたいのが、「学びをつづけ常に成長しつづけるデザインチーム」になるということ。
そのためには失敗をおそれないチャレンジ精神が大切。
そこで必要なことは当事者意識。

「自分で決めたことに対しての失敗は成長につながる。他人に決められたことに対しての失敗は言い訳になる。」という僕の好きな言葉があります。これは、自分で決めていくということの大切さをよく捉えているかと思います。

極端なエピソードですが、シリコンバレーでは失敗をしたらパーティーを開いて賞賛する文化があるという話を聞いたことがあります。
「失敗したじゃん!やったね!」となってしまい、失敗したときの悔しさが無くなってしまうと失敗の価値が無くなってしまいそうなので、実態がどうなっているか気になりますが(笑)。
パーティを開くとまでいかなくとも、少なくとも失敗を活かしていくという気概のもと、挑戦を続けていきたいと思えるチームになっていこうと思います。

そして、成長していく過程で実現していきたいもう一つのチーム像が、「デザイン水準を自分たちで引き上げていけるデザインチーム」でありたいということ。
インハウスのデザインチームとして、私たちがWeb室のデザイン品質の責務を担っていることを自覚し、自らの意思で向上させていくことが必須だと考えています。

それは、表層的な見せ方だけではなく、達成すべき目的、解決すべき課題に対してデザインできているか。ということを含めてです。
表層的な見せ方を軽視しているわけではないです。目的達成のためのロジックと見せ方をセットで高次でデザインされている状態を目指しています。

そのために、自身のスキルアップはもちろんですが、チームとしては品質向上のための建設的なフィードバックをし合える文化醸成を強化しています。
デザインの品質は「フィードバックの質」で決まるといっても過言ではありません。
フィードバックは、やり方と受け入れ方の双方向のトレーニングがマストなので、ここをしっかり伸ばしていきたいと考えています。

僕たちWeb室のメンバーは、担当プロダクトにおいて業界No.1を本気で目指しています。No.1になる一因としてデザインを機能させていくこと。デザインが競争力となり得る状態を目指して成長をしていければと考えています。

さいごに

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

世の中的にデザインの役割が広がっていますが、それは私たちWeb室にとっても変わりません。
組織の拡充に伴い、これから私たちが直面していくであろう多くの挑戦や変化にそなえて、より最善なデザインが求められてくるでしょう。
また、Web室に関わる様々なデザインにアプローチして、Web室をもっともっと良くしていきたいという想いも強いです。

これらの実現のためにも一枚岩になることが必須だと僕は考えています。
簡単なことではないですが、デザインひいてはクリエイティブを心から愛し楽しめる今のチームメンバーであれば実現できると信じています。

みんなのデザインの力でWeb室の組織やプロダクトをより良くしていければ本望です。


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

919.jp

クイックのエンジニアチームが組織づくりとして2023年に挑戦する5つの事

こんにちは。
エンジニアチームのマネージャー、桃原です。

私たちがエンジニアチームとしてどのような課題に挑戦していくか公開します。

エンジニアチームではプロダクト開発を促進する為、 各プロダクトを横断した技術課題の解決とエンジニア一人ひとりが力を発揮できる環境整備や能力向上の取り組みをおこなっていきます。

私たちが考える理想にはまだ遠く、私たちが持つ課題やエンジニア組織づくりに興味をもたれた方、ぜひお話したいです。力を貸してください。

テクノロジーの力ですべての人が目を輝かせて生きる世界を一緒に実現しましょう。
クイック Web事業企画開発室の中途採用サイト

目次

  1. セキュリティ強化
  2. システムの運用効率化に向けた状態可視化と権限委譲
  3. 開発チームのパフォーマンス改善
  4. エンジニアチームの組織力強化
  5. エンジニアチームの挑戦する文化を社外に向けて発信していく

1. セキュリティ強化

なぜやるのか?

  • プロダクトを安心して使ってもらう
  • 情報漏えいのリスクを排除
  • エンジニアの開発速度向上

環境面において常に最新のバージョンに追従できる状態にし、
言語やフレームワーク、ライブラリのセキュリティアップデートが当てられる状態にします。
OSやミドルウェアについても同様に、環境を素早く最新化するためIaC化やコンテナ化を促進します。

ここ数年で正社員以外のビジネスパートナーさんが増え、権限の範囲や判断の軸が複数存在して複雑化しており、改めて課題を整理しゼロトラストの環境構築と、権限と裁量の持てる範囲を見直します。

権限の問題で正社員のみが行っていた業務をビジネスパートナーさんも一緒に進められる環境を作る事で、新規実装、既存の改修、リファクタリング、その他改善活動など、同時に広く手が回せるようになり、開発速度向上を期待しています。

2. システムの運用効率化に向けた状態可視化と権限移譲

なぜやるのか?

  • プロダクト開発速度の向上
  • プロダクト品質の均一化に向けた取組み(メトリクスの定義)

もともと社内にはインフラを扱えるソフトウェアエンジニアが少なかった事もあり、プロダクト開発チームのソフトウェアエンジニアとインフラチームのインフラエンジニアが協働でインフラ環境を構築してきました。

インフラ環境を構築できるソフトウェアエンジニアが増えて来た事もあり、インフラチームが持つ権限をプロダクト開発チームのソフトウェアエンジニアへ権限を移譲する事を進めます。

インフラチームで多くの権限を管理する事はプロダクト数が少ない間は問題になりませんでしたが、プロダクトも増え、ソフトウェアエンジニアが行える作業についてもインフラチームの作業待ちとなり、インフラチームがボトルネックになる事が発生しています。

また、インフラチームが細かな作業を行う事で社内横断的な動きに注力できず、 新たな取組や現行作業の改善に時間が割けない課題がありました。

権限移譲を進める事で新たな取組や改善の時間を作り、インフラチームが組織横断的な課題解決や、コンテナ化、IaC化の推進をより早く進める事が期待できます。

3. 開発チームのパフォーマンス改善

なぜやるのか?

  • 既存事業のプロダクトを伸ばしつつ、新規事業の立ち上げを行うフェーズである
  • より素早くプロダクトを開発しマーケットへ価値を届ける必要がある

各プロダクトチームがそれぞれのチームで意思決定し開発を行っていた事で情報のサイロ化がおき、プロダクトによって技術スタックやアーキテクチャ、自動テストの導入有無やCI/CDの運用が異なる状況でした。

エンジニアがプロダクト開発チームを異動した時に、利用技術のキャッチアップコストの大きさや、開発チームのナレッジが共有できない課題もあります。

これら課題がある中でプロダクト開発チームのパフォーマンス改善を行うため、今まで定性で把握していた課題作成からデプロイまでのリードタイムやデプロイ実施数、各業務におけるコミュニケーションコストなど、あらゆる視点での計測が必要です。

エンジニアチームが組織横断的な動きとして、プロダクト開発チームのナレッジを共有することや、パフォーマンスを計測するための定義やツール導入など、パフォーマンス改善につながるボトルネックを洗い出し、改善を進めます。

4. エンジニアチームの組織力強化

なぜやるのか?

  • 内製の強みをプロダクト開発に活かす
  • マーケットを創造するプロダクト開発の具現化力を身につける
  • エンジニアのキャリアを描き自身の強みを明確にする

私たちはシステム内製化へと舵を切り、社内のエンジニアが自社プロダクト開発を推進しています。
内製化する事で事業ドメインの知識をベースに他職種のプランナーやマーケター、デザイナー、ビジネス職の方々とスムーズに会話を行い早い意思決定と実装を行っています。

開発する中で得た知識経験を組織全体に共有し、次に繋げて継続的な成果へつなげるアクションを私たちのカルチャーにしたいと考えています。

最近の新たなチャレンジとして、業務時間の中で毎月16時間を使って、個人で伸ばしたい分野について手を動かす時間を設けています。

目的は手を動かし具現化力を高めるためで、業務に紐付いていない事も許容しています。
ソフトウェアエンジニアがAWSを学んだり、インフラエンジニアがLaravelやJSを学んだりする動きもあります。

エンジニアとしてフロントエンドやバックエンド、インフラ、プロダクトマネジメントなど、能力やスキルを高めて様々なキャリアを描く事が可能です。

さらに、定期的に発表会を設けて、各自がアウトプットした内容をエンジニアだけでなく他職種の方へ向けて成果発表する場があります。
インプットからアウトプットまで一連を通して具現化力を高める取り組みです。

5. エンジニアチームの挑戦を社外に向けて発信していく

なぜやるのか?

  • アウトプットを通して個、チームの成長を促す
  • 日常的にアウトプットを行うカルチャーの醸成
  • 課題解決へ興味を持つ方へ私たちの考えや課題を届け、一緒に事業を伸ばしていきたい

私たちは、toC向けプロダクト開発、社内基幹システム開発、 新規プロダクト開発と3種類のシステム開発を行っています。

toC向けプロダクトであればリリース後に目に触れる機会もありますが、社内システムや新規プロダクト開発においては、どんなに良い取り組みやプロダクトになっても、社外の方の目に触れる機会がありません。

新規機能開発、パフォーマンス改善、リファクタリングなど、それらをなぜやるのか、どうしたか、何に時間を要したかをブログで発信する事で、私たちの課題や取組み、悩みを多くの方に知ってもらえると考えています。

アウトプットする事を私たちが一番楽しみ、アウトプットしたくなるチャレンジに溢れるエンジニア組織にするため、新たな取組として本ブログも一つの手段としてリブートした理由になります。

さいごに

2023年の取組みとしましたが、今年はまだ約2ヶ月もありますYO!

5つの取組みについて定期的に結果をブログでお伝えしていきます。

個人的な挑戦としては一人アドベントカレンダーを実施します!!!


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

919.jp

ブログ運用見直しで目的も見直したお話

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

クイックとして約6ヶ月ぶりの記事投稿なのですが、その期間でブログの目的や運用の見直しをしていました。

どのように運用を変えたか等、いろいろと書けることはあるのですが、今回は一番大事な「ブログの目的」に焦点を当てて書いていきます!

運用見直しの背景

本ブログは採用(社外広報)を目的として、2015年6月から運用しています。

投稿頻度は週1が適切だろうということで、週1でブログ投稿ができるように、執筆順は当番制で決めていましたが、

  • どのようなコンテンツを執筆するか
  • 執筆の工数確保
  • 記事のレビュー

等を組織的に動いておらず、各メンバーにそれらのタスク管理をお任せしてブログ運用を行っていました。

その結果、ブログ記事が投稿されない週がある等の問題があり、当初の目的に対する効果も薄いのではと考え、「ブログの運用を見直して、再始動しよう!」ということになりました。

運用見直しの体制

私が所属するWeb事業企画開発室(Web室)には、エンジニアに限らず多種多様な職種の方が在籍していますが、運用見直し直前まで執筆していた職種は「デザイナー」「エンジニア」ということで、

  • デザイナーチームマネージャー
  • エンジニアチームマネージャー
  • 筆者

という3名でブログ運用チームとして、ブログ運用の見直しを進行してきました。

運用見直し前の問題

運用見直し前の問題を洗い出したところ、

  • 目的が浸透していない
  • ブログを執筆するモチベーションが上がらない
  • ブログ運用体制ができていない

の3点を優先的に解決することが決まりました。

「モチベーションが上がらない」について、具体例を出すと、

  • 評価に直接的に影響する業務ではないため、優先度が上がらない
  • 担当する投稿日の1週間前に執筆リマインドがくるけど、書くテーマを考えるところからのメンバーもいて、精神的にも時間的にもきつい

というものがあり、ブログ自体がメンバー個人としてメリットがあるものではありませんでした。

ブログ運用の目的

問題である「目的が浸透していない」について考えたときに、「そもそもブログ投稿の目的は「採用広報」でいいのか?」ということで、目的自体を再考することになりました。

再考しようとしていた時期にちょうど、「採用のために技術ブログを書くわけじゃない。」であったり、 メルカリさんの「技術広報の役割を定義してみた 2022年春」のスライドが発信されていたため、それらの情報を参考にしながら、 我々がブログ運用をする目的を考えていきました。発信ありがとうございました!

その結果、我々がブログ運用をする目的は下記2点となりました。

個人のスキルアップ

ブログを執筆することは、具体化・具現化プロセスを整理する機会になります。

ブログは、読んでもらうことで内容を理解してもらう、比較的一方的なコミュニケーションツールです。*1

よって、執筆者自身が執筆することを体系的に理解をする必要があり、理解を促進することで、執筆した内容の再現性が高まると思っています。

体系化した内容を読者が理解しやすいように、どう言語化するかを考えてアウトプットする必要があるため、言語化力を鍛えるトレーニングにもなります。

執筆した記事は投稿前にレビュー機会をもうけているため、アウトプットに対するフィードバックを他職種も含めたメンバーからもらうことができ、それが執筆者のインプットにつながり、より質の良いアウトプットにつながる、成長の好循環があると考えています。

話が少しずれるのですが、「成長」は現在の我々Web室にとって大事なキーワードの1つです。

Web室の評価制度は2021年にフルリニューアルされ、 以前の評価制度と比較すると「個人の成長」を促すように設計されています。

「個人が成長」することで、組織として継続的な「成果」の向上が期待できると考えているからです。

業績などいろいろな要素を省いて簡素化した説明になりますが、 個人としては成長し成果が上がることで、結果として評価アップにつながります。

執筆するメンバーには成長する取組みの一つとしてブログを活用してもらうことで、問題であった「モチベーションが上がらない」を解決する一因になるかもしれません。

よって、ブログが「個人の成長」を促進する一環になればと思っています。

社外広報

こちらは以前からある目的ですが、残している理由を書いていきます。

「個人のスキルアップ」という目的だけであれば、社外に公開せず社内に閉じたやり方でも可能ですが、あえて社外に内容を公開する理由は、「ブログがないと採用市場で不利になる」からです。

例えば、ブログがないことにより、

  • 就活時の転職候補から外れる可能性が上がる。
  • 一番現場のリアルが知れる媒体がないため、ミスマッチが発生する可能性がある。または魅力づけができない。

などのデメリットがあります。

ここ数年ずっと言われていますが、年々エンジニアやデザイナーの採用は難しくなってきています。

その中で転職候補としてよく上がってくる企業は、社内外問わずアウトプット量と質ともにレベルが高いところが多い印象です。

findy-code.io ※参考事例が掲載されている資料(要DL)

我々Web室の社外アウトプットの量・質ともにまだまだ発展途上のため、我々の考えや課題を発信する一媒体としてブログを運用し、社外アウトプットの量・質を上げ、結果として求職者に認知してもらうきっかけの増加、転職候補にするか判断する良い材料の提供ができればと思います。

まとめ

ということで、これからのブログは下記2点を目的として活動を進めていきます!

ブログ執筆していただくみなさん、宜しくお願いします!


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

919.jp

*1:コメントで対話することは可能ですが

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

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

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

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