AWS 認定デベロッパー アソシエイト 試験の受験記

受験日とスコア

  • 受験日: 2022/7/3
  • スコア: 809
  • 結果: 合格

主な使用教材

受験までの大まかなスケジュール

受験までの AWS 使用経験

トータルで経験年数 3年ほどです。

受験のモチベーション

  • 引きこもりでぐーたらする生活が続いてしまったので、なにか有意義なことをしたい
  • 現職場で AWS 認定試験の受験料が会社負担になるので、制度を活用したい

受験までにやったこと

ポケットスタディ AWS認定 デベロッパーアソシエイトを読み、練習問題を解く

会社で同じ資格を取得した方から「参考書の問題を2周くらいしたら受かった」というようなお話を聞いたので、素直に問題を2周しました。

SAA を取得したときと比べ、DVA の出題範囲は実務で触ったことのある領域が多かったので、参考書をじっくり通読することはせずに、自分の触ったことのない領域だけを重点的に読むようにしました(具体的には、Cognito や SQS などの範囲)。Kinesis あたりは実務経験ないものの、SAA を取得したときの知識がわずかに残っていたので、そのときの記憶でなんとか対応できた感じがします。

公式の模擬試験を解く

参考書を2周したあと、実践形式での演習をしよう!ということで公式の模擬問題を解きました。

昨年 SAA を取ったときと異なり、模擬問題は「無料」かつ「解答&解説付き」になるという大幅アップデートがなされていたので助かりました。クラスメソッドさんの記事で紹介されているので、詳しくはそちらを参照ください!

dev.classmethod.jp

OnVue 試験について

最初の「スケジュール」の項にも書きましたが、一度自宅受験を試みてトラブルにより断念しました。

原因は不明なのですが、受験用のアプリケーション(OnVue)が本番の試験のタイミングになってフリーズしてしまい、試験を続行できなくなってしまいました。

画面がフリーズしてうろたえていると、試験官の方から試験チェックイン時に登録した番号へ電話がかかってきて、試験が中断となりました。中断のあとしばらくして、受験料の返金を知らせるメールも届きました。自分の場合は受験料 50% オフのバウチャーを使って試験予約をしたので、バウチャーも試験中断に伴い返還となりました。

あとから調べてみると、Mac での受験はどうもトラブルが多いみたいですね。私は自宅の Macbook Pro を使って受験していました。

自宅受験で再受験をするという手もありましたが、またシステムトラブルになると嫌なので、再受験はテストセンターで受けることにしました。

再受験の試験会場について

再受験は千葉駅前大通りテストセンターで受験しました。DVA は SAA に比べ受験可能な会場が少ないので、試験のスケジューリングにはなかなか苦労しました。。会場受験される方は早めの受験計画と試験場予約をおすすめします!

試験環境については、前回 SAA を受けたときの試験環境よりはかなり良好で、静粛な環境で落ち着いて試験を受けることができました。強いて言えば冷房がかなりしっかり効いていたので、羽織るものを持っていくべきだったなとは思いました。

まとめ, 感想

いち開発者をやっている身としては、SAA よりは DVA のほうが、「実務経験が資格取得に役立った」「資格取得のための勉強が実務に役立った」という感じがします。AWS を使って開発している方には素直におすすめできる資格だと思います。

ジャパンラグビーリーグワンでラグビーの試合を初めて生で観戦した話

ラグビー初観戦

2月6日に、ジャパンラグビーリーグワンの NEC グリーンロケッツ東葛 vs コベルコ神戸スティーラーズ戦を見に行ってきました。

ラグビーワールドカップ大学ラグビーなど、ラグビーの試合のテレビ中継は何度か見たことがあったのですが、生で見るのは今回がはじめてでした。

league-one.jp

せっかく最近買ったカメラも持って行ったので、まずは写真から。

www.instagram.com

www.instagram.com

のろのろと文章書いているうちに、観戦日からしばらく時間が経ってしまったのですが……。いろいろ初めての体験があり新鮮だったので、ざっくばらんに書いたレポートを投稿してみます。ラグビーに興味があり観戦してみたい人の参考になれば幸いです。

