radioc@?

レディオキャットハテナ

【読書メモ】仕事は楽しいかね?

仕事は楽しいかね? (きこ書房)

仕事は楽しいかね? (きこ書房)

Amazon Primeの読み放題対象になっていたので読んでみた。初版は10年以上前なので改めてまとめるまでもなさそうではあるが、せっかくなので要点だけまとめておきます。

読んでみた感想としては最近色々なところで言われている高速にPDCAを回すことの重要性を物語風にわかりやすく説明しているという印象。後半に出てくる3つのリストを使うことは、PDCAを回すための1つの手法だと思うが、3つに分けてリスト化することが重要で、やみくもに色々試すのではなくPlanやCheckをしっかり行ってPDCAを回すことにつながると考えられる。継続的にもっと良い状態を目指す点はスクラムの考え方に近いものもあり、発想自体はふりかえりやスクラムマスターの活動にも応用できそうに感じた。

明日は今日と違う自分になる

多くの人は人生のある時点で目標を変えて成功している。5年後にどうなりたいか目標を設定しても思い通りにはならない。

今日の目標は明日のマンネリ

であり、目標を立てるとすれば

明日は今日と違う自分になる

である。

遊び感覚でいろいろやって、成り行きを見守る

毎日、違う自分になるためには”試すこと”を続けなければならない。多くの成功は試行錯誤を繰り返し偶然の発見によって生まれた。

注意さえ払い始めたら、目にできるありとあらゆるところに偶然が転がっている

試してみることに失敗はない

成功するというのはね、右に倣えをしないっていうことなんだ。

世の中は目標が達成されるまで待ってくれない。競争相手もどんどん変わっていくため、成功を研究しても成功は生まれない。たえず”試し”続けることが必要。

完璧とは、”ダメになる過程の第一段階”

”適切な時” とか ”完璧な機会” なんてものはない

他人を凌ぎたいならその場でただちに始める。

完璧だと決め込んだ時点でそれ以上良くならずライバルに追い抜かれるのをただ待つだけになる。

3つのリスト

明日は今日と違う自分になるために、次の3つのリストを作成する(説明の都合上、書籍とは順番を変えます)。 3つのリストは目につきやすいところに置いて、常に見直す。

1. 仕事に関してイライラすることや問題点

困難というのは、一つひとつが実地演習を始める合図だ。

つまり問題点に向き合うことで何かを試してみることの機会を得る。

試すことは簡単だが、変えるのは難しい

立派なビジョンや目標を設定するのではなく、目の前の問題に取り組んで何かを変えようと努力することで成功は得られる。

2. 仕事に関してやっているすべてのこと

新しいアイデアというのは、新しい場所に置かれた古いアイデア

古いアイデアを見直すことで活用できるアイデアはあちこちにあり、どんなものでも活用できる。そのため今やっていることを詳細にすべてリストアップしていけばその中から新しいアイデアを生み出すことができる。

3. 仕事上でやったミス

失敗の中を深く突き進むと、反対側に出るよ。”失敗にあらず” にね

失敗も問題点が大きくなったものにすぎないため、しっかり取り組めばその先に新しく試すことが見つかる。しかし、大きくなった問題点は責任や怒りなどの感情は横に置いてしっかり調べなければならないため、時間をおいてもう一度取り組んだほうが良い。

ほかの2つのリストに取り組んで、それからこのリストに戻る

そのため仕事上のミスは他の2つのリストとは分けてリストアップしておき、時間をおいてから最後に取り組む。

”試すこと”に喜びを見い出す

  • イデアをいっぱい持つこと
  • ありとあらゆることをやってみること
  • 明日は今日と違う自分になること

CPU脆弱性について調べた内容のまとめ

年明け早々から話題になっているCPU脆弱性ですが、メルトダウンとかスペクターというラスボス感ある名前だけが先行してどういう内容でどういう問題が起きるのか今ひとつ理解できていなかったため調べて整理してみました。

公式情報

まずはソースの確認。

1/3に公開された一次情報: Meltdown and Spectre

JVNの発表: JVNVU#93823979: CPU に対するサイドチャネル攻撃

そもそもどういう問題なのか?

blog.trendmicro.co.jp

トレンドマイクロのブログを参考にしてみた。

Meltdown と Spectre は両方とも、不正なコードが通常はアクセスできないメモリ領域にアクセスすることが可能になる脆弱性です。

