がみぶろ

#がみぶろ

@jumpei_ikegami

眼球の中にコンタクトレンズを埋め込むICL手術をして1ヶ月たった

こんにちは、gamiです。 2018年12月13日にICL手術を受けて1ヶ月以上がたちました。 周りの人の話を聞いても、レーシック経験者はそこそこいますが、ICL経験者はあまりいなさそうだったので、その結果や感想を書きます。

ICL手術とは?

視力回復のための手術の一種です。

視力を戻すための手術としてはレーシックが一番有名ですが、 私は後述する理由によりICLという珍しい手術を受けました。

ICL(Implantable Contact Lens)手術はその名の通り、眼球の表面を切って、 その隙間から眼の中にコンタクトレンズを挿入する手術です。 痛そうですね。

特に問題なければ何十年もコンタクトレンズを入れっぱなしにするので、「眼内永久コンタクトレンズ」とも呼ばれるそうです。

なお、眼内レンズ手術には入れる場所やレンズの種類によって「前房型」と「後房型」の2種類があります。

  • 前房型レンズ
  • 後房型レンズ

私は、より一般的で傷口が小さくて済む「後房型」の手術をしました。

なぜICL手術を受けたか?

私は視力が絶望的に悪く、小1から眼鏡をかけています。 手術前の視力は両目とも0.1未満で、コンタクトレンズの度数は右目が-9.00、左目が-6.00でした。 おまけに乱視付きです。

最初はICLの存在すら知らなかったので、普通にレーシックを受けるつもりでした。 いつレーシックしようかなーと思っていたところに、「自分の結婚式」という大きなイベントが舞い込んできたので、 なんとなく「結婚式は裸眼で出たいなあ」と思ってレーシックの検査を申し込みました。

病院は、知り合いがレーシックを受けた品川近視クリニックに行きました。 その人の紹介だと、5万円くらい安くなるとのことでした。

レーシックの検査を受けてみると、「視力が悪すぎてレーシックでは十分な視力回復は難しい」という旨のことを言われました。 その代替案として示されたのが、ICLでした。

レーシックは角膜をレーザーで削って屈折異常を矯正する手術方法です。 そのため、角膜のサイズで視力の矯正幅の上限が決まってしまいます。

一方、ICLは逆にレンズを足す手術なので、より強度の近視であっても矯正することができます。

ICL手術の結果

詳細な体験談は後に回すとして、結論を先に述べます。

良かったこと

当たり前ですが、視力が1.0付近まで回復しました。 20年以上、眼鏡かコンタクトレンズ無しでは生活できない状態だったので、朝起きて眼鏡をかけなくても目が見える体験は素晴らしいです。

もちろん、この点はICLでもレーシックでも変わらないと思います。

悪かったこと

手術前に説明を受けていましたが、照明などの強めの光を見るとその周りに光輪が見えるようになりました。 手術直後は結構気になりましたが、今は慣れたのでそこまで気になりません。

大変だったこと

一時的に大変だったことは、以下です。

  • 手術料金が高かった
    • 50万円くらいしました
  • 術後1週間は、目に水が入らないようにシャワー禁止だった
    • ドライシャンプーを買ってしのぎました
  • 手術で血管を切ったらしく、術後3週間くらい、右目の左半分が内出血で真っ赤だった
    • 会う人全員に説明しなければいけなくて大変でした

概要は以上です。 細かい体験談が気になる人は、以下も合わせてお読みください。

詳細な体験談

記憶の限り、ICL体験談を詳述します。

レーシックの検査まで

前述のように、最初はレーシック手術を受けるつもりでした。 品川近視クリニックには「1日レーシック」というプランがあります。 事前予約制で、たった1日で検査、カウンセリング、施術まですべて終えることができます。 私のような効率厨には最適なプランです。さっそく問い合わせをしました。

予約に際しては、事前に電話でヒアリングを受けます。 主なヒアリング内容は以下でした。

  • どの院で受けるか?
  • 生年月日
  • 電話番号
  • ローンをするかどうか

その後、1日レーシックの予約を取ります。

レーシックの検査

レーシックの検査に先立って、注意事項を伝えられました。

  • 料金はmin 15万円だが、検査結果に応じて変動する
  • 全体の5%の人は、検査の結果、施術が不可になることがある
    • 私もレーシック手術としては不可だったので、この5%に入っていたことになる?

検査当日は、一生分かと思うくらいたくさんの目の検査をしました。 視力、眼圧、眼球の各部分のサイズなどを詳細に調べます。 また、ベッドで横になった状態で、穴の空いたカップを眼球の上において液体で満たしたまま眼の中をグリグリチェックされたりしました。

最後に医者の診断がありました。 この日の検査で、予想外のことが2つありました。

  • レーシックができず、ICL手術になる
  • 小さな網膜剥離が見つかったので、視力回復の前にそちらの手術をする必要がある

網膜剥離とは、眼球の内側の網膜が剥がれてくる病気です。 近視が強い人は、眼球が前後に引っ張られるので、中央部分が破れて穴が空いてしまうことが多いようです。

網膜剥離の手術

幸い、少し穴が空いているくらいの軽度な網膜剥離だったので、その日のうちにレーザーで治療ができることになりました。 瞳孔を広げる目薬と麻酔の目薬を差して、普通の診察室っぽいところで手術しました。

ICLがメインのトピックなので詳細は割愛しますが、網膜剥離している部分の周りをビス留めするように、数十〜百数十発くらいのレーザーをガンガン打っていきます。 麻酔をしているとはいえ、連続でレーザーを打たれると鈍痛が酷くて涙が出てきます。

肝心のICL手術は、網膜剥離の術後1ヶ月検診で問題がなければ改めて実施することになりました。

ICL手術前

ICLの手術に先だった準備としては、以下が必要でした。

ICL手術当日

網膜剥離の手術から約1ヶ月後に、ICLの手術をしました。

検査

当日は、網膜剥離の術後検査、およびICL手術前の軽い検査をしました。 特に問題なかったので、ICLの手術をすることになりました。

支払い

手術前に、料金の支払いをしました。 50万円を超えていたので、手持ちのデビッドカードの上限金額を超えていて焦りました。 なんとかWebから上限を引き上げられたので良かったです。

ICL手術を受ける場合は、事前にクレジットカード等の上限金額を確認しましょう。

手術の準備

これまでの検査や網膜剥離の手術とは違って、入念に手術の準備をしました。

  • ロッカーに洋服以外のすべての荷物を預ける
  • 青い手術用キャップをかぶる
  • 手術エリアの部屋の片隅に置かれた一人用ソファで待たされる
    • その間、5分間に1回の頻度で、なんども繰り返し目薬を差される
      • 瞳孔を広げるやつと、麻酔用、消毒用など
      • ちゃんと瞳孔が広がっているかチェックされ、不十分だと目薬を再度差してさらに5分間待つ
    • トータルで30分以上はかかった気がする

十分に瞳孔が開いて麻酔が効いてきたら、手術室に通されます。

手術中

手術は、思ったよりもガチの手術室で、複数の医者や看護師の手で行われました。 また、全身麻酔ではないので、普通に意識もはっきりし、眼もそこそこ見える状態で手術をします。

  • 眼の周りを消毒する
    • ボトルに入った目薬を、湯水のように流して綺麗にする
  • 眼の周りだけが出るような布を顔の上に置き、テープで貼る
  • まぶたをテープで広げる
  • さらに、まぶたを強制的に開かせる器具を取り付ける
  • 光る顕微鏡みたいなものを目の前に設置され、その先を見続けるように言われる
  • 眼球の表面を切るタイミングは、痛みが無いのでよくわからない
    • たまに鈍い痛みはあるが、そんなに痛くない
  • 手術中は、常に眼球に水を吹きかけられ、定期的に目薬も差される
  • レンズを挿入した瞬間、突然眼が見えるようになる
    • 瞳孔が広がっているので完全には見えないが、明らかにわかる
  • 何らかの後処理をして、片目終了
    • 眼球なので、特に縫ったりはしない
  • 片目10分程度、全体で30分程度

手術直後

手術後も、手術前に座っていた一人用ソファに座らされます。 ソイジョイとお茶を渡され、お腹が空いていたら食べるように言われました。

しばらく休んでから、改めて軽く術後の診察をします。 私はこの時点で右目が内出血を起こして真っ赤になっていましたが、たまにあることのようで、問題ないと判断されました。

その後、以下を渡されます。

  • 目薬3種類
  • 内服薬
  • 保護用メガネ
  • 眼帯

保護用メガネをつけたまま、帰宅します。 まだ瞳孔が広がっているので手元は見えにくいですが、帰るには特に問題ないくらいの視力はありました。

ICL手術1週間後まで

手術の翌日には、術後1日後検診がありました。 術後2日後くらいまでは、内服薬をちょこちょこ飲まされました。

その他、術後1週間後までは以下の制限がありました。

  • 2〜3種類の目薬を各1日5回ほど差し続ける
  • 首から上のシャワー禁止
    • 目に水の中の雑菌が入ることを防ぐため、ドライシャンプーや濡れタオルでしのぎました
  • スポーツ禁止
  • 飲酒禁止
  • 常に保護用メガネを装着
  • 就寝時は、プラスチック製の眼帯を装着
    • 寝返りを打ったときに眼球を圧迫しないように

視力自体は、翌日には問題なく見えるようになりました。

右目は内出血が痛々しい感じでしたが、目薬を差したときに少し染みる程度で、痛みはあまりありませんでした。 角膜を削るレーシックの場合は結構痛む人もいるそうですが、ICLは眼球を3mm程度切るだけなので、痛みが少ないのかもしれません。

術後1週間が経過したときも、改めて検診に行きました。

ICL手術1ヶ月後まで

1週間が経過すると、保護用眼鏡も不要になり、軽いスポーツや飲酒もOKになります。 目薬だけは、1日5回差し続ける必要がありました。

全体のスケジュール

私の場合のスケジュールは以下でした。

日付 内容
2018/10/18 1日レーシックの予約
2018/11/08 レーシックの検査&網膜剥離の手術
2018/11/15 網膜剥離術後1週間検診
2018/12/13 ICL手術
2018/12/14 ICL術後1日後検診
2018/12/20 ICL術後1週間後検診
2019/01/15 ICL術後1ヶ月後検診
2019/03/13 ICL術後3ヶ月後検診

一般的な、レーシックとICLとの違い

手術の説明を受ける中で、レーシックとICLの違いに詳しくなったので書きます。

レーシック

  • 料金は比較的安い
    • 10〜30万円程度
  • 角膜を削るので、不可逆
  • 術後の入浴や飲酒に関する制限が緩い
    • 基本的には、翌日から可能
  • 乱視の矯正も可能

ICL

  • 料金が高い
    • 50万円程度
  • レンズを後から抜くこともできるので、可逆
    • レンズが合わない場合に後から交換することも可能
  • 術後の入浴や飲酒に関する制限が厳しい
    • 術後1週間はシャワー禁止など
  • 乱視の矯正ができない
    • 後房型レンズは回転する可能性があるので、乱視矯正ができない
    • 乱視を矯正したい場合は、術後3〜6ヶ月後以降に、乱視だけレーシックで矯正することも可能

共通点

  • 光の見え方に違和感を感じる現象(ハローグレアなど)は、どちらにせよ発生リスクがある模様
  • 他にも、感染症や医療ミスなどのリスクははゼロではない

まとめ

基本的には、レーシックで直せるレベルの視力の人は、手術例も多いレーシックをするのがいいと思います。 ただしレーシックが難しい場合でも、お金さえ用意できれば、ICLの手術も選択肢に入れるのは十分にありだと感じました。

「眼球を切ってレンズを入れる」という手術内容だけを聞くと恐ろしいように感じますが、私の場合は痛みもあまり無く、また可逆であるという意味ではレーシックよりもリスクが低い側面もあります。

なんにせよ、ノー眼鏡&コンタクトライフは超快適です!

AWSは色々な業界のスタートアップでどう使われているのか?X-Tech JAWS 第6回 イベントログ

こんにちは、しがないラジオのgamiです。

今回は弊社プレイドの同僚が登壇すると聞いて、X-Tech JAWSというイベントに行ってきました。

xtechjaws.doorkeeper.jp

AWS初心者で、JAWS-UGのイベントもX-Tech JAWSも初参加というアウェー戦ですが、せっかく参加したのでイベントのログを公開します。

JAWS-UGとは?

AWSの日本ユーザーグループです。

jaws-ug.jp

X-Tech JAWSとは?

