エンジニアが
ビジネスシーンで使う
使いすぎ注意のビジネス用語を

これまで2回にわたって
ご紹介してきましたが...

今回もまた
エンジニアのためのビジネス用語講座を
開講したいと思います。

カタカナ語のビジネス用語って
本当に多いです。

問い

さて、
今回はビジネス用語の
問題から始めたいと思います。

それでは、
次の文の意味を答えてください。

・例題1

社員の情報リテラシーを深め、
シナジーを高めながら活動しましょう。

・例題2

今回の開発スキームにおいて
テスト工程におけるマイルストーンでは、
エビデンスをユーザに提示して
オーサライズしてもらう必要があります。

...意味がわかるようで
はっきりとわかりにくいですよね。

これらは過去のブログで
ご紹介した用語になります。

それでは
解答を見てみましょう。

・例題1の解答

社員の情報に対する理解度を深め、
社員同士の相乗効果を高めながら活動しましょう。

・例題2の解答

今回の開発計画において
テスト工程におけるそれぞれの節目では、
テスト結果となる成果物をお客様に提示して
承認してもらう必要があります。

だいたい
こんな感じの意味になります。

解答できましたでしょうか?

カタカナ語だと
意味が伝わりにくいですが、

日本語でも
やや固い言い方になりますね。

そのあたりも
カタカナ語が使われる
理由のひとつと言えるでしょう。

エンジニアのためのビジネス用語集3

それではさっそく
紹介してゆきたいと思います。

■1:インスコ（?）

・使用例
「プログラムをインスコしといて」

・意味
「インストール」

これは和製英語のようなもので、

「インストール（install）」

...のことを言います。

「インストール」
↓
「インスト」
↓
「インスコ」

...と、
標準語から地方の方言に変わるように
表現が変わってゆきました。

インストール作業が多い
IT業界でよく使われています。

■2:ネゴ（nego）

・使用例
「その件は部長にネゴってください」

・意味
「交渉」「協定」

こちらも和製英語のようなもので、

「ネゴシエーション（negotiation）」

...が短くなった言葉です。

上司やユーザーなど、
相手との交渉が必要なときに使われます。

■3:ブラッシュアップ（brushup）

・使用例
「その企画をもう少しブラッシュアップしましょう」

・意味
「磨き上げる」「質を高める」

ものごとを磨きあげることで
質を高めることを意味します。

ある程度の
レベルに到達したけれど
もっと質を高めたい時に使われますね。

■4:ペンディング（pending）

・使用例
「その件についてはペンディングとします」

・意味
「保留」「未定」

諸事情により
ものごとがうまく進まず、
保留状態になっていることを意味します。

「pend」

という言葉は

「ぶら下がる」

...という意味ですので、

「ものごとがぶら下がったまま」

...という意味で使われています。

■5:ボトルネック（bottleneck）

・使用例
「何がボトルネックになって遅れているのですか」

・意味
「詰まる」「（速度が）落ちる」

システム用語では
設計上の制約や速度が低下する処理などを
意味しますが、

一般的なビジネス用語としても
ものごとが進まない原因を指す言葉として
使われています。

ボトルネックとは
瓶の細くなっている首の部分のことで、

液体がそこを通る時に
流れが遅くなることが語源になっています。

■6:ミッションクリティカル（mission critical）

・使用例
「ミッションクリティカルなシステム」

・意味
「常に稼働する必要があるシステム」

電気などのライフラインや
交通系・金融系システムなど、

24時間365日の稼働が必要で
停止することができないシステムを意味します。

■7:リスクヘッジ（risk hedge）

・使用例
「問題が発生した時のリスクヘッジを教えてください」

・意味
「危険回避」「損失回避」

もともとは
金融や経済用語として使われていましたが、

計画の立案などにおいて
問題が発生した場合の回避策を表す言葉として
使われています。

システム開発でも
開発計画を立てるときに使われますね。

■8:リスケ（resche）

・使用例
「そのスケジュールをリスケしてください」

・意味
「再計画」

リスケとは…

「リスケジュール（reschedule）」

...の意味で、
もう一度計画しなおすことを言います。

システム開発では
開発に遅れが発生した場合、

当初の計画を
修正するケースがありますが、
そのことをリスケと言います。

海外では通じない用語もあります

エンジニアが使う
ビジネス用語はたくさんありますが、

今回ご紹介したように
和製英語のように使われているものもあります。

海外のエンジニアなどには
意味が通じないケースもありますので
注意してくださいね。

さて、
これまで3回にわたって...

「エンジニアのためのビジネス用語講座」

...を開講しましたが
いかがでしたでしょうか?

まだまだご紹介できる
用語はたくさんあるのですが…

またの機会に
改めてご紹介してゆきたいと思います。

PS

エンジニアになるためのスクールならこちら

以前のブログで
エンジニアがビジネスシーンで使う、

カタカナ語のビジネス用語について
お話ししましたが...

まだまだありますので
もう少しご紹介してゆきます。

使いすぎる方はたくさんいます

カタカナ語の
ビジネス用語を使う方は

結構たくさん
いらっしゃるようです。

企業の朝礼でのスピーチや
社長の訓示などが...

「カタカナ語だらけで理解できない…」

といった話も
耳にすることがあります。

使いすぎると
意味が通じなくなりますからね（笑）

使いすぎないまでも
言いたいことが理解できるように、

今回もいくつか
エンジニアが使うビジネス用語を
ご紹介しましょう。

エンジニアのためのビジネス用語集2

今回も用語の使用例をつけて
ご紹介してゆきます。

1:アジェンダ（agenda）

・使用例
「アジェンダを明確にして進行してください」

・意味
「議題」「議事日程」

会議や打ち合わせなどで
検討する課題や議題のことを言います。

国際会議の場などでも使われますが、
IT系企業でも使われていますね。

2:カットオーバー（cutover）

・使用例
「システムのカットオーバーはいつですか?」

・意味
「利用開始」「稼働開始」

システム開発において
全ての開発工程を終了し、
実際に運用が始まることを言います。

