#1 Web系企業の特徴について説明します

こんにちは、たなかです。文字起こしです。

情報がまとまっていて、サイトをいろいろ探しながら自分でまとめるよりも楽に業界を知ることが出来ました。

参考にしたYouTube

https://www.youtube.com/watch?v=4rMcu44o9XQ

 

Web系企業とは
・インターネットを活用した
・発注元の存在しない
・スケールさせることを前提とした
・自社サービス
 
を提供している企業のこと
Web系企業向けの受託開発を行っている企業さんは「発注元が存在する」という点においてはSlerさんに近いですが、カルチャーや開発方式がWeb系企業とほぼ同等の場合が多いので「Web系企業である」と考えてよいのではないかと思います。
 
Web系企業には、Slerさんのような「メーカー系」「ユーザー系」のような「大分類」は存在せず、
その企業が提供しているサービスが主にどういう分野に属するかという点で細かく「小分類」する方式が一般的です。
 
比較的大きな分野
(関わっている企業が多い分野)は
・EC系
・アドテク系(ネット広告系)
・メディア系
 
という感じになります。
 
企業の例
EC系
楽天/スタートトゥデイ
アドテク系(ネット広告系)
メディア系
BuzzFeed/ハフィントンポスト
 
分野を表す用語の後ろに「Tech」を付ける「xTech」 という方式が最近定着してきています。
よく聞くもの
・FinTech
・EdTech
・HRTech
・FashionTech
・Health Tech
など
FinTech
・金融系サービス
EdTech
・教育サービス
HRTech
・人材・人事系サービス
FashionTech
・ファッション系サービス
Health Tech
・健康系サービス
 
インターネットを活用できる分野なら、どこにもWeb系企業は存在する。
 
Web系企業のエンジニアの分類に関してSlerのように「SE/PG」という呼称は存在せず、そのエンジニアが専門としている技術分野で分類するのが一般的です。
・インフラエンジニア
・サーバーサイドエンジニア
・フロントサイドエンジニア
iOS/Androidエンジニア
※インフラ/サーバーサイド/フロントすべての領域を幅広くカバーしている人を「フルスタックエンジニア」といったりします。
その他、「Unityエンジニア」「機械学習エンジニア」等、細かく分類するともっと色々あると思いますが、代表的な呼称は大体こんな感じです。
 
それぞれの職種がどういうことやっているかというのは、また別の動画で細かく説明したい。
ざっと説明しておくと
 
インフラエンジニア
サービスで使うサーバーやネットワークの構築・運用・監視業務等を行います。
 
プログラミング的な作業も行うのですが、高パフォーマンスのサービスを安定して運用していくための様々な作業を行う「縁の下の力持ち」的なイメージの職種です。
 
サーバーサイドエンジニア
 
PHP,Ruby,Scala,Goなど様々な言語を使ってサーバー側で働くプログラムを開発する職種です。
 
フロントサイドエンジニア
主に「JavaScript」という言語を使ってブラウザ側で実行されるプログラムを開発する職種
※「ドックイヤー」と呼ばれるWeb業界の中でも、この分野の技術進化の速度(流行り廃りのスピード)がおそらく最も速い。
印象的にはドッグイヤーどころでないくらいいろんなものが進展している
 
iOS/Androidエンジニア
iPhoneAndroid等のスマホタブレット上で動作するプログラムを開発する職種。
iOSの場合はSwiftまたはObjective-C,
 Androidの場合はKotlinまたはJavaが使用される。
 
※「クロスプラットフォーム開発ツール」と呼ばれる、ワンソース(1つのコード)でiOS/Android両方のプラットフォームに対応したプログラム開発ができるツールも最近では人気がある(細かいところに手が届かない等の制約あり)
基本的にはそれぞれの言語が対応しているプラットフォームで開発するのが多い
 
Web業界の最近の技術トレンド
・IoT
VR/AR
 
