情報過多になったページを整理してみた

こんにちは！ 夏野菜の成長が著しい季節、草むしりの無限ループに陥っているHarashoです！

今回はこれまでデザインについて深く考えてこなかった私（バックエンドエンジニア）が、ページ構成やデザインについて考えるきっかけになったシステム改修について記事にしようと思います。

背景・経緯

普段私は社内システムの開発・運用を行なっていまして、もうすぐ1年が経とうとしています。

これまで機能改修や追加の依頼があった際、基本的には既存のページ構成を踏襲する形で開発を行ってきましたが、 ある時から特定のページにおいて機能追加が行いづらいと感じるようになりました。

そう思うようになったフロント起因の理由は、以下です。

• ページ内で行えるアクションが多い
  • 類似性はあるが、内容の異なるA, B, C, Dのそれぞれに対して、登録・編集・削除が行える
• ページ内に表示項目が多い
  • かつ、登録有無やステータスに応じた表示・非表示の切り分けがない
• ページ内で使用しているカラー色が多い
  など

一言でいうと、ページが『ごちゃごちゃしている』状態でした。

そのような中でさらに機能追加の依頼があり、これはいい機会だと思いデザイナーの方にフォローいただきながら整理をしました。

対応したこと

以下を実施しました。

1. ページ分割
2. 登録状況やステータスに応じた表示切り替え
3. 意図のない配色を除去
4. 余白を調整して要素を整列

ページ分割

ページ内でA, B, C, Dの登録・編集が行えていたのを、それぞれ個々のページに分解しました。
個々の登録・編集は独立していたので別ページに移動することへの仕様的制約はなく、今後新規要素が増えてもページの肥大化を防ぐことができました。

この時点でざっくりと元々のページから情報量が4分の1に減って見通しがよくなりました。

登録状況やステータスに応じた表示切り替え

修正前は初期表示されている要素が多々ありましたが、登録状況やステータスに応じて表示切り替えを行うようにしました。

具体的には、設定数を表示している箇所は登録のあるもののみ表示するようにし、 ボタンは各ステータスで押下可能なボタンのみ表示することで、次に行うアクションへの誘導を明示できるようになりました。

意図のない配色を除去

ボタンやセパレータに固有の配色を用いていましたが、極力使用する色を制限し、注意を引きつけたい箇所を目立たせるための配色に変更にしました。

余白を調整して要素を整列

項目間の余白、テーブルやinputタグのwidthを調整し、ガタガタとしていた個々の要素を整列することですっきりとした配置としました。

やってみて思ったこと

これまでデザインについて深く考えてこなかった私ですが、今回の対応でデザインはユーザーにどう行動してもらいたいか、何を見せたいかといった 意図を伝えるための手法であり、論理的に考えるものだと理解しました。

細かいテクニックは多々あるかと思いますが、基本的な考え方に少しでも触れることができ専門外と捉えていたデザインが面白いと思えるようになったことが個人的な収穫でした。

綺麗な絵は描けませんが、デザインについて少しでも語れるように日々精進していこうかと思います！

インゲージでは各種職種で募集を行なっています！ ご興味あればぜひご覧くださいませ〜。 ingage.co.jp

Integer型のカラムにdefaultを設定するとレコードの検索時間はどうなる？

こんにちは。oda@エンジニア１年目です。

先日、マイグレーションファイルを使って、テーブルにInteger型のカラムを追加しました。

必要なレコードにのみデータを入れて、その他はnullにしていたところ、次のような指摘をいただきました。

「default: 0を設定しておくのが自然」

※今回は0とnullが同じ意味合いになるカラムでした。

defaultを設定するか、nullとするかによる違いを調べてみたところ、次のようなものがありそうでした。

• レコードの検索にかかる時間
• レコードの検索や集計の結果

今回は、以下に焦点を当てて調べてみました。

• nullor0でないレコードを検索するときにかかる時間

それでは、実際にプログラムを動かしながら、確認していきたいと思います。

（以下、Rails 7.0.2.3、PostgreSQL14.2を使用しています。）

事前準備

まずは、Products(商品)テーブルを作成します。