「リリース」

や

「サービスイン」

と言われることもあります。

3:サーベイ（survey）

・使用例
「十分なサーベイを行っております」

・意味
「調査」「測量」

主に建築業界で使われますが、
IT企業などを含め

ビジネス用語として
広がりつつある用語です。

資料などを調査することで、
調査対象を把握することを意味します。

4:シナジー（synergy）

・使用例
「チーム内のシナジー効果を高めよう」

・意味
「相乗効果」「共同効果」

単体ではなく
複数が集まることで
効果や機能を高めるという意味です。

人に対して
使われることもありますが、

企業同士の協業など
組織に対しても使われます。

ちなみに反対の用語は...

「アナジー（anergy）」

と言います。

5:バッファ（buffer）

・使用例
「スケジュールにバッファは含まれていますか」

・意味
「領域」「余裕」

もともとは
システムで使用するデータを
保存しておく記憶領域のことですが、

容量や期間などの
余裕という意味でも使われています。

開発期間が短いと
トラブルが発生した場合に
遅れが発生しますが...

あらかじめ、
数日の余裕（バッファ）を設定しておくと
対応が可能になります。

6:フィックス（fix）

・使用例
「このバグはフィックス済ですか」

・意味
「修正」「調整」

問題が発生した場合、
問題を解決することを意味します。

プログラムで不具合が発生し、
修正することを...

「バグフィックス」

と言います。

プログラムだけでなく
取引先との調整に対しても
使われることがあります。

7:リテラシー（literacy）

・使用例
「社員のITリテラシーを高める」

・意味
「理解」「解釈」

対象に対する
適切な認識と理解を深めることを
意味しますが...

理解を深めた上で
応用力を身に付けるという意味でも
使われています。

「情報リテラシー」
「ITリテラシー」
「医療リテラシー」

...など、
この言葉は何にでも使われています。

8:ワンストップ（onestop）

・使用例
「ワンストップのサービスを提供します」

・意味
「1つの手続きで作業が完了すること」

こちらも数年前から
よく耳にする言葉ですね。

役所などを想像すると
理解しやすいのですが、

複数の部署を
行ったり来たりして
手続きが必要となることを

1回の手続きで
処理が完了することを意味します。

何となく使うのはやめましょう

ビジネス用語以外にも
カタカナ語は多くあふれており、

国立国語研究所では
このような外来語に対して
言い換えの提案を行っています。

たとえば
ワンストップの場合は...

「窓口一元化」

...などですね。

ですが、
日本語で言いかえるよりも

カタカナ語で言う方が
知的な感じを持つ方が多いことと、

言いかえるにしても
明確な言い換えができないなど

いろんな事情で
カタカナ語がつかわれています。

このような用語を使う場合は
用語の説明ができるようになってから
使うようにしましょう。

「それってどういう意味ですか？」

と聞かれて
答えられないと気まずいですものね。

PS

プログラミングスクールの資料請求はこちらから

日常生活には
さまざまな横文字が
あふれていますが...

ビジネスの世界にも
多くの横文字があふれています。

今回は
エンジニアが
ビジネスシーンで使う、

使い過ぎ注意の
ビジネス用語についてお話します。

何を言っているかわからない

毎年毎年
新しい言葉が生まれていますが、

ビジネスの世界も同じく
新しい言葉が次々と生まれています。

そのほとんどは
外国語をベースにした
カタカナ英語なのですが、

最新の
ビジネス書や技術書には
カタカナ英語が多く使われますので、

読んでいる方も
ついつい使いたくなる方もおられます。

しかし、
あまり多用すると
何を言っているのか分かりません。

たとえば...

開発スキームにおいては
明確なマイルストーンを設け、
ユーザにコミットする必要がある

...と言われても
普通の人は意味分からないですよね。

それらの中から
エンジニアがビジネスシーンでよく使う用語を
解説付きでご紹介しましょう。

エンジニアのためのビジネス用語集

それでは
用語の使用例をつけてご紹介します。

1:アラート（alert）

・使用例
「遅れそうなら早めにアラートあげてください」

・意味
「警戒」「注意」

作業に問題が発生しそうな時に
周囲の人に通知する時に使われます。

さまざまなシステムで
警告メッセージを出す時に
アラートを出すと言われますが...

それがそのまま
日常業務でも使われています。

2:エビデンス（evidence）

・使用例
「どうしてエビデンスを残さないの？」

・意味
「証拠」「根拠」

医療用語でよく使われますが
IT業界では主にテスト結果に対する
裏付けとなる資料を指すことが多いですね。

テスト工程で単純に...

「テストOK」

...とドキュメントに残すより、

画面キャプチャなどを残して
テストOKとなる根拠を残します。

3:オーソライズ（authorize）

・使用例
「その件は先方にオーソライズされているの？」

・意味
「（正当と）認める」「公認」

セキュリティにおける
「認証」と言う意味でも使われますが、

決定権のある立場の人や機関から
正式に認められている状態で使われます。

4:コミット（commit）

・使用例
「コミットできるよう頑張りましょう」

・意味
「関わる」「完遂する」

最近はCMでも有名な単語ですね。

システム開発では
データベースを更新する際に
使われている用語ですが、

ビジネスにおいても
目標に対して結果を出すという意味で
使われています。

5:スキーム（scheme）

・使用例
「アプリの課金スキームを提示します」

・意味
「計画」「体系」

システム開発では
データベース構造のことを意味しますが、

ビジネス用語としては
スケジュールと似た意味で
計画のことを意味します。

ちなみにこの言葉は
イギリス英語では「計画」の意味ですが

アメリカ英語では...

「たくらみ」「陰謀」

...と取られてしまうケースもあります。

注意しておきましょう。

6:マイルストーン（milestone）

・使用例
「その件は次のマイルストーンまでに対応します」

・意味
「標識」「里程標」

システム開発は
長期間にわたることが多いですが、

設計完了や製造完了など、
各工程の節目のことを呼びます。

マイルストーンの時点で
納品や出荷、品質チェックなどを
行うのが一般的ですね。

