スタイル・エッジ技術ブログ

士業集客支援/コンサルティングのスタイル・エッジのエンジニアによるブログです。

AppSheet で社内向けツールを作った話

はじめに

こんにちは。スタイル・エッジの YH です。

前回のブログ執筆からおよそ１年半が経過し、新卒で入社したてホヤホヤだった私もついに３年目…😨
今まで多様な業務を経験させていただきましたが、今回はノーコード開発に携わった際に利用した「 AppSheet 」というツールをご紹介します。

※本記事では2023年7月現在の情報を掲載しています。 最新の情報は AppSheet 公式リファレンスをご覧ください！

アプリをノーコードで開発しよう

ノーコード開発とは、コーディングなしでシステム開発を行う手法のことを指します。
GUI で処理を作成でき、インフラ関連の構築も不要であることが特徴で、非エンジニアの方でも簡単にアプリケーションを作成できます。
今回取り扱った Google が提供している「AppSheet」もノーコード開発ツールの一種です。

まずノーコード開発の手始めとして、事業部内で利用する勤怠管理ツールを開発することになりました。
アプリでできることは下記の通りです 👇

  • アプリで出退勤や所在を登録すると、勤怠連絡用のチャットに自動連携される
  • 勤怠情報がチーム別・プロジェクト別でアプリ上から確認できる

実際の開発期間は、仕様検討も含めておよそ1ヶ月ほど。
ノーコード開発の手軽さを体感しました 🎈

次は日報ツールだ！

勤怠管理ツールの開発実績からノーコード開発の可能性を見出し、次なる野望として全社向けの日報管理ツールを作成することになりました。
実際の運用に乗せるまで結果的におよそ2.5ヶ月ほどかかりましたが、この取り組みのなかでノーコード開発の便利さと難しさを実感することができました。

本記事では開発中の所感をもとにノーコード開発の得手・不得手を紹介していきます。

使って分かったノーコードの強み

環境構築が不要なので、すぐ実装に取り掛かれる

ノーコード開発ではアプリを新規作成した直後から開発に取り掛かることができ、インフラ周りの準備がほぼ不要です。
開発前の準備には専門の知識が必要になる場合が多いため、この辺りを AppSheet が担ってくれることは開発の敷居をかなり下げてくれるように感じました。

例えば AppSheet の場合、 AppSheet Database という独自のデータベースをアプリ作成と同時に自動で用意してくれます。
その他、通常の開発であれば必要になるパッケージのインストールやサーバ周りの構築などの工程が必要ですが、AppSheet ではプラットフォームに用意されているため環境構築自体が不要です。
即実装に取り掛かれるこのスピード感は、ノーコード開発の大きな強みと言えるでしょう。

共有方法に関しても、Google アカウントさえあれば公開範囲を設定するだけなのでお手軽にアプリ開発に取り掛かれます。

とにかく開発スピードが速い

仕様さえ固まれば GUI 操作ですぐに実装することができます。
対象データの一覧表示のような View なら、ものの 5 分で実装することができました。

データの表示だけでなく、登録フォームも簡単に実装できます。
特にバリデーションの設定が簡単で、Google Sheets でのデータ管理で課題となる入力規則の設定や、必須・任意項目の指定などもマウス一つで簡単に設定することが可能です。
（一部バリデーションの指定にコーディングが必要になる場合もありますが、Google Sheets や Excel の関数をご存じの方ならすぐに AppSheet 独自の関数に落とし込めそうです。）

ちなみに、実際の画面がコチラ👇

Viewの設定画面

諸々設定するとこんな感じの画面がお手軽に作成できます✨

作成されたタスク一覧画面

（Google and the Google logo are registered trademarks of Google LLC, used with permission.）

GUI なので何をやっているか分かりやすい

AppSheet では「ボタンを押すと ○○ をする」というような機能面の開発を「Action」という機能を使って行います。
この場合、「どのテーブルに」「どんな条件で」「何を行う」というのを GUI で指定・確認できるので、開発経験が浅くても開発のハードルが低くなるのではと思いました。

また、何かしらの処理や動作をトリガーにするデータ操作や、Webhook による連携を「Automation」という機能を用いて開発します。
Automation ではフロー図に処理を書いていくため、一目でなんの処理が行われているのか見やすいという利点があります。

下記は実際の Automation 設定画面になります💁‍♀️
これならプログラミング経験がない方でも簡単に実装できそうですね！

Automation設定画面

（Google and the Google logo are registered trademarks of Google LLC, used with permission.）

使って分かったノーコードの弱み

「できること」「できないこと」がハッキリわかれる

ノーコード開発ではそのプラットフォームに用意されている機能がすべてになります。
つまり、用意されていない機能や処理は実装できない（ローコードで実装できる場合でも、かえって冗長になることがある）という弱点があります。