bin/rails g model Products name:string

次に、サンプルデータとして、100,000件のレコードを作成します。

100000.times do |i|
  Product.create(name: "product#{i}")
end

このProductsテーブルに、stock(在庫)カラムを追加し、在庫のある商品は在庫数を、ない商品はnullor0を入れていきます。

defaultを設定しない場合

次のマイグレーションファイルを作成、実行します。

今回は1,000件ごとに、在庫を1入れるようにしてみました。

class AddStockToProducts < ActiveRecord::Migration[7.0]
  def change
    add_column :products, :stock, :integer
    products = Product.where('id % 1000 = ?', 0)
    products.update_all(stock: 1)
  end
end

default: 0を設定する場合

次のマイグレーションファイルを作成、実行します。

class AddStockToProducts < ActiveRecord::Migration[7.0]
  def change
    add_column :products, :stock, :integer, default: 0, null: false # ←ここを修正
    products = Product.where('id % 1000 = ?', 0)
    products.update_all(stock: 1)
  end
end

検証

それでは、rails consoleでそれぞれ確認していきます。

defaultを設定しない場合

以下のコマンドを実行します。

Product.where(stock: 1)

実行にかかった時間は次のとおりでした。

１回目：9.9ms　、２回目：11.8ms　、３回目：13.9ms

default: 0を設定する場合

同じく、以下のコマンドを実行します。

Product.where(stock: 1)

実行にかかった時間は次のとおりでした。

１回目：9.8ms　、２回目：12.6ms　、３回目：12.6ms

結果を整理

default	1回目	2回目	3回目
なし	9.9ms	11.8ms	13.9ms
あり	9.8ms	12.6ms	12.6ms

どちらの場合であっても、明確な差はありませんでした。

結果の考察

私はdefaultを設定した方が、時間が短くなると思っていました。

それは、nullが含まれていると検索に時間がかかるという話を聞いたことがあったからです。

今回、思っていたとおりにはならなかったので、その理由を考えてみました。

まず、そもそも、なぜ「nullが含まれていると検索に時間がかかる」のかということを調べてみたところ、IS NULLが含まれているとインデックスが利用できないので、遅くなるとの情報が見つかりました。

私は、上記の検証をした時に、インデックスの設定もIS NULLを含めた検索もしていませんでした。

この点について、再度検証してみます。

再検証

マイグレーションファイルにadd_index :products, :stockを加えて、IS NULLを使う場合と使わない場合を検証してみたところ、結果は、次のようになりました。

IS NULLを使った時にかかる時間（defaultを設定しない）

Product.where(stock: nil)

# 発行されるSQL
# SELECT "products".* FROM "products" WHERE "products"."stock" IS NULL

default	1回目	2回目	3回目
なし	36.3ms	36.3ms	39.7ms

IS NULLを使わなかった時にかかる時間（default: 0を設定する）

Product.where(stock: 0)

# 発行されるSQL
# SELECT "products".* FROM "products" WHERE "products"."stock" = $1  [["stock", 0]]

default	1回目	2回目	3回目
あり	38.0ms	35.7ms	38.5ms

再検証結果の考察

IS NULLを使っても、使わなくても結果に明確な差は現れませんでした。

そこで、今回使用したPostgreSQLのドキュメントを確認してみたところ、IS NULLを使ってもインデックス検索ができるとのことでした。

過去バージョンのドキュメントも見ることができたので、順番に見ていくとver8.2からver8.3に上がった時に、IS NULLを使ってもインデックス検索ができると変わっていました。

このため、結果に明確な差が現れなかったと考えています。

（参考）

ver8.2：https://www.postgresql.jp/document/8.2/html/indexes-types.html

ver8.3：https://www.postgresql.jp/document/8.3/html/indexes-types.html

まとめ

今回は、検証前に自分の考えていた結果とは、違う結果となりました。

それにより、より深く調べたり、違う角度から検証したりすることができました。

今後も自分の手を動かしながら、一つ、一つ学んでいきたいと思います！

最後まで、ご覧いただきありがとうございました！

ActiveRecord を色々試せる環境を作ってみる

