Tribal Media House Engineering Blog

Made in Tribal Media House !!!

Google App EngineとManaged Serviceだけでプロダクトのインフラを構成してみた

はじめに

初めまして、トライバルメディア ハウスで新規プロダクトのテックリードをしている松田と申します。今回新規プロダクト用にGoogle Cloud Platform(以下、GCP)でインフラ構成を組んでみたので、その一部を紹介します。

目次

本記事を書いた理由

弊社トライバルメディアハウスは様々な事業ドメインで新規プロダクト開発しています。その過程でインフラ設計やアーキテクチャ設計をしており、それらの取り組みや過程を外部の方にも知っていただきたく、その一部である1プロダクトのインフラ選定について本記事でまとめてみました。

構成について

下記の構成で組んでみました。各サービスの詳細が気になる方は記事の最後に簡単な説明やリンクを貼っておきましたのでそちらを参照ください。

簡易構成図

f:id:tribalmediahouse:20200124155538j:plain

Google App Engine(以下、App Engine)を選択した4つの理由

StorageやDatabaseはそもそもあまり選択肢はないと思うので、今回PaaSであるApp Engine(スタンダード環境)を選んだ経緯と理由を書いていきます。

1. サーバの運用に稼働がかからない

新規事業開発においてはユーザ体験などをいち早く検証することが大切であり、それが開発の成果にもつながります。

サーバの監視や運用などにエンジニアの稼働が取られるのは事業のフェーズ上あまり価値にならず、できる限り運用不要な構成にしたいと考えました。その観点でPaaSであるApp Engineは非常に良いと思いました。

加えて、新規事業が複数あるため、専任のインフラ担当者をアサインしづいという状況の中で、App Engineであればインフラの知識や経験がなくても環境構築が可能です。

2. 自動でスケールアウトする

App Engineは、自動スケーリングを指定した場合、受信リクエストに応じたインスタンスのスケーリングおよびロードバランシングを実施してくれます。

また下記のような状況で今回インフラ選定をする必要がありました。

  • 初期からインフラのスケーラビリティを正しく設計するのが難しい
  • といいつつ、スケールの問題でサービス自体を止めるという状態も避けたい

スケーラビリティの設計が不要であり、スケールが担保されているという点で、App Engineは今回の状況に適していると判断しました。

3. 標準のランタイム(特にGo)が動く

App Engineは多言語のメジャーなランタイムをサポートしており、環境に依存しない形でアプリケーションを実装できます。つまり、万が一アプリケーションを他インフラに移行する際も環境にロックされるリスクがほとんどないです。

現状、将来を踏まえたインフラを選定することが難しいため、環境にロックされないことが非常に重要だと判断しました。

今回バックエンドはGoで実装していますが、去年リリースしたGo1.12も動作が保証(公式ドキュメント上はGo1.12+と記載)されているので、今後の開発でGoの実行環境で開発が困ることはなさそうです。

4. 簡単な環境構築

YAMLファイルで設定を定義した後、ワンラインのSDKコマンドでデプロイが可能です。ロードバランシングなどを自前で設定する必要はありません。個人的には他のクラウドサービスのPaaSとApp Engineの一番の違いはここじゃないかなと思っています。

また副次的効果ではありますが、CD(Continuous Delivery)のpipelineを作るのもワンラインで済むので非常に楽です。

事業的にフィードバックループのスピードが重要で当然CDも重要なため、このように便利なSDKがあるのもApp Engine(というよりGCP)を選択した理由のひとつです。

今回気づいた懸念点

結果的にいま開発しているプロダクトでは問題になっていないのですが、少し気になったところをまとめてみました。

クローズドな通信の実現が難しい

App Engine自体がインターネットアクセスを前提としているので、サービス間のクローズドな通信を実現しようとすると途端に難しくなります。

当然ネットワークではなく自分たちのアプリケーション側の認証でアクセス制限することもできますが、可能な限りネットワークレイヤーで制限したい場合には向かないかなと思いました。

Cloud IAP などでApp Engine手前で認証を入れることもできる気もしますが、OAuthなど実装が難しそうです。

重い処理には向いてなさそう

自動スケーリングの場合、リクエストのタイムアウト時間があり、それより長くかかる処理はタイムアウトし実行が終了してしまいます。

重いバッチ処理などを実行させたい場合は手動スケーリングでインスタンスを常時立ち上げるか、フレキシブル環境で実現すれば良いのですが、それはそれでPaaSの良さを無くしてしまう可能性もあります......

まとめ

App Engineは、多少制約はあるものの使いどころを間違わなければ非常に強力だと感じました。下記の場合、利用に向いているのではないかと思います。

  • アプリケーションエンジニアが中心のチーム
  • 事前のスケーラビリティ設計が難しいプロダクト
  • リクエスト数に比例する課金体系が事業的にマッチしているプロダクト
  • リクエストが急激に跳ね上げる可能性があるプロダクト(Webメディアなど)
  • クローズなサービス間通信の必要がないプロダクト

今後について

このようにGCPの力も借りつつ、新規プロダクトをいち早く正式リリースできるように今後も頑張っていきたいと思います。正式リリース後に具体的なサービスの中身や機能についても記事にする予定です。

余談

「Cloud Runを選択肢に挙げなかったのは何故?」という疑問があるかと思いますが、「選定時期より後にGAになったため選びたくても選べない状態だった」というのが答えになります。ただし今後のために素振りはしておきたいと思っています。

cloud.google.com

参考: サービスの説明

他サービスも含めた簡単な説明と利用用途、リンクを記載しています。興味のある方は参考にして頂ければ

利用サービス

  • App Engine
  • Cloud CDN
  • Cloud Storage
  • Cloud Memorystore
  • Cloud SQL
  • 他、Cloud DNSなどネットワークサービス

利用方法・用途

App Engine

App Engineは主に二つの用途で使っています。

フロントエンド に必要なリソース(HTML/CSS/JS)を返すクライアント向けのアセット配布的な役割とServerside Renderingなどに使用しています。(React/Next)

バックエンド側はビジネスロジックを実装し、APIサーバとして稼働させています。合わせてDatabaseへの参照や書き込みも実装しています。

App Engineはサービスという単位で管理体系を分けられて、事前に定義したdispatch.yamlファイルに従いリクエストを各サービスへルーティングさせることができます。Source IPで通信を制限できる簡易的なFirewallも備えています。

Cloud CDN/Storage

画像など静的ファイルをCloud Storageに格納して、適切なキャッシュ設計をしCDNにキャッシュさせます。この辺は特に目新しい事はしていません。

Cloud SQL

主要なデータを主に格納する SQL Databaseです。App Engineからの接続方法もそれほど難しくありません。方法については下記を参照ください。

cloud.google.com

cloud.google.com

Cloud Memorystore for Redis

App Engineには元々memchachedというメモリキャッシュサービスがあったのですが、最近のApp Engineのランタイムでは非推奨となっていたので、今回Memorystoreを使う事にしました。接続には最近GAになった Serverless VPC Accessを使っています。詳細は下記を参照ください。

cloud.google.com

cloud.google.com

 

【寄せ鍋レポート #8】千差万別のセルフブランディング術!!

こんにちは。トライバルメディアハウスの鈴木彩人(すずき あやと)です!

 

企業の垣根を越えてエンジニアが集まり、プレゼンやハンズオンで知識やスキルをシェアしあい交流するイベント「エンジニア寄せ鍋」。その第8回目となるイベントが、2019年1月25日に開催されました。

 

テーマは「これからのエンジニアのためのセルフブランディング」。

自身をブランディングすることでどのようなメリットがあるのか、具体的にどのようにブランディングしていくのかを学ぶ回となりました。

 

本記事では、この第8回の模様をレポートします。「これからエンジニアとして新たなチャレンジがしたい!」という方や「周りから〇〇と言えば自分と言われたい」と思っている方におすすめの内容だと思いますので、ぜひ読んでみてください!

※ 関連リンク

エンジニア寄せ鍋第8回 Compass イベントページ

yosenabe.connpass.com

 

エンジニア寄せ鍋の紹介はこちら

tech-tribalmedia.hatenablog.com

マーケティングのフレームワークを応用したセルフブランディング術

イベントのスタートとなるイントロダクショントークでは、トライバルメディアハウス(以下、トライバル)で、オンラインコミュニティプラットフォーム「cocosquare」などの開発を担当しながら、“音楽・エンターテイメント×テクノロジー”をテーマとしたメディア「BAKERY/ベーカリー」の編集長も務める 阿部 祐輝が登壇。

 

このトークでは、今回のテーマであるセルフブランディングが「なぜ今、エンジニアにとって重要なのか」という視点で、「マーケティングの考え方をエンジニア個人に適用するセルフブランディング術」をプレゼンテーションしました。

f:id:tribalmediahouse:20190514151257j:plain

“変化の激しい世の中”をエンジニアにとってのチャンスと捉え、その中で自分自身がやりたいことをするためにはブランディングが必要だ、と今回のイベントテーマが設定された背景を語る阿部。

それではどのようにブランディングをしていけばいいか、という問いに対して、阿部は「マーケティングのフレームワークを個人に置き換えてみてはどうだろうか」と提案します。マーケティング戦略を考える上での流れを整理しながら、それを個人に当てはめて考えてみると……という展開でプレゼンテーションは進んでいきます。

 

「マーケティングのフレームワークの対象は “会社” や “ブランド” ですが、それを自分自身に置き換え、分析することで様々な気づきを得ることができると感じています。」と語り、ブランディングの各フェーズを個人に置き換えて考えると、どのような気付きが得られるかをいくつかピックアップしながら紹介していく阿部。マーケティングフレームワーク「VRIO分析」の例では、阿部はこのように語っています。

※「VRIO分析」とは、企業が持っている経営資源の競争優位性を、『価値(Value)』、『希少性(Rarity)』、『模倣可能性(Imitability)』、『組織(Organization)』の4つの視点で測るフレームワーク

 

「 自身のスキルは経済価値があるのか、そのスキルは希少か、そのスキルは真似しづらいか、そのスキルを継続して伸ばし活用していく姿勢があるのか。VRIO分析を個人に当てはめ、このように自分自身を分析すると、集中すべきポイントや目標を設定しやすくなるのではないでしょうか。」