FinTech、MediTech、AdTech、EdTech、LegalTechなど、X-Tech業界を集めてAWSに関する情報共有を行うコミュニティのようです。

xtechjaws.doorkeeper.jp

AWSという共通のテーマを通じて、異業種間の交流を促進することを目的に運営されているとのこと。 何かしらの共通の話題があると、全然違う事業をやっている人たちでもコミュニティが形成されるというのはすごく面白いと思います。

登壇メモ

X-Tech JAWSの説明を除くと、合計5つのセッションがありました。

Session0:『X-Tech JAWSの紹介』

X-Tech JAWS運営メンバー 吉江 瞬

X-Tech JAWS立ち上げの経緯

  • 「FinTech系勉強会はあるけど、他の業界はどうなの?」
  • 業界を固定しない、AWSを使ったサービスの話を聴ける場所があれば面白いんじゃないか?

X-Techとは?

  • 「洗練されたITをコアとして、その業界では新参者である企業が、今までにない価値や仕組みを提供する動向」
  • 「クロステック(xTech)」ではなく「エクステック(X-Tech)」

最近のX-Tech業界

  • 各業界のカオスマップを紹介

X-Tech JAWSとは?

  • 3ヶ月に1回
  • Amazon Chimeを使って配信
  • 登壇依頼先の選定
    • AWSを使っている
      • 企業のサイトをCMANに入れてdigって調べている
    • 技術と無縁そうだからこそ輝く業界
  • TechとBizの両方を聴くことができる
  • ASCIIさんに専用ページがある

https://ascii.jp/jaws-ug/

Session1:『スマートニュースにおけるニュースパイプラインの進化』

スマートニュース株式会社 真幡康徳

自己紹介

  • ニュース配信チームのソフトウェアエンジニア
  • ややインフラ寄り
  • 一児の父
  • Courseraのコースをひとつ終了した

SmartNewsについて

  • 全世界で3,500万人がダウンロードするニュースサービス
  • US版もある
  • スマートビューでサクサクニュースが見られる

創業期

  • 創業者の浜本さんが漫画喫茶にこもって書いていた
  • API/On-memory DB/Indexer/Crawler/Analyzer
    • これ以上なくモノリシック

近代

  • 携帯アプリ/検索エンジン/インターネット
    • 右側は、オフライン(記事が反映されるまで時間がかかってもいい)
    • 左側は、オンライン処理

オフライン処理

  • ニュース記事のクロール
    • ポピュラリティ分析
      • バズっているかどうか?
    • 国籍/言語判定
      • 記事がどこの国や言語で読まれているか?
  • ニュース記事の解析
    • 機械学習で記事のカテゴリ判定
      • 政治?スポーツ?
    • 固有表現抽出
      • 人名、地名etc...

オンライン処理

  • アプリと直接やりとり
  • 処理速度がめっちゃ大事
  • 1日四回の明確なピークタイム(朝/昼/夕/夜のプッシュ通知)
    • 大体はScale Out可能にする
    • 大体はキャッシュ可能にする

オンライン/オフライン共通

  • EC2は全てASG管理
    • 部分的にECSも導入
  • メトリクス
    • Datadog
    • 一部、PagerDuty連携
  • New Relicでパフォーマンス監視
    • メソッド単位で見たい場合など
    • それ用の小規模ASG
      • まず、そこだけデプロイして、パフォーマンス計測をする
        • ライセンス料が高いので、あんまり入れたくないのが理由
      • 問題なければ、大規模なASGにデプロイ

現代

  • ビデオ機能が追加されたことが理由
    • 現時点では、iOSのみ
  • なるべく既存システムを活かす

Amazon SageMaker

  • 機械学習プラットフォーム
    • 動画専用のカテゴリ分類機能を構築するために利用
  • US Engineeringチームが管理
  • エンドポイントのオートスケール
  • モデル更新がシームレス

Elasticserch Service

  • Cloud Searchの限界
    • 今後AWS的にどうなるか不安
      • What's newが2015年で止まっている...
  • NewsとVideoでリスクを分散したい
  • Newsアーキテクチャ刷新の試金石

UGC動画収集

  • Twitterの動画が多い
  • Twitter Search -> Spark Streaming with EMR -> 動画解析機 -(N枚の画像)> Google Cloud Visiton API
    • Googleは、画像処理周りが圧倒的に強かった
    • たとえば、ゲーム実況動画の画像を渡すと、ゲームタイトルまで返してくれる

会社自慢

  • 海外自主渡航制度
    • 用事がなくても、半年に1回、海外で1週間働ける
  • 自社イベントスペース
  • 毎月マッサージを受けられる
  • 英語学習サポート
  • SmartKitchen
    • 無料ランチ
  • 地球珈琲

smartnews.workable.com

Q&A

  • クーポンやテレビCMで変わったことは?
    • 圧倒的にユーザー数は増えて、Scale Outする数も多くなった
  • 監視は、Datadog、PagerDuty、NewRelic以外で何を使っているか?

Session2:『秒間4万イベントのプロダクトを支える裏側とは(仮)』

株式会社プレイド 徳永貴大

自己紹介

  • 楽天のアプリケーションエンジニア
  • プレイドの3人目SRE

KARTEについて

  • KARTEを知っている人?
    • (2割程度)
  • CX Plarform
    • サイトに来ているユーザーを可視化
  • StatelessなHTTPに、Statefullなユーザーレイヤーを追加したい
  • 実績
    • 秒間最大45,000イベント
    • 解析時間0.x秒

KARTEに求められるもの

  • クライアントのサービスの一部になるので、落とせない
  • req/resの一部となるので、リアルタイム解析
  • 大量のリクエストを全て解析する処理能力

マルチクラウド

なぜマルチクラウドになったのか?

  • 最初はAWSのみだった
  • 次第に一部をGCPに置き換え
    • EC2からBigtableに書き込むと、コスト増
    • 同様の機能をGCPにも構築し、両方にアクセスを振り分け

実際の障害ケーススタディ

  • 2018/7/18にGCPで大規模な障害
    • 1時間くらい、GCPのバランサーが落ちた
    • Pokemon GO、メルカリ、Abema TVなどが使えなくなった
  • 普段はGCP:AWS = 8:2で名前解決
    • SlackコマンドでAWS 10割に変更
    • 10min以内にサービス復旧

まとめ

  • マルチクラウド
    • 柔軟なサービスづくりができる
    • プロバイダー間通信に注意
      • コスト
      • VPNが詰まるとか
    • 障害に強い

宣伝

  • エンジニア募集中です!

www.wantedly.com

Q&A

  • データ量が多いので、オンプレを検討したことは?
    • まだそのようなフェーズではない認識
    • SREを3人でやっているので、リソース的にも難しい
  • マルチクラウドでプロヴィジョンをどうしているか?
    • PackerやTerraformなどを使っている
    • デプロイはSpinnaker
  • Azureという選択肢はどうですか?
    • 正直、検討していない
      • 初期はAWSが流行っていた
    • GCPを選んだ理由は、BigTable
      • そこにつなぐインフラとして、GCPを使っている
  • ネットワークレイテンシを小さくする工夫は?
    • 東京に近くてサービスが充実しているリージョンを選ぶなどしている

障害は必ず起きる

  • 2017/3: S3が3時間ダウン
  • 2016/10/13: GCPのLBが2hダウン
  • 対策
    • リアルタイム解析に関わる重要な部分は、なるべく複数プロバイダーで動かすように

Session3:『OWNERSを支えるサーバーレスアーキテクチャと、ukkaにおけるAWSの使い方』

株式会社ukka 植本 裕紀

自己紹介

  • ukkaの1人目社員
  • TechLead
  • 京都から東京に引っ越し

ukka

  • 「100年後に続く食と農のあるべき形を創る」
    • 農家さんの前でプレゼンしたり
  • 生産者側の課題
    • 誰が食べているかわからない
    • 売値が安い
    • 収入が安定しない
    • いくらで売れるかわからない
    • 質の高いものを作っても市場に出せない
      • 見た目のために味を捨てていたり
    • 規格と違う品は捨てられてしまう

OWNERS

owner-style.com

  • 生産者が作る希少食材に対して、一口オーナーとして登録し予約注文
  • 収穫された食材が最も美味しいタイミングで直接届く
  • 解決すること
    • 生産者
      • 価格決定権を持てる
      • キャッシュフローの改善
      • 事前登録型で計画生産
      • 定常的なファンづくり
    • 消費者
      • 特別な食材を予約注文
      • 最も美味しい時期に生産者直送
      • コミュニケーションで繋がる
      • 現地への体験にも参加できる
    • 「消費者ではなく当事者を作りたい」

フルリニューアル

ローカル環境をDocker化

  • 人のスケールのため
  • docker-compose up -dで全て立ち上がるようにした

デプロイ

  • 絶対に人の手でデプロイしないという強いお気持ち
    • 何度もデプロイをすることがあると、すごく時間がかかる
  • developへマージ -> staging環境へ
  • master -> production環境へ
  • Circle CIもローカルでも同じDocker環境
    • コケたら手元で検証できる

Lambdaの運用

  • Webサービス本体は1Lambdaで運用
  • 移行してどう?
    • API Gatewayはバイナリデータの扱いが苦手
    • staticなものはCloudFront + S3
    • アップロードはフロントから直接S3へ
    • 安い!
      • $100 -> $0

DynamoDBの運用

  • フルDynamoDB
    • 100テーブルほど
  • On-demand Capacityが発表されて、速攻で使った
    • キャパシティチューニングから解放された!
    • 安い!
      • $160 -> $26
      • 余裕を持って設定していた分を節約

Athenaの運用

  • マーケターが、SQL書きたいと言ってきた
    • DynamoDBなんですけど...
  • Glueからフルスキャンして、ETL JobでjsonをS3へ
  • Athenaでクエリを書けるように
  • AWSコンソールからぽちぽちしたら、実装無しでできた!
  • 使ってみてどう? -BQも良いがAthenaも十分早い
    • 安い
    • Glueが$100/month

AWSでサーバーレスやるときの注意

  • Lambdaの同時実行数上限は1,000
    • 申請が必要

宣伝

  • 全職種募集しています!

www.wantedly.com

Q&A

  • On-demand Capacityを導入する前はどうしていた?
    • 月に1回くらい、手動でチューニングしていた
    • 明確なピークが無い
  • OWNERSは、ECとSNSを合わせたようなサービス?
    • 生産者と消費者を直接つなぐプラットフォーム
    • 確かに、生産者から情報を投稿できる「手作り日誌」という機能など、相互にやりとりできる機能はある
  • ITリテラシーが高くない人たちを相手にしていることの苦労は?
    • IEを使われているのが辛いw
    • 生産者パートナーというサポートメンバーがいる
      • 機能の説明で苦労をすることは多いらしい
  • ライティングやコンテンツ作りに力を入れているが、どのようにしているのか?
    • 社員自身が取材をするパターンもあるし、ライターさんが書いてくれるケースもある
    • ゆくゆくは、FR(Farmer Relationer)を増やして、ネットワークを作っていきたい

Session4-1: 『LegalForceの開発秘話、裏側を一挙お見せします』

株式会社LegalForce 時武佑太(最高技術責任者)

自己紹介

LegalForce

legalforce.co.jp

  • 契約書をAIでサポート
  • 契約書のチェック
    • これまで
      • 紙に印刷して、見ていく
      • 「弁護士でも、契約書のリスクを35%見逃してしまう」
    • LegalForce
      • ファイルをアップロードすると、自動で抜け漏れや欠落条項をアラート
  • チーム編成
    • CEOとCOOが弁護士
    • Matzが技術顧問

LegalForceの開発エピソード

  • 最初は、コミュニケーションツールを作ろうとしていた
    • チャット+契約書+コメント
    • 解決したかった課題
      • 社内の契約書レビューに時間がかかる
      • 先方との契約書やり取りに時間がかかる
  • なぜやめたか?
    • ユーザー理解が甘かった
      • 法務部の人が使っているメールとWordの両方を代替できないと厳しかった
      • Google Docsを再発明する必要がある...?
  • レビュー支援に舵を切った
  • 2つの機能
    • 契約書検査機能
      • レビューが必要になりそうな場所を、社内ポリシーに合わせて指摘
    • 類似条文検索機能
      • 過去に使用した条文をさっと検索できる
  • プラスαのツールへ
  • 新機能
    • Wordアドインの提供