こんにちは。ryohei515です。

実務で ActiveRecord の動作を確認したいときは、開発環境内の Rails Console で動かしてみるのですが、プライベートで確認したい時用に環境を作っておきたいと思い、備忘録的に残しておきます。
過去の記事で、サンプルデータを使って DB を触れる環境を作ってみたので、今回はそれを Rails から触れるようにしようと思います。

1. データ準備

以下のサンプルデータを使用します。データがほどよくあるので便利です。
PostgreSQL Sample Database

ダウンロードしたファイルは unzip コマンドで解凍しておきます。

unzip ./dvdrental.zip

2. Docker関連のファイルを作成

Docker の公式サイトを参考に、Rails の環境を構築してみます。
クィックスタート: Compose と Rails — Docker-docs-ja 19.03 ドキュメント

ただ、掲載の Rails, Ruby のバージョンが少し古いので、こちらを参考に、Rails は 6.1.6、Ruby は 2.7.6 を利用するようにします。

適当にディレクトリを作成して、以下の4ファイルを配置します。

docker-compose.yml

version: '3.8'
services:
  db:
    image: postgres:14.2-alpine
    ports:
      - "5432:5432"
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password

  web:
    build: .
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'"
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db

volumes:
  db-data:

Dockerfile

FROM ruby:2.7.6
RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - && \
    echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs yarn
RUN mkdir /myapp
WORKDIR /myapp
ADD Gemfile /myapp/Gemfile
ADD Gemfile.lock /myapp/Gemfile.lock
RUN bundle install
ADD . /myapp

Gemfile

source 'https://rubygems.org'
gem 'rails', '~> 6.1.6'

Gemfile.lock

（空ファイルで作成しておく。）

3. Rails プロジェクトを作成

以下のコマンドを実行して、ディレクトリを作ります。

docker-compose run --rm web rails new . --force --database=postgresql

4. データを DB に反映させる

3 の手順により、DB のコンテナが立ち上がったままとなっているので、起動させたコンテナのIDを特定し、ファイルをコピーします

docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED             STATUS             PORTS                    NAMES
ce4299b2c1c6   postgres:14.2-alpine   "docker-entrypoint.s…"   About an hour ago   Up About an hour   0.0.0.0:5432->5432/tcp   rails-docker-trial_db_1

docker cp /tmp/dvdrental.tar ce4299b2c1c6:/

起動中の DB コンテナに入り、コピーしたファイルをDBに復元させます。

dc exec db bash

bash-5.1# psql -h localhost -U postgres -c "CREATE DATABASE dvdrental;"
bash-5.1# pg_restore -h localhost -U postgres -d dvdrental ./dvdrental.tar

これでサンプルデータが DB に反映された状態になりました。

ただこのサンプルデータには、 独自に追加された型定義があるため、このままだと Rails 側でスキーマ情報を反映させた時エラーとなります。
そのため、その独自の型定義を使用している、film テーブルの rating を String に置き換えます。
（View でも利用されており、View を削除しないと型定義が変更できないため、先に削除します）

psql -h localhost -U postgres -d dvdrental

psql (14.2)
Type "help" for help.

dvdrental=# DROP VIEW film_list;
DROP VIEW

dvdrental=# DROP VIEW nicer_but_slower_film_list;
DROP VIEW

dvdrental=# ALTER TABLE film ALTER COLUMN rating TYPE varchar(255);
ALTER TABLE

dvdrental=# ALTER TABLE film ALTER COLUMN rating SET DEFAULT 'G';
ALTER TABLE

5. Rails から DB にアクセスできるようにする。

config/database.yml は以下のように記載しておきます。

default: &default
  adapter: postgresql
  encoding: unicode
  host: db
  username: postgres
  password: password
  pool: 5

development:
  <<: *default
  database: dvdrental

test:
  <<: *default
  database: dvdrental_test

その後、web コンテナに入り DB の定義から db/schema.rb を作成します。

docker-compose run --rm web bash

root@90f53214db3a:/myapp# bin/rails db:create
root@90f53214db3a:/myapp# bin/rails db:schema:dump

