はじめに itoken1013です、こんにちは。今年も寒い冬がやってきましたね！ 今回はプロジェクトマネジメントに携わる方であれば一度は聞いたことがある PMBOK について、 知識エリアとプロセス群 を中心に紹介していきたいと思います。 知識エリアとプロセス群への理解はプロジェクトマネージャー以外にも、プロジェクトに関わる全てのポジションの方に得られる知見があります。 ぜひこの記事からご担当のプロジェクトで活かせる PMBOK 知識をゲットいただければと思います！ はじめに PMBOKとは？ まず、プロジェクトとは？ 次に、プロジェクトマネジメントとは？ それでは、PMBOKとは？ PMBOKの重要性 PMPとは？ PMBOKの知識エリアとプロセス 知識エリアとプロセスの関係性 プロセス群、プロセス プロセス群 プロセス 10の知識エリア プロジェクト統合マネジメント プロジェクト・スコープ・マネジメント プロジェクト・タイム・マネジメント プロジェクト・コスト・マネジメント プロジェクト・品質・マネジメント プロジェクト・資源・マネジメント プロジェクト・コミュニケーション・マネジメント プロジェクト・リスク・マネジメント プロジェクト・調達・マネジメント プロジェクト・ステークホルダー・マネジメント PMBOKを活用していく際の注意点 おわりに PMBOK とは？ まず、プロジェクトとは？ PMBOK の知識エリアとプロセスを説明する前に、まず私たちが普段当たり前のように発している「プロジェクト」とは何でしょうか？ PMBOK においてプロジェクトとは、以下の特徴を持つ活動を示しています。 開始・終了時期が決まっており、明確な実施期間がある。（ 有期性 ） 過去に行った取り組みと比べて手順、作業の内容、担当者などが異なる 独自性 を持つ。 PMBOK が指すプロジェクトの対義語として「定常業務」が挙げられますが、定常業務は期間の定めがなく、また既存のやり方に従うことで目的を達成できる活動となります。 一方でプロジェクトと定常業務の共通点としては QCD（Quality：品質、Cost：コスト、Delivery：納期）の制約が存在する点 、そして 人が業務に取り組む点 、という2つの側面があります。 次に、プロジェクトマネジメントとは？ 上記で述べた 有機 性、独自性、限られたQCDの制約がある状況下で、 プロジェクト目標の達成に向けた一連のコン トロール がプロジェクトマネジメントです。 これらの複数の制約を抱えながら目標を達成する過程では通常、何らかの課題が生まれます。 プロジェクト立ち上げ時には分からない不確定要素や想定外のトラブルが発生することも珍しくなく、一筋縄では達成できないプロジェクトをうまくコン トロール する必要があります。 これらのコン トロール を担うポジションがプロジェクトマネージャーです。 プロジェクトマネージャーがコン トロール すべき要素はプロジェクトメンバーだけでなく、スコープやリスクや品質など多岐に渡ります。 また一言でコン トロール といっても作業には計画や実行など、フェーズによって求められる内容は変わります。 それでは、 PMBOK とは？ ここまでお伝えした プロジェクトマネジメントで必要とされる知識や手法を体系的に整理し、標準化した フレームワーク が PMBOK （Project Management Body of Knowledge、ピンボック）です。 米国のPMI（Project Management Institute、プロジェクトマネジメント協会）という 非営利団体 によって制定された世界共通のプロジェクトマネジメントの標準 フレームワーク になります。 1987年に初版が制定され、2020年現在では第6版が発行されています。 PMBOK の重要性 プロジェクトには独自性があるため、 PMBOK さえ理解しておけば万事OK！という状態になることはありません。 ただ過去のプロジェクトで蓄積されたナレッジが体系化されていることにより、 PMBOK は困ったときのガイド役として大いに役立つでしょう。 特にこれからお伝えする10の知識エリアとプロセスを知っていると知らないでは、プロジェクトの課題に直面した時の対応力に違いが出てきます。 また個人的な経験から PMBOK の知識エリアとプロセスの考え方は、プロジェクトマネージャー以外の方にも自身の状況を俯瞰し、担当業務をセルフマネジメントする際の参考となると感じています。 このようにプロジェクトマネジメントの ナレッジを世界標準で体系化している点、また細やかに10のプロセスをコン トロール 対象としている点 が PMBOK の重要な存在意義といえるでしょう。 PMP とは？ PMBOK を理解することの重要性をお伝えしてきましたが、ここで PMBOK に関連する資格である PMP （Project Management Professional）について紹介したいと思います。 PMP は PMBOK と同様、PMIによって運営されており、知識エリアとプロセスをはじめとした プロジェクトマネジメントの知識とスキル 保有 を認定する資格 となります。 正確な合格率が公開されているわけではありませんが、受験から資格更新までの内容を読んでいただくと、簡単に取得・維持できるものではないことが分かっていただけるはずです。 資格試験の出題内容としてはPMIが発行している PMBOK ガイドがベースとなっており、後述する立ち上げ・計画・実行・ 終結 ・監視、コン トロール の5プロセス群に関する問題が出題されます。 出題割合は以下となります。 出題範囲 割合 立ち上げ 13% 計画 24% 実行 31% 終結 25% 監視・コン トロール 7% ※ただし PMI公式ページ では21年以降、出題範囲がプロセスをベースとしたものではなく、人・プロセス・ビジネス環境に基づく内容へ変更されることが 掲示 されています。 出題範囲 割合 人 42% プロセス 50% ビジネス環境 8% PMP の受験には前提条件があり、一定期間のプロジェクトマネジメント経験とPMIの認定研修の受講を求められます。 要件 大卒 高卒 36カ月のプロジェクトマネジメント経験を含む 4500時間（2年弱）のプロジェクトを指揮・監督する立場での実務経験 〇 60か月のプロジェクトマネジメント経験を含む 7500時間（3年強）のプロジェクトを指揮・監督する立場での実務経験 〇 35時間のプロジェクトマネジメント研修 〇 〇 また資格を取得後も、3年以内の更新が求められます。 上記の通り、高難易度の資格ではありますが、対外的に高いプロジェクトマネジ メントス キルを証明することができるでしょう。 そしてより PMBOK の知識エリアとプロセスへの理解が深まることと思います。 受験資格のある方は、ぜひトライしてみていただければと思います。 PMBOK の知識エリアとプロセス 知識エリアとプロセスの関係性 さて、ここから本題である PMBOK の知識エリアとプロセスの説明に入っていきます。 詳細は後述していきますが、まず PMBOK の知識エリア、プロセス群、プロセスの関係性を以下に示します。 縦軸が知識エリア、横軸がプロセス群、各セルの要素がプロセスです。 以降の説明の位置づけが分からなくなった際には、こちらのマトリクスに立ち返ってみてください。 立ち上げ 計画 実行 監視・コン トロール 終結 プロジェクト 統合 マネジメント プロジェクト憲章作成 プロジェクトマネジメント計画書作成 ・プロジェクト作業の指揮・マネジメント ・プロジェクト知識のマネジメント ・プロジェクト作業の監視・コン トロール ・統合変更管理 プロジェクト・フェーズの 終結 プロジェクト スコープ マネジメント ・スコープ・マネジメント計画 ・要求事項収集 ・スコープ定義 ・ WBS 作成 ・スコープ妥当性確認 ・スコープ・コン トロール プロジェクト タイム マネジメント ・スケジュール・マネジメント計画 ・アクティビティ定義 ・アクティビティ順序設定 ・アクティビティ資源見積り ・アクティビティ所要期間見積り ・スケジュール作成 スケジュール・コン トロール プロジェクト コスト マネジメント ・コスト・マネジメント計画 ・コスト見積り ・予算設定 コスト・コン トロール プロジェクト 品質 マネジメント 品質マネジメント計画 品質保証 品質コン トロール プロジェクト 資源 マネジメント ・資源マネジメント計画 ・アクティビティ資源の見積り ・資源の獲得 ・プロジェクト・チーム育成 ・プロジェクト・チーム・マネジメント 資源のコン トロール プロジェクト コミュニケーション マネジメント コミュニケーション・マネジメント計画 コミュニケーション・マネジメント コミュニケーション・コン トロール プロジェクト リスク マネジメント ・リスク・マネジメント計画 ・リスク特定 ・定性的リスク分析 ・ 定量 的リスク分析 ・リスク対応計画 リスク対応策の実行 リスクコン トロール プロジェクト 調達 マネジメント 調達マネジメント計画 調達実行 調達コン トロール プロジェクト ステークホルダー マネジメント ステークホルダー 特定 ステークホルダー ・マネジメント計画 ステークホルダー ・エンゲージメント・マネジメント ステークホルダー ・エンゲージメント・コン トロール プロセス群、プロセス プロセス群 まずはプロセス群（上記マトリクスの横軸）です。 ※正式にはプロジェクトマネジメント・プロセス群と呼びます。 PMBOK にはプロジェクトのライフサイクルと作業の位置づけによって、以下の5つのプロセス群を定義しています。 後述する知識エリアとのかけ合わせによって、どのプロセス群でどんな知識や作業が要求されるのかを考えることができます。 立ち上げ プロジェクトを定義した上で、 ステークホルダー から認可を得ます。 計画 プロジェクト目標を達成するための計画を作成します。 実行 計画に従ってリソースを調達し、プロジェクト作業を実行します。 監視・コン トロール 計画と実態の差異を継続的にチェックし、差異がある場合には解消を図ります。 終結 プロジェクトの成果物を受け入れ、プロジェクトを公式に終了します。 プロジェクトを通して得られたノウハウを、次回のプロジェクトに向けて蓄積します。 プロセス 上記のプロセス群には、円滑なプロジェクトマネジメントのために実行すべきアクティビティとして「プロジェクトマネジメント・プロセス」が定義されています。 20年時点の最新である PMBOK 第6版においては、プロセスは全49種類です。 例えばプロジェクト・スコープ・マネジメント知識エリアに属する「スコープ定義」プロセスであれば、プロジェクトで作成する成果物や品質基準を取り纏め、スコープ記述書に定義します。 全てのプロセスの詳細は今回は説明外とさせていただきますが、上記マトリクスの通り、上記の知識エリアとプロセス群のどこかに属する形となります。 ただし全てのプロセスを必ず実行しなければいけないわけではなく、マネジメント対象となるプロジェクトの特性に応じて必要なプロセスを取捨選択する視点が必要です。 10の知識エリア 次は知識エリア（上記マトリクスの縦軸）に関する説明です。 PMBOK ではプロジェクトマネジメントを行う上で必要となる要素を、10種類の知識エリアにまとめています。 10種類の内訳はQCD（Quality：品質、Cost：コスト、Delivery：納期）の3点に加え、目標達成に至るまでの6種類のコン トロール 対象、そしてプロジェクト全体を統合的に管理する「統合管理」となります。 ここから10種類の知識エリアと合わせ、それぞれに対応するプロセスを紹介していきます。 プロジェクト統合マネジメント 以降9種類の知識エリアで定義された各プロセスを統合する知識エリアです。 プロセスはプロジェクトマネジメント全体の枠組みに関わるものであり、全てのプロセス群で定義されています。 プロセス群 プロセス 立ち上げ プロジェクト憲章作成 計画 プロジェクトマネジメント計画書作成 実行 ・プロジェクト作業の指揮・マネジメント ・プロジェクト知識のマネジメント 監視・コン トロール ・プロジェクト作業の監視・コン トロール ・統合変更管理 終結 プロジェクト・フェーズの 終結 プロジェクト・スコープ・マネジメント プロジェクトで必要な作業内容、作業範囲を明確にするための知識エリアです。 プロダクト・スコープ（成果物の性質、機能）とプロジェクト・スコープ（必要な作業）の2観点におけるプロセスが定義されています。 プロセス群 プロセス 計画 ・スコープ・マネジメント計画 ・要求事項収集 ・スコープ定義 ・ WBS 作成 監視・コン トロール ・スコープ妥当性確認 ・スコープ・コン トロール プロジェクト・タイム・マネジメント プロジェクトをスケジュール内に完了させるための計画やコン トロール などのプロセスを定義した知識エリアです。 プロセス群 プロセス 計画 ・スケジュール・マネジメント計画 ・アクティビティ定義 ・アクティビティ順序設定 ・アクティビティ資源見積り ・アクティビティ所要期間見積り ・スケジュール作成 監視・コン トロール スケジュール・コン トロール プロジェクト・コスト・マネジメント プロジェクトにかかるコストを計画し、予算内でプロジェクトを完了させるための知識エリアです。 4つのプロセスが定義されています。 プロセス群 プロセス 計画 ・コスト・マネジメント計画 ・コスト見積り ・予算設定 監視・コン トロール コスト・コン トロール プロジェクト・品質・マネジメント プロジェクトの成果物とその作成プロセスの品質をマネジメントするための知識エリアです。 品質要求を定める、要求を実現するための方法を定める、等の3つのプロセスが定義されています。 プロセス群 プロセス 計画 品質マネジメント計画 実行 品質保証 監視・コン トロール 品質コン トロール プロジェクト・資源・マネジメント プロジェクトを円滑に遂行するために、ヒトやモノの資源を適材適所に配置してマネジメントするための知識エリアです。 PMBOK 第6版より知識エリアの名称が「人的資源」から「資源」へと変更されました。 プロセス群 プロセス 計画 ・資源マネジメント計画 ・アクティビティ資源の見積り 実行 ・資源の獲得 ・プロジェクト・チーム育成 ・プロジェクト・チーム・マネジメント 監視・コン トロール 資源のコン トロール プロジェクト・コミュニケーション・マネジメント この知識エリアではメンバー、クライアント、その他 ステークホルダー 間のコミュニケーションを円滑に行い、縦横の情報連携をマネジメントするためのプロセスが定められています。 プロジェクトで発生する情報の収集、共有などのチャネルを作成し、 ステークホルダー 間のコミュニケーション上の問題点を解消するための知識エリアです。 プロセス群 プロセス 計画 コミュニケーション・マネジメント計画 実行 コミュニケーション・マネジメント 監視・コン トロール コミュニケーション・コン トロール プロジェクト・リスク・マネジメント 発生するとプロジェクト進行に影響を及ぼす不確実性を特定し、必要な対応策（回避・転嫁・軽減・受容）を講じるための知識エリアです。 リスクにはポジティブな好機・ネガティブな脅威の両方が考えられますが、出来る限り脅威を排除しつつ、好機を最大化することが求められます。 プロセス群 プロセス 計画 ・リスク・マネジメント計画 ・リスク特定 ・定性的リスク分析 ・ 定量 的リスク分析 ・リスク対応計画 実行 リスク対応策の実行 監視・コン トロール リスクコン トロール プロジェクト・調達・マネジメント プロジェクトの成果物を内製ではなく、外部に依頼や調達をして作成する際のマネジメントを行うためのプロセスを定義している知識エリアです。 3種類のプロセスの中で取り扱うのは発注先の選定、 RFP （Request for Proposal）の作成、 進捗管理 など、内容は多岐に渡ります。 プロセス群 プロセス 計画 調達マネジメント計画 実行 調達実行 監視・コン トロール 調達コン トロール プロジェクト・ ステークホルダー ・マネジメント プロジェクトの ステークホルダー （利害関係者）との関係構築を行い、プロジェクト目標の達成に向けてポジティブな効果を促進するためのマネジメントを定めた知識エリアです。 第5版から新たに追加されました。 ステークホルダー を特定し、各人の期待値を調整するためのプロセスが定められています。 プロセス群 プロセス 立ち上げ ステークホルダー 特定 計画 ステークホルダー ・マネジメント計画 実行 ステークホルダー ・エンゲージメント・マネジメント 監視・コン トロール ステークホルダー ・エンゲージメント・コン トロール PMBOK を活用していく際の注意点 ここまで紹介しました PMBOK の5つのプロセス群と10の知識エリアを理解することで、経験の浅いプロジェクトマネージャーでも「基本の型」をもってプロジェクトマネジメントを行うことが可能となるでしょう。 企業でも PMBOK をベースとした教育を行うことで、一定の知識を備えたマネジメント人材を輩出できるはずです。 しかしながら冒頭でもお伝えした通り、プロジェクトとは過去の事例にはない独自性を備えた取り組みです。 プロジェクトの性質や外部環境の変化によって、 PMBOK の知識だけでは対応しきれないイレギュラーな事態が発生することは考えられます。 基本の型を超えたより応用的な対応力が求められることもあるでしょう。 あらゆる事態に 臨機応変 に対応するには PMBOK のみならず、場数を踏んで経験することでしか得られない判断力や、個人の 人間力 が必要であることは念頭に置いておくべきと考えます。 おわりに 今回は知識エリアとプロセスの紹介を中心に、 PMBOK の基礎知識を説明してまいりました！ PMBOK の体系化されたプロジェクトマネジメントの知識は、プロジェクトの規模に関わらず恩恵を感じられるシーンがあるはずです。 本記事の内容が多くのプロジェクトのお役に立てますと嬉しいです。 それでは！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

技術広報の syoneshin です。 今回は当社の開発組織メンバー達に 読んでよかった 自身が影響を受けた 他者にも読んでほしいと思った という観点で 『おすすめの技術書』 とおすすめポイントを聞きました。 質問：皆さんの「おススメの技術書」 を教えてください。 【目次】 おすすめの技術書ランキング 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 『マスタリングTCP/IP 入門編』 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践』 『達人プログラマー 職人から名匠への道』 『Webを支える技術』 『SQLアンチパターン』 『Java言語で学ぶデザインパターン入門』 『はじめて学ぶ　ソフトウェアのテスト技法』 『UNIXという考え方―その設計思想と哲学』 『Effective Java』 『内部構造から学ぶPostgreSQL 設計・運用計画の鉄則』 『リファクタリング―既存のコードを安全に改善する―』 『現場で役立つシステム設計の原則』 『レガシーコード改善ガイド：保守開発のためのリファクタリング (Object Oriented SELECTION)』 『3分間HTTP&メールプロトコル基礎講座』 まとめ おすすめの技術書ランキング 以下は当社の開発組織メンバーが選んだ「おすすめの技術書ランキング」です。 調査概要 調査手法:任意アンケート( ヒアリ ングシート)※複数回答可 調査対象:当社開発組織メンバー(テッ クリード ・開発マネージャー含む) 調査項目:2020年10月以前に出版された技術書 有効回答数:66名 ランキング内容:得票数6票以上の技術書 Rank 書籍名 得票数 1 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 12 2 マスタリング TCP/IP 入門編 11 3 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性 が生まれる原理と対策の実践 10 4 達人 プログラマー 職人から名匠への道 8 4 Webを支える技術 8 4 SQL アンチパターン 8 4 Java 言語で学ぶ デザインパターン 入門 8 8 はじめて学ぶ　ソフトウェアのテスト技法 7 8 UNIX という考え方―その設計思想と哲学 7 8 Effective Java 7 8 内部構造から学ぶ PostgreSQL 設計・運用計画の鉄則 7 12 リファクタリング ―既存のコードを安全に改善する― 6 12 現場で役立つシステム設計の原則 6 12 レガシーコード改善ガイド：保守開発のための リファクタリング (Object Oriented SELECTION) 6 12 3分間HTTP&メール プロトコル 基礎講座 6 当社で得票数1位の技術書は 『リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)』 世間一般的にも名著としてよく取り上げられる技術書 当社でも若手からテッ クリード まで幅広い支持 以下はおすすめコメント プログラムを書く上で知っておくと良い心構えを知ることができるおすすめの１冊です。もっと早く知りたかったと思うことが多々書いてありました。 お作法や書く時に気をつけることは1年目に読んでとても参考になった技術書です。 プログラムの基本的な考え方を知ることができ、おすすめです。 多くの プログラマー が読んだ技術書ということもあり、共通認識として読んでおくといいかもしれません。 etc 次いで、得票数2位の技術書は 『マスタリング TCP/IP 入門編』 こちらも若手必読の古典 こちらも幅広い支持 以下はおすすめコメント プロトコル 、インターネット、ネットワークについての理解が深まるおすすめの1冊。 ネットワークに関する基本知識はこれで身につく。 おすすめです。 ネットワークの基礎がやさしくまとめられている。 etc 得票数3位の技術書は 『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性 が生まれる原理と対策の実践』 こちらも若手必読の技術書 こちらも幅広い支持 以下はおすすめコメント Webアプリケーションのセキュリティに関する内容が詰まったおすすめの１冊。Webエンジニアならこの技術書を一度は読んでおきたい。 Webアプリケーションのセキュリティの基本が詰まった内容。基本的なセキュリティの知識はつけることができる。 etc 次いで得票数が同率4位の技術書4冊 『達人 プログラマー 職人から名匠への道』 主にテッ クリード 達が支持 おすすめコメント 著名なエンジニアが言っていること、やっていることが全てこの本に書かれていると感じました。理想のエンジニアに近づくためのマインドとふるまい方を教えてくれる本と言えます。 プログラムのお作法だけでなく、エンジニアとしてのマインド、のみならず、ビジネスマンとして重視すべき考え方などが広範囲にまとめられている 若手の方だけでなく、ベテランの方も初めて読む（ないし読み返す）と共感して自分の仕事や開発の仕方を再整理することができるとおもいます 仕様書やテスト項目書の書き方は教わるが、どうすればよい プログラマ になれるのかは分からなかった時 自分の会社の中ではなく、世界の「よい プログラマ 像」とそこに近づくためのヒントを教えてくれた。 etc 『Webを支える技術』 おすすめコメント Webアプリケーション開発に必要な基礎知識が一通り含まれている。 Web技術の進歩によって日常生活を大きく影響を与ええてきた歴史に触れることができました。 etc 『 SQL アンチパターン 』 おすすめコメント 読んだ当時は純粋な読み物として楽しんでいましたが、自分が実施したテーブル設計を後から見返すと SQL アンチパターン に影響されている部分が大きいと感じています。 DB設計における実践的かつ幅広いトピックが網羅されている必読の技術書。 etc 『 Java 言語で学ぶ デザインパターン 入門』 おすすめコメント 概念に名前を付けることのパワーを知ったおすすめの１冊。インターフェースで抽象化して 疎結合 にする意義や パターン名を知っていることで他者や フレームワーク のコードをすんなり理解できることを教えてくれた。 著者の“読者に理解させる”文章術がすごい。 有名な技術書だけあってとても丁寧にわかりやすく書かれている。 デザインパターン に初めて触れて「こんな考え方もあるんだ」と知るのに最適。 デザインパターン について知ることができます。古い技術書で書き方がやや古いところも多いですが役に立つかと思います。 etc 次いで得票数同率8位の技術書4冊は 『はじめて学ぶ　ソフトウェアのテスト技法』 おすすめコメント 自分がテスト書く時、すでにあるテストがどういう観点で書かれているかを把握するの役立ちました。スタンダードなパターンが網羅されていますし、初心者にも読みやすかったです。 始めは観点がわからないと思うので、テスト観点を体系的に学べるのがよさげです。 etc 『 UNIX という考え方―その設計思想と哲学』 おすすめコメント UNIX がなぜ優れているかを改めて整理したうえで、良いソフトウェアはどのような構造であるべきかを考えるきっかけになります。 「Small is beautiful.」「Make each program do one thing well.」は常時心に留めておきたい考え方。 小さく作ることがなぜ大切なのかを学ぶことができた。本を読みながらずっと心に響いていたのを記憶しています。 etc 『Effective Java 』 おすすめコメント 定番。第3版ではStreamや ラムダ式 など新しい機能への言及が追加。 Java エンジニアは必読の技術書。 Java の正しい理解と、簡潔で明瞭で正確なソフトウェアの設計に役立ちます。 etc 『内部構造から学ぶ PostgreSQL 設計・運用計画の鉄則』 おすすめコメント 実務で応用できる情報が項目毎に章立てされており、実際の業務で運用トラブルが発生した際に役にたった 高負荷時の原因箇所特定時の仮説の種がこの書籍から得られた。 PostgreSQL の全体像や仕組みから、運用に関する機能も記載されている。一回では理解できず、今もできていないこともあるので何度も読み返して理解したい。 データベースの基礎知識がある状態で読むと、 PostgreSQL の特徴などがよく理解できると思います。運用トラブル発生時は避けて通れない独特の仕様や用語などについても解説されており、関連知識を深めていく上でもよいインプットになると思いました。 etc 次いで得票数同率12位の4冊は 『 リファクタリング ―既存のコードを安全に改善する―』 おすすめコメント リファクタリング の仕方だけでなく、可読性や変更しやすいコードを書く方針を学べるよい本だと思います。 作って終わりではないことを知ったおすすめの１冊。洗練されたコードは一発で生まれるのではなく コードの内部品質を継続的に改善することで生まれると教えてくれた。 具体的なサンプルコードとともに、いろいろな リファクタリング の型を知ることができる。 安全に リファクタリング するための具体的なテクニックや心構えについて記載されており、コアロジックを大改修する際にめちゃくちゃ参考にさせてもらいました。 etc 『現場で役立つシステム設計の原則』 おすすめコメント オブジェクト指向 っぽい設計や書き方を、手続き型と対比してのメリットと実例が合わせて書かれている。 VOやEntityなどDDDのエッセンスも含まれている。 現場で設計し続けたエンジニアのこだわりを感じたおすすめの１冊。型を第一にシステム設計するとはどういうことかを教えてくれた。 著者の振り切った主張には、経験のあるエンジニアであれば必ず賛成できるものと反対したくなるものがあり その考察がシステム設計に対する自身の考えを一歩前進させるきっかけになった。 etc 『レガシーコード改善ガイド：保守開発のための リファクタリング (Object Oriented SELECTION)』 おすすめコメント レガシーコードに立ち向かっていくための手法が色々記載されている。 構造が複雑で理解できないようなコードに対する分析手法・対処方法が学べる。 etc 『3分間HTTP&メール プロトコル 基礎講座』 おすすめコメント 担当プロダクトでは課題図書に選定されていますが、個人的に一番勉強になった書籍。Web上ではどういったやり取りがされているのか、などは新人にはイメージしづらい領域かと思いますが、比較的わかりやすくまとまっていると思いました。図解が多いのもポイント。 登場人物2人の対話形式なので、理解しやすい。 2010年刊なので、HTTP/2などの新しい技術の説明はないが、 プロトコル の基礎を学ぶには十分。 etc その他にも 『基礎から学ぶ Vue.js』 『暗号技術入門 第3版　秘密の国のアリス』 『 テスト駆動開発 』 『エリック・ エヴァ ンスの ドメイン 駆動設計 (IT Architects’Archive ソフトウェア開発の実践)』 『マイクロサービス アーキテクチャ 』 の技術書が、一定の得票数を獲得しました。 まとめ 以上、いかがだったでしょうか。 今回ご紹介しきれなかった技術書は 次回の「番外編」でご紹介しようと思います。 当社開発組織では 業務に必要な技術書の購入と読書会の企画など 技術書に学ぶ機会の支援をしております。 社内読書会の様子 tech-blog.rakus.co.jp tech-blog.rakus.co.jp また学びを発信する機会として Meetupなど技術イベントを積極的に企画し メンバーが自己研鑽しやすい環境整備に力を入れ取り組んでおります。 当社の活動に少しでもご興味をお持ちいただけましたら、イベントにも是非ご参加ください。 主催イベント rakus.connpass.com 本記事でご紹介した おすすめの技術書 が皆さまの情報探索の一助となれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle

はじめに こんにちは。最近お気に入りのお店が閉店してしまい、悲しみに暮れています。 楽楽勤怠バックエンドチームの mako _makokです。 バックエンドチーム所属ではありますが、諸事情で数ヶ月間フロントエンドヘルプとしてTypeScriptでフロントエンドの開発を行っていました。 今ではある程度にTypeScriptを書けるようになったものの、ヘルプ当初は実務として初めてのTypeScriptを用いた大規模フロントエンド開発だったので、早期にキャッチアップする必要がありました。 今回は私がTypeScriptに入門する上で注意すべき点と実際に学習に使用したおすすめの学習教材を紹介したいと思います。 はじめに TypeScriptとは 型の恩恵 1. undefinedが激減してメンテナンスが容易になる 2. 補完を使ってサクサク書ける 3. 型がドキュメントになる 型システムを学習する上での注意点 JavaScript, TypeScriptの学習媒体について JavaScript入門したい方におすすめ JavaScript Primer TypeScript Playground 1. TypeScript Deep Dive 2. 実践TypeScript 3. プログラミング TypeScript 4. Type Challenge 最後に TypeScriptとは TypeScriptとは、動的型付け言語である JavaScript に静的型付けの概念と、一部独自の構文を取り入れた世界的に人気のある プログラミング言語 です。 *1 JavaScript のスーパーセットなので、 ECMAScript 最新仕様や JavaScript の記法がそのまま使えます。 TypeScriptで特徴的なのは型の表現力の高さです。値や数値そのものを型として扱ったり、既存の型から新しい型を作成したりなどができます。以下は型と型を合体できる Union Type という機能の一例です。 type Juice = 'Orange' | 'Apple' | 'Grape' const juice: Juice = 'Cake' // 'Orange', 'Apple', 'Grape'という文字列しか受け付けない type Coffee = 'Cappuccino' | 'American' // Juice型とCoffee型をくっつけてDrink型を生成する type Drink = Juice | Coffee // => 'Orange' | 'Apple' | 'Grape' | 'Cappuccino' | 'American' これ以外にもTypeScriptには多彩な型に関する機能や組み込み型があり、型を柔軟に操作することができます。 型の恩恵 型が柔軟なのは分かったけど、そもそも型をつけてなんのメリットがあるんだという話です。 これについては人によって様々な意見があると思いますが、個人的には以下の3点がメリットと考えています。 JavaScript においてはundefinedが激減してメンテナンスが容易になる 補完を使ってサクサク書ける 型がドキュメントになる 1. undefinedが激減してメンテナンスが容易になる 複数人で開発している以上、自分の知らないところでいつの間にかプロパティが増減しているなんてことは日常茶飯事です。依存関係があるオブジェクトをいじっていたらいつの間にかundefinedになってしまうこともよくあります。 一方で、型があれば、オブジェクトの構造は一発でわかります。 2. 補完を使ってサクサク書ける オブジェクトの構造が事前に分かっているということは、 IDE の補完が効きます。 これはつまり、numberを parseInt() しようとする無意味なコードを生み出さないことにも役立ちますし、存在しないプロパティにアクセスしようものなら コンパイル エラーとして怒ってくれます。 3. 型がドキュメントになる 型はドキュメントになります。 例えば、オブジェクト構造はuserと一緒だけど、申請画面のコードなので申請者を表すapplicantという変数を使用したとします。 型がなければapplicantってどんなオブジェクト構造なんだろうと辿るところから始まりますが、型があった場合は const user: User = { ... } const applicant: User = { ... } となり、変数名は違うけどどちらも同じUserオブジェクトなんだなと一発でわかります。 これを JavaScript で表現しようとすると、変数名を工夫するかコメントを書く必要がありますが、上記の型があるコードは短い記述で表現できます。 型システムを学習する上での注意点 TypeScriptには様々な機能がありますが、知らないまま使ってしまうと危険な機能がいくつかあります。 入門レベルのうちにVueやReactなどのライブラリを用いた開発を行っていると、以下のような問題に突き当たることになることがあるのではないかなと思います。(私はよくありました・・・) なんか型が原因でエラーを吐いているけどエラーが長くて何を直せばいいかわからない ライブラリの型を使ったらよくわからないけどエラーになってとりあえず any を使っちゃう 例えば1のような場合、 コンパイル エラーを解消するのは簡単にできます。 TypeScriptにはどのような値も許容するという any 型と、型を上書き(キャスト)する 型 アサーション という機能があります。 以下は良い例 *2 で、HTTP通信を行い、取得したデータを型 アサーション でキャストしています。 REST API による外部との通信のため、アプリケーションに型を伝えられずレスポンスの型としては any となってしまいますが、User型のオブジェクトだということが分かっている、という前提で使用しているためです。 function getUser ( id: string ) : User { // data はany型 const { data } = get( `https://example.com/user/ ${ id } ` ) // `as 型名`で型アサーション return data as User } 上記のような使用方法はとても有効的なのですが、以下のような使い方もできてしまいます。 const department: Department = getDepartment ( '1' ) const user: User = department as any as User Department 型のオブジェクトを取得し、 any 型に変換した後 User 型に変換しています。 これは コンパイル エラーにはなりません。 Department => any と、 any => User に互換性があるからです。 any はどのような値も許容するため、全ての型に互換性があります。 これは簡単な例ですが、ライブラリを扱い始めると複雑な型が出現し、「解決に時間かかりそうだしとりあえず any に アサーション してみるか・・・ｵｯなんか動いたしこれでいいか！」となるかもしれません。 これは当たり前ですが、実行時エラーの温床になっていくだけです。なんか動いているのは JavaScript のエンジンが賢いだけで、そのうちどこかで崩壊してしまうかもしれません。 TypeScriptに限った話ではありませんが、知らずに使用すると危険なコードを書いてしまう可能性があります。 後述する学習媒体では、このような機能を正しく知り、効果的に使用する方法を学ぶことができます。 JavaScript , TypeScriptの学習媒体について では具体的にどうやってTypeScript, JavaScript に入門していくかです。 TypeScriptはとても人気な言語で、資料もたくさんあります。 JavaScript はとても歴史が長いので、古くなってしまった資料なども多くあります。 実際私も資料探しにはかなり苦戦しました。資料が多く、これから入門する方からすればどれがいいかわからないのかは当たり前です。 様々な 有識者 の方にご教授いただき、私が JavaScript , TypeScriptに入門し、学習していく中で特に参考になったwebサイトや書籍を紹介します。 JavaScript 入門したい方におすすめ JavaScript Primer jsprimer.net これから JavaScript に入門したい、または JavaScript を雰囲気で書いているという方におすすめのwebサイトです。 JavaScript を体系的に、かつ実践的な使用方法を学ぶことができます。 これ1つで JavaScript の基本はマスターできます。 JavaScript の書籍をいくつか読みましたが、 JavaScript Primerは本当に必要なことだけを抽出し、実際の業務で役立つTipsなどが豊富です。 例えば、変数と宣言の項で var の使用は避けるべきということが書いてあったりします。普段 JavaScript を書いている方からすると当たり前かもしれませんが、入門者的には エビデンス 付きで説明してくれている教材はありがたく、とても貴重です。 もちろん非同期処理についても深く触れられており、 Promise や async/await への理解にとても役立ちました。 私も実務では MDN と併せてバイブルにしていました。 応用編ではVanilla JSでアプリケーションを構築する話で、 コンポーネント の実装まで行っていますが、TypeScriptの学習という点においてはあまり関係が無いので進めるかどうかは好みです。 ちなみに、書籍版もありますので、紙で読みたいという方はこちらもどうぞ。 https://www.amazon.co.jp/dp/4048930737/ www.amazon.co.jp TypeScript Playground www.typescriptlang.org JavaScript Primerで JavaScript の基本はマスターできたと思うので、次はTypeScriptに入門していきましょう。 言語の勉強をするためにはやはり自分の手で書くのが一番です。書くためには実行環境を用意しなければなりませんが、そんなときは TypeScript Playground を利用することで、即座に実行環境を用意することができます。 このPlaygroundの良いところは、TypeScriptの コンパイル 結果などを右のペインに表示してくれることです。 TypeScriptが コンパイル された結果どのような JavaScript が出力されるのか確認することができます。 enum など、 JavaScript にない機能がどのように コンパイル されるかを見るだけでもとても勉強になります。 ※ 以降のタイトルにナンバリングしていますが、番号の順に読んでいくのが良いのではないかと筆者は勝手に思っています。 1. TypeScript Deep Dive typescript-jp.gitbook.io 鉄板のWebサイトです。TypeScript commiterの方が書いてくださっているドキュメントで、有志の方たちによって日本語化もされています。 基本的にTypeScriptへの入門向けの解説が多いため、とても分かりやすく、基本的な使い方はここで学べるようになっています。 また、テストツールや周辺ライブラリへの簡単な解説などもあるので、発展的な内容や実務で使う際への足がかりになります。 TypeScriptに入門する上では欠かせないwebサイトです。 2. 実践TypeScript www.amazon.co.jp TypeScript Deep Dive を学習したあなたはTypeScriptの入門レベルを既に超えています。 次の一歩に踏み出すためには実践TypeScriptがおすすめです。 実践TypeScriptでは、実際にTypeScriptとVueやReactなどのライブラリを使用してアプリケーションのコードを書く際に非常に参考になる一冊です。 導入編と実践編の2章構成で、TypeScript Deep Diveを学習された方なら導入編の方の最初の方はサクサク進めることができるんじゃないかと思います。導入編の後半では、 Conditional Type や Mapped Type といった難易度の高い型 組み込み型の使用方法 の項目があります。TypeScript固有の書き方なので少しとっつきにくいですが、これらは型の操作やライブラリの型を読む上では欠かせないので、しっかりキャッチアップしたいです。 実践編になるとVueとReact、ユニバーサ ルフレ ームワークであるNuxt, NextへのTypeScriptの導入方法、それぞれの フレームワーク においてTypeScriptで良いコードを書くためのノウハウが書かれています。 サンプルコードが非常に豊富で、Vueの章なんかでは結構困りがちなVuexの型付けを筆者の方がほぼイチから書いているサンプルなどがあり、非常に参考になります。 3. プログラミング TypeScript https://www.amazon.co.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0TypeScript-%E2%80%95%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8BJavaScript%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E9%96%8B%E7%99%BA-Boris-Cherny/dp/4873119049 www.amazon.co.jp TypeScriptの言語仕様が体系的にまとまった一冊です。 最初はプリミティブ型のような簡単な項目から、前項でも少し出てきた Conditional Type や Mapped Type のより詳細を知ることができます。最後半になるとASTの API (TypeScriptのコードを解析する仕組み)まであります。 ASTはアプリケーションのコードを書く上では必要ないと思いますが、興味がある方は更に学習を深めてみてはいかがでしょうか。 実践TypeScriptと比較して、こちらは言語仕様がかなり詳しく書かれています。 また、こちらにも現場で役に立つTipsや デザインパターン が載っているため、実践TypeScriptと併せて読むのがおすすめです。 4. Type Challenge github.com Type Challenge では、型の実装にチャレンジすることができます。 ここまで学ばれた方はおそらくアプリケーションのコードを書くのに不自由ないレベルの知識は得られたのではないでしょうか。アプリケーションのコードでは自分で複雑な型を自作するというのは結構稀ではありますが、0では無いのでしっかり書けるようになりたいところです。 ここまで学習された方はおそらく、 Mapped Type や Conditional Type のような独自の記法でもなんとなく読めるし、ライブラリの型も結構イケる！くらいのレベル感だと思っています。ですが、実際書けるかどうかはあまり自信がありません。私もそうでした。 そんなあなたは Type Challenge に挑戦してみましょう。 まず、READMEの Challenges から取り組む問題を選択します。 Take The Challenge のラベルを押すとPlaygroundが開くので、問題で指定されている要件の型を作成しましょう。 テストケースも用意されているので、解答のチェックも簡単です。 問題をとき終わったらIssueを見てみましょう。他の方の解答を見ることができます。自信がある解答を作ることができた！という場合は自分の解答をIssueに投げてみましょう。後半の複雑な型の解法は自分が全く思いつかなかったものもあったりするのでとても面白いと思います。 最後に いかがでしたでしょうか。おそらくここまでやり込めば、TypeScriptの言語仕様はかなりキャッチアップできたのでは無いかと思います。その後はVueやReactのようなライブラリを学んだり、webpackなどの周辺ツールについて学ぶのも良いと思います。 私自身、TypeScriptどころか JavaScript 入門者でしたが、これらの書籍やwebサイトのおかげでTypeScriptへ入門し、業務で開発を行うことができました。この記事がTypeScript入門への足がかりになっていれば幸いです。また、学習する中でフロントエンドへの興味がより強くなったので、今後は各種ライブラリの学習や、 OSS へのコミットを目指してやっていこうと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : Stack Overflowの開発者の中で愛されている言語ランキング などでも2位を獲得しています。 *2 : 本来はキーのチェックやエラーのチェックを行う必要がありますが簡略化のため省略しています

こんにちは、株式会社 ラク スで先行技術検証や、ビジネス部門に技術情報を提供する取り組みを行っている技術推進課に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 改め 「技術推進プロジェクト」 というプロジェクトがあります。 2020年度は通年で「無停止リリース」について取り組んでいるので、途中ではありますが紹介したいと思います。 今までの記事はかみせんカテゴリからどうぞ。 tech-blog.rakus.co.jp 今回の目標 「無停止リリース」の定義 考慮するポイント セッション管理 リリース中のログインセッション維持 古いバージョンのログインユーザーのみ強制ログアウト可能 アプリケーション構成 リリース中の処理トランザクションの正常終了 リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない DB運用 どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること まとめ 今後の計画 今回の目標 弊社のサービスはBtoBのサービスであることもあり、多くのユーザーが営業時間外となる夜間に計画停止を行ってのリリースを行っていました。 しかし今後サービス規模の増大にともない、極力停止しないリリースが求められることや、エンジニアの夜間作業を避けるために、リリース時も極力サービスを止めない構成を模索します。 「無停止リリース」の定義 完全な無停止を目指すと大規模な分散システムにするなどコスト面で厳しい構成になると考えられたので、あくまで「ユーザーの利便性を極力損なわずにサービスを提供し続ける」という方針で検討しました。 具体的には以下のような要件を挙げています。 ユーザビリティ の確保 ログインセッションが切られることなくログイン状態を維持できる 操作内容が「なかったこと」にならないようにする システム的な完全無停止は目的にしない 内部的な停止は局所化極小化を目指す 影響がでる部分についてUI側でフォロー可能な構成を目指す プログレスバー を出せるようにする 処理完了ではなく処理受付としてレスポンスを返す など 考慮するポイント 「 ユーザビリティ を低下させない」要件をもう少し噛み砕くと以下のような要素にまとめられると考えました。 セッション管理 リリース中もログインセッションが切断されない 古いバージョンのログインユーザーのみ強制ログアウト可能 アプリケーション構成 リリース中も処理 トランザクション が正常終了する リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない DB運用 どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること セッション管理 セッション管理において リリース中もログインセッションが切断されない 一定期間経過後に古いバージョンのログインユーザーのみ強制ログアウト可能 という要件を満たす方法を考えました。 リリース中のログインセッション維持 まず「リリース中にログインセッションが切断されない」ということを逆に考えると、なぜリリース作業においてログインセッションが途切れるのかという話になります。 もっともシンプルなログインセッションの保持方法は アプリケーションサーバ ーに保持させることですが、この場合は保持している アプリケーションサーバ ーを再起動してしまうとログインセッションが失われます。 そこでログインセッションの保持を アプリケーションサーバ ーの外に出す必要があります。データベースサーバーに保持することで アプリケーションサーバ ーの再起動の影響を受けない データベースサーバーの再起動でも（正副サーバーのデータを同期しているので）消失しない とリリース中のログインセッション維持は実現できそうです。 ただ実現は出来るものの、ログインセッションの破棄処理をアプリケーションに実装する必要が生まれたり、頻繁なデータベースアクセスが発生してしまうという課題が生まれます。 これらを解決するためにRedisをセッションサーバーとして採用することを検討しました。 クラウド ネイティブな構成では（ AWS だとElastiCacheを利用して）比較的よく採用される構成だと思います。 Redisを採用するモチベーションとしては以下の点が挙げられます。 インメモリデータベースなので小さなデータを頻繁にアクセスする用途に最適 key- value 型のDBだけどログインセッションの維持に使うなら十分 レコードに TTL : Time To Live(有効期限)を設定することで自動破棄ができる TTL は更新も可能なので「最終アクセスから n 秒」という指定が容易 DBで保持したときのように 冗長化 も可能 古いバージョンのログインユーザーのみ強制ログアウト可能 バージョンが混在しても利用可能にはするものの、いつまでも古いバージョンからのアクセスを有効にし続けるわけにもいきません。いずれは古いバージョンのログインセッションを破棄する必要があります。ただしこのときも新しいログインセッションには影響を出したくありません。 これを実現するために「ログイン処理をどのバージョンで行ったか」を記録することで実現できると考えました。セッションデータにアプリケーションバージョンのデータを残すのです。 " (token_id) ": { " user_id ": xxxxxxxxx , " app_ver ": 1.0 } のようなイメージです。 これによりセッションサーバーから { "app_ver": 1.0 } のログインセッションを削除するなどして、指定したバージョンでログインセッションを維持しているユーザーのみを強制ログアウト可能にします。 アプリケーション構成 アプリケーション構成において リリース中も処理 トランザクション が正常終了する リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される 入力パラメータの過不足がある場合に異常な更新が行われない という要件を満たす方法を考えました。 リリース中の処理 トランザクション の正常終了 こちらは言い換えると処理中 トランザクション の完了を待ってからリリース処理をしてあげればいいわけなので、リク エス ト振り分けを止めて待ってあげればいいです。 HTTP Proxyで振り分け制御をするわけですが、リリースの開始判断は人間がやるとしても振り分け制御自体は自動でやりたいです。実現するための機能としては振り分け先ノードのステータスを判断するActive Health Checkと、リク エス トが完了するまで切断しないDraining Modeを使ってあげれば実現できます。 当初この部分に nginx を利用しようとしていましたが、Active Health CheckとDraining Modeがnginx+（有償版）でないと使えないということがわかりました。システム構成的にコストが見合わなかった 1 ので、別のソリューションを探すことにしました。そこで Apache を確認してみると無償版でも利用できるということだったので、 Apache を採用しています。 なお Apache はnginxの普及以降「重い」という印象がありましたが、 Apache 2.4系を評価し直してみると既に改善されているようだったことも今回の採用につながっています。 リリース前後のサーバーが混在している状態でいずれの環境にアクセスしていても正常に処理される API バージョンを複数サポートするという話ですが、試行錯誤した結果サンプル実装では以下のような ソースコード の構成にしています。 / |--app.py # Webアプリ本体。`v1/api.py`を読み込み |--README.md |--requirements.txt |--v1/ # APIバージョン:1 のソースコードディレクトリ | | # v3 を作るときに削除される想定 | |--__init__.py | |--api.py # エンドポイントを定義 | |--assets.py # 実処理モジュール | |--auth.py # 実処理モジュール | |--users.py # 実処理モジュール |--v2/ # APIバージョン:2 を作るときは v1 をコピーして改修 ウェブアプリケーション フレームワーク に用意されている、パスを指定して ルーター モジュールを読み込む機能（Path Groupとか呼ばれる機能。FlaskだとBlueprint）でバージョンごとのモジュールを読み込みます。 # app.py #... # バージョンごとのAPI読込 from v1.api import api as api_v1 app.register_blueprint(api_v1, url_prefix= '/api/v1' ) # ... # v1/api.py from flask import Flask, Blueprint, jsonify # 実処理モジュールの読み込み from . import auth from . import users from . import assets api = Blueprint( 'api' , __name__) # エンドポイントの定義 @ api.route ( '/signup' , methods=[ 'POST' ]) def post_signup (): return auth.post_signup() # ... API バージョンが変わる際にはまるごとコピーして別バージョンとして読み込む形になるので重複コードが発生しますが、今回は2バージョン（最新と1世代前）までしかサポートしない想定だったので許容しています。無理に重複コードをなくすことよりも、2世代前のサポートが外しにくくなることを避けることを優先しました。 入力パラメータの過不足がある場合に異常な更新が行われない 無停止でアップデートを行うと、 API リク エス トに必要なパラメータが異なったバージョンのアプリケーションにWebクライアントが接続されるケースが出てきます。この場合にも不正なデータ更新は行われないようにしなければなりません。 必須パラメータが不足するような組み合わせであればエラーになるため、データの更新は行われません。エラー後に最新バージョンの取得と再ログインを促せれば操作を続けられます。 エラーも発生させたくない場合があると思いますが、その場合は API バージョンを変えて2バージョン受け付けられる状態にすることになります。このとき2バージョンの差異をアプリケーションとDBで吸収しなければなりませんが、どんな場合に吸収できて、どんな場合に吸収できないのかは今後検証していきたいと思います。 DB運用 DB運用について どのタイミングでもクエリが消失せずに整合性が保たれること どのタイミングでもDBにアクセスできること 再起動中やフェールオーバー中もアクセスできること ブロックすることなく DDL 操作を行えること という要件を満たす方法を検討しました。 どのタイミングでもクエリが消失せずに整合性が保たれること こちらに関しては新たなクエリリク エス トだけを止めて処理中のクエリが完了するまでリリース担当エンジニアが見て判断する方針にしました。 現状の運用だと、リリースの際に完全に 無人 であることは考えにくく 機械的 に検知する必要性を感じなかったためにこの方針にしています。 新たなクエリリク エス トの停止についてはDBプロキシである MariaDB MaxScale（以下、MaxScale）を利用して振り分け処理を行う設計にしています。 MaxScaleにはフェールオーバー時にもアプリケーション側からの再試行を伴わずに、 トランザクション を喪失しないよう遅延、再試行を行う機能があります。 どのタイミングでもDBにアクセスできること こちらは想定している条件下では「書き込み」に関しては短時間の停止を避けられませんでしたが、片系が再起動中などでフェールオーバーが発生している場合などでも「読み込み」は常時可能になるよう設計を進めています。 MaxScaleによって参照クエリと更新クエリの分離、DBサーバーノードの管理・ 冗長化 を行います。 冗長化 されたDBサーバー クラスタ を構成することで、無停止で実行できない SQL 操作や DBMS 自体のアップデートがあった場合にもローリングアップデートで実行し、ダウンタイムを極力短縮する予定です。 この際「書き込み」はマスタのフェールオーバー中だけ実行できなくなりますが、「読み込み」は停止することなく常に実行できる見込みです。 また、DBに関しては DDL でどこまでロックされるかもシステム全体のアクセス可否に影響してきます。 MariaDB や MySQL は同じ OSS -DBである PostgreSQL と比較してオンライン DDL の対応で先行しています。 PostgreSQL ではカラム追加などのテーブル定義の変更操作は DML を（SELECTでさえ）阻害してしまいますが、 MariaDB / MySQL は多くの操作がオンライン DDL に対応しているため、テーブル定義の変更を伴う場合でもアクセスできることが期待できます。ただし、この手の機能は往々にして運用上の制約がつきものなので引き続き実際に動作させて検証していきたいと思います。 まとめ セッションサーバーにRedisを採用して外部化 HTTPプロキシに Apache を採用 アプリケーションは最大2バージョンに対応 DBMS は MariaDB を採用し、MaxScaleで クラスタ 化 MariaDB のオンライン DDL を活用 今後の計画 ここまでのお話はそれぞれの要素のカタログスペックを元にした設計です。これらが実際に期待した通りの挙動を実現してくれるのかどうかについては今年度後半で検証を進めていきたいと思います（検証結果も2021年3月ごろにブログで共有予定です）。 環境の構築 テスト項目、テスト方法の検討 本当に無停止でリリースできるか検証 （余力があれば） PostgreSQL の場合にどこまでできるか検証 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com 1ノード年間10万円。ノード数が多くなりがちなので厳しい料金体系でした。 ↩

はじめに こんにちは、tuq376sです。 今回は vim について紹介していきたいと思います。 vim というとあまり馴染みのない方には、他のエディタを使うよりも複雑で難しいという印象があるかもしれません。 しかし、あれもこれも覚えなければ基本的な使い方さえできないというわけでもないのです。 ということで、本記事では vim のインストールからファイルの基本操作までを取り扱っていきます。 はじめに インストール手順 vimインストーラーの入手とインストール 環境変数の登録 まずはここから、入力と保存 vimのモード カーソル移動と入力・保存 ファイル編集の基本操作 コピー&ペースト 取り消し&やり直し おわりに インストール手順 とにもかくにもインストールから。 今回は例として Windows にインストールする手順で行っていきます。 vim インストーラ ーの入手とインストール まずは vimの公式サイト へアクセスします。 左側のメニュー欄にダウンロードがあるので、そこから配布ページへ。 対象のOSを選べるので Windows を選択して、 インストーラ ーをダウンロードします。 ダウンロードが完了したら インストーラ ーを起動して、オプションの選択などは全てデフォルトの状態でインストールします。 完了すると、デスクトップにショートカットが作成されます。 ここから起動できるのは gvim と呼ばれる GUI で動く vim です。本記事では コマンドプロンプト から CUI の vim を使用していきますが、コマンドや操作の仕方は CUI で動く vim と変わりないようなので好みの方を利用すると良いと思います。 環境変数 の登録 vim を CUI で利用する場合は忘れずに 環境変数 も設定しておきましょう。 「コン トロール パネル > システムとセキュリティ > システム 」から、システムの詳細設定を選んで、 「 環境変数 」を選択、開いた画面の「システム 環境変数 」からPathを選択した状態で「編集」を押します。 環境変数 名の設定が開いたら「新規」を選んで、 vim .exeの場所を登録します。 デフォルトなら C:\Program Files (x86)\Vim\vim82 (82はバージョン名)にあるはずです。 環境変数 が登録できたら、 コマンドプロンプト を立ち上げて vim と入力してみましょう。 以下のような画面が立ち上がればセットアップ完了です！ まずはここから、入力と保存 では実際に vim を使っていきましょう。 vim は立ち上げただけの状態で文字の入力ができません。これは、 vim は起動された時は ノーマルモード だからです。 入力を行うには挿入モードに切り替える必要があります。 まずはこのモードからざっくりと説明していきます。 vim のモード vim にはいくつかのモードが存在し、モードによって操作できることが変わります。 よく使うものは以下の4つです。 ノーマルモード vim を起動したときの状態であり、全ての中心にあるモードです。 各モードに移動するには ノーマルモード を経由します。操作している間に意図しないモードになってしまったときは Esc を押すことでここに戻ることができます。 カーソルの移動、コピーやペーストなどができます。 挿入モード 文字を入力するためのモードです。このモードにいる間は各キーは文字入力として扱われます。 ノーマルモード から i , a などで切り替えることができ、どのキーで切り替えるかで入力位置が変わります。 コマンドモード ファイルの保存、 vim の終了などいろいろな操作を行うためのモードです。 ノーマルモード から : で切り替えます。コマンドを内容を入力したら Enter で実行します。 ビジュアルモード 主に範囲選択に関するモードで、範囲を選択したり、選択した範囲のコピーなどができます。 ノーマルモード から v などで切り替えることができます。慣れてきたら活用したいモードです。 初めはあまりピンとこないと思いますので、ひとまずはこんなモードがあるという認識だけで構いません。 カーソル移動と入力・保存 モードについて雰囲気がわかったところで、ようやくファイルの編集です。 まずは文字を入力するため、挿入モードに切り替えましょう。挿入モードに切り替えるキーは数ありますが、以下の3つを覚えれば困ることはありません。 挿入モードに切り替えたときの動作 キー カーソルの位置から文字を入力できる i カーソルの右側から文字を入力できる a カーソルの行末で改行した状態から文字を入力できる o これらのキーを入力すると挿入モードに切り替わり、 i , a , o も文字入力として認識するようになります。 しかし、挿入モードの間は入力位置を移動することができません。 入力位置を切り替えるためには一度 Esc を押して ノーマルモード に戻る必要があります。 ノーマルモード では、以下のキーでカーソルを移動できます。 移動先 キー ← h → l ↑ k ↓ j n行目 :n (10行目なら :10 ) 行頭 ^ 行末 $ n行目に移動する方法は厳密には コマンドモードで移動したい行数を入力する という動作になりますが、ここはあまり明確に意識することも少ないと思いますので、以降コマンドモードの入力は 先頭にコロンが付いているノーマルモードでの入力 として扱っていきます。 これで、任意の位置にカーソルを移動して文字の入力ができるようになりました。 次はファイルの保存と vim の終了方法です。以下の入力で行えます。 操作内容 キー 保存する :w vim を終了する :q 保存して vim を終了する :wq または ZZ 名前を付けて保存する :w ファイル名 ファイル編集の基本操作 ここまでできれば、ファイルの編集という最低限の機能は問題なく行えると思います。 けれどただ文字を入力できるだけではエディタとしては物足りないもの。どんなエディタにもあるような機能はもちろん vim にも備わっているので、こちらも紹介していきます。 コピー&ペースト 編集に必須機能その１、コピーとペースト。 vim ではこれを行う機能を「ヤンク」「プット」とそれぞれ呼びます。 まずは ノーマルモード だけで行える方法から見ていきます。 操作内容 キー n行をヤンクする nyy (10行コピーする場合は 10yy ) n行を削除する ndd (10行削除する場合は 10dd ) ヤンクしたものをプットする p ヤンクと削除は対象の行数を指定するようになっていますが、1行の場合は数字を省略して yy , dd とすることができます。 また、 dd については削除というよりは切り取りに近く、 yy したものと同様に p で貼り付けることができます。 しかしこれでは行単位でしか操作ができません。他のエディタならマウスを使って任意の範囲をコピーするところですが、 vim ではこれをビジュアルモードを使って行います。 ビジュアルモードは挿入モードと同じく、切り替えるキーによって動作が異なります。 ビジュアルモードに切り替えたときの動作 キー カーソル位置から範囲選択を行える v カーソル位置から矩形選択を行える Ctrl-v カーソル行から行選択を行える V ビジュアルモードでは ノーマルモード と同じカーソル移動を行えます。 v なら移動した位置までの文字を、 Ctrl-v なら移動した位置を対角に持つ短形範囲を、 V なら移動した位置までの行範囲をといった具合に範囲が選択されます。 選択した範囲に対して行える主な操作は以下です。 操作内容 キー 選択範囲をヤンクして ノーマルモード に移行する y 選択範囲を削除して ノーマルモード に移行する d 選択範囲を削除して挿入モードに移行する c 各入力はそれぞれモードを移行するようになっています。 c ならば挿入モードに移行し、任意の入力を行った後は通常の挿入モードと同じく Esc で ノーマルモード に戻ることができます。 これで、行単位でなくともヤンクとプットが行えるようになりました。 取り消し&やり直し 本記事最後となるのは、編集に必須機能その２、操作の取り消しとやり直しについてです。 それぞれの操作は以下のようになります。 操作内容 キー 操作を取り消す u もう一度操作する(取り消した操作を再度行う) Ctrl-r vim では複数の操作を戻ることができるため uu と入力することで2つ前の操作まで戻ることができます。 ところが vim の元で基本的な操作が同じエディタのviでは、戻ることのできる操作は1つのみです。viを使う際は uu と入力すると「操作を取り消す→取り消した操作を再度行う」という動作になるので注意が必要です。 おわりに 今回はインストールからということもあって、本当に基本的な操作だけを列挙する形になりました。 vim はもっと便利でバリエーション豊富なコマンドや操作、カスタマイズできる部分もたくさんあって、それゆえに推している方というのは多いのだと思います。 しかし自分の記憶を思い起こしてみると、使い始めてしばらくは「iで文字を入力してZZで保存して閉じる」くらいしか覚えられなかったというのもあって、本記事では「最低限のファイル編集に困らない程度」を目指すことにしました。 またいつか、今度はもう少し便利な使い方の紹介もしてみたいなと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに はじめまして、tsudachantanです。 現在、様々なサイトで広く使われている SVG ファイル。 CSS とともに SVG が必須になるともいわれ、デザイナーやフロントエンジニアの方にはお馴染みかもしれません。 今回は改めて、具体的にどのようなフォーマットのファイルなのか、特徴と変換方法について紹介していきます！ 目次 はじめに SVGファイルが普及しているワケ SVGファイルとは？ JPEG、PNG画像形式との違い メリット 拡張性・汎用性が高い！ フィルター、アニメーション表現が可能 デメリット SVGファイルの作成方法 PNGをSVGに変換してみよう SVGファイルをPNGに変換する方法 おわりに 　 SVG ファイルが普及しているワケ Webブラウザ 最大手の IE は長らく SVG に対応しておらず、 サポートされているブラウザが少ないことから普及しませんでした。 しかし現在、 IE9 をはじめ対応するブラウザが増えたことにより多くのホームページが活用しています。 また、近年はレスポンシブデザインと フラットデザイン が主流となっており、それらと相性のいい SVG ファイルの需要は高まっています。 SVG ファイルとは？ SVG （Scalable Vector Graphics)は画像フォーマットの一種です。 SVG ファイルはその名( Vector )の通り、ベクタ形式のデータです。 画像ファイルである SVG ですが、 XML に準拠しており、 テキストエディタ で編集することも可能です。 JPEG 、 PNG 画像形式との違い 画像ファイルとしてよく用いられる JPEG 、 PNG ですが、これらはラスタ形式の画像ファイルです。 ラスタ形式は点（pixel）で画像を表現しています。 こちらの PNG 画像をご覧ください。 PNG 画像 どんどん拡大していくと…… 拡大した PNG ギザギザとドットのようなものが見えてきますね。 画質を上げるためには点の数、つまり解像度を上げていく必要があり、データの容量も大きくなります。 編集を重ねると画像が劣化しやすく、ファイルサイズも大きくなりがちです。 一方、 SVG ファイルはベクタ形式の画像ファイルです。 ベクタ形式とは、画像や文字などの2次元情報を数値化して記録しており、ブラウザがその場で描画してくれます。 解像度を気にすることも、拡大縮小でデータが劣化することもありません。 主に、アイコンや地図、平面的なイラストなどを作成するときにはベクタ形式が採用されています。 メリット 拡張性・汎用性が高い！ Scalableの文字通り、伸縮可能性に優れた SVG は、後から色・サイズ・文字の変更が容易です。 レスポンシブなサイトを構築する際に、 PNG などのラスタ形式だとデ バイス 毎に複数のバージョンを作成する必要がありますが、 ベクタ形式の SVG を使えば1つのファイルで対応できます。 また、 SVG は Retinaディスプレイ *1 にも対応しています。 これにより、Webページのレスポンス向上も期待できるでしょう。 拡大縮小による画像の劣化もないため、レスポンシブデザインとの相性も良い画像ファイルです。 フィルター、アニメーション表現が可能 SVG ファイルは、 CSS や JavaScript 、動画作成ソフトなどを使ってアニメーションを表示することができます。 今までアニメーションといえばGIFを photoshop や Flash で作るのが一般的でしたが SVG はGIFでは扱えない透過も利用できます。 （参考） ics.media www.e-webseisaku.com デメリット とはいえ SVG ファイルも万能ではありません。 SVG ファイルは写真のような複雑な陰影を表現する画像には不向きです。 風景などの画像を数値として扱うためには、膨大な量の計算が必要になるからです。 また、現在はほとんどのブラウザで対応していますが、まれに未対応のブラウザも存在します。 SVG ファイルの作成方法 SVG ファイルの作成方法は、 ベクター 画像を作成できるツールを利用することです。 一般的には Adobe Illustrator や Adobe Photoshop といった画像編集ソフトを利用します。 illustrator などを使って、 SVG にしたいベクタ形式のファイルを開いて、拡張子を. svg にして保存します。 もちろん、 テキストエディタ で作成することも可能です。 PNG を SVG に変換してみよう 元データがベクタ形式でない場合も、 SVG に変換することは可能です。 ブラウザ上で完結する変換ツールを使って変換してみましょう。 検索するといろいろ出てくるのですが、今回は　 Online Image Vectorizer 　を使用していきます。 www.vectorizer.io 対応しているフォーマットは PNG 、 BMP 、 JPEG です。 また、 SVG だけでなくEPS、DXFといった ベクター 形式に変換することも可能です。 時間当たりの変換できるファイル数に制限がありますが、基本的に無料で使えます。 使い方はいたってシンプルで、変換したいファイルをアップロードするだけで SVG ファイルに変換してくれます。 vectorizer 左が変換前の PNG ファイルで、右が変換後の SVG ファイルです。 vectorizer-拡大 拡大してみると、ラスタ形式の PNG ファイルはギザギザしていますね。 無事、 ベクター 形式に変換されていることがわかります。 サイズは 7KB→2KB になりました！ SVG ファイルの中身 変換された SVG ファイルの中身はこんな感じ。 ちなみに、先述したように SVG が苦手とする写真のような複雑な描画の PNG ファイルを変換すると…… vectorizer-写真 左が変換前の PNG ファイル、右が変換後の SVG ファイルです。 ぱっと見た感じ悪くないですが、 179 KB→542KB と、かなりサイズが大きくなっていしまいました…。 vectorizer-写真-拡大 こちらも拡大するとこんな感じ。 変換した SVG ファイルのほうは、いくら拡大してもギザギザになることはありません。 ただ、複雑な色の濃淡を数式で表現するとなると、やはりデータ量が膨大になってしまいます。 SVG ファイルを PNG に変換する方法 SVG ファイルを PNG に変換したいときはこちら SVG to PNG – SVGファイルをネット上でPNGに変換する svgtopng.com 使い方は簡単、 PNG に変換したい SVG ファイルをアップロードするだけです。 一度に20個まで変換でき、まとめてZIPでダウンロードすることも可能です。 おわりに 様々な種類がある画像フォーマットの中から、 SVG の特徴を簡単に紹介させていただきました。 適切な画像フォーマットを選択できるよう、ぜひ本記事を参考に変換してみてください。 　 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com *1 : Apple 製品の高画素密度ディスプレイ