ちなみに地元チームということで、私はグリーンロケッツ東葛を応援しています。

席選び

スポーツ観戦といえばもっぱら野球、という中で育ってきたので、スタジアムの席選びがどういうものなのか全く見当がつかない状態でした。知っていることと言えば「ゴール裏は観戦初心者が行くところではない」という程度。

Google で「ラグビー 観戦 はじめて 座席」などで検索して調べた結果、バックスタンドの中央付近 (チケット料金 ¥4,000 くらい、柏の葉で言う ENGINE L/BACK_S) の席を取りました。

結果的に、座席選びは成功でした。理由としては以下です。

  • 選手がとにかく近いので臨場感があり楽しい
  • 中央付近なので、一定程度全体を見渡せる
    • 特に今回は後半かなりワンサイドゲームだったので、座席位置によっては様子がよくわからず退屈していたかも
  • 日差しが差す席なので暖かい(これは時期により条件が変わるかも)

会場近辺の雰囲気

キッチンカーや特設ステージ、自治体のブースなどがあり、ちょっとしたお祭りのようでした。特設ステージでは、試合の見どころ解説やチアのパフォーマンスがあったようです(私は時間に間に合わなくて見られず……)。

グリーンロケッツ東葛の「東葛」は、千葉県の市川市/松戸市/野田市/柏市/流山市/我孫子市/鎌ケ谷市あたりを指す地域名ですが*1、この日は松戸市のホストタウンデーということで、松戸市のブースが設置されていました。

リーグワンが2022年にスタートしたばかりということもあってか、地域ぐるみでここから盛り上げていこう!という空気が感じられて良かったです。

試合を見て感じたこと

身体能力がすごい

ラグビー選手は体格が良く、体の太さ厚さに圧倒されました。しかもそういう人がものすごいフットワークで走ったりするんですよね。身体能力がすごい。テレビでも身体能力については感じることはありますが、実際に目の前で選手がプレーしているのを見ると、改めて次元が違うのを感じます。

反則の種類もタイミングも多いのでときどきついていけない

ラグビーでは、反則がけっこうな頻度で発生します。テレビだとどのような反則かの簡単な説明が表示されますが、現地での観戦だと、当然ながらそのような解説はほぼありません。これが観戦初心者にはちょっとつらく、なぜいまプレーが止まっているのかわからない場面が何度かありました。

ノックオン」「ノットリリースザボール」「スローフォワード」「オフサイド」……まずはこのあたりの反則がどのようなものかと、審判のジェスチャーを覚えると良いのかもしれません。

最後に

新型コロナウイルスの流行があり試合が中止になったり、いろいろと困難の多い状況下ですが、ラグビーリーグワン、これからどんどん盛り上がっていってほしいです!グリーンロケッツ東葛の勝利を切に切に切に願っております!!!また試合観に行きます!!!

*1:船橋や浦安も「東葛」に含める場合がありますが、ことラグビー文脈で言えば、船橋はスピアーズ、浦安にはシャイニングアークスがあるので、除外しても良いでしょう

ミラーレス一眼のカメラを買いました

こちらは 今週のお題「買ってよかった2021」 の記事です。

年の瀬ですね。

今年買ってよかったもの」などの記事がいろいろ出ている頃と思いますが、私は 1点の買い物に絞って、今年買ったミラーレス一眼のカメラの話をしようと思います。

買ったもの

今回はじめて一眼のカメラを買ったのですが、そのわりにはお高めの機種を選んだ感じです。

(以下一文、一眼のカメラを買ったことのない人は呪文だと思って読み飛ばしてほしいですが)カメラ沼の友人たちが「APS-C のカメラを買っても、どうせいずれはフルサイズが欲しくなるんだから。出せるお金があるのであれば、最初からフルサイズのを買ったほうがトータルのコストが安く済むよ。」と口を揃えて言って来たのを真に受けて、これを買ってしまいました。てへぺろ

