黒は誰にでも似合う万能色じゃないのだ～パーソナルカラー診断を受けてみた～
どうも、みりです。
先日初めてパーソナルカラー診断を受けてみたので、そのレポです！
パーソナルカラーとは
その人の魅力を引き立てる色の系統をスプリング、サマー、オータム、ウィンターで現すものです。
今回Nちゃんがパーソナルカラー診断をできるということで、やっていただけることになりました。
パーソナルカラー診断
受ける前の私
一応、いろいろ試してみていて以下の認識でした。
こんな感じです。ブルベのウィンターかなーと。考えてました。
さて、いよいよ診断です。
診断の流れ
最初にNちゃんから説明をしてもらいました。
- パーソナルカラーとは
- パーソナルカラーの効果
- なにをやるのか
- ４シーズンの説明
- テストカラー診断
- ベストカラー診断
という流れ。
ここで初めて知ったのが、サマーの色がひまわりや青空をイメージするきっぱりはっきりした印象の色群ではなくて、霧がかっている雰囲気、紫陽花のようなパステルカラーのような色が多いんですね。意外でした。
テストカラー診断
すっぴんで大きな鏡の前に座ります。テストカラー診断でいろんな色を顔に当てて似合う色を残していくということをしました。
死んだ顔で写真を撮られていたのでどうぞご覧下さい笑
ここで、
- 色相（イエローベース・ブルーベース）
- 色の明度
- 色の彩度
- 色の清濁
を軸に似合う色を残していく、という感じでした。
ここで面白かったのが、私はパーソナルカラーを見つけるのが難しい人間だといわれたことです。え、なにそれ４シーズンに振り分けられるんじゃないの？
どうやら人間というのはそんなに簡単なものではなく、４シーズンで分けられる人もいれば、そこに当てはまらない人もいるのだそう。面白い。
テストカラー診断結果
布を当ててみて残った色がこちらです。「みりさんは春以外のどれかです！」
なるほど、スプリングではないだろうとはわかっていましたが、顕著でした。それにしてもほかのシーズンもなかなか残っています。
ベストカラー診断
テストカラー診断をもとに、Nちゃんが布をいろいろ選んでいるのを横で眺めながらぼーっとしていたら、こちらの色が並べられました。
ここに並べられた色の特徴は
- 中〜低彩度
- 暗清色 or 濁色
です。原色（清色）はてかてかしちゃって似合わないとのことだったので、あっていましたね！あとは見事に明るいパステルカラーは残ってきませんでした。笑
これらの色を実際に当ててみながら、色の組み合わせを見ました。
これをもとに、インナーとかで合いそうなベーシックカラーというものを組み合わせていきます。
黒や白、グレイ、ベージュ、オフホワイトなどを合わせていきます。
ここで衝撃の事実、黒は誰にでも似合う色じゃないということ。黒を選んでおけば間違いないでしょ、って思っていたんですが、ネイビーを黒として使った方がいい人とかそういう人がいるそうです。面白い。
ちなみにここで安心したのは私は黒はいける人でした！！！！！よかった！！！！
こんなカラフルな色を組み合わせたことなくて、本当に楽しかったです。
パーソナルカラー診断結果
ということで、結果です！
オータムメインで、ウィンター（時々サマーもいける）
オータムはイエベで他の2つはブルベ、黄身と青味にはそんなに影響されないタイプ。（思ってる以上にイエロー寄りも濃さがあれば似合うタイプ✨）
得意：中〜低彩度、暗清色 or 濁色
苦手：高明度かつ、清色（原色） or 明清色
似合う色の範囲が広いので、そこは素晴らしい
冬も夏もどちらもブルベ、メインのオータムがイエベ
なのでブルベとも呼べない奇跡の女性なのです！w
なんと奇跡の女性呼ばわりされました笑
パーソナルカラーのモデルすると、難易度が高い人に分類されるそうです。良い練習台ですね。
今度服を買うときは今回の結果をもとにいろいろ冒険してみようと思います。
おまけですが、私の次にパーソナル診断を受けたTちゃんが、THE・スプリングだったので、私と正反対ですごく見ていて面白かったです。
GYOMUハック人材のスキルセットって？
この記事はGYOMUハック/業務ハック Advent Calendar 2019の7日目の記事です。
こんにちは、GYOMUハックエンジニア歴5年目のみりです。今日はどんなスキルを持った人がGYOMUハックに向いているのかということを考えてみます。
GYOMUハッカーに共通していたと感じること
いままでGYOMU Hackers Guildというコミュニティをやったり、登壇をしたり、TwitterやFacebookを通して様々なGYOMUハッカー達とであってきました。
そのうえで、皆さんに共通していたなと感じることを連ねてみます。
- 共感力が高い
- 想像力が豊か
- 課題を俯瞰できる
- 人を助けたいと思っている
- 楽をするための努力は惜しまない
- 課題整理が得意
ふむ。それぞれ説明してみようと思ったのですが、昔の自分がなんとなく文字にしていたので、詳しい雰囲気は記事を置いておきます。
自分のパーソナリティ
私の人となりを知る人は、私はGYOMUハックという仕事に向いているといいます。そこで自分ってどんな人間だというところを公開してみます。
クリフトンストレングス
Gallupのクリフトンストレングスによると、私は以下が強みとのこと。（以前はストレングスファインダーで知られていましたね）
なんとなくまとめると、個で人をとらえて、一人でいろいろ考えて戦略的に実行するのが得意？
これは同僚に言われたことは、私は「誰のことも否定せずに、人のいいところを言葉にできる」ところが強みとのこと。なるほど、個別化はとても私の中で大きな属性なのかもしれません。
16personalities
16personalities、やるたびになんだか毎回結果が違うので、あんまり参考にならないかもしれませんが、一番読んでしっくりきたのはこれです。
人助けを人生の目標とし、救済活動に従事したり、慈善活動を行ったりしていますが、提唱者型の人達が、こうした活動を通じて真に情熱を注いでいるのは、問題の核心に迫り、人々を救済する必要が全くない環境を築き上げることなのです。
これ、めちゃくちゃGYOMUハックだと感じたのを覚えています。
ちなみに私はこういう診断で、一人にしてくれっていうのがよく出ます（笑）
CIY-TOTEM
次にCIY-TOTEMによるとこれです。
決断力と行動力を合わせ持った、生まれながらのリーダータイプ。
人の上に立ち、組織やチームをより良い方向へと導きたいという気持ちが強い人です。論理的に考えることが得意で、何かを判断するときには論理的なつじつまがあっているかや根拠があるかを重視します。
また、自分の考えも分析的・論理的で筋道を立てて考えることができ、それを理路整然と伝えることが得意です。
なるほど、リーダーっていうのはよくわからないけれど、これもGYOMUハックっぽそうです。
さいごに
最後にまとめ、といきたいところですが、まとめられませんでした（笑）
いろいろつらつら書いてみましたが、GYOMUハックという分野がまだ新しいこともあって、スキルセットの言語化って難しいなと思いました。
紹介している診断はチームビルディングなどでも楽しいので、ぜひやってみてください。
GYOMUハックのプロセスについて考えた
この記事はGYOMUハック/業務ハック Advent Calendar 2019の1日目の記事です。
こんにちは、GYOMUハックエンジニア歴5年目のみりです。今年も始まりましたAdvent Calendar！どんな記事が続くのか楽しみにしつつ、私はGYOMUハックのプロセスについて考えてみたことを書いていくことにします。
GYOMUハックのおしごと
そもそもGYOMUハックって何をやっているのという方が多いと思いますが、マーケやセールス、サポートなどのエンジニア以外のBizメンバーの業務の基盤をサポートする社内SEみたいなイメージです。
こんな感じの記事も書いているので、ぜひ読んでみてください！
プロジェクトのやっていき
プロダクトの開発においては開発ロードマップがあり、そのロードマップにそって機能開発することが多いかと思います。GYOMUハックにおいては、事業の成長曲線をイメージしながら未来を見据えて基盤を作る必要があります。事業部が今やりたいという施策や業務はその時点で機能提供できている必要があり、その機能提供のためのプロジェクトを実施する必要があるのです。
ここで難しいのは、その時点で事業部側はその機能を求めていないことも多い、ということです。GYOMUハックのプロジェクトの特性としてステークホルダーが多く巻き込み型のプロジェクトが多いですが、そのプロジェクトメンバーがイマイチなぜやるのかに納得しないとなかなかプロジェクトはうまくいきません。
なぜやるのか、なぜ今なのかをロジカルに説明できない案件は進められないですし失敗するので、いつやるのかのタイミングを計るのかもかなり重要なスキルになってくると思います。個人的にはGYOMUハックロードマップを作成していて、それをもとに話をできると良いと考えています。
プロジェクトを始める前に
プロジェクトを始めるときに最初にやらなくてはいけないことはステークホルダーをおさえることです。
そのプロジェクトで解決したい課題、成し遂げたいことを話し合います。ここでGYOMUハックは話を聞いてある程度どんな実装が必要か、どれくらいの工数がかかるのかの見積もりをします。完全に脳内試算です。その場でわからないことは持ち帰ります。
そして実現難易度と、業務インパクト、他の案件の状況を天秤にかけて優先度を決めます。
プロジェクトが始まってまず最初にやること
プロジェクトが始まってから、最初にやらなくてはいけないことはプロジェクト終了後の理想状態はなんなのかをイメージしておくことです。事前準備は大事なので、それくらいまでは心の準備をしておきます。
次にステークホルダーを集めて、ゴールの認識合わせをします。何が達成さたら・実装されたら、プロジェクトとして終了なのかを決めます。
それが決まったら、いつまでになにをやるのか、やらないのかをきめます。大まかなスケジュールを決めることによって、全員の認識があうので、すり合わせは大事です。
理想状態を定義するには
ここで私がプロジェクトの序盤でかなり大事にしていることが１つあって、それは全員に理想を語ってもらうことです。課題ベースで話をすると、現状＋αの何かしかアイデアが出ないことがあります。目の前の業務と今までの業務にかなり引きずられるためです。
そんなとき、私は1〜2時間たっぷり時間をとって、今までの業務は全部忘れてどうなるのが理想なんだろう、を一緒に考えるようにしています。最初はピンとこないんですが、例えばこんなのはどう？など簡単な例を出してみると、結構刺激されてみんなのアイデアが出るようになります。
そうして一緒に理想状態を定義して行くと、たどり着きたい状態が共通認識としてイメージしやすいです。
進めていきかた
いざプロジェクトが開始したら、あとはひたすらスケジュールに合わせてタスクをこなしていくだけになるのですが、定例は必ず入れるようにしています。
プロジェクトのスピード感で、WeeklyかTwice a Weekで定例を行います。
定例の中では、
- タスク進捗
- 状況の変化
- スケジュールへの影響
- 問題点
を確認します。日々状況が変わるので、状況の変化によってスケジュールに影響がないか、プロジェクトを進めることに影響がないかを逐一確認をします。
あとはひたすらタスクを消化していくのみです。邁進！
クロージング
ゴールで決めた判定基準が満たされたらプロジェクト自体は完了となります。
その後、しばらくは不具合がないことを監視して、一旦監視体制はおわりです。
振り返り
リリースしてしばらくしてから、関係者を集めて振り返ります。これも物によってタイミングが重要なのでうまく見計らって振り返りの日程を決めてください。
KPT（Keep、Problem、Try）で、プロジェクトの進め方自体とリリースした物自体についてふりかえります。ここで、当初の目的が達成されたのかも判定します。
振り返りを行うことで次のプロジェクトの進め方などを改善していきます。
おわりに
言葉にして書いてみるとけっこうあっさりしていて当たり前のプロジェクト開発じゃん、みたいな感じになってしまいましたが、関わる人が多かったり、期日が決まっていたりするとめちゃくちゃ大変です。
きめ細やかなコミュニケーションが重要になってきますし、手を動かしながらプロジェクトを回す力が求められます。
GYOMUハックというまだ世間的には新しい領域を広めていきたいと思っていて、スキルの言語化や仕事のフレームワーク化を頑張っているところです。
世の中のGYOMUハックに携わるみなさんとのコミュニティを作っているので、もし興味のある方がいらっしゃったらぜひご参加ください！
GYOMUハックエンジニアが重要になる理由
freee株式会社で初代GYOMUハッカーとして、GYOMUハックチームに所属しているmiryです。
GYOMUハッカーとは社内SEやBPR、ITコンサルなどビジネス要件に対して社内のシステム構築・業務改善・課題解決を行う人たちの総称です。業務ハックとも言われますね。
今日は、GYOMUハッカーがこれから重要になるのではという話をしたいと思います。
エンジニアと一言でいってもいろいろいる
エンジニア、と一言でいっても最近ではいろんな役割のエンジニアが世の中にはあふれていますね。GYOMUハックエンジニア（以後GYOMUハッカー）もその一つです。
そんなGYOMUハッカーを4年近くやってきて、さらには2年ほどGYOMUハッカーのコミュニティ（GYOMU Hackers Guild）を運営してきて感じたのが、GYOMUハッカーの一番大きな特徴は、他のエンジニアと比べて業務におけるコミュニケーションの割合が大きいところではないかということです。
課題発見のためにも現場とのコミュニケーションが欠かせませんし、課題解決においても関係者へのコミュニケーションが欠かせません。コミュニケーションの相手も多いのも特徴だと思います。
GYOMUハッカーが携わるのは社内システムであることが多く、ユーザは社内のメンバーです。そういう意味で、もっとも顧客との距離が近くそして縛られやすいエンジニアなのです。
社内システムのかたち
そもそも社内システムってなんでしょう。
たとえば従業員の管理であったり、財務管理であったり、営業の顧客管理であったりなど、社内にユーザがいるシステムのことをいうのだと思います。
そのシステムも、内製していたり、外注していたり、SaaSを使っていたり、パッケージ製品を使っていたりとさまざまだとおもいます。
サブスクリプションビジネスが主流となっている昨今では、業務系のSaaSが台頭してきていて、ほとんどの企業が何かしらのSaaSのツールを使っているような時代がやってきています。
そういったSaaSのツールを導入する理由は様々かと思いますが、業務効率化とコスト削減が大きいのかなと思います。
すこし検索してみれば、世の中には便利なツールがあります。それなのにわざわざ自分たちで開発する必要はないよね、ということだと思います。
SaaSの導入で一番理解しておかないといけないことが、「ツールは導入したら終わりではない」ということです。
顧客管理のためにSales Cloudを導入しました、これで顧客管理ができるようになります！ いえ、なりません。そんな魔法のようなことが起きるのであれば、GYOMUハッカーなどおよびでないのです。
「業務の本質を捉えること」
業務改善をしようと、何かしらのツールを導入しようと思った時に、まずやらなくてはいけないことが、今行われている業務の本質を捉えることです。なぜその業務をやっているのか、どのように行なっているのか、それを整理して、シンプルなプロセスに落とし込むことが重要になってきます。
それができないときは業務が複雑すぎて、そもそものところに無駄があったり、考えすぎてしまっていることがあり得るので、インプットとアウトプットから考えるのもいいかもしれません。
とにかくいきなりツールを触ろうとしないで、業務の整理をするのです。ここでGYOMUハッカーはすごく活躍します。
GYOMUハッカーは基本的にその業務を行う人からしたら外部の人です。その人が外の視点から俯瞰的に業務を見つめて整理できるのです。また、エンジニアというスキルも持ち合わせているので、やりたいこと・とりたい数字をきいてデータモデルで考えることができるのです。
と、ここまではたぶんどんなエンジニアでもできると思うんです。でもそんな彼らとの決定的な違いは、普通のエンジニアだとそれを作っちゃおう！ってなると思うのですが、GYOMUハッカーはこれを解決できるツールはないか、と探すのです。
そして、ツールを用意して、このツールならばこのように解決できる、という道筋を提供します。
導入して終わりではない
いざ、さまざまなステークホルダーとコミュニケーションをとって、ツールの導入に成功しましたとなったとき、それでGYOMUハッカーの仕事は終わりません。
運用が定着化するまで見守ったり、困った時に手を差し伸べるのです。
今までとやり方が変わったことで、少なからず業務効率が下がります。そうすると人間は慣れていたやり方に戻りたくなるのです。
それをもっと簡単なやり方を見つけてはチラつかせたり、こっちの方がメリットが大きいよと声をかけたりして、新しいやり方に慣れてもらいます。
慣れてしまえばこちらのもので、気づけばいつのまにか以前のやり方より効果的に業務を回すことができている、という状態になるのです。
これがGYOMUハックの醍醐味ですね。
GYOMUハッカーの仕事は地味である
GYOMUハックは、コミュニケーションにつぐコミュニケーション、整理整頓、そして当たり前のことを当たり前に、簡単にできるようにすることです。
その基盤を作ることってとっても地味なんです。
地味なんですが、今のSaaS大航海時代で、とっても重要なポジションでもあると思います。SaaSの特性と業務の特性、両方を理解し、エンジニアリングで解決していく。そしてユーザに「あれ、いつの間にかよくなってる！」という体験を提供するのです。
しかし、実はただ依頼ベースで基盤を作るだけじゃありません。
ビジネスの成長の先を見て、この時までにこれを作らなければいけない、という先見の明も必要になるのです。ビジネスに寄り添い、その先を見据えながら現在の課題を解決するエンジニアなのです。
様々な役割のエンジニアが脚光を浴びてきていますが、GYOMUハッカーもそのひとつで、今後どんどん重要になっていくポジションなのだと思われます。
GYOMUハック―ビジネスチームとの二人三脚―
freee株式会社で初代GYOMUハッカーとして、GYOMUハックチームに所属しているmiryです。
これはGYOMUハック / 業務ハック Advent Calendarの14日目の記事です。
ビジネスチームの成長の歴史
会社はどんどん成長するもので、私の所属するfreeeも2012年の創業からぐんぐん成長してきました。
それにともなって、さまざまなファンクションのチームが生まれ、日々業務を行なって居ます。初めはエンジニアとサポートから始まったのですが、マーケティングとセールスが生まれ、カスタマーサクセスが生まれ、パートナーセールスやチャネルセールスが生まれ、とどんどん規模が拡大してきました。
このビジネスチームの急成長をエンジニアリングで支えてきたのがGYOMUハックです。
SaaSで乗り越えてきた３年間
freeeでは基本的にクラウドのツールを利用しています。セールスはSalesforceを利用していたわけなのですが、今思えば、Salesforceを利用していてよかったと思える3年間でした。
この急成長なので、1ヶ月後にはこのような業務が増えているからできるようにしてほしい、という急な依頼はざらにあります。
もし内製のツールだった場合、そもそもの要件に含まれていないので、機能改修が必要になります。しかし、Salesforceをはじめとする各種SaaSだと、機能自体は組み込まれていて、あとはどう使うかをカスタマイズしてあげればいいだけなので、かなり負荷が下がるのです。
円滑なハック〜改善〜のために
大切なコミュニケーション
コミュニケーションが大事とはよく謳われますが、私も本当にコミュニケーションが大事だと実感しています。
常日頃、ビジネスチームがどんな悩みを抱えているのか、雑談などでも聞けるようにアンテナをはっており、メンバーを見かけたら積極的に声をかけるようにしています。
そうすることで、相談するハードルを下げるようにしています。
あとは意図的にどんなことをやってきたのかを発信するようにしています。なるべく、表に出て、何か困ったらあの人に聞けばいいんだなという空気を作るようにしています。
課題把握は自分の目で
新しいものを作るにも、今あるものを改善するにも、まずは話を聞くところから始まります。その時に気をつけているのが、全部を鵜呑みにしないことです。
よく、「こういう機能をこう修正してください」みたいな依頼が来るのですが、そういうときは、何に困っていて、どういう状態にしたいのか」というヒアリングを行います。そうすることで、俯瞰して課題把握ができるのです。
また、実際に業務をしているメンバーの横で業務を眺めたりします。オブザービングと呼んでいるのですが、現場からあがる課題だけでなく、エンジニア視点でこれは実は課題ではないかというように気づけることが結構あるのです。
定着化はチャンピオンと共に
改善系のタスクの難点は「今できているのになぜ変えるんだ」です。
慣れている見た目やツールが変わるのはかなり大変です。しかし、メリットをきちんと説明し、GYOMUハックを進めなくてはいけません。
そんなとき私たちは、現場からチャンピオンを選び、プロジェクトを進めていきます。
チャンピオンが現場の声を聞き、GYOMUハックとやりとりをする。最初は当事者意識が薄いメンバーも、一緒に働いているチームのメンバーが取り組んでいるので、自分ごととなって協力してくれる。そしてリリース後もチャンピオンが中身をよく知っているので対応できる。
機能や仕組みを提供するのはGYOMUハックですが、オペレーションを実際に作り、育てていくのはビジネスチームのみなさんなのです。
GYOMUハックはサポートであり先導者
このようにビジネスチームの業務を支え、二人三脚で一緒に育てているGYOMUハックは縁の下の力持ち的なサポート役かもしれません。
しかし、ビジネスの成長を見据え、システム的な土台を整え、次に来るであろう未来に備えて施策を打っていくのもGYOMUハックなのです。
すべてのGYOMUハックはビジネスチーム無しではなりたたないので、良い関係を築きながら理想に向けて進めていけたらと思います。
Salesforce上で業務プロセスを組むときの考え方
はじめに
これはSalesforce Platform Advent Calendar 2018の9日目の記事です。
freee株式会社でGYOMUハックをしているmiryです。GYOMUハックについて知りたい方はぜひこちらをご覧ください。
この記事を読んでいるみなさんはSalesforceを業務に利用している方や、Salesforce上のアプリ開発をしている方など様々かと思います。
私は今回業務構築の観点でお話したいと思います。
Salesforceでの業務プロセスの組み方
1.何をやりたいのかを明確に
Salesforce PlatformにはSales cloud、Service cloudをはじめとする様々な機能があります。まずは、いったいどのような業務を行なっていくのかを明確にします。
さまざまな業務が思いつくかと思いますが、まずは何をやるのか、そして今後何をやっていく可能性があるのかをイメージしておけるとよいです。
2.どんな数字を追うのか
どんな業務を行うのかが決まったら、それぞれの業務でどんな数字をSalesforce上で追っていくのかを考えて行きましょう。このとき、追うべき数字が決まっている必要はなく、大まかな方向性が決まっているとのちのち便利です。
- アクティビティを追うのか
- 商談化数を追うのか
- クオリティを追うのか
- 顧客満足度を追うのか
この辺りを出せるだけ出して行きましょう。
3.Salesforceの機能を調べる
Salesforceでは、ある程度の業務が標準機能で準備されているので、どういう風にSalesforce上で業務を組み立てるのかも自由にできます。
ヘルプページやTrailheadで調べられるので、どんなことができるのか調べてみるのもいいかもしれません。
他にもDevelopersEditionという無料で構築できる環境もあるので、そこで触ってみるのもいいでしょう。
一番のオススメはTrailheadで、ある程度データの入っている環境を立ち上げて、インストラクションとともに操作することができます。
4.実装設計する
機能を調べたら、早速設計です。Salesforceはカスタマイズがとても柔軟にできますが、少し（かなり？）癖もあります。
オブジェクト設計
まずはオブジェクト構成です。2で大まかに追いたい数字について決めたと思うので、Salesforceのレポートでどのように集計できるのかをイメージしながらオブジェクトの構成イメージを考えます。下記の図は簡易的なものですが、データモデル図を書くのもいいです。
オブジェクト活用を考えるときのコツは、
- 標準オブジェクトを活用する
- 標準項目を活用する
- カスタム項目を活用する
- カスタムオブジェクトを活用する
です。それぞれどのオブジェクトにどのような内容を格納するのかを考え、標準のオブジェクトが使えるときは、標準のオブジェクトを利用しましょう。
プロセスの自動化の設計
効率化のための自動化は必ずあがるリクエストだと思います。その時の実装で考えるとき、私はこのような順で考えています。
- 数式で対応できるか
- 積み上げ集計で対応できるか
- LEXのコンポーネントで対応できるか
- ワークフロールールで対応できるか
- プロセスビルダーで対応できるか
- フローで対応できるか
- Apexで対応できるか
エンジニアにとっては、Apexなどでコーディングするのが楽なのですが、できるだけ前述の順序で実装計画を立てるのがよいです。
理由はApexなどのカスタマイズだと、メンテナンスが大変で、どんな処理が動いているのか把握するのが複雑になってしまうのです。
あと、下記のような機能は標準で提供されているので、ぜひ使ってみてください。
- リードのマージ
- リードのコンバート（取引の開始）
- 取引先のマージ
- 取引先責任者のマージ
- 承認プロセス
5.実装する
Salesforceの実装をする時、いきなり本番環境に反映するのはやめましょう。
前述のDevelopersEditionやSandbox環境などで思い通りの挙動をするのかをテストしてみてください。
かなり癖があるので、あれ、これはできないんだ！とかいう細かい制約があり、苦労することこの上ありません。笑
実際に触ってみて、動かしてみて、思い通りのものを実装してみましょう。
6.動作確認
業務に実際に関わる人にも動作を確認してもらいましょう。
最初から最後の業務の流れをデモして、そしてどのようなレポートができるかを作ってみて、想定通りの動きをするのか、無理なオペレーションになっていないのかシュミレートしてみましょう。そうしてチューニングするのがよいです。
さいごに
これから、Salesforceで業務を組むという方向けに思考プロセスをかいてみました。簡単ではありますが、参考になればと思います。
GYOMUハックエンジニアが学んだこと
freee株式会社で初代GYOMUハッカーとして、GYOMUハックチームに所属しているmiryです。
今日はGYOMUハックAdvent Calendarの一発目として、3年間freeeで試行錯誤を繰り返しながら培ってきたものを書き連ねてみようと思います！
業務改善・業務効率化に携わっているという方も、GYOMUハックってなんだ、という方も、しばしお付き合いいただければ幸いです。
GYOMUハックとは
社内SEやBPR、ITコンサルなどビジネス要件に対して社内のシステム構築・業務改善・課題解決を行う人たちのことを総称してそう呼んでいます。freeeにおけるGYOMUハックは、マーケティング、セールス、カスタマーサクセス、サポートなどエンジニア以外のビジネスチームの業務の基盤を作ることをミッションとしています。日々生まれる彼らの悩みを聞き、課題を整理し、理想を共に考え、そして実現する仕事です。
freeeでは基本的にクラウドサービスを利用しており、Salesforce、Marketo、Pardot、ZuoraなどのSaaSを利用しています。GYOMUハックはそれらのクラウドサービスの構築や導入、運用・システムサポートなどを行っています。
私たちGYOMUハックの目指す理想は、freeeのビジネスを世界最先端のビジネス組織に導くことで、私たちはそこに至るための道を作るITスペシャリスト集団とならなくてはならないと考えています。
GYOMUハックを通して大事にするようになった3つのこと
3年間GYOMUハックを行なってきて、最近ではこうするとうまくいく、という自信のようなものも芽生えてきました。そして特に大事にしていることは次の3つです。
- 施策のゴールの認識合わせをすること
- ツールに業務を合わせること
- 常に一歩先の理想を考えること
それぞれなんで大事に思うようになったかのストーリーをご紹介します。
施策のゴールの認識合わせをすること
どんな施策も始める時には、社内のステークホルダーを集めてキックオフミーティングを行います。そしてそのプロジェクトをなぜやるのか、何を成し遂げなければいけないのか、どのように進めていくのか、いつまでに何をやるのか、を最初に認識合わせをするようになりました。
業務改善の施策は、基本的に現場のオペレーションが変わることが多いです。そのため、ステークホルダーも多く、ふわっと始めてしまうとうまく回らないことが多々あります。今、この施策が動いているけどなんだっけ、このオペレーションが変わるけどなぜだっけ、という疑問が現場から生まれないように、施策の最初の認識合わせが必要なのです。
ビジネス側かからすると、あれもこれも困っている、全部どうにかしてほしいという気持ちも大きいです。しかしエンジニアからするとあれもこれも対応していたら終わらない、リソースが足りない……といった苦悩があります。業務改善の施策を進めている間に、思いつく限りに次々要件が追加されて、それに逐一対応していたりすると、いつまでたっても施策が終わらずに、結局最初求めていたものとかけ離れた何かよくわからないものが出来上がってしまったりもします。それは結局誰にとっても嬉しくない状況なのです。
施策を進める上でお互いが辛くならないように、今回のこの施策ではいつまでにこの状態になっていることをゴールとします、そのほかはStep2で行いますなどと定義することで、ビジネス側もエンジニア側も納得した上で円滑に施策を進めることができるようになりました。
キックオフのミーティング後は定例を持つことで、進捗の共有とAIの確認、スケジュール感の再確認を毎回おこなっています。コミュニケーションを密に取り、お互いの状況を確認し合うことで、急な状況の変化にも対応でき、柔軟な対応ができているのも施策の関係者に明確なゴールの共通認識があって、同じ優先度を共有できていることが重要なのではないかと考えています。
ツールに業務を合わせること
最近では便利なSaaSのツールが登場していますよね。かくいうfreeeもそんなサービスの一つですが、弊社では営業の顧客管理をSalesforce、契約管理をZuoraで行なっていたりなど、さまざまなSaaSを活用しています。何かの施策を行うとなるとやることはツールの導入であるとか、機能の活用であることが多いです。
そもそもなぜSaaSが選ばれるかというと、こんなことに困っているという明確な課題のある人がいて、その課題に対してのソリューションをSaaSが提供していることが多いからなのだと思います。有名な言葉を借りると車輪の再発明をしない、ですね。そういったツールの導入は効率化や改善を考えた時にとても理にかなったものだと思います。
SaaSを提供している企業にはそれぞれのコンセプトがあり、そのコンセプトを理解するということがツールをうまく利用して業務を効率化できるか否かのかなり大きなポイントとなってきます。彼らのコンセプトにのり、彼らの考える業務フローで、彼らの考える使い方をすれば、ツールと仲良くなれます。しかし、実際問題すでに業務が回っているところに新しくツールを導入するのですから、そんなにすんなりうまくいくわけがありません。
エンジニア側がまずやらなくてはならないことは、ビジネス側が一体何に困っているのかと業務の本質の理解です。こんな課題がある→このツールはその課題を解決する機能がある→ツールを入れて終わり、ではなんの意味も為しません。ビジネス側の業務を深く理解し、なぜそのような業務を行なっているのかという歴史に寄り添い、そしてそこから大きく外れないように理想的な形を考える必要があります。業務を理解した上で、ツールの特性・コンセプトに業務を寄り添わせるのです。
ツールの特性・コンセプトの啓蒙を行い、なぜこうするとうまくいくのかを説明し、体感してもらう。そうすることで、今までのやり方よりも新しいやり方にメリットがあると実感してもらうことで、運用が定着するのです。みんなで一緒にツールと仲良くなりましょう！
常に一歩先の理想を考えること
あれもこれも課題で、何から手をつければいいのか……そんな状態を経験している人はいないでしょうか。ビジネス側は課題の山に追われ、エンジニア側もあれもこれもよくしたいという思いばかりが募る。そんな状況になった時に、私が気をつけないといけないなと身にしみたのは、たどり着きたい理想を描いた上で目の前の課題に取り組むということでした。
目先の課題を解決する時、やり方はいろいろあると思います。その最適解を考える時に、私たちはいつか実現したい理想の形に一歩近くような対応を考えられるとベストです。ビジネスというものはどんどん成長するもので、その成長に合わせて業務もどんどん増えていきます。改善しているのに、それを考慮できていなかったら改善の対応がいつかまた負債になってしまうのです。
なるべく汎用的に、拡張性を考える。ピンポイントで対応するのではなく、俯瞰的に物事を捉えて、少し高めの目線から考えてみる。
私はそのようなことを常に意識しています。実はこれは結構辛いことで、効果が出るまでに時間がかかるので、その対応した直後はよくなっている実感はなかなか持てないのですが、数ヶ月経って、あれ？ いつの間にかよくなっているぞ？ と、ふっと気づくものなのだということに、最近気づきました。数ヶ月前の私が行なった施策が、別の施策で、「おお、ちゃんとこうなってるから対応できる！」といったことがよくあるので、私は昔の自分をこっそり褒めています。笑
一番嬉しかったのは、最近Salesforceが使いやすくなっている、便利になった、追いたい数字が簡単に取れるといったビジネス側からのフィードバックでした。理想を追い求めて少しずつ改善してきたのは無駄じゃなかったんだなと、ちょっと泣きました。
さいごに
このような感じで、いろんなことを学んで、より良い形を試行錯誤しながらビジネスチームと二人三脚で進んできた3年間でした。最近は私のGYOMUハックのノウハウを外部の人にも共有したいなという気持ちが強まったので、このような記事を書くことにした次第です。
また、同じようなGYOMUハッカーと知り合いたい・繋がりたいという想いでGYOMU Hackers Guildというコミュニティを2017年に立ち上げました。
12/11にGYOMU Hackers Nightを開催しますので、興味のある方はぜひ参加して見てください！
明日はfreee developers Advent Calendarでとっておきの記事を出すので、もしよろしかったらご覧ください！
また、freee株式会社では課題解決が得意なGYOMUハックエンジニアを大絶賛募集中ですので、興味のある方はぜひお声掛けください。
最後までご覧いただきありがとうございました！
いつの日かGYOMU Hackers Nightで皆様にお会いできるのをお待ちしております。