このような処理を実現する奥の手として、AppSheet では Google Apps Script（GAS） の呼び出しが可能です。（戻り値も取得できます）
しかし「GAS の呼び出し」というオーバーヘッドが発生しているのか、処理が遅くなる感覚がありました。

実際、別で開発したアプリでは AppSheet での実装が難しい部分を GAS で補ったのですが、処理自体の遅さが気になったのはもちろんのこと GAS 実行時のエラーキャッチが難しかったです💦
そういう点でもプラットフォームに用意されている機能以上のことを実装するのはハードルが高いと感じました。

チーム開発には不向き

AppSheet は個人開発を想定して構成されているようで、チーム開発には適していません。
これは小規模ながらもチームで開発を進めていた日報ツール開発では大きな障壁となりました。

例えば、一般的な開発で用いられるバージョン管理ツール（Git や Subversion など）の役割を担えるような機能が AppSheet にはありません。
（過去の履歴を自動でバージョンとして残し、特定のバージョンを指定して変更を戻すことなどは可能です）
このため複数人で一つのアプリを編集しなければならず、変更がバッティングすると実装した機能が消えてしまったりするので運用には工夫が必要でした。

日報ツール開発時は、チームで開発するために下記のような運用ルールを策定しました。

  • 自己検証は公開中のアプリを複製して作成した別環境を用意して行う
  • 同時に公開中のアプリを編集しないよう、専用チャットで作業を行う旨を周知するよう徹底する

プラットフォームの品質への依存度が高い

提供されたプラットフォームで開発している以上、プラットフォーム自体のバグやシステムエラーには太刀打ちできません。
またメンテナンスによる瞬断の有無は運営側のアナウンスを待つ他なく、AppSheet の場合（肌感ですが）こういったアナウンスが遅い印象があります。

ちなみにスタイル・エッジでは対策として

  • 公式サイトのアナウンスを定期的に確認する
  • プラットフォームのメンテナンスがある場合は、利用者に予めアプリの使用を控えてもらうようアナウンスする

などを行っています。

最後に

ここまでノーコード開発の強みや弱みを書いてきましたが、やはり「誰でもツールを作れる」のは魅力的だと思います。
これまで Google Sheet 等で管理していたデータをアプリ化するだけでも、データの集計や入力ミスの防止などに大いに役立つと感じました。

このように、スタイル・エッジでは Web アプリケーションだけでなくノーコードツールなどの新しい技術を取り入れた社内ツールも作っています！
ご興味ある方は最近リニューアルされた採用サイト ↓をぜひご覧ください ♪ recruit.styleedge.co.jp

RPA入門

こんにちは！スタイル・エッジの310です。

簡単に自己紹介をしますと
出身は愛知県、色んな意味で激動の時代を生き抜いてきた1985年生まれです。
帰宅後は3歳になる娘と、日々一緒にお風呂入る入らない論争を繰り広げています。

職歴は一風変わっておりまして
家屋の壁紙を貼る仕事、車のライン工場、パチンコ屋、バンドマン（楽曲制作/編集）、アパレルなどを経験し
前職は『ITコンサルタント』として、主にRPAツールを用いた業務効率化の提案、構築をしていました。

現在は『コーポレートエンジニア』として、ITサポートや端末、アカウントの準備といった基本となる業務や、AppSheetやRPAを用いた業務の効率化、自動化を担当しています。

はじめに

例えば、1名の入社申請が発生し、端末をお渡しするまで、どれくらいの時間を要していると思いますか？
弊社の場合ですと

  • アカウント準備で約50分
  • 端末準備で約30分

Ｗチェックを行う関係もあり、スムーズに進んだとしても1時間半はかかります。
またチェックを待つ＝自分の業務が滞るため、強制的に複数の業務を同時進行する必要が出てきます。

こういった業務を効率化するべく、現在、RPAを用いた検証を進めており
アカウント準備に関しては、セルフチェックを含め10分～15分程度で完結できるようになりました。

今回はその経験から、RPAの入り口だけでも感じていただければと思い
1.RPAとは
2.事前の準備～構築まで
3.RPAのメリット
4.RPA導入前に考えること
をご紹介していきます。

1.RPAとは

詳細は割愛しますが、人がやっている業務をロボットに任せてしまおうということです。

例えば

  • Excelやスプレッドシートから情報を取得しシステムへの入力（出力）
  • 毎月の勤怠システムの締め作業
  • 請求書の作成
  • メール送信

のような定型業務は特に向いています。

少し応用したモノとして

  • 届いたメールの内容を判定し、テンプレートから自動返信
  • フォルダ内に新規ファイルが追加されたら自動的にアップロード

といったロボットを構築することも可能です。

2.事前の準備～構築まで

