バージョン管理システム"Git"はじめの一歩【後編】

さて、それでは後編です。前編では、gitの基本的な部分について説明いたしましたね。commit、push、pull、clone・・・それぞれ違いは理解できましたか？

後編では、ブランチについて説明し、最後に例を出して理解を深めます。

ブランチという考え

gitにはブランチといわれる機能が備わっています。そのブランチとは何なのか、何のためにあるのかを説明していきます。

ブランチとは更新履歴の流れを分岐して記録することができる機能です。

複数人で作業している場合、Aさんは新機能の追加、Bさんはバグ修正・・・という風に担当が決まっているものです。

そういったときにみんなが毎回毎回すでに稼働が確認されているリリース版で作業を行うと、バグが起きたときに大変です。
修正するのに時間がかかってしまいますし、なによりリリース版が一旦停止してしまうというとんでもない事態になりかねません。

そこで、リリース版以外にも（木の枝のように）ブランチを作成し、分岐して作業を行います。

ブランチには2種類のブランチがあります。統合ブランチとトピックブランチです。

統合ブランチ

統合ブランチは「いつでも動作ができる、実行できる」状態にしておくブランチです。先ほどの説明で言いますと、リリース版です。
このブランチは1人1人の作業が終了したものがマージされてきます。
このブランチでバグが起きることはないようにしなくてはなりません。

基本的に動作の確認ができたもののみがマージされます。
作業途中のものや、まだバグが取り除かれていないものはマージされません。

トピックブランチ

トピックブランチは担当者だけが使うブランチです。
追加機能班なら、追加機能ブランチを作成し、それにどんどん変更履歴を保存していきます。バグ修正班なら、バグ修正ブランチを作成し、それに変更履歴を保存していきます。

このトピックブランチは、細かな編集をするときに利用されることが多いので、動作が確認できなくても大丈夫です。

トピックブランチのトピックが完了次第、統合ブランチに統合していきます。
バグ修正が完全に完了したら、統合ブランチに統合しましょう。もちろん正しく動くかどうかは確認が必要です。

ブランチの切り替え(checkout操作)

ブランチとは木の枝のようにそれぞれの用途に合わせて作成し、それぞれの変更履歴を保存していくという機能でした。

ここで、例えばAさんはとても優秀な人で、機能追加とバグ修正の２つを担当しているとしましょう。

Aさんは「バグ修正が完了したので、機能追加に取り掛かろう」となるわけです。しかし、自分のローカルリポジトリにはバグ修正が完了した状態のディレクトリなので、このディレクトリ上で機能追加を行ってはいけません。なぜなら、Aさんは今“バグ修正”のブランチにいるのです。

そこでAさんは「機能追加のブランチに行かなくちゃ」となります。
ブランチを切り替える操作はcheckout操作です。

またまた図の中に新たな言葉が出てたので説明します。

HEAD

gitの世界でHEADは「今いるブランチの最新の場所」を意味します。
今回の場合Aさんはバグ修正が完了したところなので、HEADはバグ修正ブランチの先頭にいます。

以上の説明、いかがでしょうか。
なんとなく、gitの使い方がみえてきたのではないでしょうか？
逆に、まだ曖昧な部分がある気がすると思った方もいるかもしれません。

最後に、mergeとブランチ、追加でrebaseについて例を出して説明し、理解を深めてもらえればと思います。
今までの復習と思って見てください。

例を出して理解を深める

さて、あなたは今、下図のAさんとします。
Aさんはtopic-branchの先頭(HEAD)にいます。

Aさんは自分の作業が完了し、masterブランチ(以下master)へのマージを試みています。
しかし、masterにいきなりmergeをしたら、コンフリクトが発生してしまうかもしれません。

そこでAさんは一旦topic-branchにmasterの変更履歴をmergeしようと考えました。

ここで行うのがmerge操作でしたね。（コマンドは git merge master(コマンドって何？って人は気にしないで大丈夫です。)）

さあ！Aさんはmerge操作が完了し、コンフリクトも解消できました。いよいよ、Aさんはmasterにmerge操作を行うことができます。
しかし、Aさんはまだtopic-branchにいるので、このままではmasterにtopic-branchの変更履歴をmergeすることができません。