7:マター（matter）

・使用例
「何マターで発生した不具合ですか？」

・意味
「問題」「要素」

トラブルなどが発生した際、
何が原因なのかを表す時に使われます。

「○○マター」

という使われ方が多く、
○○には人名、企業名などが入ります。

8:ユーザ、サーバ

・使用例
「ユーザID」「サーバ構築」

これは他の言葉とちょっと違っていて
書き方の問題です。

エンジニアは...

ユーザーのことを「ユーザ」
サーバーのことを「サーバ」

...と書く方が多いですね。

間違ってはいないのですが、
日本工業規格 JIS(JIS Z 8301)によると...

「言葉が2音以下の場合には、語尾に長音符号をつける」

という指針がありますので、
どちらかと言えば...

「ユーザー」
「サーバー」

...と書くのが正しいようです。

「ユーザ」

とマニュアルに書いていたのを
ユーザーに指摘されて

「ユーザー」

...に訂正したという例もありますので、
気をつけるようにしましょう。

（私も「サーバ」「ユーザ」の方が好きなので、
　こちらで言いますが）

意味はおさえておきましょう

カタカナ語だけでなく
専門用語もそうですが...

使いすぎると
相手に正しく意味が伝わりません。

確実に相手に何かを伝えたい場合は、
できるだけわかりやすい表現で伝えましょう。

ですが、
いざ言葉が出た時のために
意味はおさえておきましょうね。

この他にも
エンジニアがビジネスで使うカタカナ語は
たくさんあります。

機会があれば
また次回以降にご紹介します。

PS

エンジニアになるためのIT専門スクール

エンジニアと言うと...

「PCに向かって開発業務をする」

というイメージが強いですが、
必ずしもそうであるとは限りません。

とある中小企業の
システム部に所属するエンジニアの話です。

いきなり営業になったエンジニア

彼は、
ある時上司に呼び出され、

「営業に行ってほしい」

...と突然言われました。

関連会社があるパッケージソフトを開発。

彼の企業はそのソフトの代理店となりました。

そのため、システムに詳しいエンジニアも
営業にまわすことになったとのことでした。

もちろん、
そのエンジニアには
営業経験なんてありません。

戸惑いながらも
営業活動をすることになったのですが、

もちろん
いきなりソフトが売れるはずもありません。

営業だけでなく
通常の社内システムの
開発業務も兼務していたため、

残業時間は膨れ上がり、
ほとんど寝る時間がなかったそうです。

開発ばかりしているとは限らない

エンジニアの仕事と言えば...

ハードウェアや
ソフトウェアの設計をしたり

プログラムを組んだり
するイメージが強いですが、

このエンジニアのように
別の業務と掛け持ちしつつ
システム開発を行うケースもあります。

人数も多く、
部署が明確に分かれている企業だと
あまりこのような例は見られませんが...

人数の少ない
中小企業の場合は
こういったケースはよくあります。

中小企業は
どうしても人数が少ないので

少ない人材で
売上に繋がる活動をする必要があります。

このエンジニアのように
営業を兼務するだけではなく、

会社の事務をしながら
システム開発を行うエンジニアもいます。

もちろん、
所属する企業の方針や体制にもよりますが...

エンジニアと言っても
いつも開発だけをしているとは限らないのです。

冒頭で紹介した
営業兼務となったエンジニアの方は、

社交的な性格ではなかったので、
見知らぬ人と接するのが苦痛だったそうです。

開発は好きだけど
営業が辛いという思いが強まり、

一時は退職も考えたそうですが、
続けているうちに考えが変わったようです。

電話営業や
飛び込み営業、
セミナーや展示会の開催に参加して

「ものを売る」

という行為に接するうちに...

自分はものを売ることについて
何も知らずにものづくりをしていた

...という事を
思い知ったと気づいたと話していました。

ものづくりには
必ずものを売るという行為が発生します。

今までは
ものを作ることに専念してきたが、

これからは
ものを売るということも知る必要があると
営業活動にも積極的に取り組み...

「総合的なものづくり」

...を習得しようとしているそうです。

ビジネスパーソンとして成長するために

エンジニア一筋で
仕事をしてきた方の中には、

このような
仕事内容の変化に
ついていけずに退職する方もいます。

しかし、
これまでやったことのない
活動を行うということは...

「新しい視野を広める」

...ということに繋がります。

もちろん、
専門分野に特化することも
エンジニアとして大切なことです。

ですが、
新しい業務に携わることは、
新しい視野を得られるチャンスでもあります。

まずは何でも
あなたがやれることを
やってみるようにしましょう。

そうすることによって
必ず何かを得ることができます。

その経験は、
エンジニアとしてだけではなく、

1人のビジネスパーソンとして、
あなたを大きくしてくれることでしょう。

リスキルテクノロジー
松田

PS

ビジネスで通用するエンジニアになるにはこちらから

リーンスタートアップ。

IT、さらに言うと、ITスタートアップの界隈で話題になっている（なった）起業の方法論です。

これがなんで話題になったかというと、起業のプロセスがようやくすこし科学的になったからです。

キーワードは「検証」です。

今からリーンで立ち上げるプロジェクトがあるため、復習がてら書いてみます。

スタートアップはギャンブル？

スタートアップというのは、当たるかどうかが正直わからないものです。チャレンジングなものほどその傾向が強く、Googleもそうですし、Facebookもそうです。仮に私が記憶がない状態で、過去に戻ってFacebookの創業メンバーと会っていたとしても、なんだこの連中？ くらいにしか思わず、投資なんて考えもしなかったでしょう。

実際100社に投資して、1,2社当たればいいや、というある種のギャンブルです。

急成長するスタートアップになるのか？　という疑問どころか、そもろもターゲットがいるのか？　その商品にお金を払ってくれるのか？　そもそも悩みが独りよがりでは無いのか？　

そういう不安を押しのけつつ、作って、当たれー！！！と祈るのが、スタートアップだったわけです。（いい過ぎですが）