主に撮っているもの

  • 野球とそれに関連する人物
  • 動物
  • 風景

撮った写真

せっかくなので撮った写真を何枚か上げます。ドがつくほど初心者なので、温かい目で見てほしいです。

www.instagram.com

www.instagram.com

www.instagram.com

f:id:k-anz:20211228180454j:plain 本土寺に紅葉を見に行ったときの写真

f:id:k-anz:20211228191531j:plain 動物園のミーアキャット

買ってみてどうだった?

出かけるモチベーションになる

在宅で仕事をするようになってから、外に出かけるにもなかなか気持ちが上がらない日々が続いていたのですが、カメラを持つことで外に出かけるきっかけができた気がします。

あと、冬の山などは周囲とは違う写真を残せそうでワクワクしますね。まずは山でカメラとレンズを持ち歩ける体力をつけないと、と思います。(合計で2kgくらいある)

無限にお金がかかる

望遠のレンズが欲しい、単焦点のレンズが欲しい、一脚が欲しい……と、いくらでも物欲が湧いてしまい恐ろしい気持ちです。来年のいまごろどうなっているか自分でも予想がつきません。。

これからも、お金を使いすぎないよう気を付けつつ、写真を楽しんで行こうと思います。

入社からフルリモートワークの9ヶ月間を振り返ってみた

この記事は、弁護士ドットコム Advent Calendar 3日目の記事です。

前日は hkano さんの 「OpenSearchを使ってみる」でした。

https://qiita.com/advent-calendar/2021/bengo4com

qiita.com

2021年3月1日に入社した k-anz です。弁護士ドットコムでエンジニアをやっています。

今回は「入社からフルリモートワークの9ヶ月間を振り返ってみた」ということで、3月の入社から最近までのタイムラインを作りつつ、その時にあったことや感じたことを書いていきたいと思います!

入社からフルリモートワークの9ヶ月間を振り返ってみた

  • 2021年3月の入社から、直近 11月までのできごとを振り返りました
  • 下図、赤背景で書いてある「出社」の日以外は、すべて自宅からリモートで作業をしていました

f:id:k-anz:20211203075746j:plain
タイムライン

(画像はクリックで拡大できます)

3月 (入社~入社1ヶ月)

1〜3月

3月1日、入社初日のオリエンテーションは本社にて行われる予定だったのですが、2月上旬に緊急事態宣言が延長されたことを受けて、急遽オンラインでの開催に切り替わりました。

私の場合、採用面接も全体通してリモートで進行していたので、社内の誰とも実際に会うことなく勤務がはじまることになりました。

そのことに正直かなり不安もありましたが、始まってみれば、

  • 入社直後は特にまめに 1on1 をしていただいたので、気になったことを気軽に聞けた
  • 困ったことを Slack 等に書けば、すぐに誰かからレスポンスがあった
  • コミュニケーションが柔らかい人が多く、変なプレッシャーを感じずに発言できた

ので孤立感もなく、安心して業務に入っていけました。

4〜6月 (~入社4ヶ月)

4〜6月

プロジェクトに本格的に参加し、PHP の開発を進めていました。

このころ、はじめてユーザー影響のある障害を起こしました。他のエンジニアの方と通話や画面共有を繋ぎながら、ひとつずつ対処を教えていただいたことを今でも覚えています。障害のときにイヤな汗をかく感覚は、作業場所が家であろうと会社であろうと同じものでした。笑

また、5月に健康診断があり、その際にはじめての出社をしました。コロナ禍以前の転職では、面接等で採用前に何度かオフィスを訪れることが多かったので、入社してからはじめて会社に行くというのは新鮮でした。

初出社がうれしくて撮った、会社のフロア案内の写真

社内はフリーアドレス制になっているので、どこに座ったら良いものかドギマギしつつ*1、書類の提出や名刺・入館カードの受け取りをして、はじめての物理出社の日を過ごしました。

このときは多くの人たちが在宅勤務をしていたので、オフィスは閑散としていて少し寂しかったのを覚えています。