私は目標を立てたり、自己分析することが苦手なのでVRIO分析を使用して自身のスキルを分析して目標立てしてみようと思いました。

 

またプレゼンテーションの終盤では、発信することの重要性の一つとしてこのように語っているのが印象に残りました。

「発信することは、やりたいことを自分の中に染み込ませることができる、という側面もあると思っています。

発信をするためには、その物事にアンテナを立てて調べる必要がある。アンテナを立てる習慣によって、やりたいことに関する情報を自然と集められるようになります。」

情報発信のメリットを聞き、私もブログを書いて情報を発信し、自分のやりたいことを示していこうと強く感じました。

 

ブランディングの定義と手法、情報発信の大切さを踏まえて、次のライトニングトーク(以下、LT)のパートに入っていきます。

 

LT資料はこちら 

“狂気の沙汰”にも感じる水玉ブランディングによって生み出されたもの

LTパートのトップバッターは、株式会社ロックアップ 代表取締役社長の長尾 純平さんです。

 

自身のブランドを形成するために長尾さんが活用しているのが「水玉柄」。この「水玉」を長尾さんは“焼印”と表現します。どのような意図で、どういう風に活用してきたのか、長尾さんのブランディングに対する考え方や実践されていることについて詳しくトークしていただきました。

f:id:tribalmediahouse:20190514152115j:plain

水玉柄が目立つ長尾さん。

この日も特徴的な”水玉柄”の服を身につけ登壇された長尾さん。メディアに露出する際はもちろん、驚きなのはクライアント先の偉い人と打ち合わせする際も水玉がプリントされた服を着ることが多いということ。このことについて、長尾さんはこのように語ります。

「水玉の服装で打ち合わせにいくと、第一印象はあまり良くないのですが、仕事はきちんとするのでプラス評価が普通の人よりも一つ上の段階でつけられることが多いです。

“普通の人が良いことをするとき”と、“不良の人が良いことをするとき”の周りからの評価の違いと一緒ですね。」

印象的な服装によって、相手に自分自身を強烈に覚えてもらい、さらにそのことで生まれる“不”の面すらも、より高い評価に繋げられる、という考え方。とても勉強になります。

 

続けてブランディングの手順についてこう語りました。

「自分の焼印を決め発信し続ける→周りから興味を持ってもらう→一緒に仕事をして期待以上の成果を出す。

このサイクルを繰り返すことで、信頼と安心、ブランドロイヤリティが発生し、そのまま自分のキャリアになりブランディングの糧になっていきます。」

 

また、“セルフブランディングするにあたって意識してほしいこと”としてこのような観点を伝えてくれました。

「“自分自身が発信したい内容”と“相手が認識する内容”がずれてしまった場合、これはブランディングの失敗であり、仕事の損失に繋がります。

対外評価と自己評価が一致していることがセルフブランディングにおいて大切です。」

 

今回のLTを通して、自分も何か焼印を持たねば! と強く感じました。私はバナナマンが好きなので、バナナマンTシャツを着てセルフブランディングしてみようと思います!

 

みなさんはどんな焼印でセルフブランディングしますか?

ちなみに長尾さんレベルのセルフブランディングが確立すると、様々な人から水玉の食器や水玉のシャツを着払いで送られてくるそうです(笑)。

 

LT資料はこちら

身近なところから始めるセルフブランディング

LTパートの2人目は株式会社自転車創業 取締役兼CTOの幸 龍太郎さんです。

 

セルフブランディングの重要性を、幸(さいわい)さんご自身が現在の会社で勤めるまでのエピソードを交えてトークしていただきました。

f:id:tribalmediahouse:20190514152338j:plain

“自転車創業”という会社名、インパクトがありますよね。

CTOを務める幸さんは、セルフブランディングがもたらす効果についてこのように語っています。

「セルフブランディングすることにより、サービスを知ってもらえるチャンスが増えます。

サービスの認知が広がった後、ユーザーに使ってもらい、フィードバックをもらうことができます。また仕事の仲間を集める上で、セルフブランディングは欠かせないものと考えています。」

「そのため、ブランディングにはPRが欠かせなく、発信することが大切なのでSNSなどのアウトプットが重要です。」

 

幸さんはそこから、自分の社会人人生を「Javascriptのチェーンメソッド」で例えるユニークなプレゼンテーションで、参加者の興味をひいていきます。

特に私としては、幸さんがエンジニアになったきっかけが印象的でした。

「コールセンターのバイト時代に、社内でPCが得意な人と認知されたんですね。そのおかげで顧客管理システム手伝ってみない? とチャンスをもらえました。」

ちょっとした認知が、大きな仕事のチャンスをもらえるきっかけになるのだと驚きを感じました。

 

私は今年社会人2年目になりますが、社内で「彩人といえばコレだよね!」と言われるような認知は作れていないと感じています。

今回、幸さんのLTをお聴きし、自身の得意分野を見出して、少しづつ社内に発信してみようと決心しました。

そして幸さんのように、自分の得意分野の仕事を任せてもらえるようにセルフブランディングを続けたいと思います。

得意分野の仕事を任せられるほど楽しいことはないですからね!

 

セルフブランディングによって自身の人生にチャンスを与える機会が大きく変わることを気付かされたトークでした。

 

LT資料はこちら

セルフブランディングのきっかけを掴む場づくり

LT3人目は、トライバルでマーケティングツール「cocosquare」のプロダクトマネージャーを担当しており、エンジニア寄せ鍋の幹事も務める柿沼 信孝です。

 

柿沼自身が今までセルフブランディングを意識したことはなかったそうですが、今回のテーマで話す内容を振り返ってみたところ、実は「場作り」でセルフブランディングしていたと気づいたそうです。

f:id:tribalmediahouse:20190514152427j:plain

冒頭に自己紹介とLTのテーマについて話した後、セルフブランディングをするきっかけやメリットについてお話ししました。

 

「ブランディングのきっかけ作りとして、自分で勉強会を主催することをおすすめします。

勉強会の場をオーガナイズし、自分が得意なことを少しずつブランディングすることができるため、セルフブランディングするのに効果的です。」

「さらに勉強会の場に社内の人や知り合いが参加していると『この人、こんなスキルも持っていたのか』という再認知にも繋がります。

また、再認知されることで、案件の相談が増えたり、他の案件に役立つような知識を新たに得たりすることができます。

そして、得た知識を用いて本業に活かすことができ、チャンスが増え仕事が選びやすくなるメリットが生まれます。」

 

自分が場をコントロールしやすい状況を作り、セルフブランディングを行うという合理的な考え方がとても勉強になりました。

私も何か得意なことを発信するために勉強会などを主催し、社内認知を広げてみようと思います。

 

プレゼンテーション終盤、トークのまとめを以下のように語りました。

「大切なことは、ブランディングする前の細かい根回しと自分のブランドを発信することができる場づくりです。」

 

幸さんのトーク同様、自分の得意なことを周囲が認知することで、チャンスがもらえる機会が格段に増えることは確実、と学びました。

 

LT資料はこちら

コミュニティとブランディングの意外な関係性

最後のLTは、マネーツリー株式会社のソフトウェアエンジニア コービング ロン (Ron Korving) さんです。

 

ロンさんのLTでは、「OSS(オープンソースソフトウェア)」である Node.js へのコントリビューションをきっかけに得たコミュニティの方々とのつながり、そしてセルフブランディングへの考え方についてトークしていただきました。

f:id:tribalmediahouse:20190514152512j:plain

LTは、ロンさんのインパクトのある自己紹介から始まります。

 

私はNode.jsファイルシステムの書き込み速度を100倍速くした奴だ!

 

会場が拍手に包まれてスタートしたLTは初めてだったかもしれません……!

 

当時、携わっていた業務にNode.jsが一番適していると判断したロンさん。

しかし、当時のNode.jsはスループット(一定時間あたりのデータ処理能力)がかなり低かった。そこでOSSである Node.js の改修を決心したそうです。

 

コントリビューションまでの道のりを紹介してくれるロンさん。OSSへのコントリビューションというと敷居が高く感じますが、Node.jsの改修を達成したロンさんは、このように語っています。

「私が天才だからできた、ということではないです。Node.jsに対するPassionがあったためモチベーションを保ち続けることができました。さらに、最初は高いスループットを出せない実装でしたが、コミュニティの人が協力してくれたため、改修が成功しました。」

 

これまで私は、OSSは敷居が高く、完璧な実装を求められているものだと思っていました。

しかし、ロンさんのトークを聞いて、「OSSは気軽にコントリビューションして、コミュニティの人たちと協力しながら実装していくものなんだ」と気づかされました。

 

最後に今回のトークとセルフブランディングの関係性をこのように語りトークが終了しました。

「セルフブランディングは目的ではなく結果の一つ。

あなたのPassionに合ったコミュニティを見つけ、アクションを起こし続けることでブランディングは自動的にされていくものです。」

 

私は明確なセルフブランディングの目標が立てられていないため、まずは自分に合ったコミュニティを探すことから始めてみようと思います。

そして、コミュニティで行動を起こし続けて、セルフブランディングを確立してみます。



LT資料はこちら

今回の寄せ鍋イベントのまとめ

セルフブランディングの重要性や手法、コツをそれぞれの登壇者の視点で語られた今回のエンジニア寄せ鍋。私自身とても勉強になるイベントとなりました。

 

ちなみに、LT後の懇親会も過去最高の盛り上がりに。

技術の話や情報をどのように収集しているのかなど、積極的に意見交換している参加者が非常に多かったです。 

f:id:tribalmediahouse:20190521133602j:plain

懇親会の様子

今回の寄せ鍋では、登壇者全員が「情報を発信することは非常に大切」と話していたことが印象に残りました。

セルフブランディングと情報を発信することは非常に深い関係があることを学べた寄せ鍋でした。

 

この記事を読んだ皆さんも、どんなことでもいいのでまずは情報発信をしてセルフブランディングしてみてはいかがでしょうか。

次回の開催は5月テーマは「プロダクトマネージャーの仕事」!!

