システム開発に必要なのは理数系のスキル？
「スマホアプリの開発をやっている」と知人や友人に説明すると、よく「俺は理数系得意じゃないからできないな〜」と言われます。 確かに私も理数系が得意であればもっと良いプログラミングができるんだろうなと思うことはありますが、必ずしも必須じゃないです。
必要なのは理数系スキルではなくて論理的な考え方と想像力
システム開発で重要なのは論理的な考え方と想像力です。 微分や積分の公式だとか、接弦定理を知らなくても問題ありません。 システム開発のお仕事というのは下記のような課題を解決することを繰り返します。
「１という数字を"いち"という平仮名に変えたい」
これに理数系スキルはあまり必要なく、論理的な考え方と想像力で作業を進めていきます。
・１という数字の型がintegerなのか、2byte文字なのか ・数字型だったら文字型に変更した方が使いやすいかな ・よく使いそうな機能ならいつでも使えるようにしておこうかな
これを料理で例えてみます。
「じゃがいもをフライドポテトに変えたい」
この問題を解決するためには以下のような行動が取れます。
・じゃがいもは皮をむかないといけないのか、皮付きでもいいのか ・皮つきのポテトじゃなかったら、皮をむいていたほうが使いやすかな ・よく皮をむくのなら包丁じゃなくて皮むき器のほうがスピードが速いかな
同じように論理的に考えて、想像力を使って便利にしているだけなのです。 これはシステム開発だけでなく、あらゆる職種で必要とされているスキルです。
文系と理系の違い
これは諸説あるんですが、私は以下の基準が最も確からしいかなと考えています。
文系 … 考える時の基準が自分が正しいと思うかどうか：主観的 理系 … 考える時の基準が自分以外の事実で判断する ：客観的
「数学は表現方法の１つ」という言葉
これらはすべて数学的な要素があります。 恥ずかしい話ですが私は中学生の時は音楽やイラストを描いたりと、芸術の道に進みたいと思っていましたので理数系の勉強については得意だと思ったことがありませんでした。 むしろ数学が役に立つわけない信者の１人でした。
覚えていないのですが過去に見た映画や本の中で「数学は表現方法の１つ」という言葉がとても印象に残り、それ以来数学的なことが好きになりました。 「愛してる」という日本語は「I love you」という英語に変換することができます。 英語が話せる人は世界が違って見えるんだろうかって思うことがあります。 それと同じで数学ができる人は世界が違って見えるんだろうかと思うようになりました。 ロマン大事です、ロマン。
デザインに関しても同様です。 可愛いは作れますが、客観的に伝えれるように定義することができません。 美しさは作れますし、客観的に伝えれるように定義することができます。 「黄金比」というキーワードがそれに当たります。
黄金比とは、黄金比を使ったすごいデザインテクニックのまとめ -Webデザイン・紙デザインに | コリス
私は個人的な趣味でデジタル一眼で写真を撮るのですが、これを意識している写真と意識していない写真では同じカメラで撮っているのにまるで違います。 芸術的なことにも実は数学が使われているということがわかった時はますます数学的なことが好きになりました。
まとめ
連日、ビジネス的なことを書いてきて飽きたので今日は雑談です。 皆様も日常生活で数学的なものを見つけたらロマンを感じてみてください。 くだらない話ですいません。
即戦力って何？（ハナホジー）
我々エンジニアの業界だけでもなく、どこの業界でも人手不足との声が聞こえてきます。 「本当に人が足りてないの？」と聞くと「実は、即戦力になるような人材が採用できない」と言われることが多いです。 私は頭が悪いので「即戦力」と言われても具体的なイメージが湧きませんので、「大変ですねー」と言うことしかできないのですが、このようなことが起こらないように弊社で実施していることを書こうかと思います。 もっといい方法などあったら教えてください。
マンハッタンコード全体で取り組んでいること
仕事の生産性や技術を向上させるための仕組みは人によって違うため方法は多種多様です。 ですが世の中にはこの仕組みを持っていない人もたくさんいます。 弊社ではこれを真摯に受け止めて、社員の個人を尊重しつつ最低限のやり方を覚えてもらっています。
資料なしLTでも、セミナー形式でも発表はガンガン推奨：方法の共有
運転する方法を知らなければどんなに速いスポーツカーを持っていても走ることすらできません。 これと同じで優秀な参考書をたくさん会社が買い与えても、勉強する方法がわからなければ習得スピードは向上しません。
弊社では社員が各自で持っている良い仕組みをみんなに共有しています。 共有の形式は様々でLT方式で説明する人もいますし、資料を作ってからセミナー方式で説明する人もいます。 これは社員だけでなく他社の方もよく参加してもらっています。 知りたいのはみんなが取り入れたらよくなる行動や方法なので効果測定などは行っていません。 「いいものがあるのよ〜、奥さん〜」のノリです。
ペアプログラミングの導入：経験の共有
新しい技術について自ら本を買って勉強したり、ネットで調べて勝手に一人でやっていける人もいます。 しかし悲しいことにどんな業界のどんな職種でも、これができる人は圧倒的に少人数です。
世の中には大衆的な飲食店でも独りで初めてのお店に入れない人の方が多いのです。 私も小さな子供の頃から親や兄弟といろんなことを一緒に経験して大人になってきました。 経験は共有することのできる行動です。
この考えを基にして弊社では「まず一緒にやってみる」ということを意識して行っています。 例えば、ずっとサーバの開発しかしてこなかったエンジニアさんが「iPhoneアプリ作ってみたい！」となったら、iPhoneアプリのエンジニアさんが隣で一緒にツールを動かしながら作ります。 AWSを触ったことのないエンジニアさんがいれば一緒にサーバを立ち上げてみます。
同じ場所にいなくても継続してできるようにScreen Heroというツールの導入しました。 このツールは同じ場所にいなくても自分のPC画面を共有することができ、共有される側もソースを書くことができるのでペアプログラミングに最適です。 xcodeでも使えるので、とても使いやすくおすすめです。
Screen Heroでペアプログラミング - 髪も切れるiOSエンジニアのブログ
おまけの実例紹介
先日は私が「調べる」ということをテーマに１０分間のLTを行いました。 発表する前日に思いついたので資料は用意できませんでしたが、ホワイトボードに要件を書いてLTを行いました。 はじめはテーマだけ聞いて「調べるについて発表？」と首をかしげていた人もたくさん質問をしてくれたりして嬉しかったです。 LTが終わった後に「単純なことだったけど、言葉や図にしてもらってわかりやすくなった。意識してみます」と言ってもらって嬉しかったです。
目的と狙う効果
個人で勉強するスピードが向上する
運転の方法というのは実は軽自動車でもトラックでも基本は同じです。 車種によって注意することは違いますが、運転する方法を学んでいる人であれば覚えるのも早いです。 これと同じで１つの技術を覚えてしまうと２つ目の技術を習得するスピードは圧倒的に上がります。
まだ人数は少ないですが、弊社ではほとんどの社員がたった１年でswiftでiOSアプリを作り、AWSでLAMP環境によるアプリを作れるようになってます。
勝手にコミュニケーションが取れる
弊社では「コミュニケーションを円滑にするために飲み会を開く！」なんてことは一切していません。 ですが他社の方たちからはよく「みなさん仲が良いですね！」と言っていただけます。
勉強でも作業でも一緒に行動することで嫌でも言葉が増えます。 説明するには会話が必要です。質問するのにも会話が必要です。 勝手に言葉を交わすことになるので自然とコミュニケーションが生まれます。
影響とリスク
社内の雰囲気が変わる
勉強することは良いことだ！楽しいことだ！という雰囲気になります。 「勉強しないとなー」と社員が口にする回数も減ってきました。 そして今では「勉強しないとなー」という言葉は「悔しい！！」という意味に変わりつつあります。
自発性が生まれた
「〜について発表してみんなの意見を聞いてみたい」「〜さんが来たら〜のことを聞いてみよう！」という自発性が生まれています。 何より社員本人が充実してそうな姿を見れることが非常に嬉しいです。
リスクは時間がかかること
１人でやることに比べたら２人でやる方が時間は２倍かかります。 独り立ちした後のスピードが圧倒的に早いので私は十分に元が取れると考えていますが、投資の初期コストをケチりたい人にはおすすめしません。
まとめ
弊社がまだ小さい規模だから実施できているのかもしれませんが規模なんてただの数字です。 いいと思う、いいと考えるのであれば小さく始めればいいだけです。 １００人規模の会社だったら、最初は５人くらいと一緒にやってみる。 できそうだったら徐々に横に展開すればいいだけです。 自分の行動が変わらなければ周りも結果も変わらないです。
この取り組みから弊社は長く運営をしていけばいくほど、他社に比べて有利にビジネスを進めることができると考えています。
ビジネスが下手くそな人ほど移動時間をコストとして見れない
ビジネスにはリソース（資源）となるものがあります。 有名なのは「ヒト、モノ、カネ」ですが、本当はここに「ジカン」も必要です。 我が社が行っている生産性向上の取り組みの１つを紹介します。
マンハッタンコード全体で取り組んでいること
原則、社員の自宅最寄りから現場への通勤時間は基本的に30分程度にする
ただし本人の希望により変更は可能です。 弊社は東京に会社があり、お客さんも東京ですので基本的な移動方法は電車を使います。 この移動を極力30分以内にしています。 東京駅から横浜駅は26分で移動できます。 30分以上も電車乗るとか、東京の人間にとっては単なる旅です。
弊社所在地に対して45分以上かかる場合は補助金を出して引越しを提案する
ご家庭の事情などは十分に考慮させていただいております。 当然郊外に比べて家賃は高くなりますので、そこは会社から幾分か補助しています。
目的と狙う効果
小さな行動の積み重ねが効果を生みます。
営業交通費の圧縮
遠ければ遠いほどお金かかります。 得られるお金が決まっている契約の場合はお金がかかればかかるほど事業としてはマイナスです。 ケチくさいかもしれませんが毎日移動にお金を使うくらいだったら新しい備品買います。
社員個人の時間確保の向上
遠ければ遠いほど疲れが溜まります。 社員のモチベーションが下がる要因は容易に見つかりますが、上がる要因はありません。 弊社ではこの取り組みにより確実に他社より個人の時間を確保することができます。 これがモチベーションと個人の勉強時間の増大することとなり、 他社よりも技術力の向上スピードが早いです（自画自賛）
具体的な数字で見る通勤時間
通勤時間の世界平均は32分30秒で、これに対して日本の平均は39分30秒でした。
平均の通勤時間、知っていますか? | 業務基礎スキル診断株式会社
たいした違いがないように見えますが、これを日本国内に限って分析するとかなり違います。
東京圏 51分 大阪圏 43分 人口30万人以上の地方都市 34分30秒
大都市ほど通勤時間が長いのです。 調査によっては大都市の通勤時間が1時間を超えるものもありました。
通勤時間の平均は往復1時間19分、大都市圏勤めほど長い傾向(2016年)(最新) - ガベージニュース
首都圏は電車バスなどの交通機関が発達してしまっているので、 車通勤がメインの地方都市よりも時間がかかっているのが大きな要因です。 大都市の通勤時間が日本の通勤時間平均を引き上げているということがわかります。
仮に毎日3時間近くを通勤に費やすと60時間も移動してます（月20日出勤x往復3h） 年間では720時間も移動します（12ヶ月x60h）
影響とリスク
毎日満員状態の電車に乗ることでストレスや疲れが発生しやすくなります。 特に最近の東京の埼京線、東西線などの満員状態は異常です。
冬の時期は流行病に罹りやすくなります。 私の知り合いは電車に乗っているだけで押し潰されて骨折しました。 同じ業界の知り合いは業務で使用するPCを壊されました。
電車内の乗客同士で起こったトラブルは鉄道会社は関与出来ず、 警察や弁護士を入れて当事者同士が対処することになります。 こうなると時間とお金が大量に費消されていきます。
弊社では遅刻してもいいのでちゃんと状況を把握して、 リスクは見送るように社員にはお願いしています。 これは他の作業のリスクコントロールにおいても良い影響を与えてくれています。
頭のおかしい人間や、考えが古い老害は「たかが満員電車くらいで」などと反論してきますが、 この精神論はお金も時間も生み出しません。 聞く価値はゼロどころか確実にマイナスなので聞き流しましょう。
まとめ
通勤時間が長い事のメリットとしては「本が読める」「ゲームができる」などが挙げられますが、そんなものは抱えるリスクと、抱えない時のメリットに比べるとカスです。 電車を降りてからゆっくりカフェで本読んだ方がよっぽど内容が頭に入ります。 家に帰ってからダラダラとゲームやった方が絶対楽しいです。
ただこういう細かい内容について考えたり施策を実施したりする会社はほぼないので、 弊社は有利にビジネスを進めることができるという証拠の１つとしてはありがたいです。
ブログ始めました。
うちの社員さんたちにブログやればいいじゃんwとか言っておいて、自分がやってないと批判が出ると思ったので始めました。
プログラミングとか技術的な内容は正直Qiita使えばいいと思ってるので、こちらのブログは会社の経営だとかビジネスだとかそういう内容を書いていこうかと考えています。
よろしくお願いします。