あとは存在するテーブルの model を作成し

bin/rails g model film --migration=false

（Rails の命名規則に従ったテーブル名ではないため）作成した model にテーブル名を指定してあげれば、Rails Console から扱えるようになります。

class Film < ApplicationRecord
  self.table_name = 'film'
end

bin/rails console
Running via Spring preloader in process 90
Loading development environment (Rails 6.1.6)
irb(main):001:0> Film.first
  Film Load (1.8ms)  SELECT "film".* FROM "film" ORDER BY "film"."film_id" ASC LIMIT $1  [["LIMIT", 1]]
=> #<Film film_id: 1, title: "Academy Dinosaur", description: "A Epic Drama of a Feminist And a Mad Scientist who...", release_year: 2006, language_id: 1, rental_duration: 6, rental_rate: 0.99e0, length: 86, replacement_cost: 0.2099e2, rating: "PG", last_update: "2013-05-26 14:50:58.951000000 +0000", special_features: ["Deleted Scenes", "Behind the Scenes"], fulltext: "'academi':1 'battl':15 'canadian':20 'dinosaur':2 ...">

おわりに

全 model で自動的にうまくテーブル名をつけたかったですが、今回はここまでです。
これを利用すれば、既存の DB に、Rails で接続して利用する時もできるようになりそう。
このサンプルデータは程よくデータが格納されているので、これでプライベートでも色々試せそうだなと思いました。

インゲージではエンジニアを募集中です！
詳細は以下のリンクよりご確認ください！

ingage.co.jp

完全未経験からWebデザイナーになるにはどのくらいの期間と努力が必要なのか

みなさんこんにちは!株式会社インゲージの水谷です!

コロナが流行してから、「オンライン受講で誰でもWebデザイナーに」みたいな謳い文句のオンラインスクールが増えたような気がします。

今回は、私が調査したオンラインスクールの受講内容をもとに、実際にそれでデザイナーとして活躍できるのか、どのくらいの時間がかかるのかについて考察していきたいと思います。

あくまで私の主観になりますが、キャリアチェンジや副業で「Webデザイナーになってみようかな」と迷ってる方の参考になれば幸いです。

「Webデザイナー」の定義

まずは、Webデザイナーと呼べる人材についての定義をします。

仕事でデザインを行う際の、最低限身につけておかなければならない最低条件と言ってもいいでしょう。

1.調べる力があること

デザインのアイデアを出す際に、的確で早い参考サイトなどの情報を選出できるか。

コーディング中にわからないことが出てきた時に素早く補填できるか。

基礎能力や経験がそこまで高くなくても、これらができれば現場でも十分活躍できます。

2.既存Webサイトをトレースしてデザインラフを起こす描画スキルがあること

IllustratorやPhotoshopでデザインを「ほぼ完璧に」トレースできるようになってなければならないと私は考えております。

経験が浅いうちは特に、他サイトの模倣をベースに諸々の調整やオリジナリティを付与し、デザインを作っていくことが多いです。

その際に、きちんとデザインを模倣できる基礎能力を持っていないと、案件としてのクリエイティブを作ることは困難だと考えております。

オンラインスクールの受講内容

私が独自に複数のWebデザイナー系オンラインスクールのカリキュラムやシステムを調査しました。

受講期間や値段、カリキュラムの細かい内容こそ違えど、システムやカリキュラムの構成はどこも似ていて以下のようになっておりました。

1.受講生にはメンター（講師）が1人つく

受講すると専任のメンターが1人つき、週1回のメンタリング（通話指導）を行うことができます。

メンタリングの時間はスクールによりますが、1回30分か60分ですね。

そこでカリキュラムのわからない点を聞いたり、実際のデザインの現場の話を聞いたりできます。

家庭教師みたいなイメージですね。

2.メンター複数人といつでも話ができるチャットサービスを利用可能

SlackやChatworkなどのチャットツールを使い、先述のメンタリングとは別でメンターと話ができます。

チャットグループ内は受講生+複数のメンター+運営が所属している状態となっており、他の受講生は見れないので気軽に質問することができ、複数のメンターの誰かが質問に気付き次第すぐ回答する形式ですので非常に早くて便利です。