リーンスタートアップでは、起業のリスクを最小限にし、意味のある失敗を繰り返すことで、成功へ近づいていく方法論を確立しています。これはとても革新的で、ちゃんとビジネスとしてやりましょうね、というのがひとつの案として示されたということです。

リーンスタートアップの要訣

リーンスタートアップの要訣はなんといっても、「検証による学習」にあります。

(1)すごく前

完璧なものをつくって、リリース。ウォーターフォール

(2)すこし前

とにかく早くリリース。全力で書け。アジャイル

(3)リーンスタートアップ

ちゃんと検証して、それが本当に必要なのか見てから、最小限作ろう。リーン

というのがざっくりな違いです。前と書いてありますが、現在でも主要は上の２つでしょう。

しかし、(1)(2)ですと、無駄なものを作る可能性が高くなります。どれだけ自信満々に作り始めても、まったくユーザが欲していないものを作りがちです。（実際に、僕は全力で利益にならないものをつくってしまいました）

そうすると、それまでに使った費用や工数はすべて無駄になり、だいぶ厳しいスタートアップ生活を余儀なくされます。bootstraping起業（自己資本起業）ならともかくとして、投資家がいたらより厳しいでしょう。詰められます。

だからこそのリーンスタートアップです。

顧客の課題・それに対するソリューション（解決策）・価格（収益）・チャネル、をきちんと検証し学習して、それからスケール（拡大）を考えよう、という話です。

例えば、靴の販売で有名なザッポスは、地元の靴屋の靴をそのままオンラインで販売してみて、ニーズを確認しました。

このように、実際に必要とされているものを、ユーザがいる+チャネルで売れている、という確認が取れれば、事業化および拡大に安心して走れることになります。

反面、ダメだった場合、すぐに調整してのピボットや、そもそものアイディアの再構築に時間がさけます。

やり方

やり方はだいたいこんな感じで流れます。もちろん考え方や本質の方が大事なので、参考までに。

①プランA（本来の計画）を作る

②プランで最もリスクの高い部分を見つける

③プランを体系的にテストし続ける

① プランAを作る

はじめのプランを作ります。ビジネスモデルの仮説を捕まえて、書き出します。

プランAはソリューションではなく、ビジネスモデル全体です。

なんの課題を持っているか？　
↓
では、ソリューション（解決策）は？
↓
チャネルは？
↓
収益は？

の流れです。ソリューションに拘り過ぎるのはやめましょう。ここ考えるのが一番楽しくて、大体の起業家が得意なところでして、その結果はまるのもここです。

もうすこし細かいところを考えるのであれば、リーンキャンバスというツールがいいでしょう。『実践リーンスタートアップ』の著者アッシュ・マウリャ氏が作成しているものです。

No Problems in Your Business Model is a Problem

これら９つのブロックに内容を記述していき、ひとつのプランとするのです。

このリーンキャンバス何がいいって、作成するのに３０分もかかりません。１５分くらいで作成できます。

何枚も作成して、それをまともな相談相手に相談しましょう。まともな相談相手とは、起業or事業についての理解があり、相談に対してなんらかの適切な反応が得られそうな人です。

② プランで最もリスクの高い部分を見つける

「成功する製品の構築 = リスクを減らす」ですよね。なので、成功するためにはリスクを低減しないといけません。

スタートアップの最も大きなリスクとは、「誰も欲しく無いものを作ること」です。そのため、３段階に渡ってテストします。

■ 第1ステージ　課題/解決フィット

解決に値する課題があるのか？をテストします。

実はアイディアはとても安いのです。なんらかの課題を頭に入れつつ、１０冊くらい起業家やマーケターの本を読んでみてください。きっと、新規のアイディアが2,3ノートに書かれているはずです。

しかし、そのアイディアに対して取り組むのは高いコストが必要です。

・それは顧客が必要としているものですか？
・顧客はお金を払ってくれますか？
・それは解決可能ですか？

この３つの問いに答えるために、顧客にインタビューをしましょう。

知り合いの知り合いくらいの距離感がちょうどいいですが、

■ 第2ステージ　製品/市場フィット

続いて、誰かに必要とされるものを構築したか？ をテストします。

簡単に言えば、必要最低限のものだけを用意して、実際に売ってみるということです。

とにかく必要最低限のものです。売るのに必要最低限。コア部分だけという意味ですね。アーリーアダプターが好みそうなあれです。

実際に売ってみるのも手っ取り早いのですが、顧客へのインタビューを挟むのもいいでしょう。そして、買ってくれた人がちゃんと使ってくれるかを確認しましょう。

使ってくれていないのであれば、またインタビューです。で、修正するところは修正する。

■ 第3ステージ　拡大

ここまでできて初めて拡大を考えます。

成長するための方法をひとつに絞って、時間や資金を投下します。これもちゃんとテストをしているはずですから、安心してお金を入れられるはずです。

ここまでしっかりと検証・学習に時間を費やせば、安全側な起業ができるようになります。

③ プランを体系的にテストし続ける

そして、一度検証して終わりではなく、構築 - 計測 - 学習のループを回し続けます。

常に、仮説=>検証=>結果を確認します。

・顧客はこれを悩んでいるんじゃないか？
・これだったらその悩みを解決できて、そこでお金がもらえるんじゃ無いか？
・実際に小さいものを用意して売ってみようか？ 小さい機能追加してみようか？
・売れた？　じゃあ、本格的に用意をしよう

です。

なので、失敗するのであれば、一刻も早く失敗する。それが学習ループです。

リーンスタートアップとはこのような起業方法です。従来の方法に比べて、かなり精度が高くスタートできるのがわかります。

サイバネティクス理論を取り入れた、誘導ミサイルみたいなものですね。

ただし！！！

リーンスタートアップがよくわからず、悩んで足が止まるくらいだったら、いいからガンガン進めちゃった方がいいんじゃないかと、個人的には思っています。

普通の人や、スタートアップ初心者がごちゃごちゃ考えると、たいてい進まずに諦めるもんです。

特にその分野自体をはじめてやる場合、どちらにせよ、よくわかりません。

検証とか言われましても。。。というのが正直なところだと思います。