Aさんはmasterへとブランチを切り替える必要があります。

ここで行われるのがcheckout操作です。(コマンドはgit checkout master)

ようやくこれでAさんはmasterに移動することができました。
それではtopic-branchをmasterにmergeしましょう。

以上でmasterにtopic-branchをmergeすることができました！！

続いて、発展編「rebase操作」です。
これまで説明していないので、いきなり理解するのは難しいかもしれません。

最初の状態は先ほどと一緒です。

Aさんはmasterにtopic-branchをマージしたいので、rebaseしようと考えました。

rebase操作をするとどうなるのか？
下記のようになります。

なんと、ブランチが生える場所が変わってしまうのです！
こうすることで、mergeとほぼ同様の「masterの変更履歴の内容をtopic-branchに取り込む」ということができます。
もちろんコンフリクトは発生する可能性があるので、そちらは解消してあげましょう。

あとは、同じ操作です。masterにmergeするには、一度masterに移動する必要（checkout）があります。

最後にmerge操作です。

終わりに

以上でgitの概要（内容？）の説明は終わりました。
最後には例を挙げて説明したので、理解しやすかったのではないでしょうか？

もちろん、今回の内容でgitのすべてを解説できたわけではありません。
もっと様々なコマンド（fetch操作など）があり、解説しだすとキリがありません。
ここからは自分で調べて、詳しくなっていってほしいと思います。
私もまだまだ知らない部分が多いので知識をつけていきたいです。

バージョン管理システム"Git"はじめの一歩【前編】

はじめに

皆さんにもこんな経験が1度はあると思います。

git_01

チームで何かを作り上げる時にどうしても発生してしまう問題。
最新のファイルがどれか分からなかったり、変更箇所が重なったり・・・

そういう問題を解決するシステムが「バージョン管理システム」です！

Gitとは？- 何ができるようになるのか

gitとはバージョン管理システムのことです。下記の図のようなことができるようになります。

git_02

ファイルの更新履歴の保存

gitではファイルを更新した記録を行うことができます。
この「記録」には、ファイルの中身のどこが更新されたかだけでなく、

• 誰が追加したのか。
• いつ変更したのか。
• どこが更新されたのか。
• 新たに追加したファイルはどれか。

など、詳細な情報が記録されるので、トラブルが起きにくくなります。

前の状態に戻す

gitではファイルの更新を記録するだけでなく、なんと前の状態に戻すことができます。
最新のファイルのプログラムでなにかバグが発生していた場合に、「とりあえず動く状態に戻そう！」ということができるわけです。
その後、時間をかけて変更された箇所を見ていけば、何がバグの原因となっているか特定することができるでしょう。

編集箇所の差分を表示

今の状態って前の状態からどこが変更されてるんだっけ？と、多くの箇所を修正していると、全ての変更箇所を頭の中に入れておくことは難しいです。
そんな時には、前の状態との差分（違い）を一目で分かりやすく表示してくれる機能があります。

上書き時に警告

チームで開発しているときに、Aさんが変更た箇所をBさんも変更した場合「変更箇所かぶってますよ！どっちが正しいものですか？」と警告を出してくれます。

---

いかかでしょう。Gitの魅力が伝わりましたか？
上記の4つの機能だけでなく、深く知ればもっと様々なことができるようになります。

前提知識

下記の図を見てください。

たくさん知らない単語が出てきましたね。
1つずつ解説していきます。

ディレクトリ

ディレクトリとは簡単にいうとフォルダという認識でOKです。フォルダの中には写真だったり、動画だったり、論文だったり、多くのファイルがあります。
ここでは、「ディレクトリ（フォルダ）」と「ファイル」の違いがわかっていれば問題ありません。
「ディレクトリの中にいくつかのファイルが入っている」という説明が理解できたら、次に進みましょう。

リポジトリ

リポジトリとはディレクトリの状態を記録する場所です。
このリポジトリという場所に、ディレクトリ内の変更された箇所が保存されていきます。
リポジトリにはローカルリポジトリとリモートリポジトリの2種類があります。

ローカルリポジトリ

ローカルリポジトリとは言葉の通り、ローカルなエリアにあるリポジトリです。
つまり、自分のPC内に保存されます。