特に「AI」に関しては、Web業界で働くエンジニアの「必須教養」になってきているという印象です。
※深いところまで完璧に理解している必要は無いとしても、ある程度知っておかないと時代に取り残される/生き残れない/という危機感を、かなり多くのエンジニアが感じていると思います。非常にまずいという雰囲気が漂っている。
AIにおいては、ある程度の数学知識が無いとある程度知っておくということも出来ないのでエンジンアの間で数学を学び直しを行うエンジニアが最近結構増えて一部でちょっとしたブームになっている感じはある。
IT業界で使っている技術の多くはアプリケーションエンジニアというかサービスを作ることが専門のエンジニアとしては、そういうふうに働いている人の場合、数学的素養がなくても余裕でこなせてしまうものがほとんどだったのですが、AIというか機械学習ディープラーニングという技術がWeb企業の普段の業務でも使われるようになってきたことで、数学をやらないわけには行かなくなってきた印象です。
 
 
そういう感じでですね、AI,ブロックチェーンに限らずWeb業界でエンジニアをやるということは、次から次に出てくる新しい技術にひたすキャッチアップし続けなければならないということでもあります。、
※それを「楽しい」と思えるか、それとも「つらい」と感じてしまうか、そこら辺はWeb業界でエンジニアとして働くことが自分が向いているかそうでないか判断する上では、とてもいい判断材料になるのではないかと思います。

 

 

Sler系企業の特徴について説明します。

こんにちは、たなかです。今回も文字起こしです。

とてもリアルかつ配慮された伝え方が勉強になりました。

参考にしたYouTube

https://www.youtube.com/watch?v=fS36V9mboTY

 

Slerとはなんの略?
「System Integration」に人を表す「〜er」をくっつけた和製英語
Slとは「システムを導入しようとしているお客様の面倒を、最初から最後まで見てあげること」を小難しくした表現。
もう少し小難しく言うと、「システムの導入に際して、分析から開発、運用に至るまで、すべての面倒を見てあげること」
 
Slerの分類
・メーカー系
・ユーザー系
・独立系
が存在している
メーカー系
富士通NEC、日立など主にコンピューター関連の製品を製造している電機メーカーの子会社や系列会社のSlerのこと
メーカーさんのIT部門が分離した。本体の親会社さんのIT案件を受託して開発する事もあれば、それと関係なく別の会社さんの案件を受託して開発している場合もある。基本的には親会社さんが作っているハードウェアとかソフトウェアを使ってシステム構築を行う。当たり前だがライバル会社さんのものはなるべく使わない
メーカー系の特徴としては比較的安定している。親会社さんが安定している限りは子会社さんも安定している。東芝さんのように本体自体の経営が結構危うくなっているメーカーさんもある今後どうなっていくかはからない。
 
ユーザー系
銀行、保険会社、商社、電力、鉄道などメーカー系以外の大企業の系列会社のSlerのこと
基本的にはメーカー系以外の大企業の子会社のSIさんは全部。これも基本的には親会社さんのシステム構築が中心になる。また、親会社さんで得たシステム構築のノウハウを同業他社のシステム構築に提供している会社さんとかもある。例えば保険会社さんのシステム構築はかなり色々なノウハウが必要になるが、そういうノウハウを別の保険会社さんのノウハウを別の保険会社さんのシステムを構築するときに活用するケースもある
こちらもある程度親会社さんの安定度に比例する
 
独立系
メーカー系やユーザー系以外の、何らかの巨大な企業グループに属していないSlerのこと
日本のSlerのほとんどは独立系に属する。中小企業のSlerさんは独立系に属すると考えていい。
多重請負構造というのがSIさんの業界にはある。その場合にプログラミングを担当するのは主にここの独立系に該当する企業。構造上どうしてもブラックになりやすい。三次請け、四次請けになってくるとどうしても労働環境が悪化してきやすい。「人売りSler」と揶揄される企業さんもここに属する
またアクセンチュア等の「コンサルティングファーム」と呼ばれる企業も分類的には独立系Sler。中小独立系Slerとは異なりコンサルティングファームは、要件定義等の「上流工程」をメインにしている独立系Slerはプログラミング等の「下流業務」をメインにしているところが違う
 
Slerの特徴1
メーカー系やユーザー系のSler限定ではあるんですが、社会インフラとして成り立つような超大規模プロジェクトの開発が経験可能であることが大きな特徴。ただしその場合プログラミング、エンジニアリングというよりはプロジェクトの管理が主な仕事。例えば金融系システム、交通系システムなど、例外はあるのですが、大規模な金融系システムとかに関しては、Web系企業ではまず経験できないので、非常に大人数でやる大規プロジェクトを経験したいと思ったら、基本的にはメーカー系、ユーザー系のSIerにいくしかない。いま(2018/02)、みずほ銀行の「システム統合プロジェクト」の費用は総額3000億円を超えたが、この規模の開発を日本のWeb系企業で経験することは不可能
 
特徴2
開発方式は基本的に「ウォーターフォール型」である
※開発方式が滝(ウォーターフォール)のように
要件定義→基本設計→詳細設計→製造→テストのように上から下に流れており基本的には後戻り出来ない方式なのでウォーターフォール型と呼ばれる
 ※ここから「上流」「下流」という用語が発生した