第9回のエンジニア寄せ鍋は5/31(金)に開催が決定しています。テーマは「プロダクトマネージャーの仕事」!

ご参加をお待ちしております!

「トライバルメディアハウスのプロダクトマネージャーの仕事 #エンジニア寄せ鍋#9」の詳細と申し込みはこちら

yosenabe.connpass.com

Tản mạn chuyện kỹ sư cầu nối Nhật Bản

Xin chào mọi người, mình là Trường Giang.

Mình là một kỹ sư công nghệ thông tin và đang làm việc tại công ty Tribal Media House.

 

Trong bài viết này, mình muốn chia sẻ với mọi người về những trải nghiệm của bản thân sau 2 năm làm việc tại công ty của Nhật, với vai trò là một kỹ sư cầu nối (viết tắt là BrSE). Hy vọng bài viết sẽ là một tài liệu tham khảo dành cho những bạn đang có ý định trở thành BrSE.

Ngoài ra, qua bài viết này mình cũng muốn nhìn lại chặng đường mà bản thân đã cố gắng, và từ đó có định hướng rõ hơn trên chặng đường sắp tới, với mục tiêu là trở thành một BrSE tốt hơn nữa.

 

※ Mình rất muốn biết cách nghĩ của mọi người nghĩ về BrSE như thế nào. Rất vui nếu có thể nhận được bình luận, tin nhắn từ mọi người. Đây là  Facebook của mình nhé.  

 

Cầu Miyoshi ở cạnh công ty mình

Cầu Miyoshi ở cạnh công ty mình

 

 Giờ chúng ta vào vấn đề chính thôi.

1. BrSE là gì?

Trước tiên, mình xin nói qua một chút về công việc của một BrSE.

 

Mình cũng đã thử tìm hiểu về định nghĩa BrSE, nhưng vẫn chưa tìm thấy một định nghĩa chính thức nào cả. Tuy nhiên, trên Wikipedia có định nghĩa về BrSE như sau:

BrSE nói đến một nhân sự - vai trò là một cầu nối giữa IT và các lĩnh vực khác, ngành khác, kết hợp với một team project để cùng tạo ra một sản phẩm, dịch vụ trong những dự án mang tính quốc tế.

ー Trích dẫn đoạn 「ブリッジシステムエンジニア」trên Wikipedia

 

Mình xin giải thích chi tiết hơn một chút như sau.

BrSE là người kết nối giữa team phát triển offshore và team phát triển onshore. Công việc chủ yếu là  “ cố gắng truyền đạt để team phát triển offshore nắm chắc được các yêu cầu ” , “ hiểu rõ về nội dung của những câu hỏi của team offshore, truyền đạt lại chính xác cho team onshore, cuối cùng là đưa ra câu trả lời cho team offshore” . Tuỳ vào tổ chức và tình hình của team mà cũng có lúc BrSE đảm nhiệm cả vai trò Project manager hay Development manager.

 

※ Trong một số bài viết có nói đến vai trò của BrSE là kết nối team phát triển với khách hàng, tuy nhiên đó không phải là câu chuyện mà mình muốn chia sẻ lần này. (Chi tiết được viết ở mục 3.)

2. Hành trình trở thành một BrSE

Trước khi nói về kinh nghiệm của một BrSE, mình xin chia sẻ đôi chút về bản thân.

Sau khi vào trường Đại học Bách Khoa năm 2010, mình tham gia vào HEDSPI -  một dự án đào tạo kỹ sư IT có sự hợp tác giữa Nhật Bản và trường mình. Trong 5 năm học tại đây, mình học được kiến thức IT, tiếng Nhật, và tất nhiên là cả văn hoá, quy tắc ứng xử của người Nhật.

 

Năm 2015, sau khi tốt nghiệp đại học, mình vào làm việc tại công ty  Tribal Media House tại Nhật Bản. Công ty mình cũng có cơ sở đại diện ở Hà Nội,  tên là Tribal Media House Technology Lab ( Tech Lab). (Ở thời điểm đó, Tech Lab có khoảng 10 nhân viên, nhưng hiện tại, sau 5 năm, số kỹ sư trẻ đã tăng lên đến gần 40 người rồi.)

 

Sau khi vào Tribal Media House, mình tham gia dự án cocosquare, và phụ trách vận hành và bảo trì cho hệ thống.

Kể từ năm thứ 2 sau khi tốt nghiệp, mình bắt đầu làm công việc của một BrSE, có nhiệm vụ là một cầu nối giữa team Nhật Bản và team phát triển ở Hà Nội. 

 

※ Công việc năm 1 và năm thứ 2 mình có viết trong blog dưới đây, mọi người có thể đọc tham khảo nhé.

TMH3年目のエンジニアの振り返り

3. Công việc BrSE của mình

Như vậy, mình bắt đầu công việc của một BrSE từ năm thứ 2 sau tốt nghiệp. Ngoài công việc kết nối giữa team Nhật Bản và team phát triển ở Hà Nội thì mình cũng làm những công việc khác như là phát triển, vận hành các dự án... Vì thế nội dung công việc có lẽ hơi khác với một BrSE thông thường.

 

Hiện tại, chi tiết công việc BrSE của mình như sau :

  • Trao đổi cùng các thành viên bên phía Nhật; hiểu rõ các yêu cầu, điều kiện của task; chuyển task về cho team phát triển ở Hà Nội.
  • Giải thích đúng được các yêu cầu, điều kiện của task cho team phát triển ở Hà Nội.
  • Nhận và trả lời các câu hỏi, trao đổi, thảo luận từ team phát triển ở Hà Nội.
  • Quản lý tình hình task và tình hình tiến độ phát triển của team phát triển ở Hà Nội.
  • Báo cáo tình hình tiến độ của team phát triển ở Hà Nội cho team Nhật Bản.
  • Review, test, và release source code cho team phát triển ở Hà Nội. ….

 

Từ những kinh nghiệm đã có được, mình nhận thấy hai công việc dưới đây là quan trọng hơn hết đối với một BrSE.

  • Dịch tài liệu và truyền đạt thông tin từ phía Nhật Bản một cách chính xác. 
  • Trao đổi với các thành viên trong team để hiểu rõ về nhau.

4. Điểm thú vị của BrSE

Trong 2 năm làm việc tại Nhật với vai trò là một BrSE, mình đã trải khá nhiều điều thú vị, nhưng trong nội dung bài viết mình xin chia sẻ 3 điểm mà mình thấy quan trọng nhất.

 

● Được làm việc với nhiều người hơn

Có lẽ so với một Developer thông thường thì công việc của BrSE đem lại cơ hội được giao tiếp, tiếp xúc với nhiều người hơn.

Trong trường hợp của mình, thì mình đã và đang làm việc với nhiều thành viên khác nhau như là:

  • Các thành viên thuộc bộ phận khác của công ty ( như bộ phận marketing, bộ phận kinh doanh, hay bộ phận vận hành )
  • Các thành viên team phát triển ở Hà nội
  • Leader (hoặc manager) của dự án
  • Các thành viên của team phát triển Nhật. ...

Có thể làm việc được cùng với các thành viên của cả Nhật Bản và Việt Nam, với tính cách đa dạng, nhiều kiến thức và kỹ năng khác nhau. Đó thực sự là một trải nghiệm vô cùng thú vị.

 

● Bản thân có thể trưởng thành ở nhiều mặt

Ở phần trước mình cũng có chia sẻ rằng “BrSE có thể giao tiếp được với nhiều người”, thế nhưng thực ra mình vốn là người không giỏi lắm về giao tiếp. Từ khi trở thành một BrSE phải giao tiếp, trao đổi nhiều hơn, mình cảm thấy điểm yếu này đã được cải thiện dần.

 

Hơn thế nữa, ở công ty nhờ vai trò là một BrSE mà mình có cơ hội tham gia vào nhiều dự án. Và mình cũng được thay đổi team thường xuyên khi cần thiết. Trong mỗi team lại có cách làm việc khác nhau, và sử dụng những kỹ thuật khác nhau. Vì thế những khi thay đổi team, mình thấy cũng cần thay đổi cách làm việc và giao tiếp với các thành viên trong team để phù hợp hơn. Và cũng nhờ sự thay đổi đó mà mình cũng tích luỹ được nhiều hơn các kinh nghiệm mới, phương pháp làm việc mới.

 

Sau 2 năm làm công việc là một BrSE, chưa hẳn đã xuất sắc, nhưng mình cảm thấy nhiều năng lực của mình đã tăng lên đáng kể so với 2 năm trước đây.

Ví dụ như:

  • Năng lực giao tiếp
  • Năng lực làm việc nhóm
  • Năng lực đàm phán
  • Năng lực đưa ra quyết định
  • Năng lực thảo luận
  • Năng lực quản lý
  • Năng lực leader ship

 

● Cảm giác vui và hạnh phúc khi team của mình mình trở nên tốt hơn, các thành viên trong team trưởng thành hơn

Khi team đạt được kết quả tốt hơn, thành viên của team trưởng thành hơn, mình cũng cảm thấy như đó cũng có một phần công sức của mình. Đó là một cảm xúc tuyệt vời, mang lại cho mình động lực để bước tiếp trên con đường phía trước.

5. Những khó khăn trong công việc BrSE

Công việc BrSE có nhiều điểm thú vị như vậy, nhưng cũng có không ít những khó khăn. 

 

● Khó khăn trong giao tiếp

Như mình đã viết ở trên, một BrSE có thể có được nhiều cơ hội giao tiếp với nhiều người. Tuy vậy, điều đó cũng đồng nghĩa với việc mức độ khó của việc giao tiếp cũng tăng lên.

 

Mình hay lo lắng rằng:

  • “Làm thế nào để có thể truyền đạt được một cách chính xác hơn ý kiến của mình cho cấp trên người Nhật - khi mà có sự khác nhau giữa ngôn ngữ và văn hoá, cũng như về lĩnh vực hiểu biết? ”
  • “ Làm thế nào để có thể nắm bắt được và giải quyết tốt hơn các nguyên nhân hiểu lầm xảy ra giữa thành viên Nhật Bản và thành viên Việt Nam? ”
  • “Làm thế nào để có thể giải thích và chia sẻ được các thông tin, kiến thức liên quan đến kĩ thuật giữa các thành viên Nhật Bản và thành viên Việt Nam.”
  • ...

