このエントリーをはてなブックマークに追加

はじめに

こんにちは。CTOの 金本 です。

Nagoya.php とは、名古屋で隔月を目処に開催しているPHPの勉強会です。

もともと有志の個人によって運営されていた勉強会でしたが、立ち上げメンバーが次々にカルテットに入社した結果、ここ数年はなんとなくカルテット主催のイベントという感じになっています(笑)

2019/10/31(水)に 通算18回目のNagoya.php を弊社セミナールームにて開催しましたので、その様子を簡単にレポートしたいと思います :elephant: :sparkles:

Nagoya.phpの特徴

さて、Nagoya.phpは、よくあるLT中心の勉強会ではなく、「実際に手を動かしてプログラミング問題を解いてみる」 という取り組み(通称「どう書く」)を中心にした内容になっています。

問題は主に、@Nabetani 氏が過去に開催されていた「横浜へなちょこプログラミング勉強会」という勉強会で 出題されたもの を拝借しています :pray:

ただ、最近は初心者の方の参加も増えてきたので、ある程度慣れている人には本格的なプログラミング問題にチャレンジしていただきつつ、初心者の方には別途初心者の方向けの ちょっとした課題 をご用意して、参加者の皆さんにご自身のレベルに合わせて取り組む課題を選んでいただく形をとっています。

自己紹介タイム

予定どおり18:30に開場、19:00に開始。

時間も限られているので一人15秒ぐらいで全員に簡単な自己紹介をしていただきました。

プログラミング問題タイム

自己紹介が済んだら、早速プログラミング問題タイムです。(制限時間は45分ほど)

今回使わせていただいた問題は、Bit Tetris というものでした。

制限時間が45分程度と短いので、いつも問題の選定に本当に苦労しているんですが、今回もやっぱり少し難しかったようで、ほとんどの方が時間内に最後までは解けなかったようです :bow:

とは言え、ここ数回はゼロ人でしたが今回は1人完答まで行ってくれました!弊社社員の しもP !グッジョブ! :+1:

答え合わせタイム

20:00からは、プログラミング問題の答え合わせタイムです。

「私はこんなふうに解きました」とか「こんなふうに解こうと思ったけど間に合いませんでした」とかを前に出て発表していただく時間です。

ちなみに、答えあわせタイムやLTタイムに前に出て発表してくださった方にはもれなく 条件分岐禁止ギプス というノベルティグッズ(シリコン制のリストバンド)を差し上げていますので、次回以降参加される方はぜひ発表にチャレンジしてみてください!

Q&Aタイム

今回は新しい試みとして、sli.do というサービスを使って「その場で匿名での質問を集めて、みんなで答える」というコーナーをやってみました。

勉強会開始時に、「プログラミング問題タイムの間にでもドシドシ質問を投げておいてください〜」という案内をしたんですが、皆さん問題を解くのに夢中でほとんど質問してくれませんでした(笑)

答え合わせタイム開始時点で再度「何卒質問をください・・・!」というお願いをして、無事いくつかの質問をいただくことが出来ました :joy:

結果的にはある程度有益な情報交換の場が提供できたんじゃないかと思います :+1: (思いたいです)

LTタイム

最後はLTタイムです。今回は事前に1本だけお申し出をいただいていました。

内容は、LTというか、2019年12月1日に東京で開催される PHPカンファレンス 2019 のセッション 「コミュニティアップデート powered by GMOインターネット」 に誰かNagoya.php代表として出演しませんか?という案内でした(笑)

協議の結果、私が行かせていただくことになりました :muscle: PHPカンファレンスに参加される予定の方は、ぜひ見に来ていただけると嬉しいです!

おわりに

というわけで、今回も隔月開催という約束を守って2ヶ月ぶりで開催することができました :muscle:

参加者の皆さんの解答例や当日の様子がTwitterのハッシュタグ #nagoyaphp で見られたりもしますので、興味のある方は覗いてみてください :smile:

引き続き隔月開催を目標に頑張って運営していこうと思っています(次回は2019年12月開催予定)ので、名古屋近郊にお住まいのPHPerさんはぜひ気軽に遊びに来ていただけると嬉しいです!


このエントリーをはてなブックマークに追加

カルテットコミュニケーションズ開発部に所属しているWebデザイナーの粟屋です。プロフェッショナルなベテランエンジニア集団であるカルテット開発部にジョインしてから早くも1年以上経ちました。

当記事では、私がWebデザイナーとしてどんな役割を担っていて、これから何に力を入れていきたいと考えているのか、仕事紹介を兼ねつつご紹介します。

そもそもLisketとは?

弊社の主要事業はリスティング広告運用代行業です。この業界では、広告運用やお客様への報告といった日々の業務の中で膨大な単純作業があります。それを圧倒的に削減し、より多くの時間を知的生産活動に割くべく、自社で「Lisket」を開発し活用しています。

それにより、弊社の広告取扱高は例年大きく伸びつつ、残業のほとんどない働きやすい環境も実現しています。

Lisketは、様々な機能(ツール)の集合体です。
中でも強みは、Google広告・Yahoo!広告といった様々な広告媒体のAPIから、実際の広告配信成果や予算消化状況を取得し活用する機能です。取得したデータを案件ごとにまとめて1画面でチェックしたり、Excelレポートとして自動で書き出したり、さらにはお客様へメール送信し直接ご確認いただくこともできます。

広告媒体のAPIは種類が膨大で仕様変更も激しく、さらに一部のAPIは正規の広告代理店しかアクセスできないなど、かなりチャレンジングな領域です。そこへ真正面から立ち向かい、チーム一丸となって、運用者にとって本当に価値のあるツールを日々追求しています。

デザイナーとしての仕事と役割

このように、Lisketは正しく活用すれば大幅な業務効率化が図れるツールであり、実際多くのお客様にもご活用いただいています。

しかしながら、初めて利用される社外のお客様に自力でご活用いただくには少々ハードルがあり、特にUIに多くの改善余地がある状態です。

  • 機能によって操作感にばらつきがある
  • 初見ではわかりにくい操作手順やUIパーツがある
  • カスタマーサポートの助けを借りずに適切に設定完了するのが難しいツールがある

こうした課題への解決案を提示し、チームの同意を得ながら実装を進めるのが主な仕事です。

また、開発をより円滑に進める役割も担っています。
私(初のデザイナー)が入社する前までは、コンサル部要望を開発部でまず実装し、使ってもらってフィードバックを得てまた直す…という開発フローでした。それを、まずデザイナーが迅速にプロトタイプをつくり、それをベースにコンサル部・開発部一緒に正しいあり方を議論し、認識を揃えてから実装に移る…というフローへの転換も図ってきました。

さてここからは、実際に行った業務例をいくつか簡単に紹介します。

Lisketのわかりにくい文言やレイアウトを改善

一般的にわかりにくい・使いにくいと思われる箇所、かつ実装も容易なUIを中心に改善してきました。細部の調整がほとんどでしたが、次の2ツールに関しては全体のUIを刷新しています。
※改善の意図やプロセスは今回省略します。また、改善前のキャプチャ画像を用意できなかったので、改善後の画面だけ掲載しています。

手動レポート作成ツール。

Googleアナリティクスレポート作成ツールと、そのランディングページ。

LisketのUIガイドライン策定の検討

Bootstrapの採用により、見た目はある程度の統一感が保たれています。
しかしながら、文言やボタンの位置といった細かいUIルールにバラツキがあり、「混乱する」「使いにくい」といったフィードバックもありました。それを解消するために、UIガイドラインの策定と導入を試みていた時期があります。

そこで、esaにまとめたり、自前でnpm scriptsを活用した静的サイトリポジトリを用意したりといろいろ試していました。Storybookの活用なども検討しましたが内部的な事情で進んでおらず、まだまだ試行錯誤中です。

esa
自前の静的サイト

Lisket ランディングページなど関連サイトのリニューアル