実際に自動化しよう！となったら以下の順で進めていきます。

  • 業務の可視化
    →やっておくと構築が楽になります。手順を見直すことができるため、ナレッジ化やそもそもの効率化につながることもあります。

  • 自動化ツールの選定
    →例えばフォルダ内のファイルの移動や結合だけであれば、VBS、VBAの方が圧倒的に速いというケースもあります。自社内のスキル保有者状況と相談にはなりますが、コスト、保守面を踏まえ、色々な方法を検討します。

  • いざRPAの構築
    →上記を経て、RPAで自動化をしよう！となったらいざ構築へ入っていきます。実際のUiPathでの構築画面は以下のようになります。

●画面左側にある【アクティビティ】と呼ばれる動作のパーツを
●画面中央の【デザインパネル】の部分へドラッグ＆ドロップを行い
●画面右側の【プロパティパネル】で設定を行います。
※図ですと大量に設定項目がありますが、全部を設定するわけではなく、利用するブラウザであったり、入力された文字を変数に収納するかなど2,3か所設定するだけです。

あとはコツコツと組み立てていき

  • 自身の環境で動作検証
  • 利用部署（クライアント）環境での検証
  • 必要に応じて修正、改善

という工程を経て、最終確認したらロボットの完成です！

RPAのツールによりますが
作成したロボットはZIPファイル等にまとめて共有するだけのため非常に共有も楽です。

細かな部分として

  • 効果測定
  • サイトやシステムの仕様変更時の保守やトラブル発生時の対応の取り決め

このあたりも行っておくと盤石です。

3.RPAのメリット

自動化したい！となったときに、マクロ、VBS、バッチのようなスクリプトやプログラムで補えるケースもありますが、プログラムを書けなくても、パーツを組み合わせるだけで誰でも構築できるというのは大きなメリットです。

また『Power Automate』や、諸条件はありますが『UiPath ※Community版』のような無料で使えるツールもあり、無料で使える＝利用者が多い＝情報が多いという好循環により、何か困ったときは調べれば大体の情報を見つけられるというのも大きなメリットかと思います。

無料版のRPAであれば、セキュリティ面、利用停止やサービス終了等のリスクを考慮し
問題ないと判断ができる場合は導入してもよいと思います。
もしも有料版のRPAを導入する場合、以下の3点は事前に確認、整理しておくことが大切です。

費用対効果と導入目的

RPAツールの導入では約50万～100万円前後と相応の金額が年間で発生してきます。
単純計算ですが、時間給2000円と仮定した場合、年間250時間以上の削減が見込めるか
または、費用相応のES（従業員満足度）向上　に寄与できるかといったところは大きなポイントになります。

RPAの導入意義として人手不足の解消という面もありますので、費用のみを見るのではなく『何をどうしたいか、どうなってほしいか』を定めておくことはとても大切なことではないでしょうか。

ライセンス形式

RPAツールによって、フローティング型ライセンス、ノードロック型ライセンスというものがあります。

フローティング型

　概要：契約したライセンスの数だけ自由に使うことができるタイプ
　メリット：様々な部署で利用することができ、柔軟な運用が可能
　デメリット：ライセンス管理が必要、費用が高め

ノードロック型

　概要：ライセンスと端末が紐づくタイプ
　メリット：フローティング型と比較して安い、ライセンス管理が不要
　デメリット：端末交換時に変更手続きが必要、専用端末を設けることになる

個人的な見解としてはフローティングライセンスの方がおすすめですが、開発は専門部署が行い、使うのは別部署という場合は

  • 開発部署：フローティング（開発＆実行の両方可能）
  • 利用部署：ノードロック（実行のみ可能）

とする方法もRPAツールのライセンスによっては可能です。

ロボットの管理者

RPAに限らずですが、どこの部署がライセンスを管理するのか　であったり
構築、保守は誰が行うのか　など予め決めておく必要があります。

導入したものの、属人化してしまったり、野良ツールと化してしまっては
構築当初は良くとも、だんだんと改修が困難になり業務の変化についてこられなくなってしまいますので
ロボットの運用方針は固めておきましょう。

最後に

私自身まだRPAの構築歴は浅いのですがUiPath等のRPAツールではAPI連携が可能なものもあるため、非常に可能性を感じています！

無料版であれば、法人個人問わず利用ができますので

  • プログラミングは難しすぎて挫折してしまった・・・※わたしもそうです（　＾ω＾）
  • 何かデジタル技術による効率化の取り組みをやってみたい！

という方がいらっしゃいましたら、ぜひ試してみてはいかがでしょうか。

そんな私が働くスタイル・エッジでは
一緒に働く仲間を募集しています。
最近リニューアルされた採用サイト↓もカッコイイ作りになっていますので、ぜひご覧ください♪ https://recruit.styleedge.co.jp/

Amazon ECS Execを使ってみた

AWS

はじめに

こんにちは！スタイル・エッジ・グループのKYTです。
現在私はAmazon ECS(以下ECS)のAWS Fargate(以下Fargate)にて、 弊社のシステムを運用できないか試行錯誤中です。
今回はそんな中で学んだECS Execについて書きたいと思います。

