実践業務ハック
ご無沙汰しています。
この記事は
GYOMUハック/業務ハック Advent Calendar 2018 - Adventar
12/8の記事になります。
この記事の構成は
- 自己紹介
- 業務ハックとは何か？
- 業務ハックを行うための秘訣
- 業務ハッカーになるために
の4点で構成しています。
簡単に自己紹介、会社紹介
株式会社EsyouSystemで代表取締役兼、業務ハッカーとして業務しています。
主に弊社はお客様から事業内容のヒアリング、業務内容のヒアリングを行わせて頂き、お客様への課題に対しての打ち手の提案などを行わせて頂いています。
spotでのお仕事もあれば、週1でお客様先に伺っての折衝もあります。色々な形態で仕事させて頂いてます。めちゃくちゃ自由に仕事している...
業務ハックとは何か？
どこまでお客様の業務、事業に入り込むか。という問題はあるものの基本的には下記を行う事が業務ハックと呼ばれるものになります。
-
ヒアリングを元に課題の定義を行う
-
課題に対しての打ち手の提案を行う
-
採択された提案内容の設計・構築を行う
-
打ち手に効果があったのか？の効果検証を行う
というのが業務ハックとなります。
これを世間的にはBPRと呼んだり、業務改善と呼んだりしています。
業務ハックの本質は事業を推進するにあたって、円滑に事業を推進するための業務基盤を構築していく。というのが本質になるのではないかと思ってます。
業務ハックを行うための秘訣
では、業務ハックとは何か？というのがわかったところで、実際に業務ハックを行うためにはどのような事をしなければならないといけないのか。
それを先ほどの定義になぞって細分化していきましょう。
・ヒアリングを元に課題の定義を行う
・課題に対しての打ち手の提案を行う
- 事業課題となっている部分に対しての打ち手の提案を行う
- 業務課題となっている部分に対しての打ち手の提案を行う
※例えば、事業としてはリードの数が横ばいでもっと増やしたい場合に新しい施策などの提案を行う。など
・採択された提案内容の設計・構築を行う
- 採択された内容を関係者に共有する
- 関係者とともに、事業設計・業務設計を行う
- 関係者に共有し、合意形成を図る
- 3で合意した内容をもとに必要に応じてシステム設計・構築を行う
・打ち手に効果があったのか？の効果検証を行う
- 事前に決めていたモニタリング内容に沿って、モニタリングを行う
- 検証した結果振り返り、課題定義から行いPDCAを回す
業務ハッカーになるために
何よりも大切なのは、システムに詳しいことでも、業務に詳しいことでもありません。色々な方々とコミュニケーションを取り如何に早く打ち手をうてるかです。打ち手をうつのが遅くなればなるほど、売り上げ損失が起こります。
そのため、課題定義、打ち手提案まではスムーズに進行すべきです。
業務ハックに興味がある！またはやってみたい！という方はtwitter、facebook、弊社問い合わせフォームからご連絡ください！
■備忘
本当はもっと色々書きたいことはあるのですが、なにぶん字面にするのが下手でわかりづらくてすいません。
次回(いつになるかわかりませんが)パート２的な感じで業務ハックを神速で行うための業務システムなどを弊社が何を基準に選定しお客様に提案しているのか。などを書きたいと思います。
kintone hive 東京を終えて
だいぶ更新を怠ってました。
とはいえ、Blogと言うのは書きたいときに書くのが1番だと思ってます。
(言い訳)
タイトルの通りなんですが、
kintone hive 東京を終えて色々経験したことや振り返りがあるので、
それを今日は記事にしようかと。
kintonehive20170519tokyo.qloba.com
kintone hive 東京でユーザー側の事例を話してきました。
とは言っても、開発者視点から見たユーザー事例というやつです。
言いたかった事は記事にも書いてある通りなので、
特に言及しないのですが、とにかくユーザーの事例は見ていて面白かったです。
とはいえ、先日一緒に登壇した方と
(未公開)のアンケート結果をもとに一緒に振り返りました。
私達としては、どういう層にヒットさせるコンテンツだったのか。
最初の問題提起(課題の共有)が弱かったのか。
どのようにすれば、良かったのか。今後につなげていくには。みたいなことを
つらつらと2人で振り返りしたわけです。
そこで出た話で一番話題になったのは、
どうやったらユーザ(kintoneの利用者 = hive参加者)達に自分事だと思ってもらえるか。
という話でした。
LTで話されていたテック系の内容のアンケート結果と結びつけて考えると
あまり自分事(自分たちの業務では活かせないな)と認識されていないのでは？と。
最新のkintoneの使い方の提案をいかに開発者として
ユーザにわかりやすく伝えるのか。これは自分自身も今後継続して考えていけないなー。と。
そのあたりをうまくkintone cafeなどで吸い上げて
kintoneの利用者の方々には伝えていきたいと思います。
まだまだ精進しないとなー。
kintone ２月アップデート内容の確認
随分ご無沙汰になってしまったわけですが。。
しばらく見ない間に記事の編集画面も色々変わりましたね・・・笑
最近はもっぱらkintoneばかり触っているので、2月にアップデートされた内容の確認をしてみようと思います！
■kintoneの２月アップデート内容はこちら
アップデート情報 | ファストシステムを実現したクラウドサービス「kintone」
主には下記２点がやはり印象強いのではないでしょうか。
・kintoneで操作が行われたときに、Webhookの通知をほかのWebサービスに送信する機能。
- ・新デザインで、アプリのデザインテーマを追加。
標準色に加えて、5色の中からテーマを選べます。
今回はアプリのデザインテーマについて確認しますが、下記のように簡単４ステップで画面イメージを変更できるようになりました。
①デザインテーマを変更したい、アプリ管理画面に行きます。
②アプリ管理画面からデザインテーマを選択します。
③テーマを選択し、保存ボタンを押します。
④アプリ管理画面で、アプリを更新ボタンを押します。
以上です！
簡単４ステップになります。
反映するとあっという間に、華やかな印象になりました。
(今回は清潔感あふれるグリーンのテーマにしてみました。)
４ステップで簡単に画面デザインが変更出来るなんて、すごいですね！
今回はデザインテーマについて確認してみましたが、如何でしたでしょうか？
色々なテーマがあるので、運用するアプリのカテゴリなどでテーマ分けしてみたら運用しやすくなるのではないでしょうか？
例)
・営業の方々が利用→青色のテーマ
・業務担当者が利用→赤色のテーマ
・開発者が利用→黄色のテーマ などなど・・・。
テーマ反映をして、今までの初期表示のグレー以外で是非とも業務効率あげたいですね！
次回は、webhookについての確認です。(^^)/
最近ブログ書いてないなっと思い唐突に書いていく
どうも、honkiです。
タイトルの通りなんですが、
最近salesforceを触らなくなりつつあります。
悲しい・・・・。
最近の技術要素としては
kintone = js
shell
となっております。。。
なんだか、何でも屋になりつつありますが、
現在の現場では、
運用環境の改善を神速で行っていくことを大事にしている為、
salesforceでの開発よりも
kintoneでの運用がフィットしているのもあるので
kintoneを利用してたりします。
今回の現場でkintoneを触るのが初めてになるのですが
中々良い感じです。
(かゆい所に手が届かない場合は開発する必要がありますが・・・)
日々の運用業務を改善するのに
色々なフローで試した！とかの時には
kintoneを利用し、フローを確立してから
salesforceを利用し始めるのもよいかと思います。
話は変わりますが、
salesforceというとServiceCloudの色合いが強く、私自身ServiceCloudしか
触ってこなかったのですが、ここにきてMarktingCloudを触る(見る？)機会が
あったので感動しています。
中々ジャーニービルダーの設定とかは癖がありそうですが
今後は設定にも携わっていきたいですね！
簡単な近況報告になってしまいましたが。
また何かあれば報告することとします。
パッケージインストールしている組織へのデプロイ
大事なときに何かが起こることがよくあります。
honkiです。
今回現場で開発作業を並行で行っている状況から
２つのdeveloper環境を使って開発していました。
Aの開発環境はパッケージングしてSandboxにインストールしている環境で、
Sandboxに上げる前には、ここでパッケージングをする必要があります。
Bの開発環境は純粋な開発のみに特化した環境でここで開発した開発物をAの
開発環境にデプロイし、Aでパッケージングを行いSandboxに上げるという環境でした。
私自身、あまりパッケージインストールでの環境構築をすることがなく今までは開発物をDeployしていく方法を取っておりました。
そんな状態だったので、
今まで通りBの開発環境で開発をしたり、項目の修正をしたりしていたワケですが、
全部終わってAの開発環境にデプロイを行いました。
しかし！！！デプロイに失敗する！！！
なぜだあああああああああああああああああああああ
っと色々Aの環境とBの環境を比べて見ていた所、
Aの環境でパッケージングされているオブジェクトの項目を
Bの環境で項目をテキスト型→選択リスト型に変えており、
こいつが原因でデプロイに失敗しました。
完全にやってしまったなっと思いながら該当箇所を修正し、
再度デプロイし、事無きを得たわけですが。。。
自分の勉強不足を反省すると共に、
今後は同じような環境で開発を行っている際には、
設計の段階でそういったものを洗い出せるようにしたいですね。
いやー、
肝を冷やしたぜ！！
StandardControllerとCustomControllerを一緒に使ったときにハマったこと
題名の通りではあるんですけど、
昨日あったことなので、取れたてホヤホヤです。
StandardControllerを指定する際にvisualforceに書くと思いますが、
例えば
<apex:page standardController="Account" extensions="HogeController" >
とあった場合に
HogeController内でgetRecordをすればAccountの項目が
取得出来るのはご存知かと思いますが、
Accountの項目を取得するのではなく、
その一階層下の項目を取得する必要がありました。
その場合、私はvisualforceに
<apex:inputHidden value="{!accounts.hogehoge__c}"
と実装していました。
そうすると、目的の画面を表示し、編集ボタンを押すと
謎のエラーが！
「system.security.NoAccessException: hogehogeObject__c の更新アクセスが拒否されました」
なんぞーーーーーーーーーーーー
なんぞおおおおおおおおおおおおおお
とハマりつつ、Google先生に助けて頂きながら
https://help.salesforce.com/apex/HTViewSolution?id=000002417&language=en_US
結局はこういう場合には、
visualforceでinputHiddenを書いてはいけないというのだけは理解出来ました。
(英語わからないよ・・・）
なので、apex:inputHiddenの実装をやめて
カスタムコントローラに、
this.hogeController.addFields(new List<String>{'accounts.hogehoge__c'});
と実装することで事なきを得ました。
普段スタンダードコントローラを使わないので、結構ビビリましたが
もう大丈夫です(´ー｀)
以下の２点が問題発生する要因です。
・画面を参照・編集するユーザーのプロファイルがhogeObjectを参照権限のみになっている。
(今回の私のPJの場合は、Accountの画面でhogeObjectは編集する必要がなかった為、この権現で問題なかった)
・動作確認をする際に、システム管理者で行ってしまっていた。
これから動作確認する場合には、
使用するユーザーのプロファイルで確認するように気を付けようと思います。
商談に紐付く取引先責任者を取得したい場合
List<Opportunity> oppList = [Select Id, Name From Opportunity];
for (Opportunity opp : oppList) {
List<OpportunityContactRole> contactRoleList = [SELECT Id, ContactId, Role, IsPrimary, FROM OpportunityContactRole WHERE OpportunityId =:opp.Id];
for (OpportunityContactRole role : contactRoleList ) {
for (Contact con : [SELECT Id, Name, MailingPostalCode FROM Contact WHERE Id =: role.ContactId]) {
}
}
}
とまあこんな感じに書いてたらガバナ制限に引っかかりましたというご報告です。
こういう場合って、 id IN: list とかで書くのがいいんだろうけど、
どうにもfor が多くなってしまった非常に可読性が下がってしまうのどうにかならないかなぁ。
こういう風に書けばいいじゃんとか。
めっちゃご意見募集中だったり。