3.カリキュラムの構成は主にPhotoshop+コーディング

カリキュラムの細かい内容はもちろんスクールによって違いますが、大体の流れは同じでした。

まず最初に「Webサイトがどうやってできているのか」「Webデザイナーは具体的に何をするのか」「Webデザインの原則（レイアウトやカラーなど）」といった基礎知識を学びます。

基礎を学んだあとは、Webデザインの定番ツールであるPhotoshopを使い、バナーデザインやWebデザインカンプの作成など様々な課題をこなします。

その後はHTML/CSS/JSといった、Webサイトのコーディングを学びます。最初はコピペベースでコードに触れ、徐々に自力でサイトコーディングができるようにしていくという流れでした。

受講完了したらどうなるか

前述のカリキュラムを完了した段階で、デザインの概念とWebデザインの仕組みの理解、基礎の制作スキルは習得することができると感じました。

決して安くはない受講料金を払った分の価値は十分にあると私は考えます。専門学校や大学に行くよりははるかに安く、効率もいいと思いました。

しかし、まだ圧倒的に実践経験が足りないので、最初に定義した「Webデザイナー」の定義における2の条件を満たせているかと言われると私としては疑問符が残ります。

デザインはスポーツと同じです。仮に野球で例えると、野球のルールやバットの振り方、ボールの投げ方がわかったとしても、実際に試合でヒットを打てるか、守れるかと言われるとあまりできないですよね?

従って、受講を終了したばかりの状態では現場でデザイナーとしてすぐ活躍するのは難しいというのが本音です。

では、受講完了してから何を行えばいいのか?次項でそれを解説します。

受講完了してからの活動について

「なんでもいいからデザインを続けること」と「当たって砕けろ精神で採用活動/案件獲得に動く」です。

1つ目に関しては、個人制作でもいいのでデザインをどんどん作っていくこと。

これが一番大事で、作れば作るほどいろんな発見ができるので、どんどん理解も深まりますし、作業効率も上がっていきます。

例えば自身のポートフォリオサイトや名刺を作ってみたり、既存サイトのトレースやコーディングをやってみましょう。

2つ目に関しては、先ほど「現場でデザイナーとしてすぐ活躍するのは難しい」とは言いましたが、それでも採用活動/案件獲得のために尽力しましょう。

デザインの現場は基本的に常に人手不足ですので、猫の手も借りたいような状況の会社がもしあれば経験が浅くても依頼をしてくれたり採用してくれるところもあるかもしれません。

経験が浅いため報酬は安い可能性が高いですが、それでも実際の案件をこなすという経験は大事です。

採用を狙うのであれば一般的な会社だけでなくデザイン事務所やベンチャー企業などを探して応募してみましょう。副業なのであればクラウドワークスやランサーズなどで掲載されている案件にどんどん応募しましょう。

どのくらいで一人前のWebデザイナーになれるのか

結論として完全未経験からデザイナーとして採用される/案件を安定的に獲得できるようになるまでどのくらいかかるか。

私は早くて6ヶ月、長くて1年だと考えています。

学習ペースによりますが、学習にフルコミットできるのであれば、前述のスクールにおいては3ヶ月コースで習得が可能です。（もし本業の傍らで無理なく進めるのであれば4ヶ月コースとなります。）

加えて、転職活動/案件獲得活動に関しては最初の方は撃沈することが多いでしょう。ここは不確定ではありますが、デザイン活動を続けつつ熱意を持って挑めば、おそらく4-6ヶ月もあれば何かしらの機会は訪れる可能性は高いです。

それらを総合すると、現場でWebデザイナーとして働ける環境になるのが6ヶ月〜1年ほどとなるはずです。

上記を目安として、デザイナーとして継続的に頑張れる覚悟があるかを考慮した上でスクール受講や副業化のご判断をしていただければと思います。

ちなみに私は大学を卒業してから入ったデザイン事務所で、初めてWebデザインに触れ（というか無茶振りされ）最初の1ヶ月でなんとか案件のサイトを作成しました。その後勉強と事務所に入ってくる案件をこなしつつ、営業して案件を獲得できるようになったのは約6ヶ月ほど経った頃でした。