ECS Execとは

ECS Execは、ECSで実行中のコンテナにログインするための機能です。
この機能の画期的なところは、Fargateではできなかった各コンテナへのログインを可能にした点です。

ECS Execの登場以前、Fargateで起動したコンテナは原則ECSコンソールを駆使して状態を確認することしかできませんでした。
ECS Execの登場でコンテナにログインできるようになり、内部から状態確認ができるようになりました。
トラブル時の解析がより細かなレベルでできることなどから運用において大変心強い機能です。

また、ECS ExecはAWS Systems Manager (SSM) セッションマネージャーを使用して接続することから、 セキュリティグループのインバウンドポートを開いたり、SSH キーを管理したりする必要がありません。

Fargateのプラットフォームバージョン1.4.0以降を利用した場合、 ユーザーが手作業でSSMエージェントをインストールする必要もなく使いやすいのもこの機能のポイントです。

実際に使ってみる

それでは実際にECS Execでログインするまでの手順を追っていきたいと思います。

今回は、ECR Public Galleryで提供されているApacheのイメージからコンテナをFargate上に作成し、 Amazon Linux 2023の踏み台サーバーから操作を行うという環境で進めます。

Apacheコンテナはすでに作成済みで、 aws configureコマンドにてIAMの認証情報も登録できた状態から進めていきます。

構成を簡単に図でまとめると以下のようになります。

なお、Apacheコンテナの作成は下記のクラスメソッドさんの記事が大変参考になります。

【初心者向け】Amazon ECSでApacheを起動したい~新コンソール版~ | DevelopersIO

それではやっていきましょう！

AWS CLI のセッションマネージャープラグインをインストール

ECS Execはセッションマネージャーを使ってログインをすることから、 AWS CLIにセッションマネージャープラグインをインストールする必要があります。
ということで早速踏み台にインストール！

sudo dnf install -y https://s3.amazonaws.com/session-manager-downloads/plugin/latest/linux_64bit/session-manager-plugin.rpm

ECSからセッションマネージャーにアクセスするためのポリシーの作成

ECSからセッションマネージャーにアクセスするためにIAMポリシーを作成します。
今回はEcsExecPolicyという名前で作ります。中身は以下の通りです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        }
    ]
}

タスクに紐づける実行ロールの作成

続けて、作成したEcsExecPolicyをアタッチするIAMロールを作成します。
今回ロールの名前は、EcsExecRoleとしました。
「信頼されたエンティティを選択」での設定内容は以下の画像の通りです。

次に出てくる「許可を追加」で、EcsExecPolicyをアタッチします。

タスク定義の新しいリビジョンの作成からタスクロールを指定する

ECSのコンソールに移り、Apacheコンテナを動かすタスク定義を選択し、 「新しいリビジョンの作成」からタスクロールの選択をします。
ここで、作成したEcsExecRoleを指定し、そのまま作成します。

※タスクへのCPU、メモリの割り当ては最小構成で作成しています。

サービスからタスク定義のリビジョンを最新のものにする

タスクロールの設定に伴い、タスク定義のリビジョンが新しくなりました。
それに合わせて、ECSのコンソールからサービスで紐づけるタスク定義のリビジョンに最新のものを指定しましょう。

※画像では4が最新のリビジョンになっています。

サービスに対するECS Execを有効にする

踏み台に戻りAWS CLIからサービスに対してECS Execの機能を有効にします。
デフォルトだと無効になっているため、有効化しないとECS Execが使用できません。

aws ecs update-service --cluster ｛クラスター名｝ --service ｛サービス名｝ --enable-execute-command

あらためてタスクを起動する

ECS Execの機能が有効になるのは、次に起動するタスクからになります。
ということで、踏み台から以下のコマンドを使い新しくタスクを起こしなおしましょう。

aws ecs update-service --force-new-deployment --cluster ｛クラスター名｝ --service ｛サービス名｝

コンテナにログイン

いよいよ踏み台からコンテナにログインです。新しく起動したタスクのIDをコピーして以下のコマンドを実行してみましょう！

aws ecs execute-command --cluster ｛クラスター名｝ --task ｛タスクID｝ --container ｛コンテナ名｝ --interactive --command "/bin/bash"

問題がなければ

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.

Starting session with SessionId: ecs-execute-command-…

と出てコンテナの操作ができるようになります！

ちょっとした注意事項

以上で無事コンテナには入れるのですが、気をつけないといけないことがあります。
それは、コンテナにpsやtopなど調査で使うコマンドが入っておらず、 ログインはできたけど確認ができないという場面に遭遇することです。

※今回使用したApacheのコンテナにもpsやtopコマンドは入っておりません。

実際にFargateを使う場面ではDockerfileで作りこんだイメージを使うことになるでしょうから、 その際に調査用のコマンドも忘れずに含めておきましょう！

おわりに