突っ込んで、一回叩きのめされて、２回目突っ込む時に「ああ、リーンスタートアップって正しいよね。これだよね」というふうに言えるようになったほうが健全だと思っています。

業界に詳しければ、別なんでしょうが、強くそれを感じています。理論だけの人は行ったり来たりで進まずに、割と大変そうだなぁ、とはたから見て思います。

ただ、なんにせよ、最低限のテストを実施して、失敗するまでの速度を速めるという感覚は、持っておくといいのではないでしょうか？

松田

「今日、あなたはなんの仕事をしましたか？」

この質問に明確に答えられるエンジニアは幸いです。

新人エンジニアや新しい職場に入ったばかりのエンジニア、もしくはフリーでやっているエンジニアは割ときちんと答えられるでしょう。

しかし、企業に長くいればいるほど、本来やるべき仕事から遠く離れたことに時間を使ってしまいがちです。時間管理術を身につけると、仕事の効率が格段にあがります。

本来やるべき業務ができていない

設計だったり、コーディングだったりすると思いますが、あなたが本来するべき仕事がほとんどできていない日が多くあるはずです。とくに最近では、1日２時間も生産的な時間が取れていないという感想を持ったエンジニアが急増しています。

本当の力から言えば、３時間で終わるような機能追加が、異常なほど時間が取られ、３日経っても終わらないというようなことがあるはずです。

これには、主に二つの理由があります。

大きく時間を取られることが沢山ある

これは会議や顧客への訪問などです。

会議を至上命題と捉えている会社員は多いもので、会議が多ければ多いほど、その分生産に使える仕事が減っていきます。

これは仕方ない部分もあり、会議がないと進まない場合もあるのですが、時間は制限すべきですし、最低でも区切るべきです。いらなくなった人は随時リリースするなど。

大きい時間がまるごとドカっと取られていると、そこに至るまでの時間もなかなか集中できません。集中しても、すぐに会議があるとわかっているからです。

ですから、会議の数は少なく or まとめてやる。

そして、会議自体も時間を少なくしても、目的に沿ったものにしましょう。

時間節約のアイディアは沢山あり、例えば、立って会議をするなど。弊社では実行していますが、会議の時間が20-30%ほど減ります。

短い時間のロスが沢山ある

とはいえ、なかなかどうして大きい時間のロスは減らしにくい物です。とくにあなたが上の立場でもなければ、、、まず意見するのは難しいでしょう。

それは仕方がないことです。階層社会にいる訳ですから、上司の命令にはある程度従うべきです。（そのために会社組織があるわけですし）

では誰しもが解決できる問題はというと、短い時間のロスをなくすということです。短い時間というのはそれこそ、３分や１分、３０秒といった極短い時間です。

実はこの時間がかなり大事なのです。

なぜか？　

人間は一度切れた集中力を戻すのに、ものすごい時間と体力を必要とするからです。

一度集中状態に入ったら、その状態をなるべく維持する努力をしなければいけません。プロの将棋を見ていればわかりますが、誰も音を立てようとしません。音を立てる対局者は全般的に嫌われます。

それくらいノイズなどの集中力を妨げるものはアウトとみなされるのです。

その中でも特に対処が必要はのは、下記の３つです。

時間泥棒その１メール

メールというか、メッセージといった方が正確でしょうか？

SlackでもChatworkでもスカイプでも構いませんが、なんらかのメッセージです。メッセージが来るたびに、アラートを発信して、それを読みにいっている人がいますが、あれほど非効率なことはありません。

アラートなんて全部切りましょう！

通知はすべてオフ。

そして、読む時間を限界まで制限しましょう。例えば、メールは１日に３回も見れば十分です。とにかく見ない。

見るときはそれようの時間をあらかじめスケジュールに追加しておく。それくらい、見ない。その時間以外は見ないという固い意志をもってください。

もっとも大きな時間のロスがこれです。

確かに人付き合い的には厳しくなるかもしれませんが、生産性は１０倍くらいになります。一週間でいいので試してみてください。（本当に）

また、当然ですが仕事中にSNSにアクセスするとかもNGの極みです。同様の理由で。

時間泥棒その２ 電話

これはできる人だけやってください。できない人もいるでしょう。

しかし、電話から極力離れるという考えは持っておいて損はないです。電話の近くにいて、いいことはないです。

当たり前ですが、かかって来たらとらなくてはいけないのですから。

対顧客の部署では電話がもっとも大事なものなので、必ず、一瞬でも早く取るべきです。

しかし、エンジニアは違います。エンジニアの存在目的はプロダクトを作ることです。内戦の電話や顧客からのマニュアルに書いていあるようなサポートのために存在するわけではありません。まして、営業の電話をうけるのなどは論外です。

とにかく電話から逃げましょう。（逃げられるなら）

※ 顧客サポート部隊に属しているのに、逃げるとかは職務怠慢なのでやめましょうね。

時間泥棒その３ 話かけらる

話しかけられるのはエンジニアの常です。他のエンジニアからだったり、営業さんからだったり、PMからだったりしますが、とにかく常に話しかけられます。IT企業以外でエンジニアをやっている人ほどそれを理解しているでしょう。

なぜなら彼らは他の人の時間や集中力を大事なリソースだと思っていないからです。

ではどうするべきか？

まずは、話しかけるなオーラを出しましょう。いえ、不機嫌そうにしろというわけではなく、イヤホンをして、画面にのめり込むように仕事をしましょう。それだけで、話しかけてくる人の数は激減します。びっくりするほど。

イヤホンは極力大きい物。イヤホンよりはヘッドホンの方が良いです。

そしてちなみに、コーディングをしながら、音楽を聴くのは止めましょう。明らかに集中力を切らします。マルチタスクは、人間には向いていません。

音楽はOFF。見せかけだけのヘッドホンを装着しましょう。

つづいて、打ち合わせの時間を決めてもらう。

５分でも１０分でも打ち合わせの時間を決めてもらう習慣を持ちましょう。

