プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
結論としてはプロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は（プロフェッショナルであるべきアーキテクトに関して）アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成）についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
もちろん、個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることなのではないかと思います。
ルビィのぼうけん 読書感想
ルビィのぼうけん
DevLove関西のイベント「それぞれの現場におけるチームづくりの試行錯誤」に参加したのですが、その中で翔泳社の岩切さんが１冊だけプレゼントしていただけることになりました。
１冊しかないので参加者でじゃんけん大会となり、じゃんけんとても苦手なのですが自分が勝ちとりました。
岩切さん、ありがとうございました！
内容の紹介と感想
帯の紹介によるとプログラマー的思考法を育む知育絵本、とのこと。
読んでみた感想ですが、非常に示唆に富んだ物語で面白いなーと思います。
子供が気に入って何回も読めばいろんなことに気付きそう。
そのために結構読み聞かせる親御さんなどのアシストも重要な気がします＾＾；
ルビィのほかにペンギンたち・ジャンゴ・雪ひょう・ロボットたち・きつねたちといったキャラクターが登場するのですが、たとえばペンギンたちはLinuxというよりもUnixの基本的な考え方「小さいまとまりに分けられた問題を好む」という性格で描かれていて、おもしろいです。
プログラミングが好きな人が読んでも、このキャラクターの性格は、こういう理由かなと想像しながら楽しめたり。
ルビィはある目的のために、そういうキャラクターたちとかかわりながら冒険を繰り広げる感じです。
周りのキャラたちとコミュニケーションをしつつ、出てくる難題を解決するのにはどうしたらいいか工夫をして解決していくのですが、どう伝えたらペンギンたちなど他のキャラクターに伝わるか、道具をどうつなげたら取りたいアイテムにたどり着けるか、みたいなところが見どころだと思います。
絵柄もカラフルで非常にかわいいので子供が見たら単純に楽しいんじゃないかなぁと思います。
後ろのほうに子供と一緒にパズルをとくみたいなワークがついていて、課題解決するためのアルゴリズムとか考え方を身に着けるのにとても役立ちそう。
そしてそれはプログラミングにつながっていくものだと思います。
ワークは子供とやる前にちょっと大人同士で練習してみてもいいかもしれないと思いました。
これからの時代、プログラミング的な思考のあるなしの違いは大きくなってくると思います。
それだけがすべてじゃないけれど世界を変えていく力の土台部分ですし。
子供たちのこれからを変えていくインパクトのある本だと思います。
「Whyの依存関係を明確にすることにフォーカスした質問」をどう活用するか？
暗黙知になっていること、とくにタスクや課題の依存関係などを明快にするには質問を「いい感じに考えるべきポイントにフォーカスして」繰り返すといいなと最近思っています。
というのもそういう質問の仕方がうまい人が同僚に入ったからなのですが。
『考えるときには考えるべきポイントを間違えないことが大事だ』
俺ガイル２期で平塚先生が何回もおっしゃっています。いや、何回も言ってるんじゃなくて何回も見てるんだった。
会社なら会社としてのビジョン、ミッションというのがまずあるはず。
ビジョン、ミッションにより近い質問からブレイクダウンしていく。
「プロジェクトのこの作業はこのミッションに貢献しているからやっているのですか？」
ということに答えるために、なぜなぜ分析っぽく
「会社の目標は何か？」
「会社のミッションは何か？」
「IT部門として成し遂げたいミッションは何か？」
「利益向上、コスト削減、リードタイム短縮のために作りたいインフラ基盤・アプリケーション開発基盤は何か？」
「なぜこのプロジェクトをやるのか？」
という依存関係のわかる化につなげていきます。
ハイコンテキストからローコンテキストへ置き換える作業でもあると思います。
で、その場で質問とその答えを聞いた人はわかるんだけど、それだけじゃなくて見える化したい。
そうすることで「ぶれないマニフェストをサジェスチョン」（※俺ガイル２期の意識高い系会議より）することが可能になると思うのです。
『「Whyの依存関係を明確にすることにフォーカスした質問」をどう構造化するか？』
前回参加したDevLove関西のイベントの情報設計の話ともつながると思います。
やり方自体はツリー構造でいいんじゃ、ってことなのですが。
メンバーだけで通じる暗黙知、ハイコンテキストを少なくし、周囲の人(ステークホルダー)に、常に見える状態にして『透明性』を出したいです。
その上で「本当に透明になっているか？正しいか？」ということを『検証』できる状態にしたいです。
さらには検証した結果を常に改善、『適応』できるようにしたいです。
それも楽に。
『ぶれないマニフェストをサジェスチョン』
Whyを共有できてないことに起因する本当に無駄な会議をしたくない。
やるべきことにフォーカスして仕事していきたいものです。
難しそうな「情報設計」に実際にふれてみる #DevKan
2016年3月18日に開催された表題の勉強会に参加してきました。
株式会社インパス 山下 一樹さん
UXをインクリメントするのに、UIだけをカバーしてるのはダメで、カテゴライズなどの情報設計も重要。
建築のプロセスに当てはめてみると、建築資材からコンセプトを決め、導線を決め、間取りを考え、使いやすさを実現するといった整理・設計が非常に重要になる。
情報設計は地味で出来て当たり前と捉えられがちだが、ディテールに拘る意味では計測をしっかり行うこととあわせてガチで重要だと思う。
デザインやUIだけ決めて工数見積もるとかやめて、コンセプトで情報設計に徹底的こだわるべきなのではないかと思う。
山下さん、会場の楽天さん、DevLove関西スタッフの皆さま、ありがとうございました。
『FRONTEND CONFERENCE 2016』に行ってきました
2016年3月5日にあった表題のイベントに参加しました。
特に良かったと感じているのは、以下の内容です。
大型フロントエンド開発におけるTypeScriptとDDD
奥野賢太郎さん Chatwork株式会社
累計メッセージ数 10億
以前のWeb版Chatwork
- moduleなし
- jQuery
TypeScript導入の経緯
『型がないとしんどい. 』
チームが拡大
1人 -> 8人 拡大することによる特有の問題が発生
- コメント、コーディング規約
- デザイナーとの連携
- テスト
- ビルド、タスクランナー
コメントは意図を残す
「なぜそう書かざるを得なかったのか？」
ドキュメント、コーディング規約
外注さんは背景をご存知でない。だが、JSやHTML5は得意。 暗黙知であったものを共有することが必要。 主要な処理は「エントリポイント」を用意し、新しい人でもコードをたどれるように。
ex. onclickから発火して、どのようにデータを取っていくのか
『入り口、玄関をきれいににしておく』
エントリポイントを用意する考えは参考にしたいです。
dockerfileなどのように。
デザイナーさんとの連携
- SCSSを採用 変数やmixin
エンジニアがTypescriptでHTMLのテンプレートを管理
テンプレートでUIをロジカルに設計してHTMLを構成する
そこから先がデザイナーの仕事
これをちゃんと分離していることがUIの改善を行う上で重要なんだと思います。
デザイン仕様書の取り扱い
その結果として「リポジトリ内で検索しやすい！」とのこと
単体テスト
mocha + power-assert
モックを扱ったり型違反を意図的に扱ったりする ここだけTypescriptではなくES2015で記述する部分も
不安なロジックはしっかりテスト
カバレッジ100%は目指さない。 もし実装を変更するたびにテストが赤になっていたらそもそも何か問題がある。
設計変更で壊れるテストをなくせるテスト自体も負債化する
E2Eテスト
PageObjectパターンを導入する
PageObjectは自分もGebで使っていますが、非常にわかりやすくシナリオと実現方法を分離できます。
Karmaテスト
- 開発初期のテストはmochaとE2Eだけだった
- イベントハンドリング周りの検証
ちょっと試してみたい。。。
タスクランナー
- gulpを使用
- 属人性に気をつける あっという間に秘伝のタレ化
gulpファイルの差分を見やすくするように管理
検証環境の構築
検証環境へのデプロイもgulpで構築 @kyo_agoさん
- 実際のAPIレスポンスを用いて開発
build
- build時間はモチベーションに直結 browserifyをwebpackに替えたら5分の1 tslintはバックグラウンドで回すように scssだけのタスク
TypescriptとDDD
約400のソース
- Component, Service, Utility, API
- チームメンバー全員で共有するのが大変
Typescriptの型はチームメンバープロダクト全体の把握を助け、揺るぎない情報となる
大きなシステムほど「膨大な知識」が要求される -> Domain Driven
型の恩恵
一ヶ月後の自分は他人
コンパイラはJSDocと違って嘘をつかない むしろ@paramに型情報を書かない
短いコメントを付けるくらいなら型名をIDEを使うと、ショートカットやクリックでファイルを辿れる
テストの捉え方が本質にせまる -> 振る舞いそのもの
『実行時Assert』自信を持ってリファクタリング １、２行の変更であれば型が壊れていなければ安心
DDD
- 完璧なDDDの実践は難しい 言語的な面もチーム共有の側面も
ユビキタス言語 エンジニア、デザイナー、ビジネスでの共通言語
コンテキスト
coreドメイン
- User, Message, Taskなどのドメインモデル コレクションごとのClass
Applicationドメイン BindableUser class
『３人』という文字列 {length}人ではなく{UserCounts}
TypeScriptとDDD
Viewフレームワークとの付き合い方
オワコンなんてない フレームワークの「変動に強いアーキテクチャ」の検討
フレームワークロックインへの考え方
いつでも捨てても大丈夫なように抽象化された実装にする
Applicationドメインに表示描画用のロジックを集約
Angular2化を始めている
二槽式アーキテクチャ フロントエンドフロントエンド CSSとかDom
フロントエンド・バックエンド Coreドメイン、Applicationドメイン
ScalaJSに置き換えたい
感想
『型がないとしんどい. 』とはどういうことなんだろう、と思いました。
型がある複雑な言語だと抽象化する必要があるときに複雑なステップになったりする傾向がある、と知り合いに聞いています。
ChatworkのサーバサイドはScalaと聞いているので、その影響が多いんだろうかと思いました。
型で管理するのはいいけど、特定のデザインパターンに縛られることだけは避けたい気がします。
TypeScriptを使ってIDEでの操作しやすくしたり、テストを書きやすくするってのは良さそうだけどAngularはちょっと見たいな気持ち。。。
そうしたViewフレームワークなどのJSのメインストリームの変化に対しては、抽象化している「変動に強いアーキテクチャ」で対応するというのは素晴らしいと思います。
サーバーインフラの文脈でも『Docker、Vagrant、Serverlessアーキテクチャとかに依存しすぎない』、と同じように言われています。
変動に強いエンジニアになりたいです。
不勉強なところはとにかく何とかしたい。。。
奥野さん、FRONTEND CONFERENCE 2016のスタッフの皆さま、ありがとうございました。
大事なことはすべて村上春樹の『風の歌を聴け』に学んだ
この記事は随時追記するかも。
かなりポエミーな雑記です。
『僕たちが認識しようと努めるものと、実際に認識するものの間には深い淵が横たわっている。』ってずっと昔に書かれているんだけど、素通りしてしまっている気がする。
これってつまり『認知のバイアス』だとか、『7つの習慣』でいうところの『パラダイム』の議論にも通じていると思う。
好きとか通り過ぎて何回も読み返しているけど、まだこういう気付きがある。
「インフラエンジニアの現場における仕事と文化」のDiff #DevKan
2016年2月5日のDevLove関西の表題のイベントに参加してきました。（いちおう受付スタッフも）
Developer Infrastructure in DevLove Kansai
話し手：Wantedly 坂部広大さん
www.slideshare.net
Devlove現場甲子園東日本大会での坂部さんの話がもう一度聞きたいと思って、DevLove関西でもやってもらえました。 念願かなった感じです。
syncメッセンジャー
１月からsyncというメッセンジャーアプリをローンチしたとのこと。 syncはfacebookのメッセンジャーが仕事の話が混じってしまうことを嫌う人のために、仕事領域のメッセージサービスとして特化した形を目指しているそうです。
「話を聞きに行く」「応募情報の自動入力」のボタン(OpenAPI)を作った話。
東日本大会のときはわかっていなかったのですが、相川さんというかたとタッグを組んで実現されてたのですね。 ただOpenAPIを作るというだけではなく、企画書を書いたり、使ってもらえそうなところを訪問してちゃんと営業までする、というのがインフラエンジニアとしての領域、もしくはエンジニアとしての領域を『越境』していると感じます。 そしてそれが、「Ownership」ということなのかと。 そうでもしないとWantedlyのメンバーとして生き残れない感じがあるんじゃないかなぁと邪推してしまいます。
インフラエンジニアがボトルネックにならないために
Wantedlyのサービス開発はとにかくプロトタイプを早く作り、どんどん早くリリースして検証したいという感じらしいです。 Devのエンジニアがリリース依頼して、インフラがリリースするという流れだとタスクが溜まってインフラチームがボトルネックになる。
解決する道は２通り
- インフラエンジニアを増やして人海戦術
- インフラの質を上げる
Wantedlyは後者のアプローチを取ったそうです。
『Facebookは5人で10万台のサーバーの面倒を見ている。俺たちもfacebookになろうぜ！』
『変化に強いインフラ』を目指すために
- 自動化
- セルフサービス化
を実現する。 直近の取り組みとしてCoreOSにすべてのコンテナを置き換えたとのこと。 ChefやPackerを使った構築の自動化だと、結局は「秘伝のタレ」化がなされてしまい、アプリのエンジニアがどこを変更すればいいかわからなくなるとのこと。 Dockerfileだけにしてしまえばインフラエンジニアじゃなくてもわかる。
GitHub Issueのフル活用
これはエンジニアだけでなく、ビジネスサイドの人もそうです。 そこに「Why」と「What」を必ず盛り込むため、チーム間でIssueのバトンタッチができるとのこと。 そして、PullRequestで「nginxのワーカープロセスを議論する」ということができているとのこと。
『インフラエンジニアこそ情熱的に仕事をする。』
感想ですが、どうすればこのように越境するエンジニアリングができるのか、ということを考えながらこれから先歩んでいきたいと思っています。
WhyとWhatを大切にし、必要ならばどんどん企画書を書き、営業もできるように。。。。
地道にAWS構築自動化に取り組んでいるお話し
話し手：Serverworks 永田明さん
www.slideshare.net
Serverworksのインフラエンジニアとしての構築のお仕事
サーバーワークスの提供しているのはAWSを中心として様々なサービスを組み合わせて最高のサービス基盤（インフラ）を提供すること。 そのため、セールスをしている人もセールスと言いつつ凄腕のエンジニア。 大体の構築はわかる。
もともとは、BacklogのWikiにパラメータシートをMarkdownでうめこみ、それをもとにお客様とやり取りするスタイル
そのほかAtlassian Confluenceにノウハウをためているとのこと。 でも、、「その情報あったんかい！」てなることも多いとのこと。
Wikiに記述されたパラメータをAWSのマネジメントコンソールからポチポチ転記。 その結果としてミスすることもある。
属人性が非常に高い設計フェーズだった！
自動化タスクフォース
これではあかん、ということで構築を自動化しようという運動が持ち上がったそうです。
最初にやったのはYAMLをJSON(AWS CloudFormation)にするスクリプトの作成
やってみたけれど、課題が…
CloudFormationのそもそもの課題として動かないとどこがおかしいのかわかりづらい。 AWSマネジメントコンソールは入力値のチェックもしてくれるし、元のほうがよかったのでは…
でも
そもそもAWSはプログラマブルなサービス そして我々はトップレベルのベンダー
自動化を続けるために、小さく早く試して、たくさん失敗できるようにしよう
まず、達成すべき課題として以下の２つがある * YAMLの二重管理 * スクリプトの実行環境がローカルで毎回アップデートについていかないといけない
これを解決するために
WEBアプリ化
Jenkinsによるバッチ処理実行するようにすることで、実行環境が常に最新化されスクリプトが実行する人が気にしなくてもいいようになった。
そして、Jsonだけじゃなく、Markdownを生成。
生成されるのは、属人的に作られたものじゃなく、フルスペックのパラメータ表。
これによって、ひな形のYAMLができて、無難な設計が共有されるように。
いわば『秘伝のタレ』
自動構築化後の課題
自動で構築しても確認は必要。 そして、確認は目視。 CloudFormationは動かないとどこがおかしいのかわかりづらい問題。 逆に動くと快感らしい。。。
確認のためにRSpecをもととしたWebアプリをつくる、、、ということを目指しているそう。
自動テストの文化を作るところから再スタート
感想ですが、今までやってきたことがアンチパターンになる場合もある、という言葉に深く共感します。 そのために、改善と軌道修正をやめたら負けということも。
自分も今の現場で自動化の取り組みをしていますが、今まで築きあげてきたものがレガシーになったときに、捨てたり式年遷宮的にちゃんと切り替えができるように考えていかなければいけないんじゃないかなーと思いました。
全体の感想
スタートアップとクラウドのトップベンダーという２つの現場の文化の違いはとても感じられたし、自分の現場とも比較することができ、とてもよかった！
坂部さん、永田さん、会場のMOテックスさん、参加してくれた皆さま、本当にありがとうございました。