ランディングページや、サポートサイトの一部ページのデザイン/コーディングも担当しました。詳しくはこちらの記事にまとめています。
Adobe XDを活用して自社開発サービスのLPをスピーディにリニューアルした | QUARTETCOM TECH BLOG

社内業務や制作業務の補助

自社の採用活動や、他部署のクライアント案件で必要となるバナーやサイト制作を任されることもあります。

自社用バナーの一例。

制作系の業務は、弊社では基本的に外部パートナー様にご協力をお願いしています。しかしどうしても急ぎで成果物が必要な状況のとき、稀に、社内(私)で迅速に対応して提出・納品することがあります。
本来の業務ではないのですが、そこで活躍した結果、開発部外のメンバーにもデザイナーとしての存在を認めていただく絶好の機会となり、Lisketに関する相談や提案のしやすい信頼関係の一助ともなっています。

感じた課題と目指していること

この1年を通じて、表層的なUIの改修だけでは本当の「使いやすさ」を実現できないことを痛感してきました。

まず、提案のために欠かせない知識があります。リスティング広告運用の全般知識、開発に必要な最低限の知識、そしてLisket独自の概念です。これらに乏しい状態でUIを考え提案しても、運用者にとって実際には使いづらいものだったり、実装が困難で実現しなかったりすることが往々にありました。
時間がかかりましたが、コンサル部や開発部のみなさんの協力もいただきながら、そうした知識がようやく身についてきた段階です。

Lisketは、今まで「社外ユーザーにもカルテット流の広告運用で業務の効率化をしてもらおう!」というニュアンスが強く、自社の運用者にとって便利なものを追求してきました。しかし社外ユーザーは目的も知識量も運用規模も異なっていて、そうした前提のズレがUIの問題点として表面化してきた側面があると考えています。
そこで、進行中の新しい構想や機能開発などでは、まず最初にターゲットの定義から考え決めるよう開発フローの転換にも取り組んでいます。

そうした活動の中心となりながら、より踏み込んだUIやUX改善の提案を続け、Lisketを社外のユーザーにとっても本当に価値のあるツールにすることがデザイナーとしてのミッションです。

こんな方を募集中です!

デザイナーが私一人しかいないこともあり、ある程度デザイン・コーディングスキルを既にお持ちの方しか受け入れられません…。

いちデザイナーのエゴではなく、実際に使う運用者にとって本当に良いものをつくる。そのための方法を模索し、チームに提案し、一緒に実践していけるようなデザイナーを求めています。
開発部内においては、git/GitHubSlack、esaと言ったツールを使いながらエンジニアと密にコミュニケーションし、どんな機能・画面を実装していくのかリードして決めていくポジションとなります。

また、今はフロントエンドエンジニアだけど、その知識・技術を活かしながらデザイナーとしてサービス価値の最大化に取り組みたい!活躍したい!…という方にも絶好の環境かもしれません。
自社サービス開発のデザインに携わりたい、かつサイト制作もできちゃう、みたいな方も大変心強いです。

弊社では、Slackにゲストアカウントでご参加いただき、直接開発部メンバーに質問できる場を設けています。応募で迷われている方がいらっしゃれば、ぜひこちらからご相談ください!
👉 Slackゲスト招待の申し込みはこちら


このエントリーをはてなブックマークに追加

先日、Frontend Conference 2019に参加したのでそのレポートを記事にしました。

私自身も本編最後のLightning Talkで発表させていただきました。

概要

公式サイト

Twitter #frontkansai

2019/11/02 グランフロント大阪にて

  • 10:30〜17:50(本編)
  • 18:30(懇親会)

参考情報

  • wifiはプレミアムチケット購入者のみ提供
  • 飲食可
  • 休憩ブースあり
  • スポンサーブースにて飛び込み発表のアンカンファレンス
  • Angular,React,Vue.jsのハンズオン

参加セッション

モダンJavaScript再入門

尾上 洋介さん

JavaScriptのモダンな書き方についてコードを交えての解説