リモートリポジトリ

リモートリポジトリは、自分のPCではなく、サーバーなどの遠くにあるリポジトリです。（サーバーって何？って人はひとまず遠い場所という認識でOK。ここで大事なことは、「自分のPC内には保存されない」ということです。）

どうして2つもあるの？

ローカルリポジトリとリモートリポジトリ、両方とりあえずディレクトリの状態（変更された箇所や、新たに追加されたファイルなどがあるか）を保存する場所なんでしょ？どうして2つも保存する場所が必要なの？リモートリポジトリって何に使うの？と思う方もいると思います。開発者が１人だけしかいない場合は、ローカルリポジトリだけでOKです。
なぜなら、変更するのも削除するのも追加するのも自分だけなんですから、他の人との作業がかぶることは無いはずです。

しかし、複数人で作業している場合、他の人と変更箇所がかぶってしまうことが起こりえます。
そんな時にリモートリポジトリの出番です！

Aさんが作業し終えた時に、Aさんはまずローカルリポジトリに変更履歴を保存します。
その後、みんなに作業報告をするためにリモートリポジトリに変更履歴をアップロードします。

また、Bさんは自分の作業を 終えた時に、同じくローカルリポジトリに変更履歴を保存します。
その後、リモートリポジトリに変更履歴をアップします。

ここで、Aさんが作業した内容とBさんが作業した内容がかぶっていた場合にリモートリポジトリは「変更箇所かぶってるけど大丈夫？」と警告をしてくれるわけです。

ローカルリポジトリは自分の変更履歴を保存する自分のPCにあるもの。
リモートリポジトリはみんなの変更履歴を保存する遠い場所にあるもの。

ということが分かればOKです。

いかかでしょうか。ちょっとした言葉の知識ですが、これを理解しておかないと、この先の説明がチンプンカンプンになるので、しっかり押さえておきましょう。
ちなみに図の「push」や「pull」はのちに説明します。

変更の記録「コミット」

いよいよgitでの操作をするために必要なことを説明します。まずはコミットです。

コミットとは作業が完了した時や、ひと段落ついた時に行う操作です。
このコミットをすることで、リポジトリに変更履歴を保存することができます。

このコミットという作業を忘れてしまうと変更履歴が保存されないので、必要な時に前の状態に戻すことができません。
必ず小まめに行いましょう！

マナーとして、１作業ごと（例えば1つのバグが治った時や、1つの機能を追加した時）に行うことを心がけてください。

また、このコミットにはもう1つ機能があります。
それは「コメント機能」です。

コミットをする場合はこのコメント機能を使う必要があります。
コミットする時に「〇〇を修正しました。バグ直ってます。」「△△機能を追加しました。」などコメントをつけます。
そうすることで、どのタイミングで何を行なったのかを誰がみても理解しやすくなります。

実際にコミットするには？

実際の操作でコミットするには1つ準備が必要です。それはコミットの前にアッド(add)してあげること。

下記の図を見てください。

ここでもたくさんの知らない単語が出てきましたね。

ワークツリー

ワークツリーとは今自分が作業しているディレクトリのことです。ディレクトリが何かは説明したので、理解していただいたと思います。

インデックス

インデックスはコミットを準備する場所です。

なぜインデックスが必要なのか説明します。
というのも「いきなりコミットすればいいじゃん？」と思う方もいると思うので・・・

インデックスが必要な理由はファイルごとにコミットしたいときに困るからです。
例えば、HTMLファイルとCSSファイルを両方変更したとします。
けど、コミットは別々にしたいって時があるんですよ。

そういう時に、まずHTMLだけインデックスにアップして、コミット。
次に、CSSだけインデックスにアップして、コミットということができます。

メリットとしては別々にコミットできるので、コメントも別々に残すことができます。

HTMLをコミットする場合は「バグ修正しました。」
CSSをコミットする場合は「新機能を追加しました。」という風に。

この「コミットを実際にするには？」では、コミットする前にアッド(add)する必要があるということを押さえておきましょう。

次はリポジトリの共有（push、pull、clone）のお話です。

リポジトリ間のやり取り

