言葉の意味をおさらいしてみよう！「各位」の正しい使い方と用例

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

皆さんは、ショートカットキーについてご存知でしょうか？ いちいちマウスを操作しなくても、キーボードを使って様々な動作ができるショートカットキーは、ぜひ覚えておきたい知識のひとつですよね。 今回はWord(ワード)に関連する、厳選したショートカットキーをまとめて紹介します。 初めてショートカットキーを使う初心者の方から、確認のために使いたいPC上級者の方まで、Word操作の効率アップにぜひお役立てください。     目次 新規文書作成  ファイルを開く 文書を上書き保存する 文書を閉じる すべて選択する 直前の動作を元に戻す 直前の動作を繰り返す 選択範囲をコピーする 選択範囲を貼り付ける 選択範囲を切り取る 書式をコピーする 書式を貼り付ける 文字列を太字にする 文字列を斜体にする フォントサイズを大きくする・小さくする  文書を印刷する（ダイアログボックス表示） フォントサイズを大きくする・小さくする   印刷プレビューを表示する  改ページする  次のページへ移動 前のページへ移動 覚えておきたいWordショートカットキーまとめ   新規文書作成 　 「Ctrl」+「N」 新しく文書を作成したい時、このショートカットキーを使えばいち早く新規文書を作成することができます。 他の文書を開いたままでも、「Ctrl」を押しながら「N」を押すことで白紙の文書が作成されます。   [PR] IT企業を目指すための無料カウンセリングファイルを開く 「Ctrl」+「O」 前に作成したファイルを開きたい、そんな時にオススメのショートカットキーです。 「Ctrl」を押しながら「O」を押すことで、「ファイルを開く」のダイアログボックスを表示することができます。   文書を上書き保存する 「Ctrl」+「S」 せっかく文書を書き終えたのに、保存ができておらずデータが消えてしまった！なんて経験をしたことがある人は多いのではないでしょうか。 「Ctrl」を押しながら「S」を押す動作を指に覚えさせることで、マウスを操作しなくても簡単に文書を保存することができます。 保存忘れなどのミスも防げるようになるので、優先的に覚えておきたいショートカットキーです。   コラム コスパとタイパ、両方結果的に良くなる良くなる学び方とは？ 「スクールは高いし時間も縛られて効率が悪い」と考える方は多いと思います。 もちろん、時間も費用もかかることは間違いありません。 ただ 結果的に無駄な学びにお金も時間もかける方がリスクが高いという考えもあります。 コスパ・タイパ最適化の参考として、 テックアカデミー卒業生がスクールを選んだ理由 をご紹介します。