実例と解説がとても丁寧だった。また「モダンJavaScriptを使って良いか」という補足ページがとても良いと思う。JavaScript = 最新のECMAScriptが使える、だと思ってどんどん新しいシンタックスを使ってしまうと特定のブラウザで考慮不足の例外が発生する。快適な開発環境のためにモダンを追求するのではなくてアプリを使うユーザー側の環境も考慮しなきゃいけないよねっていう視点は、当たり前のようでいてまだ暗黙の共通認識までは至っていないと思うので、そのフォローも含めてのモダンJavaScriptの内容紹介だった事が素晴らしいと思った。

ディレクトリ構成ベストプラクティス 〜 Angularアプリを作り続けてわかったこと

okunokentaroさん

7年の実務から見出したディレクトリ構成のベストプラクティスの紹介

この方のセッションを聴くのは2回目になる。話の展開のうまさ、テンポの良さ、紹介する内容の裏側にある説得力、どれを取っても抜群でとにかく愚直に「すごい」と思う。 発表内容で一番心に残っているのは「組織にマッチした答えは判断力を身につける事で磨いて行く、このセッションでのベストプラクティスも組織のベストプラクティスとは限らないが取り入れる事でひとつの判断材料となる」という部分(…そんなニュアンスだったと記憶)。良いディレクトリ構成は良いアプリケーションである、本当にその通りで、次のプロジェクトからすぐに使える実例が聞けて良かった。

レガシーなフロントエンドをリプレイスする

小島大基さん

AngularJSとVue.jsが共存するプロダクトをどのように改善していったのか、技術選定などの話

コンポーネントをテンプレートのレンダリング専用と捉えたところ、いつかコードを捨てる事を意識する、等々、次を見据えてのリプレイス戦略である事がすごいと思った。複雑な画面を後回しにした判断やテストをスキップする勇気もとても参考になった。質疑応答にもあったが、複数人の開発者の中でどうやって話し合って指針をまとめていったのか、その突っ込んだやり取りも次回聞いてみたいと思う。

高齢者でも使えるプロダクトUIの挑戦

神保 嘉秀さん

高齢者向けの問診アプリのUIの難しさと試行錯誤の紹介

場所移動のタイミングを逃してセッションは聴けなかったのでスライドだけ見た。エンジニアが当たり前のように選ぶUIが一部のユーザーにとっては使いこなせないものである事、そしてどんな理由で使いこなせないのか、説明に説得力がある。相当苦労してUIを模索したんだろうと思う。開発者目線でなくアプリを使うユーザー目線に落とし込んでUIを改善していく過程にアプリ開発の原点を見た気がする。

私たちはなぜ SPA で開発するのか

花谷 拓磨さん

何気なく使っているSPAについて本当に必要なのかを再考する話

UX要件とDX要件の視点が新しかった。技術選定がエンジニアのエゴになっていないか、という問いかけには正直にそうなっていたかもなあと反省。品質・速度ではなく、プロダクトとアーキテクチャの規模がマッチしているかを見極める事、アンダーもオーバーも等しく毒になる事、その判断は難しいが目新しいモダンな手法に流されるのではなく、アプリの目的に沿った視点を持つことが大事なんだと教えられた。

フロントエンドエンジニアのためのセキュリティ対策

平野 昌士さん

XSSの具体的な内容と対策例

普段フレームワークに乗っかって開発しているとセキュリティの観点がフレームワーク任せになってしまうので、知らなきゃいけないよねという再認識になった。知識豊富でキャッチアップもたくさんされた上での具体的で正確な対策を紹介していたので、非常にためになる。発表で勧めていた書籍は早速購入した。

LT

脊髄反射でプロダクト作ることの学びとススメ

@scrpgil さん

ひらめきとスピード感あふれる自身で開発したツール紹介

とても面白かったし、開発に使ったツールを紹介してくれたのが嬉しい。真似して小さいツール作ってみたい!という気持ちになった。

Angularはいいぞ!フレームワークにAngularを採用した理由

@ringtail003(自分)

Angularのココがいい!話