ローカルリポジトリとリモートリポジトリの違いについては先ほど説明しました。
そのリポジトリ間でどのようにやり取りをして共有をするのか説明をします。

リポジトリ間のやり取りを行う操作は3つです。

• push
• pull
• clone

順番に説明していきます。

push（ローカルリポジトリ→リモートリポジトリ）

“push”という操作はローカルで保存した変更履歴をリモートリポジトリにアップロードする操作です。

Aさんが自分のPCで変更を行い、コミットした変更履歴はローカルリポジトリに保存されています。

その変更履歴を、今度はみんなが見ることができるリモートリポジトリに保存しなくてはなりません。そうしないと、Aさんが行った変更は誰にも共有されることがなく、個人で作業しているだけということになってしまいます。

pull（リモートリポジトリ→ローカルリポジトリ）

次はpullです。

pull操作はリモートリポジトリに保存してある変更履歴をローカルリポジトリにダウンロードする操作です。

リモートリポジトリには、Aさん以外の人が変更した履歴が保存されている可能性があります。
他の人が変更した履歴をAさんのローカルリポジトリに保存したい場合、このpull操作を行います。

clone（リモートリポジトリ→新規ローカルリポジトリ）

最後に、clone操作です。

clone操作を行う場面は、例えば新しくBさんという人がプロジェクトに配属されたとなった時、BさんのPCにはまだ何もない状態ですよね。

そういったときにclone操作を行うと、リモートリポジトリのデータをそのままローカルリポジトリにダウンロードできます。

---

gitを使うためには この3つの操作（push・pull・clone） の違いは必ず説明できるようになる必要があります。

しっかり頭に入れておきましょう。

次に説明するのは衝突（コンフリクト）の回避です。
コンフリクトとは、「 変更箇所かぶってますよ！ 」状態のことです。
そういったときにどうすればよいのか、見ていきましょう！

変更履歴の統合(merge)

自分のPCで作業を続けて、「さあ！リモートリポジトリに変更履歴をアップロードするぞ」となったときにする操作は何だったか覚えていますか？

そうです、push操作です。
そのpush操作をすると、下記の図のような状態になることがあります。

リモートもローカルも変更履歴"B"までは同じ内容だったのに、ローカルで“X”という変更を行ってる間に、他の人がリモートに“C”という変更履歴を保存しちゃいました。このままpush操作を行ってしまうと、他の人が行った“C”という変更箇所がなくなってしまいます。
それは困りますよね？そこで、“merge”という操作を行います。

もちろん、この状態でpush操作を行うと、gitさんは丁寧に「リモート更新されてるけど、マージしなくて大丈夫？」と警告を出してくれますので、安心してください。

警告されれば、mergeしなくちゃぐらいの感覚で大丈夫です。
それでは、mergeするとどうなるのか説明しましょう。

merge操作を行うと、リモートの変更履歴を一旦ローカルにダウンロードできます。
ここで、「あれ？それってpull操作じゃないの？？」と思った人、いると思います。
pull操作との違いは、自分のローカルの変更履歴に追加して、リモートの変更履歴がダウンロードできることです。

pull操作はリモートでは変更履歴が保存されていて、ローカルの内容が変わってないときに行う操作です。
merge操作はリモートもローカルも内容が変更されていて、それぞれ違う履歴が保存されているときに行う操作です。

mergeした後は、ローカルの内容はリモートで更新されている内容と、ローカルで更新されている内容が両方とも反映された状態になります。

その時に発生してしまうのが、衝突（コンフリクト）です。

衝突（コンフリクト）

複数人で作業をしていて様々なファイルを編集していると、必ず誰かと同じ場所を変更してしまう可能性が出てきます。
そのような現象を衝突（コンフリクト）と呼ばれています。

コンフリクトは、先ほど説明したmergeの後にローカルリポジトリで出ます。

コンフリクトが起きると、gitは「ここが重なっている場所です！」と場所の特定まではしてくれますが、自動で修正はしてくれません。
機械にはどちらが正しい内容か理解できないので・・・

ここだけは我々人間が手作業で治すしかないのです。
コンフリクトが起きた場合は、誰と修正箇所が重なっているか確かめ、どちらが正しい内容か実際に相談して、決定し、修正を行ってください。