アーキテクチャ

  • CloudFrontでフロントのSPAを配信
  • APIはFargate
  • デプロイ周り
    • Circle CI
      • Dcokerイメージ作成
      • ECRにイメージ登録
      • ECSのタスク改定
  • Fargete
    • ホストサーバーを気にする必要がないのは楽
    • CPUコア数、メモリ容量を細かく指定できる
    • 高いことがデメリットだったが、50%も安くなったらしい
    • ログ周り

まとめ

  • ユーザーニーズについての認識合わせは、考えている以上に綿密に!
  • プラスαのツールになることで、居場所ができた
  • Fargateおすすめです!

Session4-2: 『AIは働き方を帰るのか 「AIaaS」が面白い理由』

川戸崇志(事業開発)

自己紹介

  • 事業開発の責任者
  • 前職はマッキンゼーで戦略策定からコスト削減まで
    • 日本の働き方の非効率さを強烈に実感

働いても、働いても、お金にならない

  • 1990年にはドイツと生産性が同じだったが、今では...
  • 製造業は健闘しているが、オフィスの生産性が低い
  • 弁護士の月の労働時間
    • 400時間
  • 工場と法律事務所で、働き方が違いすぎる

法務が抱えてきた問題と、目指すビジョン

  • 情報を探す手間
    • 情報のジャストインタイム
  • 個々人の作業の不可視性
    • 管理なきマネジメント
  • 作業手順の属人性
    • ナレッジベースのマネージドサービス化

AIaaS: AI x SaaSを可能にするビジネスモデル

  • 複数社への提供が前提
  • 自然言語処理・深層学習・技術の応用が必須
  • 受託開発では運用が困難

目標

  • 2025年までに、日本の法務の生産性を世界一に。

Session5: 『失敗をデザインする』

ラクスル株式会社CTO 泉 雄介

自己紹介

ラクスル

  • ネット印刷のラクスル
    • 印刷会社を束ねて、ユーザーは安く印刷を利用
  • ネット配送のハコベ

「失敗をデザインする」

  • ソフトウェア開発は安くない
  • むしろ、非常にお金がかかる事業
  • 「何を開発するのか」=投資判断
  • 失敗をすることを前提としたプロダクト開発

ラクスルのツラミ

  • 生身のユーザーになれない
  • 現場にソフトウェアを使ってもらうことは、想像以上に難しい
  • ドメインロジックが複雑
    • たとえば、物流の混載のロジック
    • 奥が深い上に、前例も無い

失敗の歴史

  • 年賀状アプリを外す
  • ビジネスチックデザインにして、CVRガタ落ち
  • 荷主向けアプリをリリースしてから、ほとんどPCしか使っていないことに気づく
  • 30商品追加して売れずじまい

Disinvestment

  • 「リリースしてから失敗に気づいても遅いんです。」
  • 出す前にとことん失敗すればいい
    • 「失敗のデザイン」
      • 中竹竜二(ラグビー界のコーチのコーチ)
        • 石鹸でヌルヌルしたボールで練習するなど

ラクスルの「失敗のデザイン」

    1. 現場観察・ヒアリング
    2. 仮説は立てず、ファクトを集める
    1. 課題解決の提案と試作品づくり
    2. なるべく破壊しやすいものを作る
    3. "Cheap Failure"
    1. 試作品の検証
    1. 1に戻る
  • どこかのタイミングで、リリース!

ラピッドプロトタイピングを支えるためのツールやプロセス

  • AWSも、簡単に失敗するためのツール

感想

純粋な技術の話だけではなく、その背景にあるビジネスモデルやクライアント業界の特性についても話を聞けたのがすごく面白かったです。 勉強会というとついつい技術の話に偏りがちですが、僕自身もプロダクトの話がすごく好きなので、熱いプロダクト話がたくさん聴けて楽しいひとときでした!

X-Tech JAWSは定期開催しているので、また興味があるトピックがあればぜひ参加してみたいです。

xtechjaws.doorkeeper.jp

プチ炎上から考える、「キャリア選択の足を引っ張るネガティブな意見」を無視するための3つの態度

こんにちは、#しがないラジオパーソナリティのgamiです。

この記事は「#しがないラジオ Advent Calendar 2018」最終日の記事です。 今年も良い1年でした。しがないラジオに関わった全てのみなさん、ありがとうございました。

adventar.org

さて、この記事では、「自分のキャリアは自分で決める」ということの難しさについて考えます。

ブログがプチ炎上した

「F2を辞めた人たちが、いまどんな感じなのかを書く」という尖った趣旨のAdvent Calendarが、Twitterで回ってきました。

adventar.org

まさにそういう発信をバシバシやってる身としては参加せざるを得ませんでした。 5秒くらい考えてから登録ボタンを押しました。

どんなブログを書いたか?

担当日には、「富士通SEを1.5年務めて辞めた結果、得られた3つの手札」というタイトルのブログを書きました。

jumpei-ikegami.hatenablog.com

論旨は以下です。

  • 本音で生きられないし目指すエンジニアとしての価値も上がらないので、1.5年で辞めた
  • とはいえ、富士通に1.5年いたことで、「エンジニア」、「大企業出身」、「SIer出身」という属性を獲得できた
  • こうした属性を組み合わせることで、できるアウトプットの幅が格段に広がった

特に「しがないラジオ」や「完全SIer脱出マニュアル」などのアウトプットは、富士通で得られた属性がなければ成立しないものだったと思います。 同時に、属性の近さによって多くの人と知り合うことができ、さらにそれがTwitterやオフ会を通じてコミュニティとして成立するまでになりました。 もちろん、多くのゲストの方、リスナーの方、読者の方のおかげです。ただ、その大きな流れを引き起こすきっかけを作れたことはとても誇らしく思っています。

どんな反応が来たか?

ぶっちゃけAdvent Calendar向けにさらっと書いたブログだったのですが、タイトルがタイトルなので、はてブが300近く付いてコメントも結構付きました。 もちろん好意的なコメントもたくさんありました。

しかし、以下のように1.5年で辞めたことに対して否定的なコメントも多く、そうしたコメントにも多くのスターが集まってプチ炎上の様相を呈していました。

  • 「1.5年で元SIerと言われましても」
  • 「わずか1.5年で得られた手札か」

こうした否定的なコメントに多数の賛同が集まること自体が非常に興味深く、考えさせられました。

今回のようなケースに限らず、「自分のキャリア選択に対して周囲の人から否定的な意見が寄せられる」という構図は多いと思います。 たとえば以下です。

  • 上場していない会社に就職しようとしたら、「安定した会社にしろ」と親に止められた(いわゆる親ブロック)
  • 転職しようとしたら、上司に「お前はどこに行っても活躍できない」と罵倒された

考えてみたいこと

そこで、「楽しく働くことを目指す人が、キャリア選択に関するネガティブな反応にどう対処すべきか」について考えてみたいと思いました。

きっと適切な心構えがないと、「楽しく働く」可能性の芽は摘まれ、この社会はどんどんつまらなくなってしまうように感じたからです。 大人が仕事を楽しんでいないと、それを見ている子供も未来に希望をもてないかもしれません。

楽しく働くためのキャリア選択をする人に求められる態度

外野の意見の裏側にある「感情を想像」し、「違いを明確」にし、「無視」する

基本的な態度は、「外野の意見は無視する」でいいと思います。 あなた以外の誰も、あなたの人生に責任を取ってはくれません。

宙船」でも聴いて頑張りましょう。中島みゆきの歌詞が沁みます。

感情を想像する

ただ、単純に無視するというのも難しいことが多いと思います。 たとえば以下のケース。

  • 不条理にイライラして、無視できるレベルを超えている
  • 親や配偶者など、相手が直接のステークホルダーである

そんなときは、その発言の裏側にある感情を想像してみます。

たとえば「1.5年で元SIerと言われましても」という批判コメントを題材に考えます。その背景には以下のような感情があるかもしれません。

  • 一般的に、新卒で入った会社は最低でも3年間いた方がキャリアが広がると、心から信じ心配している
  • SIerですでに20年働いていて、その業務の奥深さが理解されていないと感じ、憤っている
  • 転職が一般的になった時代の自由さに対して、妬ましく思っている

こうしたマイナスの感情に思いを寄せることで、不条理に感じる気持ちが少し癒されます。 「確かに同じ立場だったら自分も似たようなことを思ったかもな」と理解できるからです。

たとえば、僕がポッドキャストを始めたころに「ポッドキャストやってるんですよー」と言うと、相手からはちょっとバカにしたような反応が返ってくることが多かったです。 そんなときはちょっとイラっとしました。 ただし、もし自分がポッドキャストを全く聴いたことがない状態で、友人が「ポッドキャストやってるんですよー」と言ってきたらなんと言ったでしょう? きっと僕は「それって売れないYouTuberみたいなもの?」と小馬鹿にしてイジったでしょう。

誰もが立場によっては誰かの足を引っ張る側に回るし、誰もが相手の感情なんてそんなに考えてないです。 「敵と味方」 のように二分してしまうのではなく、想像力を触媒としてその間を溶かしてあげる方が、イライラしなくてオススメです。

この辺りのトピックについては、以下の本が非常にオススメです。 特に、犯罪者の心理に詳しい著者が「自分も事故を起こしたときは、相手の気持ちなんて全く考えず自分勝手な思考に捉われてしまう」と告白する部分がフェアですごく好きです。

反省させると犯罪者になります (新潮新書)

反省させると犯罪者になります (新潮新書)

違いを明確にする

意見や思いがズレる原因の多くは、立場や見えている景色が違うことです。 たとえば以下の違いからくるものです。

  • 「持っている情報の量や質」を左右する違い
    • 年齢の違い
    • 所属していたコミュニティの違い
  • 「判断基準」を左右する違い
    • 会社や家族の中での役割の違い
    • 個人としてのキャラ付け(ブランディング)の違い

その違いを理解することで、「立脚点が違うから否定されるんだ」ということに納得します。

「もっと安定した会社で働け」という発言をした親には、単純に「事業が安定していることと個人としての楽しさには必ずしも相関がないこと」や、「上場企業なら安定しているとは限らないこと」に対する知識や実感が足りないかもしれません。

「お前はどこに行っても活躍できない」と罵倒した上司は、「部下が辞めることで自分の評価が下がる」という事態を避けることを最優先にしているかもしれません。

「1.5年で元SIerと言われましても」と発言した人は、「1年間でできると思っていること」や「人生における1年間の価値」が僕とは全然違うかもしれません。あるいは、「ネットに上がってきたトピックを面白く消費すること」に対するプライオリティが高いかもしれません。

違いがわかると、「立脚点が全然違う意見は無視しよう」と、ドライに考えられるようになります。

話し合いが必要な場合は?

上司やネット上の意見は無視すればいいですが、親や配偶者であればそうもいかないかもしれません。 幸い僕は家族にキャリア選択を反対されたことは無いので、どうすればいいかを実体験を持って語ることはできません。

想像で話すと、否定する裏側にある思いを全て吐き出させて、その思いに共感し寄り添うのが大事かなーと思います。 頭の中身を吐き出して空っぽにしてからじゃないと、別の意見を入れる余地が空かないからです。

ただし、「情報の量や質が違う」という事実はどうしようもなく、心からお互いにわかり合うということは不可能です。 なので、最後はポジティブな意味で無視して自分で決め、信じて任せてもらうしかないと思います。

似たような話が書いてある記事を見つけました。

diamond.jp

「転職の思考法」という書籍の筆者の方が書いた記事みたいです。 この本は読んだことありませんが、良い評判を聞いたことがある気がするので、参考になるかも。

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

このまま今の会社にいていいのか?と一度でも思ったら読む 転職の思考法

自分と似た境遇を生きてきた人の意見を優先する

もちろん、キャリア選択に対する世の中の否定的な意見にも、参考に取り入れた方がいいものもあるでしょう。

  • その会社はいい噂を聞かないから、入るのはやめた方がいい
  • ○○をやりたいなら、××をやってるその会社には行かない方がいい

玉石混交な意見から、本当に役に立つものを選び取るにはどうすればいいでしょう? そのためには、「自分と似た境遇を生きてきた人の意見を優先する」という戦略が重要です。

全ての意見は、その発言者の経歴や経験が偏っているのと同様に、どこか偏っています。 たとえば僕の発言も、僕の経歴や経験から来る生存者バイアスで歪んでいるはずです。 どこかの誰かにとっては全く参考にするべきではない意見かもしれません。 きっと、僕の意見は以下のような属性に引っ張られているはずです。

  • 1990年代生まれ
  • 東大卒
  • 大企業出身
  • エンジニア
  • SIerからベンチャーへの転職に成功した

