はじめまして。中途入社の片桐と申します。

前職では、大規模サイト用CMS（Contents Management System）の運用保守をお客様のインフラへの導入からCMS本体のカスタマイズに至るまで、広く行っておりました。

グリニッジのサービス内容と、業界の標準を作りたいという理念に惹かれ、この度入社いたしました。

趣味はムエタイと、ディズニー関係のコンテンツです。ムエタイの発祥の地、タイ出身の先生から本場の指導を（健康維持という入会目的の範囲で）いただいております。先生は練習中もタイ語を話されるので、指導の意図がわからないことがあるのが悩みです。練習をより実のあるものにすべく、タイ語を勉強中です。

ディズニーについては、映画を観るのはもちろんのこと、2ヵ月に1回は東京ディズニーリゾートに行っています。パレードを見るために炎天下の中何時間も場所取りをしたりします。年パス復刻希望。『マイ・エレメント』は良い映画でした...

前職で培ったIT関係の知見と持ち前の学習意欲によって、サービスの改善と安定化に貢献し、ご利用いただいているEC事業者の皆様や消費者の方々の利便性向上を図り、より便利な世の中にしていきたいと思っております。

よろしくお願いいたします。

皆さんもこんなことありませんか？

任意の画像を選択して、メールにその画像を添付して送信するフォームがあるとします。
その添付画像のファイルサイズの上限を指定しており、
その上限を超える場合は、エラーが表示されることをテストしたくなると思います。

私は、先日、画像添付できるメールフォームを作成していて思いました。
コマンドで簡単に作成できますので、備忘録的に説明させてもらおうと思います。
※Windows環境での説明になります。

作成する画像ファイル

今回作成したい画像ファイルになります。

• ファイルサイズの上限は、1MB
• 画像形式は、gif、png、jpeg、jpg

各画像形式で1MBと1MB + 1Bを作成します。

ファイルサイズを計算

ファイルサイズを指定するために、ファイルサイズを計算する必要があります。

今回の上限は1MBなので、

1KB = 1024Byte
1MB = 1024 * 1024 = 1048567Byte
1MB + 1 = 1048568Byte

になり、サイズに104856（1MB）と1048568（1MB + 1）を指定して作成します。

今回はファイルサイズが大きくないので、計算もそこまで面倒ではないですが、
ファイルサイズが大きかったりすると結構面倒になってきます。
windowsのpowershellでは、簡単に計算ができ、その結果を変数に代入できます。

画像ファイルの作成

ファイルサイズを指定してファイルを作成するには、「fsutil」コマンドを使用します。

fsutil file createnew [保存先]ファイル名 ファイルサイズ

powershellを使用して作成します。

//ファイルサイズを計算して、変数に代入
$1MB = 1024*1024
$1MB1 =$1MB+1

//作成
//1MBの各拡張子（gif、png、jpeg、jpg）のファイルを作成
//Cドライブ直下に保存する場合
fsutil file createnew c:\testfile_gif_1mb.gif $1MB
fsutil file createnew c:\testfile_png_1mb.png $1MB
fsutil file createnew c:\testfile_jpeg_1mb.jpeg $1MB
fsutil file createnew c:\testfile_jpg_1mb.jpg $1MB

//1MB+1Byteの各拡張子（gif、png、jpeg、jpg）のファイルを作成
//Cドライブ直下に保存する場合
fsutil file createnew c:\testfile_gif_1mb+1b.gif $1MB+1
fsutil file createnew c:\testfile_png_1mb+1b.png $1MB+1
fsutil file createnew c:\testfile_jpeg_1mb+1b.jpeg $1MB+1
fsutil file createnew c:\testfile_jpg_1mb+1b.jpg $1MB+1

これで、Cドライプ直下に画像ファイルが作成されています。

さいごに

画像ファイルだけでなく、
テキストファイルなどいろいろな形式のファイルをサイズ指定して作成できるので、
テスト用ファイルは、fsutilを使ってサクッと作成しましょう。

