【テンプレあり】始末書の正しい書き方のポイントを、例文と併せて解説

社会人であれば、一度は耳にするワード「始末書」。ここでは、そもそも始末書とはどのような文書のことを指すのか、また、始末書の基本構成、書き方、NG例、テンプレートについて紹介します。

テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元：GMOリサーチ株式会社　調査期間：2021年8月12日～8月16日　調査対象：2020年8月以降にプログラミングスクールを受講した18～80歳の男女1,000名　調査手法：インターネット調査

なにか仕事上でトラブルをしたときには、始末書を書くことになります。しかし書き方がわからないといって、それを尋ねるとまた怒られる可能性があります。

なので今回は始末書の書き方を、具体例を交え解説していきます。

始末書とは

仕事上でミスしたことやトラブルを起こしてしまったことなどの不始末に対して、反省や謝罪の意を示すために会社に提出する書類のことです。

始末書の基本構成

始末書は、次の5つの基本構成で成り立ちます。

トラブルの内容
トラブルの原因
反省やお詫び
同じことを繰り返さないように対処法を提示
寛大な対応をお願いする

基本的には、この流れの通りに作成します。

[PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座

書き方の例

始末書は、次のように作成します。

宛先
日付
題名
本文

本文には、ミスやトラブルの原因が自分にあることを認めて、お詫び・反省の弁を記載します。そして、事態の収賄に努めて、同じことを繰り返さないように誠意をもって謝罪の気持ちを伝えます。

書き方のNG例

始末書では、ミスやトラブルなどの不始末を正直に申告して、心から反省の気持ちを表すことが重要です。そのため、始末書は便箋に手書きで書くのが一般的です。会社によっては、パソコンでの始末書作成が許可されている場合もありますが、相手に反省の気持ちが伝わるように、本文は必ず手書きで書きます。
そして、言い訳は反省不足だと捉われてしまうので、一切書かないようにしましょう。また、「〜しないように気をつけます」、「〜したいと思います」などという曖昧な表現も避けましょう。

テンプレート

【宛先】
■■株式会社　代表取締役　■■様

【日付】
令和■■年■■月■■日

【題名】
始末書

【本文】
私はこのたび、社の機密事項を含む重要書類を紛失してしまうという重大な不始末を犯しました。
これは、職務に対する私の軽率な姿勢が起因していることは言うまでもありません。現時点では具体的な被害が発生していないとはいえ、次第によっては会社に重大な弊害を与えかねない不始末であります。会社ならびに関係各位に対し、深くお詫び申し上げます。

今後は与えられた職務とその責務について強く自覚を持ち、二度とこのような不始末を起こさないことを誓います。何卒寛大なるご措置のほどをお願い申し上げます。

以上。

まとめ

始末書は、ミスやトラブルに対しての謝罪や反省の意を会社に示す書類のことです。前述した5つの基本構成にそって、事実をありのままに記載し、誠意をもって謝罪の意や再発防止に努める旨を伝えましょう。

始末書は、気持ちが伝わるように本文は必ず手書きで作成します。反省不足だと捉われてしまう場合もあるので、くれぐれも言い訳や曖昧な表現は使わないようにしましょう。始末書のテンプレートもぜひ、参考にしてみてください。

また、当メディアを運営している（株）キラメックスでは、オンラインのプログラミングスクールTechAcademyではエンジニア転職保証コースを提供しています。

プログラミング未経験の方でも12週間で東京のIT企業へエンジニアとして転職を目指せるコースです。

現役エンジニアとキャリアカウンセラーによる学習と転職のサポートを受けることができます。

【テンプレあり】催促状の正しい書き方のポイントを、例文と併せて解説

ビジネス上の取引で度々トラブルとなるのが料金の未払いについて。さまざまな理由はあるかもしれませんが、全く報告や相談なく未払いというのは許せないことです。 ...

ビジネスマナー

【例文あり】ビジネス文書・メールで頻出「後ほど」の意味と正しい使い方とは

ビジネスシーンはもちろん、日常生活でも使うことが多い「後ほど」と言う言葉。便利な言葉ですが、正しい意味や使い方を知っている人は意外と少ないのではないでしょうか。...

ビジネスマナー

仕事で役立つ日報の書き方のポイントはなに？明日から使えるテンプレも紹介

毎日の記録や報告を記載する代表として日報があります。これは自分自身の備忘録だけでなく、チームや上長に今の自分の仕事の進捗度を知らせ、マネジメントしてもらうために...

ビジネスマナー

便利なツールも活用してみよう：負担を減らして会議を効率化するためには

会議はさまざまな関係者と一緒に仕事をすすめていく上で欠かすことができないものです。会議はできるだけ効率的に生産性のあるものにしたいところですが、段取りが悪かった...

ビジネスマナー

【例文・テンプレートあり】情報は正確に！異動挨拶メールの書き方解説

会社で働いている定期的におこるのが異動です。異動をすると、今いる部署では引き継ぎや送別会、新しく入る部署でも業務の整理や歓迎会など、双方やらなければいけないこと...

ビジネスマナー

信頼関係を崩さず行う値引き交渉のポイントとは？

仕事をしていると、どうしても予算内に物事を進めるのが難しい場面に遭遇することがあります。そんなときは値引き交渉を行いたいもの。しかし値引き交渉は先方に不...

ビジネスマナー

あわせてよく読まれている記事

【例文・テンプレートあり】基本のビジネス文書をマスターしよう：始末書の書き方

社内外に向けて反省の意を示す始末書。これまで書く機会がなかったという人も多いかもしれませんが、社会人である以上いつ始末書が必要となる状況に陥るか分かりません。万が一の状況に備えて、始末書の書き方や例文、NG例を確認しておきましょう。始末書とは始末書とは、仕事上でトラブルやミスなどが発生した時に、社内外に対してその内容を報告し、真摯な反省や謝罪の意を表するために提出する文書です。例としては、社内規定に違反した場合や、取引先に金銭的損失を負わせた場合、会社の社会的イメージを損ねてしまった場合などに始末書の提出が必要となります。始末書のほかにお詫び文書として知られている文書には、反省文、顛末書、詫び状、謝罪文などがあります。始末書と顛末書がほとんど区別なく使われる場合もあります。厳密には、始末書は不始末やトラブル、ミスを詫びる反省文で、顛末書はなぜそのような事態に陥ったかを報告する文書です。お客様などに対してお詫びを述べる文書は、詫び状や謝罪文と呼ばれる場合が多くなります。始末書の基本構成始末書を社内向けに作成する場合は役職名と個人名で直属上司を経由して社長や部長、課長などの組織責任者宛てに作成します。社外向けの場合は、所属する組織代表者の印を得て、相手組織の代表者宛てにします。始末書本文の構成には以下の4点を入れ込みましょう。自分もしくは自社のミス、失策の内容始末書本文のはじめには、自分もしくは自社のミスや失策の内容と経過を書きます。細かく詳しく書くのではなく「いつ、どこで、誰が、何をした」というような要点を簡潔に述べるようにしましょう。迷惑をかけた相手に対して真摯に謝罪する真摯に謝罪の弁を述べ、誠意を示すようにしましょう。ミス、失策の原因の説明ミスや失策の原因を、客観的に見つめ冷静にまとめて説明します。この時、自分を正当化する内容や言い訳にならないように注意しなければなりません。再発防止対策の方針や心構えを述べるミスや失策を二度と繰り返さないため、このような方策を完遂しますといったことを述べます。今後は規則に従いますなどの誓いの言葉で締めくくりましょう。 [PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座例文【社内宛ての例文】平成○○年○○月○○日代表取締役社長　山田太郎様始末書私は、社用車による駐車違反を犯しました。ここに始末書を提出し、深くお詫び申し上げます。私が駐車違反を犯したのは、○月○日に商品を得意先に納品しようと社用車に乗車した際のことです。納品先の駐車場が空いていなかったため、公道に駐車して納品を行いました。車を離れたのは10分程度でしたが、納品を終えて戻った時には車に駐車違反のステッカーが貼られており、罰金15,000円を科せられました。今後、社用車を運転する時に事前に駐車場の有無や台数を確認し、駐車できない可能性がある場合は駐車場案内システムを利用します。納品先まで駐車場から距離がある場合は台車を利用するよう心掛け、二度と同じ過ちを犯さないよう致します。この度は私の不心得きから会社にご迷惑をお掛けし、重ねてお詫び申し上げます。営業部高橋　二郎　印【社外宛ての例文】平成○○年○○月○○日株式会社　○○ 総務部長鈴木三郎様　　　　株式会社　△△ 　　　　代表取締役社長　　　　田中四郎　印　　始末書急啓、ご依頼いただいたアプリとは別のアプリを納品するという過ちを犯してしまい、御社には多大なるご迷惑をおかけしました。不始末の段、心よりお詫び申し上げます。ご依頼内容や納品内容を正確に確認し、納品することは基本中の基本です。その基本が守られていなかったことに、会社の代表として責任を痛感し、深く反省しております。今後は、二度と同様の過ちを起こさないために、体制の強化を図り、社員教育をさらに徹底していく所存です。何卒、寛大なご配慮を賜りますようお願い申し上げます。この度の納品違いに関し、本書をもって深くお詫び申し上げる次第です。以上書き方のNG例「○○しないように気を付けます」「○○したいと思います」曖昧な表現は避けて、「○○しません」「○○します」のように明言する形にしましょう。「今回のことでご迷惑をお掛けし、大変申し訳ございませんでした」「今回のこと」が何を指しているのか分かりません。何に対して謝罪しているのかを具体的に示すようにしましょう。「幸い大事に至りませんでしたが」相手は大事であったと捉えているかもしれませんので、この表現は避けましょう。「何卒、事情察して下さい」「どうぞ、ご理解ください」相手を説得する必要があるときに使う表現です。謝罪が目的の文書では使用を控えましょう。まとめビジネスパーソンにとって、いつ必要となるか分からない始末書の書き方や例文、NG例を紹介してきました。会社によっては書式が決まっていたり、テンプレートが用意されていたりしますので、その場合は会社の意向に従いましょう。謝罪の気持ちや誠意が伝わるよう表現に気を付けて始末書を作成してください。 IT業界でおすすめの転職サイト・エージェントもまとめているので、転職を検討している方はぜひ活用してみてください。また、TechAcademyは、積極的に情報集取を行い学習、成長していくビジネスマンの今後を応援しています。そんな方々におすすめなのはIT業界でキャリアを描くこと。IT業界は成長産業であり、上昇志向や成長志向のある人であれば幅広いチャンスを掴むことが可能です。しかし、総合職であっても技術職とコミュニケーションが取れる人材が求められています。 TechAcademyにはIT業界で活躍したい方向けに無料でプログラミングを学び、転職支援も受けられるTechAcademyキャリアというサービスがあります。専門知識を効果的に学び、プロのコンサルタントの支援のもと行う転職活動でより自分にあった企業と出会ってみませんか。 IT業界でキャリアアップを目指したい方はぜひTechAcademyキャリアをご覧ください。

ビジネスマナー

【テンプレあり】事故報告書の正しい書き方のポイントを例文と併せて解説

営業や出張などで仕事中に車を使う人も多いでしょう。そういう人は常に交通事故に気をつけていますが、被害者となることだって十分にあります。起こしてしまったものは仕方ありませんので、対応をすぐにすること・次に起こさないことが大事です。そして経緯や詳細を報告し内部で情報を蓄積し啓蒙活動をするのが重要です。今回はそんな事故を起こしてしまった際の、報告書の書き方を具体例を交え解説していきます。事故報告書とは事故報告書とは、業務中に起こった事故を上司に速やかに報告するための書類です。例えば、通勤中や移動中に事故に巻き込まれた場合や、事故を引き起こしてしまった場合には、事故報告書を提出しなければなりません。また、交通事故だけでなく、医療や工業などの業務で仕事中にケガをしたりケガをさせてしまったりした場合にも事故報告書が必要です。事故報告書を提出することで事故の状態を整理し、再発防止に努めることができるでしょう。さらに、会社側がトラブル発生時の状況を理解し、会社として正しい対応をするためにも欠かせない書類となります。事故報告書の基本構成とポイント事故報告書を書くときには、次の3つのポイントを守ることが大切です。 ①5W1Hを意識する事故報告書は、事故の状態を上司や第三者に正確に伝えるための書類です。事実の食い違いを起こさないためにも「5W1H」を意識しましょう。どこでいつ誰が何をどのようにどうしての6つを意識して、できるだけ簡潔にまとめましょう。 ②事故処理の状況や添付職類をつける起こしてしまった事故が現状、どのように処理されているのか明確にします。医療費用、修繕費などがかかった場合には、そのことを記載しましょう。また、事故に巻き込まれた場合などは、通院費や保険料などが分かる資料を添付するのもいいでしょう。 ③事故が発生してから、速やかに提出する仕事中に起こったトラブルは、できるだけ早く解決することが大切です。そのため、事故報告書も後回しにしないで、早く提出するようにしましょう。事故報告書を見せながら報告をすることで、指示を仰ぐこともできます。 [PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座事故報告書の書き方の例やテンプレート事故報告書を書くときは、まず事故報告書を提出する相手の名前を記載します。続いて、事故があった日時や場所を記載して、事故の状況をできるだけ簡潔にまとめましょう。その後に、被害状況を記載し、最後に再発防止のための対策を記載するといいでしょう。こちらに非がある場合は謝罪文や反省の言葉をこちらに非があるのにも関わらず、事実だけをまとめた事故報告書はNGです。非を認めて反省する気持ちを伝えるために、反省の言葉や謝罪文を記載するようにしましょう。また、どうしてこのような事故が起こったのか理由を明確にし、再発防止につなげるような文面となるよう心がけるといいでしょう。使いやすいテンプレートさまざまな事故があるので事故報告書の形式をまとめることはできませんが、例として使いやすいテンプレートは下記のものとなります。 ○○様交通事故報告書このたびの事故につきまして、大変ご迷惑をおかけしました。誠に申し訳ありません。以下に事故の詳細を報告いたします。記 1．事故の概要（1）発生日時　平成○年○月○日　 ○時頃（2）発生場所　○○市○○駅の交差点（または、○○工場の1回など）（3）事故内容　出会い頭に追突（または、業務中に転倒したなど）（4）被害者対象　○○　○○ （5）被害状況 2．事故の原因前方確認をしっかりと行ってしなかった（または、整理整頓ができていなかったなど） 3．今後の対策運転中は気を引き締めて、周囲の状況を確認する（職場の環境を整えるなど） 4．特記事項特になし。今後は、このようなことがないよう努めます。申し訳ございませんでした。以上記載しなければならない項目を箇条書きにすることで、記載漏れが起こらないようになります。また、簡潔にまとめやすく短時間でも情報整理ができます。事故報告書の書き方の例やテンプレート事故報告書は、万が一の事態に備えて、書き方を知っておくと便利です。5W1Hを意識し、事故の状態や対応を明確に伝えられるように心がけましょう。事実をしっかりと伝えられれば、会社側も適切な対応ができます。テンプレートを活用しながら必要な情報をまとめて、速やかに提出します。また、自分に非がある場合には謝罪の気持ちや反省の意、再発防止への取り組みをしっかりと述べて、上司などに悪い印象を持たれないようにしましょう。また、当メディアを運営している（株）キラメックスでは、オンラインのプログラミングスクールTechAcademyではエンジニア転職保証コースを提供しています。プログラミング未経験の方でも12週間で東京のIT企業へエンジニアとして転職を目指せるコースです。現役エンジニアとキャリアカウンセラーによる学習と転職のサポートを受けることができます。

ビジネスマナー

【チケット売買アプリを事例に！】Googleへのアプリインデックスは努力に値するのか

本稿は、Smashing Magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、Vivid Seats（チケット売買サービス）のSEOディレクターであるBryson Meunier氏によって投稿されました。 Googleの検索結果にアプリが表示されるように、App indexingを実装することにリソースを投資するのは、アプリのトラフィックの観点から効果的でしょうか。この記事では、私の会社での活用事例を通して「App indexingを実装することは努力に値するのか」についてその答えを考えます。結果は驚くべきものです。近年、App indexingはSEOにおいて最もホットな話題の1つですが、それにはいくつかの理由があります。 Googleは約2年以上も前から、アプリをインデックスするこの技術をすべての開発者のために公開しています。しかし、実際にApp indexingを実装しているアプリは全体の約30％であり、Webサイトが追加的なトラフィックをアプリにもたらすことができる潜在的な可能性は大きいとしている調査もあります。さらにGoogleは、WebサイトがApp Indexingを利用していることと、アプリがApp IndexingのAPIを実装していることついて、検索順位を上げる要因として考慮するとしています。そのため、App IndexingをWebサイトに実装することは、検索のトラフィックを増やすのに効果的だと思われます。しかし、私の会社で実践してみたところ、効果はありませんでした。 App Indexingを実装したとき、たしかにGoogle検索経由のアプリのトラフックは増加しましたが、Web検索からのトラフィックと比べると微々たるもので、ほとんど努力に値しませんでした。私の会社における活用例と、それが全体のトラフィックへもたらした影響について、詳細をまとめています。目次 App Indexingとは実装した背景実際に行った解決策結果結論 App Indexingとは App Indexingとは、関連する検索結果と一緒に、アプリがGoogle 検索に表示されるようにする仕組みのことです。あなたのアプリで（1） HTTP URL をサポートし、（2）App Indexing SDK を追加すると、GoogleがそのWebページをクロールしてインデックス登録します。その結果、ユーザーは関連するキーワードで検索したときにその検索結果から、アプリをインストール、実行できるようになります。ユーザーがアプリをインストール済みの場合、関連する検索結果の中に、「アプリを実行する」ボタンが表示されます。検索者がアプリをインストールしていない場合には、関連する検索結果の中に、「インストール」ボタンが表示されます。理論的には、この仕組みは素晴らしいものです。ユーザーはWebサイトやアプリを好むかどうかにかかわらず、ソースが明らかで信頼できるコンテンツを見つけることができます。また、アプリの開発者やマーケティング担当者にとっても、アプリストア以外で、新規ユーザーに紹介することができるため、潜在的に利用者数やダウンロード数を増やす可能性を秘めているといえるのです。しかし、「理論的に」優れていることは、必ずしもApp Indexingが実際にトラフィックを増やす効果があることを意味しません。「どのように」また「なぜ」App Indexingを実装するかについて、私は多くの情報を調べましたが、App Indexingがトラフィックの観点からメリットがあるという実例は、見つけることができませんでした（Googleは他にもいくつかのメリットを強調していますが）。そのためマーケティング担当者、開発者が、アプリをインデックスさせることによってトラフィックを実際にどれだけ増やすことができるか把握できるように、自分の会社Vivid Seatsのアプリで試してみました。 Vivid Seatsの事例を考えるにあたり考慮すべき点があります。Bloombergによると、Vivid Seatsは、StubHubとTicketmasterに次いで世界第3位の、最大級のチケット市場です。そのため、元々トラフィックが多いのです。私たちのケースほど多くのトラフィックがないWebサイトや、同等の規模のWebサイトを持っていないアプリの場合は、私たちの結果とは異なるものになる可能性もあります。また、今回のVivid Seatsの事例は、Androidのみを対象としたものです。ベータ版のApp IndexingのiOSについては、まだGoogleのSearch Consoleを利用していないため、iOSアプリの場合にもインデックスや検索順位について同様の結果となるかは不明です。 [PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座実装した背景 Vivid Seatsは2015年9月から、Androidアプリがインデックスされています。当初、Webページと関連付けたアプリのURIをGoogleの検索結果に見つけるのは困難でした。 2016年2月に入っても、インデックスされたアプリのURIは約18で、そして「URI フォーマットはサポートされていません。」というエラー表示つきの35,000以上のページが見つかります。このエラー表示の原因は、当初のWebサイトのものとは異なるURIをアプリケーションに関連付けたため、Googleは関連付けたページを見つけることが難しかったということもあるかもしれません。実際に行った解決策最初に、この問題に関するGoogleのヘルプセクションの指示通り、関連付けるアプリのURIを示す「rel=”alternate”」を含むlink要素をWebページに追加しました。例えば、Vivid Seatsのアデル（Adele）のチケットページ――「http://www.vividseats.com/concerts/adele-tickets.html」――の場合には、次の「rel=”alternate”」を含むlink要素を追加することになりますが、これは関連付けるアプリのURIを示すものであり、モバイル端末のユーザーエージェントに動的に配信されるのです。 <link rel="alternate" href="android-app://com.vividseats.android/vividseats/performer/15313"> アデル（Adele）のチケットページのモバイルビュー（画像：Fawaad Ahmad）この問題の解決策としてGoogleはヘルプセクションでこのソリューションを推奨していたため、最初はこれで解決するだろうと思っていました。しかし、残念ながら実装して数週間が経過しても、GoogleによってインデックスされたアプリのURIの数は増えませんでした。また、Googleのクローラは私たちのWebサイトの多くのページは関連付けされたアプリビューをすでに持っていると判断したためか（その時点では実際にはそうではなかったのですが）、クロールエラーも続きました。そこで私たちは4月に、iOSアプリにおいてユニバーサルリンク、AndroidアプリにおいてHTTP URLをサポートしました。これによりエラーの数を、最多時の約40,000から、現在の約85まで減らすことができました。その結果、インデックスされたアプリのURIの数は、2月の時点における18から、現在の約35,000にまで増えました。これを実現するために、Firebase App Indexingのドキュメントで説明されている手順を実行しました。まずWebサイトの各タイプのリンクが、Androidアプリと対応する、ビューとURIを持っていることを確かめました。これを行うため、以前はアプリには含まれていなかったページタイプ用のテンプレートを設計し、Androidアプリでそれらを構築しました。各ページの固有の情報は、RESTful APIのエンドポイントから動的に提供されるため、テンプレートを設計してコード化するだけで済み、個々のページをコード化する必要はありません。私たちのWebサイトはSSLを実装していなかったため、GoogleのDigital Asset Linksによる要求に従い、Search ConsoleでWebサイトの所有権を確認しました。インテントフィルタをAndroidのマニフェストファイルに追加しました。 getIntent( )を呼び出し、onCreate( )のコードを実行して、アプリをPlayストアにデプロイしました。結果予想通り、インデックスされたアプリURIの数は、12月の18から、9月には約40,000まで指数関数的に増加しました。全体的に見ると、クリック数は919％増加しました。ブランド名を含まないクエリ（例：”Packersのチケット”など、Vivid Seatsというブランド名を含まないその他情報へのクエリ）からのクリック数は、5,500％増加しました。またこれも予想通りですが、インプレッション数の増加（具体的には、ブランド名を含まないクエリによる増加）の結果として、クリック率（CTR）は低下しました。アプリのトラフィック（Search Consoleで「クリック」と定義されています）の数は、インデックスされたアプリのURIが増加した結果、Webサイトのトラフィックに比例して指数関数的に増加しましたが、アプリのトラフィックには現在のところ効果は見られません。約40,000のアプリのURIが追加的にインデックスされても、現在、検索からのトラフィックの99.82％がWebページに送られており、アプリのURIに送られるのはわずか0.23％です。数があまりにも小さい理由はいくつか考えられます。今回の調査では実証はしていませんが、AndroidのモバイルトラフィックはiOSのモバイルトラフィックよりも、割合が低いという可能性もあります。また私たちの場合、インデックスされたアプリのページは、インデックスされたWebページよりも数が少ないです――実際に3倍以上の差があります。今回アプリのURIが多くインデックスされたことによって、トラフィックは指数関数的に増加したため、今後、最終的にGoogleがアプリのURIをすべてインデックスしたときには、トラフィックがもっと増える可能性もあるかもしれません。しかし最大の理由は、アプリのリスティング広告とWebのリスティング広告では、クリック率（CTR）が大幅に異なることだと思われます。ブランド名（Vivid Seats）は、Webにおけるクリック率では全体の約40％を占めていて、通常は平均掲載順位も1位なのですが、アプリにおけるクリック率では1％にも満たないのです。このことは、アプリのボタンはGoogle検索結果の中でナビゲーションとしては目立つものの、ほとんどの人はまだWebサイト上からクリックすることをより好むという傾向を示しています。最後の理由については、App Indexingはまだ新しいテクノロジーであり、検索者がまだレイアウトに慣れていないことが原因かもしれません。将来的にはこの傾向は逆転することも予想できます。しかし現状としては、アプリのページをインデックスさせようと考えているすべての人はこの点を理解しておくことが重要です。検索結果に表示される大きくてカラフルなボタンが、クリック率とトラフィックを増加させる効果があると考えるのは魅力的なことですが、私たちの調査からはこれを実証する結果は得られませんでした。実際の結果はその逆でした。次の表に示すように、アプリのコンテンツにおけるクリック率は、Webにおける場合の半分以下です。 Androidアプリのページは、クリック率は1.55％で平均掲載順位は5.1です。一方、Webコンテンツは、クリック率は4.67％で平均掲載順位は7.6です。アプリの一般的なクリック率（1.75%）は、Webのクリック率（4.69 ％）よりも低くなっていますが、その内訳としてナビゲーションの（ブランド名の）検索語句によるもの（1.13％）は、その他情報のコンテンツによるもの（6.16％）よりクリック率が低いことが判明しました。この内訳の関係はWebコンテンツのクリック率では、逆転しています。ブランド名によるクエリからのトラフィックは、アプリのトラフィックの約56％を占めていて、Webのトラフィックでは約40％を占めています。クエリの種類をさらに詳しく調べるために、2つのタイプに分類しました。第1に、ブランド名のクエリ（vivid seats）またはブランド名を含まないその他の情報のクエリ（Packerのチケット）を含むナビゲーションクエリ、第2に、検索者がWebサイト（www.vividseats.com）またはアプリ（vivid seatsのアプリをダウンロード）を探していることを示すクエリです。検索者がWebサイトまたはアプリを探していることを示すクエリでない場合には、そのクエリにブランド名が含まれているかどうかを確認し、Webサイトやアプリの嗜好について「特定されていません」と記録しました。アプリ名を特定した検索トラフィックは、アプリのトラフィックでは約4％であるのに対して、Webのトラフィックでは1％未満です。クエリの大多数は、検索者がアプリやWebサイトを特定しないで行った検索によるものであり、Webにおいて約99%、アプリにおいて約96%を占めています。検索からアプリへのトラフィックにおいては、今のところ効果が見られません。しかし、ほとんどの開発者がアプリのコンテンツをインデックスさせる本当の理由は、ダウンロードを促進することにあります。幸いなことに、Search Consoleを使用すると、検索からインストールされている状況を確認できます。これはSearch

Webマーケティング

【例文・テンプレートあり】効率・機能を重視しよう：社内文書の主な種類とその書き方

社内文書は社外文書と違って礼儀等の点から難しくないと考えられがちです。何となく作業的になってしまいますが、ビジネス文章としてしっかりと相手に伝わる分かりやすい文章を心がけて作成しなければなりません。ここでは、社内文書を効率的・機能的に作成できるように社内文書の主な種類や書き方を紹介していきます。社内文書のポイントまず始めに、社内文書について基本や作成のポイント、種類を確認していきましょう。【社内文書の基本】社内文書の基本は「しっかりとまとめておく」ことです。内容が相手に伝わりやすく、理解しやすいような表現が必要であり、文章の構成力やまとめる力が重要になってきます。また、文書を伝達する相手次第では、提出するタイミングも重要。相手の仕事に支障がないようにタイミングを見計らって伝達するように心がけましょう。社内文書では、頭語や時候の挨拶等を含めて過度な敬語を使う必要がありません。基本的には最低限の礼儀が守られていれば問題ありませので、文調は丁寧語・「です・ます」を使用して作成します。しかし、読む人の立場や内容によっては敬語等の表現を使い分ける必要がある場合もあります。例えば、始末書の作成の際は反省していることが伝わる表現や敬語を使用して謝意を明確に伝えなければなりません。臨機応変に対応するように心がけましょう。【社内文書の作成のポイント】文書の作成のポイントは「結論から書く」です。どんな文章でもそうですが、長くなったり分かり難かったりすると伝えたい内容が的確に伝わりません。始めに結論から書くことで文頭から確実に趣旨が伝わり、続けて内容を書くことでまとめやすい文章を作成することができます。また、書くことが多くなる場合もあると思いますが、その際は「箇条書き」を利用して見やすく分かりやすいように工夫をしましょう。要点を箇条書きにすることで分かりやすい構成にすることにも繋がりますので、伝達内容によっては考慮すると良いです。【社内文書の種類】社内文書には以下のものがあります。上部から下部への指示に使う文書下部から上部への報告に使う文書社内の連携に使う文書記録のための文書上部から下部への指示に使う文書組織の上部から下部への指示や命令に使う文章としては、以下のような社内文書があります。指示書：業務における指示・命令に関する文書通達文：社則・社内規定等に関する文書辞令：移動や昇進等に関する文書規定文：人事・労務・福利厚生に関する文書【書き方：指示書】指示書を作成する際は、箇条書きや項目を複数に分けることで1文を短く構成し、分かりやすい文章にするように心がけます。指示内容が1枚に収まらない場合は、「別紙の通り」と書き、指示内容を別紙に作成していきます。例えば、経費削減の指示書を作成する場合は、「交通費」や「営業」、「事務」、「その他」と経費削減に関連する項目をナンバリングまたは箇条書きで示し、伝わりやすい構成で作成するようにしましょう。 [PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座下部から上部への報告に使う文書組織の下部から上部への報告や提案、届け出等に使う文書としては、以下のような社内文書があります。報告書：出張や調査等の任務で得た情報を報告するための文書企画書：新規プロジェクトや新しいアイデアをまとめた文書稟議書：提案などの承認や裁決を求めるために関係者に出す文書届け出書：休職・早退・退職願や有給休暇申請、結婚届などの届け出提案書：業務改善等を提案する文書【書き方：報告書】報告書は伝えるべき内容が分かりやすいように箇条書きで作成していきます。結論は端的に記載し、補足資料等があればデータ等をまとめた資料を作成して準備をしておきましょう。また、内容があいまいに伝わってしまう形容詞（少々等）は使用せず、客観的な説明で主観（○○だと思う）を入れないように注意します。社内の連携に使う文書組織や業務の運営において、各役職や部門間での連絡・意思伝達のために使われる文書としては以下のような社内文書があります。通知 : 会議や講習会等のアナウンスで使用する文書依頼書：アンケートの提出や執筆を頼むときに使用する文書回覧板：人事異動や社員の慶弔に関する文書伝言メモ：留守中の電話や来客を伝えるために使用する文書【書き方：通知】通知には社内研修や会議の開催等さまざまな通知がありますが、例えば会議開催等の日時が決まっている場合は日程を明記の上、会議の終了時刻も必ず記載するようにします。また、管理職のように役職がある人、進行中のプロジェクトを抱えている人の研修通知においては、不在中の引継ぎについても言及し注意喚起をするようにします。記録のための文書記録のために使われる社内文書には、以下のようなものがあります。議事録：会議の内容や決定事項について記録した文書人事録 : 人事上の異動などを記録した文書統計・データ : 営業や販売、経理に関する収集データを記録した文書【書き方：議事録】議事録は社内会議や打ち合わせで決定した事項を関係者にアナウンスする公式の文書です。日時や場所、出席者、議事内容等を関係者に分かりやすく伝わるように完結に作成していきます。記入漏れのないよう注意し、記録として残す以上、個人的な意見が入らないようにまとめます。まとめ社内文章もビジネス文章ですので、誤認や誤解が起きないように分かりやすく伝わりやすい文章構成と内容を心がける必要があります。社内文書の種類や書き方を把握し、効率的・機能的に作成・活用できるようになりましょう。 IT業界でおすすめの転職サイト・エージェントもまとめているので、転職を検討している方はぜひ活用してみてください。また、TechAcademyは、積極的に情報集取を行い学習、成長していくビジネスマンの今後を応援しています。そんな方々におすすめなのはIT業界でキャリアを描くこと。IT業界は成長産業であり、上昇志向や成長志向のある人であれば幅広いチャンスを掴むことが可能です。しかし、総合職であっても技術職とコミュニケーションが取れる人材が求められています。 TechAcademyにはIT業界で活躍したい方向けに無料でプログラミングを学び、転職支援も受けられるTechAcademyキャリアというサービスがあります。専門知識を効果的に学び、プロのコンサルタントの支援のもと行う転職活動でより自分にあった企業と出会ってみませんか。 IT業界でキャリアアップを目指したい方はぜひTechAcademyキャリアをご覧ください。

ビジネスマナー

これからのエンジニアに必要なスキルとは【非エンジニアサミット・イベントレポート】

TechAcademyでは、2015年6月14日に『非エンジニアサミット「プログラミングをシゴトにする」』というイベントを開催しました。これからプログラミングの学習を始める方を対象に、第一線で活躍するエンジニアから直接話を聞けるイベントです。第1回目となる今回は、株式会社クラウドワークスCTOの大場光一郎氏、株式会社Fablicの堀井雄太氏をゲストとしてお迎えしました。本記事ではイベントレポートをお届けします。これからプログラミングの学習を始める方は参考にしてみてください。ゲスト大場光一郎氏（株式会社クラウドワークス執行役員CTO） 2001年、伊藤忠テクノソリューションズ株式会社へ入社。在職中、Rubyの導入支援やRubyを用いたクラウドサービスの開発・運用に従事。グリー株式会社インフラストラクチャ部門にて、開発環境からプロダクションをつなぐDevOps周りを担当し、GitHub Enterpriseの導入による開発品質の向上や、デプロイメント支援システムをRubyで開発。 Rubyやソースコード管理に関する講演、著書多数。 2014年1月、株式会社クラウドワークスに参画、執行役員CTOに就任。堀井雄太氏（株式会社Fablic チーフエンジニア）「Fril(フリル)」を開発しているエンジニア。2007年、株式会社ECナビ（現：VOYAGE GROUP）に新卒入社。比較サイトの運営やディレクトリ検索サービス、広告配信システムの開発などを経験。2012年、株式会社Fablicを創業し女性向けのフリマアプリ「Fril」を開発、インフラ、サーバーサイドの開発担当。クラウドワークス大場氏講演まずは、大場光一郎氏から講演いただきました。講演では、エンジニアになったきっかけ、社内の開発体制、これからエンジニアを目指す人に期待することをお話しいただきました。エンジニアになったきっかけ学研の教材に載っていたマンガがきっかけでBASICを使ってプログラムを書いてゲームを作りながら自分でやってみようと思ったのが、一番最初にプログラムを書くことのスタートだったとのこと。その後は、ハードウェアを組み合わせた業務システムを開発している会社に入社。当時は「プログラムさえ書ければいい」と思って社会人をスタートしたそうです。その時のことを大場氏は「今から考えると当たり前ですが振り返るとコードを書けるだけで会社を選ぶのは良くない」とも語りました。またその頃、働いていた会社とは別に、オープンソースを開発するプロジェクトに入り、そのプロジェクトの開発者との交流を通じて、組織の垣根を越えてプロジェクトを進めることを経験したそうです。そのため、大場氏の考え方の根本は「オープン」。実際仕事の中でもオープンソースのように仕事をしているのが特徴なんだそうです。クラウドワークスでの開発体制クラウドソーシングサービスのクラウドワークスの開発体制はどうなっているのでしょうか。特徴は、UX改善会を開催してユーザー体験を大切にした開発を重視していること。「UX改善会」は、3、4人のチームを組んで、ユーザー視点でサービスを使い、サービスにおける課題を見つけ、改善案などをプレゼンテーションに落とし込んで全社員に発表するというもの。社員はもちろん、エンジニアインターンの学生から率直な意見を聞いて改善に役立てているといいます。この取り組みにより、サービスを使い続けていると当たり前になって気づかないことを、改めてフレッシュな気持ちでサービスを見つめられ、実際にサービス落としこんで、日々改善ができているんだそうです。開発分野の他に、クラウドワークスでは日報の書き方にも工夫があり、お互いがどんな仕事をしているか共有し合えるように、他の部署の人でもわかる言葉で伝えることを推奨しているそうです。これからエンジニアを目指す人に期待すること大場氏は「今は技術が折り重なってできているので、深堀りすればするほど深いし、技術の移り変わりも早いので、エンジニアとしては多層的に折り重なる技術を同時に理解できないといけない状況です。」とエンジニアとして必要なことを語りました。そのような状況の中で、初心者としてプログラミングをはじめるのは、チュートリアルなどが充実しているため、比較的簡単で、初心者から中級者に上がるにはいろいろな技術をキャッチアップする必要がでてくるため、1人では限界があるとのこと。そのため大場氏は、勉強会を通して仲間を見つけることや、プログラミング学習のサービスの活用などを推奨しているそうです。また、JavaもRubyも最初は「おもちゃ」と言われていた背景があり、「おもちゃ」と言われているような技術を使ってみることの大切なんだそうです。「イノベーションを起こすようなものは最初おもちゃのように思われがちですが、だからこそチャレンジすることが今後のエンジニアに必要なのではないか」と大場氏は締めくくりました。 [PR] 最短2日でChatGPTが頼れる相棒に！LINEヤフー主催のAI講座Fablic堀井雄太氏講演続いて、堀井雄太氏に講演いただきました。大場氏と同じく、エンジニアになったきっかけ、社内の開発体制、これからエンジニアを目指す人に期待することお話しいただきました。エンジニアになったきっかけもともとは経済学部出身で、大学でもプログラミングの授業で受けていたわけではない、いわゆる文系プログラマーだという堀井氏。それでも大学生のころから漠然とWebサービスを作ってみたいと思っていたそうです。そこで大学生のうちにいろいろな会社でインターンをとして働いていたのがプログラミングを学ぶきっかけ。最初はHTML/CSSを使ってWebサイトを作るところからはじめ、本を読み込んでサービスを作ってみるなど独学で学んだとのことです。その後、ECナビ（現在のVOYAGE GROUP）に新卒で入社し、自社プロダクトの開発と運用をして、後半の2年はインフラの部署に所属されていました。会社に所属することのメリットとしては、独学よりも体系的に学べる、先輩や同僚がいることで成長できるなどを挙げていました。堀井氏が講演の中で話した、「エンジニアとしては遅咲きだが、遅いということはない。意志があれば、とりあえずやってみるのが大事」という言葉が印象的でした。 Frilの開発体制株式会社Fablicは、2012年7月にフリマアプリのFril（フリル）をリリース。累計ダウンロード数が300万を越えているといいます。現在は、12、13人のメンバーで開発しているそうです。エンジニアはまだまだ増やしたいとのことで、募集も随時行っているとのこと。開発体制として特徴的なことは、ユーザーと一緒に開発すること。実際にFrilを使っているユーザーをカスタマサポートとして採用しているそうです。開発の現場にユーザーがいて、「困ったことがあったらユーザーに聞く」が信条で、実際の開発フローにユーザーが関わるようにしているといいます。これからエンジニアを目指す人に期待することどんなエンジニアになるかを意識することが大事とのことです。会社のフェーズによってエンジニアに求められることは違うので、技術の経験たくさんを積むことが大事。堀井氏自体も、サーバーサイドもインフラも関わってきましたが、今では全てが関係しているそうです。それぞれの領域を学んでいく中で、強みを形成していくのが良いとのことでした。また、技術を学ぶだけでなく、行動して実践することも大事。チームで開発できる、社内で共有できる、社外にアウトプットできる、リーダーシップを発揮できるなど、技術をもとに行動することが今後のエンジニアに求められていると語っていました。また、最後には「ものづくりは楽しいので、楽しみながら開発していくのが大事」というメッセージで堀井氏は締めくくりました。パネルディスカッション「これからのエンジニアに必要なスキルとは」続いて、大場氏、堀井氏によるパネルディスカッションです。モデレーターはTechAcademyを運営するキラメックス株式会社の代表取締役社長の村田がつとめました。パネルディスカッションでは、事前に参加者から募集した質問をもとに回答いただきました。質問はこれからエンジニアになっていくことを想定して、下記のセクションに分けて進めています。エンジニアになる前の段階エンジニアとして働く段階エンジニアとしてさらにスキルアップする段階エンジニアになる前の段階（村田）それではパネルディスカッションを始めていきます。非エンジニアの方のプログラミング学習が一歩前に進むきっかけになればいいなあと思っています。最後には会場のみなさんからの質問も受け付けます。（村田）まず1つ目の質問ですが、「どのプログラム言語から勉強するべきか」という疑問にお答えいただこうと思います。これみなさん非常に悩ましい点だと思うのですが、このあたりお二人はどのようにお考えでいらっしゃいますか？（堀井）最初はPHP、Perl、Rubyあたりから始めるといいのかなあと思っています。理由は、コミュニティが活発なので困ったらそういうコミュニティに相談して聞く環境があることですね。あとは、実際に企業に入ってみて使われていることも多いです。実際、私が新卒で入った会社も主要な言語がPHPであとPerlとRubyも少しあったので就職するときも有利だと感じています。（村田）なるほど。大場さんはいかがでしょうか？エンジニア歴も長いと思いますが。（大場）最初に触る言語としては僕はなんでもいいかなと思ってるんですけど、子供向けや教育向けと呼ばれる機能が制限された言語よりは汎用的な言語を使った方がいいかなと思っています。それがコンピュータが本来持っている能力を引き出せる可能性があるという理由です。なので、あんまり学びやすさとか初心者向けといった軸で選ぶよりは、なんでもできるような言語を選ぶのがいいのではないでしょうか。（村田）では続いてプログラミングを勉強する段階になった際に「どこから着手すればいいか」という質問に入っていきたいと思います。具体的にあれば教えていただけますか？（大場）さっき話したことと関係しているのですが、一つのサービスを成り立たさせるためにはいろんな技術の積み重ねがあって、一部分だけわかっててもサービスとしては成り立たないことがあります。だから、どこからというよりは「これが作りたい」とか「こんなサービスをやってみたい」といったところを目指して、それに足りないのはどこなのか、簡単そうなのはどこなのか、一番難しそうなのはどこなのか、そういう切り分けでちょっとずつ自分がどこにいるかわかるように進めるのがいいんじゃないかなと思います。この言語を覚えたいといった学習の仕方だとモチベーションが続かないと思うんですよね。（村田）それはありますよね。（大場）コンピュータという分野も3ヶ月勉強した人や10年仕事で使ってますという人とか経験にいろいろあっても、その中で「マスターしました」って自分で言える人はあんまりいないと思うんですよね。すごい奥が深い世界なんで。だからこの言語をマスターするまでやろうとなると結構どこまでいっていいかわからない。なので、道具として何をやりたいかというところを目標にすると続きやすいんじゃないかなと思います。（村田）目的ありきでその言語をツールとして使って、形にしていくところから足りない部分を補うのがいいんじゃないかということですよね。堀井さんはいかがでしょうか？（堀井）大場さんも仰ったように一つを学べば終わりというものではないですね。プログラミングをするモチベーションを保たないと結局意味ないので、自分がこういうのがあったら便利だなというものをとりあえず手を動かしながら作るのがいいと思います。（大場）さっきTechAcademyのオンラインブートキャンプの説明の中で、Twitterクローンを作るというお話しでしたが、あれってどこまでのクローンなんですかね？投稿するだけだと簡単だけどTwitterを真面目に作ると結構難しいと思うのですが。（村田）Ruby on Railsチュートリアルに載ってるくらいのマイクロポストみたいなレベル感ですね。ユーザー登録ができてフォローして、その投稿がそれぞれタイムラインに一列に出てくるクローンです。（大場）フォローもするということは、ある程度データベースの関係性もグラフみたいなところもやるんですね。そういう意味では歯ごたえのある感じですね。（村田）そうですね。実際に世界中で使われているようなサービスに近い形で作る方がモチベーションが上がると思っています。全く使わなそうな図書館データベースを作るよりもTwitterクローン作る方がイメージがわきやすいし面白いなと感じてもらえるはずです。プログラミングを学習するときのモチベーション、特に一人で勉強する時間が長いので、自分がやる気になるようなところから始めるのがいいのかもしれませんね。（村田）では次にいきましょう。「プログラミング習得をする上でつまずきやすいポイントとその解決方法」について聞いてみたいと思います。堀井さんいかがですか？（堀井）つまずくところいっぱいありますね。特に、環境構築が一つのハードルになるかなと思ってます。弊社でもインターンに来てもらうことが多いのですが、プログラミングを書き始めるまでの開発体制を整えるところで時間がかかることがあります。ただ、今はEC2とかHerokuとか、必要なパッケージがそろっている状態で始められるものもありますね。無料プランを使うか、少しお金を出せばサーバーが簡単に手に入るので、うまく使って最初のハードルを乗り越えてから本を一冊写経してみるといったことから始めるのがいいのかなと思ったりしますね。（大場）個人的には難しいところって技術と技術の境目の部分かなと。例えば、Rubyだとアプリケーション開発の知識がいるし、データベースにアクセスするときにSQLみたいな言語をわかってないといけないし、両方わかってないといけないようなシチュエーションがサービス開発の中でたくさんあります。両方の知識が求められるところでハードルがぐっと上がって、新しいことを覚えるのが難しいのかなと思いますね。その解決方法としては繰り返すということですかね。繰り返していると、「これはこのことだったんだ」みたいに理解できることもあるので、反復するところがコツかなと思っています。もう一つつまずきやすいところとしては、技術の中でそもそも難しいところです。C言語だったらポインタ、Rubyだったらブロックとかですね。そもそも考え方が難しいものがいくつかあって、それを変な例えで理解しようとしても、結局どこかで嘘が入っていたりして本質的には理解できないところがあります。それは難しいものだと受け入れて、わかるまで何回も繰り返すところが必要なんじゃないかなと思っています。（村田さん）そうですね。僕も最初はPHPから始めたんですけど、クラスみたいな概念がそもそも理解できなかったです。その時は、10日くらいわからないまま続けたら理解できました。繰り返しながらやっていくと、ピーンとわかるときがくるので諦めずに繰り返すのが重要ですね。（大場）悟るまでですね（笑）（村田）悟りが降りてきますからね。さて次の質問ですが、「おすすめのプログラミング学習方法はありますか」ということです。いま繰り返しやるとありましたけれど、もうちょっと具体的に聞きたいと思います。大場さんは仕事を始めてから学んだという感じですか？（大場）まあプログラムを書くのがもともと好きでゲームをつくるなかで学びました。Windows3.1が出たときに「マインスイーパ」というゲームが入っていたのですが、当時Windowsが動くパソコンがすごい高かったんですよね。なので、みんなができるように、MS-DOSのキャラクターベースでできるマインスイーパを開発してみんなに配ったとか、そのなかでいろんな技法みたいなものを学んでいったというところです。今はほんと一つのアプリケーションを成立させるのにいろんな技術が必要なので、競争仲間であるとか教えてくれる先輩とかそういう人がいる環境に身を置くところが大事かなという気がします。（堀井）小さいところから考えて手を動かすのがいいかなと思っています。会社に入ってみて思ったのが、システムって完璧じゃなくてすでに困っている人がいるんですね。そこで私もわからないなりに、管理画面にあったらいい機能とかを他の部署の人から聞いたりして、改善や機能追加できるところを調べながら徐々に開発技術を学んでいくところがありました。あとは、勉強会もおすすめです。新卒で入った会社では勉強会を定期的に開催していたので、自分の回が来たら学んできたことを発表しなきゃいけない場がありました。そういう半ば強制的にでも自分のスキルを底上げするようなイベントに身を置いてステップアップしていくのはいいかなと思います。（村田）なるほど。僕も自分で学習してきていたときは、何かインターネット上で気になるサービスをまねてそれと同じ動きを作ってみることをしていました。あとは、わからないところでずっと迷ってるとやる気がなくなっていくので、すぐ人に聞くというのは結構重要ですね。僕は新卒で楽天に入ったので、エンジニアの部署にいる同期を休日にカフェとかに呼び出して、わからないことを聞くというのを結構な頻度でやってました。（大場）あとはオープンソースの開発に関わっていくこともいいですね。そんなに難しくなくても手が足りないというプロジェクトはたくさんあって、それこそプログラムだけじゃなくてドキュメントの追加みたいな簡単なところから手伝うこともできます。それでコミュニティの人たちの顔がわかってきて、だんだん開発に協力していく中でいいプログラムをたくさん読んで、自分がやるならどうしようみたいなことを考えたりすることがスキルアップにつながると思います。エンジニアとして働く段階（村田）では次の項目に入っていきますね。「採用したいと思うエンジニアの特徴」について聞いてみたいと思います。具体的にこんな人がいいなというものがあれば教えていただけますか？（堀井）大前提としてプログラミングが好きなことが当てはまるのかなと思っています。やっぱ好きな人って勝手に自分でどんどん技術習得して、自分自身でスキルアップしていくので根本的にプログラミングが好き、ものづくりが好きという素養はまず見てますね。あとは、Githubとかを使って自分が書いたコードを他の人に見てもらう、シェアするみたいな文化があると思うんですけど、自分の恥をさらすことができる、自分の持っていることをシェアするとかオープンさみたいなものを持っている人は素晴らしいかなと思いますね。（大場）堀井さんのお話の中でもサービス志向のエンジニアみたいな話題がありましたけども、スキルはすごい優秀だけどうちの事業にそんなに興味ないみたいな人は今のステージでは採用が難しいです。なにかしら共感をもってるところのプラスアルファでエンジニアリングを見て採用してます。（村田）会社の規模とかフェーズによっても変わってくるかなと思うんですけれども、やっぱりそのそもそものエンジニアとしてのプログラミングが好きであったりとか、サービスが好きみたいなところは基本的には重要ですよっていうことですね。（村田）では次です。「優秀なエンジニアはどうやって見極めているんですか？」という質問です。大場さんいかがでしょうか？（大場）正直言って僕もこれだというものはないですけど、一番確実なのは一緒に働いたことがある人ですよね。やっぱりいろんな会社にいると、こいつは本当にすごいみたいな人が何人かいたりします。（堀井）優秀の定義にもよるかなと思うんですが、見極めるとしたら今はGitHubとかあるので、どういうコードをその人が書いているのか、アプリなど個人でプロダクトを出しているのかとか見たりしますね。（村田）結局その人がどういう人かとか、どれくらいできるのかっていうのが見えるかどうかっていうのは結構重要なのかもしれませんね。ポートフォリオなりGitHubなり、今だとそういうのが結構アピールしやすい時代かなと思います。（村田）次に行きますね。「プログラミングスキル以外でエンジニアに求めることはありますでしょうか」という質問です。堀井さんどうでしょうか？（堀井）これはもうたくさんあります。まず弊社もベンチャーなのでプログラミングだけできる人は結構厳しいのかなと。具体的に言うと、やっぱコミュニケーション能力が高い人がいたら嬉しいです。実際、弊社はユーザーにヒアリングすることがあるので、ちゃんとそのユーザーさんとコミュニケーションが取れるかとか、仕様が上から降ってくるのを待つのではなくて自分で考えたものをデザイナーやディレクターに発表して巻き込んでいく力みたいなのが問われるシーンが多いです。（大場）エンジニアに求めるコミュニケーション能力でいうと、そもそも人と話すのが苦手だからコンピュータを扱う仕事を選んだみたいなところもあると思うんですよね。立ち上げ初期のベンチャーだと、とにかく作るというところがメインになっていて、そんなにコミュニケーションする必要がなかったりします。でも組織がちょっと大きくなってサービスが伸びてくると、ある時点からチーム開発みたいなものが求められて個人技だけでは限界がきたりします。そういう時にちゃんと自分に求められている役割の変化を感じて、それについてこれるかは考えてほしいなと思ったりします。具体的にはさっきの仕様の話だと、ゆるふわで落ちてきた仕様に対してこんな仕様でできるかと思うか、僕が決めてもいいんだというように受け止めるかで大きな違いがあると思うんですよ。それってエンジニアリングのバックグラウンドがあって、そういう幅のある仕様のなかで可能性として見られるかどうかっていうのは大きな違いじゃないかなと。（村田）自分から能動的に動いて、与えられたものだけじゃなくてしっかりそれ以外も自分で発信できるっていうことを理解した上でスキルを上げていけるような方が優秀になってくるし、それが求められるかもしれないですね。（村田）次の質問ですが、「エンジニアとして働き始めてからどんな勉強が必要ですか」とのことです。基本的にはエンジニアは日々勉強みたいなところがあると思うんですけど、そういったこと以外に何か具体的にあれば教えていただけますか？（大場）最近だとエンジニアの向かう方向性としてフルスタックみたいに、いろんな層の技術をまたがって自分一人でもサービス立ち上げができるみたいなところを目指したりもしますけど、実際本当に伸びてくサービス開発のなかでフルスタックになっていくのはめちゃくちゃ難しいと思っています。他に得意な人がいればなかなか手を出すのも難しい、どこをやってもいいよと言われても躊躇してしまうというところがあったりします。その中でできることは、一つひとつ極めていくところだと思っています。ただ、一個の技術だけで戦ってるとやっぱりリスクも高いので、次はこの専門家になろうみたいな二つ掛け合わせるものが何かあるといいんじゃないかと思います。（堀井）私はどういう勉強をしてたかなと思い返してみると、やっぱり学んでいくには段階的になると思うんですよね。一つの言語を学んで、データベースのことも学んで、今度はその言語の上に動いているフレームワークのことを学んだりと段階的に自分が学んだことに派生して勉強してきました。なので、最終的に自分が得意であると言えるくらいのところまで行けるように深掘りして、一つの技術を学んでいくのがいいのかなと思いますね。エンジニアにもスペシャリストを目指すのか、ジェネラリストを目指すのかいろいろ方向性があると思うんですけど、ひとつ自分はこういうエンジニアだとか自分の代表するプロダクトはこれだとか、そういうものを作れるようになるまでは深掘りすることがいいかなと思いますね。（村田）やっぱりエンジニアとしてどこか一つでもいいので、ある程度極めるというか、できたというところまでやって、そこからスキルの掛け算みたいなところが重要になってくるということですよね。エンジニアとしてさらにスキルアップする段階（村田）最後の項目に入っていきたいと思います。「エンジニアとしてどんなキャリアパスが描けると思いますか」という質問ですが、エンジニアとしてキャリアの長い大場さんお願いできますか。（大場）いまエンジニアの責任者として会社の中での役割を担っていますが、究極的には「事業のためにエンジニアリングをどうするのか」みたいな話になっていくかなと思っています。なので、技術だけではなくて、最近だとよく読んでいるのはマネジメントの本とかビジネス書みたいなところからキャッチアップするような勉強をしたりしてます。（村田）技術だけではなくて、その先の事業をテクノロジーで解決していくみたいなところに進めるようなパスがいいんじゃないかという話ですよね。（村田）では次に、「エンジニアが仕事したいと思う環境はどんなところですか」という質問です。堀井さんいかがでしょうか？（堀井）やっぱりエンジニア目線でいうと自由度が高いであるとか、個人の裁量が大きい方がチャレンジングなことがしやすいですよね。なのでそういう環境をいまの会社で作っていきたいと思ってます。弊社ののコアバリューがいくつかあるんですが、「エンジニアもチャレンジする」というのもあります。ある程度エンジニアの裁量でどういう設計をするかなど決められるような体制になっているので、自分がいいと思ったものをすぐ試せる環境があるのはエンジニアにとっていいのかなと思いますね。（村田）なるほど。では最後の質問として「エンジニアとして成長するためにどんな人がいる会社で働くべきだと思いますか」という質問です。いかがでしょうか？（大場）前職のように本当にエンジニアリングに関して職人みたいな人がいっぱいいるところにいて感じるのは、自分より優秀な人がいるところに身を置くことですね。自分が一番下手になって、あとは登っていくしかないみたいなイメージです。例えば、学生時代にインターンで初めてプログラミングをして、ベンチャー企業を手伝いながら一番下っ端でがんばってたらいつの間にか自分が一番詳しくなっていた。その後、さらに強い奴に会いにいきたいと言って弊社にジョインしてくれたエンジニアがいます。僕自身もいかに自分より優秀な人に来てもらうか、自分自身がキャップにならないようにすごく気をつけていて、優秀な人が活躍できるような環境や会社やサービスが大事だなと思っています。（堀井）これは私もほとんど同意見なんですけれども、自分よりも技術において素晴らしいと思った人がいるところですね。あとは、自分のスキルセットに近しいのを持っている人がいるような環境にいくと、自分のやろうと思っていることが一段引き上げられるのでいいのかなと思っています。あと最近は勉強会とか発表された資料とかがWebサイトにいっぱい上がっているので、そういうのを参考にしながら企業を選んだりするのはいいかなと思ってます。会場からの質問（村田）ここからは会場からの質問を受け付けたいと思います。ーー大場さんにお伺いしたいのですが、ご自身が英語情報で技術をキャッチアップするために気をつけられていることや、社内の方に英語の情報をキャッチアップするためにどんなことをしているのか教えていただけますでしょうか。（大場）今やってることでいうと、オープンソースコミュニティがだいたい英語ベースになっています。日本人しかエンジニアがいないプロダクトでもコミットとかは英語じゃないと受け付けない感じだったりします。社内に関しては、こうしないとみたいなものは今はないのですが、今週の気になる技術みたいなのを社内のGitHubにスレを立てて共有して、みんなが気になった技術は突っ込むようにしています。そういうときに情報ソースが英語のものがたくさんあるので、おのずと危機感が醸成されればと思っています。（村田）他のご質問はいかがでしょうか？ーーエンジニアが少なくて採用が大変だみたいなことを何かで読んだのですが、雇われる側としてどう感じておられるかということと、あと村田さんは育てる側としてどう思われるか教えていただけますでしょうか？（村田）まず育てる側の僕の方から話をさせていただきますね。まずエンジニアが足りてないところは事実です。エンジニアの採用が難しいっていうのは、そもそもマーケットに人材が少ないから取り合いになってるっていうのが一つあります。あとは統計的にもアメリカでは2020年には100万人エンジニアが足りなくなると言われています。日本でも2020年には20〜30万人ぐらいは足りなくなると言われています。インターネットを使ったビジネスはすごい盛り上がって市場も拡大しているのに、そこで働く人が増えていなければ足りなくなりますよね。僕らはそれをエンジニアを増やすことで解決したいと思っています。エンジニアになりたいという方は多いと思っていて、それでも増えないのは仕組みの問題もあると思っています。それが解決できる仕組みがあれば、人が足りないということに対してひとつの力になれるんじゃないかなと。エンジニアが足りないということに対して、大場さんはいかがでしょうか？（大場）エンジニアが足りないと言ってる会社も、2種類あるかなと思っています。 1つはよくよく聞いてみると、あまりエンジニアを大切にするような文化がなくてエンジニアが定着しない会社です。そういう会社の方は、「来てくれても半年くらいで辞めるから、辞めると思ってアウトソースすればいい」といったことを仰る場合もあります。こういったことが負の循環になって常にエンジニアが足りないことが常態化してしまう。僕らみたいなエンジニアリングの重要性を理解していて、Webサービス中心の会社だとまったく事情は違っていて、サービスの成長にともなって、さらに成長させるためにエンジニアは、明確に足りていなくてまだまだ必要だと思っています。TechAcademyさんみたいな取り組みでエンジニアが増えていくのはこれからの日本にはものすごい必要だなと思っています。（堀井）ベンチャーで最近伸びているサービスであれば、やっぱりどうしても人が必要になってきて、実際に弊社でもエンジニアは常にどの職種も募集しています。私もベンチャーの友達とか知り合いも多くて起業する人もいるのですが、その立ち上げにはやっぱりそれなりにWebのことがわかる人がどうしても欲しくなるんですけど、そういうスキルの高い人たちは大手であるとか名の知れた会社とかに勤めています。そもそもその会社からあまり転職市場に出てこないというのは肌感としてはあるので、僕らみたいなベンチャーはいかにいい人たちを見つけて会社のことを知ってもらって、採用につなげるかについていつも苦労しています。なので、需要はかなりあると認識しています。（村田）最後付け加えますね。プログラミングを習い事の視点でみると、換金性の高い習い事だと思うんですね。というのも、例えば10万円払って勉強してプログラミングが習得できれば10万円以上稼げると思うんですね。もちろんクラウドワークスさんのようなクラウドソーシングサービスで仕事を探してそれに応募して自分で遠隔の仕事をするのも一つだと思いますし、自分でメディアを立ち上げるのというのも一つでしょうし。そういった意味でも企業に入るだけじゃなくて働く方法はいくつかあると思います。（村田）お時間になりましたので、最後にこの会の締めくくりということで「これからプログラミングを学習するみなさんへのメッセージ」をお二方からお願いします。まずは堀井さんお願いします。（堀井）私も最初はプログラミング初心者だったんですけど、いろいろ学びながら実際にものづくりができるようになりました。最初はハードルの高い部分もあるのかなと思いますが、楽しみながら学んでいくと自分の可能性も広がって、キャリアを積む上でもいい経験だと思います。ぜひみなさんがんばって欲しいです。プログラミングは楽しいです。（大場）僕からは作るだけじゃなくて問題解決していこうみたいな話もしましたけれども、一方で何かを作り出す・生み出すということは本質的に楽しいことだなと思っています。例えば、快適に作るための環境を整えることに丸一日費やすとか、自分のエディタの設定とか、これだから開発しやすいみたいなことを考えながらものづくりを純粋に楽しむところも実際にあるんですね。そういった気持ちってなかなか社会人になってしまうと忘れてしまったり、思い出せなかったりとかあると思います。今だと、エンジニアになろうみたいなフェーズだといくらでも失敗できるので、何度も作ったり壊したりしながら、ぜひものづくりの楽しみというところを大切にエンジニアを目指していただければなと思いました。（村田）堀井さん、大場さん今日はどうもありがとうございました。イベントレポートは以上です。 TechAcademyではこれからもプログラミング学習者のためのイベントを開催していきます。

イベントレポート

写真と動画の良いとこ取り！Webデザインで話題の「シネマグラフ」とは

本稿は、Webdesigner Depotのブログ記事を了解を得て日本語翻訳し掲載した記事になります。本記事は、 The Deep End Design社のクリエイティブディレクターであるWes McDowell氏によって投稿されました。今年の初めに発行された無数のWebデザインのレポートを読んでいれば、今後が期待されるデザインとして取り上げられたシネマグラフについても、おそらく読んだことがあるでしょう。Webサイトのトップページを飾るシネマグラフのデザイン例も、数多くの記事で紹介されていました。しかし、シネマグラフはどこへ消えたのでしょうか？現状としては、ファッション業界の一部の企業のWebサイトに使われている以外には、シネマグラフは記事の中で紹介されるか、Reddit（レディット：アメリカの掲示板サイト）で語られるだけの存在にほぼ追いやられています。今こそ、シネマグラフの本来の価値を見直し、本来の「Webサイトにおけるヒーロー的存在」として活用すべき時です。シネマグラフが効果的である理由あるWebデザインが流行すると予測されたという理由だけで、ただそれに従うのは、個人的には退屈なことだと思います。むしろ、もし自分でWebデザインの新たなトレンドを開拓できるとしたら、その方が面白いと思いませんか？あるいは、もし目的を持ってWebデザインを創造し、同時にそのデザインによって何らかの問題を解決できるとしたら…？人間の目は動くものを好みます。シネマグラフは数々の記事で話題になったにもかかわらず、（しかもWebデザインのトレンドになると予測されていたにもかかわらず、）シネマグラフを活用しているWebサイトはごく少数であるのが現状です。そのため、まだ現実的な普及率は高くはないので、ほとんどのWebユーザーの目には新鮮なデザインに映るようです。写真としての要素と、動画としての要素を併せ持つシネマグラフには、潜在的に人間の視線を引き付ける力があります。見る人が思わず二度見せずにはいられないようなシネマグラフのデザインには、人の目を上手く欺くような不思議なトリックがあります。「ユーザーの注目を集めることができる」従来、Webサイトでユーザーの注目を集める方法として特に有効だったのは、「動画」です。人間の目は動くものを好みます。しかし、動画は再生時間が短いものであっても、容量が大きくなるというデメリットがあります。もちろん、動画を約1inch（約2.54cm）以下のサイズに圧縮することもできますが、小さなサイズの動画でしかありません。かといって、元の大きな容量のままにしておくと、Webページの読み込みが遅くなります。しかし、シネマグラフを使えば、表現したいと思う動きを自由にデザインできます。また、その目新しさを上手く利用できれば、ユーザーの注目を集める方法としても、シネマグラフは対費用効果が高いのです。多くのユーザーは、シネマグラフを見る機会があまりないため、見たときには思わず視線を奪われ「すごい！」と思う傾向にあります。なぜシネマグラフをWebサイトの主役のデザインとして使うのが効果的なのかを説明するために、実例を1つ紹介したいと思います。 Glendevon Motors社のWebサイトのデザインでは、シネマグラフをトップページに大きく利用することで、商品の雰囲気を伝え、競合企業の中で「一流ブランド」として目立たせる効果を狙っています。選択肢1：既製のCGを使うシネマグラフを作成するには、既製のCGを使える場合も多いと思います。私個人としては、もし思い描くイメージ通りのデザインが見つかり、かつ使用権の価格が予算の範囲内であれば、既製のCGを使う方法もいいと思います。問題はどこで入手するか？です。幸いなことに、入手先の選択肢はたくさんあります。もちろん予算にもよりますが、リソースは豊富にあります。無料で提供されているCGもあります。もし予算として約80ドル（日本円で約8,300円）使えるとしたら、質の高い高精細度のCGが入手できるShutterstockがおすすめです。（アドバイス：シネマグラフのカテゴリが設けられているとは限りません。入手先で探すときには、「シネマグラフ（cinemagraph）」という検索キーワードで探すか、または「動画素材（footage）」のカテゴリから任意の検索キーワードで探す必要があります。）イメージ通りのCGを入手できたら、次に行うべきはファイルの圧縮作業です。これについては、後で述べます。選択肢2：CGを自作する CGが動画より優れているのは視覚的なトリック効果で、それがCGを使う意味です。思い描くイメージ通りのシネマグラフが既製のCGに見つからない場合、あるいはあなたがCGの自作を得意とする強者であれば（そうであれば私はあなたを尊敬しますが。）、シネマグラフをゼロから自作するという選択もあります。短い動画撮影ができるカメラ三脚被写体となるモデル・小道具コンピュータ動画編集用のソフトウェア（※これは任意です。） Adobe Photoshop、またはflixelなどのシネマグラフ編集専用のソフトウェア上のリストが、シネマグラフを作成するのに必要なアイテムです。ただし、効果の高いシネマグラフを作成するには、もちろん良いアイデアが必要であることもお忘れなく。質の高いシネマグラフを作るには？個々のCGのテーマとして何を表現するかは、それを利用するWebサイトのニッチ市場における需要によって大体決まると思いますが、CGの作成全般において必ず押さえておくべきポイントがあります。微かなデザイン：CGが動画より優れているのは視覚的なトリック効果で、それがCGを使う意味です。最も優れたCGのデザイン作品の中には、ほとんど静止画像に近いデザインでありながら、その中のほんの微かな動きが見る人に驚きを与えるようなものもあります。デザインの全体的な構成についても、こうしたコントラストは重要です。もしCGの上に、テキストやCTA（Call To Action：ユーザーの注意を引きアクションを誘導するための要素）を、レイヤーとして重ねるとしたら、全体のデザインが乱雑すぎたり、色が強くなりすぎたりすることがないように注意が必要です。CGは、あくまでこれらの重要な要素を引き立てるために使うのです。かえって注意を逸らすことになっては逆効果です。重要な要素を引き立てる：見出し、サブヘッダ、CTAのボタンなど要素が、シネマグラフと上手く調和するようなデザインを考えましょう。デザインの全体的な構図の中で、どの要素を引き立てるかよく考えることが重要です。動く部分以外は静止させる：もちろんCGには動きが含まれますが、CGの中で動く部分以外の背景は、その動きを引き立てるために静止させます。動画撮影時には、三脚を使ってカメラを安定させるといいでしょう。もしモデルの人物の目だけが横に動くようなシネマグラフを作成するとしたら、人物の頭などがなるべく動かないように注意します。ループ可能なCGにする：ファイルの容量を小さくするには、短い動きを繰り返しループさせ、かつその継ぎ目がなるべく不自然にならないようにするのが効果的です。撮影現場のセッティングをするときにも、工夫します。自然なループの継ぎ目を作るためには、被写体の最初の位置と最後の位置を、ほぼ一致させることが理想的です。もし可能なら、被写体に人物を使う：人物を含む画像の方が、そうでない画像よりも、人の注意を引きやすいことが数々の研究結果によって明らかにされています。この結果をCGにも応用しましょう。モデルとなる人物の視線が、CTAの方向を向くようにデザインすればさらに効果的です。ユーザーの視線も同じようにCTAへ誘導しやすいことが、研究で示されています。被写体の配置を整えたら、次は撮影です。シネマグラフの中で表現したい動きを数回ほど繰り返しながら、約20～30秒の動画を撮影します。また、全ての被写体を静止させた約5秒動画も撮影します。こうして撮影できた動画が、人目を引くようなシネマグラフを作成する土台となります。動画からシネマグラフを作成するここでは、動画からシネマグラフを作成する詳細なステップは省略し、主な作成ツールについてのみ紹介します。シネマグラフ用の高性能なデザインソフトウェアは約299ドル（日本円で約31,000円）で購入できますが、Photoshopを使ってCGを組み合わせてシネマグラフを作ることも可能です。ファイルを圧縮する CGをゼロから自作するとしても、既製のCGを利用するとしても、ファイルの読み込みが速いことが重要です。また、CGの出力ファイル形式を、GIF形式にするとしても、その他の動画ファイルの形式にするとしても、ファイルの圧縮において重要になるのは次の2点です。画質長さ私は、動画やシネマグラフなど容量の大きいファイルを圧縮するときには、なるべく画質が損なわれないように努めています。視覚的な効果を得るのために、ファイルの画質を犠牲にすることは、悪だと考えています。このバランスを図るために、シネマグラフ作成においては、ループを可能な限り短くしているのです。シネマグラフのループをどのくらい短くできるかは、撮影する被写体の動きにも左右されます――例えば、被写体が「走っている列車」である方が、「ゆったりと動く人間の目」である場合よりも、短いループを作成しやすいのです。「ゆったりと動く人間の目」のような被写体の動きを、短いループで繰り返すとしたら、途切れて不自然な感じになってしまいます。例として、私がThe Deep End社でデザインした次のシネマグラフを見てください。「走っている列車」を表現するためにループさせている動画は、1秒前後まで短くすることができました。こうして、このシネマグラフでは自然な動きを作ることができましたが、ファイルの読み込みを速くするには、ファイルをさらに圧縮する必要がありました。そこで、私は最終的に、ClipChampという無料のファイル縮小用ソフトウェアを利用し、このファイルを数MBから約319KBまで圧縮しました。ぜひ覚えておいてほしいことは、ユーザーは読み込み時間に「3秒」もかかれば、Webサイトを離れてしまうということです。だからこそ、ファイルの読み込みを速くすることには、労力をかける価値があるのです。もし圧縮をしすぎた結果、最終的なファイルの仕上がりに不自然な部分が生まれた場合には、不完全な動画を上手く隠すための常套のテクニックがあります。――半透明のパタン（模様）入りオーバーレイで、覆ってしまいましょう！シネマグラフによるデザインの実例は数が少ないこともあり、多くを紹介できないのは残念ですが、ぜひあなた自身に今回の記事で述べたプランを実行に移して、Webデザインのトレンドとなるような前衛的なシネマグラフを生み出してほしいと、期待しています。 Gilt Taste（補足：このサイトは現在閉鎖中です。） The Nature Conservancy 最後にシネマグラフは、それなしでは退屈になるようなWebサイトのプロジェクトを楽しいものとするだけではなく、プロジェクトを成功に導く力もあります。最高にクールな見出し、優れたCTAなどを、シネマグラフと組み合わせれば、ユーザーの関心を引けることも間違いありません。その後は、ユーザーの関心を思いのままに導くことができます。 [お知らせ]TechAcademyでは初心者でも最短4週間でオリジナルWebサイトを公開できるWebデザインオンラインブートキャンプを開催しています。Webデザインのスキルを身につけたい方はぜひご覧ください！

Webデザイン

記事を検索

ニュース

インタビュー

テクノロジー

キャリア

お問い合わせ

【テンプレあり】始末書の正しい書き方のポイントを、例文と併せて解説

始末書とは

始末書の基本構成

書き方の例