要件定義を担当するのが、ITコンサル
要件定義を元に設計を担当するのがSE
SEからの指示でプログラミングを担当するのがPG
 
SE/PGという呼称が存在する
PGは基本的にSEが作成した仕様書通りにプログラミングする
SE,PGということばだ出てきたら基本的にSlerのことを言っていると思って間違いない。たまに間違えて混同して使われてしまっていることもあるが、SE/PGといったらSlerのこと。Web業界ではそこで働いている人はエンジニアとかデベロッパーというので、SE/PGという呼称は存在しない。
 
上流/下流という考え方が存在する
※実質的な身分制度のようなもの
上流が偉い下流があんまり偉くないみたいな文化が正直Slerさんは、ぼく昔Slerさんに居たんですけどちょっとあるなとは思います。これもひとつの特徴ですね
※転職サイトでも「SEからITコンサルにステップアップ」的なキャッチコピーが普通に使われている
※大規模案件の場合
要件定義等の「最上流」業務を行うITコンサル、
要件定義を元に設計作業等の「上流」業務を行うのがSE、
設計を元に製造等の「下流」業務を行うのがPGという役割分担になっている
 
多重請負構造
ちょっと難しい用語なんですが、要するにあるシステムの発注を請けた企業が更に外注さんを雇ってその外注さんが更に外注さんを雇っていくようにどんどんどんどん不外注さんを雇う多重構造のこと
当然のことながら末端にいくほど利益が薄まっていくので一番最初に請ける元請けさんが得をする構造
※この構造が建設業界と酷似していることから、「ITゼネコン業界」と揶揄されたりもする
※建設業において実際の工事を担当する現場作業者がある意味差別用語ですけど「土方」と呼ばれることになぞらえて、中小の独立系SlerのSE/PGは「IT土方」と呼ばれたりする。それはこの構造のため。基本的に多重請負構造の末端にいくとお金も安いですし労働環境もブラックになりやすいので、Slerブラック企業と呼ばれやすいのは多重請負構造の末端にいる独立系Slerのことを指していると考えてほぼ間違いないと思いますメーカー系ユーザー系のSlerさんもブラックになりやすい所もあると思いますが、そうはいっても元請けさんのところと一番末端で請けている人たちの労働環境というのはどうしてもいろいろな面で差が出やすいと思います
 
※メーカー系やユーザー系のSlerは親会社の風土や制度に大きく影響をされるので、親会社が年功序列なら子会社もまた年功序列にならざるを得ない。
年功序列は別に悪いことでではないのでひとつの会社で定年まで長く働きたいという人には向いているかもしれない
※中小の独立系Slerはこの限りではない。そもそもその会社に長く勤める人も少ないと思いますし、その会社さん自体が長期間存続できるかという可能性もそんなにたかいわけではない。ので人事制度や昇進制度が整っていない会社も多い。
 
「枯れた技術」しか使用できない
※枯れた技術とは、「時代遅れだが、安定していてノウハウが既に確率している技術」のこと。Slerのビジネスにおいては仕様書道理のものができればいいというのがほとんど、新しい技術を使うメリットが特にないというかものがちゃんとできればいいのでリスクの少ない「枯れた技術」が好まれる古いけれども安定していてノウハウが確立されている技術が好まれる
※Web系企業と比較するとプログラミングとエンジニアリング周りの技術面で時流にキャッチアップできなくなる可能性が高い。特にメーカー系やユーザー系の企業はそもそもプログラミングを行わないのでそちらに行ってプログラミングスキルを磨こうというのは基本的にはほとんど無理と考えていいと思います
 
給与を揚げたければ上流にいくか管理職になるしかない
※プログラミングやエンジニアリング系の技術を深めて行きたい人のキャリアパスが用意されていない場合がほとんど。例外はある。基本的にエンジニアリングの技術はある年齢からは全く重視されなくなるというかマネジメントだったりとか人員をマネジメントできる能力だったりとか。マネジメント系の能力がSIerさんでは給料をあげる上では非常に重要になる
 
スタートアップ企業は存在しない
※利益構造が労働集約型で儲けが受注額を超えることがない、つまり「収益がスケールしない」ので投資対象としての魅力が薄い。
ベンチャーキャピタル(VC)がSlerに投資するというケースは聞いたことがない
 
