ISMS取得たいへんという話
pyspa Advent Calendar 2024、2日目の記事です。
1日目は id:cco さんの 赤ちゃんが生まれてやってよかったこと・あってよかったもの - unnamed でした。
3日目は id:rokujyouhitoma さんの 情報処理安全確保支援士登録・登録後の脇道 - rokujyouhitoma's blog です。
ISMSをとるぞ！
ぼちぼち転職して1年になります。会社もめでたく9月で設立1周年を迎えました。 社員番号2番で入社したのですが、ぼちぼち会社の人数も30人くらいになって、すごく会社っぽくなってきました。 とはいえ、やりたいこと、解決したい課題は山程あるけど人がぜんぜん足りたいという状況。採用につなげるための会社のブログも立ち上がったりして、私も社員紹介という形で1記事書かせてもらいました。
そんな感じで、急速に会社らしくなってきているのではありますが、会社の制度や仕組みはまだまだ作っている最中です。仕組みづくりの一環として「ISMSをとるぞ！」という事になりました。 社のブログで、私の仕事のうちの40%くらいは情シス作業につかっていると書いたのですが、さらにその半分くらいはこのISMS取得に時間をかけました。
情報系の会社にお勤めの皆さんはISMSは聞いたことあったり、年一で研修を受けたりしていると思います。 まぁ、でも、実際のところ「やれ」と言われて研修を受けたりしている程度で、どういう資格なのか、どうやって認証を受けるのかなどはほとんどの人が知らないのではないでしょうか。
今回、会社でISMSの認証取得のため、主担当として作業をしてきた経験をここで紹介したいと思います。
まだ、認証は取れていなくて1月に第２回の審査を受ける予定なので、それが終わるまでは気が抜けない毎日です……。
ISMSとは
ISMS (Information Security Management System / 情報セキュリティマネジメントシステム) とは JIS Q 27001 という規格に定められた、企業における総合的な情報セキュリティの管理運用体制に関する認証資格です。
情報マネジメントシステム認定センターの説明を引用します。
近年、ITシステムやネットワークは社会インフラとして不可欠なものとなっているが、一方で標的型攻撃やランサムウェアなどによる被害・影響も多発している。こうした中、これらの脅威に対して適切にリスクアセスメントを実施して、企業における総合的な情報セキュリティを確保するためには、ISMSの構築・運用が必須事項となっている。
ISMSとは、個別の問題毎の技術対策の他に、組織のマネジメントとして、自らのリスクアセスメントにより必要なセキュリティレベルを決め、プランを持ち、資源を配分して、システムを運用することである。
ISMSが達成すべきことは、リスクマネジメントプロセスを適用することによって情報の機密性、完全性及び可用性をバランス良く維持・改善し、リスクを適切に管理しているという信頼を利害関係者に与えることにある。そのためには、ISMSを、組織のプロセス及びマネジメント構造全体の一部とし、かつ、その中に組み込むことが重要である。
ここでいう情報セキュリティとは、例えば以下のようなものがあります。
- 会社のパソコンの管理方法
- オフィスへの入室の方法
- USBメモリの管理方法
- サーバのログの管理方法
- などなど
というような感じで、非常に広い範囲のセキュリティの話をしています。
さらに、やり方を決めて終わりではなく、「決めたことが有効に作用しているか」「新たなリスクはないか」「実情にあってないものがないか」などを洗い出し、改善していく、PDCAの回し方自体もISMSの中で取り決めていきます。
つまり、ISMSは取得がゴールではなく、取得したら常にPDCAを回して洗練してくことが求められる、結構ハードな認証資格なのです。
ISMSはどうやって取得するの？
ISMSの取得は認証機関による審査を受け、それに合格する必要があります。しかし、まぁ、30人くらいしかいない会社にISMSの規格について熟知している人がいようはずもありません。全て自分たちで準備して認証を受けるなど不可能です。 当社の法務担当は弁護士資格をもった弁護士なのですが、弁護士のパワーを持ってしても独力での取得は不可能です。
というわけで、ISMSの取得のコンサル会社があり、そこに支援をお願いすることにしました。
私達がお願いしたコンサル会社では、ISMSの取得に必要なドキュメントの雛形が一揃用意してあり、それを当社に合わせた形でカスタマイズしていく……というのがISMS取得までの作業です。
当社の場合、基本的には３つの文書を中心にISMSを構築していきました。「セキュリティハンドブック」「情報セキュリティマニュアル」「マネジメントシステムマニュアル」の3つです。
なぁんだ3つだけか、簡単やんと思ったら大間違い。これらに付随して、例えば「アカウント管理表」「USBメモリ貸出台帳」「情報資産管理台帳」などなどの様々な台帳やドキュメントの整備がやってきます。また、これらで決めたことを全社に普及させていく必要もあり、この普及、教育が一番頭を悩ませる部分となるのでした。
基本の3文書をつくるのが大変だった……。
基本の3文章はそれぞれ、表紙や目次もいれて20ページにもみたない分量なのですが、これを作るのが大変でした。
雛形を元に、コンサルの方を毎週読み合わせを行いながら、当社とマッチしない部分を当社のものに書き換え、実際に運用できそうかを検討する……。ということを延々とやっていました。雛形自体がオンプレのサーバを持っていることが前提になっていたり、いま当社が入居しているWeWorkのようなシェアオフィスを想定していなかったりするので、そういった部分を適切な形に書き換えたり。オフィスの要件として監視カメラの設置や入退室の履歴、非常食の備蓄などについての記述があったりするのですが、そういった部分は持ち帰ってWeWorkのコミュニティマネージャーに問い合わせたりすることもありました。(WeWorkは慣れたもので「ISMSの取得で……」というと必要な情報をぽんぽんだしてくれて非常に助かりました)
基本の3文書も「こうしなさい」というわけではなくて「あなたの会社にあった方法に書き換えてください」というものだったので、非常に柔軟にできたのは良かったです。
よく「会社の決まりでこうなってるから〜〜」と、不合理な作業をしないといけないことになるという話は耳にしますが、ある程度の"幅"をもって運用で柔軟に対処できるような取り決めになったのではないかなぁと思っています。
広めるのが大変
さて、文書が完成し、ISMSの体制が整ったら、次はこれを広める作業です。これは正直、うまくいってない。
普段仕事をする上で知っておかなければならないルールや決まり、連絡先などは「セキュリティハンドブック」にまとめてあります。14ページ程度のドキュメントです。 最初はこれをパワポに内容まとめて会社に発出しようかとおもったのですが、14ページといっても見出しとかが多くて文章は少ないし、このまま出してええやろと思って「読んでおいてね」でアナウンスしました。
が、これ多分、ほとんどの人が読んでねぇや……。
やはり、文字がたくさん書いてあるPDFなんてどんなに内容が薄くて簡単でも誰も読まん。面倒でもイラストやのイラストをふんだんに使ってパワポにまとめて発出しないと誰も読んでくれない。
がんばって作ったものを誰も読んでくれないのは悲しい……。ましてや今後これを運用して、より洗練させていく必要があるわけです。
読め！ という業務命令を無視してるやつが悪いということは簡単ですが、伝える努力を怠った私の落ち度も大きい。ちゃんと広め、伝えていく、これは今後の課題です。
とはいえ、1月には第2段階審査が待ち受けており、そこでは偉い人なんかも審査対象なので、偉い人向けに噛み砕いたわかりやすい資料をさっさと作らねばならない……。
審査が大変！
すでに第一段階審査は終了し、こちらは軽微な指摘事項だけでなんとかパスしました。
審査員は初老の感じのいい紳士でもとは銀行でシステム周りをやられていたという方でした (フラグ)
第一段階審査は、こちらが準備したドキュメントが規格を満たしているかどうかを確認していきます。規格の番号とそれに対応するドキュメントを、一つづつ確認していくという作業です。
その中で、システム運用にまつわる項目を審査しているときに
- 審査員「運用と開発は明確に分けなくていいのですか？」
- hidesuke「いまはDevOpsという考え方があって」
- 審査員「ライブラリアンなどは置かないのですか？」
＿人人人人人人人人人＿ ＞ ライブラリアン ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
私が社会人になった20年前にはすでにほぼ絶滅していた職業の名前をまさか審査のなかで「置かないか？」と提案されるとは思ってもみませんでした。やー、歴史ですね。
運用が大変
まとめ
というわけで、ISMSの準備という稀有な経験をしたのでここで紹介しました。
大変ではあったのだけれども、いろいろ必要な"決め"が足りていないできたばっかりので会社で、情報セキュリティに関するルールや考え方が急速に整備できたので、ISMSの取得というのはよかったと思います。自前でここまでのことをするのはなかなかに難しいし、一部考え方が古くなっている部分はあるにせよ、規格化されているので、論点はよく整備されており、高速に仕組みをつくるのには丁度よかったと思います。
最後に宣伝ですが、まだまだやらないといけないことはなんでもやるフェーズの当社、全職種積極採用中です。
社会課題の解決に興味のある方は是非お声掛けください！ もちろん、カジュアル面談からやっています！
Theoria technologies | 認知症との向き合い方を、テクノロジーで変えていく。
是非、お問い合わせください！
それでは、よい年末を
Theoria technologiesに入社しました！
転職しました！
2024年2月1日より、Theoria technologies に転職しました!
Theoria technologiesは製薬会社のエーザイの100%子会社で、認知症エコシステムの構築を目指す会社です。
2023年の9月にできたばかりの会社で、同じ日に入社したCTOが正社員1人目、私が2人目。他の人はエーザイからの出向者で、合わせて5人という出来立てホヤホヤの会社です。 Theoria technologiesにはTechLeadという肩書で入社するのですが、人数が少ないこともあり、やらないといけないこともたくさんあるので、持ち前の高機能雑用っぷりを最大限発揮しながら走っていこうと思います。
もちろん、一緒に働く仲間を大募集中なので、気になる方はぜひ声をかけてください！ 文化や仕組みはもちろん、本当に会社を作っていくところからというフェーズで本当になかなか経験できない経験ができること間違いなしです。
前職の振り返り
Oh, 前回のポストから4年の歳月が……。
前回のポストのときはまだサービス開発の課長でしたが、その後AIの部署含めた技術部隊の全体の部長、執行役員VPoE、技術部隊をAIとサービス開発に別けてのサービス開発側の部長、プラットフォームエンジニアリング部隊の部長兼情シス課長兼新規プロダクトのBizDev部長と様々なロールを経験しました。一貫してマネージメントロールを行い、もう3、４年はコードも書いてない状態です。もともと課題解決が好きでコードを書くことにそこまで重きをおいていないのでそこは別に問題ないです。 ピープルマネージメントの面白さ、難しさを感じながらいろいろなことにチャレンジする経験を積ませてもらいました。
一般的にはEngineering Managerと呼ばれるロールだとは思うのですが、ピープルマネージメントが主な仕事でした。
あまり、技術部隊の部長のようなアッパーレイヤーのマネージメントの仕事って、イメージがつかないことが多いかと思いますので、せっかくなので私が前職でどういったことをしていたか振り返ってみたいと思います。
管理職の仕事は意思決定。腹くくってGo / No Goを決めまくる
部長の仕事はいろいろあるのですが、全てに共通するのは意思決定という部分だと思います。自分より上がもう役員しかいないので、どんなにわからなくてもどんなに決断を先延ばししたくても、決断しないと物事が進まないことが山程やってきます。それをどんどん決断していくのが部長の仕事です。 部長じゃなくても管理職はだれでも意思決定というのは重要な仕事なんだけれども、執行側の最後の意思決定者ということで、誰にもお伺いたてられない状態で腹くくって意思決定をするというのが部長と中間管理職の違いです。 部長の上には当然役員などがいるのですが、役員への意思決定を問う場合は「どうすればいいですか？」ではなく「こうしたいのでやらせてください！ (YES/NO)」という形で部長から上程することになります。なので、部長の部分でしっかり腹落ちして腹くくって意思決定をする必要があります。 意思決定をするということは、それに対して責任を取るということなので、その責任を取る準備と覚悟とくそ度胸がついたと思います。
意思決定が根本的に必要な仕事として、もう少し具体的な仕事としては部下の目標設定(と評価)と予算策定に非常に多くの時間を使ってきました。
エンジニアの評価の基本は「自分がどう評価されたいか表明すること」
私はいままでMBO (Management by Objectives 目標管理制度) で目標設定をする会社でしか働いたことがありません。よってMBOによるエンジニア評価をやってきました。
エンジニアの評価は難しいとよく言われますが、確かに難しいのですが、自己評価と会社からの評価に乖離があるときの大抵の場合はただのすり合わせ不足であると思います。 被評価者が「自分は頑張っても評価されない」「給料があがらない」と思うとき、考えて欲しいのは「自分がどう評価されたいか表明していますか？」という点です。 技術力で評価されたい、仕事をたくさんこなしたことを評価されたい、リーダーをこなせるようになったことを評価されたい、など。重要なのは意思を示すことです。 評価というのは、いくら絶対評価を標榜しようともなにかの基準があってそこに対してどうだったかという評価がされます。 そこで、自分がどう評価されたいかを表明しておけば、それを基準に評価が行われるようになります。 漫然と「評価されたい」「給料あげたい」みたいに思っているだけでは評価はされません。具体的に表明し、上司と握る。これが目標設定に必要なことです。
まず、自分の意思を示す。その後、上司とのすり合わせを行います。自分がどうなりたいかに加えて、会社があなたに何を期待しているかという部分もかならず存在し、その部分も加味して目標が出来上がります。 そこで「なになにを達成したら評価はS」みたいなクライテリアを定義し、上司と握ることで納得のいく評価がされるようになるでしょう。 (また、言い逃れはできなくなるので容赦なく低い評価がつくことにもなります)
はー、面倒くさいな大変だな。大変だけれどもこれがめちゃめちゃ重要です。 目標設定が完了した時点でその年の評価はほとんど決まっているようなものですし、逆に言うと昇給昇進にとって目標設定が非常に重要です。 上司の仕事って究極的には部下の給料を上げることだと思っています。 なので、部下の目標設定についてはめちゃくちゃ時間をかけました。多い人では目標がfixするまで7回くらい面談をしてすり合わせをすることもありました。そして見ている配下全員と面談し目標をfixするということをやっていました。
予算策定もしくは人員計画
ソフトウェアエンジニアリングの世界では、支出のほとんどが人件費です。なので、予算策定 = 人員計画と言っても過言ではありません。 前職はAIの受託開発をメインのビジネスとしていたので、その年の目標売上額や案件の見込み昨年からの傾向その他諸々を元ネタとして今年どれくらいの人数が必要なのかという計画を作っていくことになります。 とは言っても、どこまでも予想ですし、わからんものはわからんので、何パターンも仮定を設定し、いろんな角度から検算をして一番それっぽい数値をはじき出して人員計画を立てるという作業をしていました。 言葉に書いてしまうとほんの数行ではあるのですが、延々とSpreadSheetとにらめっこしあーでもないこーでもない言ったり、上司(役員)と相談したり部下(課長)と相談したりしながら作業をやってました。 とにかく時間が溶ける。あとSpreadSheetをいじっていると、いまなにの計算をしていたんだっけ……本当は何をしたかったんだっけ……ということがすこーんと飛ぶことがあり、この記憶喪失に悩まされることが多々ありました。
そんな中、私を救ったのはこの一冊外資系金融のＥｘｃｅｌ作成術―表の見せ方＆財務モデルの組み方。なんか難しいことは全然書いてなくて、見やすい表はこうつくるんやとか、自分で入力した数値は青、参照は緑、計算してだした数字は黒にするんやとか。 そういうなんでもない工夫について書いてある部分がすごく役に立ちました。 これだけで、たとえ記憶喪失になろうとも、取り返しのつかない間違いを犯すことが激減したし、数値の羅列でもきちんとあとから読んで意味がわかるような書き方ができるようになり、仕事の効率が格段にあがりました。これはおすすめ。
ほかにも色々
メインで時間をつかったのは目標設定と予算策定ではあったのですが、日々の技術的な意思決定や方針決定、アーキテクチャのレビュー、文化の醸成、お小言など、いろいろなことをやって失敗したり成功したりしました。こういうマネージメントロールを任せられて、いろいろなチャレンジをし、振り返ってみると一エンジニアとして働いていては見えなかったことが見えるようになったし、経験できなかったことを経験できたし、一つ上の視座から俯瞰して物事を見て、考えるということが身についてかなぁと思っています。
そして次のチャレンジへ
前職ではサービス開発の部隊を作るというミッションで入社し、そのミッションは達成できたかなぁと思っています。 ソフトウェアエンジニアリングにおける当たり前のことを当たり前にやることができる組織を作れたと自負しています。 日々の仕事の中で、いわゆるgood practiceを取り入れ、自分たちで自分たちのやり方を改善できる。 儀式ではなく、実効性のある振り返りの習慣があり、そこから学び成長できていく。 そういったことが自然とできる、サービス開発組織を作ることができました。 AIの会社においてサービス開発の部隊がいる意味、他のSIerとの差別化みたいな部分はなかなか評価し辛いところではありますが……
というような感じで、入社時のミッションは概ね達成され、私の役割は終わったかなという点と、こういうマネージメントロールを歩んでコードを全く書かなくなったことで、次のキャリアってのが存在しないのではないか？ と思い、自分の可能性も確認する意味でBizReachに登録してみました。 BizReachってもっと企業担当者もしくは企業担当者の皮を被った業者から直接のスカウトがくるものかとCMの印象からおもっていたのですが、実際に登録してみると、転職エージェントとの出会い系サイトで、メッセージには「わたしはこういう経歴でこんだけすごい人なんですよ！ すごいでしょ！ 優秀でしょ！ 一度お話しませんか？」みたいな転職エージェントの自分自慢のメッセージが大量にくるだけなんですね。そして、そこにうっかり返信しようものなら、その転職エージェントの会社のシステムにいろいろ登録し直さないといけないという地獄が待っていて、本当に地獄。
そんな中、自己紹介あっさりめで、最初から具体的な企業名を上げてスカウトを送ってきてくれたエージェント何人かに返信し、その中の一つがTheoria technologiesでした。
事業内容は社会的意義の高い仕事であり、なんといっても大きな会社の出島として作られた会社でできたばっかりという会社のフェーズが抜群に面白いところが転職の決め手でした。 前前職ではよく「エンジョイカオス！」と言いながら仕事をしていたのですが、まさに出来立てホヤホヤのカオスがあり、社会に大きなインパクトを与えるという熱が感じられます。
Theoria Technologiesでは、マネージメントする対象がまだいないので、まずはICというかまさに高機能雑用としてエンジニアリングに関わること全部なんでもやっていくことになります。 こんな状態なのでありとあらゆる職種で人材募集中なので、すこしでも興味がある方はぜひ話を聞きに来てみてください！
おわりに
というわけで、約5年努めたAIベンチャーを退職し、出来立てホヤホヤの医療系ベンチャーに転職します。 いろいろな方にお世話になりました。 私の新しいチャレンジを応援してください！
蛇足
ご心配おかけしました
有給消化に入った途端、義父が入院したり、自分が熱出して倒れたりして、自分自身の送別会に欠席するなどいろいろ不義理を働いてしまいすみませんでした……。 私は回復し、義父も快方にむかっております。 いろいろとご心配おかけしました。
wish list
転職時恒例のAmazonのウィッシュリストをおいておきます。 個別にお礼をしたいので、お名前がわかるようにしていただけるととても助かります🙏
Findyはいいぞ
今回はタイミングなくて使わなかったのですが、キャリアに迷ったとき、転職を考えるときはFindyが本当に良いです。 Findyにはユーザサクセス面談というものがあり、Findyのユーザサクセス担当者と30分程度の面談を行うことができます。 転職活動の一貫というより、自分のキャリアの棚卸し、キャリアに関する悩み相談のような話がメインで、なにか転職先をゴリ押ししてくることもありません。 本当に、キャリアの整理という感じなので転職するつもりがなくてもユーザサクセス面談を受けてみるのはおすすめです。 そもそも転職エージェントって求職者をただの商品としか見てない人が非常におおくて、よいエージェントに巡り合うのが本当に大変。そういう意味でもFindyのユーザサクセス担当は非常に親身で気持ちが良く大変よいです。
現場からは以上です。
AIベンチャーに転職して1年たったので振り返り
気づいたら 日産自動車株式会社を退職しました！ - 名称未定ドキュメント"Que" これから1年経っていた。転職してからというもの、1週間経つのが本当に早いし、とはいえもう何年もこのメンツで働いていたように錯覚するような濃密な時間を過ごせた一年だった。
というわけでこの一年をざっくり振り返る。
ぼっち課、ボッチ課長から、気づいたら8人の課になった
僕が入った、いま勤めている会社はAI開発を行うベンチャーでメインの仕事はB2B。お客さんの悩みや要望、課題を聞いて、それをAIを用いて解決するソリューションを提供する会社だ。
とはいえ、僕が入った時点では創業2年。AI PoCがうまくいきはじめ、さて次はこのAIを使った実際のソリューション開発や！！ というところ。
僕の部署は「サービス開発課」PoCで検証したAIを利用して、実際にお客さんや更にその先のエンドユーザにAIを利用してもらうためにサービスやソリューションを提供することを目的としている部署だ。僕が入ったとどうじに作られた部署で、もちろん課員は僕一人。僕の最初の仕事は人を採ることだ。
が、入社初日からお客さんとの打ち合わせが入れられていたw 僕を待ち構えていた案件はたくさんあった！
ボッチ課だから仕方ない。とりあえず、知人に声をかけまくりつつ、社内では案件をちぎっては投げちぎっては投げしつつなんとか走り抜けた。
そうこうしてるうちに1人増え、2人増え……と気づいたら10月には8人の課になった。おかげで案件も回り始め、新しいことへも積極的にチャレンジできる体制ができてきた。
とはいえ、会社はどんどん大きくなるし、どんどん成果だしていて確実に人手が足りない！ 興味ある方はぜひ応募してほしい！ 俺たちを助けてくれ！
やってることはweb系開発がメイン！
「AIの会社は興味あるけど、AIわからんし数学わからんし」
とういう悩みはよく聞きます。実際良く聞く。
しかし、僕たちの課はほぼ全員「AI開発」したこと無い。普通のweb系だったりSIerだったりで働いて働いて、web系のものを開発してきた人ばかりです。
AI開発自体は隣の「AI開発課」がPoCや、実際にプロダクションで利用するAIの開発をしています。僕たちはそれらのAIを組み込んで、お客さんが使えるシステムを作るのが仕事。なので、僕たちの課の技術スタックとしてはPython(django, Flask), nodejs, golang, Vue(Nuxt), あと変わりどころではFlutterといったweb系界隈ではおなじみの技術をもちいて開発を行っています。
また、お客さんからの要望が特になければ、プラットフォームはGCPを利用しています。AI(特にディープラーニング)ではGPUを利用したほうが、実行速度にメリットがある場合が多いため、クラウドサービスでもGPUインスタンスを選択することがよくあります。そうした場合にAWSやAzureと比較検討した結果、GCPが圧倒的に安いことがわかったのでGCPを選択しました。
GCP使うんだったら機能を徹底的にシャブリ尽くそう！ ということでGCPの機能をシャブリ尽くそうと頑張っています。人数も多いわけではないので運用に力をかけたくない。なので、最初はCloudFunctionsを使いまくってアプリケーションを開発していたけれども、最近ではCloudRunを積極的に活用している。新しい機能はどんどん試していき、良さそうであったり、僕たちにフィットしそうであればどんどん取り入れていく。そういう体制とマインドがしっかり育っているし、そういう人材が集まってくれて本当に心強いチームになった。そういえば、気づいたらみんなGitHub Actionsもりもり書いてCI/CD回し始めたりしてたなぁ。
僕は出自がアプリ屋なのでインフラにはそこまで詳しくはないのだけれど、インフラ担当の二人は、きちんとIaC化を実践しているし、今はまだ使っていないが、今後に向けてk8sなどの技術についての調査やPoCを行ってくれている。大変に良い。また、社内のGPUサーバ郡の運用効率化とかそういった問題にも積極的に関わってくれている。
AI人材も必要なんだけれども、そういったAIを誰でも使えるようにするための技術者というのが不足していて、まさにweb系のエンジニアが活躍できる場がAIの現場にはいっぱいあるのです。なのだけれども「AI」と聞いて「うーん、僕は違うよなぁ」と思っていたそこのあなた！ 興味ある方はぜひ応募してほしい！ 俺たちを助けてくれ！
まだまだ成長フェーズ。組織と、文化を一緒に作ってくれる人募集中！
↑みたいな文句で前職も入社したのだけれども、前職は所属していた部の文化というのはある程度作れたかなぁとは思う。しかし、超巨大組織で、一定以上上になると政治の世界であった。なので、小さくまとまらざるをえなかった、という感想はある。大きなムーブメントはつくれなかった。
今の会社はどうだろう。社員数がも増えてきたとはいえ、まだまだベンチャーだ。創業期から成長期へと、フェーズが明確に変わって来ていることが組織の中にいて肌感覚として実感できる。急速に人が増えてきたこと、フェーズが急速に変化してきていることで、僕たち自身が変わっていけないと行けないという感覚は感じている。その中でエンジニアリング組織として、どういった組織になりたいのかという方向性を模索しつつ、そのための文化というものを今まさに作り上げている真っ最中だ。エンジニアリング組織だけにとどまらずに、その他の組織もどのように変化するとより成長できるのか、といった部分を模索し、いろいろ試しているというのは感じている。
まさに、この成長という変化の中で一緒にモノを作り、文化を作りっていきたい人を募集しています！
興味ある人は是非声をかけてくださいね！
今後もがんばってやっていき。
技術書典7でスクラムアンチパターン体験本「ぼくらのスクラムウォーズ」を出します！
TL;DR
き23D 仕事しないz です！
2019年9月22日にある技術書典7にでます！ スクラムアンチパターン体験談集です！
前置き
もう、5、6年前だったか、もっと前だったか……。よくid:TOKOROTEN が「スクラムってクソだよね本出そう」みたいな話をしていて、当時は僕もまだ会社でバリバリスクラムをやっていて、当時の感覚だと「スクラムはうまくいく部分もあればうまくいかない部分もある。『クソだよね！』って言うほどクソでもないけど、まぁ不満はあるなぁ……」というような印象をもっていました。当時所属していた会社は分割したり売られたり、社名変更されたり吸収されたりで今はもうないんですけど、その会社で実践されていたスクラムは、スクラムガイドという教科書にわりとガッツリ沿ったやり方ですごくうまく回っていて(正確にはうまく回っているように見えていて)、実際開発陣も楽しそうに仕事をしていて悪いものではなかった。何より会社がちゃんとお金を出して、相当な数の開発者を認定スクラムマスター研修や認定スクラムプロダクトオーナー研修に行かせてくれていたし(2011年とかの話である)、そこでスクラムを経験した開発陣が今でもスクラムで開発を進めているという話を聞いたりする。当時から変わらない印象としては「スクラムはスキルの高い人の生産性を下げ、スキルの低い人の生産性を上げて、チームとしての生産性をそこそこにキープするやりかた」というものだ(個人の感想です)。
さてさて、僕が認定スクラムマスターをとったのが2011年らしい。それから8年経って、はっ？ 8年もってるん？？ ってなるんだけど、8年経ってスクラムという言葉がかなりエンジニアに浸透してきて、web開発界隈だと「スクラム」という言葉は説明なしに通じるようになってきた。 ま、このように言葉が人口に膾炙すると、その言葉や超ざっくりした140文字くらいの説明を読んだだけでわかったような気になり「お前達明日からスクラムで開発しろ」とか「スクラムで開発して今までの倍の速度だします！」とか、まぁ、そういうことを言い出す偉い人とか意識高い人とかが大量に発生し、そういう人は本質を理解せずに言葉だけで実装を開発者に丸投げするので開発者たちにはツラミが溜まってくる。と。
mohikanzというエンジニアの雑談コミュニティがあるのだけれども、そこの #scrum チャンネルではそういう様々なscrumに関する質問や悩み相談が多くみられた。そこでのみんなの話を聞いていて思ったのが「幸せな家族はどれもみな同じようにみえるが、不幸な家族にはそれぞれの不幸の形がある」ということ。それぞれの現場でそれぞれの形でスクラムが運用されていて、それぞれのツラミが、それぞれ深そうと感じた。
「折角だからここでの話、本にして技術書典で頒布しよぜー。とりあえず申し込んでおくわーー(ぽちーーー」
としたら、受かってしまったので技術書典7で本を出すことになりました(ここまで前置き
どんな内容？？
最初は「お前のスクラムは間違っている！」くらいの気持ちで書こうと思っていたのですが、冷静に考えたら「俺達のスクラムは間違っている!?」という内容になりました。6人の開発者がそれぞれの現場で体験したスクラムについて書いています。うまくいっていた例もありますが、全体としてアンチパターンが多めです。それぞれの章でそれぞれのスクラムについての辛みが紹介されており、それにどのように立ち向かっていったのかという内容が多いです。
さて、僕は「スクラム導入のアンチパターンと処方箋」という章を書きました。いろんな人のスクラム辛い話を聞いていると、そのスクラムが辛い理由は、スクラムの運営自体が拙い場合は少なく、むしろ上司や組織といった開発チームよりも大きな枠組みがスクラムをただの「なんかいい感じに開発が進むやり方」くらいにしか思っていないという無理解が原因にあるように見えました。そこで、いろいろな人に聞いたスクラムの辛い話をいくつか例に挙げ、何が良くないのか、どうすればいいのかという内容について論じました。
他の執筆者の章は開発者目線で現場でどうやって戦っていったのかという話がメインですが、開発者の努力だけだとどうしようもない場合どうするべきか。どういう層にどうやってアプローチしていくべきかという点について論じている点がユニークかもしれません。詳しい内容は是非本書を読んでみてください。電子書籍版もboothあたりで販売する予定です。
How to 執筆
技術書界隈ではGitHubで原稿を管理して、Re:Viewで書いて〜〜みたいなのが流行っています。確かに大規模な執筆であればそういったやり方が適切でしょう。しかし私達は、執筆者の半分以上が同人誌を書くのが初めてであり、さらに技術書を書くのはみんなずぶの素人です。
今回とったやり方はGoogle Docsにそれぞれがそれぞれの章を書き、執筆者と有志のレビュワーでクロスレビューをするというやり方でした。
Google Docsのいいところは、スマホからレビューをしてスマホからコメントを書ける点です。忙しいソフトウェアエンジニアでも通勤電車の中で執筆、校正作業ができて効率がいいね！ タスク管理はTrelloを活用しました。
執筆が終わると、編集担当がInDesignで編集をし、pdfを出力して再度チェック。
と、まぁ、こうした、手作業は多いけれども確実に書き上げることができるというプロセスを採用しました。
振り返り会
「スクラムの本を書くんだから、あとがきは振り返りをやってその結果を書こう！」
という超ナイスアイディアが、執筆のキックオフをしたときに出たので、あらかた執筆が終わったタイミングで渋谷のルノアールの貸し会議室にあつまりFun Done Learn による振り返りを行いました。
や、みんなで集まってわいわいやるのは楽しいですね。ちなみに僕が着てるTシャツはこれです
https://www.amazon.co.jp/dp/B077MBF8R7/ref=cm_sw_r_tw_dp_U_x_TJpGDbX2KKZ7N
そして、みんなでやったFunDoneLearnの結果はこちら。
高解像度版へのリンクは本に載っていますのでよければそちらをご参照ください。
まとめ
今まで同人文芸書はいろいろ作ってきましたが、技術書を書いたのは初めてでした。書いていくなかで自分の考えが徐々に整理されていき、また、他の人の文章を読むことであらたな発見と学びがたくさんありました。Fun Done Learnという形での振り返りも、初めてやったけど大変に楽しかった。
文芸同人畑の人間なので綴じ方向逆にして表紙をつくってしまうという大ぽかもやらかしたりしましたｗ
ふぁぁぁぁあああ！ この表紙右綴じやんけ！ 横書き技術書だから左綴じで作らんとあかんやんけ！！ 作り直しや！！
— hidesuke (@hidesuke) September 5, 2019
いろいろと、学びの詰まった本です。最初は50ページ弱の予定でしたが、気づいたら88ページにもなってしまいました。
なかなか世に出てこない話が詰まったいい本になったと自負しています。
9月22日はき23D 仕事しないzで「ぼくらのスクラムウォーズ」を1冊1000円で頒布します。電子版も用意してあります。皆様、是々非々おいでください！
日産自動車株式会社を退職しました！
2019年2月28日に25ヶ月勤めた日産自動車株式会社を退職しました。2月22日が最終出社日で、短い有給消化を経て3月1日より都内のAI系ベンチャー勤務です。。
辞めたが、それでも日産自動車株式会社をおすすめしたい
日産自動車というよりは、僕がいた部署、コネクティッドカーのアプリやサーバサイドを作っている部署では、絶賛人員募集中です。
車社会の未来を一緒に作るAndroidデベロッパー募集！ - 日産自動車株式会社のモバイルエンジニア中途の求人 - Wantedly
カジュアル面談(本当にカジュアル！)も随時受け付けているので、上のWantedlyから気軽に声をかけてあげてほしい。WantedlyではAndroidデベロッパーとしか書かれていないけれども、iOSエンジニアも、バックエンドエンジニアも精一杯募集しているので是非気軽に声をかけてみてほしい。
以下では、なぜ僕が日産に入って、日産で何をやって、なぜ日産を辞めたのかということについて書く。
なぜ日産に入ったのか
クビカリ！ バキューン。ある日なんとかっていうヘッドハンティング会社から「日産自動車っていう会社が……」という非常に怪しい求人を持ってきた。「おっ、日産。家から近いし話だけでも聞きに行ったろ」くらいの感じで話を聞きに行ったら、これが思いの外面白そうだった。というのが2016年の暮れ。
当時、コネクティッドカー＆コネクティッドサービスの部署を新規で作るという話があり、その立ち上げメンバーの募集をしているという話だった。コネクティッドカーというのは自動車がインターネットに常時接続されており、スマホなんかで車の状況を把握したり、なんかいろいろ便利にできる仕組みのことだ。最近ではTOYOTAのクラウンなんかがコネクティッド推しではあるが、日産では電気自動車のLEAFが、なんと発売当初の2010年からすでにインターネットに繋がっており、スマホアプリなんかが用意されていたというから、技術の日産侮れない。
しかし、世の中の誰も、「2010年当時から日産・LEAFはコネクティッドカーだった」なんて知らないのはなぜか。
これは僕の推測(と日産にいたことによる肌感覚)なのだが、昔強烈に頭のいい人がいて「車もインターネットに繋いだら便利！」みたいなことを言い出して、ベンダーを使ってもりもり作らせたはいいものの、クルマの会社はベンダーに作らせることしか知らないので、その後サービスを育てるであるだとか、ユーザの使い方を見て改善するといったような考え方がなかったのだろう。事実、僕たちの部署ができるまで、LEAFのアプリはひどいUI/UXのまま放置され続けていて、2018年僕たちの部署によってリニューアルが行われ、きれいでモダンなUI/UXの素敵なアプリに生まれ変わった。そして今も継続して進化している。
話がそれた。とにかく、そのように外注を使ってやってはみたものの、うまく行かなかった。そのため、コネクティッド分野で他社の後塵を拝することとなり、今までのやり方ではだめだ。ということになった(らしい)。そこで、コネクディットに関わる新しい部署を作り、アジャイルで、内製で、カーセントリックな考え方からヒューマンセントリックな考え方に移行し、素晴らしいモビリティ&コネクティッドサービスを作るぞ！ という目的でぶちたてられたのが僕のいた部署で、そんなん、完全に面白いやん？
というわけで入社した。
その前の職も十分面白かったのだけれども、クルマは自動車会社じゃないと作れないという点は、転職を決断した理由として本当に大きくて、いまモビリティサービス分野に進出する企業はすごく多いけれども、そのどの会社に行っても、実際のクルマは作れない。ここは本当に日産という会社に行くべき理由だと強く思いました。
んで、何をやってたか
Node.jsが得意なこともあって、Alexa関連のあれこれをメインでやり続けた2年間でした。最初はPoC的に英語版のAlexaをいじっていろいろやっていたのですが、タイミングよく日本語版アレクサの日本ローンチパートナーとしてリーフスキルをリリースすることができました。その後も細かい改良を重ね、EchoSpotの日本発売時のローンチパートナーとなり、EchoShowもローンチパートナーとなることができました。
www.slideshare.net
まぁ、ぶっちゃけテレビCMって最高の福利厚生ですよね！！
他にも、Easy Rideという日産とDeNAが共同で実証実験をしている自動運転車両を用いたロボタクシーサービスの運用を一部お手伝いしたりしていました。
他の人がやらないことを拾い続けていたら、他の人がやらない仕事ばかりをやることになり、引き継ぎ先がなかなかできずに大変ではありました。
なんで辞めるのか
ポジティブな理由
長く務めるつもりではいたのですが、ご縁があり、転職を決意しました。
ネガティブな理由
日産で頑張ってこれたのは「ああ、このままだとこの会社はだめだ。変えていかなくては」という強い思いがあったからです。
正直、日産に転職するまで『完成車メーカー』という言葉の意味を一ミリも理解していませんでした。
日産のような完成車メーカーは、重要な一部の機能を除き、部品はすべて外注し、それを組み立てて世の中にリリースするというビジネスです。以前バズった新卒で入社した本田技術研究所をたった３年で退職しました - チャレンジして失敗を恐れるよりも、 何もしないことを恐れろ。 というブログポストがありましたが、だいたいこの通りです。
このブログポストに関して、僕はネガティブな意見もポジティブな意見もありません。確かにコスト削減や部材の安定供給などの観点からサプライヤーに投げ、納品されたものを組み立てて売るというのは理にかなっています。
さて、僕がいた部署は「内製」で「アジャイル」に開発する部署なのですが、クルマの本体を作っている部署から見ると「実際にものを作っている部署はサプライヤー」と行った見方が異常に強いです。僕たちのように内製で手を動かす部隊が会社の中にいる理由は、顧客に継続して価値を届け続けることが必要で、それを実現するためという点です。僕たちは決してサプライヤーではなく、積極的にビジネスをドライブする存在であるはずです。クルマを作って、売って、終了。というビジネスしか知らない人たちとの、こういった軋轢がありました。
他にもネガティブな理由はいろいろあるのですが、書けないことが多いのでコレ以上は('x')お酒でも入ったときに聞いてください。
こう、「変えないといけない！！」という強い動機に支えられて、そのように動いて来たのですが、いざ、いいオファーを受け取ってしまうとこの「変えないといけない！」と思っていた点がそのまま「日産イケてない点」へとクルリンパしてしまいます。
ですので、すごく悩みましたし、上司にも相談したりしました。が、結局転職を決意しました。
それでもなお、日産を推す理由
私は去りましたが、日産には頑張ってほしい。というのも、日産はすごく面白い立ち位置にいるからです。
CASE という言葉があって、コレは Connected, Autonomous, Shared & Service, Electricの頭文字をとったもので、今後の自動車業界で重要な要素とされているものです。
CASEとは？ 何の略？ 意味は？ 自動運転、コネクテッド、シェアサービス、電動化 | 自動運転ラボ
日産はこの中でいうとShared & Serviceこそ自社で立ち上がっていないですが、その他については業界で先駆けて実用化してきています。
前述したAlexaのリーフスキルも、2010年にすでにクルマがインターネットに繋がる機能をリリースしていたからこそ、その資産を最大限に活用して実装できたのです。2019年2月時点で、日本のAlexa Skillのコネクティッドカーカテゴリには、未だにリーフスキルしか無いのです。
このようにイノベーションが起きる技術要素は揃っていると言えます。
もし、新しいことにチャレンジしてみたいと思っているITエンジニアがいたら、是非、私がいた部署に応募してみてください。なぜこの部署を推すかというと、真にITの技術が必要だし、実践をしているからです。何より、上司がいい。僕とほぼ同時期に入社した方なのですが「こうしないといけない。こう変えていかないといけない」という問題意識があり、とにかく戦ってくれる、信頼できる上司です。
他にも日産の良かった点として
- 給料がいい (同年代で年収言い合いっこした際、GAFA以外に負けたことは無いです)
- 福利厚生がすごい (会社と、労働組合で別々に福利厚生が用意されている。ゆりかごから墓場まで系)
- 自動車会社じゃないとできない経験ができる (厚木の研究所はテンションあがりまくりです。男の子ってこういうのが好きなんでしょ？ 系)
- 驚きのホワイト企業 (20:00 くらいになるとオフィスが閑散とする)
などが挙げられます。あと、日産は本社は横浜で研究所は厚木ですが、僕がいた部署は中目黒にあり、都心にほど近く、平日の勉強会なども顔が出しやすいです。IT/web系のエンジニアを集めるにあたり、横浜とか厚木だと人来ないだろ！！ 中目黒じゃ！ という経緯で中目黒にオフィスがあると聞いたので、や、本当にまともな人がいたんだなぁ……という気持ちです。
こういう人が向いています
日産(というか僕が元いた部署)に向いている人ですが
- 世の中にまだ無いものを作りたい人
- 組織ややり方自体を改善してものを作っていく気概のある人
- 自律的に動ける人
- モダンなコードが書ける人というのはすべてのベースラインです(みんなコードはめちゃくちゃバリバリ書ける)
逆に向いていない人は
- コードだけ書いていたい人
これくらいですね。
よく「いや、御社はハードルが高い……」と言われて、転職先候補にも上がらないことがよくあるのですが、やっていることは普通のwebアプリケーションであったり、スマホアプリ開発であったりと、特別なことは何もしていません。びっくりするほど普通です。web系の普通のアプリケーション開発なのですよ！！
はぁー、誰か、助けにきてやってくれ！！
これから何をするの？
さて、新しい職場は人工知能系のベンチャーで、実際に人工知能をお客さんが使える形の実装に落とし込んでいく部分を担当します。部署の立ち上げで、人の採用からがお仕事です。
人工知能の脳みそ部分を作る人は優秀な人がたくさんいるのですが、これを使いやすく提供するためにAPIやwebフロント、それを動かくインフラを作る人……つまり、普通のweb系のエンジニアが必要です！
もし興味がある方いましたら、twitterで @hidesuke までメッセージいただければ！ 詳しいお話したり、会社へのカジュアル面談なんかもやりますので、ぜひお声掛けください！
いつもの
というわけで、ウィッシュリストをおいておきます。お祝いなどいただけたら光栄です！！
デザイニングボイスユーザーインターフェース
オライリー・ジャパン様より献本いただきました。ありがとうございます！！
デザイニング・ボイスユーザーインターフェース ―音声で対話するサービスのためのデザイン原則
- 作者: Cathy Pearl,川本大功,高橋信夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/12/01
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
原著の方を先に読んでいて、すごくいい本なので日本語版でないかなーーと待ちに待っていたこの本。翻訳もすごくわかりやすく、読みやすくていい本でした。
Alexaと私
Voice User Interfaceと聞いてみなさん Amazon EchoやGoogle Homeを真っ先に思い浮かべるかもしれませんが、それよりも前に実は多分、みんなVUIには触れていたと思います。それは、宅急便の再配達依頼の電話のあれ。音声ガイダンスに従って「当日再配達を希望の方は”１”を」とか言われてプッシュボタンを押すアレです。あれこそ、一番身近なVUIです。
とはいえ、VUIを一気に一般的なインターフェースにしたのはAmazon Echoであり、Google Homeでしょう。自分は仕事でAlexa Skillを作っている ということもあり、日本でのEcho発売以来ずっとAlexaを触ってきました。自宅は3DKなのですがEchoデバイスが4台鎮座しているというしまつ……。最初は「はー、声でいろいろ操作するの楽だわーー」くらいの雑な感じにしか思っていなかったのですが、第二世代のEcho Showが日本で発売され、それを自宅に導入してから生活が一変しました。
Echo Show (エコーショー) 第2世代 - スクリーン付きスマートスピーカー with Alexa、チャコール
- 出版社/メーカー: Amazon
- 発売日: 2018/12/12
- メディア: エレクトロニクス
- この商品を含むブログを見る
スマートスピーカーは画面付きが圧倒的にいい。まさかここまで違うとは、使ってみるまでは思ってもみませんでした。画面なしのスマートスピーカーの問題点は「使い方がわからない」という点に尽きます。
人間というのは不思議なもので、自由を欲する割に、自由にしていいと言われると何をしていいのかわからなくて何もできなくなるものです。いざ、Echoデバイスを目の前にすると、「Alexa。えっと……。……」と、こっちがフリーズしてしまいがちです。そして、だいたい天気とニュースを聞いてそれでおしまい。みたいな。
しかし、画面付きのデバイスだと、アイドル状態のときに「アレクサ、百人一首を詠んで。と言ってみてください」のような、「〜〜ができますよ」という表示が、日々のニュースと一緒に合間合間にながれてきます。これが素晴らしい。これによって、この得体の知れないAlexaという存在が何ができるのかということを例示しつつ、興味があればユーザが自分でAlexaが何ができるのか調べるきっかけができる。この体験に僕はすごく感動しました。
もちろん、それだけじゃないです。Amazon Primeに入っていればPrime Videoで配信されている動画をEchoShowの画面＋無駄に高音質なスピーカーで堪能することができるし、Amazon Musicで配信されている楽曲の再生もできる。歌詞表示に対応している曲なら歌詞が歌に合わせて表示され、カラオケ練習だってできる！ 電気自動車のLeafをお持ちの方なら、自宅にいながらお出かけ前にクルマのエアコンをAlexaで付けておいて、クルマに乗る頃には温まった車内にのりこめる！
素敵！ 素敵でオシャンティな生活！
そんな素敵でオシャンティな生活の手助けをするのが、AlexaにおけるSkillという、どこかの誰かが作ったアプリであり、このアプリを作る人は 必ず この本を読むべきです。
VUIの難しさ
普段、僕たちはスマホやPCのアプリやブラウザの画面をぽちぽちして、便利な生活を送っています。そこには素敵なデザインがあり、ユーザが使いやすいように工夫を凝らしたいろいろがたくさん詰まっています。これは、長年にわたしGUI(Graphical User Interface)やUX(User Experience) を、人類が研究してきた成果です。
ではVUIはどうか。
僕たちは、言葉を使い、会話を、普段からしているからVUIなんて楽勝じゃないか、と思うかもしれません。でも、人間は自分たちが思っているよりも相当にバカです。前述したように、自由にしていいと言われると何をしていいかわからない問題があります。
たとえば、レストラン検索スキルを想像してみてください。
人間：「新宿のラーメン屋を教えて」
レストラン検索スキル：「５０件の新宿のラーメン屋が見つかりました。新宿１丁目x-x らーめんほげほげ、新宿三丁目x-xらーめんもぐもぐ、新宿四丁目ほげもげ亭、新宿……(50件続く)」
人間：「……」
何がなんだかわかりません。このあと何をすればいいのかわかりません。そもそも覚えてられません。
VUIにはVUIの作法があり、「会話」というプロトコルを通してコンピュータと円滑に対話するためにGUI以上に、UXをデザインする必要があります。
例えば、人間は何を答えればいいか明確になるような質問をVUIではするようにしないといけない。とか。(はい/いいえで答えられる。数値を答えればいいことが明白。足りない部分を適切に聞き返す、など)
会話でやり取りするために、画面でみる以上に注意深く考え、テストし体験をデザインしていく必要があります。
また、画面付きのスマートスピーカーで、どのように画面を利用するか、画面には人間のアバターを出すべきか、幾何学的なものを出すべきか。それぞれのときに何を注意するべきかなど、音声で操作する場合特有の、画面に何を表示するべきかという、GUIとはまた違った課題があります。
この本に書いてあること
思っていた以上にVUIは厄介です。考えること、知らないことがいっぱいあります。
この本では、こういったVUIのシステムを作る上で考慮すべきことが全て書かれています。逆にいうと VUIアプリ、システムを作る者は必ずこの本を読め ということです。
全てのVUIシステムの企画者、開発者が最低限しっておくべきことがこの本には書いてあります。このレベルの知識がない場合、ほんとうに議論になりません。
この本は大きく８つの章からできています
- 1章 イントロダクション
- 2章 VUIデザイン原理の基本
- 3章 ペルソナとビジュアルVUI
- 4章 音声認識技術
- 6章 VUIのユーザーテスト
- 7章 VUI 完成後にすべきこと
- 8章 音声対応デバイスと自動車
４章だけは、音声認識技術それ自体に関する話なので、多くの人にとってはあまり重要ではないかもしれませんが、その他の章は必ず知っておくべき内容しかないです。
もしお近くで「Alexaスキル作りたいんですけど……」とか「Google Home対応したいんですけど……」とか言ってくる人がいたら「デザイニング・ボイスユーザインターフェース読みました？」と聞いてください。読んでないと言ってきたら、読んでくるまで相手にしてはいけません。この本に書いてあることが議論のベースラインになるからです。
先日テレビをみていて、どこかのホテルが客室にEchoSpotを置いてコンシェルジュ代わりにしている〜〜みたいなニュースをみました。少しだけそのスキルの紹介があったのですが、もう、これが ひどいUX でした。明らかにこの本を読んでいないし、VUIのUXについて全くきちんと考えられていない。
会話という、普段から僕たちが使っているプロトコルだからこそ、使いづらいときのストレスは異常に高いです。一方、きちんとデザインされ、熟慮され、洗練されたスキルは使っていて本当に便利だし、気持ちがいい。
少し考慮するだけで、VUIのUXは全然変わってきます。この 少し というのが、この本に書いてある内容です。
本は250ページくらい。平易な文章で誰もがわかりやすい内容です。図も多く、サクサク読めます。難しい理論は何もありません。当たり前だけど、知らないと気づかないようなことが書いてあります。
開発前にこれを読むだけで、使いやすさが段違いとなるので、VUIに関わっている皆さん、絶対に読みましょう。これは名著です。
デザイニング・ボイスユーザーインターフェース ―音声で対話するサービスのためのデザイン原則
- 作者: Cathy Pearl,川本大功,高橋信夫
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/12/01
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
文藝バトルイベント「かきあげ！」5年の歩みを振り返る
この記事はpyspa Advent Calendar 2018 6日目の記事です。pyspa統合思念体の一部となってから1年が立ちました。ｺﾉｶﾗﾀﾞﾆﾓｽﾞｲﾌﾞﾝﾅﾚﾃｷﾀﾖｳﾀﾞ
「かきあげ！」という小説投稿サイトを、かれこれ５年くらい運営しています。
その「かきあげ！」で去る11月25日に第二十七回文学フリマ東京に出展してきました。気付いたら「かきあげ！」で出した本は9冊目。来年は10冊目が出ることに気付いたので、ちょっとこれまでの歩みを振り返ってみたいと思います。
ちょっとカロリー高めの長い文章になるので、最後までお付き合いいただけたら幸いです。
「かきあげ！」 is 何
「かきあげ！」は年に２回開かれる、小説投稿イベントです。「かきあげ！」のwebサイトに小説を投稿し、みんなで読んで、面白かった作品に投票します。投票の結果上位３作品と、かきあげ！編集部からの推薦を受けた作品合わせて10作品前後を同人誌にまとめて、文学フリマ東京で頒布するというイベントです。
これまで出した本は通販しています。
「小説投稿イベント」と言いましたが、小説でなくても構いません。これまでも、詩や文芸評論、エッセイなどが投稿されています。文藝作品で、規定の文字数を満たしていれば何でもOKです。
「かきあげ！」は毎回テーマが提示され、それに沿ったおよそ3000文字〜4000文字の掌編を書いて提出します。テーマは書くきっかけに過ぎないので、無視しても構いません。実際に、常連ほどテーマ完全に無視して書いています。
次回第10回イベントのテーマは「みみみ」！ テーマ無視しても構いません、皆様の投稿お待ちしております！ 12月23日より募集開始！！
www.slideshare.net
「かきあげ！」の目的
「かきあげ！」には２つの目的があります。一つは「本を作りたい」もうひとつは「飲み会したい」です。
本を作りたい
Webで作品を気軽に発信できるようになった現在。だからこそ、自分が書いた本が紙の本になるという体験がどんどん稀有なものとなっている気がします。昔は薄い本をせっせと作って、コミケ(などの同人誌即売会)で頒布する……以外の発表の場がありませんでした。しかし、現在は気軽にWeb上で作品を発表することができあっという間に多くの人に読んでもらえます。そのため、自分が書いた作品が紙の本になるという経験をなかなかできなくなってきているのでは無いでしょうか？
自分が書いた物が、紙の本になる。これは経験してみないとわからない謎の感動があります。まだインクの匂いのする真新しい紙に、整然と印刷された文字列。本屋で手にとる本のような気持ちで読んでみると、確かに、自分が書いた文章が印刷されている。感動だったり気恥ずかしさだったり、なんとも言えない気持ちになります。それは悪い気持ちでは無く、なんだか宝物を手に入れたような。そんな気持ち。
これを味わって欲しくて、本を作っています。
本を作るお金は「かきあげ！」編集部のカンパによって成り立っています。*1ですので、参加者への負担は一切ありません。なんでこんなボランティアじたいなことをしているかというと、前述した「自分の書いたものが本になるという経験をしてほしい」というのと、「かきあげ！」もう一つの目的「飲み会」に来てほしいという意味合いを込めてです……。
飲み会をしたい
だいたいにおいて小説を書くという趣味は、わりと、結構、孤独な趣味です。いや、小説を書く、までは行かなくとも、読書という趣味も結構孤独なもので、周りを見回して、酒を飲みながら延々と本の話をできる人がいるか考えてみてください。普通はいないと思うのです。
でも、趣味の仲間と、趣味の話をワイワイ語らいたい。同じ趣味の話題でワイワイ語らえるのはとっても楽しいということは皆さん経験的にわかっていると思います。
「かきあげ！」のような小説投稿サイトに出入りする人が本が嫌いなわけありません。さらにコイツラ飲み会が大好きです。
ITエンジニアの世界にもいろいろな宗教戦争があって、うっかりあるエディタの話になるとどうでもいい喧嘩が起こったりとか、ある言語の話になるとマウント合戦が繰り広げられてたりだとか、あるツールの話になると老害が跋扈し始めたりだとか、まぁそんなことあるじゃないですか。
文藝世界も同じで、いや、最初から個々人の趣味の問題だからもっとひどいかもしれない。でも、「かきあげ！」の飲み会、特に打ち上げの場合は自ずと話題はその回の投稿作品の話になり、宗教戦争に発展してしまうこともそうそう無いです。その中で、宗教的な一致を見て、より仲良くなる人もいるでしょう。新たな気付き、新たなチャレンジへの一歩となる人もいるでしょう。よきかなよきかな。
まぁ、そんなことはどうでも良くて、とにかく乾杯して酒飲みたいんじゃーーー！
と、まぁ、そんなモチベーションでかきあげ！ は運営されています。
「かきあげ！」のシステム
「かきあげ！」の投稿システムであるkakiage-webはnodejs+mongodbで作られています。
確認してみると一番古いコミットは2013年5月。あー、そっか。その年の夏にデブが治らなくて教育入院２週間の刑に処されて、その間にがーーっと実装したんだった。コード管理はbitbucketです。
2013年当時は、まだweb frontのフレームワークも出たばかりだったし、僕自体がweb frontにあまり興味がなかったので、Expressで普通のwebアプリとしてもりもり書いていました。最近は思うところがあって、フロントエンドをVue.jsで書き直したいと思いVue.js勉強中。
こんななんの変哲もないWeb+DBなアプリケーションになんでmongodb使ってるの？ と言われると、mongodbは無料で使えるサービスが多くあるので、というケチケチした理由です。ただこれが悪夢の始まりだったのです……。
放浪のkakiage-web
最初はホスティングにJoyentを使っていたのですが、一般向けのサービス終了。移行先としておすすめされたnodejitsuに移行してしばらくはeverything goes wellだったのですが、nodejtisuがGoDaddyに買われ一般向けのホスティングサービス終了。移行先としておすすめされたmodulusに移行し、その後xervoと名称変更がなされるのですが、こいつも一般向けのホスティングサービス終了。いろいろ悩んだ結果、いまはherokuで動かしています。herokuは一般向けのホスティング、おいそれと辞めないですよね？？
ひどいのは「無料だから」と思って採用したmongodbのホスティングサービスです。もうどんだけ移行したか覚えてないし、コミットログ追うのもしんどいのしんどい！ ってくらい移行しました。現在mlabに落ち着いてますが、mlabもサービス終了する？ みたいなメールを拝受した気がしていますが、気が気じゃないので見なかったことにしています。
「かきあげ！」を支える人々
「かきあげ！」は参加者の皆さんに支えられています！
まぁ、それだけでは無く、スタッフとして「かきあげ！」を支えてくれている人たちがいます。「かきあげ！」編集部と言われる集団です。
本を作る、本を売る、システムを運用する、どれも金がかかります。「かきあげ！」は収支管理表を公開しています。この費用は編集部のカンパで成り立っています。
また、編集部がやっていることとして以下があります。
その他にも最近では原田さんという方が主催している朗読劇でよく「かきあげ！」に投稿された作品が朗読されたりしています。
私も一度、この朗読劇を見に行ったのですが、いや、面白いものですね。自分では気付いてなかった発見がたくさんあるし、何より「紙の本になる」より貴重な体験でした。
朗読の様子は週末はかきあげ！ 祭りやで〜！ - かきあげ！こちらのエントリにYoutubuへのリンクがあります。
皆さんに支えられてのかきあげ！ ですmmm
「かきあげ！」参加者募集中！
というわけで、「かきあげ！」では参加者を募集しています。ジャンル不問、3000~4000文字の掌編文藝作品を投稿してください。
作品投稿された方には1点お願いしていることがあって、それは他の人の作品を読んで感想を付けてほしいということです。「かきあげ！」はその前身の一つである文章力向上委員会の思想である「他人の文章の感想を書くことで、自分の文章力を向上しよう！」というものを受け継いでいます。また、単純に感想がたくさんつくと、嬉しいですよね？
作品を投稿されてもいいですし、読み専でも構いません！ 感想つけていただけるととても嬉しい。
5年続けることができたので、もう5年くらい続けられるといいなぁ……と思っています。
*1:ちなみに編集部は本にする作業の中で、原稿のレビュー/校正もやっています。お金を払って罰ゲームを受けているようなもんですね……。