ちなみに６０％くらいの質問は時自分で解決できるものだったりします。調べるのが面倒だから聞いたりですとか、自分で考えるのが億劫だから聞いたりですとか、責任を一緒に追ってねという意味での質問が大体です。

なので、これだけで質問が４割くらいは減ります。なぜって、会議を設定するよりは自分で考えた方が楽だからです。

時間が倍増する

これだけで、今までの２倍は集中の時間が取れるようになります。そうすれば生産性があがりますし、バグを直すのも、顧客からの希望機能を作ることもできます。結局社内全体にとってはいいことだらけです。

性格悪くなれ、というわけではなく、自分の集中力を最大限生かすためにはどうすればいいのかを意識しましょうという話です。

これがなかなか難しいという人は、自分がどこに時間を使っているか、測ってみることをおすすめします。かなりの危機感を覚えて改善の方向に向かおうと思い出すはずです。きっと！

時間というリソース、あなたは大事に扱えていますか？

松田

PS

ちなみに、だからこそ、自分もそれをするのをやめましょうね。
相手の集中が切れたときを見計らって、話しかけたり、依頼をしたりしましょう。

PPS

プログラミング・エンジニアリングを学ぶならこちらから

「えっとここって何が書いてあるんですか？」

「ああ、これは◯◯している場所ですね」

「これって何してる関数ですか？」

「これは△△のモデルにデータを取りにいっています」

「ここで宣言している変数って何に使っているんですか？」

「えっと、これは、、、」

うちのスタッフとの会話です。

彼はかなり育ってきたスタッフで、スラスラとコードを書いてくれるようになっています。ほとんど放置しても大丈夫で、とても楽になってきました。

しかし、最近プルリクでコードを確認すると、上記のような会話が頻発するようになってきました。

僕の理解力が低いのではという話は置いておいて、これは少しまずい傾向です。

初心者を抜け出して、少しコードが書けるようになってくると、陥る罠があります。

かっこよく書きたくなる

ビギナーのレベルを超えた人間が次に目指すのは「かっこよく」です。特に男性陣はその傾向が強い。

・とにかく短く書こう
・とにかくライブラリ化して使いまわせるようにしよう
・関数をたくさん作ろう（何をとってきてんだかわからんgetホニャララ）

とか、そのような感じです。これは初心者ゾーンを抜けたエンジニアによくある病です。

当然、これらが100%いけないわけではありません。向上心も二重丸です。しかし、程度もんだという話です。

目指すべきゴール地点がずれているのです。

かっこよく書くのがゴールか？

なぜ、コードを短く書くかというと、その方がわかりやすく読みやすくなる「可能性が高い」からです。

1万文字の文章と3000文字の文章、どちらの方が早く読み終わるでしょうか？

後者の方が、時間がかからないですよね？　

コードも一緒で、3000行のコードと1000行のコードを読むとき、後者の方が早く読めます。

だからこそ短く書くべきなのです。

ライブラリや関数を作って使うのは、それが再利用できて、便利で、コードが読みやすくなるからです。

解読難度の高い１行を作った時点で、どんなに短いコードであっても、読むのに時間がかかるようになります。

少なくとも今は一回しか使わないものをライブラリ化しても、工数も無駄にしますし、コードを読みに行くのが非常に手間です。（３回くらい同じこと書く必要ができたらやるべき）

ゴールは読みやすく

「かっこよく」という定性的な自己満足ではなく、「読みやすい=他人が読んで時間がかかりずらい」という定量的なゴールを目標にすべきです。

自分だけ知っているニッチなフレームワークの隠れ関数を叩いても、他の人にとっては邪魔なだけです。

自分以外が読んでもわかるか否かを基準にコードは書くべきなのです。

どうしても使いたくなったら、上にわかりやすいコメントを書きましょう。（社内wikiは読みに行くのが手間だし、そもそも調べにいかないことが多々）

メンバー全員が、「周りの人が読みやすいコードを」を意識して書いてくれれば、それだけでいいプロジェクトになりますし、メンバーが仮に抜けたとしても、その後のフォローは格段に楽になります。

読みやすいコードを書くには？

オライリーのリーダブルコードを読みましょう。

以上！　笑

あとは、コミュニケーションと一緒です。一人で暴走しないようにしましょうね。周りに合わせて話す大きさと速度を変えましょうね、ということです。

松田

PS
空気を読めという話ではないので、それが全員に伝わるように研修をやるとかも可。

ただし、新しく入ってくる人がわからないので、マニュアルを作るか（面倒だけど、、）、もういっそプログラムごとの標準的コーディング規則およびドキュメントや本に頼りましょう。

PPS
プログラミングを学ぶスクールならこちら

つい先日、LPI-Japan（LPIC主催団体）の会合で、デージーネットの恒川さんとお話をする機会がありました。『ドラッカーさんに教わったIT技術者が変わる50の習慣』を書いている方ですね。（IT系の本としては、とても珍しいほど売れている良本です。ぜひご一読を）

せっかくの機会だったので、質問をしてみました。

「プロフェッショナルなエンジニアになるために、
　まずやるべきことってなんだと考えていらっしゃいますか？
　未経験や初級レベルから意識すべきことで」

ほとんど当たり前かのように、恒川さんが出してくれた答えが、

「タイピングをとにかく速くすることでしょう」

でした。

タイピングを速く！

恒川さんの会社では入って来る新卒に対してもタイピングを徹底するように指導するそうです。会社にソフトがあり、そのソフトを基準に実施しているのだとか。

とにかくエンジニアの最低限の条件としてタイピングを早くしてもらわないといけないという話をしてもらいました。

即答でこの回答が来たことは、とても意外でしたが、たしかに納得できるものでした。

なぜそれほどタイピングが大切か？

答えはわかりやすくて、思考をすぐにアウトプットできないと、思考の速度がタイピングの速度になってしまうからです。

一般的な社会人にも必要な能力ですが、エンジニアはなおさらです。エンジニアは書くことが仕事ですから、思考をそのままなるべく速くアウトプットでないと、話になりません。作家さんなども同じなのですが、自分の思考スピードでものが書けないと、その速度でしか思考が進まなくなります。