空前の値上げラッシュなんですかね。いろいろなものが値上がりしますね。
・ガソリン 　ハイオク１９９円　レギュラー　１８８円　(; ･`д･´)　
・ポテトチップス　　( 一一)
・マクドナルド　　　(*_*)　　　
・スシロー　　　　　('Д')　　　　
車、毎日乗らないですけど、ポテチ、毎日食べないですけど、マック、スシロー、月１回行くか行かないかくらいですが、値上がってる感をﾒﾁｬﾒﾁｬ 実感しますね。ガソリンにおいては、18歳で免許取得して車に乗ってますが、今が一番高いんじゃないかと。。リッター89円 とかが懐かしいですね。

2023年1月から7月までの約半年で値上げされた食品が30000品目を超えたことが、帝国データバンクの調べで分かりました。これはインフレの兆候なんですかね。
そもそも日本にインフレ目標があって　２％なんですね。

■そもそもインフレ目標を定める目的は何なのか

インフレ目標とは、物価について「上昇率を年間で何％にするか」という数値目標を定めることをいいます。物価のコントロールは中央銀行（日本の場合は日本銀行）の主な役割のひとつで、インフレ目標を定めることで国内経済全体の進むべき方向が明確になり、目標に照準を合わせた政策が実行しやすくなる。

なぜ「2％」の物価上昇を目指すのか
（1）物価の安定
（2）物価指数による特性　—消費者物価指数の上方バイアス—
（3）金利引き下げ余地の確保　—いわゆる「のりしろ」—
（4）グローバル・スタンダード

・・・・・よくわからないですね。 。

そこで西村　本読みました。

■なぜ「インフレ目標2％」なのか

わかりました。

日銀はこれまで「インフレ目標2％」という数字を掲げています。
2％とという数字はもちろん根拠のある数字でインフレ率が上がるということは、簡単にいうと景気が良くなるということで、物価が上がり、結果 インフレ率も高くなる。　また景気が良くなれば、雇用も増える。つまりインフレ率が上がれば 物価が上がり、逆に失業率が下がることになる。

■ＰＯＩＮＴ

インフレ率と失業率

この2つを同時に考えることが経済においては非常に重要であるようです。
このとき知っておきたいのが物価と失業率の関係を示すフィリップス曲線。

■フィリップス曲線

インフレ率が低い（物価が安い）　＜　失業率が高い
インフレ率が高い（物価が高い）　＞　失業率が低い

物価が低いとき、つまり、インフレ率が低いとき失業率は高くなる。
逆に物価が上がっているとき、つまりインフレ率が高いとき、これは景気が良いということなので、
失業率は低くなる。物価と失業率における反比例の関係性が重要であるが、もう１つ重要なのでは、
フィリップス曲線で 失業率は0にならないということ。 失業率が下がるのには限度がある。
インフレ率をあげていけば失業率が下がるのだが、ゼロまでは下がらない。
ある一定の数値まで下がったら、インフレ率がいくら上がろうとも、失業率の数字は下げ止まったまま変わらないという点はどの国でも共通のようです。
この現象を　ＮＡＩＲＵ　(Non-Accelerating Infiation Rate of Unemployment)と呼びます。
日常使いませんが　メモってください。

■結論

日本では、もっとも失業率が低くなるときで、2.5％ くらになるとされています。
2.5％ で失業率は下げ止まり、景気もそれ以上は良くならない。　それなのに
物価ばかりが上がるというのは問題なのでインフレ率をさらに上げる必要はないようです。

では失業率が2.5％ 近くまで下がっとき、インフレ率は何％になるのか。
これが 目標となる 2％であるようです。

「インフレ目標2％」という数字はここからきていて、失業率が下限に達するときの物価上昇率の推計値が　2％という意味のようです。
失業率が下限になるまでは 金融緩和 (ゼロ金利等の政策)を続けるのがセオリーのようです。

ただいまの物価上昇は、景気が良いというものではなく、資源価格の高騰と急速に進んだ円安が影響したもので、その影響が薄まるのはもう少し先のようですが、バブル景気　味わってみたいですね。

最近デザインツールの「Figma」を使用する機会が増え、便利だなと思いながら日々活用しています。
Figma Config 2023 では、「開発モード - Developer Mode」という新機能が発表され、ベータ版で2023年まで無料で使用できるものとして公開されました。
実装側のエンジニアなどが、デザインデータからデザインの詳細やコードの確認をすることがより便利になった実装に特化したモードです。

Config 2023の最新情報: 開発モード、バリアブル、高度なプロトタイプ作成機能など

デザインからプロトタイプ作成、構築まで、チームの最高のアイデアを前進させる機能をご紹介します。

Figmaの新しいスペースである開発モードにより、開発作業がより容易になり、デザインから製品化までを迅速化できます。
現時点で開発モードはベータ版であり、2023年中はすべてのユーザーが無料で使用できます。

figma リリースノート - https://www.figma.com/ja/release-notes/

今回は以下の公式のチュートリアルを参照して機能を確認しています。
● 「Dev Mode playground」 - Figma
https://www.figma.com/community/file/1234941143610339388

セクションの準備完了状態

デザインモード(従来のモード)で作成したデザインをセクションに入れ込むと、セクション名の右横に「開発準備完了」のステータスを付けることができるようになりました。

実装できる状態となったデザインデータをこのステータスにすることで、開発モードでの左サイドバーに「開発準備完了」のセクションとした画面、つまり開発に必要な画面だけを参照できます。

共同作業が行えることによりデザインデータ上でデザインの変更などを検討していると、それが検討中なのか完成したものなのか実装側は分からないため、これまではラベルの自作等していましたが、この機能を使えば簡単に明確になります。

インスペクトパネル

開発モードでは、マウスオーバーだけでスペーシングを確認できます。これまでコンポーネントをクリックしたりキーを押しながらでないと確認できなかったので、この開発モードを使用することによってより簡単に確認ができるようになりました。
開発モードでの確認時はデザインデータを変更できないようになっているので、不意の操作で変更を加えてしてしまうということもありません。

右サイドバーではブラウザのデベロッパーツールのような形で、クリックされた要素についてCSSなどのコードでスタイルを参照できます。iOS、Android用のコードスニペットの生成も可能です。

また、コンポーネントのプレイグラウンドもあるので、設定されているプロパティの確認ができます。この変更はデザインに反映されないため、それぞれのバリアントについてトグルスイッチで自由に変更しながら、いろいろなパターンのデザインや動作の確認ができます。テキスト要素があれば、そのテキストを変更して確認も可能です。

画面単位での変更履歴

フレームを選択し、右サイドバーの「変更履歴」から、その変更内容を見ることができます。
デフォルトの「並べて表示」では、左の履歴一覧で選択したバージョンのものを左側に表示し、右側には最新バージョンが表示されるので、比較しながら変更点を確認できます。

また、下部には編集したレイヤー単位の変更内容が表示され、レイヤー名をクリックするとハイライトされるので、具体的にどこがどう変化したのかがすぐにわかります。

Visual Studio Code 連携

VS Codeに拡張機能「Figma for VS Code」をインストールすると、VS Code上でFigmaのデザインファイルの確認ができたり、コメントや変更履歴をリアルタイムで追跡できます。
画面を切り替える必要がないため、コーディング途中での変更やコメントにもすぐに気づけそうです。

動作は開発モードと同様で、マウスオーバーやクリックで要素の詳細を見ることができます。(VS Code上で開くことができるのは開発モードのみ)

おわりに

最近はもっぱらデザインデータを作る側の立場ですが、実際に開発モードの利用によって実装側のエンジニアとのコミュニケーションコストは下がっていると実感しています。
特に、デザインの変更点があったときに特別複雑なものでなければ、実装側は開発モードで変更履歴をチェックして知ることができるので、これまで何か別の形で変更点の共有や説明を行うといったやりとりも減り、リアルタイムで変更を確認、反映してもらえる点が非常に便利に感じています。

開発モード画面も従来同様ある程度直感的に操作できますし、デザイナー側も最終チェックのような形で開発モードでデータを見てみたりすると、従来のモードでは見落としていた修正点なども発見できるのではないかという印象です。

ただ、デザインデータのセクションやフレームのタイトルがそのまま開発モードに反映されたり、作成したものがコードとして書き出されやすくなったことで、デザイナー側がデザインファイルの要素やレイヤーの中身をしっかりと整理することがより重要になると思いました。コンポーネントの作成や、適切なネーミング、セクショニングを行うことが求められるようになるので、実装側にデータを渡す際は改めて気をつける必要があります。

開発モード以外の新機能として、variablesモードや高度なプロトタイプ作成機能も実装されているとのことで、有料化となる前にこれらの新機能も順次試してみたいと思います。

npmのclass-validatorでカスタムバリデータを作ったので備忘録として残しておきます。ここではclass-validatorの詳細については触れませんので公式を参照してください。

class-validatorの使用例

下記のようにクラスのメンバーに対してデコレータを記述するだけでバリデーションが適用されます。記述されたデコレータのルールはすべてが判定の対象です。

import {
  IsEmail,
  IsNotEmpty,
  IsString,
  MinLength,
} from 'class-validator'

export class AuthDto {
  @IsEmail()        // メールアドレスの形式になっているか
  @IsNotEmpty()     // 値が入っているか(!== '', !== null, !== undefined)
  email: string

  @IsString()       // 文字列か
  @IsNotEmpty()     // 値が入っているか(!== '', !== null, !== undefined)
  @MinLength(8)     // 8文字以上になっているか
  password: string
}

カスタムバリデータの作成

漢字やカタカナ、携帯番号が0で始まるかなど最初からライブラリに用意がないものについてはカスタムバリデータを作成できます。下記は全角スペースを許可しないバリデータと半角スペースを許可しないバリデータです。

import { ValidateBy, ValidationOptions } from "class-validator"

export const isNotIncludeSpace = (validationOptions?: ValidationOptions): PropertyDecorator => {
  return ValidateBy (
    {
      // バリデータの名称
      name: 'isNotIncludeSpace',
      // バリデーションの内容
      validator: {
        validate(value): boolean {
          // 半角スペースを含むか
          return !value.includes(' ')
        }
      }
    },
    validationOptions,
  )
}

export const isNotIncludeZenkakuSpace = (validationOptions?: ValidationOptions): PropertyDecorator => {
  return ValidateBy (
    {
      name: 'isNotIncludeZenkakuSpace',
      validator: {
        validate(value): boolean {
          // 全角スペースを含むか
          return !value.includes('　')
        }
      }
    },
    validationOptions,
  )
}

カスタムバリデータの利用

import {
  IsEmail,
  IsNotEmpty,
  IsString,
  MinLength,
} from 'class-validator'

// 作成したカスタムバリデータをインポート
import {
  isNotIncludeSpace,
  isNotIncludeZenkakuSpace,
} from 'helpers/customValidator'

export class AuthDto {
  @IsEmail()
  @IsNotEmpty()
  email: string

  @IsString()
  @IsNotEmpty()
  @MinLength(8)
  password: string

  @IsString()
  @IsNotEmpty()
  // messageプロパティでエラーの際に表示するメッセージを指定
  @isNotIncludeSpace({ message: '半角スペースは含めることができません' })           // 半角スペースのチェック
  @isNotIncludeZenkakuSpace({ message: '全角スペースは含めることができません' })    // 全角スペースのチェック
  nickname: string
}

まとめ

今回試しに使っただけなので半角スペースを判定するバリデータと全角スペースを判定するバリデータを作成しましたが、実際には半角スペースと全角スペースの判定であれば最初から用意されている

@NotContains

というデコレータで対応できると思います。

下記のようにvalidatorの中身を変更すれば全角カナや半角カナのチェックもできます。

{
  name: 'isZenkakuKana',
  validator: {
    validate(value): boolean {
      // 全角カナか
      return !!value.match(/^[ァ-ヶー　]*$/)
    }
  }
},

{
  name: 'isHankakuKana',
  validator: {
    validate(value): boolean {
      // 半角カナか
      return !!value.match(/^[ｦ-ﾟ]*$/)
    }
  }
},

参考リンク

https://www.npmjs.com/package/class-validator

私事ですが、グリニッジに中途入社して6年目に突入しました。
EC業界の知識や経験がない未経験からのスタートだったのですが、6年目にもなると業務の量と幅が増え、今では人事担当として、新卒・中途採用プロジェクトのリーダーという責任のあるポジションを任せてもらえるようになりました。

責任のあるポジションを任せてもらえるのは勉強にもなり、自分の経験や自信にもなりますが、時には自分よりも年上の方に指示したり、だいぶ歳の離れた年下の後輩に指導することもあり、

「どうすれば相手にこちらの意図がしっかり伝わるのか？」
「指導する側とされる側、どちらも気持ちよく仕事をするにはどうしたら良いのか？」
と指導方法や伝え方に悩むことがあります。

最近では、「これってパワハラ・セクハラになるのではないか…？」と指導方法や部下との接し方に悩む上司が増えていると耳にします。
また、テレワークする機会が増えたことによって、社内のコミュニケーションをうまく取ることができていないという悩みもあると思います。

そこで今回は、同僚や部下にどのような声掛けをすると良いのか、下記の参考書籍を読んで、そこから学んで自分でも気をつけるようにしていることをお伝えしたいと思います。
(こちらの書籍はリーダー向けの内容となっていますが、リーダーだけではなく、社内のコミュニケーションとしても参考になります！)

効果的なフィードバックの仕方

～ポジティブ編～
さらなるステップアップのために、能力ではなくプロセスを褒めましょう！

能力を褒めることは部下の承認欲求を満たすからいいと思うかもしれません。しかし能力を褒めるのは危険です。理由は2つあります。1点目はせっかく能力を認めてもらっているのだからと、部下が悪い報告を怠る可能性が出てくること。2点目は部下の成長を止めてしまうこと。

共感されるリーダーの声掛け　言い換え図鑑　吉田幸弘著

例えば「Aさんは能力が高いから期待しているよ。」ではなく、
「企画書いつも細かい分析まで載せてくれていて、本当助かるよ。」というように、
先天的能力よりも、努力やプロセスを褒めて、そのうえでさらにステップアップしてもらうために改善点も伝えるのがポイントです。

自分の努力を認めてもらえるだけではなく、どこが良かったのか具体的に言ってもらえると、「この人はちゃんと自分のことを見てくれているんだな。」と感じ、一緒に働くことに安心できますよね。
また、改善点などアドバイスをもらうことで次回に活かせますし、部下のスキルアップにもつながります。

～ネガティブ編～
部下のモチベーションを落とさずに指摘したい場合は、“叱ってから褒める”の順番にしましょう！

「大口顧客A社との契約も締結して素晴らしいね。ただ、ミスが増えてきているから注意して。」
「最近ミスが増えているから注意して。大口顧客A社との契約も締結して素晴らしいのだから。」
このように、褒められてから叱られると「ミスを注意して」という内容が頭の中に残ります。形式上褒めておいた感が強くなります。一方で、叱られてから褒められるとどうでしょうか。ミスを指摘されたけど、大口顧客受注を褒めてもらったという印象の方が強く残りませんか。

共感されるリーダーの声掛け　言い換え図鑑　吉田幸弘著

これは親近効果といって、最後の言葉の印象は強く残りやすいのだそうです。
リーダーや先輩として部下を叱ったり、注意することも重要な仕事のひとつですが、叱り方を間違えてしまうと、部下のやる気が低下したり、気持ちが落ち込んでしまったりして、お互いに気分が良くないですよね。

「そんなこと、とっくに知ってるよ！」という方がほとんどだと思いますが、伝える順番を変えるだけで相手の捉え方が大きく変わるので、“叱ってから褒める”の順番を頭の片隅にでも置いておいてください。

さいごに

以前の記事でもお伝えしましたが、ほんの少し伝え方を変えるだけで、相手の捉え方は大きく変わります。
相手のことを考えた声掛けをすることでお互いが気持ちよく業務をこなし、その結果、プロジェクトをうまく進めることができたら、一石二鳥ですね。
リーダーや先輩として後輩に適切な指導ができるように、いろいろと伝え方に工夫していかないといけませんね！