Mình nghĩ rằng cách để có thể cải thiện được những điều trên là “ phải trải nghiệm nhiều, hiểu ra, sau đó mới cải thiện nó ”

 

※ Nếu mọi người có quan tâm đến giao tiếp với đồng nghiệp người nước ngoài, thì có thể đọc bài mình đã viết trước đây nhé.

日本人の同僚とのコミュニケーションの壁を越える経験

 

● Khó khăn trong việc quản lý tiến độ làm việc của team

Tự quản lý tiến độ công việc của mình đã khó rồi, nhưng việc quản lý tiến độ công việc của team còn khó hơn nữa. 

 

Việc xây dựng kế hoạch công việc rất tốn thời gian. Tuy nhiên, không phải lập xong kế hoạch là dừng ở đó mà phải liên tục quản lý và điều chỉnh tiến độ. Đặc biệt BrSE phải nắm được tình hình của các thành viên ở xa, vừa phải giao tiếp lại vừa phải triển khai công việc, điều này thật sự rất khó và tốn công sức.

 

● Khó khăn trong việc quản lý công việc của chính bản thân, khi một lúc phải đảm nhiệm nhiều công việc, vị trí khác nhau

Điều này có lẽ còn tuỳ vào vào công ty và tuỳ từng người, còn với mình hiện tại, ngoài việc đảm nhiệm công việc của BrSE, mình còn phải đảm nhiệm nhiều công việc, vị trí khác.

 

Chính vì vậy, để hoàn thành được tất cả các task theo kế hoạch là rất khó. Trong khi, lúc nào cũng có khả năng phát sinh vấn đề. Tuy nhiên, nhờ những lúc như vậy mà mình nghĩ năng lực điều chỉnh và đàm phán của mình cũng được tăng lên, nhưng…. quả thật khá là mệt.

 

6. Những điểm cần chú ý về công việc BrSE

BrSE khó là như vậy nhưng là một công việc thú vị, đáng để mình trải nghiệm. Dưới đây là một số điểm mà mình thấy có thể có ích cho các bạn sẽ trở thành BrSE trong tương lai.

 

● Luôn ý thức về việc hoàn thiện các kỹ năng của bản thân

Đặc thù công việc của một BrsE đòi hỏi một người kỹ sư phải có rất nhiều các kỹ năng quan trọng như kỹ năng giao tiếp, kỹ năng làm việc nhóm, quản lý thời gian... Các kỹ năng này không thể có ngay được trong ngày một ngày hai, mà là cả một quá trình học hỏi và tích lũy lâu dài. Chính vì thế luôn ý thức về việc hoàn thiện các kỹ năng của bản thân là một yêu cầu quan trọng với một BrSE.

 

● Kỹ năng giao tiếp là rất quan trọng

Phần lớn thời gian của BrSE là giao tiếp. Theo ý kiến của mình thì, khả năng giao tiếp là một yếu tố quan trọng nhất. Vì thế, BrSE nên xem việc hoàn thiện được kỹ năng giao tiếp là mục tiêu lớn nhất của mình.

 

● Không vội vàng, từng bước từng bước một, liên tục học tập nghiên cứu

BrSE đòi hỏi rất nhiều kiến thức và kỹ năng. Ví dụ như kiến thức kỹ thuật, ngôn ngữ và các kỹ năng giúp ích cho công việc.

 

Vì thế việc đạt được tất cả những điều này cần một quá trình phấn đấu lâu dài và bền bỉ; có lộ trình, thử nghiệm và trải nghiệm nhiều thất bại. Đừng quá nóng vội; hãy không ngừng học tập, cải thiện các kỹ năng để mọi thứ tốt hơn nhé.

 

● Xác định rõ động lực giúp mình duy trì và phát triển hơn

Thú vị cũng có, vất vả cũng có rất nhiều. Để không bỏ cuộc giữa chừng, bạn nên xác định rõ, và để ý đến động lực của bản thân, hãy trả lời những câu hỏi như : “Tại sao lại muốn trở thành BrSE?”,  “Những việc quan trọng gì mình muốn hoàn thành? ”.

 

● Luôn ý thức về sự phát triển của team

Công việc của một BrSE là làm việc với tất cả các thành viên trong team. Mình nghĩ rằng nếu các thành viên trong team không phát triển hơn, tốt lên từng ngày, thì công việc khó mà có thể thực hiện một cách thuận lợi. Chính vì thế, đối với BrSE, luôn phải coi trọng “việc hiểu rõ, và trong khả năng có thể giúp các thành viên trong team phát triển, tốt lên”.

 

7. Lời cuối

Mình đã và đang tiếp tục bước đi từng bước trên con đường để trở thành một BrSe tốt hơn nữa.

 

Ở công ty của mình, ngoài các dự án hiện tại, đã có nhiều các dự án mới, ý tưởng mới được đưa ra, và đang trong quá trình triển khai. Ở đó, mình ý thức được rằng vai trò của BrSE sẽ ngày càng quan trọng hơn, và phải tạo ra nhiều thành quả tốt hơn nữa. Vậy nên, mình nghĩ bản thân mình cần học hỏi nhiều hơn, thử thách nhiều hơn trên con đường mà mình đã chọn. Mình hy vọng bản thân sẽ trưởng thành hơn, luôn vui vẻ và không ngần ngại với các thử thách.

 

Hãy cùng cố gắng nhé!

Rất vui nếu được có cơ hội làm việc chung với mọi người!

 

Ảnh chụp với các thành viên của Tribal Media House Technology Lab

Ảnh chụp với các thành viên của Tribal Media House Technology Lab





2年間、ブリッジSEとして日本企業で仕事をしているベトナム人の話

※ Bản tiếng Việt Tản mạn chuyện kỹ sư cầu nối Nhật Bản

※ 今回の記事は、ベトナム語にも翻訳して発信します。日本にも、ベトナムにもブリッジSEについての理解が拡がればいいなと思っています。

 

皆さん、こんにちは。ザンと申します。

私は現在東京の Tribal Media House で働いているITエンジニアです。

 

今回、日本の会社でブリッジSE(以下、BrSE)として2年間働いてきた中で得てきた私自身の経験についてお話したいと思います。

 

この記事が、BrSEになりたい人にとって、参考資料になることを願っています。

 

また、この記事を書くことで、自分自身もこれまで取り組んできたことを振り返り、次にどのように進むかを考えるきっかけにして、より優れたBrSEになりたいとも思っています。

 

※ 皆さんがこの記事を読んで、BrSEに対してどういう風に思ったのか、知りたいです。コメント・メッセージなどをお待ちしています。(私のFacebookにコメントをもらえると嬉しいです。)

 

みよしばし、BrSE

会社のそばにある「みよしばし」

それでは、本題に入りましょう。

 

1. BrSEとは?

まず、BrSEの仕事について少し話したいと思います。

 

BrSEの定義を見つけようとしましたが、国際的な機関のオフィシャルな定義などは見つけられませんでした。ただ、Wikipedia で少しだけ文章を見つけました。以下は Wikipedia に書かれた定義です。

 「グローバルなプロジェクト環境下において、ITと異分野・異業界との架け橋となり融合を行い、製品やサービスをプロジェクトチームとして生み出す人材を指す。

ー Wikipedia「ブリッジシステムエンジニア」より引用

 

もう少し詳しく説明したいと思います。

 BrSEは、オフショア開発チームとオンショア開発チームを結ぶ人材です。 主な仕事は「オフショア開発チームが要件を確実に理解できるようにすること」、「オフショアチームからの質問について、その意図をしっかりと理解し、オンショアの人に伝わるように翻訳することで、正しい回答を引き出すこと」などです。

チームの構成・状態によって、プロジェクトマネージャ、または開発マネージャが担当することもあります。

 

※ ちなみに、一部のブログ記事などでは、開発チームと顧客をつなぐ役割のことをBrSEと言っていることがありますが、今回私が話したいのはそちらではありません。(詳しくは3番目の項目で書いております)

 

2. BrSEの仕事に就いた理由は何ですか?

私のBrSEの経験について話す前に、すこし私の経歴について話したいと思います。

 

私は、2010年ハノイ工科大学に入学し、日本とハノイ工科大学との協力を得て、日本語ができるITエンジニア養成プロジェクト HEDSPI に参加しました。その5年間で、ITと日本語、また日本の文化やマナーなどについて学んでいました。

 

大学卒業後、日本の Tribal Media House にすぐに入社しました。

Tribal Media House は、ベトナム・ハノイに ベトナム現地法人のテックラボ(以下、テックラボ) という開発拠点を持っており、それがきっかけになりました。(その当時、テックラボ のメンバーは10人くらいでしたが、今では若いエンジニアが40人くらいいます!驚きですね!)

 

Tribal Media House に入ってから、cocosquareプロジェクトに参加し、システムの運用と保守をしていました。

 そして新卒2年目からは、東京チームとハノイ開発チームの架け橋となる役割として働いています。そこからBrSEの仕事を始めきっかけになりました。

 

※ 1年目と2年目の仕事を以下のブログを書いていますので、ご覧でください。

TMH3年目のエンジニアの振り返り

 

 3. 私のBrSEとしての仕事

このように、新卒2年目からBrSEの仕事をどんどん始めました。ただ、東京チームとハノイ開発チームを繋げる仕事以外にも、自身も手を動かしてプロジェクトの開発・運用も行なっていたので、一般的なBrSEとは違うかもしれません。

 

4年目となった現在、私のBrSEとしての詳しい仕事は、以下の通りです。

  • ハノイ開発チームのタスクを作成するために、日本のチームメンバーと相談して、タスクの要求・要件を理解すること
  • ハノイ開発チームへ、タスクの要求・要件を正しく説明すること
  • ハノイ開発チームからの質問・相談を受けて、回答すること
  • ハノイ開発チームのタスクのステータスと開発進行状況を管理すること
  • 日本チームに、ハノイ開発チームの進捗状況を報告すること
  • ハノイ開発チームのソースコードレビュー、テスト、リリース

などです。

 