現役デザイナーとしてデザインで稼ぐためのアドバイス

最後に、10年以上かけてデザイン事務所やベンチャー企業で働き、デザイナー採用担当としても活動した経験のある私からのアドバイスです。

1.最初は大変やけどめちゃくちゃ楽しいから頑張ろう

デザイナーをはじめとしたクリエイティブ職（イラストレーターやエンジニアなどもそうです）は、営業などと違いもたらす利益を数値化しにくい職種です。それが故に報酬も足元を見られがちですし、いいものを作るために時間がかかるのに対し納期があるので大変なことも多いです。

ただ、自分の作ったデザインが世に出るのは、他では味わえない楽しさです。なので私も10年以上デザインを生業として続けることができています。

ぜひできる限り多くの方にこの楽しさを味わってほしいと考えています。

2.熱意があれば、なんでもできる

デザイナーとして採用/案件獲得するのに一番大事なのは実績やスキルより熱意が一番大事だと思っています。

継続してデザイナー活動を行うモチベーションも然りですし、仮に実力が多少足りなかったとしても熱意があれば吸収が早いので、すぐに現場で活躍できるようになります。

私が前職で採用担当をしていた際、とある傘ブランドのECサイト運用担当としてバナーやサイト小改善を行っていた女性が応募してきました。

前職はWebサービスを開発・運営していたベンチャー企業で即戦力のデザイナー（つまりサービスデザイン経験者）を求めていたので、採用要件的には足りなく書類だけで見ると不採用になるのですが、面談を行った際に熱意が非常に高かったので成長期待を込めて採用しました。（社長もそういう人が好きでした）

私の予想通り入社してからメキメキ成長し、1年もかからない内に最前線として活躍するデザイナーになり、結果として大成功となりました。

このように、大手などかっちりした会社であればどうしても書類で落ちがちですが、中小やベンチャー、デザイン事務所などであればこういったチャレンジの機会も存在します。こういったチャンスを掴むために、継続と熱意が一番大事だと私は考えております。

まとめ

非常に長い記事となってしまいましたが、ここまで読んでくださりありがとうございました。

副業でも本業でも、今後デザインをやってみたい方やデザインに興味のある方に少しでも参考になれば幸いです。

デザインに限らず、どんなジャンルにおいても新しく何かを始めるには相応の熱意と努力が必要です。ただ、その中でもデザインはあらゆる業態で必要とされる技術で需要もあり、何より楽しいのでぜひ前向きな姿勢で頑張ってください。

【ノンデザイナー向け】レイアウト・構図を美しくする3つのコツ

こんにちは!株式会社インゲージの水谷です。

みなさま資料を作ったり写真を撮ったりする際に、構図やレイアウトに困ったもしくはうまくできないと思った経験はございませんか?

実は少しのコツで、誰でも綺麗なレイアウトを実現することができるのです!

今回は私をはじめデザイナーが常に意識しているレイアウト・構図のコツをお話ししますので、ぜひ参考にしてみてください!

1.黄金比

黄金比に関しては、名前はみなさん聞いたことがあるかもしれませんね。

調べてもよく以下のような図形が出てきて「よくわからない」ってなってしまう人も多いはずです。

黄金比は端的に言うと「1:1.618の比率」です。

一般的な名詞の縦横比がこの比率に該当しますね。

このバランスでレイアウトを決めるだけで、しっくりくるレイアウトを作ることができます。

では、実例を挙げてみましょう。

こちらはインゲージの名刺です。

こちらの左側のロゴの部分と、右側の情報部分の比率には黄金比を使用しております。

シンプルなデザインではありますが、このようにレイアウトを工夫することで綺麗なデザインにすることができます。

2.白銀比

白銀比は、別名「大和比」とも呼ばれる日本人が綺麗と感じる比率です。

「1:1.414」の比率で、私たちが普段からよく見るA4コピー用紙などの紙の縦横比が該当します。