こんにちは、開発エンジニアの amdaba_sk（ ペンネ ーム未定）です。 昨年度まで、 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」というプロジェクトがありました。本年度からは規模を拡大し、「技術推進プロジェクト」と名称を改めて再スタートされました。 本記事では、昨年度かみせんプロジェクトとしての最後のテーマとなった 機械学習 テーマの延長として 2020 年度上期に行った「AutoML ツールの調査と評価」について取り組み結果を報告します。 （ちなみに 機械学習 テーマは前年度から継続していたこともあり、上期で終了となってしまいました。残念……） なお過去の報告記事はかみせんカテゴリからどうぞ。技術推進プロジェクトでは 機械学習 だけではなく、他にもいろいろなテーマで検証を行っています。どれも面白そうなテーマですので是非そちらの報告もご覧ください。 tech-blog.rakus.co.jp はじめに 検証の方法 データセット モデル学習の従来手法について 調査対象とした AutoML サービス 調査対象とした AutoML ライブラリ 結果 モデル学習の作業時間と性能 従来手法 AutoML クラウドサービス AutoML ライブラリ 考察と所感 従来手法と AutoML AutoML サービスとライブラリの比較 AutoML サービス間の比較 Amazon SageMaker AutoPilot Google Cloud AutoML Tables IBM Watson Studio AutoAI Microsoft Azure AutoML AutoML ライブラリ間の比較 auto-sklearn H2O.ai TransmogrifAI AutoKeras まとめ 参考 はじめに AutoML とは、簡単に言えば 機械学習 のプロセスを自動化し、デー タセット と最重要視する評価指標を指定するだけで最適なモデルを構築する仕組みのことです。 機械学習 を使用して良いパフォーマンスを得るためには、通常、データ収集、特徴量エンジニアリング、モデルや アルゴリズム の選択といった作業に人手による試行錯誤が必要となり、コストがかかります。AutoML では、Figure 1 に示すように 機械学習 アプリケーションの構築パイプラインの一部を自動化することで、手動でのモデル学習よりも高い性能を持つ 機械学習 モデルの効率的な構築を目指します。 Figure 1. 機械学習 アプリケーションの典型的なパイプラインと AutoML の活用範囲（Q. Yao, et al., "`Taking the Human out of Learning Applications: A Survey on Automated Machine Learning`" より引用） 今回の技術推進プロジェクトでは、そんな便利そうな AutoML を、公開されたデー タセット に対して実際に使ってみることで、効率的にモデル学習ができることを確かめました。また AutoML を提供するサービス、ライブラリを複数試用し、それぞれを比べてみました。 検証の方法 特定のデー タセット について、選定したサービスやライブラリを用いて実際にモデル学習を行い、モデル学習のための作業時間と得られたモデルの性能について調べました。また同じデー タセット について、従来の方法でモデル学習 スクリプト を作成し、その作業時間と得られたモデルの性能を AutoML を使用した場合の結果と比較しました。 デー タセット 検証のためのデー タセット として Bank marketing デー タセット を用いました。 このデー タセット は クリエイティブ・コモンズ CC0: Public Domain のライセンスで利用できるオープンデータであり、テーブル形式になっています。 今回検証の対象としたサービスの中にはデー タセット の最小サイズが設定されているものがあり、有名な Titanic dataset や Iris flower dataset はサイズが足りずに使うことが出来ませんでした。Bank marketing は 後述する Google Cloud AutoML Tables の チュートリアル で用いられているデー タセット であり、サイズも充分であるためこれを用いました。 Bank marketing デー タセット は ポルトガル のとある銀行が行った ダイレクトマーケティング キャンペーンの結果です。職業、年齢などの顧客データとキャンペーン商品を購入したかどうかが記録されています。 Table 2 に示したようにクラスごとのデータ件数にはかなりの偏りがあるデータです。 データ件数 :: 45211 件 Table 1 . カラム情報 No. カラム名 データタイプ 説明 1 age 数値 年齢 2 job カテゴリ 職業の種類 3 marital カテゴリ 婚姻状態 4 education カテゴリ 学歴 5 default カテゴリ 債務不履行 の有無 6 balance 数値 年平均残高（ユーロ） 7 housing カテゴリ 住宅ローンの有無 8 loan カテゴリ 個人ローンの有無 9 contact カテゴリ 連絡先端末の種類 10 day 数値 月の最後の連絡日 11 month カテゴリ 年の最後の連絡月 12 duration 数値 最後の連絡時の通話時間（秒） 1 13 campaign 数値 キャンペーン中の連絡回数 14 pdays 数値 前回のキャンペーンでの最後の連絡からの経過日数 15 previous 数値 前回のキャンペーンでの連絡回数 16 poutcome カテゴリ 前回のキャンペーンでの結果 17 y バイナリ 顧客が定期預金に加入したかどうか（1 : 非加入、2 : 加入） Table 2 . クラスごとの件数比率 クラス 件数 比率 1 39922 0.88 2 5289 0.12 モデル学習の従来手法について 従来手法として、以下の工程を経てモデル学習と性能指標の算出を行う スクリプト を自作しました。 デー タセット の読み込み データの前処理 使用するデータ列の取捨選択 カテゴリデータのダミー変数化 数値データの整形 学習データとテストデータの分割 モデル学習 学習データに対する CV 検証を用いたハイパーパラメータ調節 調整されたハイパーパラメータでの学習データによる学習 テストデータによる性能測定 言語は Python 3 を用いました。ライブラリとして Pandas、scikit-learn を用い、Jupyter Notebook として作成しました。デー タセット は CSV ファイル形式で作成しておき、 スクリプト 内で読み込んで使用しました。 また 4 のモデル学習の際、いくつかの アルゴリズム で学習したモデルの性能を比較し、最も高い性能を示した アルゴリズム を結果として採用しました。その際の候補となる学習 アルゴリズム は scikit-learn のアルゴリズム選定チートシート をもとに第一候補を決め、加えてよく用いられる代表的な アルゴリズム を選びました。最終的に試した アルゴリズム は以下の通りです。 線形 サポートベクターマシン （ SVM ） k 近傍法（KNN） 線形判別分析（LDA） ランダムフォレスト分類器（ RFC ） 多層 パーセプトロン 分類器（ MLP ） ガウス モデル単純 ベイズ 分類器（GNB） 今回使用するデー タセット は前述の通り偏りが大きいため、ハイパーパラメータ調整と各 アルゴリズム でのモデルの性能比較において正答率ではなく F1 値のマクロ平均を最適化の基準として用いています。 調査対象とした AutoML サービス クラウド サービスを使って AutoML を行う例として、以下の 4 つのサービスを試しました。 Amazon SageMaker AutoPilot Google Cloud AutoML Tables IBM Watson Studio AutoAI Microsoft Azure AutoML AutoML の実行の際、最適化の基準となる指標には F1 値ないしそれに近い用途の指標を用いました。他の設定は各サービスのデフォルトの設定のまま行っています。サービスによっては F1 値が選択できないものもあり、そのためサービスごとに異なる指標が最適化の基準として用いることになりました。 調査対象とした AutoML ライブラリ ライブラリを使って AutoML を行う例として、以下の 4 つのライブラリを試しました。 auto-sklearn H2O.ai TransmogrifAI AutoKeras ライブラリについてもサービスの場合と同様、最適化の基準となる指標には F1 値ないしそれに近い用途の指標を用いました。他の設定は各ライブラリのデフォルトの設定のままで行っています。ライブラリによっては F1 値が選択できないものもあり、そのためライブラリごとに異なる指標が最適化の基準として用いることになりました。 結果 モデル学習の作業時間と性能 Table 3 に今回試した各手法での作業時間（時間）、最良モデルの アルゴリズム 、基準とした評価指標、最良モデルの正答率、F1 値マクロ平均をまとめました。以下、この結果をひとつずつ見ていきます。 Table 3 モデル学習の結果。「Kaggle 投稿」は本検証で用いたものと同一のデー タセット に対して Kaggle に投稿された従来手法でのモデル学習結果。H. Yamahata, "Bank Marketing + Classification + ROC ,F1,RECALL..." より引用 エントリー 作業時間 (h) 基準指標 最良 アルゴリズム 正答率 F1 値マクロ平均 従来手法 自作 スクリプト 2.5 F1 値マクロ平均 GNB 0.80 0.58 Kaggle 投稿 - 適合率 KNN 0.90 0.88 AutoML クラウド サービス Amazon SageMaker AutoPilot < 1.0 F1 値マクロ平均 XGBoost N/A 0.71 Google Cloud AutoML Tables < 0.5 AUC ROC GDBT 0.90 0.65 IBM Watson Studio AutoAI < 0.5 F1 値マクロ平均 XGB 分類器 0.88 0.70 Microsoft Azure AutoML < 0.5 加重 AUC ROC VotingEnsemble 0.89 0.61 AutoML ライブラリ auto-sklearn < 2.0 F1 値マクロ平均 Weighted Ensemble 0.86 0.68 H2O.ai < 1.0 AUC ROC StackedEnsemble 0.87 0.72 TransmogrifAI < 2.0 AUC ROC XGBoost 0.90 0.65 AutoKeras < 0.5 F1 値マクロ平均 深層学習 0.89 0.72 従来手法 従来手法で スクリプト を自作した場合の作業時間はおよそ 2.5 時間でした。この時間には Python の書き方の復習や Pandas および scikit-learn の API を確認する時間も含まれています。それによって得られた最良のモデルは ガウス モデル単純 ベイズ 分類器によるもので、正答率 が 0.88、F1 値マクロ平均は 0.58 でした。 AutoML クラウド サービス AutoML サービスを用いた場合の作業時間にはアカウントの開設などの周辺作業のための時間は含めていませんが、AutoML の実行に関する操作や設定項目の確認は作業時間に含まれています。 Amazon SageMaker AutoPilot を使った場合の作業時間はおよそ 1 時間以内でした。また得られた最良のモデルは XGBoost によるもので、F1 値マクロ平均は 0.70 でした。最適化の基準として F1 値マクロ平均 を用いました。正答率は画面から確認する術を見つけられませんでした術 Google Cloud AutoML Tables を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは勾配ブーストディシジョンツリーモデル（GDBT）によるもので、正答率 が 0.90、F1 値マクロ平均は 0.65 でした。最適化の基準として AUC ROC を用いました。 IBM Watson Studio AutoAI を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは XGB 分類器によるもので、正答率 が 0.88、F1 値マクロ平均は 0.70 でした。最適化の基準として F1 値マクロ平均を用いました。 Microsoft Azure AutoML を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは StackEnsemble によるもので、正答率 が 0.89、F1 値マクロ平均は 0.61 でした。最適化の基準としては加重 AUC ROC を用いました。 AutoML ライブラリ AutoML ライブラリを用いた場合の作業時間にはライブラリの実行環境を構築するための時間は含まれていませんが、ライブラリの使い方の確認などの調査の時間は含まれています。 auto-sklearn を使った場合の作業時間は 1 - 2 時間程度でした。また得られた最良のモデルは正答率 が 0.86、F1 値マクロ平均は 0.68 でした。最適化の基準として F1 値マクロ平均を用いました。なお auto-sklearn は アルゴリズム として常に Weighted Ensemble を用いるようになっています。得られた最良のモデルでアンサンブルに使われた アルゴリズム とそれぞれの重み係数は Table 4 のようになっていました。 Table 4 auto-sklearn の最良モデルにおける Weighted Ensemble の詳細 重み アルゴリズム 0.82 sgd 0.04 random_forest 0.02 random_forest 0.02 random_forest 0.02 random_forest 0.02 random_forest 0.02 gradient_boosting 0.02 adaboost 0.02 extra_trees H2O.ai を使った場合の作業時間はおよそ 1 時間以内でした。また得られた最良のモデルは StackedEnsemble によるもので、正答率 が 0.87、F1 値マクロ平均は 0.72 でした。最適化の基準として AUC ROC を用いました。 TransmogrifAI を使った場合の作業時間は 1 - 2 時間程度でした。また得られた最良のモデルは XGBoost によるもので、正答率 が 0.89、F1 値マクロ平均は 0.65 でした。最適化の基準として F1 値マクロ平均を用いました。 AutoKeras を使った場合の作業時間はおよそ 30 分以内でした。また得られた最良のモデルは正答率 が 0.89、F1 値マクロ平均は 0.72 でした。最適化の基準として F1 値マクロ平均を用いました。 考察と所感 従来手法と AutoML 自作 スクリプト の従来手法で得られたモデルと AutoML で得られたモデルを比較した場合、正答率や F1 値マクロ平均といった性能指標で AutoML で得たモデルの方が良い性能を示しました。一方で Kaggle に投稿されたモデルと AutoML で得られたモデルを比較すると、AutoML で得たモデルの性能は F1 値マクロ平均で大きく劣っていました。AutoML による 機械的 なモデル探索によりある程度の性能までは達成できることが分かりますが、いまだそこには限界があり、経験を積んだデータサイエンティストには敵わないようです。ただし この記事 によると、他のデー タセット 、問題設定によっては Kaggle 投稿のモデルよりもよい性能を示すモデルが構築されるようです。AutoML にも得手不得手があることが分かります。 モデル学習の実行までにかかる作業時間を比較すると、従来手法は AutoML サービスを利用した場合の 2 倍以上、AutoML ライブラリを用いた場合の 1.5 倍程度の作業時間を要しています。従来手法でも scikit-learn の API を用いてかなりの部分が自動化されているとは言え、 アルゴリズム の選定やハイパーパラメータ候補セットの検討、それらの記述にどうしても時間がかかりました。一方で AutoML では従来手法で時間を要したそれらの工程が自動化されており、作業時間が短縮できています。 AutoML サービスとライブラリの比較 AutoML で得られたモデルの内、 クラウド サービスを利用して構築したものとライブラリを利用して構築したものを比較すると、正答率や F1 値マクロ平均といった性能指標では大きな差は見られませんでした。 モデル学習の実行までにかかる作業時間を比較すると、 クラウド サービスを利用した場合はライブラリを利用した場合の半分程度の時間で作業を終えることが出来ています。 クラウド サービスは多くの場合、データ前処理、特徴量エンジニアリングの自動化もなされており、サービスが受け付けられる形式でデー タセット を用意すれば、後は数ステップの GUI 操作によってモデル学習を実行できます。一方でライブラリではデータ前処理部分は自分でコードを記述し実装しなければならず、その点で クラウド サービスよりも時間がかかりました。 クラウド サービスとライブラリでは、モデル性能や作業時間の違いはさほど大きな問題ではなく、むしろ学習の実行環境にこそ違いがあるように思われます。 クラウド サービスであれば数クリックで計算リソースの確保ができます。予算があれば高性能な インスタンス を選択し短時間で学習を終わらせることもできるでしょう。一方でライブラリは実行環境は自前で用意することになります。より速い計算速度、より大きなメモリが必要となった場合に即調達できるとは限りません。 一方でデー タセット を クラウド 上にアップロードすることが諸事情によりどうしても許容できないとなった場合は、 クラウド サービスはそもそも使用できません。この場合はライブラリを使うことで対処することになると考えられます。 AutoML サービス間の比較 AutoML サービスで得られたモデル同士を比較した場合、正答率はどれも 0.9 程度とあまり違いは見られず、F1 値マクロ平均で見ても 0.1 程度の差しかありませんでした。モデル学習の実行までにかかる作業時間も、どのサービスを用いたとしても 30 分か 1 時間以内には終了しており顕著な差は見られません。 ただ各サービスごとに機能のラインナップや画面デザインに違いがあり、プロジェクトやチームごとの重視するポイントによって最適な選択は異なると考えられます。以下ではこれらのサービスの長所や短所の所感を述べます。 Table 5 . 機能比較表 / 学習時の機能; ○：対応、△：一部対応、×：非対応 サービス 前処理の自動化 統計情報の表示 特徴量の自動作成 交差検証 Amazon SageMaker AutoPilot ○ △ ○ ○ Google Cloud AutoML Tables ○ ○ ○ ○ IBM Watson Studio AutoAI ○ △ ○ ○ Microsoft Azure AutoML ○ ○ ○ ○ Table 6 . 機能比較表 / 評価時の機能; ○：対応、△：一部対応、×：非対応 サービス 特徴量の寄与率表示 結果の可視化 学習済みモデルのダウンロード API 接続先の作成 Amazon SageMaker AutoPilot △ △ ○ ○ Google Cloud AutoML Tables ○ ○ ○ ○ IBM Watson Studio AutoAI ○ ○ ○ ○ Microsoft Azure AutoML ○ ○ ○ ○ Amazon SageMaker AutoPilot Amazon SageMaker AutoPilot は UI からできることがあまりなく、ローコード・ノーコードという観点からは使いにくさを感じました。しかしコードを読み書きする前提に立てば、AutoML の実行コードが記述された Notebook が生成されるため、解釈性やカスタマイズ性が高いとも言えます。検証作業時に確認方法のわからなかった正答率など最適化基準ではない性能指標も、Notebook を変更すれば実行ログから確認できるだろうと思われます。データサイエンティストとして知識を持った人をターゲットに、その作業を簡略化することを目的とするサービスだと感じました。 長所 AutoML 実行用の Notebook が生成される Notebook を編集することで細かなカスタマイズができる Notebook には説明が豊富に記載される（英語） 短所 データが 1000 件以上必要 デー タセット の管理が SageMaker 単体で完結できない（S3 が別途必要） UI からできることが少なく、作業フローがわかりにくい 手動でリソースを閉じる必要がある（閉じ忘れると課金される） Amazon SageMaker AutoPilot はプレビュー版であり、使えるリージョンが限られる Google Cloud AutoML Tables Google Cloud AutoML Tables は GCP でいくつか提供されている AutoML サービスの一つで、テーブル形式のデータを扱うことに特化した AutoML サービスです。デー タセット のインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できます。各画面もシンプルな構成になっており、わかりやすいと感じました。ただシンプルな反面、モデルの構造など画面上から確認できる情報は他サービスと比べ少ないように思います。 長所 同じモデルで判定の 閾値 を変えた場合の性能指標が見られる 処理完了をメールで通知してくれる ドキュメントが丁寧かつ豊富 短所 データが 1000 件以上必要(分類ならさらにクラスごとに 20 件以上必要) モデルの内部構造を確認するために別サービス（Cloud Logging）を利用して生のログを見なければならない Google Cloud AutoML Tables はベータ版 IBM Watson Studio AutoAI IBM Watson Studio AutoAI は今回対象としたサービスの中では唯一正式サービスとして提供されています。デー タセット のインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できます。各画面もシンプルな構成になっており、わかりやすいです。 学習ジョブの進行状況やモデルがツリー状の UI でグラフィカルに表現されている点が特徴的で、学習のどの段階でどのようなモデルが試されたのかを視覚的に把握できるようになっています。また特徴量エンジニアリングでどのカラムにどのような変換がなされたのかが確認でき、学習済みモデルを説明するための情報が豊富だと感じました。一方で特徴量エンジニアリングの変換では非合理的な変換が行われているように感じる部分もあり、不安になってしまうことがあります。 長所 グラフィカルな表現でわかりやすい 特徴量エンジニアリングの詳細が確認できる IBM Watson Studio AutoAI は正式サービス 短所 特徴量の変換が非合理的に思えることがある Microsoft Azure AutoML Microsoft Azure AutoML もデー タセット のインポート、学習の設定、実行、モデルの評価の確認、デプロイまで GUI で操作できまする。デー タセット の指定から学習の実行までは、フロー状の UI で設定ステップが示されており、今回対象としたサービスの中で最もわかりやすいと感じました。逆にモデルの評価画面は初見では少しわかりにくいと感じるかもしれません。表示される情報は豊富だが、ほしい情報がどこにあるのかが少し探しにくいように思えます。 また特徴的な機能として、学習に使用したデー タセット の品質を評価してくれるデータガードレールという機能があります。 Amazon SageMaker AutoPilot や Google Cloud AutoML Tables のようなデー タセット に関する制約ではなく、デー タセット に含まれる欠損値やクラス不均衡といった問題を検出し警告してくれることで、デー タセット の品質改善に役立ち、かつ実行の手軽さも保っていると思います。 長所 学習実行条件を細かく指定できる デー タセット 自体の問題を検出してくれる モデル性能評価のグラフが豊富 短所 出力されるモデル性能が他サービスと比べ少し悪い Microsoft Azure AutoML はプレビュー版 AutoML ライブラリ間の比較 AutoML ライブラリで得られたモデル同士を比較した場合も、 クラウド サービスの場合と同じく性能的な違いはあまり見られません。モデル学習の実行までにかかる作業時間も、どのライブラリを用いたとしても 2 時間以内には終了しました。 ただやはり各ライブラリごとに特徴があり、プロジェクトやチームごとの重視するポイントによって最適な選択は異なると考えられます。以下ではこれらのライブラリの長所や短所の所感を述べます。 Table 7 . 機能比較表 / 学習時の機能; ○：対応、△：一部対応、×：非対応 ライブラリ 前処理の自動化 統計情報の表示 特徴量の自動作成 交差検証 auto-sklearn △ × × 〇 H2O.ai △ × × 〇 TransmogrifAi △ × △ 〇 AutoKeras 〇 × × 〇 Table 8 . 機能比較表 / 評価時の機能; ○：対応、△：一部対応、×：非対応 ライブラリ 特徴量の寄与率表示 結果の可視化 サマリの表示 auto-sklearn × × △ H2O.ai 〇 〇 〇 TransmogrifAi 〇 × 〇 AutoKeras × × △ auto-sklearn auto-sklearn は scikit-learn をベースにしており、インターフェースも基本的に scikit-learn と同じです。そのため scikit-learn に慣れた人間であれば最もとっつきやすくなっていると思われます。 一方で auto-sklearn は入力データが全て数値でなければならないという制約があり、文字列データは全て手動で数値に変換してからでないと学習を実行できないため、他のライブラリに比べて手軽に試すにはややハードルが高いと感じました。 長所 scikit-learn と同じインターフェースなのでわかりやすい 短所 文字列データを受け付けない（カテゴリデータは数値に変換が必要） アンサンブルに使われた アルゴリズム の取得方法が公式に用意されていない（プライベート API を使えば可能） H2O.ai H2O.ai は Java で実装されたバックエンドを Python 、R、 REST API 、 Java 、 Scala などから操作する 機械学習 プラットフォームです。ライブラリという枠とはすこし異なりますが、 Python などで スクリプト を作成することになるという点でライブラリの一つとして取り上げました。 AutoML ライブラリとして見た場合、他のライブラリに比べ評価指標の取得・可視化が簡単で、情報量が多いという点が特徴です。モデルの評価指標を調べる場合にも、コード 1 行で各種評価指標と混同行列が出力できます。 ROC 曲線や特徴量重要度などのプロットは、他のライブラリであれば matplotlib 等の別ライブラリを用いることになりますが、H2O.ai の場合は単体で簡単にプロットが可能です。 長所 複数の言語の SDK がある 結果の可視化が簡単 短所 scikit-learn ほど流行っていない TransmogrifAI TransmogrifAI は Salesforce が開発している オープンソース の AutoML ライブラリで、 Apache Spark 上で AutoML を実行できるライブラリです。実装言語は Scala です。 ビッグデータ 解析などで使用されている Spark 上でそのまま AutoML を構築できるのが強みとされています。サポートする機能は特徴量エンジニアリング、モデル選択、ハイパーパラメータチューニングと、AutoML の基本的な機能は網羅しています。 使用した所感としては、ライブラリというよりもむしろ言語ならではのメリットが大きいと感じました。デー タセット の型や特徴量のタイプの指定などで型システムの恩恵を受けることができることや、 IDE の支援を手厚く受けられます。型が定義されていることでデー タセット の持つプロパティが補完される点は、 Python にはない利点であると思います。実行環境の構築には多少手間がかかりますが、Spark をバックエンドにした Notebook である Apache Zeppelin を使用すれば、Jupyter Notebook のような形で開発を進めることも可能です。チームやプロジェクトの置かれた環境次第では十分に選択肢に入るだろうと感じました。 長所 特徴量触るのが簡単 結果の説明がやさしい 短所 細かいチューニングを行うにはライブラリに習熟する必要がある それなりにボイラープレートは多い Spark を使うので環境構築はそれなりに面倒 AutoKeras AutoKeras は深層学習のライブラリである Keras のハイパーパラメータチューニングを自動化するライブラリです。今回試した他のライブラリとは異なり深層学習であるため、得られる情報が少ないという点が気になりました。また深層学習であるがゆえにモデルの説明可能性などは考慮されていないようです。実際にどのような処理をしているかなどは意識しないように作られているように感じました。一方、試行回数を増やすことで探索を続けることができるため、リソースや時間があればある程度正確なモデルは作成できる可能性があるとも思われます。 長所 少ないコードで実装できる 短所 精度を上げるにはそれなりの前処理が必要 特徴量エンジニアリングはしてくれない 出力されるメトリクスが少ない 学習結果のばらつきが多い まとめ 公開されたデー タセット を用いて学習 スクリプト の自作と AutoML によるモデル学習とを行い、両者の作業時間、生成される学習モデルの性能を比べました。また AutoML を提供するサービス、ライブラリを複数試用し、それぞれの長所や短所を調べました。 AutoML は従来手法と比べ、やはり作業効率の点で大きく優れていることが分かりました。一方で構築されるモデルの性能については、デー タセット や問題設定によって得手不得手があるだろうことが分かりました。目的変数のサンプル数に偏りがあるようなデー タセット では、ある程度までは AutoML で従来手法よりもよい性能のモデルが得られますが、作業者にデータ分析の十分なスキルがある場合は従来手法でモデルを構築したほうが良い性能のモデルが得られるようです。 AutoML を利用する場合、 クラウド サービスとライブラリを比べると クラウド サービスの方がグラフィカルな UI で直観的に操作できる分、作業時間はかかりません。また クラウド サービスは特徴量エンジニアリングまで自動化されていることが多いですが、ライブラリではデータの前処理部分を自前で実装しなければならず、その点でも作業時間に差があります。 参考 Q．Yao, M．Wang, Y．Chen, W．Dai, Y.-F．Li, W.-W．Tu, Q．Yang, Y．Yu, "Taking the Human out of Learning Applications: A Survey on Automated Machine Learning", arXiv preprint arXiv :1810.13306, 2019. S．Moro, R．Laureano and P．Cortez. "Using Data Mining for Bank Direct Marketing: An Application of the CRISP-DM Methodology. In P. Novais et al. (Eds.)", Proceedings of the European Simulation and Modelling Conference - ESM’2011, pp. 117-121, Guimarães, Portugal, October, 2011. EUROSIS. Bank Marketing + Classification + ROC,F1,RECALL... (参照日 2020-09-23). Awesome-AutoML (参照日 2020-09-23). AutoML がすごいと聞いたので色々使って比べてみた (参照日 2020-09-23). その機械学習プロセス、自動化できませんか？ (参照日 2020-09-23). Qiita のスパム狩りをしたら AutoML に仕事を奪われた件 (参照日 2020-09-23). AutoML vs AutoML (参照日 2020-09-23). Choosing the right estimator (参照日 2020-09-23). Amazon Sagemaker Autopilot | Amazon Sagemaker (参照日 2020-09-23). AutoML Tables | AutoML テーブル | Google Cloud (参照日 2020-09-23). IBM Watson Studio - AutoAI - 日本 | IBM (参照日 2020-09-23). 自動 ML/AutoML とは - Azure Machine Learning | Microsoft Docs (参照日 2020-09-23). auto-sklearn — AutoSklearn 0.9.0 documentation (参照日 2020-09-23). Home - Open Source Leader in AI and ML (参照日 2020-09-23). TransmogrifAI - AutoML library for building modular, reusable, strongly typed machine learning workflows on Spark from Salesforce Engineering (参照日 2020-09-23). AutoKeras (参照日 2020-09-23). エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、YSです。 今回は、Node.js＋ フレームワーク 「Express」を使用して作成されたwebアプリケーションで 静的コンテンツを gzip 配信できるように独自で対応した件について共有させていただきます。 はじめに 基本知識 Node.jsとは？ Expressとは？ Expressのインストール方法 プロジェクトの作成 Expressの使い方 プロジェクトの構成について 本題 サービスの構成 要件 検討 仕様 サービス起動時の処理 静的コンテンツがリクエストされた際の処理 その他 サンプルコード lib/public_cache.js routes/publicCache.js app.js まとめ 基本知識 まず前提となるNode.jsと フレームワーク 「Express」について簡単に解説させていただきます。 こちらは初心者向けの説明となりますので、不要な方は読み飛ばしてください。 Node.jsとは？ Node.jsは、サーバサイドの JavaScript です。 一般的な JavaScript は、クライアントのブラウザ上で動作するものでしたが、 Node.jsでは JavaScript がサーバサイドで動作し、 WEBサービス 等を立ち上げることができます。 Node.jsはシングルスレッドで実行され、非同期処理が行えます。 これらの特性により、負荷に強く大量アクセスによるC10K問題が起こらないように設計されています。 C10K問題とは、サーバサイドの処理において、クライアント数が約1万台に達するとメモリの不足・プロセス数の上限・ファイル ディスクリプタ の上限・ コンテキストスイッチ のコスト増加等が発生し、リソースが不足し処理性能が劣化してしまう問題です。 Node.jsは次のような仕組みにより、負荷に強い仕組みが実現されています。 シングルスレッド スレッドを単体にすることにより、大量のプロセスやファイル ディスクリプタ を発生させないようになっています。 イベントループ イベントをキューとして扱い、順番に処理していくモデルです。 ノン ブロッキング I/O データのI/O処理の完了待ちによるブロックを発生させずに並列に処理できます。 Expressとは？ Node.js用のWebアプリケーションの MVC フレームワーク です。 Node.jsで一番メジャーな フレームワーク であり、Node.jsのWebアプリケーションに関する書籍や記事などはExpressありきで書かれている事が多いです。 Expressはガッツリとした多機能な フレームワーク ではなく、Webアプリケーションを開発するにあたって必要な部品が揃った軽量な フレームワーク であり、自由度も高いです。 Expressのインストール方法 次のコマンドでインストールできます。 ※npmはNode.jsのパッケージ管理システムです。 npm install express --save プロジェクトの作成 いちから自作でプロジェクトを作成することもできますが、大変なので express-generator を使用して雛形を作成します。 次のコマンドでインストールできます。 npm install express-generator -g プロジェクトの作成はexpressコマンドにプロジェクト名を指定し実行するだけです。 express 【プロジェクト名】 Expressの使い方 1. express-generatorを使用して雛形を作成します。 ※プロジェクト名は「testApp」とします。 express testApp 2. 関連パッケージのインストールを行います。 cd testApp npm install 3. サービスを立ち上げ方です。 npm start プロジェクトの構成について express-generatorにより、次のようなファイルが作成されます。 testAppフォルダ配下の構成 public/ public/javascripts/ public/images/ public/stylesheets/ public/stylesheets/style. css routes/ routes/index.js routes/users.js views/ views/error.jade views/index.jade views/layout.jade app.js package. json bin/ bin/www app.js メインファイルです。 アプリケーション全体の処理や設定を記述します。 public/ 静的コンテンツを格納する ディレクト リです。 ファイルを設置するだけで、自動的に静的コンテンツとして利用できます。 routes/ ルーティングファイルを格納する ディレクト リです。 ルーティングファイルでは、URL毎の処理やビューファイルの呼び出し等を行います。 views/ ビューファイルを格納する ディレクト リです。 bin/ 起動ファイル「www」が格納されています。 express-generatorにより、シンプルな構成のindex画面を返す雛形が自動生成されます。 シンプルな雛形なので、アプリケーション独自のフォルダやファイルを追加しカスタマイズすることが可能です。 本題 さて、ここからが今回の本題になります。 私が開発に携わっているWEBアプリケーションのサービスで、通信量を減らしたいという要望があがり 静的コンテンツを gzip 圧縮して配信することになりました。 サービスの構成 ・ロードバランサ 　Nginx ・WEBアプリケーション 　Node.js＋ フレームワーク 「Express」 要件 1. 静的コンテンツを gzip 圧縮し配信したい。 2. リク エス トの度に gzip 圧縮するとCPUのコストがかかるので、あらかじめ gzip 圧縮しておきリク エス ト時に返すようにしたい。 3. 今後の開発・運用での作業ミスの防止のためにも、 gzip 圧縮されたコンテンツは意識せずとも最新の内容が反映されるようにしたい。 検討 これらの要件を踏まえ、パッと対応できそうなものは次のようなものでした。 ロードバランサ等のMW側の機能を利用する。 Node.jsのnpmパッケージでExpressの gzip 配信機能を導入する。 しかし実際に調査を進めてみると、単純に静的コンテンツを gzip 圧縮された形式で配信するだけなら対応できますが すべての要件をかなえるものは見つからず、断念しました。 ※2年ほど前の話ですので、現在は要件を満たすロードバランサの機能やNode.jsのnpmパッケージがあるかもしれません。 検討した結果、すべての要件を満たすために静的コンテンツの gzip 圧縮配信を独自で実装することになりました。 仕様 Expressの静的コンテンツ配信機能とは別に、独自で静的コンテンツを配信する仕組みを設ける。 Expressの静的コンテンツフォルダ「public」と同レベルに「public_cache」というフォルダを作成し、配下のファイルを gzip 圧縮して配信できる仕組みを設ける。 サービス起動時の処理 サービス起動時に静的コンテンツを取得し gzip 圧縮する。 無圧縮・ gzip 圧縮された2種類のコンテンツデータをサービスのメモリ上に保持する。 アプリケーションのサービス起動時にフォルダ「public_cache」内のファイルの情報を取得する。 ファイルを gzip 圧縮したデータを作成する。 サービスのメモリ上に無圧縮のデータと gzip 圧縮したデータを格納する。 静的コンテンツがリク エス トされた際の処理 静的コンテンツへのリク エス トが来た際に、サービスのメモリ上に保持されたコンテンツデータをレスポンスデータとして返す。 リク エス トヘッダ「accept-encoding」が gzip に対応していたら、 gzip 圧縮したデータを返す。 gzip 非対応であれば無圧縮のデータを返す。 その他 今回あわせて下記のような仕様を盛り込みました。 ・静的コンテンツのリアルタイム反映 コンテンツが最新化されると、次回リク エス ト時に最新ファイルの内容でコンテンツデータを最新化するようにしています。 これにより、サービス停止なしで静的コンテンツに関する軽微な不具合対応等が行えるようになっています。 ・セキュリティ対策 自動的に JavaScript のコメントを除去するようにしており、開発者向けのコメントを外部に見られることを防いでいます。 サンプルコード ※サンプルですので、Headerの設定等の詳細なコードは省いています。 ※静的コンテンツのリストは「lib/public_cache.js」の変数「files」に定義しています。 　ここについては、フォルダ「public_cache」内の情報から自動的にリストにすることも可能だと思います。 lib/public_cache.js 静的コンテンツを読み込み管理するためのライブラリ ※libはサンプル独自の ディレクト リ const fs = require('fs'); const path = require('path'); const zlib = require('zlib'); const publicCachePath = module.exports.appPath + '/public_cache/'; // ※現時点ではUTF-8固定にしております。 let files = { 'hoge.html': {}, 'js/jquery.js': {}, 'js/hoge.js': {}, 'css/main.css': {}, 'css/icon.css': {} }; module.exports.files = files; // ファイルを読み込み保持する function setFileData (fileName) { let mimeType = ''; // 拡張子の判断 let ext = path.extname(fileName).toLowerCase(); if (ext) { // 一文字目に「.」が付いているので除去する ext = ext.substr(1); } // mime type 設定 switch (ext) case 'js': mimeType = 'application/javascript;'; break; case 'css': mimeType = 'text/css;'; break; case 'html': case 'htm': mimeType = 'text/html;'; break; default: mimeType = 'text/plain;'; break; } mimeType += ' charset=UTF-8'; let data = fs.readFileSync(publicCachePath + fileName, 'utf-8'); if (ext == 'js') { // JSの場合は、行コメントを取り除く data = data.replace(/^\s \/\/. $/gm, ''); } let gzipData = zlib.gzipSync(data, {level: 6}); let fileStats = fs.statSync(publicCachePath + fileName); files[fileName] = { plain: data, gzip: gzipData, mtime: fileStats.mtime, mime_type: mimeType }; } // ファイル情報を読み込む function loadFileData () { for (let fileName of Object.keys(files)) { setFileData(fileName); } } module.exports.loadFileData = loadFileData; // ファイル情報を取得する function getFileData (fileName) { let fileStats = fs.statSync(publicCachePath + fileName); if (String(fileStats.mtime) != String(files[fileName].mtime)) { // 更新日時が違っている場合には読み込み直す setFileData(fileName); } return files[fileName]; } module.exports.getFileData = getFileData; routes/publicCache.js 静的コンテンツのルーティング const express = require('express'); const publicCacheLib = require('../lib/public_cache.js'); const router = express.Router(); router.get('/', function (req, res, next) { try { let fileName = req.baseUrl.replace(/^\//, ''); let fileData = publicCacheLib.getFileData(fileName); if (fileData) { res.set({ 'Content-Type': fileData.mime_type, 'Last-Modified': fileData.mtime.toUTCString() }); let acceptEncoding = req.headers['accept-encoding']; if (acceptEncoding.match(/\bgzip\b/)) { // gzipでレスポンス res.set({'content-encoding': 'gzip'}); res.send(fileData.gzip); } else { // 通常データでレスポンス res.send(fileData.plain); } res.end(); } else { res.render('error'); } } catch (e) { throw e; } }); module.exports = router; app.js app.jsに静的コンテンツ用の処理を追記する。 // 静的コンテンツのルーティング let publicCache = require('./routes/publicCache'); // 静的コンテンツを読み込み管理するためのライブラリ let publicCacheLib = require('./lib/public_cache.js'); // 静的コンテンツのリストからルーティングを設定 let files = publicCacheLib.files; for (let fileName of Object.keys(files)) { app.use('/' + fileName, publicCache); } // 静的コンテンツの読み込み publicCacheLib.loadFileData(); まとめ 今回、独自で静的コンテンツの gzip 圧縮配信を実現することができました。 また、コンテンツをメモリ上にキャッシュしたことにより ディスク読み込み負荷なくレスポンスを返す事ができます。 今回の対応を行うと、静的コンテンツを読み込んで管理するという特性を利用して、読み込み時に内容を加工することができます。 こちらを利用して、サンプルコードでは JavaScript の行コメントを削除しています。 独自実装することでパフォーマンスの劣化が生じる懸念もありましたが 速度テストの結果、特に低下は見られませんでした。 また、サービスのメモリ使用量の増加も微々たるものでした。 注意点としては、今回の対応は大容量の静的コンテンツがある場合には メモリを大量に消費するためお勧めできません。 実際にサービスで実装した際には、容量が少なく圧縮効果のあるHTML/ CSS / JavaScript 形式のファイルのみ対応を行いました。 画像ファイル等は圧縮しても効果が薄く容量も大きいため、Express既存の静的コンテンツとして扱っています。 ※Expressの静的コンテンツ配信の仕組みと併用可能です。 今回のような独自の仕様を フレームワーク に組み込めるという自由度の高さも、 フレームワーク 「Express」の魅力だと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