また、以下のタスクについてはこれまでの経験から、より重要だと意識して行動しています。

  • 資料や日本側からのメッセージ翻訳
  • お互いの理解を深めるためにチームのメンバーとコミュニケーションすること

 

 4. BrSEの面白いこと

2年間、Tribal Media House のBrSEとして日本企業で仕事を経験して、面白いことやドキドキすることがたくさんありますが、以下の大切なポイントを3つ共有したいと思います。

 

● より多くの人と働けること

通常のデベロッパーと比較して、BrSEの仕事はより多くの人とコミュニケーションする機会があります。

私の場合、

  • 会社の他の部署のメンバー
  • ベトナムの開発チーム
  • リーダー(またはマネージャー)
  • 日本の開発チームのメンバー

などとコミュニケーションをとる機会があります。

 

日本人やベトナム人、またいろいろな技術や性格をもった人と仕事ができるのは、とても刺激になって面白いです。

 

● いろいろな面で自分自身を成長できること

一つ前に、“BrSEはいろいろな人とコミュニケーションできる” ということを書きましたが、実は私はそもそも会話するのは苦手な人でした。BrSEの仕事をしながら、いろいろコミュニケーションが取れるおかげで、それが改善できていると感じています。

 

さらにTMHで私は、BrSEであることで、いろいろなプロジェクトに参加する機会をGETできています。全体の開発状況によって、チームが変わることもあります。その時には、BrSEの人のやり方、チームメンバーにコミュニケーション方法も変えないといけないと感じています。そのため、新しい経験・新しいやり方が身につくと思います。

 

2年間でBrSEの仕事をしていることによって、まだ完璧ではありませんが、私の2年前よりいろいろな能力がアップできました。

例えば、

  • コミュニケーション能力
  • チームワーク能力
  • 交渉能力
  • 意思決定能力
  • ディスカッション能力
  • マネジメント能力
  • リーダーシップ能力

です。

 

● チームがうまくいったとき、チームのメンバーがもっと成長したときには幸せ

チームが職場でより良い成果を上げたとき、またはより成長したチームのメンバーになったとき、「その一端を担えた」と感じます。それは素晴らしい気持ちであり、そして私の現在の仕事で前に進む動機を与えてくれます。

 

 5. BrSEの仕事の難しさ

そんな面白いことがあるBrSEですが、やはり難しいことも多いです。どんなことを難しいと感じているかを考えてみると、以下のようになります。

 

● コミュニケーションが難しい

BrSEは、書いた通り、多くの人と働く機会を得られます。ただ、それはつまりコミュニケーションの難しさも上がるということを意味します。

  • どのようにすれば、より正確に、言語や文化的な相違がある日本人の上司に意見を伝え、正しくフィードバックをもらうことができるか
  • どのようにすれば、日本人メンバーとベトナム人メンバーとの間に起きる誤解の原因をうまく把握し、解決させることができるか
  • どのように、メンバー間、日本とベトナム間で技術的な知識を説明し、共有することができるか

などについてずっと悩んでいます。

 

それを改善するための方法は、「よく経験して、意識して、そして改善する」ということしかないと思っています。

 

※ 外国人の同僚とのコミュニケーションについて興味があるなら、以前に書いたこの記事をぜひ読んでください。

日本人の同僚とのコミュニケーションの壁を越える経験

 

● チームの作業進捗管理が困難

自分自身の仕事の進捗も管理するのは難しいですが、チームのタスクスケジュールを管理することはさらに困難です。

 

スケジュールを立てるのは時間がかかります。しかし、スケジュールは計画を作って終わりではありません。継続して進捗を管理し、調整しなければなりません。特にBrSEとしては、離れた距離にいるメンバーの状態を把握し、コミュニケーションを取りながら進めなければならず、これはとても難しくて、手間がかかります。

 

● 同時に多くの仕事をしなければならないとき、自分の仕事を管理することが難しい

これは会社や人によるかもしれませんが、私は現在、BrSEとしてベトナムと日本のコミュニケーションを支えると同時に、一開発担当者として実際に開発を行ったり、他の仕事(例えば間接作業)をしたり、と複数のポジションを担っています。

 

例えば、

  • プロジェクト開発に参加する(コーディング、または開発者が問題に遭遇したときに問題の解決に参加する)
  • プロジェクトの進捗管理
  • 当事者間で情報をやり取りする
  • プロジェクト品質管理(レビューコード、テスト)
  • レポートを作成する
  • 会社の業務のタスクをする

     ……

 

したがって、すべてのタスクを確実に完了させることは常に非常に困難です。また、いつでも突発の問題が発生する可能性があります。そのおかげで、私の調整と交渉の能力も向上しましたが...やっぱり大変ではあります。

 

6. これからBrSEになる方に伝えたい、2年間で気づいたBrSEのポイント

そんな難しさもあるBrSEですが、やはり面白くやりがいのある仕事です。これからBrSEになる人もいると思いますが、その時に役に立つポイントをまとめたいと思います。

 

● より優れたBrSEになるには、多くのエンジニアスキルが必要です。自分のスキルを完成させることを常に意識した方がいいと思います。

BrSEが遭遇する困難について述べましたが、BrSEは異なる国の人を繋がなければいけないと同時に、さまざまな役割の人のことを理解することが必要になります。

 

だから、それをまずは自分自身が経験して理解しておく必要があると思います。

そうすることで何に困っているかがより理解でき、適切なアドバイスを行うことができると思います。どのポジションの人にも言えることですが、エンジニアスキルをひとつずつ身につけていきましょう。

 

● コミュニケーションスキルは非常に重要です

BrSEの時間の大部分はコミュニケーションです。私の意見では、コミュニケーションするのは重要なので、コミュニケーションスキルを完成させることが常にBrSEの最大の目標です。

 

● 急がないで一歩一歩、継続して勉強することが必要です

BrSEには多くのスキルが求められます。たとえば、技術的な知識、言語、仕事に役に立つスキルなどです。

 

それら全てを習得するには多くの時間がかかるため、ロードマップとトライ&エラーの経験が必要です。焦らず、継続して勉強し続け、もっとよくしていくために改善できるところから始めていきましょう。

 

● 自分が何に対してモチベーションが上がるのか、どうしたら維持できるのかに目を向ける

面白いことがありますが、つらいことがたくさんあります。より優れたBrSEになっている道の途中であきらめないように、「なぜBrSEになりたいのか」「どんなことを成し遂げたいのか」という、自分のモチベーションに目を向け、明確にすることが必須だと思います。

 

● チームメンバーを日々成長させることを意識する

BrSEの仕事は、チームのメンバー全員と働くことです。チームメンバーの能力をアップさせないと仕事はスムーズに進まないと思います。

 

そのため、BrSEとして、チームメンバーをより理解し、できるかぎり日々向上させることを意識することを大事にしなければならないと思っています

 

7. 最後のメッセージ

私はこれからも、もっと良いBrSEになるための道を歩み続けたいと思います。

 

私達の会社では今、既存のプロジェクトに加えて、さらに多くの新しいプロジェクトが生まれ、開発されています。その中で私は、BrSEの役割がより重要になっていく、もっと成果を出していかなければならない、と感じています。

 

だから選んだ道についてもっと学び、そしてもっとチャレンジしていく必要があると思っています。楽しんで成長し、チャレンジしていきたいと思います!

 

Tribal Media House Technology Lab メンバーと取った写真です。

テックラボメンバーと取った写真です。



 

エンジニア寄せ鍋#8、1/25に開催!今回のテーマは「エンジニアのセルフブランディング」

2019年一発目となる エンジニア寄せ鍋#8 が今週末 1月25日(金)に開催されます。

今回のテーマは「これからのエンジニアのためのセルフブランディング」です!  

yosenabe.connpass.com

 

エンジニア寄せ鍋とは?

もう8回目となった「エンジニア寄せ鍋」ですが、改めてどんなイベント・グループなのかをご紹介します。

 「エンジニア寄せ鍋」のきっかけは、2014年にスタートしたエンジニア同士の交流からでした。

 

「扱ってるシステムが違うITエンジニアでも、実は共通で話して刺激なることってあるよね」

 

こんな想いから、会社の垣根を越えて少しずつエンジニアを集めて飲み会をしていたら、 気づいたら20人を超えるITエンジニアが参加してくれるように。

そこで「飲み会だけにしておいたら勿体ない」ということで、プレゼンやハンズオンで知識やスキルをシェアしあいながら、懇親会で盛り上がろう!ということで、2017年6月から「エンジニア寄せ鍋」という名前のイベントとしてスタートしました。

 

ちなみに 「エンジニア寄せ鍋」という名称は、エンジニアが寄せ鍋の中でグツグツ化学反応してたり、 エンジニアが寄せ鍋囲ってワイワイしているシーンをイメージして名付けられています。

これまでも“インフラ ”や“オープンソース”、“音楽・エンターテインメント×AI”、“チームビルディング/マネジメント”などさまざまなテーマで開催してきました。

 

第8回は「やりたいことにチャレンジするために、どう自分をブランディングするか」をトークする会

そして今回のイベントのテーマは「セルフブランディング」です。

f:id:tribalmediahouse:20190121122156p:plain

寄せ鍋第8回

https://yosenabe.connpass.com/event/105254/

 

環境変化のスピードが急激に速くなっているこの頃。

エンジニアにとってはピンチでもありチャンスでもある中で、自分たちのやりたいことをやっていくためには、今後ますます“セルフブランディング”が重要になってきているのではないか。ただ、「自分は何ができ何がしたいのかを考え、それを発信していく」ことの重要性は分かりつつも、なかなか実践できない人も多いはず…

 

そんな想いから、今回は「セルフブランディング」をテーマに設定しました!

  • こんな情報発信をしてみたらどうだろ
  • こんな想いを持ってこんな活動をしている
  • テクニックや事例について

などを考え、トークしていく回になります。

 

今回は豪華ゲストによるライトニングトーク祭り

そして今回は、いつものエンジニア寄せ鍋から趣を変えて、ライトニングトーク祭り!

「セルフブランディング」というテーマに対して、それぞれ個性的な取り組みを行っていらっしゃる4名の登壇者から、次々にトークを展開してもらいます!

 
「焼印が生み出すもの:長尾流 ロジカル思考の水玉ブランディング術」
by 長尾 純平
・株式会社ロックアップ 代表取締役社長

 

