最強のデータ分析組織を読んで
最強のデータ分析組織
なぜ大阪ガスは成功したのか
まとめ
- データ分析は手段に過ぎず、目的はビジネスに貢献することを忘れてはいけない
- 意思決定に活用してもらうには、役立てようとする意図をもっていないといけない
- 最近は、「手段のすごさ」ばかり脚光をあびて、「業務改革の成果は手段の優劣で決まる」と錯覚している
- 最初に目的ありき、手段は道具であり、分析結果は成果ではない
- 社内からのレピュテーションだけは、お金を出しても買えない
- SEにとってのデータ分析は、目標遵守型の価値観に固執せず、目標想像型に頭を切り替え、新たな仕事の進め方を身に着けていくこと
はじめに
- 組織名は「ビジネスアナリシスセンター」
- 端的には言えば、社内の「データ分析専門組織」
毎回同じ悩みを打ち明けられる
ビジネスアナリシスセンターに訪れる人たちと話しをすると
- 当社でもデータ分析専門組織を立ち上げたのだが、うまく機能しない
- これから立ち上げるので、アドバイスが欲しい
第1章
ビジネスアナリシスセンターの実像
経歴がバラバラな多彩なメンバー
- ビジネスアナリシスセンターには所長を含めて、現在十人が在籍している(2017年7月時点)
- 20代の若手から51歳のおじさんまで年齢層は幅広い
- メンバーの大半は理系の大学院を卒業しているが、専門は化学や電気、環境、資源など様々であり、数学や情報工学を専攻していたメンバーは一握り
- 大学時代に統計学などを全く学んでいないメンバーもいる
分析ツールの選定について
補足しておくと
- 各メンバーが数学やITに必ずしも詳しくないからと言って、データ分析に欠かせない論理的思考に欠けている訳ではない
- 論理思考力は非常に高いレベルを有している
メンバーの能力について
- 以下のような能力に長けている
- 混沌とした現実問題に対して、「目的」だけを頼りに論点を整理し、その目的を達成するために効果的な「問題設定」ができる力
- データ分析で得られた結果について、算出の前提条件や結果の不確実性までを踏まえた過不足のない理解をして、それを相手に分かりやすく伝わるように記述・説明できる力
- 自ら行ったデータ分析や他者によるデータ分析について、本質を突く質問や問いかけを切り出せる力
- 疑問をきっかけに、頭の中で整理した「理解」を再構造化できる力
ビジネスアナリシスセンターのメンバーは、「意外」な能力を持っている
業務コンサルティング力
- データ分析で業務に役立つには、現場担当者へのヒアリングで業務を理解し、プロセスや費用対効果などの観点から業務プロセスを見直して、問題の所在を突き止める力も持っていなければならない
- 社内でデータ分析者とみなされているだけでなく、「社内コンサルタント」として見られることもある
データ分析者に必要な３つの力
- 見つける力
- 解く力
- 使わせる力
データ分析者は問題を「解く力」だけでなく、データ分析を活用できる機会を「見つける力」が最初に求められる
その上で、データ分析から得られた結果を現場に「使わせる力」も身につけなければ、ビジネスに貢献できない
データ分析で得られた知見を現場に使わせるプロセスは、現場と一体化しなければいけない
業務改革と業務改善の違いについて
ミッションは「業務改革」であり、業務改善ではない
業務改善
- 現状の意思決定プロセスは肯定したうえで、既存のプロセスの中で工夫を積み重ねることを指すもの
業務改革
- 現状の意思決定プロセスの一部を否定し、新たなプロセスに改めること
分析方法という手段へのこだわりがなくなった
- 方法論へに固執することを忘れ、事業部門が求める成果だけを追求する姿勢に変わっていった
- データ分析は手段に過ぎず、「目的はビジネスに貢献すること」
- かつては事業部門から来る相談といえば、「こんなデータ分析ができないか」といった、あくまでも分析レベルの話だった
- しかし今は「こんな業務課題を抱えて困っている。データ分析で解決できないか」という、ビジネスレイヤーでの相談に変わってきた
ビジネスアナリシスセンターは「攻めのIT」を担うチームとして位置付けられるようになった
セキュリティーやコストダウンといった「守り」だけでなく、ITやデータをビジネスに活用していく「攻め」も求めらるようになってきた
「データ分析を受託する」という意識から、「データ分析を武器に事業部門と一緒に業務改革を完遂する」という意識に変わった
取り組みはボトムアップでのアプローチ
ひたすら現場でデータ分析の活用を積み重ねてきた
ボトムアップで取り組んできたからこそ、強固な社内レピュテーション(信頼)を築き上げられたと考えている
第2章
四種類の「人の壁」を乗り越える
人の壁は「四種類に分けられる」
- 事業部門と連携する壁
- 会社の経営に貢献する壁
- 分析組織のメンバーを育てる壁
- モチベーションを維持する壁
事業部門との連携が成功への絶対条件
分析結果や予測精度が「すごい」ことと「役立つ」ことは全く違う
- 山ほどデータを集め、最先端の分析手法を用いて、高精度な予測モデルを作ったり、数多くの分析結果を出してグラフにまとめて報告書に仕立てても、それは「すごい」ことかもしれないが、「役立つ」とは限らない
役立つとは
- 現場の業務や経営の意思決定に分析結果を使うことで、用いないときよりも望ましい帰結を得られることを指す
高い予測精度やビジュアル的なグラフといったものは、すごいと思わせる「マジック」の効果を持っている
報告会ではすごいと思えた分析結果が意思決定に役立たないとなる最大の理由は 「役立てようとする意図」を持って、データ分析していないから
事業部門に食い込まなければ、課題は見つからない
成果につながらないデータ分析に陥らないようにするには
端的にいえば、現場の業務に役立つ成果を出すように、事業部門と連携してデータ分析を進めること
- 事業部門とデータ分析組織が一体化するほど密な関係を築くこと
- データ分析者は事業部門の担当者からお題が出てくるのを待っているような受け身な姿勢ではダメ
- 事業部門の担当者のところに何度も通って業務課題をヒアリングし、データ分析でできることをディスカッションする
会社全体に貢献してこそ評価される
データ分析専門組織は現場の業務改革に役立つソリューションを提供し、事業部門がそれを使って実際に業務フローや体制の見直しを行うことで初めて、会社に貢献できる
注意点
- 最新のIT活用事例は、産業界で広く共有すべき大切な情報。一方で、ITは手段に過ぎず、成果ではない
- ところがメディアの報道はこの１〜２年で過熱する一方で、その影響もあって「手段のすごさ」ばかりが脚光を浴び、「業務改革の成果は手段の優劣で決まる」と錯覚しそうにさえなる
分析者として意識するべきこと
- 最初に目的ありき、手段は道具であり、分析結果は成果ではない
メンバーの能力だけでなくマインドも育てる
- 分析者を奮い立たせるのは、自らが「見つけた」課題を「解く」意気込みであり、自ら「解いた」結果を現場に「使わせる」という強い意思が必要
データ分析者は単なる分析だけで終わらず、業務改革につなげるため「見つける」「解く」「使わせる」の３つの力を持たなければいけない
- ３つの力のうち「解く」については、数学的な分析手法やツールは既に用意されており、書籍やセミナーで学ぶこともできる。
- しかし分析手法を習得できれば、問題が解けるわけではない。
- 「特徴量を考える」「分析結果を解釈する」「現場の仮説力と融合する」といったこともできなければいけない
- これらの力は本を読んで学べるものでなく、OJTで学んで行くしかない
間違ってほしくないこと
- 事業部門の役に立つことだけを考え、それに必要なければ多様なデータ活用や新たな分析手法に挑戦することは「悪」だと言っているわけではない
- 様々なデータや分析手法を試す機会は貴重であり、そのチャンスをうまく利用して、しっかりと分析力を培っておくのは、分析者にとって最低限の務めである
第3章
事業部門から信頼と予算を勝ち取る
- データ分析が完了した後も、分析結果を現場の業務に導入できなければ、目標を達成したとは認められない。
- そうならないように、事業部門の担当者と分析者は運命共同体として協力し合い現場の導入に向けて努力する。
データ分析の費用対効果を見極める合理的なプロセス
- 分析組織側から費用(必要な予算)を提示して、事業部門はその費用を支払うだけの成果を期待できるかを総合的に判断する
事業部門にデータ分析を提案するには２つの準備が必要
- １つはそのデータ分析を実行できるだけの分析者の「能力」
- もう一つは、データ分析の実現性を事業部門に納得してもらうための「材料」
- 事業部門からデータ分析の予算を勝ち取るための提案コスト
予算を拠出してもらうためには
- まずはパワーポイントで事業部門にプレゼンし、事業部門の関心を引き出せたら、必要なデータをもらって「パイロット分析(部分的なデータを用いた分析や部分的な問題に限定した分析)」を行う
- パイロット分析の結果を事業部門に報告し、その分析結果を基に、本分析の実現性に納得してもらえて、ようやくゴーサインが出て、予算の獲得に至る
意思決定に活用されるデータ分析とは
- データ分析から得られた結果を手がかりとして使うことで、それを使わない場合に比べて合理的な意思決定を行えて、それを使わない場合はよりも望ましい帰結を得ること。
第4章
分析組織は経営に必ず貢献できる
全方位外交が基本
全組織と仕事ができる利点を活かす
データ分析専門組織のミッションは、データと分析力で業務課題を解決すること
- 業務課題は多ければ多いほど、分析力を発揮するチャンスは増える
- 全方位外交することで、全ての組織の課題を知り、データ分析で会社に貢献できる機会を増やしてきた
組織や業務によって、データ分析を活用できるポテンシャル(データ分析で業績に貢献できる範囲や金額)はマチマチ
- 相対的に見て貢献度が大きくなるのは「未開拓のエリア」と「大金が動くエリア」
未開拓エリアとは
- これまでデータ分析をほとんど活用してこなかった業務
- 未開拓エリアは基本的なデータ分析すらやってこなかったわけなので、データ分析で貢献できるハードルが非常に低い
大金が動くエリアとは
- 例えば年間１千億円の費用がかかるような大規模な業務
- 金額が巨額な分、0.1%効率化できるだけで、１億円のコストダウンに繋がる
- 大金が動くエリアは分析力がお金になりやすい、つまり会社に貢献しやすいエリアと言える
全方位外交による利益は３つ
- 全社的に活動していると社内で認知されること
- 分析組織のリスクヘッジになること
- 全事業部門にデータ分析を提供していると、一つの事業環境の変化に翻弄されず、安定的にデータ分析で会社に貢献できる
- 仕事のマンネリを防げること
- 全部門が分析対象となれば、データ分析を活用できる新ネタが枯渇することはなく、挑戦の機会に恵まれ、メンバーには新たな動機付けになる
経営者の視点で分析に臨む
環境変化を敏感に捉える習慣を付ける
事業部門の現場に入り込んでデータ分析を活用する機会を探すボトムアップ型のアプローチ
経営の視点でデータ分析を活用する機会を伺うトップダウン型のアプローチ
- 前者だけでは森が見えず、後者だけでは個々の木が見えにくい
- 複眼でデータ分析を活用できるチャンスを見つけようとすることこそ「分析力を武器に成長できる企業になる」
成果をアピールする
- 自分たちの貢献度をリーダーがPR
成果の説明には２つの観点から
- やったことの内容を説明
- 事業部門に対して自分たちが行った内容を紹介する機会を設けてもらったり
- 研究開発部門が主催する技術報告会の場を借りて説明してきた
- 事業に役立ったことを説明
- 事業部門がデータ分析を活用した業務改革の成果を経営層に説明するとき、資料に組織名やロゴマークを併記してもらった
社外へのPR
- どんな形でも成果を説明しても、課題を「解く」ところはみんなに伝わっても、「見つける」「使わせる」の成果はなかなか伝わらない
- 成果をアピールする打ち手に困り果て、最後に思いついたのが社外へのPRだった
まずは社外の人に価値を認めてもらい、あとから社内でも認知してもらうという「ブーメラン作戦」
- 日本人は「外の声」に弱いもの
- 社外で評価されれば、社内からも「社外で高い評価をされているのだから、きっとすごいのだろう」と認知してもらえると考えた
第5章
メンバーの幸福を勝ち取る
成長の道筋を示す
ステップアップの青写真を描く
分析組織のコンピテンシーとは何か
データ分析者に求められるコンピテンシーは、その分析者が働く企業の業種や業態によって異なるので一義的に決めるのは難しい
- 例えば、アマゾンのような企業では、ビックデータを扱うエンジニアリング力や最先端の分析手法を導入する高度なデータアナリシス力が求められる
- 一方、大阪ガスのような一般企業では、そういった力よりもむしろ、自社のビジネスにデータを活用する着眼力やそれを実現するための行動力の方が強く求められる。一般的に「ビジネス力」とよばれるもの
- 解く力とは、データアナリシスとデータエンジニアリングに相当する
- それに対し、「見つける力と使わせる力がビジネス力に相当するもの」と定義している
第6章
十八年かけて気づいた三つの無形財産
三つの無形財産
- ミッション
- カルチャー
- レピュテーション
無形財産は強い信念を持ち、時間を掛けて意識的に行動してこなければ醸成できなかった
私たちのミッション
メンバーの心に根づいて行動が変わる
私たちは「企業内イノベーター」
- 私たちのミッションが意味することは「業務改善は事業部門にもできる。しかしイノベーション（業務改革）は事業部門では難しい。データと分析力に強いビジネスアナリシスセンターが事業部門を手助けすることで、イノベーションを一緒に実現する」
心に宿していること
- 私たちの仕事は社内にイノベーション（業務改革）を起こすこと
- データと分析力は手段に過ぎない。使うけれども、手段にはこだわらない
- どれだけ素晴らしいイノベーションを考えても、現場が採用してくれなかったら無意味
- どういうイノベーションを起こすのか、どうやって現場（人）を動かすのかに知恵を絞る
- 成果はイノベーションの中身ではなく、イノベーションの結果のみ
ミッションは言葉で伝えるだけでは、決して人の心に根付かない。仕事を通して成功と失敗を何度も経験しながら、徐々に心に根付いていくもの。
会社のコンピテンシーとなる組織を目指す
会社にとって必要な組織であることと、コンピテンシーとなる組織であることは、意味合いが全くことなる
成果を出すだけでは必要な組織には慣れても、コンピテンシーとなる組織にはなれない。
データと分析力を武器に他社が簡単にまねできないイノベーションを起こし、ライバルに対して圧倒的な優位性をもたらしてこそ、コンピテンシーと言える
レピュテーションを獲得
- 社内からの財産が最大の財産
レピュテーションの獲得
- レピュテーションは一朝一夕で築けるものではない
- レピュテーションは人の心に宿るもの。目には見えない
- レピュテーションは信頼に値する行動や成果を通してのみ、相手の心に根づくもの
- レピュテーションは組織単位で勝ち取るものでもない。仕事は最終的には、人と人との信頼関係で決まる。個人単位で信頼を勝ち取っていく活動が欠かせない。
- 人材やデータやツールはお金を出せば、早期にキャッチアップできるかもしれない。しかしレピュテーションだけはお金を出しても買えない
- ただし、レピュテーションは環境の変化には強いが、内部崩壊は簡単に起こる。一度でもいい加減な仕事や逃げ出すような仕事、無責任な仕事をすれば「ビジネスアナリシスセンターは無責任だ」「データ分析はお金だけかかって役に立たない」といった噂が社内に広がる
第7章
分析組織のリーダーに求められるもの
モチベーションの維持は大仕事
データ分析の価値を生み出すのは人
企業内で働くデータ分析者には3つのモチベーションが必要
- 挑戦するモチベーション
- 壁を乗り越えるモチベーション
- 継続するモチベーション
挑戦するモチベーション
データ分析の出発点は、常に「データ分析でこんなイノベーションを実現したい」「データ分析でこれだけの成果を上げよう」といった本人のチャレンジ精神。「できそうなこと」ばかりを考えずに、その殻を破って「できたらすごいこと」に挑もうとするモチベーションを持つことが大切
壁を乗り越えるモチベーション
データ分析は思い通りには進まない。色々な分析手法を試してみても、周囲の期待にこたえられるだけの結果が得られない、せっかく良い分析結果がえられても現場が納得せずに使ってくれない、といったことは日常茶飯事。大きな壁を前にしても打ちひしがれず、「絶対にこの壁を越えてやる」と決意することが、大きなモチベーションにつながる
継続するモチベーション
データ分析のなかに手離れが悪く、いつまでも同じことを続けていかなければならない案件もある。何年も同じデータ分析ばかりしていると、誰しも気が緩み、惰性に流されやすくなる。そうはならず、もっと良いやり方を模索するとか、このデータ分析をとことん極めてやろうといった前向きな姿勢を持てるかどうかが継続するモチベーションになる
データ分析は最初に決めた目標やプロセス通りにうまくいくケースはほとんどない
- 要件定義に合致したものを決められた納期までに作りあげるSEの仕事とクライアントのニーズしか決まっておらず、要件は自ら考え、うまく行かなかったら何度でもやり直す分析者の仕事。
両者は全く反対の仕事
- 前者は「目標遵守型」で後者は「目標創造型」である
- SEにとって、データ分析をする上での最も高い壁は、目標遵守型の価値観に固執せず、目標創造型に頭を切り替え、新たな仕事の進め方を身に着けていくこと
優れた分析者が有能なリーダーになるわけではない
- 学校の先生のように圧倒的な知識と能力を持ってメンバーに分析手法を教えることではなく、メンバーの心をつかんで、人を動かすこと
- リーダーも神様ではないので、自らの過ちをメンバーに指摘してもらって自省することは大切
- リーダーは誰よりも高いモチベーションを持ち、キャリアアップに貪欲で、常に会社を主語にして物事を考え、メンバーや現場とのコミュニケーションを大切にする姿勢を持つことがはるかに大切
中期計画の策定
- 普段から経営課題や業務課題について社内のいろいろな組織の人たちとコミニケーションをしながら「知る努力」をする
- 新たなデータ分析やITの活用例について社外の情報にアンテナを張るようにし、無意識のうちに頭の中で両者が交錯するようにする
いざ中期計画策定のタイミングでそのような思索の蓄積がよみがえってそれを起点に、具体性や実現性を深めていく
分析組織のタクティクス
目的は清く、進め方は腹黒く
社内イノベーションを実現できるかどうかは、イノベーションの内容の出来・不出来よりも、むしろ、社内の抵抗をどう乗り越えれるかにかかっている
手段は何であれ、イノベーションを成功させるカギは、リーダーが抵抗を乗り越えることに熱意を持つことと、戦術的に行動すること
いかにして関係者の合意をとりつけるのか、誰が協力的で誰が協力的ではないのか、誰の合意が不可欠なのか
そうしたことを緻密に考え、誰からどんな了承を得ればよいのか、そのためにはどんな説明すればよいのか、どのタイミングでするのか、といったことを考え抜く
virtualboxでネットワーク設定でつまずいたのでメモ
macOSでvirtualboxを作成して windows環境にそのイメージをインポートした際にネットワーク設定ではまった際のメモ
- ovaファイルのイメージをインポート
- ネットワーク設定が正しくならない場合があるので、電源を入れる前にネットワーク設定画面を開いてセーブさせる
ホストオンリーネットワークの追加
[ファイル]→[環境設定]→[ネットワーク]→[ホストオンリーネットワーク]
- 新規にネットワークアダプタを追加する
[アダプター] IPv4アドレス：192.168.33.1 IPv4ネットマスク：255.255.255.0 [DHCPサーバー] サーバーを有効化にチェック サーバーアドレス：192.168.33.100 サーバーマスク：255.255.255.0 アドレス下限：192.168.33.101 アドレス上限：192.168.33.254
elasticsearch+kibanaをCentOS7にインストールしてみた
macOSでVM環境を構築して、elasticsearch(6.x)+kibana(6.x)をインストールした際のメモ
各種ソフトウェアのダウンロード
- virtualboxのダウンロード
- vagrantのダウンロード
vagrantbox.es
- 標準のテンプレートは以下サイトから取得できる
box追加
- centos7.2をインストール
$ vagrant box add centos7.2 https://github.com/CommanderK5/packer-centos-template/releases/download/0.7.2/vagrant-centos-7.2.box
vagrantFile
Vagrant.configure("2") do |config|
config.vm.box = "bento/centos-7.0"
config.vm.hostname = "192.168.33.10"
config.ssh.insert_key = false
config.vm.network "private_network", ip: "192.168.33.10"
config.vm.provider "virtualbox" do |vb|
vb.name = config.vm.hostname
vb.memory = "2048"
vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
vb.customize ["setextradata", :id, "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled", 0]
vb.customize ["modifyvm", :id, "--cableconnected1", "on"]
end
config.vm.provision "shell", inline: <<-SHELL
sudo systemctl restart network.service
yum update -y
yum install -y zsh vim tree telnet dstat git tig
SHELL
end
vagrant up エラーする場合
- 以下のサイトを参考に対処する
- virtualboxを再インストールするとうまくいった
Elasticsearch+kibanaのセットアップ
Elasticsearch requires at least Java 8. Specifically as of this writing, it is recommended that you use the Oracle JDK version 1.8.0_73.
$ yum -y install java-1.8.0-openjdk java-1.8.0-openjdk-devel $ java -version openjdk version "1.8.0_151" OpenJDK Runtime Environment (build 1.8.0_151-b12) OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
- 参考URL
Elasticsearch6.1.1インストール
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
- Installing from the RPM repository
$ sudo vi /etc/yum.repos.d/elasticsearch.repo [elasticsearch-6.x] name=Elasticsearch repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md
- yumでelasticsearchインストール
$ sudo yum -y install elasticsearch
- 起動設定
$ sudo vi /etc/elasticsearch/elasticsearch.yml ## ElasticSearchをインストールしたIPを設定 network.host: 192.168.33.10 http.port: 9200
- elasticsearchを再起動
$ sudo service elasticsearch restart
- elasticsearchの自動起動設定
$ sudo /bin/systemctl daemon-reload $ sudo /bin/systemctl enable elasticsearch.service
kibana6.1.1インストール
$ sudo vi /etc/yum.repos.d/kibana.repo [kibana-6.x] name=Kibana repository for 6.x packages baseurl=https://artifacts.elastic.co/packages/6.x/yum gpgcheck=1 gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch enabled=1 autorefresh=1 type=rpm-md
- yumでkibanaインストール
$ sudo yum -y install kibana
- kinaba.ymlの設定
$ sudo vi /etc/kibana/kibana.yml server.port: 5601 server.host: "192.168.33.10" elasticsearch.url: "http://192.168.33.10:9200"
- kibanaを再起動
$ sudo service kibana restart
- kibanaの自動起動設定
$ sudo /bin/systemctl daemon-reload $ sudo /bin/systemctl enable kibana.service
firewalld設定
- kibanaの5601ポート
- elasticsearch9200ポート
$ sudo vi /etc/firewalld/zones/piblic.xml <?xml version="1.0" encoding="utf-8"?> <zone> <short>Public</short> <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description> <service name="dhcpv6-client"/> <service name="ssh"/> <port protocol="tcp" port="5601"/> <!-- kibanaポート追加 --> <port protocol="tcp" port="9200"/> <!-- elasticsearchポート追加 --> </zone>
- firewalldの設定反映
$ sudo systemctl restart firewalld
- kinabaへアクセス
elasticsearchのインストールディレクトリ
- /usr/share/elasticsearch
Plugin
- kuromoji
- Kibana上で日本語を正しく解析する際に必要となるプラグイン
cd /usr/share/elasticsearch
sudo bin/elasticsearch-plugin install analysis-kuromoji
Elasticsearch6を利用する前に読んでおいたほうがいいもの
Content-Typeを指定しないとエラーになるので注意
curl -H "Content-Type: application/json" -XPOST http://192.168.33.10:9200/blog/article/2 -d ' { "title": "My Name Is Kitagawa", "content": "I love cat", "tags": ["red", "green", "blue", "orange"] }
- jsonで一括登録する方法
$ cat requests { "index" : { "_index" : "ropeway", "_type" : "event" } } { "test" : "fukuda" } curl -X POST -H "Content-Type: application/x-ndjson" http://192.168.33.10:9200/_bulk?pretty --data-binary "@requests"
ElasticsearchとRDBとの比較
- インデックス：データベース
- マッピングタイプ：テーブル
- カラム：フィールド
- レコード：ドキュメント
パッケージ構成
パッケージ構成は、大まかに分けて３種類...
One Package
- Repository自体を単一のパッケージとみなす
- Coverageが取りやすい
- Libraryなど、簡素な構成で済むものに向いている
. ├── ctx.go ├── debug.go ├── error.go ├── handler.go ├── handler_func.go ├── jsonrpc.go ├── method.go └── parse.go
Flat Package
- 各パッケージの責務を明確にし、分割を行う
- 機能ごとに分割しているイメージ
- Go言語の標準パッケージの構成に親しい考え方
- 階層を掘ったとしても、２階層ぐらいで落ち着く
- パッケージの責務を明確にし、お互いに疎結合を心がける
- Micro Serviceや、Middlewareなどに向いている
.
├── ctx
│ └── ctx.go
├── debug
│ └── debug.go
├── error
│ └── error.go
├── handler
│ ├── handler.go
│ └── handler_func.go
├── jsonrpc.go
├── method
│ └── method.go
└── parse
└── parse.go
Multiple Packages
.
├── controller
│ ├── debug
│ │ └── debug.go
│ └── handler.go
├── jsonrpc.go
├── model
│ ├── ctx
│ │ └── ctx.go
│ ├── error
│ │ └── error.go
│ ├── marshal
│ │ └── unmarshal.go
│ └── method
│ └── method.go
└── view
└── index.html.tpl
DDD(ドメイン駆動設計) Domain-Driven Design
- 顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法
- DDDでは大規模な１つのシステムとデータベースで構築するのではなく、業務にとって適切な独立したシステムに分割する
レイヤードアーキテクチャ
- ドメインロジックと、それ以外(DBやViewなど)を切り離すのが目的
Lightweight DDD
src/
└── myapp
├── application
├── domain
├── infrastructure
├── interfaces
└── library
４つのLayerで構成
- Application
- Domain
- Infrastructure
- Interface(s)
Application Layer
- Domain layerの処理をまとめInterface Layerに提供
- Flat Packagesの思想でパッケージ分割
- interパッケージに活用し、共通ロジックを隠蔽
- Domain Layer
- Domain Layerは、他Layerには依存しない
- Entityや、Enum,Interfaceを提供
- Infrastructure Layer
- GAEのライブラリをWrap
- 基礎的な処理を保持
- Logging
- Validation Rule
- World Filtering
- Value Get/Set in Context
- Persistence
- Interface Layer
- JSON-RPCのHandler群
- Search.FindProducなど
- Original Error定義
- 32044:Not Foundなど
- Interceptor群
- Contextに色々詰める
- Action Loggerなど
- その他
- Startup処理、状態取得
- JSON-RPCのHandler群
最適なパッケージ構成
相互参照せずに快適に開発を進められるパッケージ構成を見つけるのは難しい
第１ケース
プロジェクトルートに展開する
. ├── db.go ├── errors.go ├── handler.go ├── main.go └── model.go
概要
- ほぼ全てのファイルをプロジェクトルートに展開するやり方、mainパッケージに集約する
- utlity的な共通処理も、構造体もinterfaceもその実装も、全て同じ階層にあれば、パッケージを切る必要がない
特徴
- CLIツールや小さめのサーバー、あるいは小さめのパッケージなどには適している
デメリット
- 中規模以上のAPIサーバーを用意するとなると厳しい
- 20個以上とかファイルが乱立すると分かりにくくなる
第二ケース
MVC
. ├── main.go ├── clients ├── config ├── controllers ├── models └── views
.
├── main.go
├── clients
├── config
├── controllers
├── models
├── article
└── user
└── views
- リソースごとにパッケージを区切りたくなるが、これでは大体相互参照の問題にぶつかる
article.goとuser.goなど、構造体やそれに付随する実装を全てmodelsディレクトリ直下に展開するという流れがある
小さめのAPIなら許容できなくいが、主要APIとして利用されるサーバーコードを書くときはリソースが多くなり、goのソースコードのファイルが多くなる
参考URL
PyCharmでpythonを動作させてみた
- python2.系とpython3.系をwindows環境にインストール
- virtualenvで切り替えが可能なのでいいかも...
C:\Users\xxxx>python Python 3.6.3 (v3.6.3:2c5fed8, Oct 3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> ^Z C:\Users\xxxx>py -2 Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 bit (AM D64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
python2.系とpython3系のダウンロードは以下から
