株式会社シベスピ 従業員ブログ

シベスピの社員ブログ。技術・想い・経験沢山書いていきます!

システム部員による現場営業2年目(本格スタート年)

先日の全社夕会でも紹介させて頂きましたが、改めてシステム部員としての現場営業について基本的な認識合せの話を書こうと思います。

1.主体的に考えて行動する

本件活動が全社目標達成への施策の一環であることは以前お話したとおりです。
まずは、各人がそれぞれの場所で「自身として何ができるか」を考え・相談し、アクションを始めること、それが第一歩です。

その為に、前年度表彰者や、夕会などで紹介した「既に実践的な行動を起こし、成果を上げている先輩・同僚社員」に話を聞くことも参考になるし、また、その行動が横のつながりを広げる副産物の一つになるとも思います。

2.『実績』から『信頼』の獲得

上記少々抽象的な話から入りましたが、営業行動前にシステム部員の皆さんが具体的にできることは、現場で成果を上げて『実績』を作り、そこから発生する『信頼』からアクションに繋げる事かと思います。

では『実績』、すなわち業務成果という評価を得るためには、一つに【付加価値】を付けたレスポンスが有ると思います。

例えば「共通部品の改修依頼」が有ったとして、納期遵守は当然ですが、納期期限内で、その指示の先を見据えた業務遂行、
・周辺の影響範囲を洗い出してテスト観点一覧を作成して一緒に報告する
・後続(共通部品の改修を前提とした他改修)者への改修ポイントの連携
など、現場に即して複数あると思います。
それを自発的に能動的に行うことで、
「気が付くな」「指示が楽だな」→『今後も一緒に働きたい』
といった評価に繋げられるのではないかと思います。

『これからも一緒に働きたい』と顧客や周囲のエンジニアに思ってもらうこと、これこそが皆さんが目指すべき『信頼』という一番の成果になると思います。

3.良い報告も適切に

もう一つ、コミュニケーション(報告)の重要性についても書いておきます。

入社後に行うビジネスマナー研修の中でも、『報告』の重要性は複数章に渡って指導されます。
・悪い報告は迅速に
・良い報告も謙遜・遠慮せずためらわずに
上長との緊密なコミュニケーションも営業の入り口になり得ます。

先日も現場でのミスの報告がシステム部経由で営業部にありました。
お詫びを含めて顧客に連絡したところ、
「もらった電話で悪いんだけど、こんな新案件の話があってさ」
と、特に連絡の機会がなければ逃すような営業情報を得ることがありました。

営業観点ではミス・失敗(悪い報告)、成果・評価(良い報告)のどちらも営業の種になり得ます。
ピンチはチャンス、当社方針である『三方良し』の精神からの誠意ある行動、誠実な振る舞いがあれば最後には顧客にも伝わると信じています。

4.最後に

皆さんの行動で早くも成果が出始めていることには感謝の想いです。
それとともに、施策二年目となる本年度からが本格的なスタートだとも思っています。
上記内容が皆さんの行動の一助になればと思います。
皆さんのアクション結果の報告を楽しみにしています。


以上です。

部長の小言⑤

私も歳をとってきて、若い頃の感覚や、当時考えたり思ったりしたことを思い出せないのですが、最近の上司と部下のコミュニケーションで気になることがあります。

 

何が気になるかというと、部下に注意を行った際に、その注意をすごくネガティブに捉えすぎではないかということです。

上司からの問題点の注意という行為に対して、部下が単に責められていると受け取っているのではないかと感じています。

基本的に上司が部下に注意する時は、問題があった事象を責めているわけではなく、問題点を認識してもらって次にどう活かしてもらうか、ただその一点に尽きます。
そういった場面での部下の態度として、特に多いのが言い訳です。

 

生じた問題と事実関係が違うのであれば訂正は必要ですが、あんまり意味のない言い訳をしても仕方がありません。