「チェーンでつなげていく、セルフブランディング(仮)」
by 幸 龍太郎
・株式会社自転車創業 取締役/CTO 

 

「Value first -Open source contributorの立場からセルフブランディング-」
by コービング ロン (Ron Korving)
・株式会社マネーツリー Senior Software Developer

 

「グラスルーツのセルフブランディング-草の根でデザインシンキングできる人になった話-」
by 柿沼 信孝
・株式会社トライバルメディアハウス プロダクトソリューション事業部

 

 

今年1年の目標を立てる人も多いこの1月。やりたいことにチャレンジしていくために、どんなことができるのかをワイワイ一緒に考え、交流しましょう!

 

まだまだconnpassイベントページにて募集中です。参加無料ですので、お時間のある方はぜひご参加ください!

 

関連リンク:

 エンジニア寄せ鍋 グループページ
 https://yosenabe.connpass.com/

 

画像ビューアライブラリ FMImageView 公開のお知らせと私たちがOSS活動をする目的

こんにちは。トライバルメディアハウスの高田です。

 

先日、トライバルメディアハウス(以下、トライバル)初のOSS(オープンソースソフトウェア)である画像選択・画像加工ツール「FMPhotoPicker」についてご紹介しました。

tech-tribalmedia.hatenablog.com

 

FMImageViewについて

このたび、早くもトライバルOSS第二弾となる画像ビューアライブラリ「FMImageView」を公開しました!

多くの方が一度は実装したことがあるであろう “画像ビューア” 、これをSwiftで実装したのが本ライブラリです。

github.com

 

f:id:tribalmediahouse:20180905180958p:plain

 

今回はこのライブラリを開発するにあたって、私たちが日々どんな想いで開発を行っているかご紹介したいと思います。

「FMImageView」についての詳細は、README.mdをご覧ください。

 

画像・動画というメディアについて

画像・動画がインターネットコンテンツとして当たり前の時代になりました。

 

InstagramやTikTokといった画像・動画を中心に扱うソーシャルメディアが増え、ブログですら画像・動画を用いることが多くなりました。私たちトライバルの主戦場であるマーケティングの世界でも、消費者の生活活動を理解するソースとして、また、商品やブランドへの好意度を左右するコンテンツとしても、画像・動画はますます重要なものとなってきています。

 

そんな画像・動画をモバイルアプリケーションで扱おうと考えたとき、意外とデザイン・実装において考慮すべきポイントが数多く存在します。さまざまな拡張子やメタ情報との闘いも待っています。

もちろん、OS標準のコンポーネントやUIはあります。しかし、いわゆる「いい感じ」のビューアが欲しい、となると実装が必要となる……という状況は多くの方が経験したことがあるのではないでしょうか。

 

私たちが欲しかったビューアの「いい感じ」とは

この「いい感じ」がプロダクトやサービスの特徴になる訳ですが、私たちが今回画像ビューアに求めた「いい感じ」は以下のような項目が挙げられます。

  • ページネーションを持つスライドショー
  • ダブルタップでズームイン/ズームアウト
  • デバイス上にない画像データの表示とキャッシュ
  • ふわっとしたアニメーション

言葉にするとこれだけですが、実装する際にこれらのイメージを持つ大切さは、エンジニアの皆さまならご理解いただけるのではないでしょうか。

 

これらの「いい感じ」をまとめると「シンプルである」ということがポイントと言えます。

 

画像ビューア単体として考えると、とても小さく派手さのない要素ばかりです。しかし私たちは「アプリケーションとそのアプリケーションを介して提供するサービス全体」として考えることを重視し、あえてこれらにポイントをおいて開発を行いました。

 

今回の「FMImageView」も、私たちが展開しているメディア「Funmee!!」のiOS版アプリに実装するものとして開発しましたが、「アプリケーションとそのアプリケーションを介して提供するサービス全体」として、画像によりユーザー間の相互刺激を促したりユーザーの趣味嗜好を発信しやすくする、という狙いがありました。

 

これは、「画像を通した体験や価値」であり、「画像を扱うことによる体験や価値」ではありません。つまり、「画像を扱うことだけでユーザーへ提供できる価値は決まらない」のです。

もちろん、UI/UXがユーザーに与える印象や体験はとても重要なポイントです。直感的であり、かつユーザーを驚かせない、理解できるUI/UX、そして操作性も失いたくありませんでした。

 

エンジニアがコードを介してユーザーに提供できる価値とは

皆さんも、日々コードを書く際、アドレナリンがドワーッと放出され「もっと書きたい!もっと作り込みたい!」という気持ちになったことがあるのではないでしょうか。

機能を充実させたい、インターフェースやAPIにこだわりを持ちたい、より格好良く、より速く……いろいろな想いを抱いて開発をしますよね。

 

しかし、そのこだわりや想いの全ては、本当にユーザーが求めているものでしょうか?サービスを使うユーザーが、本当に欲しいモノは何なのでしょうか?

「“ユーザー”って言葉にするのは簡単だけど、どんな人が使うかなんて分からないから、具体的に考えても……」という方もいらっしゃるかもしれません。ですが、私たちは具体的なユーザー像(ペルソナ)を描き、その人にどんな価値を届けるべきかを常に想定すべきだと考えています。

 

特に私たちは、ユーザーは「どんな体験をして」「どんな時間を過ごしたいと感じているのか」を大切にしています。

 

エンジニアの思想をコードで示すことを諦めない

  • もっと書きたい、という気持ちをぐっとこらえる。
  • 書いたコードがユーザーに届いた瞬間を想像する。
  • そのコードから生まれたプロダクトがユーザーに提供するベネフィットを諦めない。
  • ユーザーのことを考える。
  • ユーザーのためにコードを書く。

私たちはこうした気持ちや姿勢を忘れてしまわないように、日々心がけています。

 

もちろん、ふと忘れてしまったり、優先度が下がってしまうときもあります。

特に、マーケティング業界はとても進歩が早いので、毎週のようにプロダクトへのニーズや必要な知識が変化しますし、その気持ちや姿勢を忘れていたことに後々気づくこともあります。

 

そんな状況下でも、エンジニアとしての気持ちや姿勢を大切にしたい。諦めたくない。世の中をより良くしたい。

 

そのために、私たちはソースコードにその気持ちや姿勢を込めて、OSSを公開しています。OSSとして公開することで、より多くの方に私たちの気持ちや姿勢といった“哲学”を知ってほしいのです。

 

さらにベトナム現地法人のエンジニアとのコラボレーション

実は、今回この「FMImageView」は、ベトナムにある現地法人「TMH Tech Lab.」のメンバーだけで開発をしました。

普段は離れた場所で活躍しているメンバーによる開発ですが、上記の“哲学”はしっかり反映されていると思います。

これは、会社として、そしてチームとして普段から開発に対する姿勢が共有できていた成果でもあります。



今日は、画像ビューアライブラリ FMImageView 公開のお知らせと私たちがOSS活動する目的について書かせて頂きました。

 

トライバルでは、ユーザーのためにコードを書きたい! コードに“哲学”を込めたい! というエンジニアを絶賛募集中です!

Swift、Golang、 PHP etc. 言語に関わらず、「適切な技術を適切な場所に」をモットーにしています。

 

ぜひお気軽にお問い合わせください!

日本人の同僚とのコミュニケーションの壁を越える経験

皆さん、こんにちは。

トライバルメディアハウス ソリューション開発部のザンです。

ベトナム出身です。

 

前回「TMHの3年目になったばかりのエンジニアとして振り返り」というブログを公開しましたが、ご覧いただけましたでしょうか。

 

※まだご覧いただいていない方は、良かったら、以下のリンクにてご覧ください。

tech-tribalmedia.hatenablog.com

 

その中で、日本の企業におけるコミュニケーションの壁も少しだけ話しましたが、今回もっと詳しく話したいと思います。

 

日本企業で働く外国人として感じる、日本人の同僚との“コミュニケーションの壁”をご紹介し、その壁をどのように越えるかを自分で考えたことをみなさんに共有したいと思います。

 

さらに、日本人の方に向けて、もっと外国人の同僚とスムーズにコミュニケーションできるように、覚えておきたいポイントも共有したいと思っています。

f:id:tribalmediahouse:20180830170854j:plain

 

1. 見えない壁

 

まずは言葉や文化などの違いにより、外国人社員が日本人社員との間に「見えない壁」を感じたり、コミュニケーション上のトラブルが発生したりするケースも多いと思います。

 

どんな見えない壁があるか、詳しく説明します。

 

■言語の障壁

 僕は数年日本語の勉強を続けていますが、なかなか日本語が難しいと感じています。

なぜ日本人とうまく話せないのかをよく考えてみると、以下の問題があることに気づきました。

 

  • 聞き取りきれない

日本で働いている外国人の日本語の能力は、日本語能力試験のだいたいN3~N2レベルだと思います。そのレベルであれば、日本語をかなりよく使えて、普通のコミュニケーション(生活のコミュニケーション) について問題なくできると思います。

 

しかし、日本人の話す日本語を理解するためには、さらなる壁を越えなければなりません。職場では、日本人の同僚がよく長い文章を使ったり、難しい言葉を使ったりします。また、話すスピードが早いことがあります。

 

そのために、ある程度日本語の能力を持っている外国人の方でも、聞き取れず困ることが多いと思います。

 

  • 聞き取れたと思ったけど、実は別の意味を理解する

さらに、これはちょっと危ないケースですよね。これもやっぱり日本人とコミュニケーションをするときに、よくあるケースです。

 

前述した通り、外国人は、日本人の同僚が話した際、内容を100%聞き取ることは難しいです。

 

そのため、聞き取れた80%,または70%の内容から、残りの部分を判断します。そうすると、判断が少しずれ、話がかなりずれることがあります。

 

■コミュニケーション力の問題

日本で働いている外国人はだれでもコミュニケーションの能力が高いわけではありません。

 

その上、母国語ではない日本語を考えて、テンポよく話さないといけないから、話している内容が混乱するケースが多いです。

 

