EeWriterのE-PADは大味なE Inkタブレット
8月はAWS認定の試験勉強に忙殺され(落ちた)9月は燃え尽きていました。
そんな中、Kickstarterで出資していたE InkディスプレイのandroidタブレットE-PADが届きました。
ちょっと使ってみただけで言いたいことが結構出てきたのでレビューしていきたいと思います。
TL;DR
- サイズ感がちょうどよく、書き心地も結構いい
- 本体も追加注文した純正ケースも全体的に作りが荒い
- BOOX買ってみたくなった
開封
外装。ガジェット系によくある高級な感じではなく厚手のボール紙のようなパッケージ。高級なパッケージは所有欲を満たしてくれるんですけど、どうせ捨てないといけないしバラすのが大変なのでこれくらいで十分です。
中身は画像の通り。ペンは別オプション。本体の他にはSIMカードのイジェクトピン、USB-USB Type-Cのケーブル、説明書に保証書。画像以外には別オプションの蓋付きタブレットケースがあります。
充電器はついてきません。あっても使わないので構いません。
見た目
正面画像。スリープ状態だと手書き風画像が表示されます。Kindleみたいな感じですね。ただKindleと違って画像は1種類だけです。
裏面。銀色の面は触れるとひんやりしているのでおそらく金属製です。縁の白い部分は樹脂製です。
保護シートが最初から貼られているのですが、貼りがかなり雑です。ゴミが入ってますし縁の方は空気が入って浮き上がっています。しかしこの保護シートが紙っぽいザラッとした質感を出しているので剥がすに剥がせず悩ましい。
本体右側面の上部にSIMカードスロット。技適の関係でネットに接続しない（できない）ので使いません。
上部には電源ボタン。一般的なスマホの電源ボタンの押し心地。
底面。USB Type-Cのポートと隣にマイク穴。両端はスピーカー。タップ音でしか音は聞いていませんが聞いた限りではおそらくモノラルかと思われます。
スペック表を見た時にE Inkリーダーにスピーカーなんているか？と思ったんですが、画面切り替え時にワンテンポ遅れて反応する都合上、音でタップしたかどうか分かるのは助かります。
触ってみた
ホーム画面はインストールしてあるアプリがすべて表示されるiOS方式。androidらしからぬUIが物珍しいです。
画像はプリインストールの状態から変わっていますが、Kindleは最初から入っています。Yahooニュースアプリなんかも入っていましたが消せます。
アンインストールやアプリの位置の移動はできません。アンインストールは右下のSettingsのAppsから消します。
ヘッダ部分は左から起動中のアプリ一覧、謎の刷毛ボタン、画面の濃さ調整、スクリーンの縦横変換、バックライトのON/OFF切り替え、音量調整、Wi-Fi、バッテリー残量、となっています。
E Inkといえば電子書籍リーダーとしての役割が大本命です。
Readerで内部ストレージ内の書籍一覧が表示され、読むことができます。が、プリインのリーダーは本当に最低限の機能しかありません。通常のandroidと同じく、開くアプリを選択できるので、Perfect Viewerなんかで読むのがいいです。
Readerからファイルを開こうとするとファイルが見つけられないことがあったので、その場合はPerfect Viewerから直接ファイルを開くとうまくいきました。
液晶の質はむちゃくちゃいいという感じでもないですが悪くもないです。ただ表面のガラスと描画面の間に隙間があり、画面が奥まって見えるのが気になります。
電子書籍リーダーと双璧をなすのが手書きメモツールとしての役割。画面下のNoteからメモの一覧画面に遷移し、新しいメモを開いたり、今あるメモを編集できたりします。
メモは白紙の他に罫線、方眼紙、ドット、英語の4線ノート等から選べます。
肝心の書き心地ですが、他のペンタブやE Inkタブレットに書いたことはないのでわかりませんが、なかなかいいと感じています。
ペンの追従はほぼリアルタイムですし、保護シートのザラッとした質感も相まって書いている手応えを感じられます。他の面に手が乗ってても誤検知しません。
問題点
とまあ基本的なところは見てきたんですが、いくつか気になる、というか個人的には結構な問題点が散見されたので書き連ねていきます。
戻るボタンで戻れない箇所がある
タブレット下部についている丸いものは戻るボタンなのですが、このボタンを押しても戻れない画面があります。通常のandroidであればホーム画面に戻るなりでなんとかなるんですが、このタブレットの戻るボタンはホームではなく、あくまで1つ前に戻るなので困りものです。
こういうときはヘッダの起動中のアプリ一覧→何もない箇所をタップ→ホーム画面、という方法で乗り切るしかなく、若干不便です。
純正タブレットケースのロック解除が役に立たない
別オプションで買ったケースですが、こいつが純正と呼ぶには微妙なクオリティです。
蓋がついており、閉めるとスリープ状態になり、開けると解除されるというつもりで作ってあるのでしょうが、想定通りに動きません。なぜならこの蓋、一般的に閉めた時に固定する方法がなく、常に若干隙間が空いてしまうからです。そのせいでスリープのON/OFFがおかしくなり、開いた時にスリープし、閉めた時に解除されるという意味不明な挙動をしばしば引き起こします。結局電源ボタンを押して解除するという本末転倒さ。
ノートを送る手段がない
先程いい感じ評したメモですが、こいつにも割と致命的な欠点があり、手軽にシェアできる機能がありません。一応送る機能自体はサポートしているみたいですが、技適の関係上ネット・無線系は使えません。
USBでPCと接続すると内部ストレージが見られるのですが、メモがありそうな場所にメモがありません。他のところも探しましたが、結局見つけられず。書いたものをPCに送ったりして手書き文書とデジタル文書を一括管理しようと考えていたので、これは残念な仕様です。
セキュリティロックがない
これが一番の問題で、タブレット自体のロック機能がありません。
外に持ち出す時に誰でも見られるような状態なのはセキュリティ的な観点でもそうですが、精神衛生上もあまりよろしくありません。物理媒体では本やメモなんかにロックを掛けるようなことはそうないからいいという考えなのかもしれませんが、個人情報が含まれるようなタブレットに関してはPINでもパターンでもいいのでロック機能が欲しかった……。
まとめ
ここ最近E Inkディスプレイのandroidタブレットがいくつか出てきていますが、その中でも安く手に入りそうなので出資したE-PADですが、いいところもありますが、正直期待値までは達しなかった出来でした。
いくつかソフトウェア的な改善によって劇的によくなりそうな部分もあったので期待したいですが、ハード的な部分・周辺に作りの甘さはいかんともしがたいです。
そこへいくとこの界隈で最有力なBOOXシリーズは一体どれくらいの出来なのだろうと気になってきました。それなりに満足いく品質なのかもしれませんが、同じようなサイズ感のものは倍以上の値段がするので、高いなーと悩ましくもあります。
そう考えると値段とのトレードオフと考えれば十分な出来とも言えるのかもしれない、そんなタブレットでした。
完全SIer脱出マニュアル(書籍版)を読んだ
TL;DR
- インプット・アウトプットしようという意欲をひたすら高めてくれる本
感想
完全SIer脱出マニュアルを買って読みました。
同人版は読了済みなので後輩への布教用とお布施と思って買いました。
同人版3章に対して書籍版では4、5章が追加されており、転職したその先のキャリアパスが紹介されています。
結構過激なタイトルに反して、転職というイベントを通じてエンジニアの適切なインプット・アウトプットの仕方とは何かをレクチャーしてくれる本という印象です。
この本には難しい話も深い話もありません。読み終えたら自分もなにかやらなきゃと思わせる、エンジニアに向けた自己啓発本とも言えます。
- 作者: 池上純平
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2019/06/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
第1章 なぜ「エンジニア」はSIerを去るのか
一般的な「IT企業のエンジニア」のイメージと、SIerの実際の業務内容との間に大きなギャップがあるから去るんだよね、という話。
SIerのエンジニアの一日が紹介されていますが、前職がSIerでSEやっていたので「どこもやってること同じだなあ」と遠い目をしながら読みました。
世の中ではこんなに新しいものを取り入れて仕事してるのに、うちはなんでまだSubversionとOracleとStruts(しかも1系)なんて使ってんだぁ……と思ってたことを思い出しました。あと、なんでWeb上でブログやってる人やQiitaで投稿してる人ってあんなにキラキラ楽しそうに仕事してるんだろう、とか。
第2章 自分や環境を変えるための前提知識
6つのワードの画一的なイメージを覆していく章。
- 「仕事」
- 「成長」
- 「IT企業」
- 「ベンチャー企業」
- 「エンジニア」
- 「転職」
個人的に興味深かったのはベンチャー企業で、給料が安く、やりがいを食べて生きる人しかいないという項でした。(このタイトル自体がパワーワード感ある)
ベンチャー企業は、収益が安定していないから給料が安いのではないかというのが一般的なイメージが支配的です。
ですが、実際は人が少ないので一人あたりの会社への影響力が大きくなるので、いい人でないと会社が傾く可能性があることから採用や雇用に支払うコストが高くする傾向があるという説明は納得感がありました。
第3章 完全SIer脱出マニュアル
本編。
全体を通してSIerから転職するまでをステップに分けて解説しています。
どうやってエンジニアとして必要な情報をインプットしていくのか、自分のスキルや意欲を可視化できるようにアウトプットしていくかということや、転職の面談・面接への臨み方について説明してくれています。
まずPCを買うところから書いているのが実用的でいいです。デスクトップではなくラップトップを買うべきというのもよき。
GitHubやQiitaや個人ブログのアカウントを作る、というのは大いに参考にしました。というかこのブログを始めたのはここのアドバイスのおかげです。
この先続けられるかはともかく、こういう風にアクションを起こせたというだけでこの本の価値は非常にでかいです。社内に留まらないアウトプットをしていくきっかけを掴めたという点で意義の大きい章だと思います。
第4章 転職したその先のキャリア
転職後に関わるべき事業、職種、就業形態の選択肢を挙げて解説する章。
個人手に発見は少なかったですが、グロースハッカーという職種については初めて聞いたので知れたのは良かったです。
第5章 一生楽しく働くために
キャリアの選択肢の広げ方について説明している章。
個人的に最近の関心であるスキルセットのユニークさを高めるについて短いながらも触れられていましたが、その他多くは第3章で触れられていたことの延長という感じです。
まとめ
たとえ今いる会社がSIerでなくとも新人エンジニアにぜひ一読させたいですね。
転職してほしいとは思いませんが、未経験者がこういう本で意欲を高めて勤勉になると自分も焦って勉強しなきゃと思えるので。
ちょっと前までは正直家に帰ると何もしたくないと思っていたのに、そんな気持ちに火を点けたという意味で価値のある本です。
AWS認定ソリューションアーキテクト - アソシエイト合格しました
TL;DR
- 参考書は黒本が強い
- AWSそのものは少し触れば大丈夫
- 模試の復習が大事
ソリューションアーキテクト - アソシエイト合格しました
先月に1つ下の難易度の資格であるクラウドプラクティクショナーに合格して、そのままの勢いで次の資格も行こうということで受験。
結果としては無事合格しました。
結果は909/1000。受けている間はそこまで手応えがなかったけど、意外と点が取れてた。
クラウドプラクティクショナーは900/1000だったので点が増えてる。なぜだ。
合格するにあたって、クラウドプラクティクショナーからどういう・どういった観点で勉強したのか、受験時の雑感を掘り下げていきます。
動機
会社でAWSをはじめとしたクラウドベンダー系の取得が奨励されていて、受験料負担 + 合格時のインセンティブがあったため。
あと、Webエンジニアとしてプログラミングはできるけどインフラやネットワークの知識がさっぱりだったので、クラウドの最大手であるAWSのサービスを通じてその辺の知識を身に着けていきたかったため。
AWSはサービスが無数にある上にサービス1つをとっても設定できることが非常に多く、網羅的な知識をまず押さえていく必要があったので、資格取得を勉強のモチベーションにしようと考えた。
勉強開始前の筆者のスペック
- AWSは業務で開発環境用にEC2インスタンスをネットの人の記事読んで何個か建てたくらい
- あとはRDSを1回最低スペックで構築した程度
- Azure・GCPの知識はほぼ皆無
- そもそもサーバも満足に建てたことがなく、インフラの知識もかなり怪しい
～クラウドプラクティクショナー受験
- 期間
- 3週間ほど
- 毎日の勉強時間
- 平日1時間、土日のどちらかで2時間程度
- 使った教材
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
2019年6月時点の大定番参考書。クラウドプラクティクショナーは95%これ読んでただけで受かりました。
まずはAWSの全体像を掴むためにも1章を読み切ることが大事です。(1章でサービスを一通り説明してくれます)
2章以降は1章で出てきた各種サービスの詳細を補間してくれます。
章末の問題はクラウドプラクティクショナーの試験問題よりは若干簡単ですが、知識の定着には使えます。
試験までに2周読みました。
クラウドプラクティクショナーのサンプル問題(英語)
https://d1.awsstatic.com/training-and-certification/Docs%20-%20Cloud%20Practitioner/AWS%20Certified%20Cloud%20Practioner_Sample%20Questions_v1.1_FINAL.PDF
試験の雰囲気を掴むためにやりました。10問しかないので雰囲気だけ。
やらなくてもよかったと思います。
クラウドプラクティクショナーの試験の感覚
正直どんな問題が出てきたのもよく覚えてません。
体感としては、前半に答えづらい問題がやや多かった気がします。問題文が長く、少し考えないといけない問題ですね。
順番に解いていくと中盤に差し掛かる前に挫けそうになりましたが、中盤以降は～ができるサービスは何かみたいなシンプルな問題が多く、俄然勢いづきました。
時間は見直しを含めても1時間もかからずに終わりました。
試験問題にはあとから見直したい問題にフラグを立てておけるので、ある程度自信がない問題にはとりあえず立てておくと試験の最後に簡易的に自己採点ができます。
～ソリューションアーキテクト - アソシエイト受験
- 期間
- 1ヶ月ほど
- 毎日の勉強時間
- 平日45分、土日は基本的に勉強なし
- 使った教材
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
2019年6月時点の大定番参考書。ソリューションアーキテクトは(以下略
クラウドプラクティクショナーで2周してたので、試験日3日前に苦手なセキュリティと1章を見直したくらいです。
Amazon Web Services エンタープライズ基盤設計の基本
- 作者: 堀内康弘,三浦美緒
- 出版社/メーカー: 日経BP
- 発売日: 2018/10/04
- メディア: 単行本
- この商品を含むブログを見る
AWSを使ったエンタープライズのインフラ設計を学んでいける本。
最初はオンプレだったシステムを、章ごとに新しいアーキテクチャを学び、新しいアーキテクチャを使ってクラウドに構築していく構成が特徴。
前述の徹底攻略がAWS全体を広く網羅しているのに対し、こちらはより具体的なソリューションに焦点を当てて解説しています。AWS KMSについて詳しく書かれていて、その辺りはかなり勉強になりました。
試験までに1週読み切りました。
AWS Solution Architect Associate Practice
いわゆる模擬試験。通常なら受験に数千円かかるのですが、クラウドプラクティクショナー合格の際に模擬試験が無料になるバウチャーを貰えたので、無料で受けられました。
本番が65問に対し全部で20問なので物足りなさはありますが、本番試験と同程度の難易度なので雰囲気を掴むのに非常に役立ちました。
受験後に具体的な問題の正否がわからないので、問題を覚えといた上でどれが間違っていそうか見当を付ける必要があります。
本番10日前に受けましたが、なんとなく自分の苦手な傾向がわかったので残りの期間はその克服に時間を充てました。
無料で受けられる人は是非受けるべきですね。お金かかる人は、試験に自信がないなら受けておく価値はあります。
ソリューションアーキテクト - アソシエイトの試験の感覚
クラウドプラクティクショナーと比較すると、とにかく問題文が長い。平均して2～3倍はあったような気がします。
オーソドックスなインフラ構成と実現したい要件が与えられて、それに対してベストプラクティスを選ばせる問題が大半だったような気がします。
WebページとバックエンドアプリケーションとRDBというオーソドックスな構成で負荷分散やアクセス制御の方法は鉄板。
あとはEFSはAmazon的には推しのアーキテクチャみたいですね。
1問1問がやや重いですが、時間もたっぷりあります。本試験は130分でしたが、急がずやって100分足らずで終わったので焦らずに着実にやっていって問題ないはずです。
ポイントとしては、主要なサービスに関してできることと得意なことを把握しておくことが肝心です。1サービス単位で把握しておけば、あとはその組み合わせで実現できる選択肢を選ぶだけです。同じようなことができる・一見似ているもの同士は異なる部分を具体的に挙げられるようにしておくと最後の2択を制することができるはずです。
複数選択問題は選択肢の組み合わせで1つのソリューションを提示すべきなのか、選択肢間で別々のソリューションを提示すべきだったのか試験が終わった今でもわからない……
おわりに
知らない人も多いかもしれませんが、AWS認定試験を合格すると認定者だけが入れるストアに行く権利が得られます。
個人的にはシャツやマウスパッド辺りが欲しいですね。
資格のランクによって買えるものが違うので、プロフェッショナルになるとどんなラインナップになるか楽しみです。
プロフェッショナルの資格を手にするために今後も頑張っていきます。
Reactチュートリアルは入門React本で斬り伏せられた男に手を差し伸べてくれた
TL;DR
- 業務でjQueryばかり使っていた男がReactチュートリアルをやってみた
- 以前入門Reactという本を読んだことがあったが途中で挫折
- チュートリアルは最後までできたし、Reactの基礎的なエッセンスが何となく理解できた
- 初学者はまずはチュートリアルをやってみるととっつきやすいかも(入門Reactはその後で読もう)
Reactを使ってみたい
jQueryでフロントエンドを書くことに限界を感じていたんですよね(限界まで使い倒せていないと思うけど)
DOMの操作の処理が恐ろしく汚くなってメンテナンス性が非常に悪く感じたので、今風のjavascriptライブラリならそのへんの課題が解決されるのでは？ と思ったのがきっかけです。
いくつか選択肢はありますが、学習コストや情報の充実度的にReactがよさそうかなと。
それで手始めにオライリーの侍本(入門 React ―コンポーネントベースのWebフロントエンド開発)を買って読み始めたんですが、全然入門じゃない内容に斬り伏せられました。
入門 React ―コンポーネントベースのWebフロントエンド開発
- 作者: Frankie Bagnardi,Jonathan Beebe,Richard Feldman,Tom Hallett,Simon HØjberg,Karl Mikkelsen,宮崎空
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/04/03
- メディア: 大型本
- この商品を含むブログ (2件) を見る
何も知らない状態で読んで3章くらいからついていけなくなり、モチベーションがダウン。
そして時は流れ、再度モチベーションが上がってきたところで、チュートリアルから入っていったらどうだろう？ と思い至ってチャレンジしてみました。
環境
自分のPCに開発環境を入れることに抵抗があったので、AWSのサービスの1つ、Cloud9を利用してやってみました。
Cloud9はクラウド上に開発環境を構築し、Webブラウザ上でコーディング・実行できるサービスです。
AWSはクレジットカードがあれば無料でアカウントが取れるし、設定で一定時間放置何もしないと自動で休止状態になるので経済的です。
AWSの初期設定については下記の記事を参考にしました。
セキュリティ周りや請求周りの大事だけど若干面倒くさい部分をしっかり押さえてくれているので非常に助かりました。
gitにAWSの大切な情報をpushしてしまわないようにするベストプラクティスとしてgit-secretsというgitのアドオンがAWS公式で提供されているというのが一番大きな収穫でしたね。
その後、Cloud9の開発環境を構築していきました。
設定にあたり、下記の記事を参考にしました。
今はOSがAmazon LinuxだけでなくUbuntuも選べるので汎用的なUbuntuを選択しました。
チュートリアルをやる
HTML + JavaScriptで三目並べを作りながらReactの基礎を学べる感じです。
ブラウザでコードを書くかローカル開発環境を構築するかというオプションがありますが、今回はCloud9で環境構築したので、ローカル開発環境を構築しつつブラウザでコードを書くというハイブリッドな状態となりました。
このページを上から下までただただ順に読みつつやっていきます。
概要
Reactコンポーネントについての説明。
コンポーネントクラス内のrenderが描画用関数だよ、JSXというHTMLライクなタグ構文で書くとjavascriptに変換されるよという説明。この辺は入門Reactの最初でも触れていたので問題なくついていけた。
スターターコードの中身を確認する
まずはスターターコードを写経。
コードからどういうアウトプットになるかはふんわり想像しつつ書いていく。
親コンポーネントから子コンポーネントの名前でJSXを呼び、子が孫コンポーネントを呼んで……と繰り返して最終的なアウトプットとして画面に絵が描画される。
データを Props 経由で渡すでは、子コンポーネントにはパラメータも渡す話をしている。
受け取ったパラメータが子自身のpropsの中にあり、子はそれを使うことができるので、親は子に値を渡すことで影響を与えることができる。
インタラクティブなコンポーネントを作るでは、コンポーネント自身の状態をstateで持たせている。
propsが親->子へ渡すものであるのに対し、stateはコンポーネント自身の状態であるという違い。
ゲームを完成させる
個別のマスに状態を持つよりはボード自体で一括管理するほうがコードがシンプルなので、親コンポーネントにstateを移動するようにリファクタリングをやろうというのがState のリフトアップの説明。
onClickの扱いは、buttonタグの場合は意味のある名前の属性で、ユーザ定義のコンポーネントではonClickは意味はないので、違う名前でもいい。
ミュータブルとイミュータブルの話が出てくるが、これはこの後の履歴を遡る機能の実装に必要。もとの値を書き換えると変更前後でどこが変更されたのかを検出するのが困難。
関数コンポーネントでは、stateを持たないrenderだけのコンポーネントはfunctionで書くと解説。
手番の処理で、交互に手を打っていくための仕組みをボード自体のstateを直前と反転させることで実現している。シンプルで無駄のない方法だなと感心しました。
ゲーム勝者の判定で勝ちパターンをすべて洗い出して、そこに合致しているかどうかを判定するというロジック。三目並べというパターンの少ないゲームだとできるけど、力技な方法なので、碁盤上でやる五目並べなんかでは違う方法でやらないと大変なことになりそう。そもそも勝ち負けの判定の最適化が焦点じゃないので簡略しているのだと思われる。
タイムトラベル機能の追加
打った手の履歴の状態は、ボード全体の状態のためGameコンポーネント自体に持たせてあげる。そのためにリファクタリングして、Boardで持ってたstateを親のGameに移行するのをState のリフトアップ、再びで実施。
過去の着手の表示、ここが若干わからなかった。Gameのrender関数内のmove変数(引数？)がインクリメントされるのはなぜ？ と思ったけど、JavaScriptのmap関数でhistoryのインデックス番号が表示されているのね。
過去の手番に戻って再度打ち直した時に、誤ってしまった未来の手をすべて削除するロジックなんかもなるほどなーと感心しながら写経しました。
GitHubにpush
Cloud9で作ったチュートリアルコードを自身のGitHubにpushしました。
やり方は下記の記事を参考にしました。
アプリケーション作成時にcreate-react-appコマンドを使うと、Gitもインストールされて手間が省けていいですね。
振り返り
チュートリアルで親子コンポーネントの関係や、stateをどこに持たせるべきかなど、Reactで開発するにあたっての基礎的な部分は掴めたかなと感じてます。
コーディングに関してはまず触ってみることが大事なんだなと実感しました。
入門Reactで同じようにつまづいた人はチュートリアルやったほうがモチベーション上がるしおすすめです。
これでやっとReactの入り口に立ったかどうかというところなんで、チュートリアルの最後にあった改良のアイデアを実装したり、簡単なWebアプリを作るかして精進していきます。 あと、今なら入門React再挑戦してもいいかなーと思ってるので時間を見つけて読み進めます。
はじめてのイベント参加でJBUG 札幌#4に行ってきた
TL;DR
- 勉強会とかそういうのに行ったことなかった男がこちらに参加してきたレポ↓
- Backlogというツール自体は優れている
- 運用ルールの作成と、徹底がなされないことが問題
- Backlog APIは可能性の塊
- 怖くないし、意外と初参加の人も多い
- 自社外の人と話すのはいいぞ
参加の経緯
いきなり個人的な話ですけど、今まで勉強会とか参加したことなかったんですよね。
前々から自社以外の人と会うことで刺激を受けたいなと思ってたりしたんですが、人見知りだから知らない人怖い、初めての勉強会怖い……と思って時は流れ……
業務でBacklog見てたら札幌でイベントをやるらしい → スピーカーの人知ってるー！
知ってる人がいればなんとかなるのでは……？ と思って思い切って参加してみました。
会場
フュージョン株式会社さんのオフィスで行われました。
入って最初に思ったのはおしゃれなオフィスだなーってことですね。
木目調の部屋で、カフェに来たかと思いました。
写真はこういう時に撮っていいかもわからなかったのでありません。
個人的に意外だなと思った点としては、
受付みたいなところで名前を聞かれたりするのかなと思ったのに特にそういうのがなかったところです。
みんな来たらどんどん部屋に入っていく。
性善説だ……と思ったけど、顔見知りが多いから割となんとかなるんでしょうかね。
あと他にも知り合いがいました。
意外と世間って狭いんだなあ。
セッション
小林さん
プロジェクトの成功率の話から始まり、
失敗の原因あるあるを挙げていき、結局はいろんなことを曖昧にしているからイカンよね、という話。
- ゴールが共有されていない
- 客の言われるままのスケジュール
- アジャイルが、仕様をいつでも変更できるという誤解がある
- 決定が先延ばしになりがち
最近読んでるエンジニアリング組織論への招待の中でも、不確実性を減らしていくのがエンジニアリングという話があって、まさしく上記のようなことが不確実性そのものなんだろうなあと思いました。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
あとここ2年近くほどで強く実感したのは、
- wikiがカオス(情報が古い、似て非なる情報が点在している)
- レビューの文化がない
の辺りで、割と今の会社の課題かなと感じているところです。
個人でコード見てくれる人はいるけど、ルールがないのが問題。
個人的に一番刺さったのは、
- 進捗率90%から進まない
ですね。
作業中に発覚した要素によって残り10%を埋められないやつ。
本質的ではないかもしれませんが、こういう時って進捗率を下げる方が管理サイドとしては工数が見えて嬉しいんでしょうね。でも作業者は90%にした手前、また戻すという選択は取りにくいよなあ……。
曖昧なことへの対策としては、明確にするということを挙げていました。
- すべてチケット化する
- しない人には教育する
- とりあえず、一旦、で決めることは禁止
- すぐに決められない場合は、いつ決めるかを決める
- Backlogには開始日、期限日を必ず入れる
- 進捗率付きガントチャートを作成
割とBacklogの課題の日付やカテゴリとか入れなくても使えるんですが、しっかり埋めていく(=明確にする)ことで曖昧さによる失敗を解消できるんじゃない？という話でした。
進捗率ガントチャートの実装方法が個人的にはハック感あって好きでした。
川筋さん
Backlogアンチパターンの紹介と、それに対してやっていること/やりたいことの紹介。
SQLアンチパターンをはじめとしたアンチパターン大好きマンなので興味深く聞きました。
- 作者: Bill Karwin,和田卓人,和田省二,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
- 購入: 9人 クリック: 698回
- この商品を含むブログ (46件) を見る
- お知らせ機能
- お知らされない
- 担当者未設定
- どこにもお知らせされていない
- お知らせテロ
- 関係あるなし問わずあらゆる人にお知らせする
- お知らされない
お知らせしてないのも多数にしすぎているのも問題で、前者はもちろん気づいてもらえない。
後者はいわゆるお知らせ疲れみたいな感じで、見なくなるし本当に重要なものは埋もれてしまうという指摘でした。
それに対してやっていることは、お知らせ機能はメールのCCのような感覚で使うとあって、さじ加減の説明としては結構腑に落ちた感覚がありました。
メールのCCって感覚、今の新卒とかそれより下の人に伝わるのかなあ……。
あと、お知らせテロのスライドが、100人くらいお知らせしていた画面のスクショで度肝抜かれました。お相手氏ギャグのつもりかな？
- 課題の作り方
内容の本当の優先度が伝わらないし、Excelだと後から情報が追いづらいよね、という話。
これらに対しては、5W1Hを明確にする(タイトルならWhat, Howを書く)、脱Excel課題管理とありました。
前者は割と個人的には気をつけていて、タイトルだけ読めばだいたい何すべきかわかる状態が一覧化できる方が後から助かるんですよね。
Excel課題管理に関しては、自社で事前に運用のグランドルールを決めて、それをお客さんにも守ってもらうように働きかけるのがよいよね、って話も出てきました。
Backlogにも簡易的なものですが優先度設定できる機能があるので、せめてそれを使ってもらいたいですね。
- 課題の運用
- 課題の途中下車
- コメント上は
クローズ、完了って言ってるのに、実際のステータスは処理済み
- コメント上は
- 棚卸さない
- 課題を起票したけど、誰も着手せず何年も塩漬け
- 起票者がプロジェクトアウトしてもう誰もわからないなんてことも
- 課題の途中下車
途中下車は、課題一覧でステータスの検索をした時にノイズとなる課題が出てくるし、逆に引っかからないケースも出てきて困るという話。
棚卸さないは、いつ誰がやるのかがわからない、けどただただ溜まっていくという問題。
これらに対しては、課題のステータスの運用ルールを決めること、定期的な課題の棚卸し、似た課題はマージ、期間を決めて過ぎたら機械的にクローズしていく、というようなことをやっていきたいとありました。
ここまでを総括すると、ツールそのものの不足というより、使う人間が自分ルールでやることが大半の問題を引き起こしているという感じですね。
小出さん
Backlog APIとGoogleスプレッドシートを駆使して業務に必要なツールをゴリゴリ作った話。
お知らせ機能のユーザに入れてもらえなくて本当は見たい課題を見れなくて困ったから自作したという経緯。
Backlog APIで差分比較機能を実装したのは素直にすごい。
会社のツールになるので公開できないというのが残念。
こういうところでExcelではなくGoogleスプレッドシートを選ぶところにエンジニアっぽさを感じます。
LT
新井さん
結局今のスタートアップでは課題管理ツールをGitlabにしたのでBacklogは使ってないよ、でもコスト以外の面ではBacklogはいいよ、という話でした。
社内でGitlabを使っているので、プロジェクトをまたいだ情報をどこで管理していくか、という話題が出たときに、どうしたらいいんだろうなあ、と同じように考えました。
今回はGitlabだけど、Backlogにした時でも同じような課題が起こるんじゃないだろうか。
プロジェクトをまたいだものは別のツールを使う？
他の会社ってその辺どう解決しているのだろうか気になる。
懇親会
人見知りなので行くかどうか迷いましたが、結果としては行ってよかったです。
他の会社の方の業務についてとか抱えている課題について話を聞くのってめちゃくちゃ面白い。
意外とJBUG初参加の人も多かったりして、みんな顔見知りでアウェー感があるのでは……？ という心配は吹き飛びました。
あと、飲み会の中で次回の勉強会の予定も決まったので良かったです。
こういう場の出会いを繋げられたというのは単純に嬉しい。
まとめ
勉強会とかイベントとか行ったことなくても、行ってみたらなんとかなったし得られたものは多かったです。
行ってよかった。
Backlogはあくまでも1つのツールなので、どれだけ便利なものになるかは運用ルールや使い方1つだなと再確認できました。
エンジニア以外のユーザにもとっつきやすいツールですが、それゆえに運用方法なんかがファジーになってしまいがちになるので、そこはロジカルに詰めて運用していく必要があるなと思いました。