自分は悪くないといった自己弁護の方向に話が流れやすくなっていて、上司としては誰が悪いとかそういう話をしている訳ではないので、論点がずれてしまいます。
注意される事を怒られていると感じているのかもしれませんが、本質的にはそうではありません。


人は失敗もするし、完璧でもありません。

ただ、失敗を反省し、改善する事はできますし、私はその繰り返しが長期的な成長につながるのだと考えています。

逆に常に他責にすることばかりに執着する人は、成長する事はむずかしいと思います。
なので、注意された時も上司は責めているわけではないので、あまり感情的に対処せず、自身の成長の糧にしてもらえればと思います。

会議について

ご無沙汰してます。佐藤です。
コロナ禍をいかがお過ごしでしょうか?
コロナ疲れ、リモート疲れも一周し、慣れてきた感じでしょうか?

当社のある池袋駅周辺では、マスクしていることを除けば、ほぼコロナ前と同じ景色になってきたように思います。

とはいえ、仕事の方はどうかというと、対面での会議はまだ少なく、WEB会議を一日中行っているような感じで、不要な会議までどんどん増えているように思います。

WEB会議が増えていく中で、今一度会議の目的を意識し、見直しする機会が必要だと感じたので、
今回は会議をテーマにしてみました。
そもそも、WEB、対面に関わらず、何のために会議を行うのか、みなさんは意識されておりますでしょうか?

○○に△△を報告が行いたい。
○○に××について相談がしたい。
○○に□□の提案がしたい。
  ・
  ・
  ・

さまざまな目的があると思いますが、何となく会議に参加している人、多くないですか?

・何をやるのかわからないけど、呼ばれたのでとりあえず参加してる人、いませんか?
・会議中一言もしゃべらない人、いませんか?
・会議中に、他のことやっている人、いませんか?

このような人がいる(もしくは、自分が当てはまる)場合は、ぜひ、会議自体の見直しを行ってみて下さい。
効率的な会議になっていないのであれば、そもそも目的を果たす場は会議で無くても良いかも知れません。

会議体を見直すにあたっては、まずは下記について考えてみると良いです。

①誰が主催者か?
 〇〇課長、〇〇部長 など

②会議のアウトプットは何か?
 課題の共通認識
 ○○の稟議を通す
 〇〇について解決策を、方針を出す など

③参加者は誰が妥当か?
 検討するにあたって必要な人は誰か
 この人に知っていて欲しい など

参加者に明確に会議の目的を伝えていないと、何を求められているのか、ゴールが何かわからず、内職などを行う人や、ただ聞いているだけの人が多くなると思います。

ただ認識を持って欲しいだけであれば、会議に参加してもらわなくても、資料の共有や会議の議事録、録画などを渡せば済むケースがほとんどです。

対面式であれば、話を聞いていないことや内職を行っていることは一目瞭然でしたが、
WEB会議では、ただただ参加しているだけの人が増えているように思います。

特にWEB会議では、目的を持って、それを周知し、なるべく少人数で行うようにすれば
有意義な会議へと変わっていくと思います。

みなさん、意識してみて下さい。

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

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

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

ブランチという考え

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

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

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

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

そこで、リリース版以外にも(木の枝のように)ブランチを作成し、分岐して作業を行います。
f:id:chivsp:20200903210950p:plain
ブランチには2種類のブランチがあります。統合ブランチとトピックブランチです。

統合ブランチ

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

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

トピックブランチ

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

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

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

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

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

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

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

そこでAさんは「機能追加のブランチに行かなくちゃ」となります。
ブランチを切り替える操作はcheckout操作です。
f:id:chivsp:20200903211238p:plain
またまた図の中に新たな言葉が出てたので説明します。

HEAD

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

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

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

例を出して理解を深める

さて、あなたは今、下図のAさんとします。
Aさんはtopic-branchの先頭(HEAD)にいます。
f:id:chivsp:20200903211506p:plain
Aさんは自分の作業が完了し、masterブランチ(以下master)へのマージを試みています。
しかし、masterにいきなりmergeをしたら、コンフリクトが発生してしまうかもしれません。

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