脆弱性の仕組み

上記のブログによると以下の通り。

Meltdown と Spectre は CPU の投機的実行におけるセキュリティ欠陥に基づく脆弱性です。最近の CPU は処理が高速なため、(中略) CPU はメモリの読み書きを待つ間、先に実行可能な命令を実行します。このようにして投機的に実行された結果が正しいかどうかは事後的に検証され、もしその結果が不要な場合 CPU の内部状態とメモリへの影響は削除されます。(中略)メモリから 1 ワード長のデータをレジスタに移動する命令を投機的に実行し、その結果が不要となった場合、レジスタは元の値を保持していますが、キャッシュはリードサイクルで修正されます。Meltdown と Spectre を発見したリサーチャは、保護されているメモリ領域にアクセスするためにローレベルの CPU 状態を使用しました。

なるほど、わらかん。

色々ググってみると以下のブログでは図付きで説明されていて、これを読むと大まかなイメージはできた。

milestone-of-se.nesuke.com

超ざっくりまとめると

メモリ上の値A=1なら計算式Bを実行

というような処理が実行される場合、値Aは過去の処理履歴から予測すると多分1なのでメモリから値を取得するのを待っている間にCPUが先に計算式Bを実行する(間違っていたらロールバックする)というのがCPUの投機的実行の仕組み。この仕組みを悪用して誤った投機的予測をさせ、例えばカーネル権限だったらパスワードを取得するというような処理で先にパスワードを取得させて、予測が間違っていると判断される前に取得した情報をキャッシュメモリの別の領域にコピーすることで本来取得できない情報を取得できてしまうという事らしい。

Spectreには細かく分類すると2種類の手法がある。

  1. 投機的予測の判断を遅らせる手法を使って情報を取得
  2. Intelが採用している投機的実行の仕組みでは特定の条件で結果を予測できることが分かっており、その条件で不正な投機的実行を行う

Meltdown のほうは、Intelの投機的実行とアウト・オブ・オーダー実行の仕組みを組み合わせることで、特定の条件でカーネルメモリや物理メモリにアクセスできてしまうらしい。 アウト・オブ・オーダー実行は投機的実行と似ているが、

命令A
命令B
命令C

という処理で命令Aの処理の中でメモリ上の値を取得してくる必要がある場合は同じように待たされるため、命令Bを先に実行しておくという仕組み。いずれにしても本来必要ない処理を先に実行していまう点が問題の元となっているようだ。

どういう問題がおきるか?

JVNの発表によると以下の通り。

ユーザ権限で実行中のプロセスから、機密情報を取得される可能性があります。

Spectre 攻撃に関しては、細工された Javascript コードによって、Javascript からは取得できないはずの web ブラウザプロセス中のデータを取得可能であると報告されています。

外部からのアクセスなどで即座に問題が起きるわけではなく、不正なプログラムが実行されればその実行で本来アクセスできない領域の情報を読み取って取得されるということのようだ。物理的に同じ環境にある他のユーザーの情報にアクセスできてしまうため、トレンドマイクロのブログにも書かれてあるようにクラウドサービスでの影響が懸念されている。

さまざまな攻撃シナリオの中で最も可能性が高いのはクラウドサービスのような共有システムへの攻撃です。1 つの仮想マシンへのアクセス権を持つ攻撃者は Meltdown を利用することによって物理的に同一の PC で仮想マシンを利用する他のユーザの情報にアクセスすることが可能になります。

影響の範囲

まとめるとそれぞれの脆弱性の影響は以下のようになる。

  • Meltdown:IntelのCPUを使ったPC、サーバ
  • Spectre:ほぼ全てのCPUを使ったPC、サーバ、スマホ、その他の機器

主にIaaS,PaaS系のクラウドサービスもその環境が上記に該当していれば影響を受ける可能性がある。また、SaaS系のクラウドサービスについては利用する分にはあまり関係がない話だが、サービス提供側は環境が上記に該当する場合は状況に応じて対策は考えたほうが良いかもしれない。社内システムなどのクローズドな環境にあるサーバもそうだが、基本的には不正なプログラムが実行されない限り問題は起きないようではあるが、昨年世間を騒がせたWannaCryなどはその前提で放置されていた環境で被害が拡大したとも言えるので少なくともMeltdownはどのような環境であっても対策しておいたほうが安全と思える。

なお、GPUは影響を受けないとのこと。投機的実行の仕組みは使っていないということなのだろう。