そのため、たとえば現時点で50代の人には全く参考にならないかもしれないし、エンジニア以外には全然当てはまらないことを言っているかもしれません。 こうした「生きてきた境遇の違いからくる現在の状況の違い」を差し引いて考える必要があります。

コミュニティなどを通じて自分と似たような属性の人とつながることで、より価値のある意見を多く受けられるはずです。 「しがないラジオ」も、「自分と属性の近い人たちのコミュニティだ」と思ってくれる人のために、価値を提供できるコミュニティであるといいなあと思います。

「世代間の争い」

様々な違いの中で、最も大きなものが「世代」の違いだと考えています。 単位時間当たりに手に入る「情報の量」や「繋がれる人の数」が爆発的に増えていく中で、世代間の情報格差は信じられないほど広がっています。 僕自身、一世代下の人たちの文化や考え方に付いていけていないと感じることが頻繁にあります。 同時に、自分より若い人たちの仕事上での優秀さに、焦りを感じることもしょっちゅうです。

また、世代毎に何かの価値判断をするときの「判断基準」も大きく変わると思います。 あと20年しか生きない人に「未来への投資のために云々」と言ってもピンとこないかもしれません。 若い世代は、これからどんどんリスクを取ってレバレッジを効かせられます。 逆に言えば、「あと50年以上楽しく生き続けよう」と本気で考えたら、今から色々と仕掛けてスキルや経験や実績を積まないといけません。

僕はベンチャーに転職して、仕事中もずっと本音で生きられるようになりました。  その1つの要因が、近い世代の人が多くいる場所に移ったことだと考えます。 もはや、「これまでの世代が作った常識を、現代に合うように作り変えていく」という「世代間の争い」を、公私ともにやっているという感覚すらあります。 この点に関しては、以前「クソみたいな当たり前を壊すことが、ベンチャーに関わる楽しさである」という趣旨のLTをしました。

speakerdeck.com

「価値が届いた実績」が自分を癒す

変わったキャリアを選択したり、ユニークなチャレンジをしようとしたりするほど、周りからの「そんなの無理でしょ」という意見に晒されます。 そんな否定的な意見に晒され続けて、心が荒むこともあるでしょう。

ネガティブな反応に心を左右されなくするための一番の方法は、「価値が届いた実績」を積み重ねることです。 「やっぱりそんな仕事やらない方がいい」と言われても、「あなたは知らないかもしれないが、実際に私の仕事に対してユニークな価値を感じてくれる人がいるのだ」という実感があれば、自信をもって無視することができるでしょう。

たとえば僕は「わずか1.5年で得られた手札か」というコメントを見たときも、全然気になりませんでした。 それは、「わずか1.5年」でSIerを辞めたことで可能になったアウトプットが、「人生が変わるきっかけになりました」というポジティブな反応をたくさんもらえるほどの価値を生んだことを知っているからです。 「しがないラジオ」や「完全SIer脱出マニュアル」をきっかけにして、実際に転職をしたり、エンジニアとしてのアウトプットやつながりを増やしたり、楽しく働ける人が増えているという実感があるからです。

「完全SIer脱出マニュアル」が技術書典5で売れたときの感動については、以下のLT資料に書きました。

esa-pages.io

また、「わかばちゃんシリーズ」で有名な湊川あいさん(@llminatoll)も、「書籍化目指します!」というチャレンジに対するネガティブな反応についてマンガで描いています。

会社の中での仕事においても、会社の中で「自分にしか生み出せない価値」を発揮できた実績を積み重ねていくことで、「自分はここにいていいのだ」という自信を強くもつことができます。

このように、実際に「価値が届いた実績」を積み上げていくことで、自分をネガティブな反応から守る「最強の盾」をつくることができます。 また、感謝の言葉を言われると、これまでの苦労や心労がどんどん癒されていきます。 言い換えると、「『世間体』よりも実際に自分や周りの人が感じた『価値』を大事にする」ことで、次第に世間体は気にならなくなっていきます。

自分で決めてない選択は、反省すらできない

ここまで、「楽しく働くことを目指す人が、キャリア選択に関するネガティブな反応にどう対処すべきか」について考えてみました。

まとめると以下です。

  • 外野の意見は、「感情を想像」し、「違いを明確」にした上で、「無視」する
    • そうすることで、イライラせずにちゃんと無視できる
  • 多くの意見の中からは、「自分と似た境遇を生きてきた人の意見」を優先する
    • 特に、同じ世代を生きている人と共に戦う
  • 「価値が届いた実績」を積み上げることで、ネガティブな反応から自分を守り癒せる

では、逆に「納得できないまま、周囲の意見に左右された決断をしてしまった」場合、どうなるでしょうか? そのような決断の一番の問題点は、「仮に失敗したとしても、自分の失敗として反省できない」ことです。

多くの人は、キャリア選択の中で失敗を繰り返しながら、より楽しくなる方向に舵を切っていきます。 僕自身、公務員試験に落ちて就職浪人したり、自分と合わない会社に新卒で入ってしまったり、多くの失敗を繰り返してきました。 しかし、それらは全て自分がそのときの最大限の努力をもって選んだ道でした。 それが失敗だとわかった時点で、自分にどんな情報が足りなくて、どんな思い違いをしていたのか、「自分事」として反省することができました。

もしも、たとえば「親から言われたから」という理由でキャリア選択をしてしまったら、その失敗を親のせいにするはずです。 「自分は悪くない」という言い訳に使える材料がある以上は、人は易きに流れます。 自分自身の落ち度として反省はせず、失敗を自分の糧にすることができません。 次に大きなキャリアの選択をするときも、リスクをとって正しい選択をする能力は一向に上がっていきません。

自分の思うようにキャリアをコントロールするためには、「自分で決めた」と言える決断を積み重ね、またその決断が失敗だったときも過去の決断を「失敗だ」と自分で断定していく作業が必要になります。 自ら主体的に決断と失敗を繰り返すことで、初めて「自分」にその経験値が蓄積されていきます。

「失敗したらどうする」というネガティブな反応がよくありますが、「ちゃんと『失敗』できないこと」以上に無駄なことは無いのです。

他の誰も、「私の人生」を代わりに生きてくれる訳ではありません。 「私」が生きるしかない「私の人生」は、自分の責任において楽しい方向に引っ張っていくしかないのです。

楽しく働き続けられる場所は、きっとあります。 ネガティブな意見に負けずに、頑張ってつくっていきましょう!

エンジニア勉強会で間違った情報を発表してもいいのか?WeJSで考えるコミュニティの価値と運営

f:id:jumpei_ikegami:20181219070822p:plain

こんにちは、gamiです。

この記事は『We Are JavaScripters!【執筆初心者歓迎】 Advent Calendar 2018』の18日目の記事です。

adventar.org

今年は僕が書いたサイ本についてのブログ記事がバズったりしました。

jumpei-ikegami.hatenablog.com

なのでJavaScript自体のことを書いてもよいのですが、せっかくWe Are JavaScripters!(以下、WeJS)も2周年を迎えたことなので、WeJSから考えるコミュニティの在り方みたいなことを書きたいと思います。

僕とWeJS

最初に自分語りをします。

たみー in セブ

僕は「新卒のときに就活で都庁の公務員採用試験しか受けずに爆死する」という若気の至りによって、大学卒業後に1年間フリーター生活をしていました。

その人生最後?のモラトリアム期間で、「留学というものをしてみよう」と思い立ち、セブ島に英語留学に行きました。

選んだのは、NexSeedという「エンジニア留学と英語留学が一緒にできる」という触れ込みの語学学校でした。 nexseed.net

そこにはフィリピン人講師だけではなく学校運営メンバーもいて、学校を運営しているギークス株式会社からもインターンが何人か来ていました。 geechs.com

その中の1人が、WeJSの創始者であるたみー(@ta__miyan)でした。

学校に通う日本人生徒は基本的に同じ寮に住むのですが、寮と学校との間は「ジプニー」という乗合タクシーで移動します。

ジープニー - Wikipedia

たみーはジプニー担当で、毎日学校にジプニーが到着する度に「ジプニー!ジプニー!」と生徒に呼びかけていました。 5時のジプニーが来た時は、「5時プニー!5時プニー!」とも言っていたような気がします。

超ドメスティック思考だった当時の僕は、「海外まで来てインターンをする凄い人がいるもんだ」と感動していました。

初めてのWeJS

フリーター生活の末に富士通という会社に入社しCOBOLを書いていた僕は、なんと1.5年で会社を辞めてWebエンジニアとしてベンチャーに転職しました。 (最近、その経緯を書いたブログが「1.5年で何がわかんの?」とプチ炎上しました) jumpei-ikegami.hatenablog.com

転職先はNode.jsとVue.jsをメインで使っているPLAIDという会社で、転職当初は必死にJavaScriptを勉強していました。

また、しがないラジオというポッドキャスト富士通同期の@zuckey_17と一緒に始めることになり、そのネタ作りや宣伝のために、「勉強会というものに行ってみよう」という気運が高まっていました。

そんなとき、Twitterか何かでWeJSの情報が流れてきて、「初心者向けのJS勉強会とか最高かよ」と思って詳しく調べました。 主催者をよく見てみると「これ、ジプニー使いのたみーさんでは?」と気付き、その偶然に驚きながら、気づくとconnpassの参加申し込みボタンを押していました。

最初に参加したのは、今から1年半以上前、2017/3/11の休日もくもく会でした。 ポッドキャストの相方である@zuckey_17も一緒で、なんならしがないラジオep.1の収録をした、まさにその日の午後でした。

wajs.connpass.com

今思うと、いきなりもくもく会から参加するのも変な感じですが、変な内輪ノリとかも無くとても居心地よく作業できました。 すでに主催者に加わっていたふかみん@fukamiiiiinmin)さんが、@zuckey_17にReact.jsについて質問をしにきて、「説明マジでわかりやすいっすね!お金取れますよ!!!」とハイテンションで言っていたのが印象的でした。端的に言って、「コミュ力おばけ」でした。

今思い返すと、初参加の私たちに気を使って話をしにきてくれたのかもしれません。

WeJSとの1.5年間

そこからは、「毎回参加するわけでもないが暇だったら行く」くらいのゆるーい参加者として、3ヶ月に一回以上は参加していたような気がします。

登壇も、WeJS@10thで1回だけしました。

speakerdeck.com

継続的に参加している勉強会はWeJSしかなかったのですが、 「勉強会に何度も参加していると主催者や常連と顔見知りになってさらに楽しくなる」という気づきを得られました。

また、最近では僕が窓口になって弊社PLAIDのオフィス@GINZA SIXを会場としてWeJSに提供することもあります。 wajs.connpass.com

WeJSでエンジニアコミュニティについて学べたと思っているので、少しでもその恩返しができていれば嬉しいなあと思います。

WeJSで考えるコミュニティ運営

WeJSを外から見ていたり主催者のみなさんから話を聞いて、コミュニティ運営について考えたことを書きます。 完全に外部の立場から勝手に言ってるだけなので、私見です。

「マルサン・コミュニティの法則」とWeJS

コミュニティ・アクセラレーターの河原あずさんという方がいるのですが、その人がブログに「マルサン・コミュニティの法則」というコミュニティ運営の法則を書いています。

azkawahara.hatenablog.com

要約すると、「コミュニティ・ベースからイベントに動員する人数比を、『コア:常連:新人』で1:1:1にすると、コミュニティが育ちやすい」ということらしいです。 特にWeJSでは「初心者歓迎LT大会」を標榜しているので、一定割合を「新人」に保つというのが重要な気がします。

ここはWeJS主催者側でも意識しているようで、2018年1月からは「ビギナー登壇枠」を設けて、登壇3回未満の人が優先的に登壇しやすいように参加枠の設計をしています。

2年もコミュニティが続き、常連さんもかなり増えている印象ですが、同時に新しい人の登壇も良く見るので、この辺りのバランスは流石だなといつも思っています。

WeJSの裏にある思想

WeJSの歴代主催者4人にはしがないラジオというポッドキャストにゲスト出演していただいているのですが、清水(@chikoski)さんが出演回で話されていたことがすごく印象的でした。

勝手にまとめると以下です。

  • コミュニティは書籍と違って、正確で体系的な知識を与えてくれるわけではない
  • コミュニティの存在意義を、「安定した状態のモノに対して外部から刺激を与えること」に置きたい
  • 「何を言ってもいい状況」を維持することで、コミュニティの中で様々な刺激が得られる