人間は多くの場合アウトプットの速度に合わせて思考をします。話すのが早い人は頭の回転が早い傾向にあるのも、それが一因でしょう。

エンジニアの生産量には100倍の差があるという話がありますが、生産性の高い人は確実にタイピングも早いです。

トライアンドエラーに速度の差が出る

また、タイピングが速くなるメリットにトライアンドエラーが繰り返せるというものがあります。恒川さんの本にも詳しく書いてありますが、タイピングだけで5〜10倍の差がでます。

トライアンドエラーを1/5しか実施できなければ、その分、学ぶ量が圧倒的に少なくなるのはよくわかると思います。その分だけ成長率は下がりますし、長期間見ると大きな差になってきます。

タイピングをどれだけトレー二ングするかで、そのときの生産量だけではなく、成長の速度も変わってくるということです。

仕事ができるように見える！

もうひとつ、副次的な効果ですが、タイピング早いだけで仕事ができるように見えます。それはもうびっくりするほど仕事ができるように見えます。

近くにいるタイピング早い人を思い浮かべてみてください。多分、仕事も速い、印象がないですか？　実際の仕事量はなかなかわかりにくいのですが、タイピングの速度だけでファーストインプレッションに大きな効果があるのです。

タイピングの速度を上げるだけで仕事ができるように見えるのであれば、これほど楽なことはありません。ひたすらに向上させるべきです。話し方を変えるとか、プレゼンスキルを身につけるとか、発想力を上げるとかよりも目標が具体的なだけに目指すのが楽でしょう。

LAの授業や研修でもそう

また、授業・研修でもタイピングが遅いため、打つにのに必死になり、授業についていけないという人がやはり出てきます。

授業がわからないという相談の大きな原因が、だいたいここにあります（本当です）。タイピングに必死になり、考えるという時間がないのです。じゃあ、長く時間を取ればいいのかというとそういう訳でもありません。人間が集中できる時間はそれほど変わらないので、いつまでたっても終わらなくなります。結果、途中で挫折しがちです。

LAでも極力練習をしてから、クラスに入ってもらうようにしています。そうすることで、習得率はあがりますし、考える時間がとれ、質問の質も上がり、クラス全体がいい雰囲気になります。

練習方法と基準

練習方法は、とくにはじめのうちは、なんでも構いません。ウェブにいくらでもタイピングソフトやタイピング練習サイトが落ちているのでそれを利用しましょう。

私がよく研修などでも利用するのは、「寿司打」です。寿司を食べていくら儲けられたかというゲーム性も強いタイピングソフトです。検索してみてください。

ただ、慣れてきたら、日本語ではなく、英語のソフトを使ったほうがいいでしょう。

日本語ももちろんたいせつなのですが、どちらかというと、初心者がつまづくのは記号です。そちらも練習をすべきです。

オススメは下記サイトです。

http://typing.lk/

コードのタイピング練習には最適です。

理想的には１秒間に10文字程度のペースで打てるようになるといいです。

練習しましょう！

速くする方法はひとつだけ。練習あるのみです。

あまり意識したことがない人も多いでしょうが、確実にあなたの人生を向上させるので、時間を見つけつつ楽しんで実施してみるのをオススメします。

松田

PS
プログラミングを学ぶならリスキルテクノロジー

From: 松田航
新宿本校にて

「とりあえず動くようにしてくれ！」

多分、先週の日曜日に、僕がもっとも発した言葉です。

リリース直前のアプリケーションがあり、これがなかなか完成しない。そのため、リリース日当日に、スタッフのエンジニアにそんなことを言っていたのでした。

いや、今思っても最悪に近い言葉ですね。僕自身もコードを全力で書いていたため、若干焦り気味だったのでしょう。

ちなみに、PM（プロジェクトマネージャ）がコードを書き始めると大体残念な結果に終わるプロジェクトが多いので、極力書かない方がいいです。全体に関係のない、API叩いてデータ取ってくる、とかそういう箇所だけやるのなら影響範囲が小さいのでOK。

で、話を戻すと、「とりあえず」という発言はそれはもう、リスキーで、情けない言葉です。

ちゃんと失敗する

アプリケーションの不具合は発見できるのが早ければ早いほど、その後の修正は少なくて済みます。他部分への影響が小さいのですから、そりゃそうですよね。だから、単体テストをいかにしっかりと実施できているかが、最終的に安定稼働するアプリケーションになるかどうかを分けます。

問題点が早くに発見できるのは、最終的にすごく健全で、堅牢のソフトウェアができることを意味して言います。だから問題を発見できるようにすべきなのです。

だから、「とりあえず」動かすのではなくリリース前であれば尚更、エラーを表示させてちゃんと失敗をすべきです。

作り始めは全力でエラーを表示

とにかく作り始めた段階ではエラーは目立たせるべきです。PHPのCakeフレームワークのエラー表示など素敵です。赤字のバーが上部に表示される形ですね。自分でゼロからアプリケーション作る場合でも、あれを表示させてもいいくらいです。

エラーをウェルカムしましょう。エラーが出たときにいちいちへこまずに、

「よし、また一個素晴らしいプログラムに近づいた！」

になったと思うべきです。完全に思い込みましょう。自分のストレスを減らすためにも。

つい先日、エンジニア向け本の中で20万部を超える大ベストセラーになった奇跡の書「なぜプログラムは動くのか」の著者、矢沢さんに講演を行ってもらいましたが、講演の中で、こんな話が出ていました。

「コンパイラやエラーそのものを大切に扱いましょう。彼らはあなたをマンツマーンで叱ってくれるいい先生です」

まさしくだと思います。

（要約前「コンパイラを女優の◯◯だと思えば、叱られるのを幸せに感じるでしょ！」笑）

予測できない問題への対応

予測できないような問題に対応できる方法はとても大切です。ソフトウェアの品質が本当に試されているのは、何か問題が起きた時です。

誰でもミスを犯します。仕事を進めていく中で愚かなミスがあります。人間ですから。でも、そのミスをなるべく早く見つけることができれば、後からの問題は激減します。

