エンジニア立ち居振舞い：エンジニアにもコンサルティング的思考を
このようなエントリーがあったので、私も普段気を付けていることについて少しだけ書いてみたい。
イシュー分析ちゃんとやってますか？
何か「こんな機能が欲しい」とクライアントから要望があがった時。仕様を確認したらすぐに開発を始める、という人はさすがにいないと信じたい。
が、なぜその機能が必要なのか？そもそもどんな問題を解決したいのか？この検証プロセスを軽く考えている人が、エンジニアには結構多いように思う。
コンサルティングに近くなるが、イシュー分析することを怠っていると、良いシステムは出来ない。
何のために必要なのですか？程度の質問までは、おそらくエンジニアでも誰しもやっていると思う。でもそこから更に、その変更によって解決されることは、果たして本質なのか？まで追求しているだろうか。
機能の剪定が目的ではない
なるべく作らない、という話にも少し似ているけど、ちょっと違う。機能をふるいにかける事が目的ではない。
表面的に見えている事が必ずしも問題の根本原因とは限らない。顧客の言葉を鵜呑みにしない。こういう機能が欲しいと言われた背景や原因、その原因によって不便を感じている人の数、機能変更によって発生する利用者の日常業務への影響など。イシューをどんどん掘り下げいてき、本当に解決すべきなのは誰のどんな課題なのか、それに対して本当に必要な機能とは何か。しっかり考える。
そんなのエンジニアが考えることじゃないよ、と言う人もいるかもしれない。そういうのはディレクターやUXデザイナーがやる仕事でしょ、という人もいるかもしれない。
しかしこれらを意識して仕事をすると確実に違うのは、一覧表一つ作るにしても、どういうソート順にするべきかが明確に分かることがある。一覧の列名、さらには列の並び順を考える場合にも、適当になることがない。そしてそれらは、残念ながらあまりドキュメント化されることがない。
私は、かつてコンサルティング会社に所属していて、そういった分析を数多くやってきたけど、これは何もコンサルティングだけでなく、エンジニアであってもデザイナーであっても、はたまた営業であっても必要だと思っている。
エンジニアは技術的なことだけを解決すれば良い、と思う人も多いかもしれないけど、私にとっては喜ばれるシステムを作ることがエンジニアの存在意義であり、技術うんぬんはあくまで実現手段の一つに過ぎないと考えている。
なんで にんげんは みんな カゲを もってるの？
寝る直前に娘から「なんで人間はみんな影を持ってるの？」と聞かれました。影を持っている、という発想がなんとも可愛いらしい。可愛いなぁと思うと同時に、幼児にはどうやって説明したらいいんだろう？と悩みました。
こういう質問には濁さずちゃんと答えてあげたい。でもちゃんと説明しようとすると5歳には結構難しい・・・
私 「影を持ってるのは人間だけかな？」
娘 「猫ちゃんも持ってる！」
私 「じゃあ動物だけなのかな？」
娘 「あ、椅子も持ってる！」
私 「影は1つかな？」
娘 「んー、わかんない」
簡単な質問で、どこまで理解してるのかなぁ〜と探ってみたけど、ほぼ何も分かってない、ということだけ分かりました。(^^;
「光があるから影が出来るのよー」的な説明だけじゃ、ふ〜んで終ってしまう。せっかくこういう科学的な疑問をぶつけてくれたのに、絶対に適当な回答で終わらせたくなかったので、無い知恵を絞って考えてみました。
"光る"ってどういうこと？
影の話をするためには光源の説明が不可欠です。
ところで、この部屋の中に光ってる物はあるかな？
こんな単純な質問でも速攻で「わかんない」と言われてしまい、正直挫けそうになりました。普段「お星さまが綺麗に光ってるねー」などと会話していたので、てっきり"光る"という現象そのものは理解していると思っていましたが、実はこれも娘的には理解が曖昧だったようです。意外な盲点でした。
そこでヒントを出しました。
ほら、天井のライトは光ってるね！他には無いかな？
そのヒントで、他のライトを指したり、光るオモチャを持ってきたりしました。うん、これで"光る"については大丈夫かな？と思った時。
「これも！」と言って持ってきたのは、銀色のキラキラシールが付いたオモチャでした。おや・・・
私 「これ、真っ暗なお部屋に持っていっても光るかな？」
娘 「うん、光ると思う！」
私 「そっかぁ・・・じゃあこれを、廊下に持っていってごらん？」
"光る"という意味では確かにキラキラシールも反射で光ってる。私の表現が悪かったな、と反省。そして「光ってなかったー」と帰ってきた娘。
実はそのオモチャ、スイッチを入れると内蔵ライトが点灯するのです。そこで今度はスイッチを入れて廊下に置くように言いました。
娘 「光ってるよ！」
私 「廊下は真っ暗なのに光ってる。つまり光がオモチャから出てきてるってことだね」
これでやっと、"光源"という言葉は伝わらなくても、私が言いたかった"光る"については、なんとなく把握してくれたようです。
光は進む
でも一番大切なのはこの次です。すべてはこれが言いたかった。
オモチャから出てきた光も、ライトの光も、まっすぐ進むんだよ。
1つの方向だけじゃなく、外側に向かって色んな方向に出ていくけど
でも必ずまっすぐ進むんだよ。
必ずとか言い切ってますが、まぁここで屈折や重力レンズの話とかはさすがに早すぎますからね・・・。
それより"必ず"という言葉のインパクトで興味を惹きつけるほうが大切。ちゃんと理解したかどうかは不明ですが、娘も「光はまっすぐ進むー」と繰り返してました。何かしらは伝わったと思う。たぶん。
光は進む。これが影を説明するのに絶対不可欠で、これが言いたくてここまでかかってしまった。。。
影は光のとうせんぼ
ここまで来たら後は楽勝でした。
まっすぐ進む光の、通り道の途中に人間や猫がいると、光はそこから先に進めなくて、その部分が暗くなる。これが影。
あと、影は1つだけじゃないという事も。
うちのリビングには2箇所に天井ライトがあるので、その中間あたりに立ってダンスをすると、うっすら2個影が出来ているのが確認できます。それを見ながら、
「影は何個ある？」「どうして2個になったのかな？」などと確認してみたら、ちゃんと分かってたので安心しました。
子どもの「なぜ？」や「分かった！」を全力で共感したい
影を説明するだけでとても大変でしたが、科学的な疑問には一緒になって考えたいし、子どもが何かを発見をしたら私も一緒に驚きたいのですよね。
子供の頃、無限だと思っていた宇宙が実は有限だと知り、大興奮して親に話したところ「ほぉ〜そうか〜」程度の反応しかなく、そういうことが何度か続いて、親に話してもムダだなと寂しく思ったんですよね。今思えば、3人も子どもがいたら、一々そんな話に新鮮に驚いてみせる余裕もなかったんだろうと思いますが。
そんなこともあり、私は可能な限り一緒に興奮したいな、と思うのです。
あと、今日みたいな可愛いらしい疑問は、なるべく覚えておきたいな。とも思ったのでした。
his birthday 翻訳チャレンジカップ
色々実験してみたのでメモ。くだらない検証結果です。
このようなブログエントリーがあって、ブックマークコメントで「前後の文脈がないから判断できないのでは」というツッコミが多数だったので、情報を与えればGoogle先生は意図したように翻訳してくれるのか？を実験してみました。
結果はこの通り。
前後に父の誕生日だと分かるような情報を与えても、her birthday となる。しかも最後の文章では his mother となっていて、父の母、つまりお婆ちゃんまで登場してしまった。
ただし、「自分の誕生日」という文章については、正しく his birthday となっているので、「自分の」という表現については、そこそこの精度であると思われる。
いくつか試すうちに「父」とか「母」という固有名詞を繰り返すと精度が落ちる傾向が見えてきた。
そこで次は、文章を減らして、最後の「父」を「彼」にしてみた。人間なら「この日は父の誕生日」という前情報があるので、高確率で his birthday となるはずだ。（だよね？）
相変わらず her birthday のままだ。
次に、「怒っている」から「悲しかった」に変更してみたところ変化が起こった。
やっと his birthday になった！！
ここで見えてくるのは、Google先生の思考は「怒っている」なら対象は女だろう、というロジックの重みが強いのではないかということ。
ちなみに、「父は悲しかった」にしても、相変わらず her のままであるので、夫婦間だと感情の原因は女側という判定がさらに強いのかもしれない。ある意味正しくはある…
インフラエンジニアでもない私がクラウドを勉強し始めた時の話
先日Google CloudのCP100という無料のトレーニングを受講してきました。これは、基本的に座学でGCPのサービス全般を広く紹介してくれる内容で、AWSの知識しかなかった私には大変有意義なものでした。でもまったくのクラウド初心者だと、出て来る用語が分からず苦労するのではないかなと思ったのです。
そんな話をツイッターでしていた時に、まったくのクラウド初心者だった私がどうやって勉強を始めたっけな？と思い返してみて、誰かの参考になればと思ったので書きます。誰の参考にもならないかもしれないけど…(汗)
ことのはじまり
アプリ開発の経験しかなくインフラのことはさっぱりだった私が、AWSのユーザーグループの勉強会に初参加したのは約2年半前でした。
初心者向けの内容だったにも関わらず全然理解できずで、聞く用語全てが初耳くらいの勢いだったので心が折れそうになりましたが、その時の私は上から下まで全て一人で運用出来るようになりたい野望があったので、その日のうちに「クラウドデザインパターン設計ガイド」の書籍を購入しました。
※注意：アフィリエイトになってます、リンクだけだと書籍のキャプチャが表示されなかったので… お前のアフィリエイトなんぞ踏みたくないわ！って人はAmazon等で検索してください。当時私が購入したのは別の書籍ですがそちらは古いので、最新のを掲載してます。
書籍でなくても、Webサイトからも見られます。（ただし書籍と違って画面キャプチャ等はない、文字情報のみです）
クラウド全般というより、AWSを使う前提の記述なので用語はすべてAWSになっていますが、どのクラウドも基本は同じなので見ておいて損はないと思います。
私は書籍を隅から隅まで読みました、分からない用語はググりながら3周くらい読んだ気がします。この手の書籍は、必要な箇所を辞書的に読むものだと思うんですが、私にとってはほぼ全てが未知だったのと、普通に読んでて楽しかったのもあり、苦労しながら読んだという感じではありませんでした。利点と注意点が明確に書かれているのが個人的には非常に良かったです。実際に手を動かして覚えるのが一番良いとは思いますが、知識武装するだけでも全然違います。
その後
知識が付いてくると、当たり前だけど勉強会に参加しても理解出来るのでツラくない。そして、しょっちゅう「アハ体験」がある。これが更なる勉強へのモチベーションに繋がる。
そしてツイッターで、中の人や有識者の人を色々フォローする。そうすると新機能のリリース情報などが自然と流れてくるようになり、キャッチアップもそんなに苦痛ではなくなる。
実際に業務で使うのが一番なので、なるべく関わるように・・・と言ってもアプリエンジニアだと限界があるし、週末にわざわざ時間を使うなら自分の本業のほうの勉強を優先してしまうので、手を動かすまでのことはなかなか難しい。
となると、ここは外部からの強制力を発揮して、LT駆動で勉強したり、この時期だとアドベントカレンダーにチャレンジしてみるのも良かったです。最初は勇気がいるけど。
2年も経過すると、インフラエンジニアの方々ともそれなりに会話が出来るようなレベルになり、公開スライドを見てもチンプンカンプンな事もなくなり、今まで完全に自分の中でブラックボックスだったインフラレイヤーの話に恐怖することがなくなりました。これが一番大きい。
さいごに
インフラについては今でも正直あまり興味がなくて、それゆえに自己学習も十分とは言い難いのですが、どうしても興味を持てないことはムリヤリ情報を浴びる環境に身を置くしかないと思っています。AWSのユーザーグループに関わっているのも、本業に比べて興味が薄いので自分の意思に頼る学習だけでは絶対無理だと思っているからです。
あぁ世の中のスーパーマンは、一体どうやって勉強しているんでしょうか。
なんてことはない話
いつも仕事や英語などの意識高い系(？)の話とか、子育て系の真面目な話を多く書いてきたせいで、自分のブログなのに「高尚なネタが無いと書いちゃいけない」ような気持ちになっていました。
でも、ほぼ自宅でフリーランスの私に、そうそう高尚なネタなど降ってきません。むしろあるのは、日々の不安やドス黒い感情ばかり。黒い感情も1年くらい溜まり続けると、ついブログに吐き出してしまうくらいのエネルギーに変換されることもあるんですが（下記ブログ参照）、まぁ大抵は半減期1日くらいです。
というわけで、たまには息抜きに「なんてことはない話」を書きます。最初に言いますが、特に有益な情報は無いです。でも何かアウトプットしないとモヤモヤしてしまうので、ゴミみたいな内容ですが、それでも良ければお読みください。m( )m
クラウドの人
何度かイベントでお話をさせてもらったり、コミュニティ活動で色々関わってきたこともあり、初対面で会った方に自己紹介をすると、既に認知してもらっている事が何度かありました。
そういう時は大抵、8割の確率で「AWS方面の人」「クラウドの人」と認知されていて、残り2割は「デザイナ」という感じです。すごくありがたいんですが本業はそこじゃないので、自分の至らなさを思い知るわけです。（一応フロントエンドの人だと自分では思っています）
自分が発信している内容が主にそっち寄りだったり、デザインワークでコミュニティに参加している事が多いので自業自得なんですが、なぜ私は自分の本業での発信が少ないのかというと、まぁ自信がないからです。ぶっちゃけました。自信がありません。
本業で自信がないくせに興味は多方面にあり、AWSのユーザーグループで色々やってるのも、業務ではなかなかクラウドに直接関わりが持てないので、コミュニティを通して情報を収集するキッカケを作っているような感じです。その延長で情報発信するのは何も抵抗がないくせに、本業のほうではどうしても勇気が出ない。なんでだろうねこれ。
で、どうしたいの
「プロジェクトを複数掛け持ちするということ」のブログを書いた時から・・・いや正確にはもっと前から考えていたことが、時間の経過と共に少しずつ大きくなってきた感じですが、そろそろ私は次のステージに行きたいのです。次のステージというのが何かについては、具体的に言える時が来たら書きたいと思います。
ただ、人生は思い通りに行かないことのほうが多いし、挫折もたくさんしてきたので、仕事以外のことも色々迷いまくっていました。母親としても。
んで、今日たまたま見掛けたこちらの記事
「そこから学んだのは、成長と心の安らぎは同時には得られないということです」と彼女は言う。
「誰だってどんな国でも企業でも、それは同じです。自分が成長するのはどんな時か、考えてみれば分かるでしょう。それはリスクをとって新たな物事にチャレンジする時なのです」とロメッティは語った。
これを読んで、あぁこれだったのか！と。膝ポンおよび目から汗ですわ。
私は成長と心の安らぎの両方を得ようとしていて、でもその答えが見つからなくて迷っていたんだな、と。リスクを取らない事ばかり考えていたんだな、と。
その気付きがあった事が、今日一番の収穫でした。というわけで、お昼休みが終ったので仕事に戻ります。
技術ブログの翻訳をしてみて思ったこと
前回のヒアリングネタに引き続きですが、先日、英語の技術ブログを翻訳致しました。（仕事ではなく完全に趣味の範囲です）
10月1日に行われたServerlessConf Tokyoで、スピーカーとして来日していたAlexのブログ記事を見て、とても素晴らしい内容だったので、翻訳してみたいと思ったのがキッカケです。
語学の学習は継続が大切ですが、これまで何度も「やるぞ！」と思ってもなかなか継続せずで、どうしたら長続き出来るのか？が永遠のテーマです。
その一環として初めて翻訳をしてみたのですが、前回書いたヒアリングと同じで、自分が興味ある内容だと苦痛じゃないんですよね。むしろとても楽しかったです。
今回翻訳してみて
感じたことを書くと
- 興味ある技術内容を選べば、業務にも役立つ。
- 執筆者本人にも結構喜ばれる（場合によってはNGかもですが）
- 公開することが1つのゴール、およびモチベーションになる
- 公開後に反応があると次のモチベーションに繋がる
- 記事への反応を執筆者にフィードバックすれば、きっと喜ばれるはず（マサカリは悩むけど…）
このようにメリットが多いので、これ最高じゃない？と思ったのです。特に翻訳中は、言及されている技術分野についてある程度自分でも調べないと、英語表現では意味が分からない事が結構出てきました。なので、時間は多少掛かるんですが、その分とても勉強になりました。（そして5番のフィードバックはまだ出来てません…汗）
ただ、気を付けたほうがいいな、と思った幾つかの事についても書いておきたいと思います。
1. スラングが多そうなものは避ける
上級者でないうちは、スラングが多そうな記事は避けたほうがいいと思います。でも、初心者だとスラングが多いのかどうかも判断付かないですよね。なので、個人のブログよりは、法人サイト内に掲載されているブログを選ぶのが無難ではないかと思います。
2. 長文は慣れてから
これ今回の私の反省なんですが、見てもらえれば分かるように超長文です。日本語で読んでも長いなって感じるくらいですから、翻訳している最中は出口の見えないトンネルがずっと続いているような気分でした。途中で挫折しないためにも、最初はライトなものから始めるのが良さそうです。
3. まったく知識がない分野は上級者になってから
専門用語の表現がなかなか難しいです。言及されている技術に対して知識がゼロだと、これは専門用語だとすら気付けない場合もあります。最初のうちは、自分がよく理解している分野から手を付けるのが良いと思います。
4. 翻訳許可を取るタイミング
本人に許可を貰うのは、ほぼ翻訳が終ってからにしましょう。翻訳してもいい？なんて聞いておきながら、途中でやめちゃったり、何日も掛けてモヤモヤさせるのは失礼ですよね。
さいごに
今回、公開許可を貰うにあたって、ドキドキしながら本人にTwitterで話し掛けてみたところ、快諾してくれました。
hi @bump_of_kiharu! for sure, let me know when it's ready! I'm also working on a new article about @AzureFunctions and @openwhisk :)
— Alex Casalboni (@alex_casalboni) 2016年10月18日
その後、実際に翻訳記事をアップしたら彼も拡散してくれて、私が反応のあったツイート（日本語）をリツイートするとファボしてくれたりと、なんだかちょっとワクワクした数日間でした。
もし翻訳をしなかったら、このような縁は生まれなかったんだなと思うと、ちょっと大げさですが感動した私です。
【小ネタ】技術者向け：英語のヒアリング勉強法
この仕事をしていると、ドキュメントが英語というのは普通によくあることなので、読むのはさほど苦痛ではなくなってきましたが、ヒアリングやライティングについては全然自信がありません。（読むのも自信があるわけじゃないですが）
11月に海外遠征に行くにあたり、全編英語セッションなのでせめてヒアリングをどうにかしたいと思っているんですが、TOEICの試験対策みたいな勉強をしてても非常にツマラナイし続かないので、どうしようかなぁと思っていたところ、お金もかからず、楽しみながら、かつ技術的な知識にも触れられる方法があるじゃん！と気付きました。
例えばこういう動画です。PCで見るほうが良いです。
歯車アイコンのところをクリックしてみてください。「字幕」というメニューがあるのが分かるかと思います。これで「英語-cc」にすると英語での文字起こし字幕が表示されます（自動文字起こしではなく、おそらく人間による文字起こし文章）。また、「日本語」にすれば日本語字幕が出ます。
すべての動画がこうなっているわけではないですが、YouTubeのGoogle developerアカウントでアップされた動画の中には、日本語で字幕表示されるものが結構多くあります。（Android developerアカウントとか他にも幾つかGoogle関連アカウントがある）
何がいいって、ヒアリングの答え合わせが出来ることです。最初は音だけ聞いて、次に英語字幕を見て聞き取りの答え合わせ。ここで意味が分からなければ、最後に日本語訳まで見る、という流れ。
英語/日本語の字幕を切替える作業だけが面倒なんですが、この勉強法だと英語だけでなく技術情報も一緒にインプットできるので、なんだかお得感があるんですよね。
ちなみに、YouTubeには便利なショートカットがあって、一時停止/再生、5秒巻き戻し/スキップ、などがキーボードで出来ます。このショートカットを使うと、何度でも同じフレーズを聞けてとても良いです。（逆にこれを知らないと異常に面倒くさい）
他にも楽しみながら勉強法があったら、ぜひ教えてください！