混乱してしまうと、本来もっている日本語の能力を発揮できなくなるので、うまく話せなくなってしまいます。

 

2.壁を越える

 

壁は多くて、高いですが、越えないといけません。

 

ただ、どうやって越えられるか?人によって、いろいろな方法があると思いますが、自分の経験から、以下にいくつかのポイントを共有したいと思います。

 

■日本語の勉強を積極的に続けること

日本語の勉強は必要だと思います。いつでも、どこでも(職場、生活、日本語クラス、また自習など)多くの言葉、文法をできる限り勉強したほうがいいと思います。

しかし勉強は終わることはありません。勉強できたことをよく活かして、話していきましょう。

 

■大切な話なら、終わりにメインの内容を復唱する

大切な話なら、話の終わりに、メインの内容が漏れないように復唱して、相手に確認してもらうと安心だと思います。

 

■話したい内容を準備すること

事前に話の内容が準備・整理できたら、話す時に、自信を持って、あまり混乱せずに、スムーズにコミュニケーションできると思います。

 

■日本の文化を理解するだけでなく、同僚を理解する

日本で働いている外国人が日本の文化を理解しなければならないことは当然だと思います。

 

ただ、文化理解だけではなくて、できる限り日本人の同僚を理解して、スムーズにコミュニケーションできるようになった方がいいと思います。また良い関係を構築しましょう。

 

■自分のコミュニケーション力をアップするべき

日本語のひとつひとつに問題がなくても、伝え方が良くないと、話したいことをなかなか伝えられないということを経験しました。

 

難しい問題だと思いますが、ある程度効果があるいくつかのTipsを共有したいと思います。

  • もっと簡単な言葉で考える
  • 伝えたい内容(一番大切な内容)をまず伝える
  • 主語が抜けずに短文で伝えた方が相手はわかりやすい
  • 難しい話しなら、小さく分割して、1つずつ説明する

 

3.日本の同僚のみなさまにお願いしたいこと

外国人の方々に向けたTipsを書いてきましたが、さらに、日本人の同僚のみなさまにも、意識的に心掛けることで、外国人社員とのコミュニケーションをスムーズに進められるコツを紹介しようと思います。

  • 思っているよりも、さらにゆっくり、はっきり発音する

 

  • 一つの長文よりも、複数の短い文にして伝える

→ 外国人にはより話の内容が分かりやすくなります

 

  • 主語や目的語を明確にするように意識する

 

  • よりわかりやすい、シンプルな言葉を選ぶ

→意味が同じ(似てる)言葉がたくさんあると思いますが、その中で一番わかりやすい(普段よく使われる言葉)を使ったほうがいいと思います。とくに打ち合わせをするときです。

 

  • 打ち合わせなどの結果を復唱させる

→ 打ち合わせの際、話のポイントなどについて、外国人社員に声を出して復唱してもらいます。そうすると、積極性を養えて外国人社員が質問しやすくなる効果があると思います。

 

  • 一緒に働いている外国人の同僚の国を少しだけでも知る

 

  • 相手の日本語能力を理解する

→ 相手の日本語能力を理解することで、それにあった話し方・言葉を意識できるようになると思います。

 

4.最後に

日本で働いている外国人には、コミュニケーションの壁がたくさんあります。

 

苦労すると思いますが、「もっとスムーズにコミュニケーションできるようになりたい気持ち」が大事です。それを持って、1つずつ問題を改善しながら、紹介した壁をドンドン越えていきましょう。

 

また、一緒に働く日本人の同僚からの理解や支援も大事だと思います。ご紹介したTipsを使ってコミュニケーションがスムーズにできると、より良い結果がでると思います。

 

コミュニケーションはよくキャッチボールに例えられます。伝えたいことを相手に投げたり、相手から受け取ったりすることによって情報交換し、お互いを分かりあうことですね。

つまり、1人だけで頑張ってもコミュニケーションになりませんね。

会社では日本人社員と外国人社員がスムーズにコミュニケーションできるために、相互理解したり文化や言葉の障壁をひとつずつ越えたり、お互いに協力することは大事です。それができれば、素敵なグローバル企業への第一歩になると思います。

一緒に頑張りましょう。

外部ライブラリに依存しない Pure Swift な FMPhotoPicker を公開しました

こんにちは。トライバルメディアハウスの高田です。

 

このたび、トライバルメディアハウス(以下、トライバル)初のOSS(オープンソースソフトウェア)であるツール「FMPhotoPicker」をトライバル公式Githubアカウント(@tribalmedia)にて公開しました!

このブログでは、このツールがどんなものなのか、また開発背景についてご紹介したいと思います!

github.com

f:id:tribalmediahouse:20180815191447p:plain

 

FMPhotoPickerについて

「FMPhotoPicker」は、iOS版アプリのための画像選択・画像加工のツールです。

 

