f:id:yuzutas0:20181016110318p:plain:w250

概要

ITmedia様の＠IT（アットマーク・アイティ）に連載記事を寄稿しました。

開発現場に“データ文化”を浸透させる「データ基盤」大解剖
「使われるデータ基盤」「組織におけるデータ活用」といったテーマに関心のある方のヒントになればと思います。

記事一覧

殴り書きのメモ

振り返り（執筆）

執筆ツールは最終的にGoogleDocsで落ち着いた。
- レビュアーと共同編集が可能。
- 最終成果物はWordに出力して受け渡しが可能。
書き出して初めて気付くことがある。
- 例えば、システム設計については大まかな意図だけを伝えるつもりだったが、実際に書いたら抽象的で分かりにくくなって方針転換した。
- 当初想定の通りにはいかない。慣れないうちは「どんどん書いて、どんどん書き直す」スタンスが良さそう。
テキストで情報を伝えるのは難しい。
- 図解を多用した。分かりやすくなる。
- プレゼンスライドだと【おしゃれな画像＋メッセージ】で鼓舞しているように見えても、同じ言葉を【テキスト単体】で書くと説教臭くなってしまったので大幅に修正した。

振り返り（進め方）

執筆であっても仕事の勘所は同じ。
- 例1:最初に全体の方向性を合意形成する。
- 例2:早い段階で20点版を提示してフィードバックをもらう。
色々な人にレビューを依頼した。
- @int_ttさん、@akito0107さん、@shoitoさん、その他お世話になった皆様、ありがとうございました！
- 自分よりスキルのある人にツッコミをもらうと勉強になる。
- 複数人にレビューを受けたのは正解だった。
  - 「全員から指摘される箇所」と「一部の人に指摘される箇所」を区別できる。
  - ソフトウェアエンジニアにも派閥があるので、同じ言葉に対する受け取り方が人によって違う。
  - 普段そこまで一緒に仕事をしていない人のほうが、先入観がないので客観的にコメントできる。

振り返り（コンテンツ）

記事の位置付けは「ケーススタディ」に振り切った。
- 「データ活用」というテーマについて「ハンズオン」「用語の解説」は世の中に山ほどあるが「ケーススタディ」がまだまだ不足していると考えた。
- MBAで経営を学ぶ時と同じように、テクノロジー活用に関しても豊富なケーススタディを参照することで、バズワードに振り回されない意思決定ができるようになると良いのではないか。
伝えたいことの1割も書けなかった（悪い意味ではない）。
- むりやり詰め込むと伝わらない文章になってしまう。筆者と読者には情報の非対称性がある。
- 例えば「データ基盤においても進化的アーキテクチャを踏まえて設計しましょう」という旨の長文があったが丸々カットした。
  - というのも、どうしても解説事項が多すぎて、記事全体の趣旨が変わってしまうから。
- ポジティブにカットして「今回の連載とは別のネタが見つかった！」くらいの心持ちが望ましい。
  - 「進化的データ基盤アーキテクチャ」（？）という別のテーマに切り出して考える。
  - 記事もデータ基盤システムと同じ。疎結合にして責務を分ける。
  - 記事の「数」を脳内KPIにしている人は、自然と分割する発想になるだろうなと思った。
  - ブログを書いて、反響を勝ち取って、その実績をもとに企画を持ち込んでやるぜ！くらいのモチベーションだと最高。