WeJSでは「マサカリ」(登壇者に対して技術的な指摘を強めにすること)を禁止し、「安心して発信できる環境」を大切にしているそうです。 この点は、WeJSの「アンチハラスメントポリシー」にも明記されています。

極端な話をすると、コミュニティでは「間違った情報を登壇者が話す」ということがあっても、その現象自体が刺激になれば許容されるべきとも言えます。 もちろん、参加者の今後の学習のために軽く指摘した方がいいことはあるでしょう。 しかし、「なぜ間違った情報を信じてしまったのか?」ということを題材にして、議論が深まったり、新しい課題が見つかったりすれば、それは1つのコミュニティにとっての価値でしょう。

こうした「様々な刺激が得られる」環境を維持するためには、先ほどの「マルサン・コミュニティの法則」で言った「一定割合を新人に保つ」ということも重要に思えます。 常に同じ人が参加し続けていると、似た考え方や知識量の人が増えていき、一参加者が得られる刺激としては減っていきます。 そこに全く新しい視点を持ち込むためには、コミュニティにとって異質な「新人」を温かく迎え入れ、内部に取り込んでいく必要があります。

「WeJSというコミュニティはどんな価値を提供すべきか?」という思想が背景にあって、それを実現するための運営ポリシーがあるからこそ、WeJSはみんなに長く愛されるコミュニティになっているのだなあと、強く感じます。

宣伝

散々WeJSを持ち上げたところで、宣伝です。

前述のように、WeJSの歴代主催者4人には、僕がパーソナリティの1人をしている「しがないラジオ」というポッドキャストにゲスト出演していただいています! コミュニティ運営の裏話なども聴けるので、ぜひ各種ポッドキャストアプリで聴いてみてください。

富士通SEを1.5年務めて辞めた結果、得られた3つの手札

こんにちは、gamiです。 この記事は、楽しかった職場 みんなのF2 Advent Calendar 2018 - Adventarの9日目の記事です。

僕は文系卒で2015年4月に富士通に入社してから公共系SEになり、2016年11月に退職して当時40人規模のベンチャーにWebエンジニアとして飛び込みました。 今は楽しくて仕方がない仕事生活をしています。

また、その経験を活かして「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という燃えそうなタイトルのポッドキャストをやっています。 略して「しがないラジオ」といいます。

テーマ

以下を書きます。

富士通に入った理由

富士通に入った理由は、主に以下の2つです。

  • もともと公務員志望で、公共系システムの開発に関わりたかった
  • ITスキルという自分の専門性を獲得したかった

いま思うと、その両方は富士通で満たすことができたので、感謝しかありません。

富士通を辞めた理由

富士通を辞めた理由は、主に以下の2つです。

  • 本音で生きられない環境だった

「社長-本部長-事業部長-部長-マネージャー-平社員-パートナー」という身分制度がしっかりしている会社だったので、「平社員」の身分を超えた発言や活躍ができないのが今思うと辛かったです。 特に仕事のでき不出来が身分と完全に相関している訳ではなかったので、「仕事もできないのに出世してる人」への不満みたいなものが社内に見え隠れしている感じはありました。 もちろん尊敬する先輩や上司もいましたが、彼らもまた完全に本音では生きられないように見えたので、それもまた辛かったです。

  • 開発手法や技術が古すぎて、エンジニアとしての価値が上がらないと感じた

とあるきっかけでRebuildという神Tech系ポッドキャストを聴き始めたのですが、そこで話されている技術的なトピックが全然わからずに衝撃を受けました。 エンジニアインターンなどはしたことがなかったので、「COBOLJavaアプレットとか結構古そうだけど、業務での開発なんてこんなもんなのかな」と思っていましたが、全然そんなことは無かった。 プロジェクトとしても、もっと生産性の高い開発を目指すべきだと思ったし、個人としてもそういった開発に触れていないと転職できなくなると感じたので、早めに転職しました。

以上です。 もちろん、富士通は超巨大企業なので、部署によって全く別の会社のように文化が違ったりします。 そのため、たまたま僕がいた部署と僕が合わなかったというだけの話でしかありません。

なお、転職活動の経緯は、以下の記事にも書きました。

jumpei-ikegami.hatenablog.com

また、「しがないラジオ」の最初の方の回でも経緯について話していると思います。 聞いていない人は、ぜひ各種ポッドキャストアプリから聞いてください。

転職前後の違い

結果的には、富士通に1.5年だけ在籍して、当時40人のベンチャーに転職しました。 その中で働く個人として、両者の違いを考えます。

信じて任せる範囲

富士通にいた頃は、良くも悪くも「新卒1年目」として扱われ、「全てのアウトプットに誰かしらの事前・事後の承認が必要」な状態でした。 制度や風土としても、「優秀な人には信じて任せる」というより、「どんな人が来ても最低限の仕事ができる」ことを目指した組織だったと思います。

現職は当時40人の会社だったので、純粋に「会社の一員」として迎えてもらった気がします。 また、「事前に承認を得るより、勝手にやって迷惑かけたら後から謝る方がいい」という失敗を奨励する文化だったので、「自分で勝手にissueを立てて自分で勝手に解く」みたいなことをガンガンやることができました。 これが、少なくとも僕には性に合っていたようで、とにかく仕事が楽しく、月曜日に会社に行くのが辛くなくなったのが衝撃でした。

それなりに仕事ができる個人の生産性を最大化するには、「個人を信じて、個人に任せる」ことが必要だと実感しました。

服装

富士通ではだいたいみんなスーツを着ていたので、僕もスーツを着ていました。 いま思うと、客先に行かないことがほとんどだったので、「誰のためにスーツを着ていたのだろうか?」という気持ちです。

いまは、だいたい赤いスニーカーにTシャツとパーカーで出社しています。 クライアントとの打ち合わせに同席することも多いですが、なんとそのままの格好で行っています。

働き方

富士通では、8:40出社、17:30退勤でした。 出勤時間は打刻管理され、遅刻が許されない雰囲気でした。 「朝に遅刻をしてはいけない」というプレッシャーが地味に辛く、寝過ごした日は朝一の打ち合わせなどがなくても走って出社していました。 なお、残業が多い部署もあったようですが、幸いにも僕はほとんど残業せずに18:00までには退勤していました。

いまは、前述のように「個人の生産性は個人が管理する」という思想の会社なので、フルフレックスで何時に来ても何時に帰ってもいいです。 一応10:00〜19:00が就業時間っぽい雰囲気はありますが、別に守る必要はありません。 また、リモートワークも自由なので、1人でできる作業をするときは家でやったりもしています。 「少し朝に洗濯してから行こうかなー」みたいなことが気軽にできるのは、生活のストレスが減ってすごくいいです。

給与

富士通の当時の年収と比べると、今の年収はだいぶ高いです。

富士通では、少なくとも入社数年は全員給料が同じ(正確にいうと、学部卒と院卒では初期の給料が違う)です。 そこからは職位とともに上がっていくと思いますが、職位自体がだいたい足並み揃えて上がる印象なので、そんなに給料の差がつきにくい会社だと思います。 僕は給与にそこまで関心が高くないのであれですが、純粋に給料だけを考えれば、「平均以上に優秀な人は損をし続ける」制度だったと思います。

富士通にいたことで得られた3つの手札

富士通に入社したことを後悔しているかというと、全くそんなことはありません。 以下の3つの手札を得られて、その先の活動の幅が広がったと感じるからです。

  • エンジニアと名乗るのに最低限必要な「ITスキル」

転職後しばらくはゴリゴリのWebアプリケーション開発をしていましたが、割とキャッチアップは早かったと思います。

  • 「大企業」の組織構造を体験したこと

まだまだ日本の経済活動の多くは「大企業」が回していると思いますが、その裏側を身をもって体験できたのはとても良かったです。 最近、学生のキャリア相談に乗ることがありましたが、「大企業とベンチャー」という比較軸で実体験を話せるのは結構ありがたがられました。

  • SIer出身」という属性

SIerと自社Webサービス開発」の2つを経験しているという属性があるからこそできることがあると強く感じています。 一番有名な活動としては、冒頭に書いた「しがないラジオ」というポッドキャストを配信しています。今では初対面の人に「しがないラジオのgamiさんですよね?」と言われることがあるくらいに広まっています。 ポッドキャストではゲストの方を呼んで色々なテーマで話すのですが、キャリアの話、特に「SIer論」みたいな話が話題になることが多いです。 このようなテーマについて話せる最低限の経験ができたことは、とてもよかったと思っています。

このテーマを煮詰めて実用的に固めた、「完全SIer脱出マニュアル」という同人誌も書いたりしました。

jumpei-ikegami.hatenablog.com

仕事や趣味を問わず、個人としてのアウトプットは「いかに自分の尖った手札を増やして、それを組み合わせるか」がとても重要だと考えています。 その意味で、「エンジニアである」とか「大企業に新卒で入った」とか「SIerCOBOLで開発をしていた」などの属性を手札として獲得できたことで、アウトプットの幅は格段に広がりました。

まとめ

富士通には、ITスキルという専門性が欲しくて入社しました。 富士通は同期も多く研修も手厚いので、新卒で入る会社としては最高でした。 ただ、たまたま僕が配属された場所は、そこから成長していこうと思ったときにスピードが出ない予感がしたのですぐに辞めてしまいました。

富士通に入る決断も辞める決断も、どちらも後悔はしていません。 逆にいうと、それを後悔しなくても済むように、その経験を自分個人のカードとしてうまく利用している節があります。 もしこの記事を読んでいる富士通の若手社員に偉そうにアドバイスを垂れ流すとしたら、「キャリアの選択肢を広げるための『カード』を今の仕事で獲得し続けられるか?」という視点で振り返ってみるといいと思います。

ちなみに、そのためには今とは違う可能性についても知る必要があるので、「転職」をするかどうかに関わらず、「転職活動」をしてみるのがおすすめです。

【保存版】 #技術書典 初出展マニュアル【表紙入稿データサンプル付き】

f:id:jumpei_ikegami:20180922182207p:plain

gami(@jumpei_ikegami)と申します。 2018年10月8日に開催された「技術書典5」で、『完全SIer脱出マニュアル』という本を頒布しました。

jumpei-ikegami.hatenablog.com

技術書典とは、技術書オンリー同人誌即売会です。

技術書典

僕が所属するサークル「しがないラジオ」は、 技術書典へのサークル参加はおろか、同人誌を作ること自体が初めてでした。 なんとか無事に入稿も終え、当日を迎えることができました。

しかし、正直に言って、同人誌作りのノウハウはインターネット上にまだまだ足りないと思います。 特に入稿作業にまつわる細かい情報について、 印刷用語や入稿の方法など重要なことはかなり調べないと出てこない印象でした。

そこで、僕たちのような「初の同人誌作りで技術書典への初出展を目指す人」に向けて、 同人誌の入稿や当日運営に必要な「ミニマムの作業」を、実際のスケジュールも含めて全て公開します。 このブログ記事を読んで、技術書典の出展に対する不安がなくなったら、 ぜひサークル申し込みをしてみましょう。

前提

基本的には僕が体験したことしか語れないので、この記事は以下の前提のもとに書かれています。

  • 印刷所は日光企画さんを利用する
  • オフセット印刷フルカラーセット(後述)で、特別な装丁は無し
  • 以下の形式で頒布する
    • 技術書典5当日
      • 物理本(B5)
      • ダウンロードカード
    • それ以降
      • PDF版のネット販売
  • 作業環境

事情が異なる人は、 適宜読み替えてください。

技術書典5までのスケジュール

技術書典4当日から技術書典5当日までの詳細スケジュールです。 細かいです。

  • 下線がある部分は、弊サークルがやった作業
  • 全て2018年の出来事
日付 n日前 出来事
04/22 169日前 技術書典4当日!
06/20 110日前 技術書典5開催決定&サークル申込受付開始
07/19 81日前 サークル申込受付終了
08/01 68日前 当落発表
08/05 64日前 「技術書をかこう! ~はじめてのRe:VIEW~」購入
08/09 60日前 執筆環境の構築完了
08/12 57日前 表紙デザイン依頼
08/17 52日前 サークル配置決定
08/19 50日前 表紙案の完成
08/20 49日前 第1章の草稿が完成
08/24 45日前 サークルカットデザイン依頼
08/29 40日前 サークルカットデータ完成
08/30 39日前 日光企画が入稿締切日を公開
08/31 38日前 カタログ用サークルカット締切
09/04 34日前 第2章の草稿が完成
09/09 29日前 入稿プランを決定
09/10 28日前 一般参加者向けウェブサイト公開
09/16 22日前 本編全ての草稿が完成
09/17 21日前 本編の校正作業が終了 & 表紙データ仮完成
09/20 18日前 ページ数の確定 & 表紙データ完成
09/21 17日前 付録の草稿が完成
09/22 16日前 20%OFF締切 & 怒涛の入稿日!
10/01 7日前 ダウンロードカードの入稿
10/02 6日前 通常料金締切
10/03 5日前 10%UP締切
10/04 4日前 15%UP締切
10/05 3日前 20%UP締切
10/06 2日前 直前準備
10/08 0日前 技術書典5当日!

