桜井政博さんの「仕事の姿勢」に関する動画を視聴しての所感
はじめに
タイトルの通りなのですが、動画を視聴して気になったものピックアップして自分なりの所感を書いていこうかなと思います。
✅すべて個人的の感想と見解です
✅出典の記載がないものに関しては動画内にあるものになります
🚨下記の動画を視聴してない方は、このnoteを観るより先に動画や再生リストを視聴した方が100%時間の使い方として有益です！！！
関連の再生リスト
まとめ動画
A-1 遊びの仕事は遊びじゃない
得意なことを仕事にする
あなたはなぜゲームを作るのですか？
一番多いのは
「ゲームが好きだから」だと思うし
そうであるべきですけれども
私は「自分がもっとも得意とする仕事だから」と答えるところでしょうかね
この章で一貫して言われてますが、前提として「好きだから」はすごく大事。
「好きなことを仕事にする」ことは大事ですが、「仕事で好きなことをする」は違うのかな。
ちなみに、自分がシステムエンジニアになった理由としては、何かのサービスが好きだったとかプログラミングが好きだからと言う理由は多くを占めていなかったですね。
大学在学中にハード/ソフトウェア両方を経験して、どちらかというとソフトウェアの方が得意だったのでシステムエンジニアになった流れでした。
(元々ハードウェア企業に就職予定でしたが、ハンダゴテは苦手だし電気系も全然無理でした・・・笑)
好きでないことも仕事においてはこなす必要がある
自分の好みと正反対であっても
それが仕事ならば
しっかり器用にこなさなければいけませんね
どんなジャンルを提示されても課題とみなし考えた上で目的にあったものを作ろうとします
ただこれもまたなるべく楽しむようにするのが一番ですね
システム開発で言うと、個人開発であれば自分の趣味趣向をいくらで詰め込んでもいいし、好きな言語・フレームワーク・手法を取り込んでも構わないです。
ただ、仕事となると話は別です。
例えば、システムエンジニアとして特にプログラミングが好きな人だと、資料作成などのプログラミング以外のタスクは苦痛かもしれません。
業務としてプログラミングだけしていたいと言うことが通る方が少ないかと思うので、苦手なこともそのタスクに対して結果を出すことは大事ですね。
そこに更に「楽しさ」を上乗せ出来たら一番良いですよね。
顧客を一番に考えて行動動機にする
作品を作る最終目的は
”プレイヤーを楽しませること”に他なりません
開発の事情 困難はあれど
遊ぶ人が楽しめることを行動動機にしてもらえればと思いますね
システム開発はユーザーがあってのものになります。
お金出してくれる人がいないと開発が出来ないですからね。
システムエンジニアとしての作業内容自体はプログラミングであったりなのですが、背景まで見るとユーザーに使ってもらうものを開発することですよね。
自分が楽しみながら仕事するのは大事なのですが、ユーザーにとって便利(サービスによっては楽しむ)なものを考えながら仕事をすることも大事です。
チームが炎上していることもうまくいかないこともあります。
でも、自分たちがゲームやWebサービスに触れる時に開発側の苦労や事情を考えながら遊ばないですよね？
同じくシステムを使う人も開発陣の事を考えてないし、見ているのはシステム自体の機能や便利さを見ている人の方が多いです。
仕事していて大変なことも沢山あると思うんですけど、サービスを使ってくれる人のことを考えて仕事をするのは大事です。
プレゼンはスピード
必要なことを伝える
ぜい肉をそぎ落とし、必要なことだけ伝えるようにしましょう
意図も第二案も必要なし
必ずしも短くある必要はありません
プレゼン時間をいかに濃密にテンポよく進められるかがポイントです
プレゼンの機会はシステムエンジニアであれば多くはないかなと思います。
ただ、社内(外)でのLT会やMTGでの発言や提案はあると思うので大事なポイントとして押さえておくと良いですよね。
スピード＝時間が短いではなく、無駄なことがなく必要なことだけがまとまっているという認識は持ち合わせておきたいです。
お客さんに説明できるの？
開発者ファーストにしない
開発者に都合がよく遊び手には不親切なものが出てくることが多々あります
ただただ不親切であったりとか、自らあるいは制作側の都合を優先され過ぎているとか
こんな時によく口に出す言葉があります
それ、プレイヤーに事情を説明して回るつもりなの？
A案の方が便利だけど、B案の方が楽に実装出来るからB案にする
みたいなことがあったりなかったり・・・笑
全てをユーザー側に沿って開発するのは難しいので、理想と現実を良い塩梅で折り合いをつけるかというのは一種の能力です。
年々役割が上流になってきたり、リーダーをしている自分にとって結構響く箇所でした。
仕様を変えること
仕様変更に対する心構え
ゲームにおける仕様を途中で変える
極力避けるべきことではありますが
柔軟にすべきことでもあります
開発していたら仕様変更ってしょっちゅうあると思います笑
正直変えるの面倒くさいと思うこともあるし、今までのことが無駄になることもありますが、これらが仕様変更をしない理由にはならないですよね。
時々無茶な投げやり的な仕様変更注文もありますが、無理ですの一点張りでなく折り合いをつけたり説明することは仕事として必要になります。
問題が発覚したらすぐさま報告
スタッフ等が問題点に気がついていた場合
後から「そうだろうと思っていた」
などと言うことはナシです
問題に気が付いたらすぐに誰かに言わなければならない
スタッフなら誰でももれなくです
これ問題っぽいけど誰かが言うだろう
納期も迫ってるし放っておこう
こういうパターンありませんか？
最短で問題解決をしようと思うと、問題が発覚した時が一番大事です。
ここの報告が遅れれば遅れるほど、解決までの時間がかかりますし何より手遅れになる可能性すらあるからです。
問題が起こった原因は後から振り返って改善すれば良い。
まずは解決を最優先にスピーディーに行うこと。
それには発覚時の報告を早くすることです。
問題解決について
理屈が通じないコンピューターを相手にするからこそ、矛盾めいた解決できない問題が起こることも多いですが、だからこそ集合知と言うのは侮れません
できる手立ては考えられるだけ机上に並べ、そこか現在における最適解を選択する
解は短期と長期の両方から吟味する
問題がなぜ起こったのかも大事なのですが、問題が起こった時にどうするのかというのも同じくらい大事です。
言い訳から始めるのが最悪だけど結構見るパターンだったり・・・
とりあえず出来ることや案を出して、そこから最適解を出す
これは意識したいですね。
良いチームは相談が素早くできる環境を持つ
相談のために「どう相談しよう」なんてチームで揉んでいて、時間がかかるなんてことも本当にあるんですが、そういうこともソンですね
良いチームとそうでないチームの違いの一つに、情報共有や報連相が出来るかどうかの環境というのがあります。
あえて「環境」と書いたのは、出来ないのはその人の問題ではなく環境であると考えているからです。
相談したくても
・誰に
・どうやって
これらが分からなければ出来ないなんてこともあります。
チームとして気軽に相談や報告ができる体制があると、仕事をする上で凄く心理的環境が良いし役割が上の人間がどんどん整備していくところだと個人的には感じています。
企画書の書き方
短ければ良いというものでもない
よく「企画書は薄い方がよい」なんてことも言われますが、必ずしもそうではないです
分かりやすいか・面白いか・内容は妥当か
密度あるプレゼンをスピーディーに聞ければ、ページ数自体は問題ではないです
漫画でもそうですけど、短い方が面白かったり伝わるとかではなくて、内容が濃くて分かりやすく描かれていると長くても面白いんですよね。
薄くても文字だけがバーっと羅列してあるだけじゃ分かりにくいです。
企画書だけじゃなくて、普段の話(トーク)にも応用出来そうだよなって思いました。
ディレクターは”個”
個性とバランス
1つのものを見るとき、あるいは流すとき
ささやかな何かを見逃さずに拾ったり
人と異なる何かを感じることができる人
ある程度のバランス感覚も必要である
個性って目立ってなんぼとか人と違う身なりとかそういったことではなくて、同じものやことを共有した時に違う着眼点だったり、微妙な変化を感じられるとこだったりする。
個性的な人=変な人みたいな感覚があったりするけど、個性だけあれば良いのではなくて、協調性を持ちつつ違う感性や観点を持つことが大事だとおっしゃってる点もとても共感出来た。
とにかくやれ！
言い訳するな。手を動かせ。
やる気が出ないことに対して深く考えても意味がないです
とにかくやるべし
手を動かすべし
やる気は後からついてきます
やる気がないからどうしよう。
やる気を起こす方法
これらを考える時間があるなら、とりあえず行動。
0の状態から1にするだけで、まずはスタートのモードに入ります。
やり始めると案外すんなり進みます。
とりあえず手を動かすとやる気なんて考えてる暇がなくなります。
やり始めが一番大事なので、そこを強引に行動という方法を取る
これ大事だけど出来てない時多いから気を引き締めよう・・・
圧倒的な手数
自らを鍛えるのは
あるいは成功に近づくのは
圧倒的に手数です
効率vs手数みたいなのも見ますけど、何もない状態から効率を考えてもあまり意味がないと個人的には思ってます。
やっぱり何かしらで成果出している人は圧倒的な数をこなしています。
効率悪いとか考える前にまずは動いて後で振り返ってフィードバックする。
考える前に動くというのはめちゃくちゃ大事だし、効率ガーとか言ってくる人がいても気にせず動く。
例えばプログラミングスキルを高めたければ手を動かすのが一番です。
スキルの高いエンジニアほどたくさんコードを書いてるし、学びに時間を割いてます。
インプットを太く、アウトプットも太く
習慣化
インプットは外から受ける刺激
アウトプットは自身から出す出力
これらを習慣づけ、当たり前のようにすることをオススメします
どちらかだけでも十分ではないし、どんな立場や年齢になってもこれらを続けられるかが自身の成長につながると考えてます。
自分の場合は
・インプット
読書、会話、技術的記事、勉強会
・アウトプット
会話、記事執筆、SNS、勉強会
といった感じでしょうか。
どうしても日々忙しくてやっている暇がないと言ってしまいそうになりますが、どんなに忙しくても毎日やり続けている習慣は誰にでもあると思います。
時間がないからやらないという考えではなく、習慣として落とし込むまで初めは無理にでも詰め込んでやってみるところまで持っていければ良いのかなと思います。
インプット・アウトプットでいうと、例えば日々の何気ない通勤一つとっても視点や観点を変えれば何かに気づくかもしれない。
人との会話や業務での気づきに深みを持たせてアウトプット用にメモをするのでも良い。
やり方は色々あれど、量も質も大事に日々インプット・アウトプットに励まなければと改めて思いました。
暗示の力
自己暗示
何かの仕事をするならば
いつでも着手して終えて良いと思うより
「あと何時間で終わらなければいけない！」とする方が
実際には進むであろうと思います
人間って「よし本気出すぞ！」と言って取り掛かっても、実際には100%の力なんて都合よくすぐには出ないです。(出てる気にはなれる)
本気すなわち100%の力が出る時って追われている時に必死になって「でてる」ことも多いのではないでしょうか？
全ての物事に対して締切が存在するわけではないので、特に時間があればやりたいなということをやるには、自分で締め切りを設定しないと動きもしないです。
制限時間があるから動けるし必死になれる。
モチベーション云々ではなく、追われてるという背景を自分に課すことで力が発揮出来るのだと感じます。
変にプレッシャーになりすぎないようにはしたいですが笑
自分を追い込む
できれば何かに向かったり、目指すという同じ方向に行く暗示よりも
何かから逃げるという暗示の方が効果的かもしれません
自分がプログラミングコミュニティなるものを運営している中での気づきなのですが、未経験からのエンジニア転職をするぞ！という目標に向かっていく中で、より良い環境に身を置きたいと考える人よりは、何月までに決めるとか今の会社を今すぐ辞めたいみたいな何か切羽詰まった感がある人の方が早く決まっている印象がありました。
結局、目標を掲げてそれに進むだけではモチベーション云々に頼らざるを得ない状況にもなってくることもあるので、火事場の馬鹿力ではないですが、何か自分にリミットを課して進めることは大事だと感じます。
言ったことはそうなっていく
言霊はある
言ったことや考えたことが
自らの姿勢を作るということです
自分は言霊みたいなことはあると思ってる派です。
なんかだるい、しんどいなと思った時に、口に出したり表現すると思考が結果に現れてしまう的な感じですね。
逆に、何か出来そう、やるぞ、と思った時はあまり調子良くない時でも進められたり実行できることもあります。
言葉や思考が自身の行動に繋がり、行動が自分を変えたりしますよね。
ネガティブは全てが悪ではない
ある意味ポジティブなだけよりも、ネガティブは積極性が出るチャンスかも
ネガティブなことがあるなら、それを改善していこうという気持ちに持っていくなら、逆に効果が上がります
ポジティブ！ポジティブ！
ずっとこうだとしんどいし、難しいですよね。
ネガティブがダメというわけではなく、それを原動力に何か変えたり行動する。
バネのようにネガティブな時期や感情をタメと考え、それを解決するために気持ちを切り替えると飛躍的に跳ねるといったことがあります。
ネガティブを100%悪とするのではなく、逆に逆手にとって良い付き合いをしていきたいものです。
エコーチェンバー
エコーチェンバーとは
エコーチェンバー現象（エコーチャンバー現象、Echo chamber）とは、自分と同じ意見があらゆる方向から返ってくる「反響室」のような狭いコミュニティで、同じような意見を見聞きし続けることによって、自分の意見が増幅・強化されることを指す。
賛成意見以外の排除
仲間が仲間を呼ぶとも言えますが、実際には閉じた世界で他の意見や見解を受け入れられなくなってしまう
特にSNSはこの風潮が強いですよね。
自分は攻撃的なことやあからさまに敵意を向けられた時や極端すぎる意見に関しては、内容がどうであれ取り入れないし聞かないようにしています。
あとは例えばXでいいねが多いから自分の発言に肯定感を感じるというのも実は結構危険だと思っていて、自己主張の正しさを自己補強してしまうのは実は本質的な部分を考えると、発言を見ていない否定意見を見なくなってしまうことに繋がると考えるからです。
上は下なり、下は上なり
立場は違えど高さは一緒
ディレクターやプロデューサー、あるいはリーダーは
チーム内では決して周囲のスタッフよりえらいというわけではありません
偉い順に並んでるのではなくて、指示をする順番にすぎないと思ってます。
リーダーといってもスタッフやメンバーがいなければリーダーという役割が出来ませんからね。
リーダーだから偉ぶるとか、スタッフだから卑下になる必要はないです。
お互いにリスペクトを持って目的に向かって仕事をしていきたいですね。