音楽とお酒とものづくりとスマートフォン用の表示で見る音楽とお酒とものづくりと営業マンが元webエンジニアの経験を生かしてあれやこれやするやつこの広告は、90日以上更新していないブログに表示しています。2018-03-17【営業マンのための】営業活動を分析するために日々の予定をスプレッドシートに吐き出す【仕事効率化】もはや週末の趣味になりつつあります。営業マンのための仕事効率化シリーズ第3弾です。日々の営業活動を明らかにする必要があります。新規提案の打ち合わせが何件あったのか、社内の打ち合わせは何件あったのかなどなど。1週間ごとにサマって報告しているのですが、1週間分のスケジュールを目視で確認し、どういうアクションが何件あったのかを把握するのは意外と面倒です。calendarから予定を取得し、それがどういうアクションだったのかをスプレッドシートに書き出し、それぞれのアクションを週次、Qごと、合計値で算出するGASを書いてみました。false;}特に難しいことはしていません。これまでやったことを組み合わせて実装できました。spreadsheet.getSheetByName("マスタ");メールアドレスに紐づくカレンダー情報を取得し、今日の予定を取得してきます。予定を書き出すスプレッドシートのURLとシートを指定します。}そしてそれぞれのイベントに対し、自分が出席するイベントのみスプレッドシートに書き出します。自分が出席するもののみ書き出すのは、他の人に同期だけされた予定を自分の営業活動としてカウントしないためです。event.getTitle()]);}スプレッドシートに追記しいてくのはこちら。最後の行にどんどん追加していきます。day;}スプレッドシートには、その予定の日付と予定名を書き出します。event.getStartTime()では日付だけでなく時刻まで取得してきます。今回は時刻は必要ないので、YYYY/MM/DDの形式で書き出すようにフォーマットしています。false;}こちらは自分が出席するイベントかどうかを判別する関数です。それぞれのイベントに対し、自分の参加ステータスが決められています。Enumで定義されているようで、それぞれ以下のように定義されています。他人に同期され、出席と回答したもの:YES他人に同期され、欠席と回答したもの:NO自分が作成したイベント:OWNER同期されたが出席とも欠席とも回答していないもの:INVITED未定と回答したもの:MAYBE自分が出席するイベントは、YESとOWNERが該当するため、この二つのステータスを持つイベントのみスプレッドシートに書き出す対象としています。これでスプレッドシートに予定が書き出されていきます。あとはスプレッドシート側で予定をサマっていき、週次、クォーターの報告として活用します。スプレッドシートには以下のように追記されていきます。本当は予定を書き出した段階でその予定がどのカテゴリに入るのかまで判別できれば良いのですが、他の人に同期された予定名はプレフィックスのルールがバラバラだったりするので、予定のクラスタリングだけは手動でやるようにします。該当するカテゴリのところに1を入力していきます。このデータを元に、集計する数式を埋め込みます。完成系はこんな感じ今週のアクション数を出すところは、WEEKDAY()を利用します。3)2018/3/12のところは上記の関数を埋め込みます。2018/3/17のところはTODAY()でOKです。週次の報告を上げるのは基本金曜日なので、いったんTODAY()で運用します。これで今週の日付も自動で変わっていってくれるので、便利ですね。日付に該当する予定の各合計数を算出します。これはSUMIFS()を使えば1発です。’今日まで')こんな感じですね。1本のメール作成であっても、チリも積もれば山となり、バカにならないくらいの時間がかかってきます。イレギュラーな内容のメールは仕方がないにせよ、御礼メールやリマインドメール、週報メールなどはある程度文章の方向性が決まっており、効率的にメール作成ができるはずだ、ということでやってみました。gmail実装メールのテンプレートはスプレッドシートに保存しておきます。メールの作成のタイミングでスプレッドシートを読みこみ、テンプレートを取得し下書きに保存します。this.bodyData;}イベントの発火は時間駆動型とし、明け方1~4時の寝てる間くらいに実行されるようにセットしています。calendarからその日の予定(events)を取得してきます。Date());そしてそのイベントが往訪であれば、gmailにメールを作成します。以前もありましたが、予定入力のルールとして、予定名のプレフィクスに予定の種類を入力しています。takaaki-z.hatenablog.comMTGの予定なら「会議:ほげほげ打ち合わせ」みたいな感じです。外出の予定の場合は「往訪:ほげほげ」と入力しているので、これをチェックし予定の種類を判別します。false;}メール作成はもともと用意されてるGmailオブジェクトのcreateDraftメソッドを叩くだけです。calendarの予定のタイトルから宛名となる情報を取得してきます。予定入力のルールとして、往訪する会社の名前を「【】」でくくって入力するようにしているので、こちらも正規表現で引っ張ってきます。companyName[1];}メールの本文はスプレッドシートからテンプレを引っ張ってきてます。this.bodyData;}件名と本文をあらかじめスプレッドシートに入力しておき、対象となるセルを参照し取得します。件名はそのままひっぱってくればOK。calendarの予定に合わせて入力するので、整形したものを返します。改行は文字コードを直接指定して入力するようにしました。これで、朝起きたら御礼メールの下書きが作成されます。あとは実際に往訪時に話した内容に合わせて少し編集すればメール作成が完了します。往訪時の話の内容を自動入力するのは難しいので、ここは手動で編集します。送信先アドレスも今回は手動入力を想定しています。往訪前にアドレスがわからないパターンもあるので、今回は自動化しませんでした。実際に運用してみて実際にこれを1週間運用してみましたが、想像以上にメール作成が楽になりました。いった細かいところからちょっとずつ自動化していき、より本質的な仕事に時間が割けるようにしていきます。基本的に自分のタスクは全てtrelloで管理しています。カンバン方式のようにレーンを作り、それぞれ以下のようなレーンでタスクを分類しています。漏れが出てくるので、基本的には日ごとに入力を行うようにしています。毎日やるタスクを毎日trelloに登録するのもめんどくさいし、でも登録していないとたまに入力を忘れる日が出てくるので、なんとかしたいなあと思ったのが背景です。ちなみに何か仕事が入ってきたらとりあえずtrelloに登録、緊急度を他のタスクと比較し、次にやるタスクの選定を行っています。基本的に何かをずっと覚えておくのはつらいので、trelloに登録したらそのタスクのことは一旦忘れます。覚えておかないといけないこと(タスクの詳細やメモなど)は説明欄やコメントに残し、目の前の仕事に集中できるようにします。そんなやり方をやっていると、交通費申請なんてどうでもいいタスク(よくないけど)、忘れてしまうわけです。trelloは必ず頻繁に確認するので、自動でタスク登録してくれたら毎日忘れずに処理できるかなと思ったわけです。実装trelloのAPIトークンを取得するさて本題。APIを叩くためのトークンの発行を行います。trelloにログインした状態で以下のURLにアクセスします。https://trello.com/1/appKey/generateまずは開発者向けのキーが表示されるので、これをメモ。次に「あなたは手動でTokenを作られます。」のTokenの部分がリンクになっているのでこれをクリック。遷移後に認証を求められるので、READとWRITEの権限があることを確認し、認証します。認証後、APIトークンが表示されるので、こちらもメモ。この段階で、まずは認証が正しく完了したかを確認します。以下のURLをブラウザに入力します。https://trello.com/1/members/"USERNAME"/boards?key="KEY"&token="TOKEN"&fields=name"USERNAME"にはtrelloのユーザIDを"KEY"と"TOKEN"にはそれぞれ先ほどメモしておいた値を入力します。認証が済んでいると、自分のアカウントに登録しているボードの情報が表示されると思います。ちなみに最後の「fields=name」を入れることで、そのボードに対する名前とIDだけを表示させることができます。これでtrelloを操作する準備が整いました。calendarの予定を取得するcalendarの予定を取得するメソッドは既にあり、取得対象となるメールアドレスのみ指定すればOK。```CalendarApp.getCalendarById('自分のメールアドレス');```あとは検査対象となる日付を与え、予定を取得します。予定を入力する際にその予定のカテゴリ(外出、来客、会議など)をプレフィックスとしてつけているので、外出の予定かどうかはこのプレフィックスを用いて判別します。最終的に出来上がったコードは以下の通り。options);}正直ソースコードはすっちゃかめっちゃかです。クラス化(ライブラリ化?)したりして最適化したいとは思いますが、今回は諦めました。cronのように特定の時刻になればこのプログラムが起動されるように設定しております。同じタスクが登録されているかどうか、外出の予定があるかどうかを確認し、交通費申請タスクを「今日やるタスク」リストに追加しています。ユニットテストを書かずにコードを書いたのは久々で、めんどくさいな〜と思いながらも手動テストでせこせこやってました。コードの最適化もそうだし、テスト環境も入れたいと思ってはいますが、もうちょっと本格的に自動化を進める段階で検討します。実際に導入してみて交通費処理漏れがなくなりました。タスクはtrelloに入れる、trelloを見る習慣がこびりついているので、絶対に思い出せます。今回得られる恩恵は小さいものですが、今後も自分の作業を自動化していきたいと思います。scriptを使って、翌日に外出の予定があれば交通費精算のタスクをtrelloに自動で登録する【仕事効率化】Tweet広告を非表示にするもっと読むコメントを書く2017-07-28第5回アジャイルディスカッションに参加してきた!今回も参加してきました、アジャイルディスカッション!前回参加したレポートはこちら。takaaki-z.hatenablog.com今回我々のチームで取り上げられたテーマは以下の通りでした。振り返りのやり方どのようなメトリクスを収集し、どのように活用しているかペア固定によるペアごとの属人化についてディスカッション議論のスタートは「KPT以外の振り返りの方法はどんなものがあるのか」でした。KPTでやっているとマンネリ化してくる、どうしてもProblemに意識がいってしまいポジティブになれない、あがってくるKeepやProblemの質が低いなどなど、様々な話が出てきました。ディスカッション中に出ていたやり方としては、YWTM・公園で飲みながらやる・お絵かきをするなどが上げられていました。YWMTは我々も取り入れていて、なかなか良いなと感じています。Keepを出すのではなく、まずはスプリントでやったことを洗い出し、出てきたYに対して気づきを上げていくので、KPTよりももれなく気づきを抽出できると感じています。私は、振り返りはチームのパフォーマンスをもっと高めていくためにやるものだと思っているので、パフォーマンス向上に大きく寄与しないような、単なる「よかったね」をできるだけ減らしたいなあと思っていました。「よかったね」が気軽にたくさん言える雰囲気になっているのはチームとして健全だ、と言われ、ハッ!としました。その「よかったね」から何がよかったのか、どうしたらもっとよくなりそうかなどを引き出していくのがファシリテーターの役割だと言われ、これまたハッ!と。あとは、プロダクトオーナーに対して、振り返りやトライの内容をオープンにし共有していくのも面白いなと感じました。POも巻き込んで全体で問題に取り組んでいく雰囲気の醸成、そして開発者とは違った目線からの意見が出てきたりなどいいことがたくさんあるとのことでした。イベント全体を通して「なぜアジャイルをやるのか」「アジャイルで何がしたいのか」これを押さえておくのは改めて大事だなと思いました。開発プロセスのフレームワーク・手法にすぎないので、自分たちのやりたいことにあったものを適切に選ぶのが良いかと思います。あとやっぱりビール飲みながらディスカッションするんは、すごい良いです。結論リモートペアプロ超快適やん!という話です。働き方改革で今年の3月くらいから全社でリモートワークを導入しました。リモートワークについてはエンジニア交流会でもLT登壇させていただき、リモートワーク導入の話から、現在のスクラムチームでの活用方法をお話しさせていただきました。詳細についてはこちらのブログをご覧ください。gaiax.hatenablog.comさて、今回のお話ですが、リモートワークしながらペアプロをしてみた話をします。ちなみに、最近はモブプログラミングがすごく取り上げられていますね。モブプロはまだトライしたことはありませんが、うちのチームではペアプロ・ペア作業は当たり前のように行っています。最近はリモートワークをよくやるので、一度リモートでペアプロやってみよう、となったのでそのお話。リモートペアプロをやってみてリモートペアプロの際に使うのはslackだけです。slackで音声通話しながら、画面共有機能を使って画面を共有するだけ。ドライバーが画面を共有し、ナビはそれを見てナビする。本当にたったこれだけなのですが、普通にペアプロ実施できました。画質も音声もキレイにいけてました。出社したとしても、自社の執務室だけでなく、同ビルの地下や屋上などで作業をすることもあります。GRIDというところです。こちらのブログでも紹介されているように、非常に多様な働き方ができるビルです。www.gaiax.co.jp外部ディスプレイをわざわざ地下に運んでペアプロすることもありますが、いかんせん重たいのでめんどくさいのです。このように、外部モニタがないときは、一緒にいるときでも、slackの画面共有機能を使ってペアプロをすることもあります。やりとりは一緒にいるため、マイクをミュートにし、直接行います。ちなみに音声通話の代わりにテキストでもやってみたのですが、これは微妙でした。音声通話よりもリアルタイム性がないし、なにより文字入力がめんどくさい。あとPCのスペックにもよるんでしょうが、slackの画面共有中のテキスト入力がすごく重かったです。slackじゃなくても、音声通話と画面共有ができるツールならなんでもいいと思います。まとめ以上、ビデオ会議ツールの画面共有機能を使ってのリモートペアプロがすごい快適やっていう話でした。想像以上に快適に作業できたので、今後も続けていこうと思います。14:43リモートワーク×ペアプロにトライしてみた話Tweet広告を非表示にするもっと読むコメントを書く2017-06-19アジャイルディスカッションに参加してきた!先日アジャイルディスカッションに参加してきました!アジャイルディスカッションについてはこちらを参照ください。takubon.hatenablog.com本イベントでは、アジャイルを導入したり進めていく上での悩みごとなどを共有し、ディスカションしていきます。進め方はじめに主催者の木村さんからのイントロダクションがあり、それぞれがディスカッションしたいテーマを列挙します。4~5人くらいのグループに分かれ、グループごとにテーマを選び、ディスカッション開始となります。イベント中はビールを飲みながらのディスカッションOKというスタイルでした。取り上げたテーマ我々のグループは以下のテーマでディスカッションを行いました。「失敗アジャイルの共有」ディスカッション内容と気づき、次のアクションV字モデルの下の方だけスクラムやっているチームが多いこれは確かに、と思いました。ウチのチームも同じような感じで、最初に決めた受け入れ条件を守ることを大事にしていたように感じました。実際にストーリーの実装を開始した後に、「こっちの方がいいんじゃね?」と思っても、「でも受け入れ条件がこうやから・・・」と受け入れ条件をひっくり返したりしてなかったなと。V字の上の方の変化を受け入れず、下の方だけスクラムしていたように思います。すれば成功するかなんて誰にもわかりません。実際にやってみて違和感を感じたり、もっとこうしたほうがいい!と感じたのなら、素直にそれを提案し、受け入れ条件の見直しから柔軟にやっていくべきだなと思いました。プロダクトバックログの上から機械的にストーリーをこなすだけになってないか。スプリントゴールが「価値を届けること」ではなく、「スプリントを終わらせること」になっていないかただ機械的にこなすだけなら、当然ミニマムしかあげないし、ストーリーの実現に伴う副作用的な変化は排除するようにしか動かんなあと。そのストーリーを提供することでどんな価値が届くのか、お客さんのどんな課題が解決されるのかをしっかり意識することが大事ですね。課題解決のための価値提供であることをしっかり認識しておけば、常に最適解を探すようになり、V字モデルの下だけスクラムとかからも脱却できるのかなあと思いました。これからは「この価値を届けることで、お客さんの抱えているどんな課題が解決されるのか」を意識していこうと思います。具体的にはリファインメントの時に、その質問を投げてみることや、ストーリーの着手前に、この価値が届き、お客さんがどうその価値を体験するのかをストーリーベースで妄想すること、それをペア作業者と一緒にやること、などをトライしていこうと思います。開発チームだけでなく、営業やサポート、ステークホルダー全員で1つのプロダクトを作りあげ提供していく、そこに関わるものとしての当事者意識を持つことが大事だという話も上がりました。これに関しては、最近社内で雰囲気が少しずつ変わりつつあるように感じます。私個人としても、開発以外の視点で捉える必要があると思います。作っておしまいじゃなくて、営業の人がもっと売ってきやすくするために何ができるかなどを考えたりすることが必要かなと思いました。失敗を恐れず行動していくためには、失敗を褒める文化を作ることが大事これも思い当たる節がちらほら。最近完成させたストーリーの中で、あくまでストーリーの実現がメイン。それに伴う副作用的な変化はできるだけ排除しよう、という思いがありました。これは、変化による失敗を恐れていたからだなあと感じ反省しました。副作用的な変化があったとしても、より価値が届くのはどちらかを考えた結果であれば、どんどん変化を受け入れていくべきだと思ったし、行動していくべきだなと感じました。イベント全体を通して立場や年齢、スクラムの経験年数もバラバラの人が集まり、いろんな視点からの意見がたくさんでてきて良い会だなあと思いました。たくさんのいい刺激をもらったので、どんどんチームに還元していきたいと思います。COFFEEで実施してみた久しぶりのブログ更新です。COFFEEというミーティングの手法を知ったので、早速チームのミーティングで実践してみました。COFFEEについてアジェンダを用意せずに始めるミーティングのこと。詳しくは以下の記事を参考にしてください。medium.comやってみて思ったことダラダラと議論が続くことはないやっぱりこれが一番大きいなと思いました。タイムボックスを決めて議論するため、ダラダラと議論が続くことはありません。時間がきたら継続判断を全員で行うので、議題の切り替えも非常にスムーズでした。やってみると、意外と2、3回目の継続判断で次のトピックに移ることが多く、いつもよりコンパクトに議論ができた感じがありました。全員の意思を確認してから次の議題へと移るので、「もっと話したかったのに・・・!」という不満がたまることもなかったように感じます。普段は結構議論が長くなりがちなので、実施前は、今回も時間内に議論し尽くせるかな〜と若干不安でしたが、アクションプランを出すところまで含めてきっちり議論しきり、時間内に終わることができました。全員が本当に議論したいと思っているトピックが挙がる最初のステップで、議論したいトピックを挙げ全員で投票し、投票数が高いものから議論していくため、全員が議論したいと思っているトピックが優先度高く取り上げられます。ファシリテーターがトピックをあらかじめ用意してくるより、良いなと感じました。多くのトピックについて議論できるまた、ダラダラと議論しないことで、時間内に多くのトピックを取り上げることができました。まとめ議論したいトピックを全員で決めて、タイムボックスを切り、議論の継続判断を行う今後も、この手法を取り入れていってみようと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。