以下の作業は、もうちょっと早くやった方がよかったです。

  • 草稿の執筆(がんばるしかない)
  • サークルカットデザイン依頼(デザイナーさんすいません。。。)
  • ダウンロードカードの入稿(早ければ早いほど安心)

なお、技術書典の公式的な告知については、だいたい「技術書典公式ブログ」で公開されています。 実際の内容が見たい場合は、ぜひ技術書典公式ブログの過去記事を読んでください。

知らなかったけど実は重要だった情報

最初の時点で知っておいた方がよかった「意外な事実」について紹介します。

  • 物理本を印刷する場合、ダウンロードカードのみに比べて難易度が10倍くらいになる
    • でも、紙の本を作って売るの楽しい
  • 印刷用の本文入稿データは、ページ数を4の倍数にする必要がある
    • つまり、最後にページ数の調整が必要
  • ページ数が確定できないと、表紙データも確定できない
    • つまり、ページ数が締切ギリギリに確定すると、表紙データの修正も締切ギリギリになる
  • 初めての入稿はWebではなく店舗で直接やった方が、その場で紙や印刷方法の実物を確認できて良い

どれも物理本に関わる部分です。紙の印刷を思い通りに行うのは結構めんどくさいですが、技術書典当日に段ボールを開けるときの感動はなにものにも代え難いので、ぜひがんばってみてください。

「技術書典」初出展マニュアル

それでは、作業の詳細について弊サークルの実際の時系列で述べていきます。 たぶん長くなるので、作業フェーズに合わせて気長に読んでください。

169日前: 技術書典4当日!

技術書典4が開催されました。 僕は一般参加者として参加しました。 技術書典自体が初参加だったので、その活気に衝撃を受けました。

知り合いも何人か本を出していたので、 次回はサークル側で参加したいなあとぼんやり考えました。

110日前: 技術書典5開催決定&サークル申込受付開始

技術書典5の開催が決定され、同時にサークル申込受付が開始されました。

blog.techbookfest.org

全ての手続きは、技術書典公式サイト内で完結します。 何を書くか決まっていませんでしたが、とりあえず申し込みました。

81日前: サークル申込受付終了

開始から1ヶ月経つと、サークル申込期間が終了します。

68日前: 当落発表

出展可能サークル数に対して希望数の方が多かった場合は、抽選になります。 技術書典5では会場が広くなったこともあって、あまり落選の話は聞かなかった印象です。

64日前: 「技術書をかこう! ~はじめてのRe:VIEW~」購入

技術同人誌の書き方を全く知らなかったので、技術書典を主催するTechBoosterさんの同人誌を買いました。 この本が無ければ、僕は同人誌をここまでトラブル無く頒布できなかったでしょう。 というわけで、ぜひ入手することをおすすめします。

techbooster.booth.pm

のちに気付きましたが、この本をビルドするためのデータは全てGitHubで公開されています。 自分でビルド環境を整えたあかつきには、普通に本のコンテンツをPDF形式で読めます。

github.com

ただし、お布施の意味でBOOTHで購入するのも良いと思います。

60日前: 執筆環境の構築完了

入稿用PDFのビルド環境を整備

最低限の執筆環境を整えます。 実施した作業としては以下です。(もしかしたら不要な作業があるかもしれませんが、まあ気にしない)

$ git clone git@github.com:TechBooster/C89-FirstStepReVIEW-v2.git
$ mv C89-FirstStepReVIEW-v2/ REPO_NAME/ # REPO_NAMEは適宜変える
$ cd REPO_NAME
$ rm -rf .git/
$ git init
  • vvakame/docker-reviewでビルドできるように、プロジェクト直下に以下のRakefileを保存する
    • 別にコマンド実行できればpackage.jsonのscriptsでもなんでもいい
$ touch Rakefile
desc 'build pdf'
task :pdf do
  sh <<~"EOF"
    docker run \
    --rm \
    -v `pwd`:/work \
    vvakame/review:latest /bin/sh -c "cd /work/articles && review-pdfmaker config.yml"
  EOF
end
  • 以下を実行し、PDFがビルドできることを確認
    • うまくいくと、/articles直下にPDFが生成される