Spring Boot入門 こんにちは。高照です。 Webアプリケーションを作成する際にどうすれば作成できるのか、またはSpring Boot聞いたことあるけど、どういうものなのかよくわからない！ という方に向け今回は簡単にWebアプリケーションを作成できる フレームワーク のSpring Bootについてご紹介します。 ちなみに私は普段の業務では SAStruts という フレームワーク を使用していますがSpring Bootを使って見て便利だと思いこの記事を書くことにしました。 フレームワーク とは まずSpring Bootの前に フレームワーク とは何かをご存じでしょうか。 フレームワーク をなんとなく聞いたことがある、なんとなく分かるという方もいるかもしれませんが、具体的にどんなものなのか知らないという方が多い印象です。ぜひこの機会に覚えていただければと思います。 フレームワーク とは「あらかじめシステムを作成する際に必要な機能が用意された枠組み」のことです。 今回題材にするSpring BootはWebアプリケーションを作成する際に必要な機能があらかじめ多数用意されています。 Spring Bootとは Spring Bootとは Spring Framework をベースとした Java を使用してWebアプリケーションを作成するための フレームワーク です。 Spring Framework が登場した当時は SAStruts という フレームワーク が普及していました。そのため、 Spring Framework は設定のしづらさと日本語ドキュメントの少なさから SAStruts と比較すると普及していないというのが現実でした。しかし、そのような難しい設定部分をある程度省略できるように改良されたものがSpring Bootです。 あらかじめSpring Bootに用意されている機能を使用しつつ比較的簡単にWebアプリケーションを作成することができるようになりました。 また、Spring Bootは数ある Java フレームワーク の中でも非常に人気の高い フレームワーク です。 そのため今回説明は省略しますが、多くの機能を プラグイン のように後から追加することも可能です。 ここで何の プラグイン を追加すればよいのかを、たくさんある プラグイン から選択することが非常に難しいポイントでもあります。 Spring Bootは現在コミュニティも活発で情報も手に入りやすいので習得すると大きなアドバンテージになると思います。 Spring Bootでできること 簡単にWebアプリケーションを作成することができます。 Spring Bootは MVC モデルというものが使用されます。 MVC とは3つの頭文字を取ったものです。 それぞれの名称と役割は以下の通りです。 M : Model → 具体的な処理 V : View → ユーザに表示する画面 C : Controller → ユーザからリク エス トを受け付ける このように役割ごとにプログラムを記述することで簡潔にWebアプリケーションを作成することができます。 前提条件 ここからは実際にプログラムを書きながら説明していきたいと思います。 また、今回はSpring Bootの解説となるため Java とHTMLをある程度知っていることが前提となります。 以下が今回筆者の使用するソフトウェアです。 IntelliJ IDEA Java OpenJDK 11 プロジェクトの作成 ここからは簡単なWebアプリケーションを実際に作成していこうと思います。 Spring Bootのプロジェクトは Eclipse や IntelliJ などの IDE からテンプレートを作成できますが、今回は 公式Webサイト からプロジェクトのテンプレートを作成しダウンロードしようと思います。 公式のプロジェクト作成サイト : Spring Initializr 今回項目は以下の通りにします。 Project : Maven Project Language : Java Spring Boot : 2.3.5 Group : com.example Artifact : demo Name : demo Description : 任意 Pacage name : com.example.demo Packaging : War Java : 11 さらに ADD DEPENDENCIES... CTRL + B を選択します。 以下のようなダイアログが出たらSpring Webを選択します。これにより MVC を使用できるようになります。またローカルで実行するための Tomcat をデフォルトで使用できるようになります。 再び ADD DEPENDENCIES... CTRL + B を選択しThymeleafも追加します。 Thymeleafは動的にHTMLを生成することができる様々なプロパティを追加することができます。Webアプリケーションを作成する際に非常に役立ちます。 以上の操作を行うと以下のようになっていると思います。 再度確認後、画面下部の GENERATE CTRL + ↲ を選択します。 すると、demo.zipというファイルがダウンロードされます。このファイルがSpring Bootプロジェクトのテンプレートです。 demo.zipを解凍し IDE でプロジェクトを開きます。 コードの編集と実行 まずはSpring Bootプロジェクト内にパッケージを作成していきます。 一般的に作成するパッケージは以下の5つです。(今回controllerのみ使用します。) controller : 画面遷移などの画面制御を行うクラスを格納 domain : データベースから取得するためのテータ構造を定義したクラスを格納 form : 画面のフォームを取得するためのデータ構造を定義したクラスを格納 repository : データベースに直接アクセスを行うクラスを格納 service : 具体的な内部処理を行うクラスを格納 続いて、作成したcontrollerパッケージの中にtestControllerクラスを作成します。このクラスでリク エス トを受け付けます。 クラスの 命名規則 としてポピュラーなのは [クラスの役割]Controller や [クラスの役割]Form とつけられることが多いです。 作成すると以下のようなファイル構造になります。 次に初めに表示する画面を作成します。 resources/templates 内にindex.htmlを作成します。 index.html初めに表示されるトップページとして 命名 されることも多いですが名前はindex以外でも問題はありません。 作成すると以下のようなファイル構造になります。 ここからコードを実際に記述していきます。 まずはtestControllerクラスから記述します。 package com.example.demo.controller; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; @Controller @RequestMapping( "/test" ) public class testController { @RequestMapping( "/index" ) public String index(){ return "/index" ; } } testControllerについての解説 @Controller はコントロー ラク ラスであることを示して、主に画面遷移の制御を行います。 @RequestMapping はアクセスされるURLを指定します。今回は localhost :8080/test/index でアクセスできるように指定しています。 return "/index" は resources/templates からの .html を抜いたパスを返しています。 続いてindex.htmlを記述していきます。 <!DOCTYPE html> < html lang = "jp" xmlns:th= "http://www.thymeleaf.org" > < head > < meta charset = "UTF-8" > < title > Spring Boot入門 </ title > </ head > < body > < h1 > Spring Boot Home </ h1 > </ body > </ html > xmlns:th=" http://www.thymeleaf.org " はThymeleafを使用するために必要な文です。 Thymeleafを使用することで簡単に Java からHTMLにデータを表示させることができるようになります。 では実際に Java からHTMLにデータを渡す処理を記述する前にスコープについて解説したいと思います。 スコープで主に使用するものは3つあります。 リク エス トスコープ : 次のページまで有効 セッションスコープ : 同一セッション内で有効 アプリケーションスコープ : Webアプリケーションの起動から終了まで有効 これらのスコープを使用してデータの受け渡しを行います。 今回はリク エス トスコープを用いてデータを Java からHTMLへデータを渡します。 まずはtestControllerを以下のように変更します。 package com.example.demo.controller; import org.springframework.stereotype.Controller; import org.springframework.ui.Model; import org.springframework.web.bind.annotation.RequestMapping; @Controller @RequestMapping( "/test" ) public class testController { @RequestMapping( "/index" ) public String index(Model model){ model.addAttribute( "tag" , "Spring Boot + Thymeleaf入門" ); return "/index" ; } } indexメソッドでModel型の宣言をしています。これは、先ほど説明したリク エス トスコープです。 次の行を見ていただくとリク エス トスコープにデータを追加していることが分かります。データはタグと情報をセットで渡します。今回タグ名を tag データを Spring Boot + Thymeleaf入門 とします。 addAttributeメソッドでは様々なデータを渡すことができます。基本的なデータ型以外にも配列やリスト、マップ、 Enum などを渡しリスト表示等に使用することも可能です。 このリク エス トスコープはreturnするページへ自動で渡されます。 では次にindex.htmlでこのデータを取り出して表示します。 <!DOCTYPE html> < html lang = "jp" xmlns:th= "http://www.thymeleaf.org" > < head > < meta charset = "UTF-8" > < title > Spring Boot入門 </ title > </ head > < body > < h1 > Spring Boot Home </ h1 > < h3 th: text = "${tag}" ></ h3 > </ body > </ html > h3のプロパティの th:text はThymeleafのものです。スコープ内の情報を参照するときはThymeleafのプロパティの値に ${タグ名} を使用することで取り出すことができます 。 また今回説明を省略させていただきますがThymeleafには他にも様々なプロパティが存在し、それらを使用してWebアプリケーションを作成していきます。 ここから更にHTMLの入力を Java で受け取ってみましょう。 まずはtestControllerから。 package com.example.demo.controller; import org.springframework.stereotype.Controller; import org.springframework.ui.Model; import org.springframework.web.bind.annotation.RequestMapping; @Controller @RequestMapping( "/test" ) public class testController { @RequestMapping( "/index" ) public String index(Model model){ model.addAttribute( "tag" , "Spring Boot + Thymeleaf入門" ); return "/index" ; } @RequestMapping( "/input" ) public String input(String testInput, Model model){ model.addAttribute( "tag" , "Spring Boot + Thymeleaf入門" ); model.addAttribute( "testInput" , testInput); return "/index" ; } } inputメソッドを作成しました。このメソッドではHTMLのFormタグ内のnameプロパティがtestInputのものの値をString型で受け取ります。 String型で受け取る理由としてはどんなデータも格納できるためです。例えば、整数値の入力をIntegerで受け取る際にテキストボックス内に文字列が入力されたとします。その場合受け取った段階でNumberFormatExceptionとなってしまいます。 引数にnameプロパティと同じ項目を書くだけで受け取れるので非常に簡単ですね。 そして受け取った値を再びリク エス トスコープへ格納してindex.htmlを表示します。 ここで見ていただきたいのは model.addAttribute("tag","Spring Boot + Thymeleaf入門"); がもう一度書かれているところです。ここでもう一度リク エス トスコープへ追加されているのは ページ test/index から ページ test/input へ移動してしまうため情報が消えてしまうためです。実行時に試しに コメントアウト してみてください。ページ遷移後、 Spring Boot + Thymeleaf入門 という文字列は消えます。 続いてindex.htmlを以下のように変更します。 <!DOCTYPE html> < html lang = "jp" xmlns:th= "http://www.thymeleaf.org" > < head > < meta charset = "UTF-8" > < title > Spring Boot入門 </ title > </ head > < body > < h1 > Spring Boot Home </ h1 > < form method = "post" action = "/test/input" > < input name = "testInput" type = "text" > < button type = "submit" > 送信 </ button > </ form > < p th: text = "${testInput}" ></ p > </ body > </ html > HTMLからデータを送る際はFormタグを使用します。actionプロパティにはデータを送信する先のURLを指定します。先ほど作成したメソッドのRequestMappingの値は /test/input となるため、これを指定します。 また、先ほどと同様に th:text プロパティを使用しデータを受け取ります。 Formタグのmethodプロパティでpostを指定していますがここではデータが直接見えないようにデータを送信しているだけであって暗号化されていないことに注意してください。そのため安全にデータをやり取りする場合は別に暗号化する仕組みを使用する必要があります。 少し余談ではありますが、 JavaScript や CSS 、画像ファイルは resources/static 内に格納し使用します。 resources/static 内にjsや css 、imgフォルダを作成し管理することをお勧めします。 以上で実装は完了です。実際に実行してみましょう。 実行 実装お疲れ様でした。 では実際にSpring Bootを起動し Webブラウザ からアクセスしてみましょう。 アクセスURLは localhost :8080/test/index です。 このような画面が表示されましたでしょうか。これが表示されていない場合はSpring Bootがちゃんと起動できていないかどこかコードが間違っているかだと思います。 では送信ボタンの横にあるテキストボックスに何かしらテキストを打ち込んで送信と押してみてください。入力されたテキストがそのまま表示されます。 例では Spring 入門 と打ち込んで送信してみます。 このようにちゃんと Spring 入門 と表示されていれば完成です。 また、URLに注目して向てください、 localhost :8080/test/index から localhost :8080/test/input に遷移していることが分かると思います。 また、直接 localhost :8080/test/input にアクセスもしてみてください。送信ボタンを押さなくても直接アクセスできるため動作を確認してみてると、 localhost :8080/test/index と全く同じページになると思います。このような点でバグを生む可能性があるので動作確認はしっかりと行いましょう。 次にtestControllerのinputメソッド内にある model.addAttribute("tag","Spring Boot + Thymeleaf入門"); を コメントアウト して実行してみましょう。 //-- 省略 -- @RequestMapping( "/input" ) public String input(String testInput, Model model){ //model.addAttribute("tag","Spring Boot + Thymeleaf入門"); model.addAttribute( "testInput" ,testInput); return "/index" ; } //-- 省略 -- この状態で実行して localhost :8080/test/index にアクセスしても表示は変わりません。しかし、テキストボックスに文字列を入力し送信ボタンを押すと・・・ コメントアウト 前同様、 Spring 入門 という文字列は出力されます。しかし Spring Boot + Thymeleaf入門 という文字列が消えていることが分かります。 そのためデータをやり取りする際にはスコープに注意してください。スコープは短すぎると今回のように消えてしまいます。逆に想定より長いスコープを使用してしまうと前の情報を抜き出せてしまい、情報流出が起こる可能性にもつながってしまいます。そのため、使用用途に合ったスコープを使用するようにしましょう。 まとめ Spring Bootを使用して簡単にWebアプリケーションを作成できることを実感していただけましたでしょうか。 実際はDIコンテナなどの難しい部分の説明を省略してしまっていますが調べてみると面白いかもしれません。 今回はテキストを入力・表示をさせただけでしたが、入力情報を検査したり、データベースの情報を取得したりと様々なことが簡単に実装することができます。 また、Thymeleafのプロパティを書き込んでいくだけでUIの処理ができるためBootstrapや WordPress などと合わせて使用すると更に見栄えの良いページができたり、Vue.js等を使用して更に動きのあるページを作成したりと様々な表現も可能となっています。 私の感想としては、Spring Bootについて簡単な部分だけを抽出して書きましたがこれだけでもかなり便利だと感じてしまうほどでした。特にThymeleafとの相性が良くて全体的にまとまっていて非常に使いやすい印象でした。ここまで揃っていると実務でSpring Bootを使って開発できたら楽しそうですね！ 初めて使用すると裏で何をどこまで処理してくれるかなど理解できない部分も多々あります。しかし、慣れてくると非常に簡単にWebアプリケーションを作成できます。 ぜひ、Spring Bootを使用していろいろなWebアプリケーションの作成に挑戦してみてはいかがでしょうか。 以上、Spring Boot入門でした。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、新卒1年目のHiroto-Kitamuraです。 私の所属する部署では RDBMS ( 関係データベース管理システム )に PostgreSQL を採用しており、私も日々勉強を行っています。 その中で難しく感じたことの1つが、ターミナルに打ち込むコマンドです。 RDBMS が変わっても共通する点の多い DML (テーブル内データを操作する系統の SQL 、SELECTやINSERTなど)と異なり、コマンドは RDBMS によって差が大きく、私はなかなか慣れることができませんでした。 またインストール方法についても、簡単なインストールツールがあるとはいえ RDBMS による違いは大きいでしょう。 記事をご覧の皆様の中にも、複数の RDBMS を使っていて混乱したことがある方は多いのではないでしょうか。 本記事では、 SQL はある程度わかるけど自分でインストールしたりコマンドで管理を行ったことがないという方や、データベースを触ったことはあるけど PostgreSQL はわからないという方向けに、最も基本的である Windows における 簡単なインストール方法 や 基本的なコマンド について書いていきたいと思います。 なお、 SQL が何かわからない、ほとんど触ったことがないという方は本記事を見ながら PostgreSQL のインストールをした後、無料でダウンロードできる 標準教科書 の1～6章などで基本的な SQL について知ることをおすすめします。 ◆ 関連記事 ・ 【SQL入門】INSERT まとめ ・ 【SQL入門】UPDATE まとめ ・ 【SQL入門】DISTINCT 使い方 ・ RDBMSとDBMSについて【初心者向け】 ・ SQLの基本【まとめ】 はじめに PostgreSQLのインストール手順 ダウンロード インストール pgAdminの使い方 PostgreSQLの基本的なコマンド PGDATA環境変数 initdb pg_ctl psql createuser, dropuser createdb, dropdb 終わりに 参考文献 PostgreSQL のインストール手順 Windows における PostgreSQL の簡単なインストール手順です。 本記事ではWindows10 64bit版における手順を説明します。 なお、本記事で紹介する方法以外に ソースコード からコマンドでインストールする方法もありますが、難しく初心者にはメリットもあまりないので今回は触れません。 ダウンロード www.postgresql.org まず、このページのDownload the installerをクリックして ダウンロードサイト に移動してください。 その後、 Windows x86-64 の列にあるダウンロードリンクをクリックすると PostgreSQL の インストーラ (インストールプログラム)がダウンロードされます。 バージョンは会社等で指定があればそれにするべきですが、特になければ最新のもの(記事投稿時点で13)で大丈夫です。 ただし新しいバージョンが出たばかりだと PostgreSQL日本語ドキュメント が対応していない場合もあるので、その場合は1つ前のバージョンをインストールしたほうがいいかも知れません。 インストール いよいよ PostgreSQL のインストールに入ります。 前項でダウンロードした インストーラ ( postgresql -[バージョン番号]- windows -x64.exe)をダブルクリックして起動しましょう。 Nextを押して進めていくとインストールする場所や付属ツールの有無などを聞かれますが、特に必要性やこだわりがなければデフォルトのままで問題ありません。 しばらくするとスーパーユーザー(管理者)のパスワード入力を求められるので、使用するものを入力してください。 慣例的に、最初のユーザー名はpostgresになっています。 このユーザー名とパスワードはデータベースを管理する上でログインに必要なので、必ず覚えておきましょう。(パスワードは忘れても再設定可能です) 次に、 PostgreSQL が外部と接続する際に用いるポート番号の設定です。 基本はデフォルト値(5432)で問題ありませんが、既に使われている場合は警告が出て先に進めませんので、5433など別の番号にしましょう。 今度は ロケール (地域)の設定です。 日本に設定しておくと全角文字の並べ替え等の際に日本語を考慮した挙動をしてくれるようですが、その分検索性能が低くなる場合があるので、C(無設定)にするのがおすすめです。 なお、この場合でもデータベースに日本語は利用できますので、日本語のデータを入れる予定がある場合でも基本的にCで問題ありません。 その後設定事項を確認してNextを押していくとインストールが始まります。 しばらくかかるので、気長に待ちましょう。 この画面が出ればインストールが終わっています。 Stack Builderは追加ツールをインストールするためのものなので、特に必要がなければチェックを外しましょう。 Finishを押せば、ついに PostgreSQL のインストール完了です！ pgAdminの使い方 先程インストールした PostgreSQL には、pgAdminという GUI ツールが含まれています。 データベースの管理コマンドについては後程触れていきますが、それよりまず SQL を書いてテーブルやデータを操作したい！という方はこちらを使用するのがおすすめです。 本筋から外れるので簡単な説明に留めますが、気軽に SQL を触りたい方はぜひご覧ください。 まずスタートメニューを開き、pgAdminと入力して出てきたアプリをクリックします。 ブラウザでpgAdminが起動するので、ユーザー名にpostgres、パスワードに先程決めたものを入力してログインしましょう。 ログインが出来たら、左側の>マークを押していくと現れるpostgresデータベース(本格的な開発は他のデータベースが望ましい、下記参照)をクリックで選択し、上のTools>Query Toolをクリックします。 するとエディタが現れるので、 SQL を書いていきましょう。 書いた SQL はF5キーで実行できます。 なお、本記事は PostgreSQL のインストールとコマンドについての記事なので、 SQL についての詳しい説明は割愛します。 マニュアルなどを参照してください。 ちなみに、postgresデータベースは後述の psql コマンドや サードパーティ 製品におけるデフォルトの接続先として使われるためのものなので、本格的なデータ構築を行う際はcreatedbコマンドやpgAdmin>Databases右クリックで別にデータベースを作成してそこで行うようにしましょう。 PostgreSQL の基本的なコマンド 本節ではインストール後ターミナルで使用できる PostgreSQL の基本的なコマンドと、その使い方について解説します。 本記事では Windows を前提に紹介しますが、 Mac や Linux でも基本的な部分は変わりません。 ただし、 Ubuntu のaptでインストールした場合はinitdbやpg_ctlまわりのコマンドが大きく違いますのでご注意ください。(詳しい紹介は割愛します) 当然ですが PostgreSQL をインストールしないと使えないので、まずは前節を見ながらインストールを行った上で、本節をご覧ください。 なお、コマンドのオプションは主なもののみの紹介となっています。詳しく知りたい方は、 PostgreSQL ドキュメントをご参照ください。 PGDATA 環境変数 これはコマンドではありませんが、以下の解説で時々登場する用語なのでここで説明します。 PGDATA 環境変数 はOSで設定できる、 PostgreSQL のデータベース クラスタ (データベースの集まり)のフォルダを表す値です。 以下で解説するコマンドではデータがあるフォルダを指定する必要があるのですが、この 環境変数 を設定しておくことでコマンドを入力する際にいちいちフォルダ名を入力する必要がなくなります。 設定方法ですが、まずスタートメニューを開いてシステムの詳細設定と入力して出てきたアプリをクリックします。 その後[ 環境変数 ]>[新規]の順にクリックし、変数名の欄にPGDATA、変数値にインストール時に指定したデータベース クラスタ の場所(デフォルト値ではC:\Program Files\ PostgreSQL \<バージョン番号>)を入力し、OKを押していけば設定完了です。 なお、他にも PostgreSQL 関連の 環境変数 が存在しますが、同様に設定すればOKです。 initdb 以下、大カッコ [ ] で囲まれている部分は、省略可能であることを表します。 指定したフォルダに PostgreSQL のデータベース クラスタ を作成するコマンドです。 PostgreSQL ではこのデータベース クラスタ の中にデータベースを作成することになります。 先述した方法でインストールを行うと自動的に1つ クラスタ が作成されるので、単純な利用方法であれば実行する必要はありません。 ただしデータベースサーバーは クラスタ 単位で起動できるため、1つのマシンを複数のサービスで利用する場合にはこのコマンドを使うことになるでしょう。 なお、ポート番号が同じサーバーは複数同時起動できないので、複数のサーバーを同時起動する場合は設定ファイル( postgresql .conf)でportパラメータを変更する必要があります。 詳しくは PostgreSQL ドキュメント等を参照してください。 コマンドの使い方: $ initdb [-D ディレクト リ] [-E エンコーディング ] [--locale= ロケール ] [-U スーパーユーザ名] オプションの意味は以下のとおりです。 オプション名 意味 省略時のデフォルト値 -D クラスタ を作成するフォルダ PGDATA -E 文字 エンコーディング OSの設定値 --locale ロケール (前節で解説) OSの設定値 -U スーパーユーザー名 コマンドの実行者のOSにおけるユーザー名 -Dには空のフォルダを指定するようにしてください。 -EにはUTF8や EUC _JPが使用できます。 -Uでは クラスタ の管理者ユーザー名を指定できます。 OSのユーザーと PostgreSQL のユーザーは別個の概念 なので、異なる名前の設定が可能です。 pg_ctl PostgreSQL サーバーの起動、終了などを行うコマンドです。 設定ファイルの変更反映にも使用します。 サーバーが起動していないと SQL や以下の管理コマンドの実行はできません。 ただし、先述のインストール方法を使うとインストール完了時とPC起動時に自動的にサーバーが起動する設定になるので、毎回このコマンドでサーバーを立ち上げる必要はありません。 コマンドの使い方: $ pg_ctl 操作 [-D ディレクト リ] [-t 最大待ち時間] [-m シャットダウンモード] 操作の部分に入る主なコマンドは以下のとおりです。 コマンド名 意味 start サーバーを起動する stop サーバーを停止する restart サーバーを再起動する reload 設定ファイルを再読込する status サーバーの起動状況を表示する 設定ファイルの項目の中には、reloadではなくrestartでサーバーを再起動する必要があるものもあります。 詳しくは PostgreSQL ドキュメントを参照してください。 オプションの意味は以下のとおりです。 オプション名 意味 省略時のデフォルト値 -D クラスタ のあるフォルダ PGDATA -t 起動・停止の最大待ち時間 60秒 -m 停止モード(下記で解説) fast -tはstart,stop,restart、-mはstop,restartを行うときのみ利用できます。 -mは停止時の挙動を指定するもので、以下のオプションがあります。 オプション名 意味 smart サーバーへの接続の切断を待つ fast サーバーへの接続を強制切断 immediate サーバーを緊急停止 次回起動時に復旧が必要 psql 起動している PostgreSQL サーバーに接続し、データベースの操作などを行うコマンドです。 コマンドの使い方: $ psql -l [-p ポート番号] [-U ユーザー名] または $ psql [-c コマンド] [-f ファイル名] [-p ポート番号] [-U ユーザー名] [-d データベース名] オプションの意味は以下のとおりです。 オプション名 意味 省略時のデフォルト値 -l データベースの一覧を表示して終了 実行しない -c 実行する SQL コマンド 実行しない -f 実行する SQL が書かれたファイル名 実行しない -p サーバーのポート番号 PGPORT 環境変数 -U 接続する PostgreSQL ユーザー名 コマンドの実行者のOSにおけるユーザー名 -d 接続するデータベース名 postgres -dを省略してデータベース名のみ記載することも出来ます。 また、データベース名のあとに-Uを使わずユーザ名を記載することも可能です。 $ psql [-c コマンド] [-f ファイル名] [-p ポート番号] データベース名 ユーザー名 -l,-c,-fを指定した場合、指定の操作を実行してコマンドは終了します。 これらを指定しなかった場合は、 PostgreSQL ターミナルが起動し、先述のpgAdminのように SQL を入力、実行することが出来ます。 なお、各種操作の実行には設定ファイルに示された方法によるログインが必要です。 createuser, dropuser ユーザーを作成、削除するコマンドです。 コマンドの使い方: $ createuser [オプション] 作成するユーザー名 $ dropuser [-p ポート番号] [-U ユーザー名] 削除するユーザー名 オプションでは、主に作成するユーザーに許可する操作を設定できます。 主なオプションとその意味は以下のとおりです。 オプション名 意味 省略時のデフォルト値 -s(-S) スーパーユーザー権限を設定する(しない) -S -d(-D) データベース作成権限を設定する(しない) -D -r(-R) ユーザー作成権限を設定する(しない) -R -l(-L) ログイン権限を設定する(しない) -l -P 作成と同時にパスワードを設定する しない --interactive 権限の有無を対話的に指定 しない -p サーバーのポート番号 PGPORT 環境変数 -U このコマンドを実行する PostgreSQL ユーザー名 コマンドの実行者のOSにおけるユーザー名 権限関連のオプションを指定しない場合はログイン権限のみ持つユーザーが作成されます。 -Pオプションを指定しない場合、パスワードは設定されません。 ただし後で SQL を使って設定ができますし、パスワードを使わないログイン認証方法もあるため、必ずしもここで設定する必要はありません。 -Uオプションは現在 コマンドプロンプト を開いているOSのユーザー名とユーザー作成権限を持つ PostgreSQL のユーザー名が異なる場合に使用します。 作成・削除するユーザー名を入力するのではないことに注意してください。 ちなみに、 PostgreSQL のインストール時に作成したユーザーはスーパーユーザー権限を持っています。 スーパーユーザー権限はあらゆる権限を兼ね備えた権限なので、安易に作成するべきではありません。 createdb, dropdb データベースを作成、削除するコマンドです。 コマンドの使い方: $ createdb [-O ユーザー名] [-T テンプレートDB名] [-p ポート番号] [-U ユーザー名] データベース名 $ dropdb [-p ポート番号] [-U ユーザー名] データベース名 オプションの意味は以下のとおりです。 オプション名 意味 省略時のデフォルト値 -O データベースの所有者 -Uで指定したユーザー -T 元となるデータベース template1 -p サーバーのポート番号 PGPORT 環境変数 -U 接続する PostgreSQL ユーザー名 コマンドの実行者のOSにおけるユーザー名 PostgreSQL では、新しいデータベースはいずれかの既存のデータベースをコピーする形で作成します。 デフォルトではtemplate1という空のデータベースを利用しますが、-Tコマンドで他のデータベースを指定することも出来ます。 また、事前にtemplate1にデータを追加しておくことで共通のテンプレートを作成することも可能です。 終わりに PostgreSQL のインストール方法、コマンドの基本について駆け足で説明してきましたが、いかがでしたでしょうか。 恐らく、読んでいて「このコマンドが動かない」「この場合はどうするの」といった疑問が生まれた方も多いでしょう。 それだけ PostgreSQL は奥が深く、短い記事ですべて詳しく説明することができないということなのです。 ただ、だからといって PostgreSQL が勉強が難しい、とっつきづらいということではありません。 幸いなことに、 PostgreSQL には日本語で書かれた詳しい ドキュメント があります。 Google で検索すれば個人ブログ等で噛み砕かれた使い方も様々出てくるでしょう(この記事もその1つとして書いています)。 この記事であまり触れられなかった内容として、設定ファイル( postgresql .conf,pg_hba.confなど)・バックアップなどがあります。 気になった方はぜひ調べてみてください。 本記事を入り口に、 PostgreSQL の世界に入ってくる方が増えることを願っています。 参考文献 福岡博・笠原辰仁・宇山公隆 (2019) 『 OSS 教科書 OSS -DB Silver Ver2.0対応』 翔泳社 SRA OSS , Inc. 日本支社 正野裕大 (2020) 『徹底攻略 OSS -DB Silver問題集［Ver.2.0］対応』 インプレス 日本 PostgreSQL ユーザ会 「 PostgreSQL 日本語ドキュメント」< https://www.postgresql.jp/document/ > エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちはchoreiiです。先日、 応用情報技術者試験 を受験してきました（2020年10月18日）。記憶が新しいうちに自身の対策や勉強法をアウトプットします。 はじめに 応用情報技術者試験とは 応用情報技術者試験の受験背景 自己採点結果 対策と勉強法 午前 1.基礎理論 2.コンピュータシステム 3.技術要素 4.開発技術 5.マネジメント 6.ストラテジ 午後 おわりに 2020/12/25 追記 応用情報技術者試験 とは 応用情報技術者試験 とは、 IPA （ 情報処理推進機構 ）が主催する 情報処理技術者試験 の一つです。 引用：情報処理技術者試験 試験要綱 試験要項の対象者像には「高度IT人材となるために必要な応用的知識・技能をもち、高度IT人材としての方向性を確立した者」とあり、 基本情報技術者試験 よりワンランク上の試験と位置付けられています。 問題形式は、午前は マークシート の択一で、午後は記述式になっています。 応用情報技術者試験 の受験背景 ラク スに新卒入社してから今年で3年目になります。業務で必要な知識はある程度ついてきましたが、体系立てて学んだわけではなく、なんとなく理解した気になっているIT知識なども多くありました。そんな中、職場の先輩の勧めもあり受験を決意しました。 ちなみに私は 基本情報技術者試験 を受験しておらず、今回が初の 情報処理技術者試験 になります。 応用情報技術者試験 の出題範囲が 基本情報技術者試験 を内包していると聞いたため、 基本情報技術者試験 を飛ばして 応用情報技術者試験 を受験しました。 自己採点結果 2020年11月5日現在合格発表はされていません。これは例年のことで、 応用情報技術者試験 は受験日から2ヶ月後程度に発表されます。 令和2年度10月試験　合格発表スケジュール そのため、午前は公式の解答、午後は公式ではありませんが IT資格の歩き方 の解答例を参考にさせていただいて自己採点しています。 自己採点 合格点 午前 85点 60点 午後 65点 60点 午前は マークシート 式なのでマークミスさえなければ余裕を持って突破できていますが、午後はギリギリでどちらに転んでもおかしくないと思います。自分としては正解か不正解かわからないものは不正解判定にしたので、合格の方が分が良いのではないかと思っています。 対策と勉強法 さて、ようやく本題の対策と勉強法についてお話します。午前／午後別に記載しますが、先に全体の所要時間などや参考書籍を以下に記載します。 勉強期間 1ヶ月 勉強時間 50〜60時間程度 勉強方法 応用情報技術者 合格教本 https://www.amazon.co.jp/dp/4297109514 www.amazon.co.jp 応用情報技術者 過去問道場 www.ap-siken.com 午前 次のような流れで勉強を進めました。 過去問道場で午前の過去問を確認 まずは、現時点でどの程度勉強しなければいけないかを測るために、無勉強の状態で過去問にトライしてみました。結果としてほとんどの問題に解答できず、解答できたものも「この4択なら多分これ」といったような選択肢ありきかつ自信がない状態でした。そのため過去問の確認は早々に見切りをつけました。 合格教本を一通り読む（2日） 範囲全体を網羅した書籍があった方がいいと思い、前述の合格教本を購入し土日で一通り読み切りました。一通りの情報を頭に一度通すのが目的で読み進めたため、章末問題にはあえて手をつけず、自分が理解できたと思ったタイミングでどんどん読み進めました。私の場合「業務で触れている知識」「大学時代に学んだ知識」が前提にあったため、知識の補間や穴埋め的に読み進めることができたため2日で読み終わっていますが、その下地がない場合はもう少し読むのに時間がかかると思います。 過去問と書籍学習の反復（1〜2週間） 通勤途中に過去問道場で過去問を解き、家では間違えた箇所を合格教本で見直したり、章末問題を解いたりしていました。過去問を解く際は直近の2回分を除いて、直近数年分を優先的に解いていました。これは 応用情報技術者試験 の午前問題の出題傾向として、「直近の過去2回と同じ問題は出題されない」「全80問のうち半分程度は過去問から出題される」というものがあったためその点を意識しました。 合格教本の模擬試験を解く 過去問で9割程度の正答できるようになってきたため、合格教本に付属していた模擬試験を実施しました。結果として1時間以上時間を残し解答でき、正答率も8割を超えていたので午前に絞った勉強は終了し、午後勉強の合間に今まで通り過去問を解いたり、合格教本で見直す状況へシフトしました。 大筋としては以上の通り進めましたが、 応用情報技術者試験 は出題範囲が広いため出題分野によって勉強量に差がでました。出題分野別にどのようなことを意識していたかを簡単に記載します。 1.基礎理論 代表する出題内容 「集合」「 情報理論 」「確率」 「2分木」「スタック・キュー」「 アルゴリズム 」 対策 基本知識を覚えた上での計算問題が多い印象です。情報系の大学や専門学校に通っていれば一度講義で解説されている内容で、忘れてしまっていても参考書籍を読んで過去問を解けばすぐに思い出せると思います。反面、初めて内容を勉強する場合は基本知識の吸収と計算問題のパターンへの慣れが必要になるためある程度の勉強時間は確保したいところです。この範囲の知識は午後問題の「プログラミング」の範囲に大きく影響してくるので確実に理解を進めることをおすすめします。 2.コンピュータシステム 代表する出題内容 「組合せ 論理回路 」「パイプライン処理」 「集中／分散処理システム」「 待ち行列 理論」「システムの信頼性評価」 「 排他制御 」「言語プロセッサ」 対策 「1.基礎理論」ほどではありませんが、処理の仕組み・流れを覚えて、その知識を使って計算を解く問題が多いです。コンピュータのソフトウェア・ハードウェアの構成要素など暗記しなければならない問題も同じくらい出題されるため出題範囲がとても広いです。全部覚えるのが理想ですが私はそこまで時間がとれなかったため、「計算問題は確実に解けるようにする」「暗記は過去問で出たものを優先的に覚える」ことを意識していました。 3.技術要素 4.開発技術 代表する出題内容 「データベース」「ネットワーク」「セキュリティ」 「開発手法」「 オブジェクト指向設計 」「テスト技法」「レビュー手法」 対策 普段アプリケーション開発をしている人は馴染みがある範囲なのでそこまで勉強しなくても点数が取れると思います。一から勉強を始める場合もデータベースは基本的な構文や仕組みしかでてこないため難しくありません。ネットワークとセキュリティに関しては、通信規格や暗号化の規格といった技術の世代をまたいで覚えなくてはいけない分野があり、名前や説明内容も似通っているため覚え間違いをすることが多いです。私は、時系列や表に書き出すなどして混同しないように気をつけました。また、最近追加された「 アジャイル 開発」に関する問題が頻出されています。 5.マネジメント 6.ストラテジ 代表する出題内容 「プロジェクトマネジメント」「 タイムマネジメント 」「コストマネジメント」 「システム戦略」「経営戦略」 対策 この範囲に関しては私自身、深い理解を諦めた部分があります。耳馴染みがない単語が多く一から覚えることが多いですが、午前で出題される問題数はマネジメント10問、ストラテジ20問なので、勉強時間に対する点数の伸びが他の技術的分野に比べて低いと考えたためです。積極的に勉強を捨てるのはリスクが高いですが、この範囲を深追いするより技術系の基礎知識をしっかりと定着させることが優先だと感じています。また、後述しますが午後は解答分野を選択でき、マネジメントとストラテジを選択しないことも可能なため、その点も優先度を下げた理由になります。 午後 午後試験は記述式になり難易度が上がります。記述式だからというよりは、問題文が長文になるため文章の読解力が求められ、出題分野の知識の習得を前提とした上で解答を求められます点が難しいと感じました。解答は必答が1問存在し、他10問の中から4問を選択することになります。 必答 情報セキュリティ 選択（4問） システム アーキテクチャ ネットワーク データベース 組込み システム開発 情報 システム開発 プログラミング プロジェクトマネジメント サービスマネジメント 監査 ストラテジ 午前勉強と勉強方法に大きな流れの変化はありませんが、以下のようにすすめています。また、午後は分野の選択式であり、分野毎の勉強方法は個人差が大きいので記載はしません。 解答予定の項目を絞りこむ 前述の通り、情報セキュリティ以外は10問の中から4問を選択して解答することになります。年度や自身との相性によって問題の難しさが変わるので4問だけに絞るのはリスクが高いですが、10問全てを解けるようになる必要はなく、解答予定の項目を5〜6問程度に絞ることで勉強しやすくなります。私はマネジメント系とストラテジ系の問題は諦めて残りの6問を解答できるように勉強しました。 過去問と書籍学習の反復（2〜3週間） 午後試験は暗記で点数を伸ばすことができる午前試験とは違い、問題の解き方や考え方の慣れが必要なため早速過去問を解き始めました。この時意識したことは、「分からないなりにでも自分の力で記述問題を解答を記載し、何も書かずに模範解答を見ないようにする」ことです。記述解答の場合は模範解答が絶対の正解ではありません。（もちろん、ポイントとなる単語を使用しているかどうかといった基準はあります。）最初から解答を見てしまうと問題文を読んで解答を導き出す力が身に付かず、いざ本番で少し問題形式が変わっただけでどこを読めばいいのか分からず、まったく解けなくなる恐れがあります。 合格教本の模擬試験を解く（試験前日） 直前に予想問題を解いた時は正答率8割程度でした。本番結果は自己採点に記載の通りに下にブレてしまっていますが、当時はある程度手応えがあったため、試験直前まで解説を読んで問題文の読み進め方や解答のあたりのつけ方を反復していました。 おわりに 所感として、勉強の流れ自体や意識していたことに間違いはなかったと思っていますが、午後試験の対策にもう少し時間を使うべきだったと思っています。逆に午前試験は午後試験の勉強の合間にも勉強できたためもう少し早めに切り上げるべきでした。 まだ、合格発表はされていませんが、合格していれば データベーススペシャリスト の勉強を、不合格であれば再度 応用情報技術者試験 の勉強して受験しようと考えています。反省点も存在する受験でしたが、改めて勉強したことによって理解が深まった部分もあるため、合格していなかったとしても意義のある受験だったと思います。 この記事が今後、 応用情報技術者試験 を受験する方の手助けとなれば幸いです。 2020/12/25 追記 本日合格発表だったのですが、無事合格していました！！ 自己採点では午前85点／午後65点だったので概ね試算通りの結果でした。正直なところ午後試験の点数がギリギリなため勉強量が足りていたとは言い難いです。ですが合格は合格と受け止め、今回の結果に甘んじずに今後も勉強して理解を深めて行きます。今回無事合格したことによって高度試験（ データベーススペシャリスト など）の午前Ⅰ試験が免除される（2年間）ため、次の春試験で データベーススペシャリスト を本命としていずれかの高度試験を受験します。 引用：情報処理技術者試験の高度試験、情報処理安全確保支援士試験の一部（午前Ⅰ試験）免除制度 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 使った物 準備 その1：tweetをする。 その2：特定のユーザーのtweetを取得する。 その3：検索ワードで引っかかったtweetをJSONファイルにする。 おわりに はじめに こんにちは。 rs_chankoです。 本格的に寒くなってきましたね。 スノーボード が楽しみな季節です。 全然関係ないので本題に入ります。 エンジニアたるもの、情報収集に SNS って欠かせないですよね。 私は気軽に使えるし、ユーザーも多いため Twitter をよく利用しています。 その昔、シュ○○。○○○○ーだとか、ザ○○○ドとか、 UserStreamsで常に新しい tweet が流れてくるクライアント、流行りましたよね。（流行りましたよね？） 私はそんなクライアントを使っていわゆる「ツイ廃」という人種でした。 ただ、 API の仕様変更だとかなんだとかでそのようなクライアントからも離れ、今は公式に落ち着いています。 当時は「 API 」ってなんぞや、と思いつつも、調べることも特にありませんでした。（高校生の頃の自分の欲のなさよ…） 最近、業務で API チックな実装に触れた時に突然このことを思い出したんですよね。 そして思いました。 「公式に慣れたとはいえ、自分の理想のクライアント作れたら、面白くね？？」 ということで、今回はクライアント作成まではいきませんが、 ひとまず API で何かしてみようと言うことで初級編をやったので記事にしてみます。 使った物 Twitter アカウント Python -3.9.0( VSCode ) 準備 Twitter で API を利用するには、まず「利用申請」が必要になります。 この辺は結構いろんなサイトがあるので、参考にしました。 参考にしたサイトはこちら www.itti.jp これが完了してメールが届くと、ようやく API を使ったいろんなことができます。 ひとまず、このあと必要になる下記4つを取得します。 consumer_key consumer_secret access _token access _token_secret 探すの結構苦労したんですが、実はまとまっていました。 下の画像の順に探っていくと全部取得できました。 API _Keyの取得 これらが取得できたら、早速コードを書いていきましょう その1： tweet をする。 クライアントを作って tweet が見れたところで、自分が tweet できなきゃ面白くないですよね。 なので、直書きでとりあえず tweet してやる！といった感じで書いてみました。 #tweetを投稿 import tweepy # 準備で取得したキーを格納する consumer_key = "consumer_key" consumer_secret = "consumer_secret" access_token = "access_token" access_token_secret = "access_token_secret" # Twitterオブジェクトの生成 auth = tweepy.OAuthHandler(consumer_key, consumer_secret) auth.set_access_token(access_token, access_token_secret) api = tweepy.API(auth) # tweetを投稿 api.update_status( "APIでツイートできた〜〜〜やった〜〜〜〜" ) #準備で取得したキーを格納する の部分には各自取得したキーをいれてください。 これを実行すると… tweet _ スクリーンショット こんな感じで実際に tweet できました。 OAuth認証 で API 呼び出しする感じですね。 この段階で「お、意外と簡単やん。」と自信を付けさせてくれます。 API ってこう言うところが偉大ですよね。 その2：特定のユーザーの tweet を取得する。 今回は我らが＠DevRakusの tweet を取得します。 twitter.com 最新の5tweetくらいを取得してみます。 import tweepy consumer_key = "consumer_key" consumer_secret = "consumer_secret" access_token = "access_token" access_token_secret = "access_token_secret" # Twitterオブジェクトの生成 auth = tweepy.OAuthHandler(consumer_key, consumer_secret) auth.set_access_token(access_token, access_token_secret) api = tweepy.API(auth) #tweetを取得 Account = "DevRakus" #取得したいユーザーのユーザーIDを代入 tweets = api.user_timeline(Account, count= 5 , page= 1 ) for tweet in tweets: print ( 'tweetId : ' , tweet.id) # tweetのID print ( 'tweetUser : ' , tweet.user.screen_name) # ユーザー名 print ( 'tweetDate : ' , tweet.created_at) # 呟いた日時 print (tweet.text) # tweet内容 print ( 'favo : ' , tweet.favorite_count) # tweetのいいね数 print ( 'retw : ' , tweet.retweet_count) # tweetのRT数 print ( '=' * 80 ) # =を80個表示(区切り線) これを実行すると… tweet _取得結果 こんな感じで tweet の取得ができた～～～～！ クライアント作ってユーザーページ開くときはこんな感じで tweet 取得して表示する… とかそんな感じなんですかね。 その3：検索ワードで引っかかった tweet を JSON ファイルにする。 さっきのよりも、よりシステムチックに tweet を取得してみましょう。 今回は弊社の製品、 楽楽精算 と入った tweet を検索して JSON ファイルに仕立て上げようという魂胆です。 #tweetをファイルとして保存 import json import datetime import time from requests_oauthlib import OAuth1Session from pytz import timezone from dateutil import parser # 取得した各種キーを格納----------------------------------------------------- consumer_key = "consumer_key" consumer_secret = "consumer_secret" access_token = "access_token" access_token_secret = "access_token_secret" SEARCH_TWEETS_URL = 'https://api.twitter.com/1.1/search/tweets.json' RATE_LIMIT_STATUS_URL = "https://api.twitter.com/1.1/application/rate_limit_status.json" SEARCH_LIMIT_COUNT = 10 # セッション確立 def get_twitter_session (): return OAuth1Session(consumer_key, consumer_secret, access_token, access_token_secret) # キーワード検索で得られたtweetを取得する # max_idを使用して次の100件を取得 def search_twitter_timeline (keyword, since= '' , until= '' , max_id= '' ): timelines = [] id = '' twitter = get_twitter_session() params = { 'q' : keyword, 'count' : SEARCH_LIMIT_COUNT, 'result_type' : 'mixed' } if max_id != '' : params[ 'max_id' ] = max_id if since != '' : params[ 'since' ] = since if until != '' : params[ 'until' ] = until req = twitter.get(SEARCH_TWEETS_URL, params=params) if req.status_code == 200 : search_timeline = json.loads(req.text) for tweet in search_timeline[ 'statuses' ]: # 次の10件を取得したときにmax_idとイコールのものはすでに取得済みなので捨てる if max_id == str (tweet[ 'id' ]): print ( 'continue' ) continue timeline = { 'id' : tweet[ 'id' ] , 'created_at' : str (parser.parse(tweet[ 'created_at' ]).astimezone(timezone( 'Asia/Tokyo' ))) , 'text' : tweet[ 'text' ] , 'user_id' : tweet[ 'user' ][ 'id' ] , 'user_created_at' : str (parser.parse(tweet[ 'user' ][ 'created_at' ]).astimezone(timezone( 'Asia/Tokyo' ))) , 'user_name' : tweet[ 'user' ][ 'name' ] , 'user_screen_name' : tweet[ 'user' ][ 'screen_name' ] , 'user_description' : tweet[ 'user' ][ 'description' ] , 'user_location' : tweet[ 'user' ][ 'location' ] , 'user_statuses_count' : tweet[ 'user' ][ 'statuses_count' ] , 'user_followers_count' : tweet[ 'user' ][ 'followers_count' ] , 'user_friends_count' : tweet[ 'user' ][ 'friends_count' ] , 'user_listed_count' : tweet[ 'user' ][ 'listed_count' ] , 'user_favourites_count' : tweet[ 'user' ][ 'favourites_count' ] } # urlを取得 if 'media' in tweet[ 'entities' ]: medias = tweet[ 'entities' ][ 'media' ] for media in medias: timeline[ 'url' ] = media[ 'url' ] break elif 'urls' in tweet[ 'entities' ]: urls = tweet[ 'entities' ][ 'urls' ] for url in urls: timeline[ 'url' ] = url[ 'url' ] break else : timeline[ 'url' ] = '' timelines.append(timeline) else : print ( "ERROR: %d" % req.status_code) twitter.close() return timelines, id def write_tweet_to_file (timelines, dt): # 日付ごとにjsonで書き込み f = open ( "/Users/koichi/Documents/tweet/tweet-" + dt + ".json" , "a" ) for timeline in timelines: json.dump(timeline , f , ensure_ascii= False , sort_keys= True # ,indent=4 , separators=( ',' , ': ' )) f.write( ' \n ' ) f.close() return ## メイン処理 timelines = [] # tweetID max_id = '' # 検索ワード keyword = '楽楽精算' # tweet取得対象日 start_dt = '20201104' start_dt = datetime.datetime.strptime(start_dt, '%Y%m%d' ) for i in range ( 7 ): dt = (start_dt - datetime.timedelta(days=i)).strftime( '%Y-%m-%d' ) # print(dt) since = str (dt) + '_00:00:00_JST' until = str (dt) + '_23:59:59_JST' while True : # tweet検索 timelines, max_id = search_twitter_timeline(keyword, since, until, max_id) time.sleep( 5 ) if timelines == []: break write_tweet_to_file(timelines, dt) if len (timelines) < SEARCH_LIMIT_COUNT: break 先ほどまで使っていた tweepy というライブラリではない方法で試してみました。 実行した結果は… tweet _ JSON ファイル できたできた！ ただ、筆者はここで力尽きてしまったのでせっかく JSON にしたのに tweet の形にして復元みたいな もう一段階の作業 をやりませんでした はできませんでした… ただ、今回みたいなことをしたおかげで、 特定のワードが入ったtweetしか流れてこないTL みたいなのもできそうで面白そうですよね。 (普通に公式の検索機能と同じですが…) おわりに お恥ずかしながら、筆者はTwitterAPIで遊んでみようと思って初めて Python を触りました。(環境構築 からし ました。) Python ってとても扱いやすくていい言語ですよね。(筆者は制約が多い方が好きですが) API も相まって、初級編としてはかなり扱いやすくてこれからいろいろ試してみたいなぁという気持ちになりました。 Python 自体が未知の世界で、ほとんど参考にした記事の内容を拝借させていただきましたが、 とりあえずお試しに触ってみたい！という方の目に留まればよいと思います。 次回の記事ではもう少し完成形になるようなものを書けると…いいな…(将来の自分に期待) 以下の記事を参考にしています。 qiita.com qiita.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