今回はECS Execを使用してログインするまでの手順を紹介いたしました。
Fargateでもコンテナのなかに入れるようになったことで、 運用上の安心感が以前より増したなあと個人的には感じております。

今回の記事が少しでも健やかなコンテナライフにつながれば幸いです。

そんなことをしている私が働くスタイル・エッジ・グループでは、 一緒に働く仲間を募集しています。

もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

私のAnsibleのTips

こんにちは、システム事業部のTMです。
普段はシステムの開発・保守やサイトの運用保守をしています。

弊社では、Ansibleでサーバーやシステムの設定管理をしています。
管理している中で見つけたAnsibleのTipsを紹介したいと思います。

変数名

変数名にハイフンを使っていて失敗することがよくありませんか？

FILE-OWNERというハイフンを使った変数を使ったPlaybookの実行例が下記です。 FILE-OWNER という変数名なのにFILEとなっています。変数名のハイフン以降が認識されていません。

fatal: [web]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'FILE' is undefined\n\nThe error appears to be in 以下省略}

Ansibleでは変数名は英字、数字、アンダースコアのみで構成されている必要があります。また変数名は英字から始めなければいけません。
またPythonやPlaybookの予約語は使えません。 https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#creating-valid-variable-names

cronの削除

Ansibleでは、cronモジュールを使用してcronジョブを設定することができます。

cron: 
   name: "upload log file to s3"
   minute: 45 
   hour: 8
   job: /usr/local/bin/aws s3 cp /var/log/httpd/access.log s3://log/access.log --no-progress

cronを設定する方法についての紹介記事はよく見かけますが、削除する場合についての記事は見かけません。
削除する必要が出てきた場合、どのようにしたら良いのでしょうか？
削除の場合だけ、crontabコマンドで削除しないといけないのでしょうか？

削除の場合はstateパラメータにabsentを指定します。

cron: 
   name: "upload log file to s3"
   state: absent

stateパラメーターのデフォルト値はpresentなので削除以外の場合は指定しなくても大丈夫です。
これで安全にcronを削除できますね。

暗号化したファイルを見るだけのコマンド

AnsibleのPlaybookはGitでバージョン管理されると思います。
その際、パスワードなどの機密情報を平文のままリポジトリにプッシュするのではなく、
Ansible Vault で暗号化してプッシュできます。

暗号化されたファイルを作成

ansible-vault create 暗号化するファイル

暗号化されていないファイルの暗号化

ansible-vault encrypt 暗号化するファイル

暗号化したファイルの編集

ansible-vault edit 暗号化したファイル

暗号化した内容を見たいだけというシチュエーションはよくあるのではないでしょうか？
ansible-vault editコマンドで確認もできるのですが、内容を確認するだけのコマンドもちゃんとあります。

暗号化されたファイルの中身を内容を確認

ansible-vault view 暗号化したファイル

ドライラン

Ansibleにもドライランがあります。
公式サイトではチェックモードと呼ばれています。

実行方法

ansible-playbook -i inventories/production.ini site.yml --check

--checkをつけて実行すると、リモートへの変更は行わずにPlaybookが正しく実行されるかどうかが確認できます。

おわりに

今回はAnsibleのTipsを紹介しました。
Ansibleを使うときの助けになれば幸いです。

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。 興味をお持ちいただけましたら是非とも下記を覗いてみてください！ recruit.styleedge-labo.co.jp

仕事で行き詰まった時に、やっていること3つ

スタイル・エッジ・グループに入社して5年目のリンです。
社会人歴はそれ以上に長いのに、未だに課題に行き詰まったり
悩んだり改善したりを日々繰り返しています。

今回は、個人的によく行き詰まる課題に対して心掛けていることをまとめました。
職種問わず、誰かの行き詰まりのヒントになればと思います。

最初に「みんなが同じ認識」という状況を作る

認識を合わせる
コミュニケーション全般に言えることですが、
複数人で話を進めるうちに、話がズレ始めてしまい、いつの間にか迷路に入り込んでしまうことがあります。

原因はその時々だとは思いますが、前提として実は
「その場にいる全員の理解・認識のレベルにばらつきが発生していた」というのはよくある話です。

お互いの過去の記憶に頼るよりも、
まず話の最初に理解レベルを揃えるための「おさらい」や「前提」「話し合いのゴール」を説明するだけで、
各自の心理的なハードルが下がり、思った以上に話がスムーズに進みます。

とはいえやっぱり難しいなと思った方は、以下のパターンに当てはめてみるのはどうでしょう。

  • 今日のミーティングはみなさんに◯◯を理解していただくことで、仕事で◯◯に活かしてもらうための会です
  • 前回出た結論（もしくは宿題）は◯◯でした。それを踏まえて、今回は◯◯の議題について話し合い、◯◯の答えを出すことが会のゴールです

大体、このパターンを応用することでなんとかなる…気がします。
会議中、迷路に迷いがちな方はぜひ、試していただければと思います。