事例を挙げると、東京スカイツリーや法隆寺など、日本の建築に反映されていることが多いですね。

引用元：https://www.fourglobe.co.jp/blog/p-83050

3.3分割法

3分割法とは、縦横3分割した線や交点に合わせレイアウトすることですね。

実際に図で見た方がわかりやすいかと思います。

この様に、赤い点の部分にメインの被写体や目立たせたいものをおくことで、自然と綺麗なレイアウトに見えるのです。

こちらは私も写真を撮る時などに特に意識しています。

まとめ

これらの技術は少し意識するだけで誰でも扱え、今後の業務の手助けになると思いますので、ぜひ覚えておいていただけると幸いです!

ここで挙げた以外にも様々な比率や図形、法則があったりしますので、機会があればそちらもお話しできればと思います。

段階的にスクラムを導入していく

どうも、@shutooike です！

現在、社内にスクラム経験者が（僕含めて）全くいない中で、自チームにスクラムを段階的に導入しています。

全員未経験のスクラム導入戦略、なぜスクラムを導入するのか、導入にあたって困ったことなどを複数回に渡って書ければと思います。

ざっくりスクラムとは？

"スプリント内で5つのイベント（スプリントプランニング・デイリースクラム・スプリントレビュー・レトロスペクティブ・リファインメント）を行いながら、チームでスプリントゴールを達成する"

というのが凄いざっくりとしたスクラムの説明です。 *1

詳しくはググるか スクラムガイド や SCRUM BOOT CAMP THE BOOK【増補改訂版】 を読んでください。

まずはスプリントを決める

スクラムではスプリントという決められた期間（タイムボックス）を作ります。

Re:lation は週に1回リリースしており、チームもそのリズムに慣れているのでスプリントは1週間にしました。 *2

レトロスペクティブ（ふりかえり）だけ始める

「さて、スプリントは決まったぞ。次は最初のイベント、スプリントプランニングだ！！！」と昂る気持ちを抑えて、まずはレトロスペクティブだけ始めてみることにしました。

5つのイベントの中でレトロスペクティブが一番やることのイメージが出来て、手軽に始められそうだったからです。スモールスタート大事。

ちなみに提案するときにチームに

「週に1回レトロスペクティブをやりましょう！」

といってもあまり伝わらない気がしたので

「週に1回ふりかえりをやりましょう！」

と言いました。

ふりかえりはコスパ最強

ふりかえりはみんな大好き KPT（Keep, Problem, Try）を使って行っています。

チームのみんなで出した KPT *3 を眺めていると、

👨‍💻「この取り組みは良かったので続けていきましょう！」

🙍‍♂️「これは上手くいかなかったですね...」

💁「こうしていたら上手くいったかも？」

🙋‍♀️「じゃあ来週はこんな取り組みをしてみましょうか！」

という会話が自然と出てきます。

とりあえず決まった時間に集まってふりかえりを行うだけで、

• カイゼンのループが回る
• 経験が蓄積されチームとして強くなっていく
• チーム状況を定点観測できる

などの効果が得られるのでコスパ最強です。

さいごに

正直、導入を進めている僕もスクラムについてわからないところ、腑に落ちていないところがまだまだあります。

原理主義、完璧主義に陥らず、わからないなりにやってみる。

上手くいかなかった部分はふりかえりでカイゼンしたり辞めたらいいやというスクラム導入自体をふりかえっていくスタイルでこれからも模索していきます。

ということで、インゲージではスクラム経験がある方を大募集してます！教えてください！！！

ingage.co.jp

ではまた！

*1:ロールや成果物など色々端折ってます。

*2:スクラムに慣れるまではスプリントを短くしたほうがいいという意見をよく見ます。3日とかでやることもあるみたいです。

*3:最初はふりかえり前に各自KPTを書いて来てもらうよう依頼しましたが、浸透しなかったのでふりかえりの最初に書く時間を取るようにしました。

docker compose run で個別に立ち上げたコンテナを restart で再起動させない方法

どうも、にしむらです。

最近になって開発環境のcomposeコマンドをdocker-composeからdocker composeに変更したのですが、挙動が異なる事があります。