こんにちは ラク スの iketomo です。 今回は アジャイル 開発( Agile ) について紹介させていただきます。 アジャイル 開発の特徴や ウォーターフォール と比較、弊社での スクラム の取組事例などを紹介させていただきます。 皆様が アジャイル 開発手法をどう取り入れるべきかのご参考になればと思います。 ① アジャイル開発とは？ アジャイルソフトウェア開発宣言 ② アジャイル開発の特徴とウォーターフォール開発との違い 戻らないことを前提としたウォーターフォール 戻ること（仕様変更）を前提としたアジャイル開発 開発サイクルの違い ③ アジャイル開発のメリット・デメリット アジャイル開発のメリット アジャイル開発のデメリット ④ アジャイル開発で気を付けるべきこと アジャイル開発≠ドキュメントを作らない 適時のコミュニケーションと確認 顧客にチーム参画してもらう ⑤ スクラムの取組事例 配配開発チームでのスクラムの取り組み 不確実性の低減 改善文化の醸成 楽楽明細開発チームのスクラムの取組 失敗から学びとスクラムとウォーターフォールの融合 ⑥ アジャイル開発の関連書籍の紹介 SCRUM BOOT CAMP THE BOOK アジャイルサムライ みんなでアジャイル アジャイルレトロスペクティブズ Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン スクラムガイド アジャイルマニフェスト ① アジャイル 開発とは？ アジャイル には「素早い」や「機敏」という意味があります。 従来の ウォーターフォール モデルと呼ばれる開発手法が「技術や環境の変化」に対して仕様変更を即応することが難しくなる側面がありました。 アジャイル 開発はそのような煩わしさから解放されるために作られた開発手法になります。 アジャイル 開発の基本概念はあまりに有名すぎるので、割愛させていただきリンクだけ張らせていただきます。 アジャイル ソフトウェア開発宣言 agilemanifesto.org ② アジャイル 開発の特徴と ウォーターフォール 開発との違い 戻らないことを前提とした ウォーターフォール ウォーターフォール では基本的に各工程（要件定義・概要設計・詳細設計）は一方通行で戻らないことを前提としています。 ウォーターフォール 開発において工程が戻るということは、大きなリソースを消費することになるため、避けなければいけません。 そのため 各工程では入念にレビューやチェック、関係者の承認を得て 進むことになります。 ただ開発をしたことがある皆様はわかると思いますが、どれほど入念にレビューしても後工程で問題が発生し仕様変更をしなければいけないことは現場ではよくあります。 例えば実装フェーズで仕様に問題があった時に「概要設計」「詳細設計」まで戻って修正し さらには実装前にテストケースまで作っていた場合、ほとんどのテストケースを作り直しということもあり そういった場合、そこまでに使っていた大きなリソースを無駄にしてしまうこともあります。 また実際に開発完了して顧客に 検収 してもらうと「まったく思っていたものと違う」と言われて呆然としまうこともあるでしょう。 そこで アジャイル 開発の登場です。 戻ること（仕様変更）を前提とした アジャイル 開発 アジャイル 開発では 戻ること（仕様変更）を前提 としています。 そのため、 ウォーターフォール に比べ重厚なチェックなどは行わずに ある程度仕様が纏まったら、とりあえず作って、実物を見てもらいチェックしてもらおうという進め方になります。 見てもらう相手（承認者）は開発内部だけではなく、場合によっては顧客を含めることもあります。 承認者から違うと言われ、仕様変更になれば即対応を行います。 なぜそれができるかというと 開発サークルの単位が小さい からです。 開発サイクルの違い アジャイル 開発では イテレーション （スプリント）と呼ばれる小さいサイクルの開発を反復して行います。 通常 イテレーション は 1週間～長くても1カ月位の単位 で反復して機能追加を行っていきます。 各 イテレーション の中で設計・実装・テストを行い、必要であれば承認者（顧客も含むこともある）に実際の機能を見てもらうことになります。 見てもらった時に、もし予定外の機能要望や変更等があれば、また イテレーション のサイクルを繰り返すことになりますが、小さいサイクルなので問題がありません。 ③ アジャイル 開発のメリット・デメリット アジャイル 開発のメリット 前述していますが、 アジャイル 開発の大きなメリットは 不具合や仕様変更が発生した時の手戻り・ 工数 が少ない ことです。 これにより柔軟に顧客の要望を取り入れやすく、 顧客ニーズに最大限に答えることができます。 また 要件がはっきり決まっていない案件 でも作りながら見てもらいながら開発を進めることができるのでそういった案件には アジャイル 開発が向いているでしょう。 アジャイル 開発のデメリット 全体のスケジュール・予算が見えずらい アジャイル 開発では開発初期に全体のかっちりした仕様を決めずに、仕様変更を許容しているため、全体像がぼやけています。 仕様変更・追加を繰り返していくと、当初計画から大きくスケジュールがずれてしまうこともあります。 この点については下記の対策をする必要があります。 ・仕様変更などを考慮し、バッファをもったスケジュールにしておく ・全体進捗を監視し最終的な納期に間に合うかどうかを常に判断する ・顧客とスケジュールのずれについて合意しておく 開発 工数 が大きくなったり、スケジュールが伸びてくると、予算・リソースについても同様のことが言えます。 全体が見えずらいため、ある時に予算オーバーとなってしまった。開発リソースが確保できなくということもあり得ます。 ・仕様変更・追加に伴い予算追加の議論ポイントについて顧客と合意する ・リソースが大きくなった時に、確保できるように関係各署と交渉しておく といった前準備が必要になるでしょう。 アジャイル 開発と ウォーターフォール 開発のメリット・デメリットを整理すると、以下の表のようになります。 ④ アジャイル 開発で気を付けるべきこと アジャイル 開発≠ドキュメントを作らない ウォーターフォール のように重厚なドキュメントを作るということではありませんが アジャイル 開発においても場合に応じて各種ドキュメントを作成し、要求者と認識が合っているかを確認することが必要です。 適時のコミュニケーションと確認 小さいサイクルだから作った後に見てもらえば大丈夫！！という考え方は間違っています。 小さいサイクルと言えども、何度も繰り返し修正が積み重なると、大きなリソースを失いますし、進捗せずにスケジュールが伸びてしまいます。 あれ？と迷った時や疑問に感じるならば、即時で各関係者へ確認することによって、修正の度合いを減らすことができます。 どちらのケースでも言えますが、仕様変更・追加があっても修正するから確認しなくても大丈夫。 ということではなく、あくまで修正は少ない方が良いという考え方をバランスよく持ち合わせる必要があります。 顧客にチーム参画してもらう 顧客が忙しくて見ることができません。最後にできたものを見ます。という状態に陥ると アジャイル 開発の意味をなさなくなります。 開発前にしっかりと顧客と事前合意して、チームの一員となってもらい、各 イテレーション ごとの成果物を見てもらいましょう。 ⑤ スクラム の取組事例 スクラム とは アジャイル 開発の手法を取り入れた フレームワーク の1つで最も有名な開発手法の１つになります。 弊社で実際に スクラム 開発手法を取り入れたチームの状況を説明させていただきます。 配配開発チームでの スクラム の取り組み 不確実性の低減 スクラム 導入前の開発チームはスケジュールの遅延が多発し、メンバーは 疲労 していたのですが スクラム 導入によって、チームで少しずつ解消していきました。 ただ、導入当初はタスクを順番通りに進めていくという ウォーターフォール 的な進め方で開発していたため、重要なタスクが後の方に残ったり、個人の遅れがそのままチームの進捗遅れに繋がってしまっていました。 これを打破するため 1週間毎のスプリント反復開発 と カンバン を導入しました。 カンバンによって終わらないタスクが可視化され、終わらないタスクは スウォーミング（問題のある所に人が集まり解決する） でチームで解決していきました。 1週間毎に計画・振り返りを行うことで、プロジェクトが進むごとに計画の不確実性が低減していくという良い循環になりつつあります。 改善文化の醸成 スプリント毎の振り返りで改善のア イデア を出し合うことを反復することでチームメンバーに改善の文化が醸成されていきました。 こういった意識が芽生えたことで 「顧客から始める」という アジャイル 原則 に回帰し チームの在り方、将来のロードマップを作るという、より本質的な改善を行うことができました。 詳細な記事は下記をご覧ください。 speakerdeck.com speakerdeck.com 楽楽明細開発チームの スクラム の取組 失敗から学びと スクラム と ウォーターフォール の融合 楽楽明細の開発チームでは2019年春～ スクラム の取り組みを始めました。 スクラム を取り入れたものの当初は大きな課題にぶつかってしまいました。 開発した成果物を営業・企画に見てもらうと 「思っていた機能と全然違う！！」 と言われてしまい 大きな仕様変更が発生 。 「多分こうだろう。違ってもスプリントごとに見てもらえるからまぁ大丈夫か。」といった過信が原因です。 そこで 「小さめの案件は今まで通りの アジャイル 開発」 「大きめの機能は ウォーターフォール と アジャイル の融合」 といったやり方に方針変更。 大きめの機能は要件定義の段階で前よりは詳細に設計を進めることにしました。 今では小さな手戻りはあるものの 大きな手戻りはなくなり効率よく開発 を進める事ができています。 ・ スクラム の取組で良かった点 昔は開発メンバーが増えてきたが 1人の熟練技術者に設計が依存していて ボトルネック になることが課題でした。 アジャイル 開発手法の導入で設計フェーズが軽量化されたことにより ボトルネック が分散され 全体の開発力・スピード が向上することができました。 また営業・企画がスプリントごとにフィードバックしてくれることで、営業・企画との連携・風通しが良くなってます。 詳細な記事は下記をご覧ください。 speakerdeck.com ⑥ アジャイル 開発の関連書籍の紹介 SCRUM BOOT CAMP THE BOOK スクラム のことを知るならまずこの本。 アジャイル の必読入門書。 www.shoeisha.co.jp アジャイル サムライ アジャイル とセットで語られる事が多い手法やプ ラク ティスが一通り網羅されており、 アジャイル のマインドや全体像を抑えることができる、 アジャイル の現場の教科書。 shop.ohmsha.co.jp みんなで アジャイル 手法が中心の書籍が多い中で、顧客からはじめるのが アジャイル であると言い切っている点で貴重な書籍。 www.oreilly.co.jp アジャイル レトロスペクティブズ アジャイル に挑戦するときに多くの人が最初に取り組み、馴染み深いが実は奥が深い「ふりかえり」にスポットを当てた、ふりかえりの教科書とも言うべき書籍。 shop.ohmsha.co.jp Fearless Change アジャイル に効く ア イデア を組織に広めるための48のパターン アジャイル に取り組む中で直面する様々な課題に向き合うためのマインドや行動様式を48のパターンを通して学ぶことができる。 www.maruzen-publishing.co.jp スクラム ガイド 言わずと知れた スクラム のルールブック。 スクラム 実践者の多くが経験を積めば積むほど結局ここに立ち戻るとも言われている。 https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf アジャイル マニフェスト アジャイル の原典にして原点。 agilemanifesto.org 今回ご紹介した アジャイル 開発のご紹介が、これから アジャイル 開発を導入を検討されている方々の一助となれば幸甚です。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに Webスクレイピングの基本事項 Webスクレイピング(Scraping)とは Webスクレイピングの活用シーン Webスクレイピングの基本的な仕組み Webスクレイピングの注意事項 取得先への攻撃とみなされたり、規約違反や、著作権法違反に問われることもある 取得先の変更に影響を受ける 取得先がAPIを公開しているならそちらを活用する方が良い Webスクレイピングの実践方法 Webスクレイピングを実践するには 1. ベンダーのサービスやツールを利用する 2. 自分でプログラムを作成する なぜPythonなのか？ Pythonでのスクレイピング実践方法 事前準備 BeautifulSoup4のインストール 模擬Webサイトの構築 Webサーバーを立ち上げる 初級編：特定の要素から単一の要素を抜き出す 中級編：あるページから繰り返しを伴う複数の要素を抜き出す 上級編：複数のページから複数の要素を抜き出し、CSVに出力する おわりに はじめに みなさんこんにちは。フジサワです。 みなさんも一度や二度は、インターネット上の情報を収集して分析するという作業を行ったことがあるのではないでしょうか。 調べる対象のWebサイトが数ページくらいであれば、ブラウザを開いてコピー＆ペーストを繰り返すだけでもなんとかなりますが、 対象が数十、数百ともなると、途端に人力で情報収集を行うことが難しくなります。 こうした時に用いられるのが「Web スクレイピング 」という手法です。 先日、とあるWebサイトから情報を集めて分析するという作業をやっていたのですが、チマチマ手作業でやろうとするも精神的に限界を迎えたので、Web スクレイピング してうまく情報を集められないかと考えました。 ところが、 簡単なWeb スクレイピング であれば、さほど技術的に難易度の高いものではないのですが、調べてみると、意外とWeb スクレイピング には法要件など、技術面以外で注意しなければならないポイントが多いようです。 そこで、本稿では「Web スクレイピング とは何なのか？」「Web スクレイピング で気を付けなければならないこと」などの基本事項と併せて、「 Python を用いてWeb スクレイピング を実践するにはどうすればよいのか」といったあたりを解説したいと思います。 特にエンジニア諸氏におかれては、「あまり意識せずにWeb スクレイピング していた」人も少なくないのではないでしょうか？ Web スクレイピング について初めて学ぶ方はもちろん、既に実践されている方も、本稿を読んで改めてWeb スクレイピング について整理して頂けると幸いです！ Web スクレイピング の基本事項 Web スクレイピング (Scraping)とは Web スクレイピング とは、Webサイトに含まれる情報から必要なものを抽出する技術・行為を指すものです。 ※なお、本稿では「Web」 スクレイピング と正確に記載するようにしていますが、単に「 スクレイピング 」と呼ぶ場合も、おおよそWeb スクレイピング を指していることが多いと思います。 Web スクレイピング と並んで、よく耳にする言葉に、Webクローリング（Crawling）というものがありますが、これは、あるURLを基に、そのWebページに含まれているリンクを辿りながら、情報を収集する仕組みを指します。 ちょっとややこしいですが、この両者の違いは「 クローラー が集めた情報を スクレイピング する」という文章にすれば、より分かりやすいのではないでしょうか。 Web スクレイピング の活用シーン Web スクレイピング の基本的な狙いは、膨大な情報の収集を手作業ではなく自動化することにより業務を効率化することです。 主な活用シーンとしては次のようなものが挙げられます。 マーケティング や研究分野におけるデータ分析 機械学習 におけるモデル作成のための学習データとして Web スクレイピング の基本的な仕組み Web スクレイピング の基本的な仕組みは次の通りです。 あるWebサイトからHTMLデータを取得する HTMLデータをタグ構造に従って分解・分析（パース）する 目的となる情報を選び出し、ファイルやDBに保存する 1.～3.のプロセスを、複数のページに対して繰り返して実行する Web スクレイピング の注意事項 Web スクレイピング はデータ収集を行う上でとても強力な手段ですが、注意しなければならない点がいくつかあります。 取得先への攻撃とみなされたり、 規約違反 や、 著作権法 違反に問われることもある 取得先への攻撃 Web スクレイピング はプログラムが自動で実行するという性質上、人間には不可能な大量のリク エス トをデータの取得先に送信することができてしまいます。 しかしながら、短時間に大量のリク エス トを送信することは、取得先のサーバーの処理を遅延させ、場合によってはサーバーをダウンさせるなどの損失を与えてしまいます。過去に、この件で逮捕されてしまった事例などもあるので、慎重に考える必要があるでしょう。 では、どれくらいの頻度であれば許容されるのかというと、残念ながら明確な基準はありません。 Webサイトの運営者が robots.txt を設置している場合は、クロールして良いURL／良くないURLや許容するアクセス頻度について明言されている場合がありますので、そちらも確認しましょう。 robots.txt …Webサイトの運営者が、 Google などの 検索エンジン の クローラー 向けに配置するファイル。通常は、対象 ドメイン のルートに配置されます。（例： https://xxxx.example.com/robots.txt ） 利用規約 違反 Webサイトによっては、明確に スクレイピング することを禁止しているものも存在します。 スクレイピング する際には、十分に取得先のWebサイトの 利用規約 を確認するようにしましょう。 著作権法 違反 Web スクレイピング の対象となる情報に 著作権 が生じている場合、活用方法を誤ると 著作権法 違反となりますので注意が必要です。 なお、 著作権法 では、第三十条の四にて「情報解析の用に供する場合」は 著作権 者の承諾なく利用することができるとされています。 活用事例として挙げた「マーケテイングや研究分野におけるデータ分析」や「 機械学習 におけるモデル作成のための学習データ」として スクレイピング した情報を活用することは問題ないと言われています。 ※筆者は法律の専門家ではないので、この点については改めて十分に確認されることをお薦めします 取得先の変更に影響を受ける スクレイピング の基本的な仕組みは、「HTML要素を特定のパターンに沿って抽出する」ことですので、データの取得先の仕様変更やデザイン変更によって、HTML構造が変わり、うまく抽出できなくなってしまうことがあります。 スクレイピング が上手く処理されない場合は、取得先のHTML構造に変化がないか確認し、調整をする必要があります。 そのほか、 スクレイピング が過度に相手先に負荷をかけていなかったとしても、相手先の通信拒否リストに載ってしまい、 スクレイピング ができなくなるような場合もあります。 取得先が API を公開しているならそちらを活用する方が良い ここまで述べたとおり、Web スクレイピング にはセンシティブな問題や面倒ごとがつきまといますので、データ取得先が API で必要な情報を公開している場合は、そちらを活用する方が安全だと思います。 本当にWeb スクレイピング する必要があるのかどうかをまず考えましょう。 もちろん、 API を利用する際にも、 利用規約 があればしっかり確認してくださいね。 Web スクレイピング の実践方法 Web スクレイピング を実践するには Web スクレイピング を実践するには、次のいずれかを選択することになります。 1. ベンダーのサービスやツールを利用する ベンダーが提供しているサービスはとても種類が多く、紹介しきれないので、ここでは簡単に導入できる Chrome 拡張をいくつか紹介します。 Instant Data Scraper 複数ページにまたがる一覧画面からの スクレイピング に特化した拡張で、起動すると自動で画面上の一覧要素を判定して抽出してくれます。あとは、次のページに進むボタンがどれかを指示するだけで、自動で スクレイピング してくれます。 Scraper とてもシンプルな スクレイピングツール 。ブラウザ上の右クリックメニューから実行できるなど、現在表示しているサイトの情報を簡易的に抽出したい場合には手軽に活用できます。 Web Scraper 複数ページに対するクローリングの設定や、動的ページへの対応など、使い方を覚えるのに少し時間が必要な半面、自由度が高く高機能な スクレイピングツール です。 2. 自分でプログラムを作成する Python や Java , PHP , Ruby といったプログラム言語を用いて、 スクレイパー を作成する方法です。 費用もかからず、自由度も高いため、簡単な スクレイピング 処理であれば、慣れているエンジニアにとってはベンダーのサービスやツールを使用するよりも手軽かもしれません。 仮に、ベンダーのサービスやツールを利用する場合であっても、内部で動作しているプログラムの基本的な考え方は同じですので、ツールの機能を理解するために、 スクレイパー の実装を把握しておくのも良いのではないでしょうか。 それでは、実際に Python でWeb スクレイピング をするプログラムを作成してみましょう。 なお、本稿では、 Python のバージョンはPython3系を用いて解説していますが、Python2系をお使いの方はご了承ください。 なぜ Python なのか？ Python 以外の言語でも同様のことは実現できるのですが、 Python の場合、Web スクレイピング を実現するために必要なライブラリや書籍などが豊富だからです。 Python での スクレイピング 実践方法 Python でWeb スクレイピング を実現する方法は様々です。 本稿では、比較的ベーシックな作り方である、 Python ライブラリの「 BeautifulSoup4 」を使用した実践例を解説します。 他の方法としては、「Scrapy」というWeb スクレイピング に特化した フレームワーク を用いる場合や、「 Selenium 」などの Webブラウザ を動作させて実行するライブラリを用いる場合、あるいは少しWeb スクレイピング の本流からは離れますが、「Pandas」を用いたデータ解析などが挙げられます。 事前準備 BeautifulSoup4のインストール HTMLの解析を行うライブラリに、もっとも定番のライブラリと言われている「BeautifulSoup4」を使って解説します。 「BeautifulSoup4」は次のようにインストールすることができます。 なお、今回のサンプルでは、対象のWebサイトにアクセスするためのライブラリとして、こちらも Python では定番となっている Requests を使用するので、併せてインストールしています。 ※ Python 実行環境の構築や、pip（ Python のライブラリ管理ツール）の導入については本稿では触れませんのでご了承ください。 $ pip install beautifulsoup4 requests 模擬Webサイトの構築 それでは、 スクレイパー を実装するにあたり、模擬的なデータ取得元のWebサイトを構築しましょう。 次のファイルを、 Python を実行する ディレクト リと同じ階層に配置してください。 index.html < html > < head >< meta charset = "utf-8" />< title > フルーツショップ </ title ></ head > < body > < h1 > 商品一覧 </ h1 > < ul class = "fruits_list" > < li >< a href = "http://localhost:8000/apple.html" > りんご </ a ></ li > < li >< a href = "http://localhost:8000/grape.html" class = "new_item" > ぶどう </ a >< span style = "color:red" > 新商品！ </ span ></ li > < li >< a href = "http://localhost:8000/banana.html" > バナナ </ a ></ li > </ ul > </ body > </ html > apple .html < html > < head >< meta charset = "utf-8" />< title > 商品 </ title ></ head > < body > < p id = "item_name" > りんご </ p > < p id = "item_price" > 100円 </ p > </ body > </ html > grape.html < html > < head >< meta charset = "utf-8" />< title > 商品 </ title ></ head > < body > < p id = "item_name" > ぶどう </ p > < p id = "item_price" > 200円 </ p > </ body > </ html > banana.html < html > < head >< meta charset = "utf-8" />< title > 商品 </ title ></ head > < body > < p id = "item_name" > バナナ </ p > < p id = "item_price" > 79800円 </ p > </ body > </ html > Webサーバーを立ち上げる 上記のファイルを配置した ディレクト リで、下記のコマンドを実行して、 Python のビルトインサーバー機能を使って、Webサーバーを立ち上げましょう。 $ python -m http.server 8000 ブラウザを起動し、 http://localhost:8000 にアクセスをして、次のような画面が表示されればOKです。 なお、次節以降でWeb スクレイピング を行う Python プログラムを実行しますが、上記コマンドを実行したターミナルとは別のターミナルを立ち上げて実行する形を想定しています。 初級編：特定の要素から単一の要素を抜き出す それでは、先ほど作成したフルーツショップサイトから、「新商品」マークがついている商品の名前を取得してみましょう。 以下の Python コードを scraping_beginner.py というファイル名で保存します。 Python コード例 import requests from bs4 import BeautifulSoup target_url = "http://localhost:8000/" r = requests.get(target_url) # target_urlにアクセスして、HTMLを取得 r.encoding = 'utf-8' # 文字化け対策のため明示的に文字コードを指定 bs = BeautifulSoup(r.text, 'html.parser' ) new_fruit = bs.find(class_= 'new_item' ) # HTML要素の中から目的の要素を探す print (new_fruit.text) 実行結果 $ python scraping_beginner.py ぶどう Python コード解説 bs = BeautifulSoup(r.text, 'html.parser') ここではHTML文字列を元にパースを実行し、 Python プログラムで扱いやすくするオブジェクトへの変換を行っています。 第一引数 r.text には、 target_url にアクセスした際のレスポンスのHTML文字列が格納されています。 今回は、実際にWebサイトにアクセスしていますが、次のような形で文字列を直接渡すことや、ファイルオブジェクトを渡すことも可能です。 開発中や デバッグ の際に活用すると便利ですね。 bs = BeautifulSoup('<b class="boldest">Extremely bold</b>', 'html.parser') 第二引数 html.parser は、HTMLの解析を行うライブラリに何を指定するかを記述します。 上記のものも含め、 Python の定番パーサーを列挙します。 ・ html.parser 　…　 Python の標準機能として備わっているパーサーで、手軽に利用できる半面、 Python で記述されているため処理速度が遅い。 ・ lxml … C言語 で記述された高速なパーサーがあり、大量のHTMLを処理するのであればこちらを利用することがお薦めだが、別途OSに lxml をインストールする必要がある。 ・ html5lib …　HTMLが正しく記述されていないなどの多少の問題があっても柔軟に解釈してくれる一方、処理速度がとても遅い。 Python 標準のライブラリではないので、別途pipでインストールが必要。 new_fruit = bs.find(class_='new_item') ここでは、パースされたHTML要素の中から、目的の要素を探す処理を行っています。 今回の例であれば、 class に new_item が指定されている要素のうち、最初に見つかったものを返す、という処理になります。 ※ちなみに、キーワードが class_ となっているのは、 class という文字列が Python の 予約語 だからです。 BeautifulSoupは、HTML要素にアクセスするために必要な機能を揃えています。 イメージを掴みやすくするため、いくつかの例を紹介しておきます。 ・IDが name である <a> 要素の href 属性の値を取得する bs.find('a', id= name ) ・ class に parent が指定されている <div> の子要素である <p> を取得する bs.select( div.parent > p ) 中級編：あるページから繰り返しを伴う複数の要素を抜き出す 次に、フルーツショップサイトから、商品の名前一覧と、商品の詳細ページへのリンクURLを全て取得してみましょう。 以下の Python コードを scraping_intermediate.py というファイル名で保存します。 Python コード例 import requests from bs4 import BeautifulSoup target_url = "http://localhost:8000/" r = requests.get(target_url) r.encoding = 'utf-8' bs = BeautifulSoup(r.text, 'html.parser' ) fruits = bs.find( 'ul' , class_= 'fruits_list' ).find_all( 'li' ) for fruit in fruits: fruit_name = fruit.a.text fruit_detail_url = fruit.a[ 'href' ] print (fruit_name) print (fruit_detail_url) 実行結果 $ python scraping_intermediate.py りんご http://localhost:8000/apple.html ぶどう http://localhost:8000/grape.html バナナ http://localhost:8000/banana.html Python コード解説 fruits = bs.find('ul', class_='fruits_list').find_all('li') ここでは、二段階で要素の検索を行っています。 一段階目の find では、 class に fruits_list を持つ <ul> 要素を探し、二段階目でその子要素の <li> を全て取得しています。 初級編で解説した通り、 find は最初に見つかった要素を１つ返すだけでしたが、 find_all は、見つかった要素を全て、配列で返却します。 for fruit in fruits: fruit_name = fruit.a.text fruit_detail_url = fruit.a['href'] find_all で取得した配列を走査し、それぞれのテキスト要素と、 href 属性要素を抜き出しています。 上級編：複数のページから複数の要素を抜き出し、 CSV に出力する ここまでは、ある単一のWebページから情報を抽出するだけでした。 最後に、極めて初歩的ではありますが、Web クローラー としての振る舞いをもったプログラムを作成します。 フルーツショップサイトのトップページに記載されている全商品の詳細ページに含まれている、商品の金額情報を集め、 CSV に出力してみましょう。 以下の Python コードを scraping_advanced.py というファイル名で保存します。 Python コード例 import csv import requests import time from bs4 import BeautifulSoup target_url = "http://localhost:8000/" r = requests.get(target_url) r.encoding = 'utf-8' bs = BeautifulSoup(r.text, 'html.parser' ) fruits = bs.find( 'ul' , class_= 'fruits_list' ).find_all( 'li' ) fruit_prices = [] for fruit in fruits: time.sleep( 5 ) # 一定時間待つ fruit_name = fruit.a.text fruit_detail_url = fruit.a[ 'href' ] r_detail = requests.get(fruit_detail_url) r_detail.encoding = 'utf-8' bs_detail = BeautifulSoup(r_detail.text, 'html.parser' ) fruit_price = bs_detail.find( 'p' , id = 'item_price' ).text fruit_prices.append([fruit_name, fruit_price]) with open ( 'fruit_prices.csv' , 'w' ) as csvfile: csvwriter = csv.writer(csvfile) for fruit_price in fruit_prices: csvwriter.writerow([fruit_price[ 0 ], fruit_price[ 1 ]]) 実行結果 $ python scraping_advanced.py では、出力された CSV を見てみましょう。 $ cat fruit_prices.csv りんご,100円 ぶどう,200円 バナナ,79800円 期待通り、それぞれのページを参照して、必要な情報を集めることができていますね。 Python コード解説 r = requests.get(target_url) … [A] : fruits = bs.find('ul', class_='fruits_list').find_all('li') … [B] : for fruit in fruits: : fruit_detail_url = fruit.a['href'] : r_detail = requests.get(fruit_detail_url) … [C] 上記の処理が、とても簡単な処理ですが、この一覧の動きがWeb クローラー としての振る舞いになります。 [A]でトップ画面にアクセスし、[B]で表示されている果物リストを取得し、[C]で、それぞれの詳細ページにアクセスをする、という流れになっています。 time.sleep(5) # 一定時間待つ 5秒間待ってから、次のページへのアクセスを行っています。 この処理はとても重要で、本稿で既に述べた通り、一定時間待つという処理を挟まない場合、データ取得先のサーバーに大きな負荷をかけてしまうことになるので、かならずスリープを挟むようにしましょう。 with open('fruit_prices.csv', 'w') as csvfile: csvwriter = csv.writer(csvfile) for fruit_price in fruit_prices: csvwriter.writerow([fruit_price[0], fruit_price[1]]) fruit_prices.csv というファイル名で、 スクレイピング した情報を CSV に出力しています。 今回の例では、 CSV に出力していますが、ここの処理をDBへの登録処理や、 Excel ファイルへの出力処理など、用途に応じて変更すると良いです。 とても簡単なサンプルでしたが、Web スクレイピング 、およびWeb クローラー の基本的な仕組みは以上です。 おわりに さて、いかがでしたでしょうか。 今回は、Web スクレイピング を活用する上での前提知識、注意事項をふまえつつ、 Python プログラムの実装例を紹介しました。 みなさんもぜひ、Web スクレイピング を活用して、業務の効率化をされてはいかがでしょうか。 くれぐれも、 ・データ取得先のサーバーへの過度な負荷をかけないこと ・ 利用規約 を守ること ・ 著作権法 を守ること について、ご注意くださいませ。 ではでは、みなさま良きWeb スクレイピング ライフを。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