Microsoft系のテクノロジーを使った開発案件が多い
※Web系企業ではサーバーサイドには「Linux」というOSを用いることがほとんどなので「.NET Framework」や「SQL Server」等の、Microsoft系のテクノロジーを使った開発が行いたい場合は独立系Sler以外の選択肢はあまりない。Microsoft系の技術を学びたい場合は、独立系SlerさんでMicrosoft専業でやっているみたいな所に行くしかないかなあと思います
 
客先常駐が非常に多い
※Web系企業では基本的に自社サービスの開発がメインなので、自社のオフィスまたはリモートワークの場合は自宅等で働けるが、中小独立系Slerの場合は発注元の企業や上流の会社が定めた作業場所で働かざるを得ないことが多い 
 
スーツ勤務を指定されることが多い
 
リモートワーク可の職場は少ない
出社しないで、自分の家とか好きなところ、カフェとかで働いてもいいよという    web系企業の会社さんが増えてきてるSlerさんでもあるとは思うんですがかなりレア。客先常駐の事があったりだとか、大企業文化というかそういうところがあるので、基本的にオフィスに出社して働こうという感じでリモートワークで働きたいという感じでは適切なSlerさんを見つけるのは難しいかも
 
情報発信に熱心ではない
※Web系企業はリクルーティングも兼ねてエンジニアの人たちが書く「エンジニアブログ」を公開しているケースが多いがSlerでそのような情報発信を行っている会社はあまり見たことがない
Slerはそもそも技術的に新しい技術に取り組める機会が少なかったりするので、そもそもエンジニアブログに書くことがどうしてもないという感じだったりとかセキュリティや契約的なしがらみで技術情報を公開できない環境になっているからですね。web系企業は基本的に自社のシステムを作っているのでもちろん公開できない情報も多々あるんですけども技術的な部分で公開できる情報も多々あるのでweb系企業はそういう情報を外部に公開するっていうのに非常に積極的それに関連して、業務中はツイッターFacebookにアクセス禁止になっている。それはネットワークで遮断されているのでSNSにアクセスできない。それは情報漏洩防止のため。
 
コミュニケーション手段が未だにメールのところが多い
※最近のWeb系企業はコミュニケーションツールにSlack等のチャットツールを使ってやり取りすることが多いんですがSlerさんだと未だにメールでやり取りするケースが多い。Web系企業さんだと勤怠連絡にLINEを使ったり積極的にいろんなSNS使ったりしてるんですけどもSlerさんとかだと社内のコミュニケーションもやっぱり昔のツールを使いがち、なかなか新しいツールを使うことが難しい傾向がある

Railsでポートフォリオを作るまでの学習順序と具体的な教材について

こんにちは、たなかです。以下YouTube文字起こしです。自分のためのメモとしてここに記載します。

参考にしたYouTube

https://www.youtube.com/watch?v=8UtQPtxbXF0

 

学習順序
コンピュータサイエンス基礎
Linux基礎
HTML/CSS/JavaScript基礎
Ruby基礎
SQL基礎
GitとGitHub基礎
Rails基礎

オススメ教材
コンピュータサイエンス基礎:キタミ式イラストIT塾 基本情報技術者
Linux基礎:Linux標準教科書
HTML/CSS/JavaScript基礎:Progate・dotinstall
Ruby基礎:Progate・dotinstall
SQL基礎:Progate・dotinstall
GitとGitHub基礎:Udemy「はじめてのGitとGitHub
Rails基礎:「Rails Tutorial」

point:「学習を開始してからポートフォリオを作り切る期間をできるだけ短くする」
人間は古い記憶からどんどん忘れていってしまうのでRubyとかRails基礎学習が完了してからポートフォリオ作りに入るまでに数週間とかの間が空いてしまうとまたある程度時間をかけてRubyRailsを復習しなければいけなくなって、そんな感じで色々なことを復習しているうちにどんどん時間が経ってしまい、ポートフォリオ作りが全く前に進まないみたいなことになってしまうので、なるべく記憶が新しいうちにポートフォリオ作りに入って短時間で作り切るようにしないと、挫折する可能性が非常に高くなってしまう。

以前の動画で週の学習時間は20時間程度確保しましょう。という話をしましたが、それでもかなり少ないぐらいなので、人それぞれ色々な事情があるとは思いますが、とにかく間を開けずに記憶が新しいうちにどんどん先に進んでいって短期間でポートフォリオ作成までやりきってしまうことをお薦めします。