$ rake pdf
  • 以下を全て削除する
    • /articles/*.re
      • 章別のコンテンツファイル
    • /articles/images/*
      • コンテンツ内に挿入する画像
  • /articles/catalog.ymlから、削除した*.reファイルの指定を削除する
    • あとで実際のコンテンツを追加していく
  • /articles/config.ymlを書き換える
    • 書き換える箇所は、たぶん以下(内容は適宜変えてください)
bookname: escape_from_sier
booktitle: 完全SIer脱出マニュアル〜『しがないラジオ』と学ぶ、転職して楽しく働くための7つのステップ〜
aut: ["jumpei_ikegami","zuckey_17"]
edt: ["jumpei_ikegami"]
pbl: しがないラジオ プロジェクト
date: 2018-10-8
history: [["2018-10-8 技術書典5版 v1.0.0"]]
rights: (C) 2018 しがないラジオ プロジェクト
  • 気になるようであれば、不要なファイルを削除する

    • PDFの生成だけなら、以下は要らないはず
      • /Gruntfile.js
      • /articles/*.scss/articles/*.css
  • commit & push

$ git add -A
$ git commit -m 'initial commit'
$ git remote add origin git@github.com:ACCOUNT_NAME/REPO_NAME.git # ACCOUNT_NAMEとREPO_NAMEは適宜変える
$ git push -u origin master
  • CI環境とかは、まあ無くても何とかなる

執筆フロー

上記作業が完了したら、とりあえず執筆作業を始められます。

まずは、Re:VIEW記法をなんとなく覚えます。

github.com

見出し、箇条書き(ol、ul)、リンク、画像辺りを覚えれば最初は十分です。

執筆フローは、大まかに以下です。

  • 新しい章を書き始めるときには、ブランチを切って/articles/xxx.reファイルを新規作成する
  • 章のコンテンツをそのreファイルにRe:VIEW記法で記述する
  • /articles/catalog.ymlに、その章に対応するreファイル名を追加する
  • rake pdfでビルドして、出力を確かめる
  • 必要なら、PR作ってレビューを依頼する

編集作業は最後にやるので、まずはコンテンツの量を稼ぐことを考えます。

ちなみに、/articles/config.ymlでいじった記憶がある設定値は、以下の2項目です。

# 目次として抽出する見出しレベル
toclevel: 2
# 本文でセクション番号を表示する見出しレベル
secnolevel: 3

57日前: 表紙デザイン依頼

Adobe IllustratorPhotoshopが自分では使えない場合は、 表紙と裏表紙のデザインを誰かに依頼します。 僕は偶然にも婚約者さんがデザインできる人だったので助かりました。

日光企画で印刷する場合は、最終的には以下の「表紙用トンボテンプレート(B5判・PSD形式)」を使って作成することになります。

【トンボダウンロード】オフセット用

ちなみに、デザイナーさんにお願いする可能性のある制作物は、全体を通して以下です。 僕はPOPや値札だけ自分で作りました。

デザイナーさんにお願いする可能性のある制作物

  • 物理本の表紙+裏表紙データ(.psdなど)
  • PDF版の表紙/裏表紙データ(.jpgなど)
    • 物理本と違って、表紙と裏表紙を別ファイルにする
    • 背表紙は無し
  • ダウンロードカードの印刷データ(.aiなど)
  • サークルカット(.png
  • 当日設営に必要な印刷物(.pdfなど)
    • ポスター
    • POPや値札

52日前: サークル配置決定

サークルの配置が決定します。 特にこの時点で配置を意識することは無いです。

気が向いたら、Twitterの表示名に配置番号を入れましょう。 僕は技術書典期間中はgami お27『完全SIer脱出マニュアル』@技術書典5さんになりました。

50日前: 表紙案の完成

表紙案がデザイナーからいくつか上がってきたので、良さそうなやつを選んで軽く幅出ししてもらいます。

49日前: 第1章の草稿が完成

時間を見つけて、原稿も進めます。

45日前: サークルカットデザイン依頼

サークルカット」のデザインを依頼します。 サークルカットとは、技術書典のサークルリストやカタログに掲載されるサムネイル的な画像です。 普通にPNGファイルなので、自分で作ってもいいです。

f:id:jumpei_ikegami:20181007200612p:plain

docs.circle.ms

  • 画像をダウンロードして、サイズを変えずに上書きする
  • 左上の枠は配置番号、右上はサークル名を書く(たぶん)
  • Web用(カラー)、カタログ印刷用(グレースケール)の2種類用意

40日前: サークルカットデータ完成

サークルカットの画像データが完成したら、技術書典のマイページで2種類とも登録します。

ついでに、書く内容も固まった頃だと思うので、「頒布情報」も埋めておきます。 頒布情報には、同人誌に関する以下のような情報を登録します。

  • 書名
  • 概要(1,000文字まで)
  • ページ数
  • 頒布価格
  • 頒布予定数
  • 関連URL(最大4つ)
  • 頒布物について説明する画像(最大4枚)

いつでも編集できるので、未定の項目は決まり次第登録します。

39日前: 日光企画が入稿締切日を公開

これも同人誌文化らしいですが、印刷所毎に、「このイベント向けに同人誌を印刷するなら、いつまでに入稿してくださいねー」という締切が設定されます。 印刷のプランによって違いますが、通常締切はだいたいイベントの1週間前くらいです。

なお、通常締切より早く入稿すると割引になったり、遅く入稿すると割増になったりします。 早く入稿できれば部数によっては数万円単位で安くなるので、できれば早割りを狙っていきましょう。

38日前: カタログサークルカット締切

カタログ用のサークルカット(グレースケールの方)が締め切られます。 つまり、この時点のサークルカットでカタログが印刷されます。 間に合わなかった場合はデフォルト画像になるので、頑張りましょう。

なお、Web版のサークルリストはこれ以降も編集できます。

34日前: 第2章の草稿が完成

全体の1/3くらいの草稿が書き上がりました。

29日前: 入稿プランを確定

日光企画のWebサイトとにらめっこしながら、入稿プランを確定しました。 サイトには色々書いてありますが、オフセットなら「スタンダードフルカラーセットB5」というやつにすればいいです。 名前的に本文もカラーかと誤解しがちですが、表紙がフルカラーなだけで本文はグレースケールです。

プランが決定したら、目指す入稿締切日を決めます。 僕らはイベント16日前入稿の「20%OFF」を目指すことを宣言しました。

なお、日光企画さんが「にこぷり」というサービスでWeb見積もりができます。

日光企画 にこぷり.com

入稿自体は店舗で実施するのでここでの手続きは不要ですが、何となくどんな設定値があるのかを見ておくと良いでしょう。 入稿時には、ざっくりと下記項目を決めることになります。

  • オフセット/オンデマンド
  • プラン(スタンダードフルカラー)
  • 表紙の用紙、印刷方法、PP貼り(表面の加工方法みたいなやつ)
  • 本文の用紙、印刷方法
  • トジ方法、トジ方向
    • オフセットで横書きなら、普通は「平トジ/左トジ」
  • ページ数、発行部数

用紙などは店舗で実物を確かめながら選べるので、ここで決める必要は無いです。

ちなみにこの日は「本編の草稿を完成させるぞ」という意気込みで1日中カフェに籠りました。 実際の草稿完成はその7日後のことでした。 えてして、自分の作業見積もりは甘くなりがちです。

28日前: 一般参加者向けウェブサイト公開

一般参加者向けに、ウェブサイトが公開されます。

特に重要なのは、「サークルリストが一般公開される」ということです。 参加者はサークルリストを眺めて、どのサークルの本を買おうか吟味します。 つまり、この一般参加者向けウェブサイト公開までにサークルカットや頒布情報などを充実させておくことで、より広い人に興味をもってもらえるようになります。

この日までには、自サークルの情報をちゃんと技術書典のサイトに登録しましょう。

22日前: 本編全ての草稿が完成

本編の草稿が書き終わりました。 めっちゃ疲れた。

21日前: 本編の校正作業が終了

以下を無くすために、校正作業をしました。

  • 誤字・脱字
  • 表記揺れ
  • 不適切な表現やわかりにくい表現

また最初から読み直して、「全体を通じた表現や論旨の一貫性」を向上するための修正をガシガシ加えていきます。

PCで作業をしてもいいですが、なぜか人間は紙に印刷した文章の方が校正能力が上がる気がします。 アナログですが、印刷した草稿に赤ペンを入れていくのがおすすめです。

21日前: 表紙データ仮完成

表紙データが仮完成しました。 「仮」と言っているのは、ページ数が確定するまでは背表紙の幅が決まらないからです。

「表紙データ」とは、正確に言うと「表紙+背表紙+裏表紙」が合わさったPSD形式のデータです。 そして考えれば当たり前ですが、「背表紙」は本の厚さに応じてその幅が変わります。 つまり、本文のページ数が決まらない限りは、表紙データを確定させることができないのです(!)

f:id:jumpei_ikegami:20181007205715p:plain

18日前: ページ数の確定 & 表紙データ完成

締切2日前にして、まだ付録原稿ができていませんでした。 しかし、デザイナーの作業可能時間を考えると、ページ数を確定させて表紙データをfixさせる必要がありました。 ページ数自体は後で調整が聞くので、「えいや」で表紙込み100ページに確定させました。

背表紙の幅(背幅)の計算方法は、以下です。

  • 表紙込みページ数 * 本文用紙の厚さ

「表紙込みページ数」とは、紙の枚数ではなく、言葉通り「ページ数」です。 たとえば『完全SIer脱出マニュアル』は本文のページ番号が96までありましたが、そのときの表紙込みページ数は「表紙+表紙裏+裏表紙+裏表紙裏」の4ページを足して、100ページです。

「本文用紙の厚さ」は紙の種類に依ります。こだわらなければ日光企画さんの「上質90kg」になるので、0.063mmです。 各紙の厚さは、日光企画さんのトンボテンプレートのページに記載があります。

つまり、表紙込み100ページの場合、背幅は6.3mmです。 これをデザイナーに伝えて、表紙データをfixしました。 「レイヤーの統合」や「文字のアウトライン化」を忘れずにしてもらいましょう。

実際に日光企画で入稿実績のあるPSDファイルを公開するので、参考にしてください。

「完全SIer脱出マニュアル」表紙データ

17日前: 付録の草稿が完成

入稿〆切前日に付録の草稿が完成しました。 あとは付録の校正と、全体の編集作業を完了して、入稿するだけです。

16日前: 20%OFF締切 & 怒涛の入稿日!

いよいよ、自分たちで設定した入稿締切日です。 本日の18:00までに日光企画お茶の水店に原稿を持ち込めば、20%OFFを勝ち取れます。

最後の編集作業

入稿前に、最終校正を実施します。 全体を通じた表記揺れをエディタで一括置換したりしました。

参考までに、僕が置換した表記揺れは以下でした。

最も重要な作業は、ページ数の調整です。 印刷の都合上、ページ数を4の倍数に調整する必要があります。

僕たちは本文ページ数を96ページに設定したのですが、この時点ではページ数が足りませんでした。 読みやすさの観点も踏まえて、以下の方法で水増ししました。

  • コラムの挿入
  • 改ページの挿入

コラムを挿入するには、以下を記述します。

====[column] コラムのタイトル

コラムの本文

====[/column]

改ページを挿入するには、以下を記述します。

//embed[latex]{
\clearpage
//}

PDFをビルドし、ページ数が問題なくなれば、以下を実施します。

  • フォントの埋め込み
  • PDF/X形式への変換

PDF/X形式への変換については、「技術書をかこう! ~はじめてのRe:VIEW~」に詳しく書いてあるのでそちらをご覧ください。 この本にあるように、PDF/Xの出力にはAdobe Acrobat Pro DCが必要です。 無料体験版でも特に問題ありません。

「フォントの埋め込み」についても書かれていますが、vvakame/docker-reviewがデフォルトでやってくれていました。神。

入稿

本文データ(PDF/X)と表紙データ(PSD)をUSBメモリに入れて、日光企画お茶の水店さんに行きました。

店舗に行く

日光企画お茶の水店さんは同人グッズの工房も提供していて、同人誌入稿窓口と同じ場所にあります。 わいわい同人グッズを作っている人達の横で、「同人誌の入稿に来ました」と告げましょう。

  • 予約は不要です
    • 唐突に来店しても、優しく対応してくれます
    • 営業日や営業時間は結構変則的なので、必ず公式ホームページで確認しましょう
  • 所要時間は約30分間でした
    • 僕は14:15に行って、14:40には手続きを終えて外に出ました
  • その間に同人誌入稿の手続きをしていた人は僕だけでした。割と空いてる

印刷申込書の記入

作成する同人誌について、店員さんがヒアリングしながらテキパキと「印刷申込書」を埋めてくれます。 連絡先とイベント情報だけは、店員さんがデータチェックをしている間にこちらで記入しました。

印刷申込書に記載される内容は、以下でした。

  • 全般
    • 書籍タイトル: 完全SIer脱出マニュアル
    • サイズ: B5
    • 表紙込みページ数: 100ページ
    • 印刷部数: 200冊
    • トジ方向: 左トジ
    • トジ種類: 平トジ(固定)
  • 表紙
    • 用紙: NPホワイト200kg
    • PP加工: マット加工
    • 作成環境(表紙): MacでIllustrator→PSD出力
    • 作成環境(本文): PDF/X
  • 本文
    • 用紙: 上質90kg
    • 作成環境: MacでPDF/X出力
  • 搬入
    • イベント名: 技術書典5
    • 会場名: 池袋サンシャインシティ2F展示ホールD
    • スペースNo: お27
    • サークル名: しがないラジオ
    • 全部搬入?: 200冊全部搬入
  • 連絡先
    • 氏名
    • 電話番号
    • メールアドレス
    • 住所
  • その他

だいたいは即答できましたが、 表紙データと本文データの作成環境については、訊かれると思っていなかったので曖昧になってしまいました。 特に深くは訊かれませんでしたが、念のためAdobe Photoshopバージョン番号などを控えておきましょう。

窓口には紙や印刷のサンプルが置いてあり、その場で触らせてくれました。それをふまえて用紙やPP加工について決めていきます。

PP加工というのは「ポリプロピレン加工」のことで、表紙の表面をコーティングする加工方法です。 一番安いものでいいかと思っていましたが、 マット加工の艶消し感が好みだったので、その場で心変わりしました。 マット加工への変更は+5円/冊だったので、200部でも1,000円しか変わりませんでした。

表紙データは、特に何も言われず問題なし。

本文データについては、以下を指摘されました。

  • 目次や本文のリンク部分の色が、もともと赤いのをグレースケールにしたので、色が薄い
  • 目次直後のページだけ、ノンブル(ページ番号)が無い
    • 「隠しノンブルにしておきますね」と言われた。製本すると隠れる部分にページ番号を振るという意味っぽい

通常料金は8.7万円くらいでしたが、以下の割引が効いて6.3万円くらいになりました。

2.4万円の割引は破格なので、確実に利用しましょう。

なおpixivプレミアム会員特典割引は、スマホでpixivのマイページを開いてみせればOKです。 URLパスの末尾に表示されるIDを控えられます。

最後にお金を現金で払って、印刷申込書の控えと領収証を受け取って終了です。 「お客様の名前で領収証を切って大丈夫ですか?」と言われたので、会社名で発行する人もいるのかも。 最後に飴をくれました。さすが優しいと評判の日光企画さん

なお、日光企画の技術書典5新刊では、特典でポストカード(本の発行部数と同じ枚数) or A2ポスター(1枚)が無料で印刷できたようです。 僕は当日知ったのですが、A2ポスターもお願いすればよかったと後悔しました。

f:id:jumpei_ikegami:20181008073001p:plain

7日前: ダウンロードカードの入稿

QRコードの生成

ダウンロードカードの作成にはPDF版書籍データをダウンロードできるQRコードが必要です。 僕たちはPDFに加えてポッドキャストの限定エピソードも配布したので、そっちのQRコードも生成&印刷しました。

複数ダウンロードを防ぐならシリアルコードを生成してごにょごにょやった方がいいですが、 めんどくさいので僕はGoogle Driveにアップロードして共有URLを生成しました。

URLをQRコードに変換するWebサービスはたくさんあるので、適当にQRコード画像化します。

なお、Google Drive内のデータを後から更新する場合は、必ず「同名のファイルをアップロードし、既存ファイルを上書き」します。 既存ファイルを削除してからアップロードすると、共有URLが別のものになってしまうので、QRコードがリンク切れします。 これも本来は自分が持っているドメインDNS設定をちゃんとやった方がいいですが、まあ気にしない。

ちなみに、Google Driveは大量のリクエストが来ると一時的にダウンロード禁止になったりするので注意です。僕たちもイベント直後は一時的にダウンロード制限されたようです。

AWSをはじめよう」のmochikoさんは、BOOTHでパスワード付きzipを無料配布し、パスワードをダウンロードカードに印刷して配布しているようです。アクセスが集中するようなら、この方法が良さそう。

mochikoastech.booth.pm

ダウンロードカードの印刷依頼

ダウンロードカード用の画像データを入稿します。 基本的には事前に自宅で受け取るので、イベント当日までに宅配を受け取れないと涙目です。なるべく早めに入稿しましょう。 もっと早くてもよかった。

ダウンロードカードを印刷する印刷所はどこでもOKです。 僕はザッと調べた限り一番安そうだった東京カラー印刷さんの名刺・ショップカード印刷を利用しました。

サイトにIllustrator形式のテンプレートがあるのでそれを利用して入稿データを作成しWeb入稿します。 文字のアウトライン化を忘れて一度差し戻しになったので、注意しましょう。

名刺サイズで1,000枚両面印刷すると、2円/枚くらいで印刷してくれて、1週間くらいで宅配されます。 100枚しか刷らないと10円/枚くらいするので、できるだけたくさん刷りましょう。

紙質は値段相応といった感じでしたが、いい感じに印刷できました。

6日前: 通常料金締切

本文データの入稿締め切りです。 なお、表紙データの通常締切は1日早かったみたいなので、注意してください。

ここから、入稿が1日遅れる毎に大幅な料金アップが始まります。 ご利用は計画的に。

  • 5日前: 10%UP締切
  • 4日前: 15%UP締切
  • 3日前: 20%UP締切

2日前: 直前準備

イベント直前の休日を使って、イベント当日の準備をしました。

電子書籍版PDFの生成

ダウンロードカードやBOOTHへの登録に使う、電子書籍版のPDFを生成します。 こんなにギリギリである必要は無いですが、逆にいえば当日までは電子書籍版であれば直せます。

「技術書をかこう! ~はじめてのRe:VIEW~」に書いてある通り、電子書籍版の生成作業をします。 電子書籍版のブランチを作って作業するのが良さげ。

  • /articles/config.ymlを編集します。
# LaTeX用のスタイルファイル(styディレクトリ以下に置くこと)
# texstyle: reviewmacro
# tatsumacroは、電子書籍版の制作に利用する
texstyle: tatsumacro
# texstyle: techbooster-doujin

#
# LaTeX用のdocumentclassを指定する
# tatsumacro利用の場合はこちら
texdocumentclass: ["jsbook", "oneside,14pt,uplatex"]
# TechBoosterの指定は次の通り
# texdocumentclass: ["jsbook", "b5j,twoside,openany,uplatex"]
  • /articles/layout.tex.erbをリネームして無効化します

こうすると書籍入稿用PDFに特有の余白が減り、1ページあたりの文字数が増えます。

あとは以下の作業をします。

  • 改ページなど紙版特有の記述を削除
    • ページ数の制約は無いので、入稿用に追加した改ページなどを適宜消します
  • PDF出力したファイルをAdobe AcrobatのPDF編集モードで開き、空ページを最初と最後に足す
  • 表紙と裏表紙のpngデータを、その空ページに貼り付ける
    • config.yml内で表紙画像を指定できますが、裏表紙がtexでややこしかったので、PDFを直接編集しました。PDFは作れる!

以上で、それっぽいPDFが生成できます。

なお、「技術書をかこう! ~はじめてのRe:VIEW~」に書いてないけどハマったポイントも、いくつかありました。

  • 電子書籍版で出力すると、なぜかフォントが太くなる
    • 詳しい状況やとりあえずの解決方法は以下のtweetをご覧ください

  • config.ymlのtoclevelの指定が、入稿版と電子書籍版で1段変わる気がする
    • マジで謎
  • 電子書籍版で出力すると、B5ではなくA4になる
    • 仕様かもしれないですが、表紙データのサイズを間違えて作り直してもらった

以上です。TeXつらい。

POPやポスターの準備

当日の設営に使うPOPやポスターを用意しました。 本の内容がどんなによくてもブースの見栄えが悪いと目立たないので、「それっぽさ」を演出しましょう。

買うもの

  • カード立て ×10個
    • 紙全体を包むタイプの方が、ペラペラの紙でもそれっぽく見える

  • ポスタースタンド ×1個
    • 折りたたむとめっちゃコンパクトで素晴らしい
    • クリップタイプのPOPスタンドとセットで買った

  • テーブルクロス ×1枚
    • ブースの机サイズを要確認
    • だいたい1m * 1mあれば大丈夫

  • 集金袋 ×10個
    • お札を10万円セットにして数えるために、多めに買いました
    • 700円など端数がある場合は、コインケースも買いましょう

  • 見本誌用ブックスタンド
    • 僕は自宅で使っていたものを持っていきました

actto BST-02 ブックスタンド(OEM品番:EDH-004)

actto BST-02 ブックスタンド(OEM品番:EDH-004)

他には、アカウント情報を印刷したネームカードを入れるネックストラップなどを準備しました。別に無くてもいい。

印刷したもの

こだわらなければ、コンビニ印刷で大丈夫です。 紙を選んだり大量に印刷したりする場合は、kinko'sなどを使いましょう。

www.kinkos.co.jp

僕が刷ったのは以下です。

  • A3ポスター ×3枚
    • 前述のように、日光企画さんでA2ポスターを1枚刷ってもらってもよかった
    • 2枚は机の前に、1枚はポスタースタンドに設置
  • 値札系(カード立てに入れるやつ)
    • 物理本の値札
    • ダウンロードカードの値札
    • 「写真OK!ハッシュタグでツイートしてね」
    • 「ご自由にお持ちください」
      • 無料で配る名刺とかシールとかがある場合
  • POP系(クリップで挟むやつ)
    • 「見本誌:お気軽にお読みください」
    • ブース番号表示

コンビニ印刷のデフォルト設定だと、データ上のサイズより少し小さく印刷されるという問題がありました。 詳しくは以下の記事を参照。

yarnyarnyarn.hatenadiary.com

設営リハーサル

当日の設営で慌てなくてもいいように、余裕があれば自宅の机で設営リハーサルをしてみましょう。

ブログ&ツイートで宣伝する

自分のブログがある場合は、本の内容や執筆裏話などを記事にまとめて公開しましょう。

jumpei-ikegami.hatenablog.com

技術書典に来る一般参加者の目にとまるように、#技術書典でツイートするとよいです。

0日前: 技術書典5当日!

あとは当日を楽しむだけです!お疲れ様でした! 余裕があればTwitterで本の宣伝をしたり売れ行きを実況したりすると楽しいです。

やること概要

  • サークル入場時間中に会場入りする
    • 運営の準備が早く終わると、早く入場できることがある
  • 自分のブースを探す
  • 本が届いていること&印刷に問題ないことを確認する
  • ブースの設営をする
  • 開場後は、がんばって売る
    • 売り子は自分含めて2人以上いないとトイレも行けなくて死ぬ
  • 閉場後、ブースの撤去をする
    • 段ボールは運営さんが回収してくれた
  • 非公式打ち上げがあったりするので、気が向いたら参加する

当日の詳細は、以下のブログ記事をご覧ください。

jumpei-ikegami.hatenablog.com

反省点

今から振り返って、「こうしておけばよかった」という反省点を列挙します。

印刷について

  • 「目次直後のページにノンブルが無い問題」を解消できなかった
    • まあ隠しノンブル入れてくれたので大丈夫
  • 「PDF内のリンクが赤い問題」を解消できなかった
    • 以下のリンクに詳しい

qiita.com

イベント当日について

  • オンライン決済に対応すればよかった
    • めっちゃ簡単に対応できるもよう

blog.techbookfest.org

  • 見本誌を多めに用意すればよかった
    • 混んでくると、1冊じゃ足りなかった

まとめ

以上、技術書典にサークル参加するまでにやった作業の全貌でした。

この記事でサークル参加のハードルが下がったと思うので、気軽にサークル参加しましょう〜。

また、いろんな参考記事があった方がいいので、ぜひ本記事のような作業振り返りブログを書いてみてください。

#完全SIer脱出マニュアル が #技術書典 5から1週間で800部も売れて心底驚いている

f:id:jumpei_ikegami:20180922182207p:plain

こんにちは、gamiと申します。

2018年10月8日(月)に開催された技術書典5に軽い気持ちで初サークル参加しました。

techbookfest.org

結果、オンライン購入も含めて1週間で800部も売れたので、驚いてブログを書いてます。 別に売れた本が良い本という訳でも無いですが、「こんなに需要があったのか!」という感じです。

頒布した本は、『完全SIer脱出マニュアル』という、なんとも燃えそうなタイトルの本です。今でもPDF版はダウンロード購入できます。

booth.pm

本の内容や本を出すまでの経緯は、以下のブログに書いたのでぜひご覧ください。

jumpei-ikegami.hatenablog.com

事前の準備

紙の本は200部刷った

技術書典では、Webサイト上でサークルを「チェック」することができます。 さらにサークル側は、自サークルの被チェック数を見ることができ、どのくらい本が売れそうかを事前に知ることができます。

紙の本を入稿したのは、技術書典の約2週間前でした。 この時点の被チェック数は86だったので、直前の伸びも勘案すると200部は売れるやろという感じで部数を決めます。

もともと僕たちのサークルは「しがないラジオ」というポッドキャストをやっていて、1エピソードあたりの再生回数は1,500くらいあるので、その点では認知度的にけっこう有利だったと思います。 ポッドキャストでもこの本の宣伝をしました。

ep.32 楽しいVue.js入門と完全SIer脱出マニュアル | しがないラジオ

ダウンロードカードは1,000部印刷

技術書典では、紙の本が売り切れた場合に備えて、ダウンロードカードを用意するのが一般的です。 QRコードが印刷された紙で、そのURLからPDFをダウンロードできます。

前回の技術書典4では、知っているサークルの人が「ダウンロードカードが足りなくなってコンビニで印刷した」と言っていたので、絶対に無くならない数を刷ろうと1,000部印刷しました。

印刷費用でいうと一枚2円くらいなので、余ったら捨てればいいかーくらいの気持ちで刷れました。

技術書典5当日以降

被チェック数

技術書典前日には、被チェック数が更新する度に爆上がりしていました。 僕がTweetした値を振り返ると、以下のような上がり方です。やばい。

  • 前日
    • 09:44 → 247
    • 22:02 → 306
  • 当日
    • 05:03 → 388

この時点で、「紙の本は確実に売り切れるな」と確信します。

ちなみに当日は、楽しみすぎて朝5時に起きて池袋に向かいました。遠足の日の小学生か。

ブース設営

当日のサークル入場は10:00からの予定でしたが、運営の準備が早く終わったらしく、9:31には入場開始してました。

ブースの設営は、事前に自宅で一人リハーサルをしていたので、バッチリでした。

特に机に敷く黒い布が、怪しい高級感を演出してた気がします。買って良かった。

開場!

予定通り、11:00に一般参加者の入場が始まりました。

開場を告げるアナウンスが流れ、サークル参加者が立ち上がって拍手をします。 「これ、げんしけんで読んだやつだ!」と、一人で感動してました。 あの拍手するやつ、すごい楽しいのでぜひサークル参加しましょう。

開始1時間で紙版200部が完売

開場して少しすると、人がすごい勢いで歩いてきました。 事前にチェックしてくれていた人が、口々に「1冊ください」と告げてきます。 僕と相方のzuckeyは、本を売るマシーンと化しました。

結果、12:00直前には紙の本200部が完売します。

最初の1時間は、20秒に1冊以上のペースで売れたことになります。 流石にこんなに早く売り切れるとは思わなかった。

この1時間は、本の執筆やこれまでの「しがないラジオ」の配信で苦労したことがすべて報われていくような、ものすごい多幸感に包まれていました。 脳内物質がドバドバ出てきて、正直泣きそうでした。 生きてて良かった。

ダウンロードカード版の販売に切り替え

紙の本を置いていたスペースに「紙版は完売しました」と走り書きした紙をおいて、ダウンロードカード版を売り始めました。 この時点では、コンテンツが重要とはいえこんなペラッペラな紙を買ってくれる人が本当にいるんだろうか、と不安でした。

蓋を開けてみると、時間帯もあって勢いは落ちてきましたが、コンスタントに売れていきました。

売り子2人体制だったので、14:00頃まではほとんど休めず、やっと昼食にありつけました。 COMPはいいぞ。

お客さんとの会話を楽しむ余裕がでてきた

14:00以降は人の波もだいぶ落ちついてきました。

ブースに置いてある見本誌を目の前で立ち読みしてくれる人もたくさんいて、「もしこの人がSIerの偉い人で、急に殴りかかってきたらどうしよう」とビクビクしながら見守っていました。 もちろんそんなことはなかったです。

中には「自分と状況が近すぎて泣きそうです」とか、「僕はもう脱出しました」とか、「友人にお土産として買って帰ります」とか、話しかけてくれる人もいました。 実際に交流ができるのが、技術書典のようなリアルイベントの醍醐味だなあと感じました。

ポッドキャストのリスナーさんもたくさん来てくれたので、ホクホクでした。

また、タイトルがタイトルなだけに、弊サークルのポスターを見ながらクスクス話している通りがかりの人がとても多かったです。 ネタとしての話題性の高さを感じました。

当日は、合計500部を売上!

最終的には、ダウンロードカードもなんと紙の本の部数を超える約300枚を売り上げました。 12:00-17:00の5時間で、1枚/分のペースで売れたことになります。 1,000枚刷ったので枚数としては余裕でしたが、本気でびっくりでした。

紙版と合わせると、約500部を売り上げたことになります。

BOOTHでオンライン販売を開始

17:00-18:00の撤去作業中に、BOOTHでPDF版のオンライン販売を開始しました。 事前にショップ設定はしておいたので、公開設定をするだけでした。

当日夜は知り合いのサークル参加者のみなさんと非公式打ち上げに参加したのですが、 その最中もBOOTHからの「商品が購入されました」というメール通知がバシバシ届きました。

だんだんと、「これはすごい本を生み出してしまったかもしれない」という実感が湧いてきます。

技術書典5から1週間経って

技術書典5から1週間たった2018年10月15日8:36現在で、BOOTHでの売上部数は298冊です。 当日の売上と合わせると、合計で800部を売り上げたことになります。冷静にやばい。

また、Twitterハッシュタグ"#完全SIer脱出マニュアル"で感想をつぶやいてくれる人も多く、そのTweetがきっかけで他の人が買ってくれたりしているみたいです。 中にはブログまで書いてくれる人もいて、執筆者冥利に尽きます。

感想Tweetは、togetterにまとめたのでぜひご覧ください。 「本に書いてあるアクションを、実際にやってみました!」というTweetも多く、仕事で悩んでいる人の背中を押せたことが、ただただ嬉しいです。

togetter.com

まとめ

技術書典へのサークル参加は初めてでしたが、自分が苦労して書いた本が目の前で売れていく光景は、思っていたよりずっとずっと素晴らしい体験でした。 サークル参加できる人は、ぜひ体験してみた方がいいです。

加えて、オンライン販売の部数が伸びていることが、とても嬉しいです。 この本の一番の対象読者は、「SIerやSES企業でSEや開発をしていて、毎週⽉曜⽇の朝に仕事に⾏くのがつらい⼈」です。 ただし、本のあとがきにも書いた通り、「この本を⼼から必要としているような⼈は、技術書典などというリア充エンジニアたちが集まるイベントには来ない」と思っていました。 なので、当日の売上に匹敵するくらいの部数が「イベントに来なかった人」に届いたという事実が、この本を書いた思いからすると僕にとっては一番重要です。

まだ『完全SIer脱出マニュアル』を読んでない人がいたら、お近くの人に借りるか、よければ買ってください。 そして、この本を読んだ方がいいような知り合いがいたら、ぜひ貸してあげてください。 私的利用の範疇で一般公開しないのであれば、PDF版であっても送信していただいて構いません。 「楽しく働くエンジニア」を増やすために、ぜひよろしくお願いします。

booth.pm