www.itmedia.co.jp

対策の状況

Intelは1月中に全てのパッチを提供するとのこと。

japanese.engadget.com

前述の通り、不特定多数のユーザーが物理的に同一の環境で利用するクラウドサービスでは影響が大きいこともあり年明けから順次対策されている。

qiita.com

PC向けにもOS、ブラウザ、アンチウィルスソフトなどが順次対策パッチを提供している。

japan.zdnet.com

MacWindowsiPhoneAndroidなでそれぞれ対策が行われている。

news.mynavi.jp

対策の副作用

投機的実行に制限が生じるためCPUのパフォーマンスが低下するようで、悩ましい話ではあるが既にいくつか副作用が問題となっているようだ。開発者側はセキュリティ対策と合わせてパフォーマンスの確認も必要そうだ。

www.itmedia.co.jp

japan.zdnet.com

参考情報

d.hatena.ne.jp

【読書メモ】SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

年末に読み直したので読書メモとしてまとめます。実践編の中でも触れられていますが、スクラムのルールはシンプルではあるものの、その最低限のイベントやロールの責務を守り続けるための規律は自分たちで作って維持する必要があります。そのためにはまず基礎編を何度も読み返して目的をしっかり理解することが重要になります。実践編では自分たちのスタイルでスクラム開発を進めていくためのヒントになりそうなポイントが、スクラムを進めていくシーンごとに説明されています。「こういう場合はこうした方がいいだろう」という説明もたくさん散りばめられているため、スクラム開発に取り組む際に状況に合わせて読み返してヒントを得ながら進めていくのが良さそうです。

基礎編 Scrumってなに?

スクラムアジャイルの開発手法の1つで、最低限の定義されたルールに従い、重要なものから最短ルートでプロダクトを作ることで成果を最大化するためのフレームワークである。定義されている最低限のロール、会議体、成果物に沿ってスプリントを繰り返し実行することでプロダクトを作る。

スプリント

  • スクラムでは固定の期間に区切って繰り返し開発を行う
  • スプリントの期間内で開発チームはプロダクトの特定の要求についてリリース判断に必要な作業をすべて行う
  • 期間は必ず固定で作業が残っていても延期しない
  • プロダクトオーナーの判断でのみスプリントを途中で終了することができる
  • スプリントの期間は通常1週間〜4週間程度で、プロジェクトの特性や開発チームの体制などを考慮して決める

成果物

  • プロダクトバックログ
    • 実現したい要求を1番目から順番に一列に並べる
    • 常にメンテナンスして最新に保つ
    • 要求の一番上から順に開発する
    • それぞれの項目は開発するまでに見積もりをしておく
  • スプリントバックログ
    • プロダクトバックログの1つ1つを具体的なタスクに分割したもの
    • 開発チームが洗い出して管理する作業計画
    • 開発チームが自由に追加・削除可能
    • 個々のタスクは1日以下の単位にする
  • リリース判断可能なプロダクト
    • スプリント内で開発するプロダクト
    • スプリントの完了の定義を満たすもの
    • 完了の定義はプロジェクトであらかじめ決定し、途中で縮小しない

ロール

  • プロダクトオーナー
    • プロジェクトに必ず1人必要
    • プロダクトの結果責任を取る
    • プロダクトバックログを管理し並び順の最終決定権限をもつ
    • 開発チームを活用してプロダクトの価値を最大化する
    • 開発チームに相談できるが干渉はできない
  • 開発チーム
    • リリース判定可能なプロダクトを作る
    • 3〜9人で構成
    • 全員揃えばプロダクトを作れる
    • 上下関係はない
  • スクラムマスター
    • プロダクトオーナーや開発チームを支える
    • プロセスがうまくまわるようにする
    • 妨害を排除する
    • 支援と奉仕をする
    • 教育、ファシリテート、コーチ、推進役

会議体

  • スプリント計画ミーティング
    • スプリントで開発するための計画を立てる
    • プロダクトオーナーのほしいものと開発チームができそうなものをすり合わせる(第一部)
    • 開発チーム内でどうやって実現するかのタスクを決める(第二部)
  • デイリースクラム
    • 開発チームが毎日同じ場所、同じ時間に状況を確認する会議
    • 15分間のタイムボックスで行い延長しない
    • 開発チームの各メンバーは以下の3点についてチーム全体に報告する
      • 前回のデイリースクラムからやったこと
      • 次回のデイリースクラムまでにやること
      • 困っていること
  • スプリントレビュー
    • 開発チームの成果物をプロダクトオーナーが確認する
    • プロダクトオーナーは完了を判断する(完了していなければプロダクトバックログに戻す)