コンセプトとして大切にしたのは、私たちが展開しているメディア「Funmee!!(https://funmee.jp/)」のiOS版アプリ開発時に画像選択ツールや画像加工ツールを選定するうえで悩まされた「外部ライブラリとの依存関係を持たない」ということです。

また、コンフィグ周りも実用的なツールになるよう配慮をしました。

MITライセンスとして公開しています!どんどんご利用いただき、コントリビューションしてくださいませ!

 

具体的な使い方等は、READMEをご参照ください。

 

デジタルマーケティング会社がOSS貢献する事になった背景

今回、デジタルマーケティング会社であるトライバルがOSS活動をし、貢献するにあたり、悩んだり検討したことがいくつかありました。

 

トライバルでは、人類にオドロキと感動を提供するぞ! 人生をもっと熱狂させるぞ!!という熱い想いを持って、おもにデジタルマーケティング分野のご支援を行っており、私が所属するソリューション開発部では、プロダクト・ツールを中心にチームで開発・運用をしています。

 

そんなトライバルの数ある事業の一つに、「Funmee!! 」というメディアがあります。

このメディアサイトのiOS版アプリ開発にあたり、画像選択・画像加工の機能が必要となったのが、この「FMPhotoPicker」開発のきっかけでした。

 

当初は外部の有料ツールやライブラリを検討していましたが、いざ自社のプロダクトとして採用するとなると、いくつか問題点がありました。

  • 依存関係

これは開発者の定めではないでしょうか。さまざまな依存関係と上手くやっていくのは必要なことですが、“画像選択・画像加工をする”というシンプルな動作であるにも関わらず必要以上の依存関係に悩まされるのはもったいない、と考えました。

  • 適度な設定値

これも、あるあるではないでしょうか。過剰な設定値が必要であったり、設定値のインジェクションの難易度が高いというパターンは少なくありません。

自分たちが本当に欲しい機能を必要な大きさのスコープで振る舞ってくれるツールが欲しい、という想いが強くありました。

  • コスト

個人的に、素晴らしいツールにはガンガンと課金する課金厨ですが…会社のプロダクトとなると、そうはいきません。

私たちのプロダクトのライフサイクルやサービスの提供形式などを考慮すると、ツールの利用料を払うよりも自社で開発し、メンテナンスまで行う方がメリットが大きいと判断しました。

 

これらの理由から、画像選択・画像加工のツールを自分たちで実装することを決断しました。

この決断は、上記のメリット以外にも、OSSにすることで自分たちの資産にもなり、世の中の役にも立てる、というメンバーのモチベーション向上はもちろん、メンバーがOSS活動へさらに興味を持つようになるといったメリットもありました。

 

グローバルな視点でコラボレートしていくこと

 この「Funmee!!」iOS版アプリ開発にあたって、ベトナムにある現地法人「TMH Tech Lab.」のメンバーとチームを構成しているという点もトライバルらしいユニークな取り組みだと考えています。

 

日本とベトナムの開発チームが、自社ツール・OSSの開発を行うという国をまたいだコラボレーションはとても刺激的でしたし、このコラボチームをリードしてくれた来日3年目のベトナム人エンジニア Cong(コン)のナイスプレーにはとても助けられました。彼を中心とした素晴らしいメンバーのおかげで、良いOSSが作れたと思います。

 

また、UIについて、iPhone、 iOS、 Swiftの規約や推奨に従いながらにはなりますが、ベトナムの視点も交えながら議論し進められたのは、貴重な経験だったと思います。

 

今日は、pure Swiftで使える画像選択・画像加工ツール「FMPhotoPicker」の紹介と、その開発背景について書かせていただきました。

 

近日、第二弾のOSSも公開予定です! お楽しみに!!

 

トライバルでは、Swiftを書きたい! グローバルなチームで開発をしたい! 俺もOSS貢献したい! 人類を驚かせたい! というエンジニアを積極募集中です!

 

ご連絡お待ちしております!

アカウント統合に向けて動き出したLINE、今後アカウント運用はどう変わる?

※ この記事はトライバルメディアハウスブログの以下の記事から転載しています。

www.tribalmedia.co.jp

 


 

こんにちは。トライバルメディアハウスでLINEマーケティングを推進している高松です。
 
2018年6月28日(木)に「LINE CONFERENCE 2018」が開催され、「リデザイン」をテーマに、今後のLINEの事業戦略に関する発表がされました。今回は、その中でも現在LINE アカウントを運用している企業、今後LINE アカウントの開設を検討している企業がとくに知っておくべき内容についてご紹介します。
 
 
《複数タイプあったLINE アカウントを統合》
 
これまで複数に分かれていたLINE アカウントタイプが統合される、というものです(※)。利用料金を見直し、より多くの企業にとって使いやすいアカウント形態を目指すということになります。
※2018年7月時点では導入時期未定
 
 
《現行のLINE アカウントタイプ》
以前「LINE 各企業アカウントの特徴」という内容で、LINEの企業アカウントの種類と特徴を解説しました。

この記事でも紹介した4つのアカウントタイプとLINE@の特徴について、改めて簡単にご説明しましょう。
 
・LINE 公式アカウント
もっともポピュラーなアカウントタイプで、友だちとなったすべてのユーザーへ一斉にメッセージ配信が行えます。マス的な目的で活用されることが多く、サービスやブランドを訴求し、認知向上や理解促進が期待できます。
 
・ビジネスコネクトアカウント
LINEのAPIを活用することで、ユーザーの属性ごとにメッセージが配信できます。ユーザーにあわせた最適なメッセージ配信が行え、エンゲージメント向上や、サービスの利用率の向上が期待できます。
 
・API型公式アカウント
公式アカウントとビジネスコネクト両方の特徴をあわせ持つのがAPI型公式アカウントです。もっともオールマイティなアカウントといえます。
 
・カスタマーコネクト
ユーザーから届いたメッセージへの対応が可能です。botなどの自動対応や、有人対応、また音声通話との連携ができます。ユーザーやオペレーターの負担を減らし、状況に合わせたカスタマーサポートを行うことができます。
 
・LINE@ 
中小規模の企業や、店舗などで運用されるアカウントタイプです。すべての友だちへのメッセージ配信ができ、1対1のトークなどが行えます。ただし、プロモーションなどの実施に制限がある点には注意が必要です。
 
今回はこれらが統合され、一つのアカウントとして新たに「LINE 公式アカウント」としてリデザインされます。
※ビジネスコネクトとカスタマーコネクトついてはそれぞれオプション機能となり、利用にはLINEのAPIを利用した開発が必要となります。
 

 
 
《統合によって予想されるアカウント運用の変化》
 
今回発表された変化は以下の内容です。
 
・複数タイプあったアカウント機能の統合
・月額費用0円からスタートできるプラン
・従量課金制の導入

 
もっとも目を引く変化は、従量課金制になるということでしょうか。
 
これまでのLINE 公式アカウントのように一定のアカウント費用を支払い、複数回の一斉配信を行っていくという料金体系ではなく、使った分(配信メッセージ数分)だけ料金を支払うという形式に変わります。これにより各企業の予算にあわせたLINE アカウントの運用が可能になります。
 
ただそのためには、アカウントの運用において、常にすべての友だちにメッセージを配信するスタイルではなく、適切な友だちグループに対して、計画的にメッセージ配信をしていくことが重要になります。アカウントが統合されたら、自社はどのような運用スタイルをとるのか? など改めて考えてみてはいかがでしょうか。
 
トライバルメディアハウスでは、各企業さまの運用スタイルに合わせたLINE アカウントのコンサルティングを行っています。またLINEのAPIに対応したEngage Managerの提供も行っていますので、興味のあるご担当者様はお気軽にお問い合わせください。
 
LINE ビジネスコネクトを活用したマーケティング支援の特設サイトはこちら
 
LINE ビジネスコネクトを活用したサービスの企画・運用事例はこちら
 
LINEのAPIに対応した、ソーシャルメディアアカウント統合管理ツール「Engage Manager」はこちら

エンジニアがブログを書く/情報発信する上でおさえておきたいポイントとは?

新年度もスタートし、もう1ヶ月…時が流れる速さに戦々恐々としています。どうも、今年度このブログ

Tribal Media House Engineering Blog

の運営を担当することになりました、トライバルメディアハウス ソリューション開発部の阿部です。このブログで色々と ためになる/役に立つ/いい息抜きになる 情報をメンバー共々発信していければと思っています。

 


 

さて、2018年度1本目の記事はこれを書いておきたい!ということで、今回のお題は「エンジニアがブログを書く/情報発信する上でおさえておきたいポイントとは?」。

 

気軽に情報発信できる場が増えてきている中、書かないのはもったいない。ただ、闇雲に書いても 伝わらない、読まれない のは実に悲しいし気持ちが折れる…。

 

でも実は、ちょっと意識するだけでクオリティがぐっと上がるかもしれない。そこで、エンジニアがブログを書く/情報発信する際に、意識すると良い基本的なことをまとめたいと思います。

実はこの記事、社内の若手エンジニア向けに書いていたものになります。(少し説教臭いかも)

ただ、「心機一転、今年度こそブログ書くぞ!」という人もぜひご覧頂ければ幸いです。

 

f:id:tribalmediahouse:20180427091816j:plain

 

 

 

まず目指したいのは 「最後まで読まれる記事」・「一人にでも役に立つ記事」

ブログを書く/情報発信する目的はいろいろあり、それによってさまざまな“良い記事”がありうる。

大量の情報が載っていれば良い記事なのか、要点だけ書いてあれば良い記事なのか…そこには様々な答えがあると思いますが、共通して「良く書けたかどうか」の基準を置くなら、以下がいいのではないか、と思っています。

  • 最後まで気持ち良く読まれる記事か
  • 一人にでも「役に立った!」「あってよかった!」と言われる記事かどうか

 

最後まで読まれ、「役に立った!」と思わせられた記事は、以下を満たせていると言えます。

  • 意図した相手に、読みたいと思ってもらえた(興味をひく・内容にあっているタイトル/導入になっていた)
  • 詰まらずに読み進められた(わかりづらい単語や表現が無かった)
  • 読み終わって気持ちいいと思わせられた(十分な情報が載せられていた)
  • また読みたい、と思わせられた

 

まずは 「最後まで読まれる記事」・「一人にでも役に立つ記事」 、これを目指していきたいものです。

 

 

重要なのは “ゴールの設定”・“取捨選択”・“来た道の地ならし”

それではどうすれば 「最後まで読まれる記事」・「一人にでも役に立つ記事」を書くことができるのか? 第一に重要となるポイントは ゴールの設定 と 取捨選択 ストーリー作り地ならし にあります。

 


「① ゴールの設定」 〜ひとりよがりではない記事作り〜

エンジニアが情報発信の際についついやりがちなことが “自身の経験の羅列” 。

「自分の時はこうだったから、それを書こう」とシンプルに考えてしまいがちですが、
そのように書かれた記事には以下のような課題がありがちです。

  • その時・状況でしか役に立たないメモでしかない(前提の環境が違うと役に立たない、システムの仕様変更ですぐに使えなくなる)
  • 異なるスキルセットのエンジニアが読んでも、前提知識が異なり分からない

 

それではどうすればいいのか、それが「ゴールの設定」になります。

  • 読み手が誰か(どんなスキルを持つ人なのか、どんなことに困っている人か)を明確にイメージしてみる
  • 読み手が読み終わった後、どうなっているか(何ができるようになっていればゴールか)

 

「どんな人にどんな効果を与えたいのか」を考えることでどんな順番で話をすべきなのか、どんな補足が必要なのかが見えてくるはずです。

 

そう、ひとしきり読んでから「ミドルウェアのバージョン違うから、この情報使えないじゃん!最初に書いておいてよ… :( 」というあの気持ちを、他の人に味わわせてはいけないのです。

ネットの向こう側にいて、同じようなことで頭を抱えているエンジニアへ届けるように、ゴールと注意点を考えてみましょう。


「② 取捨選択とストーリー作り」 〜捨てることで、ストーリーを輝かせる〜

ゴールと気をつけたいことが決まったら、「さあ書き出そう!」という前に一呼吸。

 

いきなり走り出す前に「書くべきこと」「書かなくてもいいこと」を決め、それを「どんなストーリーで見せるか」を決める、そんないわば “準備体操” をすることで、より素晴らしい記事にすることができます。

 

『新しい文章力の教室 苦手を得意に変えるナタリー式トレーニング』(Amazon)というライティングの良著がありますが、そこで紹介されている内容をベースに、私は構成を考えるにあたって以下のSTEPを踏むようにしています。

 

 

  1. 書こうとしている情報を、まずは“箇条書き”でメモに起こす
  2. 箇条書きされたそれぞれの情報を眺め、足りない情報を追加していく
  3. それぞれの情報を、その重要度からA・B・Cの3段階に分ける
  4. 思い切ってAの情報だけ取り出し、並び替えてストーリーを付ける
  5. ストーリーを飾る情報として、Bの情報で肉付けする
  6. どうしても必要なCの情報だけ、最後にトッピングする

 

全体を通して、いわばAの情報は“ストーリーの盛り上がりポイント”、それを強調するのがBの情報になります。Cの情報は無くてもいいものの、実はトッピングすることで物語全体が輝くこともあるかもしれません。

 

このステップを踏むことで、“記事の台本” とも言えるメモができたはず。これさえあれば、記事はすぐに書けるのではないでしょうか?早速書いてみましょう!


「③ 地ならし」 〜穴や出っ張りをなくす〜

台本にしたがって記事が書けたでしょうか?それでは投稿!の前に、ぜひやっておきたいのが “地ならし” です。

ゴールを決めて台本を書いてもやはりつきまとうのが、自分の経験・知識を前提にしてしまっているが故の

  • “出っ張り”(書きすぎていて読みづらくなっている、理解しづらくなっている)
  • “穴”(自分にとって“当たり前”だから、と省略してしまっている)

が起きてしまっていること。

 

ぜひ、最後のクオリティアップのために、そんな“出っ張り”や“穴”を地ならししておきましょう。具体的には以下を実施してみるのをオススメしています。

  • 記事を声に出して読み上げる(誤字や表現の引っかかりに気づくことができる)
  • 一般的でない略し方、表現を使ってしまっていないかチェック(迷ったらGoogle検索のHit件数で比較しましょう)
  • 1晩おいて、改めて読み直してみる(別の人が書いた記事として見てみると、意外と誤字脱字に気づける)
  • ディスプレイから離れて、記事の濃淡を見てみる(黒く見えるのは、漢字が多い/スペースが少ない証拠)
  • 冗長になる箇所は、別記事への切り出しやリンクを検討する(長すぎる記事も、最後まで読まれない)

 

あとは、とにかく書いてみる!読んでもらう!

さて、ゴール決め〜書いた後のチェックまでをまとめてきました。あとはいちばん重要なこと「とにかく書く」というのを実践するのみです。

書いて、さらに読んでもらいフィードバックをもらうことで、書くプロセス・ポイントが自分の中に染み付いていくことで、発信がどんどん楽に、クオリティが上がっていきます。

いろいろと書いてきましたが、結局は「とにかく書いて、読んでもらう」が大正義なのかもしれません。(臆するよりも行動あるのみ)

 


 

最終的に「行動あるのみ!」という着地になってしまいました笑
いかがだったでしょうか?

新年度、ぜひ情報発信にチャレンジしてみて欲しいと思います。(特にトライバルメディアハウスの若手エンジニアに期待大です!)