はじめに 今回は10/28開催の ラク スMeetup 『 SaaS プロダクトのフロントエンド／Vue.js、React、TypeScript、E2Eテスト』 の様子をお届けします！ ラク スがこれまで開催してまいりましたイベントの中でも最多の申し込みをいただき、 ラク スエンジニア3名が日々のフロントエンド技術の取り組みを堂々と発表させていただきました。 はじめに イベントテーマ概要 発表の紹介 テスト稼働の削減とフロントエンドの品質担保を行うE2Eテスト Vue.js + TypeScriptによる新規サービス開発ふりかえり 息の長いサービスのフロントエンドを少しずつ改善していく営み おわりに イベントテーマ概要 今回のMeetupでは ラク スが展開する新旧3種類のサービスから、各サービスにおけるフロントエンドに関する取り組みを発信させていただきました。 10月にリリースしたばかりの 楽楽勤怠 、急速に利用者が拡大する チャットディーラー 、すでに数多くの利用者を抱える歴史ある 楽楽明細 より、それぞれ開発をリードするエンジニア達が登壇させていただきました。 それぞれの局面を迎える3サービスでフロントエンド技術をどのように活用しながらサービスを成長させているか、またモダンなフロントエンド技術をどのように大規模 SaaS に取り入れていくかをメインテーマとした登壇となりました。 発表の紹介 それではここから各発表内容と資料を共有させていただきます！ テスト稼働の削減とフロントエンドの品質担保を行うE2Eテスト まずはチャットディーラーのフロントエンド開発とバックエンド開発で横断的に活躍する川又が、フロントエンドの効率的な品質担保策として導入したE2Eテストを紹介させていただきました。 そのサービスの特性上、大前提となる自動応答処理（ユーザから質問に対し、想定した回答を返す）を担保するのが非常に重要なチャットディーラー。 かつては多大なる 工数 によってテストを行い、その品質を担保していました。 今回ご紹介しましたのはそんな状況を回避すべく、Puppeteerを中心としたE2Eテストです。 同じ悩みに直面している方には、川又の発表から解決のヒントを掴んでいただければと思います。 speakerdeck.com Vue.js + TypeScriptによる新規サービス開発ふりかえり 10月にリリースされたばかりの ラク ス最新のサービスである楽楽勤怠について、リリースに至るまでの約1年間の振り返りを共有させていただきました。 ラク ス初のフロントエンド・バックエンド分離の体制、またVue.jsとTypeScriptを中心としたモダンなフロントエンド技術での開発、この2つの側面から良かった点・苦しんだ点が詳細に紹介されています。 ラク ス初のフロントエンドエンジニアであり、フロントエンド組織の拡大にも従事する北嶋がこれらの学びを今後どう活かし、 ラク スのサービスの発展に挑戦していくか注目です。 speakerdeck.com 息の長いサービスのフロントエンドを少しずつ改善していく営み 最後に楽楽明細のリードエンジニアとして中心的に活躍する三田より、2010年リリースのサービスのフロントエンドを改善していく取り組みを紹介させていただきました。 リリースからこれまでの10年以上に、今後10年もより加速度的に利用者が拡大することを見込み、楽楽明細では現状の問題点を分析しながらフロントエンドの改善に取り組んでいます。 モダンな技術の導入には技術・組織・人などの課題をクリアしていく必要がありますが、ここまでの改善に至る地道な取り組みが紹介されています。 ご参加の方の中には、 ラク スが組織的に取り組む技術ロードマップについて関心を持っていただけた方もいらっしゃったようです。 ぜひとも多くのエンジニアの方のご参考としていただきたい内容です。 speakerdeck.com おわりに ラク スによるフロントエンドの取り組み、参考にしていただける知見はありましたでしょうか？ 多くの方に支持いただける大規模 SaaS が故の制約と闘いつつ、それでも技術の進化を止めない ラク スの戦略を感じ取っていただけたのではないかと思います。 今後も ラク スMeetupでは日々のエンジニアの取り組みを発信してまいりますので、次回もぜひご参加いただけますと幸いです。 そして直近ですが、フロントエンドがテーマのイベントが予定されています！ 前回の実施の際にも多くの方にご参加いただけ、盛況なイベントとなりました。 今回も面白く有益な場となりますので、是非ご参加いただけますと幸いです！ rakus.connpass.com