本稿は、Smashing magazineのブログ記事を了解を得て日本語翻訳し掲載した記事になります。 本記事は、UXディレクターでありデザイン本の執筆もしているTom Greever氏によって投稿されました。   先日、クライアントに向けたHTMLとCSSを使用してデザインを実装するための方法についての講習会で指導を行っていました。 そこでは、スタイルガイド駆動開発やOOCSS・SMACSSのような取り組み方、及びモジュール設計などの工程についての議論も行われました。最終日近く、ある人に「でも、どうやってそれが正しく行われていると判断したらいいんでしょうか？」という質問を受けました。 最初、私は混乱していました。それまで私は「正しく行う」ことだけを説明していましたが、その質問が何が主格の選択肢であるかを評価するためのより深いニーズに根ざしているのに気付きました。 例えば「他と共同して動作するクラスの数は最小限にする」というような特定のアドバイスは、モジュール性に関する幅広い認識がなければ役に立たないのです。 私たちの仕事がきちんとできているかを本当に知るために、デザイン実装の目安として使えるより高いレベルの原則が必要であると気付きました。 この溝を埋めるため、デザイン実装に関する9つの原則をまとめています。 CSSやコードを吟味するときの他にチームに志願している人への面接を行うときでも、これらの原理は特定の技術やデザインを実装する一般的な手段を超越した骨組みとして利用することができます。   1.構造化 文書はスタイルシート適用の有無に関わらず、意味があり論理的に書かれている。 2.効率的 デザイン実装に使われているマークアップとアセットは最小限である。 3.標準化 共通の規定があり、自由に使うことができる。 4.抽象化 ベースとなる要素は特定のコンテキストから切り離され、中心となるフレームワークを形成している。 5.モジュール化 共通して使える要素は、再利用ができるように分割されている。 6.設定が可能 ベースとなる要素を、任意のパラメータでカスタマイズできる。 7.拡張が可能 コードは簡単に拡張することができ、今後も追加されることが見込まれている。 8.文書化されている すべての要素は、それを使用して拡張できるように他の人に説明されている。 9.正確である 最終的なアウトプットは、予定された通りのデザインとして適切な表現がされている。   プロジェクトに各原則がどのように適用するかを確認するため、この記事の基準として私のプロジェクトのひとつのモックアップを使用します。 これは既存のECサイト中の、デイリーディールを宣伝する特別なランディングページです。スタイルの一部は既存のサイトから継承されますが、ほとんどの要素は新しいものであるということに注意してください。上記の原則を使って、この静止画像からHTMLとCSSを生成してみましょう。 この製品の「カード」レイアウトは、新しい要素です。   1.構造化 文書はスタイルシート適用の有無に関わらず、意味があり論理的に書かれている。 ここでの原則は、ドキュメント(HTML)の内容がスタイル(CSS)がなくても意味を持つということです。正しい見出しレベル(heading)や順序なしリスト(ul)などを設定し、<header>や<article>といった意味のあるタグを利用するということでもあります。 aria-labelやalt属性、その他のアクセシビリティに必要な可能性があるものをきちんと使用しましょう。 見た目的に変わらないアンカータグとボタンのどちらを使うかということは、大したことには思えないかもしれません。ですが視覚的に同じであっても、これらは違う意味を伝え違う動作を行います。セマンティックマークアップはその意味を検索エンジンや補助技術に伝え、他デバイスにおいての再利用もやりやすくします。それはプロジェクトの将来性に繋がります。   よく構造化された文書を作成するということは、セマンティックHTMLを書くことを学び、W3Cによる標準や他の専門家のベストプラクティスを習慣づけ、自分のコードが分かりやすくなるように時間をかけることです。 スタイルシートなしでブラウザで確認するのが、一番シンプルなHTMLのテスト方法になります。 そのHTMLはCSSがなくても使うことができるか 階層構造が一目で分かるかどうか HTML自体で意味を伝えることができるか しっかりした構造をもつ文書を作成するにはHTMLから始めるのがよいでしょう。ビジュアル的なスタイルを考える前に、構造とそれぞれの意味のためにプレーンなHTMLを書きます。divは避け、妥当なタグを考えます。この基本的なステップが、適切な構造を作るために役立つでしょう。 <section> <header> <h2>Daily Deals</h2> <strong>Sort</strong> <span class="caret"></span> <ul> <li><a href="#">by ending time</a></li> <li><a href="#">by price</a></li> <li><a href="#">by popularity</a></li> </ul> <hr />