実践編 どうやればうまくいくの?

ロールを現場に当てはめる

  • ロールが求めていることに熱心に取り組める人を探す
    • 肩書や役職とは別もの

プロジェクトを理解する

  • プロジェクトの ゴールミッション を知る
    • プロダクトオーナーがプロダクトバックログをうまく作るため
    • 開発チームがどういう作業を優先させるべきかを考えて日々行動するため
  • インセプションデッキ :プロジェクトを始める前にプロジェクトのことを知るための活動

プロダクトバックログをつくる

  • プロジェクトの見通しを立てるために致命的な漏れを無くす
  • プロジェクトのゴールを達成するために必要なものやっておいたほうがいいものを全て書き出す
  • 出てきた項目を縦一列に並べる
    • 例)超重要、重要、普通、なくてもいいの分類から順番を決める
    • 上位の順番は詳細に考える(直近のプロジェクトで取り組む)
    • 全体は大雑把に順序をつける(絶えず見直す)

見積もりをする

  • 好きな方法で見積もる
  • 実際に作業をする人が最終的な見積もりをする
  • 相対見積もり:特定の作業を基準に決めて、その作業と比較してどれくらいの作業量かを見積もる
    • プロダクトバックログの項目の作業量を的確に把握するために適切な基準を選ぶ
    • フィボナッチ数(1,2,3,5,8,13...)で見積もる⇒大きな数字ほどブレが出るため重要な場合は細かく分割して見積もる
  • 詳細な見積もりは直近のものだけにする

見積もりをより確実にする

  • 見積もりポーカー:フィボナッチ数の書かれたカードを全員に配り、自分が考える見積もりポイントのカードを出す
    • プロダクトバックログの項目ごとに全員で一斉にカードを出す
    • 数字が違う場合は理由を話し合ってからまた一斉に数字を出し直す
  • 開発チームのメンバーで見積もるが、疑問点などはプロダクトオーナーが解消に協力する
  • 実際に作業する人同士の対話が重要

プロジェクトの計画を立てる

  • 見積もったプロダクトバックログの項目ごとのポイントの合計でプロジェクトの見通しを立てる
    • ベロシティ :1スプリントで開発できるポイント数
    • ベロシティがわかれば全て実現するまでの期間を予測できる
    • スクラムチームの実力に合わせて考える
  • リリースに関する作業はスクラムと分けても良い
    • スプリントが終わったあとでリリースのための作業をする期間を別途用意する

詳細な計画を立てる

  • スプリント計画ミーティングは二部構成で進める
    • 第一部:スプリントでどこまで終わらせそうかをプロダクトオーナーと開発チームで話し合って見当をつける
      • プロダクトオーナーから開発チームに実現してほしい内容を詳細に説明する
      • 各項目の完了条件を決める
      • 話し合い中に項目を入れ替えても良いが開発チームが準備できている項目以外は除外する
    • 第二部:開発チーム全員で必要な作業を洗い出して詳細に見積もり、本当に終わるかを判断する
      • 実装、テストなどのタスクを洗い出して時間で見積もる
      • タスクの単位は1日以下にする
      • 開発チームがスプリントの期間で実現できると判断したらプロダクトオーナーに連絡してスプリント計画ミーティングを終了する
  • スクラムチーム全員が確実に終わらせられると見極められる具体的で詳細な計画をつくる
    • スプリントごとの目標を決める
    • デモの手順などを決めて終わりの認識を揃える
    • 性能や品質などの受け入れ基準を設ける

素早くリスクに対処する

デイリースクラム

  • 1日分の予想の前提を揃えるために毎日同じ時間に同じ場所で開催する
    • 直近1日分の最新の予想を伝えて、翌日その結果を報告する
    • 予想のズレの原因を問題点として報告する
  • スクラムマスターは必要や要望があれば司会をする
  • スプリントの目標を達成できるかを検査する
  • 特定の誰かに向けての報告ではない
  • 問題解決の場でもない(開発の課題などは別の場で解決する)

何が終わったかを明確にする