7〜9月 (~入社7ヶ月)

7〜9月

この前後から、開発だけでなく、施策の検討やチームメンバーのタスク管理などを行うようになり、仕事の幅が広がってきました。

チームの人たちともだいぶ打ち解けてきたことや、いままでに経験のない分野の仕事に挑戦しはじめたこともあり、このころは Slack で作業実況をたくさんしていました。

  • 「どの画面でダイアログ出すのがいいかな」
  • 「もしかしてどこで出すかによって実装難易度も違ったりする?」
  • 「これをどうやって A/B テストしよう」

など思考を Slack 上で発話しながら作業を進めていく感じです。以下リンクのブログで言われている「 Working Out Loud 」と呼ばれるものと近いかもしれません。

テキストとして残しながら思考を進めていくことで、手の空いたときにチームの人がアドバイスのコメントをくれたり、自分自身で行った作業を思い出すときの助けになりました。

blog.studysapuri.jp

このあたりでワクチン接種のため 2回ほど出社していますが、本当にワクチンを打ってすぐ帰るようなかたちだったので、同僚と会うことはありませんでした。

緊急事態宣言が延長され、しばらくまたリモートワークも続きそうだったので、この頃に改めて、ヘッドセットなどリモートワーク向けの機材を増やしました。また、会社に行かないのをいいことに、髪の毛を脱色してヤンチャな髪色にしたりもしました。笑

10〜11月 (~入社9ヶ月)

10〜11月

あまりにも家族以外の人と会わない・喋らない生活が続き、かえって人と会うのが怖くなってきたのがこの頃です。

(当時の自分のツイートです)

実際に顔を合わせてお仕事もしてみたいな、でも家の環境も整ってきて快適*2なので離れたくないな、みたいな気持ちで日々仕事をしていました。

そんな

  • 人間こわい
  • 自宅の作業環境が最高
  • でも人恋しい

の気持ちがないまぜになっていた11月の中旬頃、タイミングが合ったので、プロジェクトのメンバー数人とはじめて対面して、作業&ごはんをすることになりました。

会ってみてどうだった?

姿をはじめて目にしたことによる新鮮さはありつつも、話してみると「はじめて会った気がしない」という不思議な感じでした。

いらすとや「オフ会のイラスト」

雑にいらすとやの画像を持ってきてしまいましたが、私に見えていたのはわりと本当にこんな世界でした。(あ、あのアイコンの中の人が動いて喋っている……)というような感じです。

正直なところ「会ったことで、ものすごく仕事がしやすくなる」だとか、「会ったからわかることが増える」ということはあまり感じなかったので、リモートにしても対面にしても、接点を多く持ち、日頃からコミュニケーションをしっかりと取って行くことが大事なのかな、と思いました。

今後もしばらくリモートワークが続きそうなので、引き続きコミュニケーションを密にしながら頑張って行けたらと思います!


明日は @shotanue さんの 「 JetBrains GatewayをSSM経由でEC2に繋ぐ 」です。

*1:いま思えば、フリーアドレスなので好きなところに座ればいいわけですが……笑

*2:特に家での作業は、気分転換の手段をいろいろ自由に用意できるのが良いですね。最近の私は作業の合間にハーゲンダッツを食べる瞬間が至福のときです。

AWS 認定ソリューションアーキテクト アソシエイト 試験の受験記

受験日とスコア

  • 受験日: 2021/7/17
  • スコア: 795
  • 結果: 合格

主な使用教材

受験までの大まかなスケジュール

  • 5月11日 試験を受けることを決める
  • 5月24日 1回目の Udemy 模擬問題を解く(正答率60%)
  • 6月17日 2回目の Udemy 模擬問題を解く(正答率49%)
  • 6月22日 試験を予約
  • 7月13日 AWS 公式の模擬試験を解く(正答率65%)
  • 7月17日 試験受験, 合格

恥ずかしながら、問題を解いて初見で合格ラインに達せたことが、受験までのあいだで一度もありませんでした。