年末年始の関係先への挨拶をメールで済ませることも増えています。 ここでは、受け手に好印象を与えるための、ビジネスメールにおける年末年始の挨拶のルールと例文をまとめました。   年末年始の挨拶の場合の注意点 年末年始の挨拶をメールで送る場合の注意点をまとめます。 まず、年末・年始どちらのメールにも共通する注意点は2つです。 時節の挨拶を書く 次節の挨拶は必ず書きます。とはいえ、「師走の候～」などと格式張ったことを書く必要はありません。「今年もあとわずかとなりましたが～」など、時季を感じさせる挨拶なら問題ありません。 できるだけ個人名で送る 宛先はできるだけ1人にし、「○○様」と宛名を入れましょう。宛名を「お取引先様各位」などとして一斉送信する方法もありますが、事務的な印象になってしまいます。 次に、年末の挨拶を書く場合の注意点は3つです。 今年の感謝の気持ちを書く 1年間お世話になったことに対する感謝の気持ちを内容に含めます。 年末年始の休業期間を書く 文面には年末年始の休業期間を案内する内容を含めます。 来年のお付き合いをお願いする言葉で結ぶ メールの最後に「よいお年をお迎えください」と添え、来年のお付き合いをお願いする言葉で結びます。 年始の挨拶メールは、送るタイミングが大切です。 松の内に送る 新年のメールは松の内である1月7日までを目安に送りましょう。営業開始日以前のメールでは営業開始日の案内も行います。   例文・テンプレート 年末の挨拶メール 件名：年末のご挨拶 株式会社○○ ○○部 ○○様 いつも大変お世話になっております。 株式会社○○の○○です。 今年も残すところわずかとなりましたが、 貴社ますますご清栄のこととお慶び申し上げます。 ○○の折には◯◯様のお力添えのおかげでつつがなく業務を進めることができ、 心より感謝しております。 来年はより一層お役に立てるよう励む所存ですので、 引き続きご指導、ご鞭撻のほど宜しくお願いいたします。 なお、弊社は年内12月○日（曜日）まで通常通り営業いたします。 新年は○月○日（曜日）より通常営業を開始いたします。 以上、メールで恐縮ではございますが、年末のご挨拶とさせていただきます。 どうぞ、よいお年をお迎えください。 新年も何卒宜しくお願い申し上げます。   年始の挨拶メール 件名：年始のご挨拶 ○○株式会社 ○○部 ○○様 謹賀新年 株式会社○○の○○です。 旧年中はいろいろとお世話になり、まことにありがとうございました。 本年は昨年以上に○○株式会社のお役に立てるよう最大限の努力をする所存ですので、 変わらずお引き立てのほど、よろしくお願いいたします。 また、今年は昨年以上にご満足いただけるサービスをご提供していく所存ですので、 変わらぬご愛顧を賜りますようお願い申し上げます。 なお、弊社は1月○日(曜日)より平常通りの営業を開始いたします。 何かありましたら、私○○まで遠慮なくご連絡下さい。 メールにて恐縮ですが、貴社益々のご発展をお祈り申し上げ、 新年のご挨拶とさせていただきます。 平成○○元日   [PR] IT企業を目指すための無料カウンセリング書き方のNG例 ビジネスメールで正しい言葉使いをするのは当たり前のことですが、特に年始のメールでは、使い方を誤りがちな言葉があります。 「常識がない」、「失礼」という印象を与えないために、次の2点のNGは最低限覚えておくべきです。   （1）「元旦」の使い方 新年の挨拶に使われる「元旦」という言葉は、1月1日の日の出までを指します。 そのため、1月1日であっても日中～夜に送るメールに「元旦」と記すのは誤りです。「元日」という言葉を選びましょう。   （2）目上の方に2文字の賀詞はNG 新年を言祝ぐ賀詞の中でも、「迎春」「賀正」といった2文字の賀詞は目上から目下に向けて使われる言葉。 取引先や上司に送るメールに記すのはNGです。「謹賀新年」「恭賀新年」などを選ぶか、「謹んで新春のお慶びを申し上げます」などと記しましょう。   まとめ 仕事関係者に送る時候のメールの中でも、大きな節目の挨拶として重要な役割を果たすのが年末年始の挨拶メールです。事務的になりすぎず、1年間の感謝や新たな年のお付き合いを願う気持ちを込めることが大切です。 また、年末年始の営業日を伝達する意味もあるため忘れずに記載しましょう。関係先からの印象を悪くしないために、日本語の慣習をきちんと理解して、非常識であったり失礼にあたったりすることがないようにしたいものです。 IT業界でおすすめの転職サイト・エージェントもまとめているので、転職を検討している方はぜひ活用してみてください。   また、TechAcademyは、積極的に情報集取を行い学習、成長していくビジネスマンの今後を応援しています。そんな方々におすすめなのはIT業界でキャリアを描くこと。IT業界は成長産業であり、上昇志向や成長志向のある人であれば幅広いチャンスを掴むことが可能です。しかし、総合職であっても技術職とコミュニケーションが取れる人材が求められています。 TechAcademyにはIT業界で活躍したい方向けに無料でプログラミングを学び、転職支援も受けられるTechAcademyキャリアというサービスがあります。 専門知識を効果的に学び、プロのコンサルタントの支援のもと行う転職活動でより自分にあった企業と出会ってみませんか。 IT業界でキャリアアップを目指したい方はぜひTechAcademyキャリアをご覧ください。 プログラミングを独学で学習していて、このように感じた経験はないでしょうか？ ・調べてもほしい情報が見つからない ・独学のスキルが実際の業務で通用するのか不安 ・目標への学習プランがわからず、迷子になりそう テックアカデミーでは、このような 学習に不安を抱えている方へ、マンツーマンで相談できる機会を無料で提供