スプリントレビュー

  • 実際に動作するプロダクトで確認する
    • 開発チームがそれぞれ実現したものをデモする
    • プロダクトオーナーは気になったことを質問し問題ないかどうかを判断する
    • スプリントを始める前に考えていたことが実現できたかどうかで判断する
    • 考えていたことが変わったり新しく気づいたことは判断に含めない⇒プロダクトバックログに追記
  • 問題なければその項目は終了
    • 問題があれば次のスプリント以降で実現するかどうかから考える
  • 完了の定義はスクラムチームで合意する
    • プロダクトオーナーがどこまで終わっていてほしいかを伝える
    • 開発チームはどんな基準を設けるか話し合って決める
    • プロダクトオーナーが本当にそれでいいかを判断する
  • 完了の定義は実際のリリースで求められる品質基準とは分けて考える

状況をうまく把握する

先を予測しやすくしておく

  • スプリントの期間を一定にしてどこまでできたかを計測することで全ての作業を終わらせるのにどれくらいのスプリントが必要かを予測する
  • 期間内に終わらかなったものは次のタイムボックス(スプリント)に回す

次にやることを明確にする

  • スプリントが予定より早く終わったらプロダクトバックログの次の項目に着手する
  • 手頃な項目が無い場合は項目を分割する
    • 最低限スプリントレビューでデモできる単位である必要がある(画面だけつるくなどはNG)
    • 開発チームが中心となって分割などの調整した項目を書き込む
    • 項目の順序はプロダクトオーナーが最終判断する

みんなの自立を促していく

  • スクラムで定義されている最低限のイベント以外は各ロールが自律的に責務に応えることで進める
  • スクラムイベントとロールの責務を守り続けるための規律は誰も与えてくれない

ベロシティを上げていく

  • ベロシティは安定が求められる
    • 安定していないベロシティは予測に使えない
  • 人を増やしてもベロシティはすぐに上がらない
    • 引き継ぎや教育を計画する
  • スクラムマスターが今より仕事を進めやすくすることを考える
  • よりうまく進める方法を考える機会としてスプリントレトロスペクティブを活用する

問題を見つけやすくする

  • 問題がどこにあるかをすぐに把握するためにロールがある
  • それぞれのロールにはやらなければならない事があり簡単に代理できない

意図を明確にしておく

  • ユーザーストーリー :実際に使う人達の視点で機能を簡潔に記述
    • <どういったユーザーや顧客>として<どんな機能や性能>がほしいそれは<「どんなことが達成したい>ためだ
    • ほしいものだけでなく意図を伝える
  • 実現したいことの理由をスクラムチーム全員で共有する

プロジェクトを支援していく

より良い状態にしていく

  • スクラムチームが抱えている問題は隠さず公開する
  • 妨害リストスクラムチームを理想に近づけていくためのToDoリスト
    • スクラムマスターが見つけて取り除いていく

先のことをいつも明確にする

  • プロダクトバックログはいつでも誰でも書けるようにしておく
  • 見積もりなおして最新の状態にしておく
  • 定期的なイベントにするなどして整理する

手戻りをなくしていく

  • プロダクトオーナーは直近で実現したい項目を明確にすることに注力する
  • 手戻りをなくすために次のスプリントが始まる前に着手できる状態にする
    • 次のスプリントの準備に10〜20%確保する

あふれそうなものを調整する

  • ゴールに向けて問題が起きた時の対処法は2つ
    • スクラムチームの仕事の進め方を良くする⇒すぐには効果が出ない
    • 以下のいずれかを調整してゴールに近づける⇒多少の痛みを伴うが確実
      • 品質⇒実際に提供する品質は一定であるべきなので調整が難しい
      • 予算⇒機器購入などは即効性があるが人員に使っても即効性は無い
      • 期間⇒何度も延ばせない、予算にも影響が出る可能性がある
      • スコープ⇒本当の目的を考えてプロダクトバックログを見直す、実現方法を変える
  • スコープの調整はスクラムチームとって頼みの綱であり腕の見せ所

さまざまな状況に対応する

  • スクラムの開発チームに求められること
    • 自己組織化 ⇒状況に応じて誰かがリーダーシップを発揮
    • 機能横断的 ⇒スプリント中に必要な様々なことをチームでできるようにする
  • スキルマップを作る
    • プロジェクトに必要なスキルや知識を列挙する
    • 開発メンバーの「得意」「経験有」「未経験」を書き込む
    • 誰か一人ではなく開発チームで色々なことができるようにする