ここで行うのがmerge操作でしたね。(コマンドは git merge master(コマンドって何?って人は気にしないで大丈夫です。))
f:id:chivsp:20200903211558p:plain

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

Aさんはmasterへとブランチを切り替える必要があります。
f:id:chivsp:20200903211651p:plain
ここで行われるのがcheckout操作です。(コマンドはgit checkout master)
f:id:chivsp:20200903211712p:plain
ようやくこれでAさんはmasterに移動することができました。
それではtopic-branchをmasterにmergeしましょう。
f:id:chivsp:20200903213103p:plain
以上でmasterにtopic-branchをmergeすることができました!!

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

最初の状態は先ほどと一緒です。
f:id:chivsp:20200903211753p:plain
Aさんはmasterにtopic-branchをマージしたいので、rebaseしようと考えました。

rebase操作をするとどうなるのか?
下記のようになります。
f:id:chivsp:20200903211818p:plain

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

あとは、同じ操作です。masterにmergeするには、一度masterに移動する必要(checkout)があります。
f:id:chivsp:20200903211846p:plain
最後にmerge操作です。
f:id:chivsp:20200903211859p:plain

終わりに

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

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

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

はじめに

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

f:id:chivsp:20200903204020p:plain
git_01

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

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

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

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

f:id:chivsp:20200903204148p:plain
git_02

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

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

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

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

前の状態に戻す

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

編集箇所の差分を表示

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

上書き時に警告

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



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

前提知識

下記の図を見てください。
f:id:chivsp:20200903204606p:plain
たくさん知らない単語が出てきましたね。
1つずつ解説していきます。

ディレクト

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

リポジトリ

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

ローカルリポジトリ

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

リモートリポジトリ

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

どうして2つもあるの?

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

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

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

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

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

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

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

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

変更の記録「コミット」

いよいよgitでの操作をするために必要なことを説明します。まずはコミットです。
f:id:chivsp:20200903205149p:plain
コミットとは作業が完了した時や、ひと段落ついた時に行う操作です。
このコミットをすることで、リポジトリに変更履歴を保存することができます。

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

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

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

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

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

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

下記の図を見てください。
f:id:chivsp:20200903205245p:plain
ここでもたくさんの知らない単語が出てきましたね。

ワークツリー

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

インデックス

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

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

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

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

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

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

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

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

リポジトリ間のやり取り

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

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

  • push
  • pull
  • clone

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

push(ローカルリポジトリ→リモートリポジトリ)

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

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

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

pull(リモートリポジトリ→ローカルリポジトリ

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

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

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

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

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



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

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

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

変更履歴の統合(merge)

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

そうです、push操作です。
そのpush操作をすると、下記の図のような状態になることがあります。
f:id:chivsp:20200903210334p:plain

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

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

警告されれば、mergeしなくちゃぐらいの感覚で大丈夫です。
それでは、mergeするとどうなるのか説明しましょう。
f:id:chivsp:20200903210421p:plain
merge操作を行うと、リモートの変更履歴を一旦ローカルにダウンロードできます。
ここで、「あれ?それってpull操作じゃないの??」と思った人、いると思います。
pull操作との違いは、自分のローカルの変更履歴に追加して、リモートの変更履歴がダウンロードできることです。

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

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

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

衝突(コンフリクト)

複数人で作業をしていて様々なファイルを編集していると、必ず誰かと同じ場所を変更してしまう可能性が出てきます。
そのような現象を衝突(コンフリクト)と呼ばれています。
f:id:chivsp:20200903210555p:plain
コンフリクトは、先ほど説明したmergeの後にローカルリポジトリで出ます。

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

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



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

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

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

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


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


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

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

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

もっと情報がほしい!

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

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

りんごについて

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

絵について

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

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

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

百聞は一見にしかず。

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

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

イメージの共有大事!!

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

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

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

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

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

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

まとめ

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

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

虹プロにはまりました

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

虹プロって?

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

虹プロの魅力

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

最後に

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