受験までの AWS 使用経験

トータルで経験年数 2年ほどになります。触ったことのあるサービス(とりあえず思いついたものを思いついた順に並べてみました)は以下の通りです。

  • VPC, EC2, ECS, ECR, Lambda, RDS, Aurora, ALB, Route53, CloudFront, S3, SNS, CloudWatch, CloudFormation

受験のモチベーション

  • 前職でサーバーレス関連のサービスを中心に AWS を触ったので、対外的にアピールできる形でスキルを示したい
  • 現職場で AWS 認定試験の受験料が会社負担になったので、制度を活用したい

受験までにやったこと

Udemy の問題集を解く

細かにメモを取りながら問題を解き、答え合わせ・復習時は選択肢の絞り込み方と根拠が正しいかを確かめました。

65問を丁寧に解いて復習するので、とにもかくにも時間がかかりました。Udemy の問題集は基本的にこの勉強方法で回していたので、最終的にはこの「メモを取りながら回答→復習」を6セットこなしました。

時間はかかるものの、理解の曖昧な場所が明らかになり、ぐんぐん力がつく実感があったので良かったです(問題は解けていても正しい根拠に基づいて解けていない場合もあるので)。

教科書を通読

Udemy の問題を解くのと並行して、実務経験のない分野を中心に教科書を読みました。私が特に重点的に読んだ分野は以下です。

  • Kinesis 周りのリアルタイムデータストリーミング処理
  • オンプレミス環境からクラウド環境への移行に伴って使用するサービス・ツール類

公式のドキュメントを読む

問題を解いてつまづいた部分を中心に、ホワイトペーパーや各サービスの FAQ を読みました。

前述の教科書は、大まかな概略をつかむには良いのですが、これだけで試験に臨むには心もとない(内容がやや薄い)と感じたので、ところどころで公式ドキュメントをあたるようにしていました。

また、最新のトレンドを追う意味でも、公式ドキュメントは大事だと思います。書籍だと直近のサービスのアップデートはカバーしきれないので、教科書だと「正答」とされていることが、最新機能を前提とすると「誤答」になるケースがありました。

自分の場合だと、直近で以下のような変更がありました。

  • S3 で「強力な整合性」がサポートされる (2020年12月)
  • EBS のプロビジョンド IOPS SSD で、マルチアタッチがサポートされる (2020年2月)

Web 問題集を解く

無料WEB問題集は10問ずつ解けるので、朝早めに起きて仕事前に少し問題を解くのを習慣にしていました。

正直、この問題集は簡単な問題ばかりなので、受験前には全問余裕で解けるくらいの状態にはなっておくのが良いと思います。

公式の模擬試験を解く

いろいろな問題集を解くうちに、実際の問題のレベル感がわからなくなったので、公式の模擬問題(20問¥2200)を購入し解きました。正直、公式模擬問題はもっと早い時期にやっておけばよかったと感じています。

また、AWS 公式の模擬問題は、分野別の正答率しか返って来ないので、問題と回答をメモして自分で調べて答え合わせをするしかありません。

私はこのあたりをよく知らずに模擬試験を受けてしまったので、どの問題で自分がミスしたのもわからず、ただ点が取れず落ち込んだだけで終わってしまいました。(事前の情報収集って大事ですね。)

試験会場について

柏駅南口にあるテストセンターで受験しました。自宅での受験とどちらにするか悩みましたが、同居人もいて集中できる環境を用意するのがなかなか難しかったので、自宅外で受けることにしました。

試験会場は冷房がついていたものの、新型コロナウイルス感染対策で窓が開いており、大変に暑かったです。また、線路際の建物だったので、電車が通るたびにかなり大きな音がしたのが気になりました。あと近所にカレー屋さんがあるので、お昼どきはほんのりカレーの香りがしました……。

SAA 試験はあまり時間に追われるタイプの試験ではないので、試験への悪影響はそれほど感じませんでしたが、切羽詰まっていたらかなりイライラしただろうとは思います。次回 SAP など受ける機会があったら、それは別の会場にしようかと考え中です。

