2019年の振り返り
記事が消えた
確か6000字くらい書いた気がするんだけどなぁ…
一回同じタイトルで振り返り記事を書いたのですが、投稿中に無線LANの接続がおかしくなり記事が消えました。
（公開ボタンを押下した後、Safariが「ページを読み込めません」画面を表示、再読みこみのためCmd+Rを押したところ記事が全部消えた状態で編集画面が表示された）
来年の目標は家の無線LANアンテナを買い換えて安定した回線を手に入れることです。
来年までの時間が許す限り思い出して書いていきたいと思います。
後輩
Qiitaにも書きましたが、インドから来た新卒のエンジニアさんが後輩になりました。すごい。
また、高校生のインターン生も来ました。すごい。
この二人に、今後エンジニアとして活躍できるようにスキルやマインドを伝えていくことが今年の目標です。
発表とか
DoridKaigi初登壇でした。
今年もDroidKaigi登壇します！
来てね！！！
エンジニアリング
Flutterしてる一年でした。
昨年からリプレイスしていたアプリを公開でき、たくさんの方から注目していただく事例になったので感無量です。
世の中的にはiOS/Androidのどちらが覇権を握るか、という競争が（結局どちらも覇権を握らなかった、という形で）ひと段落し、モバイルのエンジニアは両プラットフォーム向けにアプリを作らねばならない、というある意味では非効率的な状況になっています。
そうした中でクロスプラットフォーム（X-Plat）なフレームワークの一つとしてFlutterが注目されている、というのが現状なのだと思います。
X-Platの文脈では、Flutterのライバルとしては未だReactNativeが健在ですし、KotlinConfの内容を見ているとJetBrainsはKotlin MPPに力を入れていくようです。
（個人的な見立てでは、ReactNativeはまだ1.0がまだリリースされない、Kotlin MPPは主なターゲットがAndroidエンジニアなのでしょうが、そちらの取り込みはFlutterの方が早かったので今からKotlin MPPへの切り替えが起こるかどうか微妙、という気がしているので、まだFlutter優勢の時期が続くのではないかと思っています）
個人ではPythonとかC# (8.0)をいじったりしてました。
pandasとnumpy何もわからないんですが…あれむずくない？
旅行
id:side_tanaさんに縁のある人たちで台湾旅行に行かせていただきました。
私以外の人たちが水曜どうでしょうノリで面白かったりして（私だけ水曜どうでしょう未履修だった）、めっちゃ楽しかったです。
他にはシンガポール行ったりタイに行ったりしました。
プライベート
未だに通勤に片道1.5時間かかっている生活が続いているので、早く通勤時間を短くしたいところです。
昨年に「実家を出られない事情は時限式」と書いた気がするのですが、前提が崩れてしまい事情が無期限になってしまった、というように状況が悪化しているので、心労がやばいです。
なんとかしたい。
来年の抱負
まずは後輩たちにもっと成長できる環境を用意することが一番です。
今のところは、「どんなコードが良いコードか」を判断できるようになって欲しいかなと思っています。
「良いコードとは、ドメイン知識に合わせた適切な抽象度でクラスやメソッドが分割されていて、各種原則に則していて…」という説明は当然してはいますが、一つ一つの具体例に対してしか説明できていないので、
もっとたくさんコードを読むとか、自分で書いたコードを長期間メンテナンスしてみるとか、してもらうしかないのかも、と思い始めているところです。
あとは英語力。
多少なりと話せるようになったので、あとは語彙力をつけていきたいと思います。
それから、会社勤め以外の収益源を作るところとか、漠然ともうちょっと大きなことをしてみたいとか、本をたくさん読みたいとか…
いっぱいありますね…
おわりに
2019年はお世話になりました！
2020年もよろしくお願いします！！！！！
日本語話者が英語を話すことの難しさ
私も多分にもれず、中高の6年間も英語教育を受けていたにも関わらず全然英語を話せない種類の人間なのですが。
最近仕事で英語で会話する機会が増えて、その度になかなか話したいことの英語表現がスッと出てこないので、自分なりに原因を考えてみました。
日本語が母語の場合の頭の中
私の場合、日本語で何か伝えたいことが出てきた場合に、以下のプロセスを通して口から言葉が出てきている気がしています。
1 の段階では「何となく」しか話したいことが浮かんでいません。
言葉にしてみないと整理できていなかったりする支離滅裂なこともあったりします。
抽象概念的な何か。
2 の段階でようやく言語化していて、この段階で、抽象概念的な何かが言葉になります。
さて、英語で話す場合は、抽象概念的な何かを言語化するプロセスでいろいろなことが起こります。
- 話したいことがもやっと頭に浮かぶ（非言語）
- 言語化する必要のある部分だけ言語化する。日本語で思考するパスと英語で思考するパスがある
- 日本語の語彙に当てはめる（英語より正確性が高い）
- それから英語に直訳する（遅い）
- 英語の語彙に当てはめる（語彙が足りないので正確性が低い）
- 翻訳の必要がないのですぐに発話のプロセスへ
- 日本語の語彙に当てはめる（英語より正確性が高い）
- 二つのパスを統合
- 英語で発話する
あくまで私の場合ですが、英語で直に発話できる場合と、英語に該当する語彙がない・日本語の方で先に概念に該当する語彙を見つけてしまったなどの原因で和英翻訳をかける必要がある場合の二つがあります。
あれです、CPUのエミュレーションをせずネイティブで動いている場合と、CPUエミュレーションしているみたいな違いです。
とすると、スッと英語で話せるようにするには、エミュレーションなしで話せるようになればいい訳です。
英語に該当する語彙が見つからないケース
当然ただ単に語彙が不足していることもあるのですが、普段の日本語での思考の癖が足を引っ張っているケースが少なからずあることに気づきました。
例えば上司が部下に「それ、なんとかしておいて」と言うみたいな、超抽象的なことを伝えたい時。
日本語でもぼんやりしすぎなので明らかにいいコミュニケーションの仕方とは言えない伝え方ですが、まあ例なので・・・
英語でこれと同じことを伝えようと思ったら、私はけっこう骨が折れます。
"Please process it in something good way." とかでしょうか？
こう訳すだけでも、「なんとかする」の翻訳はちょっと考え込んでしまいました。
なぜなら、以下のような、言葉の解像度を上げると言うか、具体化するというか、そういったプロセスが必要だったためです。
- （元の言葉）なんとかする
- （一度抽象的な何かに落として）「こなす」「処理する」「良いように」「方法は問わない」的なもやっとした何か
- （具体度上げる）"Process" "best way" "something good way"
- （「bestってほどじゃないんだよなー」など、具体度上げながら抽象的なものとの整合性をとる） "process it" "something good way"
- （ちゃんと文章の形に仕上げる） "Please process it in something good way."
この間3〜４秒程度でしたが、会話だとちょっと「間が開いた」と思われるには十分な時間がかかっているわけです。
抽象的な概念から直に英語の表現が出てくれば問題ないのですが、問題は日本語で「なんとかする」という語彙を先に閃いてしまった場合。
「なんとかする」に直接的に対応する英語の語彙を私は知らなかったので、どうしても日本語の便利な語彙「する」に頼りがちです。
そして一度「する」という語彙に落ちてしまうと、英訳が非常に難しくなります。なぜなら "do" と同じような概念の言葉ではないから。
もちろん「する」だけではないですが、日本語って曖昧で、普段の会話の範囲だけで考えを言語化しようとすると、英語に落とし込むためには具体度が低すぎる考え方になってしまいがちで、すぐに考えが英語にならないのが一因にあるのでは、と思いました。
日本語話者が英語を話せるようになるには
- 日本語でも抽象度が高いまま話さず、具体的に話す（動詞だけでなく、副詞、形容詞も）
- 英語の語彙をたくさん身につける
というようなことが必要なのではないでしょうか。
多分、普段から文章をたくさん書いている人とかは、文語体で考える癖がついていて、文の構成要素が具体的になりやすくて英語で話しやすい、とかあったりするのかしら。
設計原則に関する英語の語彙を増やしたい
日本語訳される前は何と呼ばれていたのか調べておきたかった。
| 日本語 | 元 |
|---|---|
| 単一責任（責務）原則 | Single Responsibility Principle |
| 関心の分離 | Separation of Concerns |
| 開放・閉鎖（オープン・クローズドの）原則 | Open-Closed Principle |
| 拡張に対して開いていなければならない | should be open for extension |
| 変更に対して閉じていなければならない | should be closed for modification |
| リスコフの置換原則 | Liskov substitution principle |
| 依存性逆転の原則 | Dependency inversion principle |
| インターフェイス分離の原則 | Interface segregation principle |
他にも増やしたい語彙が見つかったらまた書く。
教養と認識
人間というのは不思議なもので、知っている物事は簡単に認識できても、知らないものはなかなか認識できなかったりします。
知らないもの、というか、意識の外にあるもの、というか。そういうものは簡単には認識できない傾向にあるようです。
例えば私は同僚が髪を切ったとか、そういうことに無頓着だったのでにあまり気づかない人でした(今でも気づかなかったりすることがあります)。
人生において色々な物事が自分の脇を通り過ぎていくように思えますが、そのうち認識できているのはどの程度なんだろうか、それを認識できるようになるにはどうしたら良いのだろうか、とふと思ったりするわけです。
そういったものを認識するにはそのものを知る必要、もしくは強烈に認知する必要があります。
例えば髪を切ったことに気づくには、「人が髪を切ったことは話題になるし、気付いてもらえると嬉しい」ということをわかっているか、誰かに「あの人、髪を切ったね」と教えてもらうか、とかがそれぞれに該当するかも。
かたや、リベラルアーツとか教養の必要性がよくわかられていない、というような話がTwitterでよく見受けられる気もします。
私も大学時代は教養の必要性はわかっておらず、授業のテーマで「なぜ大学や大学院が必要なのか」を考えることになった時に「同等の教育ができるなら専門学校があれば良いのでは」という結論を出したこともありました。
今であれば、知らないと気づけないから、予め広い分野において知識を仕入れておくこと、広い世界があるのだと知っておくこと、色々なことに気付けるようになること、それが教養なのだと思います。
なので、話の通じない弟には様々な分野の本を読んで欲しい…(奴はラノベしか読まない)
いくら自分に対して思索を深めたところで、自分以外の考え方や世界があることを認めなければ、いつまでも井の中の蛙なのだということをわかって欲しい…
まあ私もまだまだ教養が足りない部類の人間だから、そう言っても行動で示しても伝わらないのかもしれないけれど…
自戒を込めて。
エンジニアの育成とマネジメントが難しい(と私は思い込んでしまっている)
年一更新のブログになってしまいそう。
それでは良くないので、思ったことを未整理のままでも書き出してみたりしようかと。
職場に新しいエンジニアの方々お二人がいらっしゃって、それぞれのメンターを務めることとなりました。
どちらもお若くて、ほとんど新社会人みたいな感じ。お一方はインドの大学の新卒、もうお一方は高校生インターン。どちらもプログラミングは結構できる方。
私は人を育てるということを上手くできた試しもないので、勝手に育ってもらうしかない。
とりあえずどうなりたいのかを聞きつつ、なるべくその要望を叶えられるようにタスクを振ろうと思っているところ。
しかし、タスクを振るって言っても、私はタスクマネジメントも苦手なので、そこも上手くできるか自信がない。まずどれだけのことをお任せしても大丈夫なのかわからない。どんな仕事の進め方をしたら楽しんでもらえるのかもわからない。
私がガッツリ設計とかモジュールの分け方とか決めて、その後で小さくしたタスク(このクラスをこう作ってとか)をお任せした方が良い？
でもそれだと自由度小さすぎない？ 私がそんな振り方されたらマイクロマネジメントだと思う。しかしお二方とも基本的な型というか、「この種のプロジェクトでは、このコードはこう書く」みたいなところまで理解が及んでいるのかわからないし…いやいや、そんなの書いてみてもらってコードレビューするまでわからない。
2〜3年前のペーペーの頃はどう指摘したものかわからなかったけれど、最近の私なら設計原則に関する語彙があるので、理由を説明した上で必要であれば軌道修正ができるかも。
そうなると比較的最初から設計の方針を話し合いの上で決めた方が良いのだろうか。
多分そうで、ちゃんと納得の行く進め方をしたいし、そうした方がきっと良い。
と、まとまらないまま書き始めてみたら悩みが一つまとまって解決してしまった。
今後も続けていこう。