タスクに追われる前に、整理する

タスクと時間の優先度
カレンダーに登録されているミーティングの数や、
チケット管理ツールやタスク管理ツールに記載された「期限付きのタスク」を大量に確認している時に、
ふとタスクに追われている自分に気づけることがあります。
（気づくことがまず大事です）

この時、急いでタスクを完了させねばと焦って走り出したい気持ちを抑えて、
とりあえずコーヒーを入れながら、優先度の整理を行います。

時間管理マトリックス
時間管理といえば、このマトリックス図が有名です。
さすがに毎日ここまでしっかり整理はしませんが、上記の図を念頭に軽くタスクを振り分けてみましょう。

この時、たまに「重要度がとても高いが、かなり時間もかかりそうな根深いタスク」に
気づくことがあります。

この課題こそが「業務に追われていると気づけず
ズルズルと抱え続けてしまい、いつまでも解決できないタスクになりがちです。

けれどもし、ここで気づくことができれば、この根深いタスクを
さらに細かいタスクに分解し、計画的に進めるための準備に入ることができるのです。

「仕事に追われる」というのはすなわち「重要なタスクを見逃すこと」と同義なので、
未来の自分のためにも、まずはここから始めたいところです。

「分からない」をそのままにしない

誰でも最初は分からない
「何が分からないのか、分からない」

目の前に立ちはだかる壁が大きすぎて、その壁の先に崖があるのか、お花畑があるのかすら分からない。

この時の「分からないから、焦りすら感じない」という”無”の状態こそが
目の前のタスクをタスクと認識できていない瞬間と言えます。

そんな時の魔法の言葉は

「この件に詳しい方はいらっしゃいますか？」

です。

この言葉を言うのに、勇気が必要な人もいると思います。相手に「これくらいも知らないの？」と
思われたくないとか、相手の時間を奪ってしまうようで申し訳ないとか…。

けれど、その一言を口にするだけで状況は変化し、
結果「何が分からないのかが、”わかった”」が課題解決の第一歩となるのです。

未来の自分への投資と思って、知らないことがあったら堂々と
「知らない」と言えるメンタルで、時には取り組んでみてはいかがでしょうか。

最後に

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。

興味をお持ちいただけましたら是非とも下記をクリックしてください🌸

recruit.styleedge-labo.co.jp

エンジニアも知っていると嬉しいデザインの原則

こんにちは！システム事業部のMJです。
もうすぐ新卒4年目、インターンも含めると5年目になり、年次を重ねるごとにさまざまな経験をさせていただいています。
ここ1年ほど新規事業のシステム開発に携わっていますが、その中で特に記憶に残ったのがシステムのデザインを1から担当したことでした。
（この話をすると、毎日Adobe XDと睨めっこしながら、2ヶ月ほどピクセル単位の修正をしていた記憶が蘇ってきます…）

上記のようにシステムのデザインとまではいかなくても、UI設計を行ったり、プレゼン資料を作成したり…とエンジニアがデザインをする機会は想像以上にあり、デザインの経験がなくても知識を身に付けておくだけで役に立つことがあります。
今回は、知っているだけでドキュメントや成果物のアウトプットが向上するデザイン・設計のテクニックをご紹介します！

ペルソナ設計

ペルソナ（Persona）とは、サービス・商品の典型的なユーザ像のことです。 マーケティングなどでよく聞くペルソナですが、デザインでも必要になってきます。 ペルソナを設定するメリットとしては、

  • プロジェクトの関係者間で、共通した人物像を形成することができる

  • ユーザを具体的にイメージしやすくなるため、製品やシステムが実際に使われている場面をイメージしながらデザインができる

  • その人物像を掘り下げることで需要の高い（低い）コンテンツが見えてくるため、取捨選択など各種判断の材料になる

などが挙げられます。

具体的には、システムのメインカラーを決める際に暖色系か寒色系かで自分とステークホルダの意見が割れたのですが、今回設定した主要なペルソナが20代女性で美容クリニック勤務（以下詳細割愛）だったため、それを根拠に議論を重ね、双方納得する色合いでデザインを進めていくことができました。

このように、デザイン決定の判断軸としてペルソナ視点を用いることでスムーズに問題解決ができたときなどは、ペルソナ設定の重要性を痛感しました…

デザインの4原則

わたしが実際にデザインを担当してみるまでは、デザインというと、色や柄などの美しさのイメージが先行していました。
ただ実際にデザインしてみると、色や柄が美しくてもレイアウトが整っていないと、ユーザに情報が的確に伝わらないということがわかりました。

レイアウトを整えるために重要になってくるのが「デザインの4原則」です！

  • 近接
    関連する要素をまとめることで、グループ化して情報の整理を行う

  • 整列
    要素を意図的に配置してページ上に関連性や統一感を持たせる

  • 反復
    ルールに基づいてデザインの要素を繰り返す

  • 対比
    異なる要素間でサイズや色の強弱を強め、目立たせたい情報を強調する