また、最近はWeb系エンジニア志望の方が非常に増えて、さらにweb系自社開発企業さんに転職するためのルートが可視化されたことでポートフォリオの平均レベルがどんどん上がってきているので、「Rails TUtorialに毛が生えた程度のポートフォリオ」だと他の求職者の方たちと差別化が出来なくなってきている。特に学歴面、職歴面、年齢面でフリのある方たちは、機能をもっと豊富にするとか、インフラにAWSを使うとか色々工夫しないとある程度レベルの高いWeb系自社開発企業さんの書類選考は中々突破できないと思います。

採用担当者の方たちは皆さんが「どれだけ頑張って勉強したか」ではなくて「学習した内容を良質な成果物に落とし込めるだけの自走能力があるかどうか」を見ているわけなので一生懸命学習したけどそこで燃え尽きてしまってしょぼいポートフォリオしか作れなくて結局Web系自社開発企業さんに転職できなかったみたいな悲しい事にならないように最後まで気持ちを切らさずに頑張っていただきたいなと思います。

 

【皆知らない】仕事ができない人の「文章の書き方」10選

こんにちは、たなかです。久々の投稿になってしまいました。
【感想】
文章・情報の構造化能力ってビジネスマンにおいて何よりも必要な能力。原因がわからないけど読みにくい文書を書いている自分にぴったりでした。
自分から学んでかないとビジネスライティング伸びてかないなと思いました。
参考にしたYouTube
 
 
1.並列じゃない情報に箇条書きを使う
 箇条書きを使う条件
 「・」のあとに書かれたひとつひとつの情報が独立している
 2つ以上の並列な情報がある
2.順序じゃない所に数字番号の箇条書きを使う
 これは並列な情報なんだ。順序なんだという理解を助けるのに役立つ
 理由①②③、その①その②その③、原因①②③と言葉を添えてあげるといい
 「理由は3つあります。」と概要から示すとより良い
3.「→」を多用する
 めちゃくちゃ汎用性が高く「→」がどんな意味をもっているかわからなくなる
 「因果関係」を表すときだけ限定
 ex.「事象Aが発生」→「その結果Bになった」
4.逆説か順接かわからない接続詞「が」を使う
 「が」には順接と逆説両方の意味がある、相手に文脈から読み取る手間が派生するので分かりづらい
 ex.今年は景気が落ち込んだものの、売上は落ちていません。
 ex.今年は景気が落ち込みました。しかし売上は落ちていません。
5.「です」「思う」など同じ語尾を連続する
 同じ語尾を連続すると幼稚な印象を与える
6.主語と述語が対応していない
 主語と述語で短い文書を書く
7.文字壁を作る(50・5の法則)
 文章を書くときにやっては駄目なこと
 一文50文字以上書く
 一段落に5文以上つめこむ
8.文章に見出しを作らない
 見出しは本文を作りながら都度見直していくもの
 抽象から具体に落としていく(演繹的に考える)
 具体から抽象に落としていく(帰納的に考える)
 わかりやすい文章を書くには、演繹的かつ帰納的にわかりやすい文章を何度も見直して構造を作り変えていくことが不可欠
 ■見出し◎小見出し
 ex.
  ■今日の本題
 ◎概要
 ・〜〜〜
 ・〜〜〜
 ・〜〜〜
 ◎議題その1
 ・〜〜〜
 ・〜〜〜
 ・〜〜〜
9.タイトルで相手に求めることが判断不能
 あなたの文章を読んで私は何をすればいいの?が明確になる
 人に文書を送るときタイトルの一番最初に以下をつける
 【相談】【共有】【連絡】【依頼】【決算】【お礼】
10.タイトルに「〜について」を使う
  〜については汎用性が高すぎるその結果なにが言いたいのかわかりにくくなる
 ex.
 ✕ 来週実施予定のキャンペーンについて
 ○【相談】来週実施予定のキャンペーについて予算を決めたいです
 ✕社員の健康診断について
 ○【重要な連絡】健康診断の受診方法
 

メンタル弱い性格を変える10の介入行動

こんにちは、たなかです。

参考にしたYoutube

https://www.youtube.com/watch?v=OCjctkidm1o

 

感想

自粛ムードの中、気分が落ち込んできたので、見てしまった。

話の内容は「行動によって自分の性格を変えよう」というもの。

自分がやってる筋トレもこれに入るんではないかな。

紹介される2つの行動は、新しいことではなかったけど、これでメンタル強くなるのという驚きがある内容だった。

この行動にどういう意味があるのか、どういう効果があるのかわかっていないと十分にその行動からの効果がえられない。のでしっかり意味を理解していきたい。

 