---

以上で、gitの基本の基本を説明しました。
個人でgitを使う場合には、ここまでの説明で十分扱うことができると思いますが、チームで開発となった場合、ブランチという考えを理解しておく必要があります。

後編では、ブランチについて説明します。
また、最後に実際に例を出して説明しますので、さらに理解を深めていきましょう！

「1枚のりんごの絵」を説明してみる

今年の夏は猛暑日が続いておりますね。
ミキサーを使ってフルーツジュース作りがマイブームな鈴木3世です。
最近は、氷×スイカのスムージーや、冷凍バナナ×牛乳のバナナミルクを作りました。
次は、桃かりんごのジュースに挑戦したいです。

さて、話は変わりますが私の部屋には「1枚のりんごの絵」があります。
どんな絵か想像してみて下さい。

あなたは何を想像しましたか？

あなたが想像したのは木に実るたくさんのりんごでしょうか？
それとも、皮付きのりんご1つ？
もしかしたら、半分に切られ種まで見えるりんごかもしれないし、皿に並ぶうさぎさんカットのりんごかもしれません。
macユーザーは、アップル社のロゴマークを思い浮かべるかも。
椎名林檎さんのファンなら、歌手本人のポスターを想像しているかもしれませんね。

誰もが知っている「りんご」というモチーフでも想像するものは十人十色です。

もっと情報がほしい！

文章で特徴を挙げてみる。

やはり「1枚のりんごの絵」だけでは情報不足です。
この絵の特徴を文章で思いつく限り、挙げてみましょう。

りんごについて

• りんごは1つ
• 皮付きりんごで切られてはいない
• 色は真っ赤だが、りんごのお尻の方と茎の周辺は少し黄緑色
• 茎は左に向かって少し曲がっている
• 葉は無い
• りんご以外に、机やナイフなどの付属品はない

絵について

• 大学時代にゼミで作成した
• 画材は岩絵具(日本画の絵具)
• 背景は銀箔のみ
• 左上の銀箔が少し剥げている
• 右下に滲んで読めない落款印(白文)が押してある
• 額縁に入れられ壁に飾られている
• 額縁は背景に合わせた銀色で、外枠は黒色

これだけ特徴があれば、イメージの修正はできたと思います(少なくとも椎名林檎さんではないことはわかると思います)。
絵についての特徴も加えたので、色鉛筆のような画材ではないこともわかると思います。

それでも、形や色味は正確には伝わりません。

百聞は一見にしかず。

こうなったら実物を見せるのがお手軽簡単。
さあ、答え合わせのお時間です！

どうでしょうか。
これなら、上記で羅列した文章を説明しなくても「1枚のりんごの絵」を簡単に共有できますよね。

イメージの共有大事！！

一番最初に思い浮かべた絵を、もう一度思い出してください。

もし私が「この絵、少し殺風景だから何か足したいのよね。」と相談したとしましょう。

〈 実のなる木のりんご 〉を想像した人は「りんごを収穫しようとする人」を提案します。
〈 皿に並ぶうさぎさんりんご 〉を想像した人は「りんごを見て喜ぶ子ども」を描こうと言います。
〈 椎名林檎さん 〉を想像した人は、「バックダンサーでも追加したら？」と言うでしょう。

もう既に実際の絵を見ている人からすると、これらの提案がミスマッチなものだとお分かりかと思います。

イメージの共有が出来ている状態であれば、「りんごだけが宙に浮いているから、机を描けば良いじゃない」と適確な提案ができるでしょう。

このように、イメージの共有ができているか、できていないかで後の出来栄えに影響があります。
説明する側も、説明される側もイメージがお互いに合っているか確認しましょう。

まとめ

・同じモチーフでも、想像は十人十色
・文章である程度イメージの共有はできるが、百聞は一見にしかず。
・イメージの共有ができていないと、「違う、それじゃない。」なものができあがる。

以上です。
秋のりんごジュース作りたくなってきました。

虹プロにはまりました

いきなりですが、虹プロジェクト見ましたか？
もともと、まったく興味がなかったのですが、外出を控えていたのに加えて、友人の勧めもあり見ることにしました。
見てしまったが最後、ものすごくはまってしまいました。
めちゃくちゃ面白いです。