文書を作成するときは、横書きにするのが主流です。 しかし、目上の人への手紙やお礼や謝罪などのあらたまった内容の文書は、今でも縦書きで作成します。 そこで今回は、Word(ワード)で文書を縦書きにする方法を解説していきます。 なお本記事は、KiRAMEXのオンライン完結のWord(ワード)講座の内容をもとに紹介しています。   目次 Word で文書を縦書きにする方法 縦書き文書内で横書きの数字などを挿入する方法   Word で文書を縦書きにする方法 Word は、デフォルトの状態では横書きになっているので、縦書きの設定にする必要があります。 まず、上のツールバーの[ページ レイアウト]タブをクリックしましょう。 そうすると、ツールバーが切り替わりますので、[文字列の方向]をクリックします。 [横書き]や[縦書き]などの一覧が表示されるので、[縦書き]をクリックしましょう。 これで、文書を縦書きにすることができます。   [PR] IT企業を目指すための無料カウンセリング縦書き文書内で横書きの数字などを挿入する方法 縦書き文書内では、半角の数字などが横向きに表示されてしまいます。 ここでは、縦書き文書内で半角の数字などを正しい方向（横書き）で表示する方法を、解説していきます。 まず、横書きにしたい数字などを選択してください。 次に、ツールバーを[ホーム]に切り替え、[拡張方式](下の画像のオレンジ色の「A」のボタン)をクリックしましょう。 そうすると、[縦中横]や[組み文字]などの一覧が表示されるので、[縦中横]をクリックします。 「縦中横」とは、ドラッグした数字などを、全角1文字のスペースに横向きに表示させる方法です。 「縦（書きの）中（で）横（向きに表示させる）」ということですね。 そうすると、[縦中横]ダイアログボックスが表示されるので、プレビューを確認の上で[OK]をクリックしましょう。 これで、縦書きの文書内で横書きの数字を挿入することができます。 他にも、アルファベットなども、「縦中横」の機能を使えば横書きで表示させることができます。 縦書きの文書内に日付けや英単語などを記入する際に、ぜひ活用してくださいね。 以上、Word で縦書きにする方法を紹介しました。 縦書きの方法を覚えたら、手紙やはがき作りに挑戦してみてはいかがですか。 プログラミングを独学で学習していて、このように感じた経験はないでしょうか？ ・調べてもほしい情報が見つからない ・独学のスキルが実際の業務で通用するのか不安 ・目標への学習プランがわからず、迷子になりそう テックアカデミーでは、このような

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] IT企業を目指すための無料カウンセリング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ではこれからもプログラミング学習者のためのイベントを開催していきます。 プログラミングを独学で学習していて、このように感じた経験はないでしょうか？ ・調べてもほしい情報が見つからない ・独学のスキルが実際の業務で通用するのか不安 ・目標への学習プランがわからず、迷子になりそう