この4原則を用いることで、論理的にレイアウトを決めていくことができます。

ただし、顧客管理のようなシステムでは情報過多になるため全体的に項目が詰め込まれる傾向にあり、近接・整列・反復は実現できても対比などは難しく苦労しました…
アクセントカラーを決めたり、アイコンを使用するなどして多くの情報の中でも目を引くよう意識しました！

システム開発時に意識するポイント

上記2つのポイントはデザイン全てにおいて基本となる考えですが、システムを開発する際に意識すべきポイントもあります。

流行りのデザインと使いやすいデザインは違うということ

システム事業部にはデザイナーも在籍しているため、おしゃれなデザインやかっこいいデザインを見せていただく機会も多く、システムにも取り入れたいと思ったことが多々ありました…

流行りのデザインは斬新で魅力的に感じますが、ユーザが日常的に使うシステムの場合、デザインによってはユーザが入力する前に考える時間が増えてしまうことがあります。

例えばボタンをアイコンのみで表現した場合、「このボタンはなんのボタンだっけ…？」と悩む一瞬の時間が積み重なってユーザのストレスに繋がりかねないため、デザイン性と利便性を兼ね備える必要があります。

おそらく、流行りのデザインはユーザにとって馴染みがない、システムで使うには情報が省略されすぎている、などの点から使いやすいと言えない場合があるのだと思います。

ターゲットや場面によって「使いやすいデザイン」が変わってくるので、都度判断していくことが大事になります。（この判断軸としてペルソナを用いることも有効）

ユーザレビューを必ず行うこと

これはシステム開発においてどのフェーズでも必要ですが、特にデザインをしていると、自分のデザインしたシステムが自分の「当たり前」になってしまいます。
自分が使いやすいと思ってデザインをしていても、実はユーザの業務都合上項目の配置はこうがいい、といったケースを何度も経験しました。

それだけでなく、世間的にベターとされている手法や理論でさえも、使い方次第ではユーザに受け入れられない場合もあります。
そういった気づきや学びを得るためにも、ユーザレビューは必ず行うよう心がけていました。

おわりに

今回は自分の経験から「エンジニアも知っていると嬉しいデザインの原則」をご紹介しました。
エンジニアとデザイナーは、別分野として捉えがちですが、知っておいたほうがいい知識がたくさんあります。少しでも興味を持つきっかけになれば幸いです！

実はわたしがシステムデザインを担当したきっかけは、色彩検定を取得したことでデザインに興味を持ち、「やってみたい！」と頼み込んだことでした。
やりたいことがあれば、話を聞き、実践する環境を用意し、気にかけてくれる、そんな社風が弊社の素敵なところだなと感じています…！

☆スタイル・エッジ・グループでは、一緒に働く仲間を募集しています☆
もし興味を持っていただけましたら、採用サイト↓も覗いてみてください！
recruit.styleedge-labo.co.jp

CDKでCloudFormation StackSetsのデプロイを行ってみる

はじめに

お世話になっております。システム事業部のONです。
前回の執筆からちょうど2年になります。

中途入社して1カ月でアドベントカレンダー書いてと言われ、2~3カ月で技術ブログを書いてと言われ...
どちらもネタがないとオロオロしながら書いた記憶が鮮明に残っています。
そんな今回もネタがなくオロオロしているので試したかったことを実践してみます。

課題発生

ここ半年程、CloudFormationやSAM, CDKを触ることが多くありました。
これらの沼は深く、私はまだまだくるぶしぐらいしか浸かれていない状況です。

そんな最中、同一AWSアカウントの全リージョンにデプロイする内々のCDKを作る必要が発生しました。
当時はリージョンの配列をループさせて、各リージョンにスタックを作成する形で実装を終えたのですが...
後からCloudFormation StackSetsの存在を思い出し、これを利用すればもっとスマートな形にできたのでは...と疑問が出てきました。

StackSetsとCDK

CloudFormation StackSetsは複数のAWSアカウントやリージョンにスタックを作成できるサービスです。
すなわち、1つのテンプレートで複数のAWSアカウントやリージョンへの一括デプロイをしてくれます。
ドキュメントはこちらから。

StackSets の概念 - AWS CloudFormation https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html#stacksets-concepts-stackset

AWS Organizationsと組み合わせると、特定のOUに対してデプロイできたりメンバーアカウントが増えた際に自動的に反映してくれたりする、より強力な存在となってくれます。

CDKもAWSの各種リソースをデプロイすることができる仕組みです。
内部的にはCloudFormationが動いていますが、各種言語で定義できることが魅力の一つです。
CDKに関しては、当ブログで紹介している記事があるのでよかったらご参照ください！

AWS CDK入門｜準備からサブネットを分けるまで - スタイル・エッジ・グループ技術ブログ https://techblog.styleedge.co.jp/entry/2022/07/19/163825