まとめ, 感想

直前までかなり勉強が難航したのですが、当日朝まで粘った結果、無事に合格できたのでよかったです。

範囲はかなり広いですが、しっかりと根拠から理解して解くことを繰り返せば、充分太刀打ちできる試験かと思います。これから挑戦する方はぜひ最後まで諦めず頑張ってください!

完全リモートワークでの入社〜オンボーディング。3ヶ月間自分なりに心がけていたこと

転職しました

2021年3月から新しい会社で働いています。今回特筆すべきは、「緊急事態宣言下」「リモートワークでの入社〜オンボーディング」だったという点です。前職でフルリモート勤務の経験はあったのですが、オンボーディングからリモートというのは初めてでした。

入社に際して自分でも不安はあったのですが、3ヶ月働いてみてそれなりに手応えが得られたので、オンボーディングにおいて自分なりに心がけたことについて書いてみようと思います。あくまで自分がやってきたことで、職場環境もところによりさまざまなので、万人に適用できるものではないと思います。

緊急事態宣言も延長になっているので、同じような境遇で転職された方、環境が変わられた方などの参考になれば幸いです。

情報収集編

どこに何の情報があるか、どのように探せばよいかを把握する

入社したてのころは本当にわからないことだらけです。ざっと大別しただけでもこれくらいあります。

  • 事務的な処理について(勤怠の入力について, 就業規則, 経費精算, 作業工数の入力など)
  • 開発周りの TIPS 的なもの(開発環境の構築について, データの更新についてなど)
  • 過去のプロジェクトや開発についての記録、仕様書
  • 現在進行中のプロジェクトについての状況、開発のバックログ

人に聞いたりしながらできるだけ早い時期に、このあたりの情報がそれぞれどこにあるか、の、脳内地図を整理しておきました。

総務関係については、会社によっては社内ポータルサイトがあったりもしますね。開発のバックログにかんしては、企画起点のものと開発起点のもので微妙に扱いが違っていたりとか、これも会社やプロジェクトによりけっこう癖のあるところだと思います。

とくに意識したのは、全文検索などで「雑に探せる」探し方を覚えておくことです。過去のとあるプロジェクトについて調べたいときに、まず検索をかけるべきなのは JIRA なのか、Confluence なのか、それとも GitHub の issue なのか。雑に知りたいキーワードひとつで検索をしても、情報のまとまっているところに行き着けるようにしておくと、ちょっとしたことで人を呼び止めずに済むので良かったです。

まあ別に入社して間もない頃なんて、気軽に人を呼び止めることにためらいはいらないとは思うのですが。サクッと探せるようにしておいて損はないので……!

ボンヤリ情報を見る時間を意識的に作る

会社に入って最初のうちは、簡単なタスクをもらいながら、システムの構成や開発フローをつかんでいくことが多いと思います。

日の浅いうちはなにかと不安で、目に見えて評価につながるアウトプットをしたいので、「急いでタスクを片付けて!次のタスクへ!」と行きたくなるところです。なのですが、タスクの周辺のコードをぼやっと眺めたり、システムの全体像をじっくり読んだりする時間も大事にしていました。その上で気になったことを人に聞いたり、社内の Wiki で調べたりしていました。

ここでいう「ぼやっと」「ボンヤリ」は特に目的を持った情報収集ではないという意味です。だらだらさぼっているわけでは決してないです。決して。(あまり強調すると、逆に嘘くさいかな。笑)

こういうぼやっとやる情報収集は、種まきみたいなもので、すぐに実になるものではないのですが、あとあとけっこう役に立つと思います。実際、私ものちに「この話どこかで読んだことあるな……」と、情報収集中に見たことがらが実務とつながるのを実感できました。

情報発信編

タスクの状況は、途中であってもなるだけ開示していく