エンジニアの方に囲まれて発表するのは2回目の経験。 「大阪という場所柄、用意したポイントで笑ってくれるし登壇者を死んだ魚の目で見ない」という前評判の通り、空気が柔らかかった。後日TwitterとかでAngularちょっと使ってみようかな、なんて感想を言ってくれた方もいて本当に嬉しかった。

TypeScriptでHTTPリクエストを型安全にする方法

@aspidajs さん

自身で開発したaspidaで型安全を実現しJSカーストに食らいつく話

めちゃくちゃ話が楽しくて、会場が笑いの渦だった。この方の登場でLTらしいほぐれた雰囲気に一気に加速した。面白さはさておき、内容はTypeScriptの型安全を披露するデモで、分かりやすさが抜群だった。5分で簡単に説明をしているが、自身でのパッケージ開発に苦戦もしただろうし、純粋にすごいなと思った。

コンポーネント管理の失敗と今後のやっていき

@yahooshiken さん

UIコンポーネントの失敗談とその打開策の話

StoryBookの失敗例はほぼ聞いた事がなかったので、やはりどこにでも落とし穴はあるんだと参考になった。コンポーネント名が共通認識されているか?にはまさに認識していなかったと自覚。LT駆動開発で決意を固めてプロジェクトに取り組むそうで、この心意気に共感した。

Automatic Test for Frontend Side

(スライド非公開のようです)

@woosyume さん

WEBサイトのe2eテストにAIを取り入れて自動化する話

登壇後に少しお話させてもらった。Seleniumは2年くらい前にe2eテストで使った事があるが、その後も進化を遂げていたのを知らなかった。今やWebDriverがブラウザ標準化されてSelenium勉強会も開催されていますよとの事。スライド中で見せてくれた動画でAIが人間と同じように購入ボタンを押してショッピングカートを覗くのが、人力に変わるすごい技術だなと感心した。日本出身ではないという事で「みなさん日本語が上手で…」と恐縮されていたが、聞き取れない箇所もなかったし、とても良い発表だったと思う。

まとめ

発表全体を通して「プロダクトの本来の目的を見据えた技術選定のあり方」という傾向だったように思います。今使っている技術が何をもたらしてくれるのか、そのアーキテクチャは本当に必要なのか、どんな失敗談があるのか、等々…。普段、ネットでスライド単体を見た時は技術名や結果に目が行きがちでそれ以外を補足情報として見てしまうのですが、会場で登壇者の生の声を聞くと全くの逆で「なぜそう考えたのか、なぜそれを選んだのか」を主体として見る事ができます。そこに共感するポイントがあれば自分も取り入れる事ができるし、今悩んでいる技術選定の判断材料にもなる、それがカンファレンス会場に足を運ぶ事の大きな魅力だと思います。

実際、今後新規開発していく上でフロントエンドにどういった設計手法を取り入れたらいいのか悩んでいたので、ディレクトリ構成やSPAの話、コードを捨てる事を前提にする考え方がピンポイントで心に刺さりました。

事前にTwitterやスライドの内容から「この人はすごい…ベテランでドライな人に違いない」と一方的に勝手なイメージを持っていた方もいるのですが、実際に発表を聞いてみるとちょっとはにかんだ表情が見えたりイメージとは真逆の面白い方だったり、親近感を感じられるのもいいですね。LT記念にTシャツいただいたたり、ng-kyotoブースでステッカーもゲットできたので「ヨーシまた仕事頑張ろう!またカンファレンスに来よう!」ってテンションがぐぐーんと上がりました。

また、会場のスタッフの方々に感謝を述べたいと思います。会場内、常に見えるところにスタッフ数名の方が待機されていて「何か困った事はありますか?」「この列はXXXの順番待ちです」等々声をかけていただきました。大きなイベントですのでいろいろなフィードバックがあるかと思いますが、私は感謝しかないです。開会から閉会までほぼ丸一日、気を配って声を掛け続けて帰りはクタクタだったと思います。みなさんの苦労に甘えて、フロントエンドカンファレンス2019、本当に楽しませていただきました。ありがとうございました!