こんにちは。株式会社 ラク スで先行技術検証を行っている技術推進課のt_okkanです。 現在、フロントエンドの技術検証をしているのですが、手頃にバックエンドの API を構築したいと思い JSON Serverを利用しました。 同じようにバックエンドを手軽に構築する手段としては、FirebaseなどのBaaSを利用することがあげられますが、より手軽にローカルで構築できる手法を紹介しようと思います。 さらに今回はDockerでの JSON Serverの構築と、デフォルトの JSON Serverの機能を拡張し認証機能を追加する方法を紹介しようと思います。 JSON Server JSON Serverの実装 フォルダー構成 API仕様 data.json JSON Serverの実装 Docker環境 実行 まとめ JSON Server JSON Serverは、フロントエンド開発者向けプロトタイピング時のバックエンド API のモック作成ライブラリです。ローカルに用意した JSON ファイルをリソースとして API を構築することができ、その JSON ファイルの構成から自動的にURLが生成されます。 www.npmjs.com Expressベースでサーバーを構築しているので、Expressのモジュールを使用してカスタマイズを実装できます。 今回はその仕組みを利用して、認証機能付きの JSON Serverを構築します。 タイトルの 30秒で構築できる はコードがあれば、30秒で構築できるということです。 デフォルトの認証なしの機能なら、 Getting started 通りに構築するとコードレスで、30秒で REST API を構築できます。 公式ドキュメント でもアピールしています。 Get a full fake REST API with zero coding in less than 30 seconds (seriously) JSON Serverの実装 フォルダー構成 今回構築する API サーバーのフォルダー構成は以下のようになります。 ./server フォルダー内にDockerコンテナへ配置する、 JSON Server用のファイル群を配置します。 ./ |- server | |- data | | |- data.json | |- server.js | |- package.json |- docker-compose.yml |- Dockerfile server.js にはExpressのモジュールを利用してデフォルトの Json Serverをカスタマイズした機能を実装します。今回は認証処理を実装します。 data.json には API で管理するリソースデータを記述します。 API 仕様 今回構築する API サーバーの主な仕様です。このほかにも PUT や DELETE も使用できます。 今回はブログ記事の API を想定しています。ログイン・ブログ記事取得、の API にのみ認証なしアクセスでき、それ以外の API にアクセスするには認証が必要となります。 URL メソッド 機能 認証 http://localhost:33000/blogs GET ブログ一覧取得 なし http://localhost:33000/blogs POST ブログ記事追加 あり http://localhost:33000/blogs/:id GET ブログ取得 なし http://localhost:33000/users GET ユーザー一覧取得 あり http://localhost:33000/users/:id GET ユーザー一覧取得 あり http://localhost:33000/auth/login POST ログイン なし data. json data.json はデータベースのように、 API で扱うデータを保存します。今回は、ユーザー情報とブログ情報を保存するようにします。 { " blogs ": [ { " id ": 1 , " title ": " Java ", " body ": " Java Beans ", " post ": " 2020/10/01 ", " userid ": 1 } , { " id ": 2 , " title ": " Python ", " body ": " Python3.10 ", " post ": " 2020/10/04 ", " userid ": 1 } , { " id ": 3 , " title ": " JavaScript ", " body ": " Vue.js ", " post ": " 2020/10/10 ", " userid ": 2 } ] , " users ": [ { " id ": 1 , " name ": " user one ", " email ": " one@example.com ", " password ": " userone " } , { " id ": 2 , " name ": " user two ", " email ": " two@example.com ", " password ": " usertwo " } ] } JSON Serverの実装 ではプログラムを実装し、 JSON Serverを拡張し認証付き REST API サーバーを構築していきます。 まずはNode.jsのプロジェクトの package.json を以下のように設定します。 { " name ": " json-server-docker ", " version ": " 1.0.0 ", " description ": " Json Server on Docker ", " author ": " XXXX@example.com ", " main ": " server.js ", " scripts ": { " start ": " node server.js " } , " dependencies ": { " body-parser ": " ^1.19.0 ", " helmet ": " ^4.1.1 ", " json-server ": " ^0.16.1 ", " jsonwebtoken ": " ^8.5.1 " } } main , scripts , dependencies 以外は好みの値に設定してください。 今回は認証にJWTでの トーク ン認証を使用するので、 jsonwebtoken を依存関係に追加します。 では次に、サーバー本体となる server.js を以下のように実装します const jsonServer = require( "json-server" ); const fs = require( "fs" ); const bodyParser = require( "body-parser" ); const jwt = require( "jsonwebtoken" ); const helmet = require( "helmet" ); // JSON Serverで使用するJSONファイルを設定 const server = jsonServer.create(); const router = jsonServer.router( "./data/data.json" ); // JSON形式のリクエスト対応 server.use(bodyParser.urlencoded( { extended: true } )); server.use(bodyParser.json()); // 署名 const JWT_SECRET = "jwt_json_server" ; // 有効時間 const EXPIRATION = "1h" ; // データーベースの作成 const db = JSON.parse(fs.readFileSync( "./data/data.json" , "UTF-8" )); // ①ログイン用のルート server.post( "/auth/login" , (req, resp) => { const { email, password } = req.body; // ログイン検証 if ( db.users.findIndex( (user) => user.email === email && user.password === password ) === -1 ) { resp. status (401).json( "Unauthorized" ); return ; } // ログイン後、アクセストークンの生成 const access_token = jwt.sign( { email, password } , JWT_SECRET, { expiresIn: EXPIRATION, } ); resp. status (200).json( { access_token } ); } ); // ②ログイン認証が必要ないルート // 記事一覧を取得 server.get( "/blogs" , (req, resp) => { const blogs = db.blogs; resp. status (200).json( { blogs } ); } ); // 記事IDから記事を取得 server.get( "/blog/:id" , (req, resp) => { const id = req.params.id; const blog = db.blogs.find((blog) => blog.id === Number (id)); resp. status (200).json( { blog } ); } ); //③ 認証が必要なルート server.use((req, resp, next) => { // 認証形式チェック if ( req.headers.authorization === undefined || req.headers.authorization.split( " " ) [ 0 ] !== "Bearer" ) { // 認証形式が異なる場合 resp. status (401).json( "Unauthorized" ); return ; } // 認証チェック try { var decode = jwt.verify( req.headers.authorization.split( " " ) [ 1 ] , JWT_SECRET ); // 認証に成功した場合は、next関数を実行しJSON Serverの機能を利用する next(); } catch (e) { // 認証に失敗した場合 resp. status (401).json( "Unauthorized" ); } } ); // JSON Serverを起動する server.use(router); server.use(helmet); server.listen(33000, () => { console.log( "JSON Server Start" ); } ); JsonServer Access Control を参考に実装しました。 実装した ルーター としては、 ログイン用（ /auth/login ） 認証なしで公開（ /blogs 、 /blogs/:id ） 上記以外で認証が必要 の3種類を実装しています。 jsonwebtoken や、 body-parser の使い方はこちらを参考にしています。 jsonwebtoken - npm body-parser - npm Docker環境 Dockerを用いて JSON Serverを構築します。 Dockerfile と docker-compose.yml は以下のようにしました。 Dockerfile FROM node:latest RUN yarn add global json-server docker-compose.yml version: "3" services: json-server: build: context: . dockerfile: Dockerfile volumes: - ./server:/data/server:delegated tty: true working_dir: /data/server command: sh -c "yarn install && yarn start" container_name: jsonserver-docker ports: - "33000:33000" 実行 では最後にDockerコンテナ上で実行しましょう。 $ docker-compose build $ docker-compose up -d 起動後に curl で http://localhost:33000/users にアクセスしてください。認証をしていないので、 Unauthorized が返ってきます。 $ curl http://localhost:33000/users "Unauthorized" /auth/login でログインしてから、レスポンスのアクセス トーク ンをヘッダーに付与して同じURLにアクセスしてみます。 $ curl -X POST -H "Content-Type: application/json" -d '{"email": "one@example.com", "passowrd": "userone"}' http://localhost:33000/auth/login { "access_token": "アクセストークン" } $ curl -H "Content-Type:application/json" -H "Authorization:Bearer アクセストークン" http://localhost:33000/users [ { "id": 1, "name": "user one", "email": "one@example.com", "password": "userone" }, { "id": 2, "name": "user two", "email": "two@example.com", "password": "usertwo" } ] レスポンスから分かるように、ユーザー一覧を取得できます。 /blogs のGETメソッドとPOSTメソッドでも試してみてください。 まとめ JSON Serverを利用して認証機能付きのモック REST API を構築しました。 一度作成してしまえば、Dockerを起動するだけでいつでも30秒でバックエンドの API を構築できます。 日々の勉強や、ちょっとした検証などに利用してみてください。 GitHub にもコードを上げています。参考にしてみてください。 https://github.com/txkxyx/jsonserver-docker github.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、itoken1013です！ 定期的に発信しています入門シリーズ、今回のテーマは Emacs の使い方 です！ 昔から多くの人から熱い支持があるエディタである Emacs ですが、使い方をマスターするととても便利に素早くコーディングが可能となります。 今回の記事を読んでいただき、ぜひ使い方を身につけていただければと思います！ はじめに インストール手順（Windows） インストーラを入手する インストールを実施する インストール手順（Mac） 前提知識 コマンドの表記 C-x M-x Return バッファ ウィンドウ ミニバッファ 基本的なコマンド Emacsを起動する ファイルを新規作成する 移動する（上下左右） 文字を削除する Undo（変更の取り消し） ファイルを保存する ファイルを閉じる ファイルを開く 上書き保存 Emacsを終了する 困った時の中断コマンド その他のコマンド一覧 終わりに インストール手順（ Windows ） 使い方の前に、まずはWindow向けの Emacs のインストール手順からです。 Catalina以前の Mac もしくは Linux を利用の方は Emacs はインストール済ですので、デフォルトの状態で Emacs を利用可能です。 このインストール手順をスキップし、次項の『前提知識』へ進んでください。 インストーラ を入手する まずは Emacs の インストーラ のダウンロードからです。 今回は使い方の説明を優先するため、 Windows の スタンドアロン 版 Emacs をご案内します。 以下の公式ページにアクセスし、 Windows 項配下の nearby GNU mirror をクリックしてください。 バージョン別の Emacs が表示されます。 www.gnu.org 今回は執筆時点の最新版である「 emacs -27/」を選択します。 次に インストーラ は「 emacs -27.1- x86 _64.zip」を選択します。 ダウンロードが完了しましたら、 Windows の任意のツールを使って zipファイルを解凍します。 特にこだわりがなければ、 Windows でよく使われる Lhaplus や 7-Zip などでよいでしょう。 インストールを実施する 次にインストールを実施します。 解凍したフォルダにアクセスし、binフォルダ配下の runemacs.exe を起動してください。 起動後、こちらのウィンドウが立ち上がれば、インストール完了です！ これで無事に Emacs が起動し、 Windows でも使い方を学ぶ準備ができました。 インストール手順（ Mac ） Catalina（ macOS 10.15）から Emacs は Mac に同梱されなくなりました。 このため、利用にはアプリケーションのダウンロードが必要になります。 詳細はこちらをご確認いただき、セットアップをお願いします。 applech2.com 前提知識 それではさっそく使い方を説明していきたいのですが、まずは前提知識と用語を説明させてください。 Emacs は他のツールとコマンドの表記が異なる点もあり、前提知識を踏まえた方がスムーズに使い方を理解できるはずです。 コマンドの表記 公式ページや各種リファレンスのコマンドは、 Emacs に初めて触れる方には見慣れない表記となります。 本記事も表記内容を揃えて掲載しますので、以下の点は使い方を読む前に理解してください。 C-x 『Ctrl を 押しつつ 、x（任意のキー）を押す』 を指します。 C-f であれば『Ctrl を押しつつ f を押す』、C-g であれば『Ctrl を押しつつ g を押す』となります。 （ Windows だとCtrl、 Mac ではcontrolに読み替えてください） 最初は表記内容と使い方と結びつけるのが大変ですが、何度か練習すると慣れてきます。 M-x C-x と混同しがちですが、こちらは 『ESCを 押した後 、x を押す』 または 『Altを 押しつつ 、xを押す』 を指します。 MではなくESCもしくはAlt、またESCだとC-xと違って「押した後」である点に注意してください。 （ちなみにMとは現行のキーボードに存在しない「Metaキー」に由来しており、ESCキーがMetaキーの代替を担っています） Return Mac には存在しますが、 Windows ではEnterキーを指します。 バッファ Emacs 上でファイルを開いている領域を 「バッファ」 と呼びます。 このバッファと呼ばれる領域上にファイルを読み込み、 Emacs 上で編集した内容をファイルに書き込む流れでファイルを更新していきます。 Emacs では同時に複数のバッファを開くことができ、表示するバッファを切り替える操作ができます。 ウィンドウ ファイルを開いた際に、テキスト内容が表示される Emacs の領域を指します。 ミニバッファ Emacs を起動した際、コマンド入力やメッセージが表示される領域を指しています。 上述のバッファと混同しないよう、ご注意ください。 基本的なコマンド それでは一般的な テキストエディタ として必要な Emacs の使い方を説明していきます。 最低限必要なコマンドと使い方を以下に示しますが、説明を読むだけでなく、 Emacs を立ち上げて一緒に操作してみると使い方を早く身につけられるはずです！ No コマンド名 用途 1 emacs Emacs を起動する 2 C-x → C-f ファイルを新規作成する 3 C-f 右に移動する 4 C-n 下に移動する 5 C-b 左に移動する 6 C-p 上に移動する 7 C-d 文字を削除する 8 C-x → u 変更の取り消し 9 C-x → k ファイルを閉じる 10 C-x → C-f ファイルを開くする 11 C-x → C-s 上書き保存する 12 C-x → C-c Emacs を終了する 13 C-g コマンドを中断する Emacs を起動する Windows の場合、インストール時に指定した runemacs.exe をダブルクリックすることで起動完了です。 Mac の場合、ターミナル上で 「 emacs 」 を入力してください。 ファイルを新規作成する まずは練習用に編集するファイルを作成してみましょう。 Emacs 上で 『C-x』の後に『C-f』 を入力してください。 最下段（「ミニバッファ」と呼びます）に現在の ディレクト リが表示されますので、今回は「 emacs .txt」というファイル名を入力してみます。 ファイル名を入力後、バッファ上に「 emacs .txt」というファイルが作成されます。 移動する（上下左右） まずは通常のテキスト入力の要領で、以下の3行を入力してみましょう。 初心者でも分かる Emacsの使い方 Windowsのインストール手順・コマンド一覧付き 次にファイル内のカーソル移動です。 Emacs では矢印キーでもカーソル移動が可能ですが、 ホームポジション から手を離すこととなるため、編集時にタイムロスが発生がちです。 対して以下のキーを使うことにより、 ホームポジション にステイしたままで素早くカーソル移動ができます。 それぞれ試してみてください。 右／C-f 　※f はForward 下／C-n　※n はNext line 左／C-b　※b はBackward 上／C-p　※p はPrevious line 文字を削除する 文字の削除も通常の テキストエディタ 同様、BackspaceとDeleteキーで可能です。 ただ矢印キー同様、 ホームポジション から離れずに実現するには 『C-d』 を使うことで現在カーソルがある文字を削除することが可能です。 試しに最後の行を削除してみましょう。 Undo（変更の取り消し） 先ほど削除した行を復活させるためには、 『C-x』の後に『u』 を打つことで直前の変更を取り消すことができます。 ファイルを保存する それではこのファイルを保存してみましょう。 ファイルの保存には 『C-x』の後に『C-s』 を打ちます。 これでバッファの内容が新たに作成されたファイルに記録され、 エクスプローラ からもファイルが確認できるはずです。 ファイルを閉じる 正確にはバッファーを閉じることを意味しますが、編集中のファイルを閉じてみましょう。 『C-x』の後に『k』 を打つと、ミニバッファ上に『Kill buffer（default emacs .txt）』と表示されますので、「 emacs .txt」を入力の上、Enterを押下してください。 これでバッファーを閉じることができます。 この際、未保存の場合には追加で yes か no の選択を求められますので入力の上、Enterを押下してください。 この後、 Emacs を起動した際の画面に戻れば、保存完了です。 ファイルを開く ただいま閉じたファイルをもう一度開いてみましょう。 『C-x』の後に『C-f』 でファイル検索ができますので、「 emacs .txt」を指定してください。 上書き保存 「 emacs .txt」が無事に開けましたら、今度はファイルを編集し、上書き保存してみましょう。 末尾を改行して「編集しました」と加えた後、 『C-x』の後に『C-s』 で上書き保存を実施します。 ミニバッファ上に「Wrote ・・・・ / emacs .txt 」と表示されれば、上書き保存が完了しています。 Emacs を終了する 最後に Emacs を終了するコマンド 『C-x』の後に『C-c』 です。 ファイル編集後に保存していない場合にはミニバッファ上にメッセージが表示されますので、必要なキーを入力してください。 入力後、 Emacs のウィンドウがクローズされれば完了です。 困った時の中断コマンド ハンズオン形式で Emacs のコマンドを説明してきましたが、いかがでしたでしょうか？ 途中でコマンドを打ち間違えたり、謎の文字列が表示されたりして戸惑う方もいたかと思います。 そんな時のお助けコマンドとして、 『C-g』 で実行中のコマンドを中断することができます。 コマンド入力後、ミニバッファには「Quit」が表示されます。 より上級的な使い方でもこの中断コマンドは使えますので、身につけていただければと思います。 その他のコマンド一覧 ここまで簡単なテキスト編集に必要な Emacs の操作を説明してきました。 より応用的なコマンドと使い方は以下にまとめてありますので、こちらも実際に Emacs を触りながら手に覚えさせていただければと思います。 No コマンド名 用途 1 C-スペース 範囲選択 2 M-w コピー 3 C-w カット 4 C-y ペースト 5 C-a 行頭に移動する 6 C-e 行末に移動する 7 M-< 先頭に移動する 8 M-> 末尾に移動する 9 C-p 1行上を移動する 10 C-n 1行下を移動する 11 C-s 文字列の検索 12 M-% 文字列の置換 終わりに 超入門ということで最低限なコマンドの使い方を紹介しましたが、利用イメージを持ってもらえましたでしょうか？ Emacs を使い方を身につけることで開発効率を爆速化することができます。 Windows は最初のインストールだけが少し手間ですが、インストールの手間を大きく上回るリターンが得られることでしょう。 また今回は触れませんでしたが、 Emacs ではブラウザなどの各アプリケーションを操作するなどの使い方も可能です。 ぜひ使い方を体に馴染ませて、 Emacs をマスターしていってください！ それでは～！ 今回引用させていただきました記事はこちらです。 applech2.com エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは。 sts -250rrです。 いきなりですが、皆さま開発において フレームワーク は使われていますでしょうか？ 世の中のサービスはもちろん、 ラク スのシステムにおいても様々な フレームワーク が使われているわけですが、 フレームワーク 自体も時代の流れに沿って、新しいものが出てきています。 新規サービスは新しい技術を、既存のサービスは新しい技術に置き換えていくなど日々試行錯誤をしている方もおられるかと思います。 今回はそんな Java フレームワーク を7つご紹介したいと思います。 他にも魅力的なものがあるとは思いますがご了承ください。 私が使用したことのあるものについてはちょっとした感想なども添えていますのでご参考程度に読んでいただければ幸いです。 はじめに フレームワークの良さって？ メリット デメリット Javaフレームワーク Spring Framework DI（Dependency Injection：依存性の注入） AOP（Aspect Orientation Programming：アスペクト指向プログラミング） Play Framework Spark Framework Apache Struts Seasar2 Java EE（Java Platform, Enterprise Edition） JSF（JavaServer Faces） まとめ フレームワーク の良さって？ メリット サービスを開発する上で、チームや複数メンバーで開発することは避けて通ることはできないプロセスです。 しかし、スキルやバックボーンが異なるそれぞれのメンバー間でプログラムの書き方がバラバラになってしまうと、統一感が崩れてしまうことによる可読性の低さや、改修コストが上がってしまう恐れが出てきます。 フレームワーク を利用することでチーム内で共通の規則に沿った書き方に統一することができ、これらの問題を解決することが可能です。 また、 フレームワーク 側が用意している機能を用いることで、セキュリティや認証の機能を低コストで実装することができる場合もあり、開発速度を上げることにも繋がります。 デメリット 基本的な Java の知識に加えて、 フレームワーク 特有の機能やその書き方を理解する必要があるため、それに伴い学習コストは上がってしまうことは避けられません。 他の フレームワーク で開発されていた方や若いエンジニアの方は苦労するポイントになってくるかと思います。 特に新卒エンジニアは フレームワーク の知識が先についてしまい、 Java の基本がわからなくなってしまう。いざプレーンな Java のプログラムを書こうとすると手が止まってしまうなんていう落とし穴もあるのではないでしょうか。（これは結構に身に覚えがあります。） Java フレームワーク フレームワーク についてメリット・デメリットをお伝えしましたが、本項では Java 開発における有名どころの フレームワーク をご紹介します。 2020年現在のトレンドや過去に活躍した フレームワーク を選抜してみましたのでお楽しみください。 Spring Framework Webアプリケーションやモバイルアプリをはじめとした様々な開発に適している フレームワーク で、 ラク スでも利用実績があります。 2020年現在「 Java といえばSpring」のようなイメージを持っている方もいるほど、スタンダードになりつつある フレームワーク なのではないでしょうか。 私も最近になってこの フレームワーク で開発を行う機会が増えてきました。 Spring Framework の特徴は DI（ Dependency Injection：依存性の注入） と AOP （ Aspect Orientation Programming： アスペクト指向 プログラミング） の概念を取り入れることで機能開発や改修が楽にできる点が挙げられます。 簡単ですがDI・ AOP のメリットは以下のようなものがあげられます。 DI（ Dependency Injection：依存性の注入） クラス間の依存関係を解消し、 疎結合 にすることで保守性を高めることが可能。 依存関係のある他のクラスが完成していなかったとしても、Mockに置き換えてやることで、テストを実行することが可能。 AOP （ Aspect Orientation Programming： アスペクト指向 プログラミング） ログの出力や認証など、共通で行うような処理を1つの機能として抜き出し、プログラム内のいろいろな場所で横断的( Aspect )に利用することが可能 共通の処理が抜き出されているため、業務ロジックに集中した開発が可能。 また、 Spring Framework には多くのプロジェクトが存在するため、作成するシステムによって必要なプロジェクトを使い分けることで様々なアプリケーションの開発に適することができていると言えます。 ただし、多くのプロジェクトが存在する反面、多くのことができてしまうため、必要な要素を適切に利用することが大切です。 また、 フレームワーク が担える範囲が広い（≒隠ぺいできる範囲が広い）ため、開発に慣れていない方にとってはどこで何をしているかわからない。といったことが起こりがちなように思います。 spring.io Play Framework Play Framework（プレイ・ フレームワーク ）は、 Scala と Java 言語で書かれた フレームワーク で、生産性を重視した フレームワーク になっています。 既存の Java のWebアプリケーションの開発手法では、 JSP や サーブレット をコツコツと書いて、コードを修正したら コンパイル して、ビルドして、初めて編集した内容が確認できる。といった状況であったため、コーディング以外にとられる時間もあり、しんどさを感じている方が少なくなかったようです。 そういった状況の中で、 Ruby の「 Ruby on Rails 」や Python の「 Django 」のような開発を、 Java でもやりたいというニーズで生まれた背景を持つようです。 そのため、Play Frameworkは「 Ruby on Rails 」、「 Django 」の影響を強く受けているといわれています。 Play Frameworkの特徴は コンパイル が早く、コードの追加・修正がすぐに反映され確認できる 点と、使用するCPUリソースやメモリ使用量が少ないため、 システムが大規模なものになったとしても動作するシステムを作ることができる 点です。 Java の弱点であった コンパイル に時間がかかるという欠点をなくし、メリットである堅牢性や高速な動作を活かすことができるようになっています。 また、 MVC （Model-View-Controller） アーキテクチャ を使用しているため、開発者にとって理解しやすく高速なアプリケーション開発に適しているとされています。 もともと Java で開発をしていなかった方にとって、他の開発言語の流れを汲んでいるPlay Frameworkは馴染みやすいのではないでしょうか。 Spark Framework Spark Frameworkは、シンプルな構成でできていいる軽量な フレームワーク で、軽量であるためにマイクロ フレームワーク とも呼ばれています。 ここまでで紹介してきた Spring Framework やPlay Frameworkは複雑で大きなシステムを開発する際にも活躍しますが、シンプルで小さなシステムを作る際にはあまりに機能が豊富で大げさになってしまうため、よりシンプルな フレームワーク として生まれました。 Ruby の「 Sinatora 」という フレームワーク に影響を受けており、多くの アノテーション の記述や設定ファイルを必要としないため、開発する際の負担を軽減してくれます。 これらの特徴に加え、Lambda式とstaticメソッドを活用することで手軽に実装することが出来るということが挙げられています。 Apache Struts 2013年にEOLを迎えた フレームワーク ではありますが、 Spring Framework が出てくるまでは「 Apache Struts が Java の主流 フレームワーク 」と言われていました。世の中で動いているシステムで Apache Struts を採用しているプロジェクトも少なくないと思われますのでご紹介します。 ※2007年に新しく Struts2 という フレームワーク が誕生していますが、今回はStruts1についてです。 Apache Struts の特徴は MVC （Model-View-Controller）の アーキテクチャ に基づいた、 Java サーブレット や JSP （ JavaServer Pages ）の仕組みを組合せてWebアプリケーションを作成することができる フレームワーク です。 XML ベースの設定ファイルを記述することで、ユーザのリク エス ト（URL）を適切な Java クラスに割り振るような動きや、JavaBeanに値を自動設定できるようにするなど、 Java プログラムのコーディング削減ができるような仕組みがそろっています。 ただし、 XML の設定ファイルが便利である反面、様々な設定ファイルを書かなければならないというデメリットとして挙げられることもあります。 Seasar2 2016年にEOLとなっている フレームワーク ですが、日本国産の フレームワーク ということでご紹介します。 前述した Apache Struts では設定ファイルの記述が多くなることがデメリットとして挙げられるとお伝えしました。 また、修正したプログラムの動作を確認するためにデプロイをしなければならないという点で開発速度を上げていきたいエンジニア的には煩わしい部分になっていました。 Seasar2 はそういった部分を解消するため、設定ファイルの記述を 命名規則 や アノテーション でカバーすることで設定ファイルを少なくし、 ホットデプロイ の機能を取り入れることで修正のたびにデプロイの作業をせずに開発を進めることが可能です。 ただし、個人的には 命名規則 などを誤ると途端に動かなくなってしまうため、 フレームワーク 特有のルールを理解する必要がある点はちょっとした学習コストがかかるなと感じる部分だと思っています。 ちなみに、Springの項でご紹介したDIや AOP は SAStruts でも利用することができ、個人的に Seasar2 からSpringへの学習は割とスッと入ってくる印象を受けました。 Java EE（Java Platform, Enterprise Edition） Java EE は、エンタプライズ（企業）向けのシステム構築するために作られた Java 標準仕様の フレームワーク です。 Java SEにサーバー関係のライブラリなどを追加することで、Webアプリケーション開発ができるようになっています。 Servlet ・ JSP 、 EJB に加え Java の各種 API など、大規模システムの構築に必要な機能がまとめて提供されています。 JSF（JavaServer Faces） JSF は Java EE の中のサブシステムですが、 フレームワーク としての役割を持っています。 Apache Struts と同じく MVC を利用していますが、 XML 方式のHTMLを利用した、 コンポーネント ベース フレームワーク であるため、 Apache Struts とはまた異なります。 JSF は専用のタグライブラリを使ってWeb画面の構築を行う「フェースレット」とフェースレットと関連づけた処理をおこなったり、値設定をしたりする Java のクラス「マネージド ビーン 」で構成されています。 まとめ 今回 Java フレームワーク についてまとめてみましたが、いかがだったでしょうか？ 改めて見比べてみてもどの フレームワーク にも特徴があり、すべてにおいて最も優れているというものはなかったように感じます。 当たり前のことではありますが、「目的（作りたいシステムや、開発手法）に合わせて、最適な フレームワーク を選択する」ことが開発を『楽』にする第一歩であると思います。 私事かつ話がそれますが、私が関わっているプロジェクトで徐々にSA Struts からSpringに乗り換えようとする動きがあり、 Struts とSpring共存した状態で動作させるということを行ってます。 ただし、これもそう簡単なことではなく、既存の Struts の機能に引っ張られてSpringの機能が上手く使えない、ということも発生しておりこれを解決しようと思うと新旧両者の知識を求められるためなかなかに苦労しています。 皆様の フレームワーク 選択の足掛かりになれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