自分が受け持っているタスクに関しては、どこを見て何を考えて実装しているかや、質問未満のぼやきのようなものを、なるべくリアルタイムで Slack に書くようにしました。ぼやきを気軽に書くことができるかは、ちょっと会社の雰囲気にもよると思うのですが、いま勤めている会社は分報をやっている人がいたりと割合オープンな雰囲気なので、気軽に書き込むことができました。

あとは Pull Request は WIP の状態で早めに共有して、自分の認識がチームの人たちと相違ないかを確認したりしました。

自分が新入社員を受け入れる側をやっていたときのことを思い返すと、「アラートが上がってこないので順調に作業が進んでいるのかと思ったけれど、コードを見せてもらったら全く進んでいなかった!」というような状況が一番困ったので。

先輩社員が安心して見守れるように情報を発信していくこと、何か困ることがあったらなるだけフォローに入ってもらいやすい状態にしておくことを心がけました。

プラスの感情については積極的に伝えていく

人とのやりとりが事務的なものに留まらないように気をつけていました。「ありがとうございます。」「承知しました。」だけじゃなくて、「ちょうどここのところは悩んでいたので、助かりました!」「シンプルな仕様に寄せられてよかったです」とか、そんな感じです。

リモートワークだとなかなか人柄や雰囲気が伝わりづらいので、事務的なやりとりだけでなくもう一歩踏み込んでコメントすることを意識していました。とくにプラスな感情については、ひとこと多く伝えるほうがみんなハッピーになれるかなと思っています。


ここまでつらつら書いてきたことをひっくり返してしまうようであれですが、3ヶ月間無事にやって来られたのは、なにより、周りの社員の方の手厚いサポート体制があったおかげだと思っています。なにか困っていると誰かしらがすぐに反応して助けてくれるので、安心してチームに入っていくことができました。

そのうち「リモートのオンボーディングでやってもらって良かったこと」も記事にできたらと思います。

何か参考になる部分があれば幸いです。

Confluence, Qiita:Team 解約 -> ドキュメントのアーカイブ作業の記録

いくつかの SaaS のサービス解約を行うことになり、ドキュメントのアーカイブ作業を行ったので、そのメモです。主に以下の作業を行いました。

  • Confluence -> GitHub Wiki 移行
  • Qiita:Team 上の情報の HTML 化

Confluence -> GitHub Wiki 移行

Confluence 上の情報の markdown

Confluence の情報は、設定から Export すると、「PDF」「XML」「HTML」の形式が選べます。ただ、GitHubWiki 等に移行したい場合は、 markdown 形式である必要があるため、もうひと手間必要になります。そこでこのツールを使いました。

k-anz/confluence-to-markdown: Confluence to Markdown converter which is actually working forked from meridius/confluence-to-markdown

pandoc を使って、Confluence の情報を markdown へと変換してくれます。おおもとのツールを動かしてみたら、オプションの関係でうまく動かなかったので、fork していくつかオプションをコメントアウトし、一旦動く状態にしました。

markdownGitHub Wiki にアップロードする

GitHub Wiki は git リポジトリとして clone できるので、

git clone https://github.com/YOUR_USERNAME/YOUR_REPOSITORY.wiki.git

して、markdown ファイルを一通り add し、master(今どきは main?) ブランチへ commit すれば完了です。これで一応読める状態の Wiki が完成します。いくつか画像等がリンク切れする部分が出てきてしまったのですが、一斉置換して手直ししたらなんとかなりました。

Qiita:Team 上の情報の HTML 化

Qiita:Team については、HTML としてアーカイブを残すことになりました。

k-anz/quiita-team: Qiita Team JSON to HTML forked from okaxaki/quiita-team

このツールが作られた当時は、Qiita:Team から Export される JSON ファイルは 1ファイルの巨大な JSON だったようなのですが、2020年12月現在では 3ファイル (articles, groups, projects) に分かれて Export されるようになっていました。

なので、これも fork して 3ファイル分読み込み処理が走るよう修正し、一旦動く状態にしました。

なかなか解約作業をやる機会も少ないとは思いますが、必要がある方は参考にしてみてください。