虹プロって？

一応、知らない方のために虹プロジェクトとはどんなものか説明します。
韓国の芸能事務所「JYPエンターテイメント」とソニーミュージックによるオーディション番組、「Nizi Project」です。
世界で活躍できるガールズグループの発掘・育成を掲げ、1万人以上の応募者から、最終デビューメンバー決定までを追ったドキュメンタリーです。

虹プロの魅力

虹プロの魅力といえば彼女たちの努力や成長を見守り、応援できるところかと思います。
デビューのために毎日練習に励む彼女たちが、1話ごとに成長していることが素人の私でも実感することができました。
そんな彼女たちが、努力し、成長していく姿にすごく胸を打たれました。
そして、その努力が報われたときに、流れる涙！
きれいすぎる。私も何回も泣きそうになりました。

最後に

コロナ禍で沈む中、沢山の感動と元気を届けてくれた虹プロは本当に楽しいエンターテインメントでした。
まだ見てない方は是非見て頂きたいです。
今後、彼女達が世界で活躍する姿を楽しみに、応援していきたいと思います。
がんばれ！！
以上

残暑お見舞い申し上げます。

暑い日が続きますね。
こんなに暑いと体調管理もままならないので、つい自宅にひきこもりがちです。

この夏はもっとやりたいことあったのになあと思いながら、
別のことに転嫁して楽しく過ごしています。

とは言え、気持ちはまだ3月なのですが笑
この半年間で自分が変わってしまったかように思います。

消費者であると自覚したことをキッカケに、
無くなって欲しくないものをお金で守っていこうと決めました。
大げさかもしれませんが、何もしないよりマシかなと思っています。
無くなったあとに後悔したって遅いですしね。

私の未来に、彼らがいないと寂しい！

出来るだけ外食(テイクアウト)をしたり、たくさん服を買ったり、
ライブハウスに寄付したり、あっちこっち大忙しの日々です。
(字面だけ見ると散財しているようにみえますが、、、まぁほんとに散財してます。)

生活の中で特に変わったことは、大切な人たちに連絡をするようになりました。
「好きな人に好きって伝えるの、もしかしたら明日では遅いかもしれない、、！」
なんて思いながら。

一方的ではありますが、ファンレターはおすすめです！
アーティストに限らず、
近所のご飯屋さんやスーパーの店員さんにだって送って良いと思います。

ちょいとしんみりしちゃいましたね。
最近の楽しかったイベントをいくつか書きましょう。

フラ

フラを習っているのですが、その発表会が先日行われました。

1人モザイクかかってないじゃん、、、？
YES、それが私です。

GWに行われるはずでしたが延期になり、中止かもしれないと思っていました。
しかし、ソーシャルディスタンスが配慮された内容となり、
なんとか無事に終わりました。
とっても、とーーーっても楽しかったです★☆

配信ライブ

最近、ハマっています。
インスタ、ツイキャス、楽天、Thumva、アベマ、などなど、
なんだかいっぱい登録してしまいました笑

いままで気になってたけどチケットを取れなかったアーティストや、
ライブに行くまでもないし、DVDを買うまででもないけど
やっぱり気になるアーティストのライブ配信を
なんと、お家から観ることができる！なんて便利！！！！！

アーカイブを残してくれることも多いので
何度も繰り返し視聴することが出来て、ちょっとおトク感もあります。
ぜひチェックしてみてください。

この機会に新しい趣味に出逢えるかもしれないですよ！！

おまけ

このブログが公開されるころには、私は三十路突入です。
誕生日プレゼントには、プロカット・ホワイトライトの花束をください(ウインク)

今だからこそ「片付け」のコツ

お久しぶりです。大墨です。

最近はコロナの影響で仕事は基本リモートとなりました。趣味の方も、カードゲームはwebカメラを使ってリモート、映画鑑賞も映画館ではなくPCやスマホで……と、とにかく自室にいる時間が増えました。

そこで、ステイホームを快適に過ごすため、部屋の片付けについて調べてまとめてみました。

「1日かけて全部やる」は無理？