技術広報の syoneshin です。 リモートワークの普及とともに帳票管理や押印を SaaS で代替する動きが注目され、システム化に必要な棚卸しに フローチャート (フロー図)を使う機会が増えていると聞きます。 10年以上前、今でいうPMOとして内部統制や業務改善に関わる多くの フローチャート (フロー図)を書いた経験から、今回は当時の上司やコンサルのプロたちのもとで学んだ フローチャート (フロー図)の書き方についてご紹介します。 ※本記事は初級者向けに フローチャート (フロー図)の書き方をまとめた内容になります。 フローチャート(フロー図)とは？ フローチャート(フロー図)の書き方 よく使う記号 プログラミングフローチャート(フロー図) の書き方 フローチャート作成ツール まとめ 　 もし、当社の雰囲気・技術内容等にご興味を持たれましたら以下サイトの募集職種をお気軽にご確認ください！ フローチャート (フロー図)とは？ フローチャート とは、業務やシステムにおける工程やプロセスの各ステップや アルゴリズム などの流れを、長方形・ひし形・楕円形などの記号で表示し、流れの方向を矢印でつなげて視覚的に表した図の事です。 フローチャート には管理観点で主に以下4つの種類があり 文書 フローチャート ：複数の部門に閲覧してもらうための文書の流れを記した図 データ フローチャート ：システムのデータの送信経路を記したり管理したりするための図 システム フローチャート ：プログラム、サーバー、ネットワークなどシステムの物理的な構成要素をデータがどのように経由するかを記した図 プログラム フローチャート ：システムのプログラム処理や管理形態を記した図 また、一般的な業務フローなどで使われる ワーク フローチャート ：業務処理、文書・データ情報の流れなどを含むオフィス業務に関わる仕事の流れを記した図 などがあります。 フローチャート を使い、業務・作業プロセスを可視化することで、第 三者 への情報伝達や説明、認識の統一が簡単になり、不要・不足の業務をみつけたり、引継ぎを早めたりなど業務の効率化と品質の維持向上に役立ちます。 フローチャート (フロー図)の書き方 では フローチャート の書き方について説明します。 フローチャート は仕事の流れや構造を整理・可視化し、関係者の間で仕事の流れや構造を理解・共有できるようにすることを目的にしています。そのため フローチャート の書き方の基本は、「誰が・何が」「いつ、何をきっかけに・どういう場合に」「どんな作業・処理を」行っているかを、シンプルに分かり易くに書き表わすことが求められ、作成目的をしっかりと理解し、対象範囲を決めて書くことが必要になります。 以下4点は フローチャート の書き方で気を付けるべきポイントです。 フローは流れを上から下へ、左から右へ流れるよう要素を配置すること 各ステップには図記号が持つ基本的な意味を理解して配置すること 図記号と図記号の間隔は開けて重ならないようにすること 時系列が分かるよう並列に書かずテキストは簡潔に分かり易くすること また、 フローチャート を書く際、ページを分割したりまたがると、流れや構造を追いにくくなる傾向があるため、基本的には1ページにまとめて書くことに努めましょう。 以上が基本的な フローチャート の書き方になります。 よく使う記号 それでは次に フローチャート でよく使う記号と意味を見て行きます。 フローチャート の書き方をマスターするためには、各図記号の意味と用途を理解することが必要です。 各記号の意味・用途・事例を見て フローチャート の書き方の参考にしてください。 端子・開始/終了 業務プロセスやプログラムの開始/終了やスタート/ゴールを表す記号。角の丸い四角形で一般的に”端子”と呼ばれフローの始まりと終わりに配置する必要がある。また業務のトリガーとなるきっかけを表すこともある。 処理 フローチャート の１つのステップ・作業・処理を表す記号。四角形で"処理"とよばれ、一般的な処理、作業、手続きを表す際に配置。基本的には１ボックスにつき、1つの処理内容を記載。※複数の処理を記載すると、わかりづらくなるため注意。 判断・条件分岐 「真/偽」もしくは「Yes/No」が答えとなる判断や、複数の選択肢に分かれる判断を表す記号。ひし形の図形で”判断”もしくは”条件分岐”と呼ばれ、2つ以上の判断処理を表す際に配置。1つの図形各頂点から「Yes」or「No」/「真」or「偽」もしくは複数の判断に対応する線や矢印を次のステップ(図形)に向けて書く。 ループ開始/終了 何度も繰り返しで行う処理を表す記号。台形のような六角形の図形で、繰り返し条件と繰り返し終了条件を表す際に配置。ボックスの中に繰り返し名と条件を記入し、間に処理を挟む。 システム・データベース・磁気ディスク 業務システムやデータベースへの入出力や保管を表す記号。円柱の図形で、”システム”もしくは”データベース”、エクセルの フローチャート では”磁気ディスク”と呼ばれ、システムやデータベースへのデータの入出力や保管を表す際に配置。使用システムが複数ある場合、システム名称も記載することが多い。 データ・入出力 媒体を指定しないデータやファイルなどの参照や書込み、入出力を行う機能を表す記号。平行四辺形の図形で”データ”もしくは”入出力”、”I/O”とも呼ばれ、主にデータベースとファイルを分けて図示したい際に配置。 書類 ・ドキュメント 受発注書・請求書・伝票などの書類や帳票を表す記号。一般的には”書類”と呼び、処理に応じて発生する際は処理の記号と重ねて記載し、2つ以上の書類・ドキュメントが1つの段階に含まれている場合は”複数書類”の記号を使うことになる。 定義済み処理・サブルーチン 処理の一部を別 フローチャート と分けて作成する場合や、使用頻度や認知が高い場合に配置する記号。 フローチャート を1枚にまとめる際に長くなるケースは，この記号で一部フローを分けて記載することが多い。 結合子 フローチャート が長くなったり、複雑になったりした際に同じ フローチャート 内で別の処理に飛ばす場合に配置する記号。結合子の中に参照先を記載することが多い。 外部結合子 こちらも フローチャート が長くなり、後工程を別ページにまたいで記載する必要がある場合に使用する記号。外部結合子の中に参照先を記載することが多い。 ここではよく使う フローチャート の記号を紹介しましたが、 フローチャート 作成では記号の種類を増やさず、できるだけシンプルに書くよう気を付けましょう。また記号の持つ意味や用途を正確に理解して作成することで、読み手に伝わりやすい フローチャート になるでしょう。 プログラミング フローチャート (フロー図) の書き方 プログラミングの フローチャート の書き方ですが、まずは基本的な以下3点の書く目的をしっかりと理解することが大切です。 プログラム構造の整理 目的の１つ目は、プログラム構造の整理・理解をすることです。 プログラムは、書き方によって処理スピードや可読性に大きな影響を与えます。 実際のプログラミング前には、最適な設計が可視化され共通認識されていることが望まれます。 プログラミング速度を上げるため(効率化) 目的の2つ目は、プログラミングの速度を上げることです。 しっかり設計ができていれば、その通りに効率的にプログラムを書けます。設計ができていなければ、後々修正が多く発生し余分に時間が掛かかってしまいます。 プログラム品質の向上 目的の3つ目は、プログラミング品質を向上させることです。 フローチャート を書くことでプログラムの全体像が明確になり、設計漏れやバグを減らせます。つまり、プログラムの品質が上がります。 フローチャート を使って他者と事前レビューをすることで、更に品質を上げることもできます。 次にプログラミングの フローチャート の書き方を紹介します。 プログラミングにおける フローチャート には、よく使われる以下の「型」がありますので、まずは「型」を覚えることが、プログラミング フローチャート の書き方をマスターする近道です。 それでは代表的なプログラミングの フローチャート の書き方(事例)を見て行きます。 順次構造 順次構造の フローチャート の型はプログラム処理を順番通りに記述しているプログラムの構造を表します。「開始」の記号が上にあり、上から一番したにある「終了」の記号へ向けての処理がシンプル書かれていく構造です。 分岐構造 分岐構造の フローチャート の型は「条件分岐」の記号が使用され、条件によって処理内容が分かれている構造を表します。 具体的にはコード記述で使用する「switch/case文」や「if/else文」を表す構造です。 switch / case文 if / else文 反復構造(ループ) 反復構造の フローチャート の型は、「条件分岐」や「ループ開始/終了」の記号が使用され、繰り返し処理のあるプログラムの構造を表します。具体的にはコード記述で使用する「for/while文」「do while文」などを表す構造です。 for / while文 do while文 　※最初に処理を実行するか・しないかの違いだけのため省略 またプログラミングの フローチャート の書き方において、 アルゴリズム 理解は必須となります。 そもそも アルゴリズム を理解しなければ、プログラミングの フローチャート は書けません。 以下に代表的 アルゴリズム のうち「ソート」と フローチャート の書き方(事例)を一つ紹介します。 バブルソート バブルソート とは、ソート(データの集合を一定の規則に従って並べること)の一つで、バラバラに並んでいるデータ要素を「昇順(小さい順)」もしくは「降順(大きい順)」に並べ替えるやり方のひとつです。隣接する要素の大小比較と並べ替えを繰り返すことで全体を昇順(降順)に並べ替えるやり方です。 (例) 他、代表的なソートには以下があります。 選択ソート 選択ソートも「昇順(小さい順)」もしくは「降順(大きい順)」に並べ替えるやり方のひとつです。バラバラに並んでいるデータ要素の中で一番小さい値を探し、1番目の要素と交換し、次に2番目に小さい値を探し出し、2番目の要素と交換し...をデータがなくなるまで繰り返すことで全体を昇順(降順)に並べ替えるやり方です。 クイックソート クイックソート も「昇順(小さい順)」もしくは「降順(大きい順)」に並べ替えるやり方のひとつです。バラバラに並んでいるデータ要素から 軸要素となる基準値を決め 基準値より大きい値を基準値より右に置く 基準値より小さい値を基準値より左に置く の3ステップを「基準値よりも大きいグループ」と「基準値よりも小さいグループ」に対して何回も繰り返すことで全体を昇順(降順)に並び替えます。 ソート以外の アルゴリズム について、ここでは省略します。 他 アルゴリズム 種類について詳しく知りたい方は以下入門書がおススメです。 www.shoeisha.co.jp ここでは、プログラミングの フローチャート の書き方について見てきました。 プログラミングの フローチャート の書き方をマスターするには、まずたくさんの「型」を覚え、実践では書く目的をしっかり意識するように心がけましょう。 フローチャート 作成ツール ここでは フローチャート 作成ツールを紹介します。 フローチャート はMSOfficeのWord、 Excel 、 PowerPoint の図形挿入を使っても簡単に作成できますが、以下の様な フローチャート 作成ツールでも簡単に作る事ができます。 google スライド docs.google.com Google ドライブ で無料使用できるプレゼン用ツールの『 Google スライド』でも フローチャート の作成は可能。安全なデータ共有・観覧による第 三者 とも共同編集も可能。 フローチャート を作成するための機能やパーツ数は少ないが、シンプルなチャートを作れる。 draw.io www.draw.io 完全無料で会員登録やインストール不要な『draw.io』は、高機能で使いやすいのが特徴の フローチャート 作成ツール。 記号もテンプレートも豊富かつ図形から自動で線や矢印を伸ばすことができるため、初心者にも直感的な操作ができる点が魅力。作成した図はOneDriveや Google ドライブや GitHub に保存できます。豊富な機能とテンプレートで素早く フローチャート を作成したい方におすすめ。 CaCoo cacoo.com 『CaCoo』は完全無料オンライン使える フローチャート 作成ツール。 マインドマップ やプレゼンなどのテンプレートや、 スマートフォン 用の ワイヤーフレーム が用意されていたりとパーツが多いため、リッチな フローチャート を書くことができる。また、共 有機 能を利用して他メンバーとのチャットや同時編集もできる点も魅力。 まとめ 最後に フローチャート の書き方で参考になる書籍もご紹介。 システム分析・改善のための業務 フローチャート の書き方 改訂新版 https://www.amazon.co.jp/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E5%88%86%E6%9E%90%E3%83%BB%E6%94%B9%E5%96%84%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E6%A5%AD%E5%8B%99%E3%83%95%E3%83%AD%E3%83%BC%E3%83%81%E3%83%A3%E3%83%BC%E3%83%88%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9-%E6%94%B9%E8%A8%82%E6%96%B0%E7%89%88-%E6%A0%84%E5%8F%A3%E6%AD%A3%E5%AD%9D/dp/4382055776 www.amazon.co.jp 業務改革、 見える化 のための業務フローの描き方 https://www.amazon.co.jp/%E6%A5%AD%E5%8B%99%E6%94%B9%E9%9D%A9%E3%80%81%E8%A6%8B%E3%81%88%E3%82%8B%E5%8C%96%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E6%A5%AD%E5%8B%99%E3%83%95%E3%83%AD%E3%83%BC%E3%81%AE%E6%8F%8F%E3%81%8D%E6%96%B9-%E3%83%97%E3%83%AC%E3%83%9F%E3%82%A2%E3%83%A0%E3%83%96%E3%83%83%E3%82%AF%E3%82%B9%E7%89%88-%E5%B1%B1%E5%8E%9F-%E9%9B%85%E4%BA%BA/dp/4839965560 www.amazon.co.jp 今回は フローチャート の書き方を紹介しました。 特に若手のうちはできるだけ多くの フローチャート を書くことをおススメします。 頭で理解しているつもりの流れを フローチャート で可視化すると、意外な発見や不要・不足のステップが多くあることに気づき、自身の業務理解を早めるだけでなく、マネジメントに必要な「俯瞰する力」、「整理・要約する力」、「他者に説明する力」も高めてくれるはずです。 今回ご紹介した フローチャート の書き方が これから フローチャート を書く方々の一助となれば幸甚です。 　 当社ではエンジニア 中途採用 に力を入れております。 もし、当社の雰囲気・技術内容等にご興味を持たれましたら以下サイトの募集職種をお気軽にご確認ください！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 https://rakus.hubspotpagebuilder.com/visit_engineer/ rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

こんにちは、株式会社 ラク スで先行技術検証や、ビジネス部門に技術情報を提供する取り組みを行っている技術推進課に所属している鈴木（ @moomooya ）です。 ラク スの開発部ではこれまで社内で利用していなかった技術要素を自社の開発に適合するか検証し、ビジネス要求に対して迅速に応えられるようにそなえる 「 開 （ か ） 発の 未 （ み ） 来に 先 （ せん ） 手をうつプロジェクト（通称：かみせんプロジェクト）」 改め 「技術推進プロジェクト」 というプロジェクトがあります。 2020年度上期に「サービス分割を見越した ドメイン 層設計」について取り組んだので、概要を紹介したいと思います。 今までの記事はかみせんカテゴリからどうぞ。 tech-blog.rakus.co.jp 今回の目標 余談：「開発速度を維持するために」サービス分割を検討するというのはなぜ なぜ最初からサービス分割をしないのか モノリスで困ること モジュラーモノリスとは ビジネスロジックの設計方法 実装と機能修正の範囲限定 データストアについて 結論 今後の課題 参考文献 書籍 論文 ブログ記事 今回の目標 2017年に社内で マイクロサービスアーキテクチャについて検証した 際には「サービス立ち上げ時にはマイクロサービス アーキテクチャ は選択するべきではない」という結果が導かれました。 この判断結果は2020年時点でも変わらないものだと感じています。とはいえサービスが大きくなったときに「開発速度を維持するためサービスの分割を検討することになる」というのも正だと思います 1 。 このとき必要に応じて「サービスを分割することが出来る」設計になっていなければ、年単位で移行したという事例が散見されるように、 モノリス からマイクロサービスへの移行は極めて難しい判断になるでしょう。 サービス分割の肝となる部分は「 ビジネスロジック ＝ ドメイン 層が分割可能かどうか」という点だと考えています。なので今回のテーマは「サービス分割を見越した ドメイン 層設計」と設定し調査検証を行っていきました。 余談：「開発速度を維持するために」サービス分割を検討するというのはなぜ プログラマー が扱える適切な ソースコード 量（プログラムの規模）には上限があります。 プログラミング言語 等にも大きく依存しますが、1万行であるとか、1画面に収まる量であるとか、いろいろな観点で語られますが人間に認知限界が存在する限りどこかに限界があります。 そして（特に エンタープライズ 領域の）プログラムの ソースコード は数十万をゆうに超え、数百万を超える場合もあります。明らかに人間が扱える上限を超えています。 上限を超えたプログラムがどうなるか、というと「ロジックのミス」「想定しないバグ」「修正漏れ」が増加することは想像に難くないと思います。そのため適切なボリュームになるようプログラムを分割する必要があると考えます。 なぜ最初からサービス分割をしないのか まずは「サービス立ち上げ時にはマイクロサービス アーキテクチャ を選択しない」のはなぜなのかという話を振り返ります。マイクロサービス アーキテクチャ を採用する、ということがどういうことなのか噛み砕くと以下のようになると思います。 複数の Webサービス を開発・運用し、連携させる （理想としては） Webサービス ごとにチームを構成し、互いに内部の構造は依存しない 複数の Webサービス として作ることでマイクロサービスのメリットとされる技術異質性が確保できたり、物理的にロジックの汚染を防ぐことは出来ますが、それらのメリットを覆すだけの運用コストが発生してしまいます。 Kubernetes などのコンテナ オーケストレーション ツールを高レベルで使いこなすだけの運用スキルがチーム内にあれば解決できるかもしれませんが、結局「高レベルのスキル＝高コスト」なので立ち上げ時には向きません。 また Webサービス ごとにチームを構成することで迅速な開発を行っていけるのもメリットですが、物理的に別サービスになっていることと、チームが分かれていることでサービス境界の定義の見直しがしにくくなります。サービス境界の定義が不適切だとマイクロサービス化して得られるはずのサービス感の独立性が失われるため、いわゆる「分散 モノリス 」という アンチパターン に陥ってしまいます。サービス立ち上げ時は一般的に ドメイン 知識も乏しく適切なサービス境界の定義は難しいため選択しにくい選択肢になります。 またサービス立ち上げ時は「扱えない規模のプログラム規模拡大」も「大きな負荷」もまだ発生していません。利益が発生していない時点で、発生していない問題にコストを投入するのは悪手と言えるでしょう。 モノリス で困ること マイクロサービス アーキテクチャ が流行し始めた2016年頃から「モノリシック アーキテクチャ は悪」という主張が散見されました。これには誤りが含まれています。 まずモノリシック（1枚岩） アーキテクチャ の特徴としてデプロイメントラインが1つであることが挙げられます。これは明確にマイクロサービス アーキテクチャ に対してメリットです。複数のデプロイメントラインが存在するとその分デプロイコストはかさみます。 ではモノリシック アーキテクチャ は何が「悪」なのか、というと体験している人も多いと思いますが、モジュール間の参照が複雑に交差することによるスパゲッティ化（ Big ball of mud = 大きな泥団子、とも）が起こりやすいことがモノリシック アーキテクチャ の真の問題です。 マイクロサービス アーキテクチャ は構造的にスパゲッティ化が起こりにくい アーキテクチャ です。しかし立ち上げ時にはコスト的に見合いません。であれば、スパゲッティ化しにくい方法（適切なモジュール分割）を適用した モノリス が実現できれば立ち上げ時の有力な候補となりえると考えました。 モジュラー モノリス とは 適切なモジュール分割を行った モノリス を調べていくとそれが「モジュラー モノリス 」と呼ばれていることを知りました。端的に言うと理想的なモジュール分割が行われた「きれいな モノリス 」です。 1つのプログラム内で独立性の高いモジュールとして分割されることで、規模が大きくなったときのサービス分割もやりやすそうに見えました。 またモジュール分割の境界線（サービス境界）を見直したくなった場合でも1つのプログラムの中の話なので、マイクロサービスに比べて見直しやすいとも感じます。 当然 モノリス なのでデプロイメントラインも1つです。 ビジネスロジック の設計方法 実際の ビジネスロジック 層の設計はDDDで出てくるアグリゲートパターン 2 が適用できそうです。 加えてファクトリパターン 3 も適用候補として準備しておくと良いと思います。ちなみに今回の検証ではファクトリパターンを候補にしていなかったため実装の段階で課題に直面することになりました。 詳細はDDD本を参照していただきたいですが、アグリゲートパターンは アグリゲート（集約） 関連するオブジェクトの集まり データを変更する単位（≒DB トランザクション の単位） アグリゲーションルート 外部のアグリゲートとコミュニケーション可能な唯一のオブジェクト（＝エンティティ） という概念に基づいていて、アグリゲートの生成もアグリゲーションルートのインタフェース（コンスト ラク タとか）により行います。 ただし、アグリゲートがある程度複雑になってくると生成ロジックも分離したほうがよくなってきます。生成ロジックの分離と カプセル化 を行ったものをファクトリとして扱うのがファクトリパターンです。 ファクトリパターンと言っても実装方法（実装場所）はさまざまなようです。 アグリゲートルート 集約ルート内にファクトリメソッドとして実装 もちろんコンスト ラク タでもよい アグリゲートパターンの部分で触れたケース （アグリゲート内の）別のオブジェクト 生成に関連がつよいオブジェクトにファクトリメソッドをもたせる （アグリゲート外の）別のオブジェクト（もしくは別のサービス） 生成ロジック的にアグリゲート内に収めるべきではない場合はアグリゲートの外におくことをためらわない また、アグリゲートパターンに代わる別の設計手法としてMichael Nygard氏により「ライフサイクルによる分割( Services by Lifecycle )」も提唱されていますが、今回は未検証です。 実装と機能修正の範囲限定 結局実装してみないとわからないので試しに実装してみました。お題は弊社「 楽楽明細 」のような帳票発行サービスをイメージして作ってみました。 アプリ（サービスレイヤ）の部分は ウェブアプリケーション フレームワーク のルーティング処理の実装箇所だと思ってください。 上記のような設計をして、実際に実装してみたのですが先述の通りファクトリパターンを把握していなかったため「アプリ（サービスレイヤ）」の部分に初期化処理を実装してしまいました。 それの何が悪かったかというと機能追加のアップデートを実装したときに顕在化しました。 請求書のテンプレートを送付方法に応じて使い分ける事ができる機能を追加しました。送付方法は「メールにPDF添付」「印刷して郵送」を想定しています。点線部分は追加、修正が入ったモジュールになります。 見ての通り「アプリ（サービスレイヤ）」に修正が入ってしまってます。今回の前提（モジュラー モノリス ）であれば実質的な問題はほとんどありませんが、サービス分割後を想定するとサービス全体が停止することになってしまいます。ファクトリメソッドとしてアグリゲートルート内もしくはアグリゲート内にファクトリオブジェクトとして持っていれば「アプリ（サービスレイヤ）」には影響がなく、修正が入っていない受領者アグリゲート、売上レコードアグリゲートに関する機能は動かし続けることが可能になります。 データストアについて 今回は利用していませんでしたが、データストア、主に RDB についても分けておいたほうが良いです。 物理的にDBサーバーを別で用意するとやはり手間がかかるので MySQL でいうdatabase（ PostgreSQL だとschema）の単位で分けるとか、もっと簡易にテーブル名で分けておくとかやり方はいろいろあると思いますが、分けておくと良いでしょう。 DBの分け方については参考文献の"Monolith to Microservices"のchapter.4が参考になると思います。 結論 実際に設計、実装してみた感じでもモジュール化（モジュラー モノリス ）を目指すことでサービス分割を低コストで実現することは可能そうに思えました。ただし、昔ながらの モノリス より手間が増えることは間違いありません。手間が増える量がマイクロサービスに比べてはるかに少なく現実的な選択肢になるところまで落ち着く可能性がある、というのが適切な評価だと思います。 なので結局はバランスの問題ですが、ある程度サービス拡大が見込める場合には先行投資的にモジュラー モノリス で構成し、賭けの要素が強いサービスの場合は モノリス でコスト最小で昔ながらの モノリス で構成する、といった選択になるのかな、と感じました。 今後の課題 アグリゲートパターンはやはりサービス境界（アグリゲート バウンダリ 、アグリゲート境界）の定義に ドメイン 知識を必要とするため難しい、というのは解決されていません。 モノリス であることで取り返しはつくようになるものの ドメイン 知識が乏しい立ち上がり時に設計することは難易度が高いと思います。 「ライフサイクルによる分割( Services by Lifecycle )」ではサービスの利用フェイズをもとにサービス境界を定義していくという発想によりサービス境界の定義を比較的容易に行うことが出来る可能性を感じるため、ライフサイクルによる分割について今後検証していきたいと考えています。 参考文献 書籍 クリス・リチャードソン『 マイクロサービスパターン 』（ インプレス , 2020） ヴァーン・ヴァーノン『 実践ドメイン駆動設計 』（ 翔泳社 , 2016） エリック・ エヴァ ンス『 エリック・エヴァンスのドメイン駆動設計 』（ 翔泳社 , 2011） サム・ニューマン『 Monolith to Microservices 』（ オライリー , 2019） 洋書 nginxから 無料版PDFが配布 されています 論文 Brian Foote & Joseph Yoder, " Big Ball of Mud " ブログ記事 The awesomeness of Modular Monolith (投稿日: 2017/05/08) Sebastian Gebski CTO at Gemius （デジタル マーケティング 企業） マイクロサービスへのアンチテーゼ The Modular Monolith: Rails Architecture (投稿日: 2018/01/23) Dan Manges CTO at Root Insurance （ 自動車保険 ） 元創業CTO at Braintree （支払いプラットフォーム） Rails アプリの アーキテクチャ としての提案 今回扱う内容についての言及はおそらくこれが最初 Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity (投稿日: 2019/02/21) Kirsten Westeinde Dev. Mgr. at Shopify Shopifyによる事例紹介 Modular Monoliths — A Gateway to Microservices (投稿日: 2019/03/31) Natalie Conklin Modular Monolith Primer (投稿日: 2019/12/03) Kamil Grzybek engineer at ITSG Global モジュラー モノリス 入門 モノリスの分解において、マイクロサービスは必然ではない - QCon LondonにおけるSam Newman氏の講演より (投稿日: 2020/06/29) エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com 他にも大きくなってきた負荷を適切に分散したい、なども理由になると思います。 ↩ エリック・ エヴァ ンス『エリック・ エヴァ ンスの ドメイン 駆動設計』 p.123 ↩ エリック・ エヴァ ンス『エリック・ エヴァ ンスの ドメイン 駆動設計』 p.134 ↩