きちんとミスをするのがリスク回避につながる！

またどこかで書こうと思いますが、breakのひと文言だけで、60億円の損失を発生させた例もあります。

真っ青になるなんてものじゃないでしょう。

ちゃんとミスしましょう！
とりあえず、動けばいいとか言わずに！

松田

From: 松田航
新宿サザンテラスのスタバにて

先日、リスキルテクノロジーのインターン生から、いい質問を受けました。

「プロフェッショナルなエンジニアになるためにはどうしたらいいでしょうか？」

漠然としていますが、いい質問です。あなたも考えたことがあるかもしれません。

もし、あなたもなんらかの分野で成功したいと思っているなら今日のメルマガは参考になるはずです。プロフェッショナルになるための"現実的な"方法についてお伝えするからです。

プロフェッショナルになるには？

この方法はすべてのプロフェッショナルに当てはまります。このステップに従って、自分のキャリアを組み立てればほぼ確実になんらかの成功を手にするでしょう。金銭面か地位か時間かは、個人の望みによります。

僕もこのステップに従って動いていますし、今後も肝に命じたいと思っています。

ステップその１：分野を選ぶ

何でもいいからプロフェッショナルになればいいというわけではありません。まず重要なのが分野を選ぶということです。

ビジネスでいうとポジショニングです。これは事業だけではなく、個人にも当てはまるということです。

今からCOBOL（すこし古くなったプログラミング言語）に時間を投下して、プロフェッショナルになったところで見返りは小さいでしょう。ただプロフェッショナルになるのではなく、なんのプロフェッショナルになるのかということをまず意識する必要があります。

できるだけ長く持つ分野。とはいえ、新しすぎてブームが去ったら、すぐに消えそうではない分野。を選ぶ必要があります。

それだけではなく、需要に対して供給が少ないものに時間を投下すべきです。例えば、いまからHTMLのコーディングに時間を投下し、誰よりもミスが少なく、インデントをきれいにコーディングができても、見返りは小さいでしょう。Webがある限りなくならない技術ですが、それでも見返りが小さいのです。

だからまずは分野を慎重に選ぶことが必要です。

・その分野の将来性
・需要と供給バランス

なるべく価格競争に陥らず、将来長持ちする技術や分野に時間を投下するのが賢明です。それが難しいという話もありますが、そこはある程度の判断をし、次のステップによってリスクを下げます。

ステップその２：すこし上の階層も視野にいれる

分野を決めるとはいっても、その分野に固執するだけではリスクがあります。なぜなら、領域が小さければ小さいほど、その領域には「旬」があるからです。

特にエンジニアリングの領域は変化が激しい業界です。あるフレームワークのプロフェッショナルになっても、３年後にはトレンドが変わっているというのはよくあることです。

そのため、ひとつ上の階層に目を向ける方がいいでしょう。

プログラミングのプロフェッショナル・サーバのプロフェッショナル・ネットワークのプロフェッショナルという階層をまず視野に入れて、それから、さらにJavaやRubyのプロフェッショナルという風に一段下も見るという視点を入れてください。

そうすれば、仮にRubyが時代遅れになっても、プログラミング全般の知識があるため他の分野への移行はスムーズになります。（もともと、ひとつの言語を極めようとするとそうなります。しかし、割とそうじゃない人もいるのが事実です）

デザイナでもマーケタでもそれは同じです。企業だけではなく、個人もリスクヘッジはとても大切だということです。

そうすることで、耐久年度はあがり、あなたの価値は長続きします。

ステップその３：１万時間投下する

１万時間の法則という法則をご存知でしょうか？

１万時間その分野に、プロフェッショナルになれるという法則です。マルコム・グラッドウェルという人唱えた理論です。感覚的にも、この理論はとても現実に即しています。

幸い、僕たちがいるのはビジネスの世界です。スポーツの世界ではありません。0.1秒や0.1mを競うような世界ではないのです。

才能はもちろん作用しますが、才能以上にどれだけ時間を投下したかで、十分に勝てる領域に行ける分野なのです。

１万時間というのはどれくらいの時間でしょうか？

１日３時間、毎日で１０年間かかります。

仕事で関わっているのであれば、１日８時間、平日だけで約2000時間。５年間でプロフェッショナルになれます。

ジャンルを決めたら、そこに時間を投下する覚悟を持ちましょう。

反対にいうと、５年はかかるということです。すぐに成功したいと望むのは人間のサガですが、これを頭に入れておくと、忍耐を忍耐と思わずに済みます。自然なことだと捉えられるようになるのです。

ただし、プロフェッショナルになる前が素人で食えないかというとそんなことはありません。ある程度で十分に稼げるようになります。その中でもプロフェッショナルを目指すならという話です。

最悪なのが、、、

途中で諦めて次の分野に移ることを繰り返すことです。別の分野に移ると楽しいし、楽ですが、すぐに時間が経過してしまいます。いつのまにか５年経っていたということになりかねません。

もちろん、最初の１時間がなければ、残りの9999時間はありません。しかし、自分のキャリアは慎重に選ぶ必要があります。

エンジニアリング・マーケティング・マネジメントが今後１０年では重要知識になると僕は思っています。いずれかを選択されることをオススメします。マネジメントはなかなか勉強が難しいですし、実践しにくいですから、エンジニアリングかマーケティングでしょう。

現実的にプロフェッショナルを目指す

これがプロフェッショナルになるための現実的な方法論です。

宝くじを当てるよりも、片手間にFXに手を出してみるよりも、不動産投資をやるよりも確実にあなたに金銭的利益ももたらしてくれます。

世の中誘惑がいっぱいですが、それらに振り回されないようにしましょう。

あなたはどの分野に時間を投下しますか？

松田

PS

僕は「教育事業」というまた別の視点に１万時間を投下しています。このような投資の仕方も、（オススメはしませんが）ありです。特化して、そこに集中することです。

PPS

一方で全体像を理解していることは大事なので、その話はまた時間があるときに。。