さて、CDKで定義したリソースを複数のAWSアカウントやリージョンにデプロイするためにStackSetsと連携することはできるのか？というお話ですが...
CDKとStacksetsの連携は残念ながらサポートはされておらず、長い間issueがopenしている状態です。

StackSets Support · Issue #66 · aws/aws-cdk-rfcs · GitHub
https://github.com/aws/aws-cdk-rfcs/issues/66

ただ、このissueのなかでCDKを使ってStackSetsを作成する方法を紹介している方がいらっしゃいました。

https://github.com/aws/aws-cdk-rfcs/issues/66#issuecomment-754599325

せっかくなので、試してみましょう！！

実践編

StackSetsを扱うための準備として、下記2つのIAMロールを作成します。

AWSCloudFormationStackSetExecutionRole
操作するAWSアカウントのAdministratorAccessポリシーを利用できるロール

AWSCloudFormationStackSetAdministrationRole
CloudFormation経由でAWSCloudFormationStackSetExecutionRoleを利用できるロール

作成手順は以下のドキュメントをご参照ください。

Grant self-managed permissions - AWS CloudFormation https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-prereqs-self-managed.html

これらのIAMロールを作成するにあたって「ドキュメントは分割記載されていて分かり辛い！」という方は、CloudFormationのテンプレートも用意されていますのでおすすめです。

https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetAdministrationRole.yml
https://s3.amazonaws.com/cloudformation-stackset-sample-templates-us-east-1/AWSCloudFormationStackSetExecutionRole.yml

それでは、先ほどのissueのコメントにならってCDKの実行ファイルを調整してみます。

調整前のループでスタックを作るコード

// HogeEnvなどをimport(省略)

const app = new cdk.App();

// リージョン毎にスタックを実行(HogeEnvは{ account: xxxx, region: yyyy }の配列)
HogeEnv.forEach(env => {
    new HogeStack(app, 'HogeStack', { env });
});

調整後のStackSetsでスタックを作るコード

// envなどをimport(省略)

const app = new cdk.App();

// デプロイしたいスタックからテンプレート文字列を生成
const stage = new cdk.Stage(app, 'Staging');
new DeployCDKAsAStackSetsStack(stage, 'DeployCDKAsAStackSetsStack', { env });
const stackSetTemplateObj = stage.synth().stacks[0].template;

// StackSetsを作成するためのCloudFormationスタックを作成
const stackSetDeployer = new cdk.Stack(app, 'StackSetDeployer');
// テンプレート文字列を使ってStackSetsを作成
new cdk.CfnStackSet(stackSetDeployer, 'DeployCDKAsAStackSets', {
    permissionModel: 'SELF_MANAGED',
    stackSetName: 'DeployCDKAsAStackSets',
    capabilities: ['CAPABILITY_NAMED_IAM'],
    stackInstancesGroup: [
        {
            deploymentTargets: {
                accounts: [env.account],
            },
            regions: ['デプロイするリージョン', ...],
        },
    ],
    templateBody: JSON.stringify(stackSetTemplateObj),
});

今回は同一AWSアカウント内で複数のリージョンにデプロイするのが目的です。
そのため、デプロイするAWSアカウントはOrganizationsに依存しない形になります。
これらからpermissionModelにはSELF_MANAGEDを設定しました。

StackSetsを作成するためのパラメーターは以下のドキュメントをご参照ください。

class CfnStackSet (construct) · AWS CDK
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_cloudformation.CfnStackSet.html#autodeployment

デプロイ結果

今回はus-east-1とap-northeast-1の2リージョンを['デプロイするリージョン', ...],に指定します。
実行するとCloudFormationコンソールのStackSetsで2リージョンにスタックが実行されているのが確認できました。

同コンソールのスタック-スタックの詳細ではStackSetsを作成するためのstackSetDeployerスタックが作成され、
その後にStackSets経由で実際にデプロイしたいDeployCDKAsAStackSetsStackスタックが作成・実行されたことがわかります。

最後に

いかがでしたでしょうか？
2023年2月現在CDKのCloudFormation StackSets連携はサポートはされていませんが、
StackSetsを作成するスタックを定義することでCDKからStackSetsの作成ができることが確認できました。

冒頭のCDK内でループさせてスタックを作る方法だと、各リージョンでcdk bootstrapする必要がありました。
また、デプロイコマンドもcdk deploy --allとなって少々力業な感じが否めません。

StackSetsを作成する方法だと、記述量は増えてしまいますがIAMロールを2つ用意するだけで全リージョンのスタックを作成できるためスッキリとした構成にすることができました。
引き続き改善を進めていきたいと思います！

スタイル・エッジ・グループでは一緒に働く仲間を募集しております。
興味をお持ち頂けましたら是非とも下記をクリックしてください↓↓

recruit.styleedge-labo.co.jp