より確実な判断をしていく

  • コミットメント⇒スクラムチームが現場の様々な状況から判断する
    • 必ず何かを達成させるためのもので、無理をして守るものではない
    • プロジェクトの大事な判断はスクラムチームでないとできない
  • 失敗から学ぶ⇒失敗しても構わないので自分たちで判断する
    • スプリントをくりかえしながら学ぶ

リリースに必要なことをする

    • リリーススプリント :リリースまでに必要な作業を行う期間
    • セキュリティやパフォーマンスの確認、社内手続きなど
    • リリースを満たす基準とスプリントの完了の定義との差分の作業
    • やり方は特に決まっていない。スクラムイベントも必須ではない。
  • リリーススプリントがあるからといってスプリントでできる事を後回しにしない
  • 残された時間は少ないので問題が見つかればすぐに対処する必要がある

Web系エンジニアのSwift学習ことはじめ 2018

年明けに書いたとおりSwiftの学習を始めてみた。いきなり何かのアプリを作ってみてもいいのですが、モバイルアプリ開発全般の中でのSwiftやiOSアプリ開発の現状を知ることを重視したいためまずはきちんとSwift言語を学習してみることにした。丸腰の初心者がiOSアプリ開発をやってみたという話ではなく、ある程度ほかの言語をかじったことのあるエンジニアがSwiftをさらっと学習するためにやってみた内容としてまとめておきます。

学習教材

詳解 Swift 第4版

詳解 Swift 第4版

詳解 Swift 第4版

いくつか探した中でSwfit4をサポートしていて言語についてしっかりまとまっていると感じて選択。今回はSwiftの基礎知識を得るためCHAPTER 1だけ読んだが本格的に学ぶならそれ以降も読んでおきたいと感じられる内容。というか取っ掛かりは良いとしても最終的には全部読むべき。その価値のある一冊だと感じた。

Hatena-Textbook プログラミング言語 Swift

github.com

はてなさんのエンジニア向け学習教材。実際にアプリ開発に入るうえで必要な、より実務寄りの必要最低限がまとまっている。これだけでも基礎知識としては充分まとまった内容だと思う。

The Swift Programming Language

developer.apple.com

言わずと知れた公式。今後、必要に応じてここに来るだろうということで、特にLanguage GuideやLanguage Referenceあたりにどういう項目があるかをさらっと見ておくのが良さそう。

学習環境

詳解 Swiftの途中でも紹介されているが、言語仕様を把握するだけとはいえ実際にコードを書いてみたほうが理解しやすいケースは多いので以下のツールが最初から使える状態にしておいたほうが学習が捗ると思われます。なお、Xcodeのインストール手順などの基本的な開発環境の構築手順はググればいくらでも出てくるので割愛。

Xcode playgrounds

インタプリタ方式のツール。XcodeのWelcome画面から呼び出せる。

f:id:radiocat:20180105233637p:plain

補完がきいたりリアルタイムでエラーが表示されて分かりやすい。1行程度のコードでその動作を学習するには手軽でちょうどよい。

f:id:radiocat:20180105233938p:plain

コマンドラインツール

REPL方式のツール。コマンドライン好きならこちらが良さそう。

f:id:radiocat:20180105235216p:plain

Serria以上のMacなら簡単に導入できる。

$ sudo xcode-select --install

詳細は以下。

developer.apple.com

なお、SwiftはOSSはなのでUbuntuでも同様のことが可能。

swift.org

参考にした情報

qiita.com

paiza.hatenablog.com

お正月だよWeb系エンジニア〜2018年の個人的ToDoリスト

あけましておめでとうございます。気づけば正月三ヶ日が過ぎようとしていますが、新しい年がスタートしたので早速今年やることリストをまとめてみます。大晦日に技術トピックスをふりかえって終わった のでその続きです。

改めてモバイルアプリ開発に向き合う

2017年のふりかえりにも書きましたが、モバイルアプリ関連は色々動きがあったので今年もしっかり動向を追いかけたい。

Ionicを使ってみる

Cordova関連の技術は以前からあるもので個人的にも既に使ってきた技術ではあるが、近年また注目されてきているように感じている。特にIonicはJSフレームワークと合わせて使う事ができてフロントエンド技術も抑えることができるしPWAにも対応している。関西でも昨年何度か勉強会が開催されていて学習機会も豊富にありそうだ。

