From: 松田航
新宿本校にて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なぜか？　

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

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

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

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

時間泥棒その１メール

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

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

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

通知はすべてオフ。

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

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

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

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

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

時間泥棒その２ 電話

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

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

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

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

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

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

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

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

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

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

ではどうするべきか？

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

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

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

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

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

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

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

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

時間が倍増する

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

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

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

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

松田

PS

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

PPS

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

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

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

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

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

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

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

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

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

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

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

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

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

かっこよく書きたくなる

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ゴールは読みやすく

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

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

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

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

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

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

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

以上！　笑

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

松田

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

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

PPS
プログラミングを学ぶならこちら

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

つい先日、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万部を超える大ベストセラーになった奇跡の書「なぜプログラムは動くのか」の著者、矢沢さんに講演を行ってもらいましたが、講演の中で、こんな話が出ていました。

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

まさしくだと思います。

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

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

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

• 間違いに気づいたら、とりあえずの処理をしない。納期の問題で仕方がなかったら、少なくとも、メンバーのに状況を共有する。wikiにあげてもいいですし、slackで発言してもいいでしょう。
• 解決策を提示しよう。時間リソースが足りずに、自分が解決できなくても、こうすれば解決出来るという道を見出して、メンバーに共有しましょう。できれば、そのメンバーのリソースで適用可能な対処法を提示できると、その人は重宝がられます。極端な話ですが、ある新規のプログラムを作成していて、OracleにDBを変えれば、大丈夫。というような解決策は、まぁ残念な訳です。
• 早く相談する。相談する相手がいれば、相談することです。プロマネでもいいですし、技術のメンターでも構いませんし、仲良くなった技術者に「今度おごるから！」と叫んで協力してもらってもいいです。早めに相談することがデスマーチから遠ざかる道です。

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

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

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

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

松田