結論

10:29「今日は楽しい行動を選ぶように心がけよう」と朝起きたら自分に言い聞かせる。

13:33「辛いことが会った場合に何回か深呼吸しましょう」

 

 

10:29「今日は楽しい行動を選ぶように心がけよう」と朝起きたら自分に言い聞かせる。

 

効果

楽しい行動を選べない状況とは、普段は楽しい行動も選択肢の中にあるのに、メンタルの弱さ故に楽しくない行動を選んでしまっている。

人の目を気にしたり、こういう風に言われるんじゃないか、自分のキャラと違うとか関係なしにつまんないとか、いらないと思ってる行動を取るのをやめましょう。それを決意しろ。

また、朝ネガティブなことを考えるとIQが下がる。

認知能力が落ちたりする。

 

13:33「辛いことが会った場合に何回か深呼吸しましょう」

 

効果

2,3分深呼吸を繰り返すとストレスは半分になる。ぐらい呼吸は重要。

呼吸法が緊張を緩和する。のに加えメンタルが強くなることがわかったから素晴らしい。

吸う息と吐く息の比率=吸う時間(緊張):吐く時間(リラックス)で考える。

緊張しているときは、まず息を吐く。吐いてるときに副交感神経が有になる。

 

 

 

 

99%の人は「考える」が出来ない

こんにちは、たなかです。

 

参考にしたYoutube

https://www.youtube.com/watch?v=gKJUWUMfAFo

https://www.youtube.com/watch?v=zZwg4dNe9nE

 

【アウトプットしてよかったこと】

認知バイアス(物事を短絡的に考える癖)にかかっていた

具体:理解度10%(50%理解した気になっていた)→理解度70%

考える:「自分が今何を考えているかを文章に落とすこと」

 ・自分の考えの論理が通っているのか抜け漏れがないか客観視できる

 ・「もしかしたらこれってこういうことかも」とはっとする体験し、何も考えていなかった所に気づく=認知バイアスから抜け出せた瞬間

【アクションプラン】

発散フェーズ

 0秒思考する

収束のフェーズ

 0秒思考を元に「これからどうするか」を決める

 他人にまとめたものを見せたとき、「なるほどね!確かにそれが一番いい選択肢だ ね」と思ってもらうように書く。

 できる限り簡潔なアクションプランとやるのがよい理由を書く

 ※収束フェーズで発散フェーズに戻ってもOK

 

【0秒思考やり方】

・紙に問いを1つ作ってそれに対して答えを書き出す。

・書いたら次の紙に移ってまた次の問いを書く(先程の続きでも続きでなくても可)

・これを10分間繰り返す

ポイント

 どういう問いを立てれば良いのか、

 問いに対してどういう答えを書くのが良いのか

 何も難しいこと考えず悩む必要はない。

 悩んだら手を止めてすぐ次に行きましょう。

 

【0秒思考要約から】

・すべての思考は、言葉によってなされ、感情も言葉にできる。

 思考と言葉は強く関係している

・時間をかければ考えが深まるとは限らない

 調べすぎて決断が遅くなる

 

 

【9割の人ができない】「仕事が遅い人」がやっていないたった一つのこと

こんにちは、たなかです

参考にしたYoutube

https://www.youtube.com/watch?v=ArMNB_QTSXw

 

結論

仕事をする前に、「アウトライン」を作り込むこと

①アウトラインを作り込むとなぜ仕事が早くなるのか

②最強のアウトライン作成法

 

①については、ずばり、「やり直しの少なさ」

以前の記事でも自分のためのメモあり。

アウトラインの作成とは、実際に仕事に手を付ける前に仕事の全体感を詰めることを指します。

②最強のアウトライン作成法

いきなり手を付けると膨大なやり直しが発生します。

このやり方でやれば一番漏れなく作れるっていう最強のフォーマットがある、

これから言う方法で作ると吉。

 

・ゴール(得たい成果)

・現状の課題(現状との間にある壁)

・解決策(壁を壊す方法)

 

この中で最も大事なのがゴール。ここで仕事の9割が決まる一番の頑張りどころなので気合い入れてやりましょう。

本当に得たい成果を考えないといけない。

よく油断してやらかすミスは、曖昧な言葉で定義すること。

ゴールの設定は、誰が見ても解釈のズレがなくなるくらい具体的に定義することがポイント。

ゴール、現状の課題、解決策を文章化出来たら上司に送ってフィードバックをもらい、認識のズレがないか徹底的に詰める。