diaryとある天パーエンジニアのblogこの広告は、90日以上更新していないブログに表示しています。2018-08-25アジャイル開発の本を読んで引き続き、アジャイル開発系の本を読んで似たようなことが印象に残ったのでメモ程度に残しておきます。読んだ本はこちらです。印象に残ったこと・ユーザストーリー(誰のために何をやり、なぜやるのか)を理解すること・フィーチャーごとに短いスパンで実装していく・ストーリーポイント(あるフィーチャーに比べて何倍くらいの労力がかかるか)で工数を見積もる・すべきでないこと、やらないことを決める・優先順位をつけるときの判断の要素として4つ(価値、コスト、得られる知識や意義、低減できるリスク)で分けて考えるユーザストーリー(誰のために何をやり、なぜやるのか)を理解することここは特に読んでいてハッとしてしまいました。現状だと結構社内システム系の構築をしているので実際の業務を行なっている人がどうなのかみたいなことを考えて行動しがちでした。本当に考えるべきは、そのシステム改善によって価値提供できるエンドユーザーに対してどうあるべきなのかを本来ならば考えなければならない項目なのではないかと思い、今までの行動を反省しました。ビジネスなので結局は価値提供した先に金銭が発生します。それは誰なのか、その人がどういうことに困っていて、どういう価値を提供することで何が改善できるのかという視点から物事の思考をスタートせなばとひしひしと感じていますwストーリーポイントで工数を見積もるこれは結構実戦でもすぐに役に立つことでした。過去いろんな大きさの機能などを実装してきていたので、あの時のこういう実装はこのくらいかかっていたからそれに比べると、、、とかもしくはあの時の実装に比べて今実装しようとしているものがどのくらいなのかを相対的に判断するのは結構やりやすい感覚が個人的にはあります。優先順位をつけるときの判断の要素として4つ知識の獲得とリスクの低減が可能なテーマ、、、システムの使い勝手や機能についてのフィードバックなどのフィーチャーを早い段階にスケジュールする。いったようにこの4つの要素の優先順位の付け方として、「価値とコストの面から暫定的なスケジュールを決め、あとは調整」というイメージで進めるのが良さそう。これが正解というわけではないのでその場その場でどういう判断をするのか、その時にメリットデメリットを理解して上で進められるのかが重要になるのだなと思いました。まとめこういう本を今まで読んだことがありませんでした。いうものを知った上だけでは意味がないので、自分が行動する時に少し時間をかけながらでも自分の頭で考えて合っているやり方を模索できればと思っています。23:21アジャイル開発の本を読んでTweet広告を非表示にするもっと読むコメントを書く2018-08-18達人プログラマーを読んでコードを書いていていろんな先輩方からレビューをいただき「良い環境に入ったなぁぁ」と思いつつも、もっと自分でもなんとかしなければということで初心に戻り現在こちらの2冊を読んでいます。オブジェクト指向開発の神髄と匠の技で今回は達人プログラマーについて読んでて何かしら残しておいてあとで自分で見返したいと思ったので自分用に残していきます。読んで印象に残ったこと自らの技術に関心を持つこと自分の仕事について考えること悪い設計、悪い意思決定、質の悪いコードを見つけたらその場でどうにか対処する知識ポートフォリオを充実させる一つのエディタを熟知して生産性をあげる特に「自らの技術に関心を持つこと」「自分の仕事について考えること」「知識ポートフォリオを充実させる」は印象に残っています。自らの技術に関心を持つことコードのレベルでいうと普段使っている言語で何か記述するときにその1行1行に意味を込められているのかその1行がどう動いているのか理解しているか設計の話だとどういう理由でその構成にしているのかその構成にすることでのメリット、デメリットは何でなぜそれを選択したのかを明確なのかこういった風に「考えること」が大切でありmustです。自分の仕事について考えること”自らの技術に関心を持つこと”に近いです。対象が技術なのか、そうでないかの違いに過ぎないと個人的には感じました。自分は今何をやっているのか自分は本当にそこに向かっているのかこういうことを常に考えながら、物事を判断していくというのが仕事について考えることです。知識ポートフォリオ少なくとも年に1つ以上は新しい言語をマスターする3ヶ月ごとに関連ある技術書を読み込む。マスターできたなら他のところにも突っ込む技術書籍以外の本を読む社外の人と技術的な話をする常に最先端にいる新しい言語も最近ちょっと学べていないので改めて学んでいかなければいけないです。その時に時間がかかっても良いから一行ずつなんでこうなのかを理解して進めていきたいと思います。百歳の間三万六千時を失う。-毎日少しずつ行うことで習慣化していきます。8時にやる新しい言語については、今までマスターというレベルでないものがちらほらあるのでそこを洗い出し興味のあるものからやるという感じで進めていきます。marketo連携】両方へ入門してみた2まさか前回の続きを書くことになるなんて思ってもいませんでしたが、こちらも僕が「あったらいいなー」と思ったので残しておきます。(すごく長くなってしまいました。)ちなみに前回のがこちら。marketoの連携のみの説明になっていました。kintoneの連携について書いていこうかなと思います。やりたいこと特定の時刻に自動的に起動し、特定のリードのセット(集まり)に対して一度にメール処理を行うことができてかつ、そのメールの開封がkintoneで確認できること今回の場合の知っておくべきことさてさて、今回の登場人物は以下です。スマートキャンペーンこいつだけです。こいつはスマートリストフローという2つの要素を持っているので、スマートキャンペーンというよりこいつらのことを知る必要があります。スマートキャンペーンとは個人的にはmarketoの根幹部分にあたるところでないかと思っています。何かと言われると難しいです。設定次第でなんでもできちゃうからなので基本的に何かmarketoでしようと思ったら最初にこいつから手をつけることになると思います。これに関してはこれ以上説明できないのでやめますwスマートリストとは作成方法とかは画像つきで載っているのでそのまま真似するだけでokです。Documentationそして、このスマートリストですが2つの役割に分かれます。バッチスマートキャンペーン特定の時刻に起動し、特定のリードのセットに対して一度に処理を行います。「愛媛県」にいるすべてのリードにメールを送信する場合に使用されます。トリガースマートキャンペーントリガー起動イベントに基づいて、一度に1つのリードに対して処理を行います。メール内のリンクがクリックされた場合です。ドキュメントはさすがですね。このままで特別わかりにくいこともないと思います。どこでその区分が分かれるのか、、実際に見てみると2つの選び方があります。トリガーフィルターこの2つの選択の仕方で役割が変わります。フィルターのみならバッチスマートキャンペーンフィルターありなしに関わらずトリガーが入るならトリガースマートキャンペーンになります。フローとは次はフローについてです。こいつは実際の動作を定義するところです。marketo側が何かメール開封した時の為のトリガー的なのものを用意しているだろうと思っていてこんな感じをイメージしていました。自作する時とかは画像仕込んで、開封ログ取るとかはやってましたし。ドキュメントをザーッと軽くみてもそれらしきものが見当たらない。ドキュメント読まないといけないのか〜となり、ちゃんと読み始めました。実際の動作の部分なので(上で説明した)フローを見ればなんとなく想像できるかなーと思ってフローで何ができるのかをポチポチしながら確認。すると・・・ウェブフックを発見しました。実際にドラッグしてみるとこんな感じ。いうことでウェブフックを使って外部APIを叩くという方針になります。ここで問題発生!!!!marketoで用意されているwebhookは「GETとPOST」しか用意されていません。今回僕はkintoneへPUTで投げたかったので直接叩くのは不可能になりました。最終webhookからPOSTでAPIGatewayを呼び出し、lambdaをキック。IPをkintone側で許可してアクセスするようにしました。この辺のやり方はまた別途書きます。marketo内での設定さて外側の部分はできたのでいよいよ本題に入っていきます。残りやることとしては以下です。Documentationヘッダの設定は「カスタムヘッダ」というところから設定できます。テンプレートにはpostするときのデータを入れます。方針のところでもありますが大きく設定するのが2つでメール送付メール開封とともにウェブフック起動です。やるか結論から言うとバッチスマートキャンペーンとトリガースマートキャンペーンを組み合わせることでできます。具体的に言うとバッチスマートキャンペーンからトリガースマートキャンペーンを呼ぶトリガースマートキャンペーンで「メール送付とウェブフック起動」設定カオスですねwwwまあただこうやると特定の時刻に自動的に起動し、特定のリードのセットに対して一度に処理を行いうことができるかつそのメールの開封がkintoneへ送付することができます。Documentationただここではスマートキャンペーンをリクエストできるということがわかります。バッチスマートキャンペーンからトリガースマートキャンペーンをリクエストできれば解決できるのではないかと。実際にフローの中を調査するとキャンペーンリクエストというものがありました。これで呼び出せるっぽいです。具体的にはこんな感じバッチスマートキャンペーンフィルターは適当にメルアドで指定しています。「メール送付」して「キャペーンを呼び出し」をしています。トリガースマートキャンペーンここではメールを開封したのかどうかの確認のために加えています。ここを挟まないとフィルターに対象のユーザーが引っかからず、開封1回目が取得できない。できないのかはやってみるとわかりますが一応説明リクエストを受け取った時点でトリガーキャンペーンは実行されるなのでトリガーキャンペーンのリストのフィルターでメール開封ずみユーザーのみ取得するようにするただメール開封ずみかどうかはmarketoのDBを参照しているなのでmarketoのDBに入るタイミングとウェブフックのタイミングはウェブフックの方が後に実行されなければならない。いうことで待機するようにキャンペーンを追加したトリガースマートキャンペーン最後はウェブフックで飛ばしています。kintoneでは対応できなかったです。(僕の理解の範疇なのでもしこうやればできるよってのがあれば教えて欲しいです。)メールに返信したかどうかをkintoneへ送れない??こちらどうやら不可能ではないらしいです。工数かかるので一旦置いておくという判断にしました。以下marketoのコミュニティの方から教えていただいたこと。sorting/processing.まあなので現実ライン、SES経由とかになりそうな感じがしますけどね。この辺りも対応したら記事でも書こうと思います。marketo連携】両方へ入門してみた先週の1週間ずっとこれらの連携周りで調べていて、あまり情報ないなぁと思い結構時間かかってしまったのでログ残しておきます。kintone名前聞いたことある程度だったので軽く調べてみました。kintoneとはサイボウズさんが自社で開発しているクラウドサービスです。ググってみると色々説明出てきますが、個人的には「webデータベースのアプリを構築してくれるサービス」という認識で良いかなって思っています。「アプリ」という単位でフロント側とDBを持ち、フロントをそのアプリを使う人が自分で勝手にカスタマイズできる業務支援システムというイメージです。フロントを簡単にいじれてかつそれがDBに入るので営業さんとかのPDCAを高速に回すとかにはすごく良いんですけどね。marketoこちらも名前を聞いたことがあるという程度だったので軽く調べました。marketoとは「マーケティングオートメーション」というやつで、顧客一人一人の行動を追え、タイミングタイミングでアクションを変えたりすることができるプラットフォームです。個人的には「そのユーザーが自社(サービス)に興味をどのくらい持っているのかを可視化できて、その興味や状態によってどうアクションするのかを選択できるツール」くらいの認識ですがwdocumentの見方どちらも親切なことにdocumentが用意されています。基本的にはそこを読めば解決できます。どちらもdeveloper用の質問サイト?が用意されており、過去のログもみることができるので同じ問題にぶち当たった人がどう解決したのかなどもわかるので便利です!ただ僕が一瞬あれ?と思った箇所があったのでそこだけ説明しますwそれはmarketoのdocumentです。developers.marketo.com連携させたかったのでapiのdocumentをみたのですが、全て英語です。英語が苦手な人は少し辛いかもしれないですね。頑張りましょ!でその中でみていくとpostする際のデータの持たせ方が載っています。http://developers.marketo.com/rest-api/endpoint-reference/lead-database-endpoint-reference/#!/Leads/syncLeadUsingPOSTこれをみたとき僕は一瞬「めっちゃデータ構造複雑だな、SyncLeadRequestとLeadと・・・を持たせるのかよ〜。持たせれば良いのかな?」と思ってましたwwactionはstringで持たせるよ!とか書いているのに途中でLeadというのが出てきます。https://test.co.jp/やりたかったことkintoneで更新した時に、marketoのAPI叩いてmarketoにleadの(見込み客のことをleadと呼ぶ)新規作成or更新をかける。});})();marketo側このURLのdocument通りに、API叩くようのユーザーを作成し、そのユーザーにAPIロールを付与してアクセストークンを発行する。APIのdocumentをみて対応させていく。Developers新規作成の時は、/rest/v1/leads.jsonでinputのところに初期設定したい値を入れるだけです。ちなみにlookupFieldというのは、データ整合性をとる時にどこのフィールド(カラムのことですね)を対応させるのかということです。"email"としたので、marketo側でメルアドを参照し同じメルアドがあったら更新、なかったら作成という挙動になります。Database」というところの「全ての顧客」にデータが作成されます。更新されるときはそのユーザーが更新されます。まとめ蓋を開けてみると、非常にシンプルですが初めてだとそもそもの理解に時間がかかるものだなと思いました。いうものでも時間をかけずにできるように、今回詰まったところをもう一度洗い出して、なぜ詰まったのかを考え次に繋げたいです。転職初日に新規立ち上げの部署への移動が決定し、最近は四苦八苦しながらプロジェクトを前に進めています。その進め方で今度やるときはこうして進められると初動としてはよかったのではないかと思ったのでログ残します。その前に前提サービス自体はすでにありました。簡単にいうと人材を集客して教育し事業所へ流す、その時の事業所への紹介料でマネタイズするというビジネスモデルです。した業務フローですが営業がもともと強い会社なので、集客してきたユーザーに架電し、面談実施を行いそこで事業所へ紹介できる人材なのかを見極める。見極めた後、就業支援やら教育などをして一定の力をつけて事業所へ流すという感じです。縦割りのチーム分けになっています。架電部隊は架電部隊でデータを管理し、教育支援やらなんやらのところはまた別の方法でデータ管理しているという状態です。データ連携もところどころうまくできていなく、担当の方が手作業で入力しているという感じでした。アサインはされたものの「何して良いのかわからない、そもそもここはどこなんだ?」という状態だったので、各フローのリーダーや事業責任者などへのヒアリングを行いました。そこでは主に以下を聞いていました。そもそもなぜシステムを入れるという判断になったのかKPIから乖離しているポイントはどこでどのくらい離れているのかなぜそのような乖離が生まれたのかの仮説を持っているのか各フローは現在どういう作業を行なっているのかその中で今困っていることはなにか今後どのようにしていきたいなどの理想はあるかあとはその話を聞いてもっと知りたいことなどを追加で聞きました。これを通して全体像の把握は完了し、なんとなくボンヤリとした各部門の業務フローと困っていることはわかります。各フローの実際の作業の把握ボンヤリとした、業務フローはわかったのですが具体的にどういう風に行なっているのはやはり実際に足を運ばないと理解はできなかったので各部門の見学なり体験なりしました。フローの詳細、どんなデータをどこにどうやって管理しているのか、そしてそのデータはどこへ連携しているのかの理解できます。理想形の設計ここは未だ手が出ず。何を理想形としどうあるのが業務的に一番楽で成果出るのか、そうあるにはシステム的にどうあるべきなのかを考える必要がありました。これを考えるにあたり、重要視したのが問題の切り出し方。→なるべく問題を小さくしながら随時改善の効果が実際の現場に反映されるようにしないといけない。ここを模索しながら、成果に繋がるところを改善していく方針にしました。現状の問題の洗い出し各フローのヒアリングや見学・体験を通して一旦下記を洗い出すことにしました。どこが改善できそうなのかどこに手を加えるのが一番事業としてインパクトがあるのかそして、洗い出した中で自分なりの解決策を考え、その工数を見積もる。見積もったあと、各部署に提案。そのまま実行して良いのか、それとも修正した方が良いのかを詳細を詰めていきました。実行スプリント形式の方が、自分はやりやすいのでgithubでissue管理し、何をいつまでにやるのかというのを管理することにしました。反省なんと言っても、スピード感は遅すぎたように思います。いうのも最初は「ビジネスモデルを理解し、どうあるべきなのか理想形を考える」というとてつもなく大きなものから考えようとして、時間が無駄にすぎていっていました。理想形ができたところで、現状のフローをいきなりガラッと変えることはあまりないと思います。ましてはその理想形が本当にベストなのかも未定です。この場合は現状のもう実際に動き出しているフローがあるのでそこをどう改善するか、どういう設計にした方が効率良いのか、そういうところを考え先に実行しながら、同時進行で理想形を設計していくというのがトータル早く成果に結びついたのではないかなと思っています。まとめやることとしては以下の順番がよいかなと現時点では考えています。引き続き毎日考えながら次へ活かせるようにやっていきたい。existと言われた。以前、docker上にDB立ててリモートからdumpしてrestoreするの時間かかるからそのままリモートDBに繋げるようにすれば楽だよねーって記事を書きました。katsuyukikun.hatenablog.com僕が今回業務で対応していたのが、DBからデータを取得するだけのアプリケーションだったのでこれで良いと思っていました。selectだけだから間違えてDB吹っ飛ぶなんてことは絶対ないと思っていたから・・・しかし今回、DB吹っ飛びましたw開発用DBなので別に影響範囲もくそもないのですが、精神的に穏やかでなかったのでログとして残します。PHPで書かれたアプリケーションとそのDBとしてmysqlを利用していました。今回僕は、phpのアプリケーションのある動作をフックにし、そのmysqlのDBともう一つ違うところにあるDBにアクセスし、データ統合やら整形をして、違うDBにpostするというアプリケーションをrailsで対応しようとしていました。「新しいレポジトリ作成して、既存のDBたちにアクセスできるように0からのアプリケーションを作る」です。ロジックやらなんやら書いてテスト書いてdeployフロー作って、deployさせるってかんじというのはすぐ思いつくと思います。