これまではモバイルアプリを専門としていないエンジニアが手軽にモバイルアプリを開発できてマルチプラットフォームに対応できる点が重視されてきたが、個人的にはWebとモバイルアプリの垣根が下がってきている状況に注目しており、その動向を追いかけるための手段の1つと捉えている。

Kotlinを勉強する

Kotlinはいよいよv1.0が出ると話題になった頃にサンプル的にAndroidアプリのコードを書いたきりなので改めてコードを書いてみたい。AndroidはもちろんサーバサイドKotlinも事例が増えてきているので自分でコードを書いて抑えておきたい。

Swiftの勉強をする

これは今更ではあるが、これまでAndroid中心にモバイル界隈の技術に触れてきたためSwiftを使ってこなかった。しかしモバイルアプリ開発の技術動向を追いかけると言っておきながらiOS関連を無視するというのは片手落ちな感じがするので避けずに使ってみようと思う。

息をするようにクラウドプラットフォームを使う

AWSにしろAzureにしろ、もはやいくつサービスがあるのか誰もわからない状況になってきている。このままだと必要な時に必要なサービスを使おうと思っても、選択肢が多すぎてどれが適切なのかすらわからない状況にもなりかねない。

昔はよく先輩エンジニアにWeb系エンジニアもある程度インフラの知識が必要なので自宅サーバーなどを構築して普段からLinux環境に触れておくと良いというような事も言われてきたが、同じ論拠に立つなら今やそれは自前でサーバを持つだけでは不十分だろう。

幸いなことに大手のクラウドプラットフォームも一通りのサービスが出揃って競争が激化しており、試す機会は豊富にある。昨年刷新されたIBM Cloudでは期限無制限で無料で利用できるライトプランなども出てきている。

www.ibm.com

ただ、あまりにもたくさんのサービスがある状況で1つ1つを順番に使ってみてもキリがないので、作りたいモバイルアプリのために必要なサービスを選んで使うなど、アプリ主導でクラウドプラットフォームを使うのが良いと考えている。

Scrumを体系的に学習する

これまでもネットや勉強会で得たアジャイル的なプラクティスを様々な場面で使ってきたものの、自分の周りも含めてその手法や理論を理解できて実践できそうなものだけをつまみ食いしてきた感じだった。しかし昨年は ryuzee さんの スクラムトレーニングを学ぶ機会 があって基礎からしっかり取り組む基盤ができた。このタイミングでしっかり基礎を復習したうえで実践に活用したい。幸いなことに関西でもアジャイル系の勉強会はわりと頻繁に開催されていて、去年も色々な手法を学ぶ機会があった。

qiita.com

qiita.com

今年はまず書籍で体系的に復習しつつ上記のような勉強会で理解を深めるようにしたい。取り掛かりとして年末からScrum Boot Camp The Bookとエッセンシャルスクラムを読書中。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

その他注目していること

以下は次点として動向を見守りつつ、必要に応じて何か取り組みたい。

エンジニアとしてUI/UXを考える

昨年参加したDevLove関西のイベントでエンジニア系の勉強会の中でもUI/UX系の話題が注目を集めていた。デザイナーとエンジニアの連携をより強化していくことの重要性が高まってきているのだと感じている。

radiocat.hatenablog.com

Deep Learning系ライブラリ・サービスを使う

年末にふりかえった通り、専門外のエンジニアでも使えるライブラリやサービスが増えてきているので使う側としての知見を増やしたい。

Webの入り口としての音声応答を考える

Amazon Echoも春までには一通り行き渡ると思われるが、スマートスピーカーが普及し音声応答がWebサービスの入り口として定着したその先で我々エンジニアがどのように関わるのか考えておきたい。

ブロックチェーン技術に触れる

仮想通貨の話題ばかりが先行しているが、技術としても活用事例が増えてきておりWebとの連携も不可欠なので機会があれば使ってみたい。

2018年の技術動向参考情報

毎年恒例だが、ガートナーなどが今年の技術トレンドを発表している。これらを参考に2018年のToDoリストをピックアップしてみた。技術の移り変わりの激しいこの業界で1年間のToDoリストがどれだけ信憑性があるのかと言われると反論が難しいところではあるが、まあ新年の嗜みのひとつということで。今年もよろしくお願いします。

ガートナー | プレス・リリース |ガートナー、2018年の戦略的テクノロジ・トレンドのトップ10を発表

www.itr.co.jp

opensource.com