片付けをしようとする時、「この日に一遍に全部やるぞ」というふうに考える人は多いのではないでしょうか？実は、これが片付けが上手くいかない落とし穴なのだそう。

そもそも、部屋が散らかっている状態とは、大抵何ヶ月、何年も掛けて積み上げられた結果です。それを1日でそっくり綺麗に、だなんて虫のいい話はありません。しかも、片付けは実は頭も体力も使う大変な作業です。丸1日なんて、集中力は保ちません。

今週は本棚を、来週はクローゼットを……という様に、計画を立て、時間を決めて少しずつ進めていくことが大切なようです。小さい範囲でも綺麗に片付くと、次の片付けに対するモチベーションを保つことにも繋がります。

収納のコツは「戻しやすさ」

一度片付けたら、次は散らかりにくい方がいいですよね。そのためには、一つ一つのモノを仕舞う所をキッチリ決めておくことが重要です。使ったものを片付ける時、どこに仕舞えばいいか迷わなければ、その分、部屋を綺麗に保つための手間も省くことができます。

服、食器、漫画などのように様々な種類のあるものは、色やサイズ、使用頻度などで細かく収納場所を分けておくと、使うのも仕舞うのも楽になります。また、しっかり整理できていれば、既に持っているものをまた買ってしまう、というような失敗も防ぐことができます。

最後に

片付けをトピックに選んでいる時点でお分かりかもしれませんが、私は整理整頓があまり得意ではありません。思い立った時に「今日1日で片付けるぞ！」と考えながら始めて、途中で疲れて飽きて中途半端になってしまうという、典型的片付け下手ムーブを取っていました。何事も闇雲にやろうとするのではなく、計画を立てて少しずつ進めることが重要ということが改めて分かりました……。

片付けが苦手な方、ステイホームを機に部屋を片付けたいという方は、是非参考にしてみて下さい。

「伝え方」について

久しぶりの投稿になります。

前回の投稿からだいぶ時間が空き、私自身にもいろいろな変化がありました。
特に、新しい案件とリモートワークの開始によって考える機会が増えた「伝え方」について今回は書こうと思います。

コロナの影響もあり、私もリモートワークを行いました。
業務上の都合もあり、チャットやメールといった文章で情報連携や相談を行わなければならない場面が多くなりました。

ただ文章を書くだけでは、なかなか思った通りには伝わらず、相手とのやり取りが多く発生してしまうことがあります。
チャットならまだいいのですが、メールだとリアルタイムというわけにもいかず、それだけで数日必要になってしまうこともあります。

上長からの指導もあり、以下の点に気を付けることで少しでも認識齟齬をなくし、やり取りをスムーズに行えるよう心掛けています。

情報を省略しない

いままでは、情報連携の際にこのことはわかっているから伝わるだろう、や、メールの本文が長くなりすぎるのは読むのが大変だろう、という変な気を遣って、本来の目的である正しく伝えることを無視したメールの本文を考えていました。
しかし、目的は「正しく伝える」ことです。読みやすくても正しく伝わっていなければ、意味がありません。
そのことを教わってからは、まず第一に正しく伝わるかどうかを意識してメールの本文を考えるようになりました。

資料をつける

メールには文章しか書けません。
どうしても文章だけでは、伝えられる内容に限界があります。
そういった場合には、Excelなどのドキュメントを用意して、お互いの認識のずれが少なくなるようにしています。
画面のキャプチャや図がひとつあるだけでも、伝わり方は全然違います。

直接会話（電話）を行う

これは時と場合によっては出来ないこともありますが、もっとも効果的だと感じました。
メールやチャットなどで事前に情報連携や相談内容を伝えた上で、直接会話をします。
直接のコミュニケーションは、細かい認識のずれも互いに確認しやすく、やはり文章よりも認識を合わせやすく感じています。

最後に

心掛けていても、正しく伝えるということはなかなかうまく出来ません。
これからもリモートワークによって気軽に相談が出来ない環境が続くと思いますが、この業界はコミュニケーションがとても大切だと感じています。
どうしたら正しく伝わるのか、これからも意識して正確なコミュニケーションがとれるように頑張りたいです。
出来ていない人も多いと思うので、参考にしてもらえればと思います。