島までは遠い

佐藤正志@サークルアラウンドのことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる予定。しばらくは工事中。

IT技術者の勤める会社の分類、こんな感じで合ってます?

f:id:ms2sato:20180914090239j:plain

はじめに

ms2sato.circlearound.co.jp

前にこんなエントリ書いてたんですけど、結構ギリギリまで「言語で分けるか業界で分けるか」とか迷ってたんです。その当時はとりあえず言語軸で分けてみた書き方にしました。

最近「SES」「自社開発」を比べている言説が結構多いように見受けられますが「この分け方ってザックリし過ぎじゃないですか?」って思ったので自分なりの表現をしてみたいと思います。例のごとく私は統計を取ったわけでも確かな情報を元に書いているわけでもなく、見聞きしたことと自分の経験から書いています。というわけで「そうじゃねぇよ、こうだよ」というのがあったらどんどん出してもらえる方が、私もハッピーになれるのでよろしくお願いします。

前提・注意など

零細な会社や例外な会社

物事には必ず例外があると思うので、類型っぽくまとめることができたとしても「そうでないもの」は大抵あると思います。特に零細な会社は社長の力が強いので「分類としては何かに属しているかもしれないけれど、その実そんなことはない」という事がよく起こるのではないでしょうか。通常の倫理が働かずにとんでもないブラックとかも混ざっている可能性はあります。零細は良くも悪くも社長次第かと。

「パターンで考えすぎるの危険もありますよ」ってことで一つ。結局一社一社違う事やっているので、最終的には自分で何かを見極める必要があるはずです。

お金と余裕

もう一つ前提を。会社経営の余裕は結果としてキャッシュの話になると思います。余裕のなさは以下のようなところの反映されるはずです。もちろん「余裕はあってもやらない・やれない」という文化的なものもあると理解しておくと良さそうです*1

  • 新しい事業に時間やお金を投入する事ができない
  • 新人をゆっくり育てる事ができない
  • はやく帰る事ができない

そしてもちろん例外はあって、どんなにキャッシュに余裕があっても「もっとひたすら儲けたい」という考え方をする社長なら、結局余裕は無いわけですね。

自社開発系

自分の会社で開発できる会社を書いてみます。

スタートアップ

小規模・零細

基本的に調達をして、ビジネスが大きくスケールするのを目指しているのがこの界隈です。なので事業が小さいうちは全く余裕がありません。スピード優先で顧客を獲得していかなければキャッシュが無くなって会社は倒産しますし、VCの期待に応えられなければ次の調達が無いかもしれません。そういう事情から「もっと働け、死ぬほど働け。」になりがちです*2

また、人数が少ないということは多様な業務を要求される可能性もあり、プログラマーとして雇われたけれどプログラミングだけではない様々な雑用をしているようなケースもあるでしょう。高い給金よりも、ストックオプションや向かっているビジョンような「会社の将来」をモチベーションにして動く事が多いです。会社制度も整っていないことが多いです。

親切に何かを教えてもらえるような事を待つ人には向きません。誰にも教わらなくても自分で工夫して成果を出そうとするタイプの方がマッチしています。いい意味でギラギラしたエネルギーが必要な分野ではないでしょうか。

大規模・メガ

様々な苦難を乗り越えて安定を手に入れたスタートアップは、自分たちの事業から黒字を生み出してある程度の余裕を作っていきます。既に中心になる事業で会社が運営できている状態なので、さまざまなことに投資をしやすくなっているでしょう。

知り合いに聞いている感じだと、良い意味でスタートアップらしさを失っていなかったり、創業者がそれを失わないようにアクションしたりする様子で、余裕はあるけれど切磋琢磨する環境を大事にされている様子が伺えます。

持ち帰り受託

基本的に受託の会社は小規模なスタートアップに比べれば余裕を作りやすいと言えます。シンプルに「依頼を受けて見積もりをし、作成して納品をする」というオーダーベースの製造の商売なので、見積もりを大きく間違えるような事が無ければ利益を出しやすいです。上手にやっている会社なら社内で仕事を教えながらうまく伸ばしてくれると思います。

ここで紹介するのはお客さんから取ってきた仕事を社内に持って帰ってきて開発しているタイプの会社です。古式ゆかしいやりかただと思っていたのですが、ひょっとして今はSESとかの方が増えているのでしょうか?(ちょっとこの辺よくわかりません)お客さんがITわからない会社なら一次請けとして全てを決めてハンドルできるポジションです。逆にITわかる会社に対して二次請け的にうまく協力していくスタイルもあります。

弊社は以下二つの両方をお客さんに合わせてやったりします。どちらかというと準委任にしてしまうのが多かったのですが、最近は請負もバランス良くいれていこうとしています。

請負型

「こういう仕様のものをいつまでに納品で、いくら」と決まっているやつですね。マルッと全部引き受けるので責任も大きいですが自由もあります。新規の開発になる事が多いので、利用する開発の言語や環境の提案もしやすいですよね。新規の開発の経験的には一番増やせる業態ではないでしょうか。ちなみにこれで新規を作った上で保守で月額費用をいただいていく、というのが以前結構あったスタイルかと思います(ちなみに私が過去関係した会社では「保守はつまらないから作りしかやらない」という集団もいたりして、結構色々なスタイルがあるのかもしれません)。

保守まで持っているような会社さんだと、最初は簡単なバグ対応やログ管理から始まって、徐々に新規開発のメンバーへステップアップできるような環境を作れる会社もありそうです。

期限が決まっているのに納期直前にお客さんからの仕様変更を受けて大変な目に合うとか、営業がホイホイ「やるやる」って言ってきて社内リソースが全く足らずに大変な目にあうとか、過去あったりしましたね。そういう会社は慢性的にそうなるので、注意ですよね。社内のエンジニアさんと腹割って話せないと回避できない感じしますけど。

準委任型

「能力は貸すよ。完成は保証しないよ。一時間おいくらだよ。」のようなやつです。手は貸すけれども、完成を保証しないスタイルですね。稼働量の調整がしやすいので、請負型にあった納期直前に大変!みたいなのは基本的には(契約上基本的には、です)無いものです。逆に必死になって早く終わらせてもあまり実入りがよく無いとも言えます。ただし、長期的に考えると価格に見合ったスピードや品質は大事になるので「手を抜ける」というわけではありません。

完成は保証しないのだけれども、相手側の都合によって結果的に急かされるとかは発生します。ただ、長い時間稼働するならそれは請求できるものになるので「もっと長時間働け」という圧力は会社によってはあるのかもしれません。

ある程度開発の進んだコードを途中から見ることも多いです。「まず読み込んでいく」ことが必要ですし、技術的負債のようなものに向き合わなければならないシーンも多いです。ただ、新規案件ばかりやっていると「とにかくはやく仕上がって一旦出せれば良いや」という思考に陥りがちなのに対して、こちらは既に動いているものをいかにより良く変容させるかが大事になるので、別の意味での成長ができます*3

弊社の場合にはトレーニングをやっている都合上、あまりに納期納期で追い詰められるとトレーニングの品質に影響してしまうので、この準委任型を中心に受託を構成しています。

新規事業型

既に別の事業で安定されている企業が、新しい領域としてインターネットのシステム開発をしている場合があります。あまり表に出なかったりしますが、私はこの界隈の話も何本か聞いたことはあって、環境がとても良いケースがあるのではないかと推察しています。パターンとしては以下くらいがありそうなんですけどね。

新規事業を短期で立ち上げないといけない追い詰められ型

「試しにやってみよう」という形で始まっていたりするとかなり予算を絞っているケースがあるようです。しかも短期間で、のような条件付きだったりするようです。

仕事としては面白いものがあるかもしれませんが、短期間で成果を出さないと維持できないようなところだと、そういう一定の追い詰められ環境に耐性がないと難しいかなと感じたりします。こちらのタイプだと即戦力求めるので力ある人をとにかく取りに行く気がします。もしくはマルッと社外に委託するかでしょうか。

将来に備えて別事業を求める分岐型

本業とシナジーのあるようなWEBサービスをやるなどして、会社の行く末に長期的に寄与する目的でシステム開発を始めているケースを伺ったことがあります。上記の追いつめられている感じがあまりなく、安定して開発することができたりする様子です。

最近聞いた話ですとエンジニアとしては給金が少なくなってしまう様子ですが、いわゆる労働の条件が良かったりするので*4、求めているものの本質がお金ではない方とか、子供のいらっしゃらない方など、ライフスタイルによってはとてもマッチしそうだと思いました。

ただ、エンジニア組織としての成熟がどの程度かというところがあり、成長できる文化があるかとか、良い上司がいるかどうかなどは実際に確かめていかないと難しいかもしれませんね。

社外系

派遣・SES

私は派遣社員の経験はあるのですが、SESは自社でも個人でも経験が無いです。社外に出て働くという切り口でザックリ書きますね。

基本的に自社への帰属意識は薄れます。日々一緒にいるのは派遣先のプロジェクトの人たちなので、その人たち次第で随分環境は変わると思います。

もしも能力がまだ足らない場合だとできる誰かと一緒に現場に配属されることがあるようですが、この一緒に派遣された人が育てることに意識を持っている方だととてもハッピーです。そうで無い場合にはかなり自力で伸びていくことを望まれるでしょう。

何より私がこの働き方のメリットとして感じているのは「様々な現場」を短期間に見て回れる可能性の高いことです。派遣の時期にはいわゆる大企業の二次請け三次請け、もちろん一次請けの会社も見ることができました。その中でいくつもの世界を見ることができたことは自分にとっては大きなプラスになっています。

私の頃はかなり昔の話なので、この界隈が大きく変わっている可能性は感じています。

おしまいに

一旦ザザッとこんな感じかと思うので、業界で職を求めている皆々様にあられましては色々と調査した上でご検討いただければ幸いです。冒頭にも書きましたが不足点のツッコミや誤りについてのご意見など期待しています。私の目的は「概ねこういう感じじゃないか?」と掴めるような情報が得られるようにすること、その一点です。

*1:例えば、新人をゆっくり育てるようなことは現場がそういう文化を持っていなければなかなかできないです

*2:でも、そういうことが好きで世の中を変えるようなアクションの為に今の激務に耐えられる人がいる界隈ではないでしょうか

*3:個人的にはこちらの感覚は大切にしています

*4:本業が別途進めている働き方に合わせて内容が決められているからかと推察しています

自分なりに「独身40代の孤独」と向き合う

f:id:ms2sato:20180906005329j:plain

はじめに

本当はIT技術とかプログラマーのキャリア的な内容で一本書けたらなと思っていたんです。でも帰りの電車で見かけたこの内容が僕に響いたので、勢い付けに缶ハイボール軽く飲みつつ書いてみることにしました。

qtamaki.hatenablog.com

僕は今年42歳で独身であるから、まさにこの記事のターゲットだと思います。最初に伝えておくと、僕はこの記事の人達ほど孤独を感じてはいないように思います。そのことを中心にできればと思っています。猫を飼ってもいませんし、瞑想もしていません。

純粋な「友達」はいなくなったし、増えることもない

「社会人になると、友達ができない」

どこかで聞いた話ですが、僕にも当てはまると思っています。比較的初対面を得やすい仕事内容と立場に身を置いていますが、仕事経由で出会った人は仕事の相手であるし、会社のメンバーを友達扱いしないというのは自分なりの決め事でもあるので、特別な趣味も持っていない僕には友達の増えようがありません。

では過去の友達と思っていた人達はどうかと言うと、元記事と同じように「昔話」をする相手にしかならなくなったんです。

僕にとっては「今」や「未来」の方が大事なので、彼らの「過去」を引き合いに出す内容が馴染めないのです。かと言って自分の日常や未来の話を彼らにしたところで噛み合わないのです。「明日職場に行くの嫌だ」と言っているような連中に「自分の会社は今後こういうことやりたいと思ってて、こんなことやるんだ!」などと伝えても、面白い内容にはなりませんし、そんな話を下手に引っ張ろうものなら「あいつは自分の立場を鼻にかけている」と思われるのがオチでしょう。結果的に僕の日常については積極的に言葉を出すことは無く、彼らの愚痴を聞くだけになります。もともと人の話を聞く側のポジションで定着しているのでそれ自体は問題ありませんが、今の僕にとって楽しい話は出てこないのですね。

そういうことが気になってしまってからは古い集まりから遠ざかるようになってしまいました。昔あんなに楽しかった集まりが、そうなるなんて予想もしなかったのですが。

ちなみに仕事の関係から始まっているとしても声をかけてくださるのは嬉しいので、なるべく一緒させていただいています。いつも声かけしてくださる方には感謝しています。

会社の存在

友達が増えることは無いのですが、仲間は増えているんですね。僕にとってサークルアラウンドという会社は自分の一部を切り出した存在なので、その会社に賛同してくれる人が中や外に増えていくのはとても嬉しいことです。幸い一定の絆が発生する仕事であるので、卒業した人たちが活躍しているのを知るのもとても楽しいです。

会社を作る前から人が成長するところにはコミットしてきていた事があるので、今それなりに大成していたり一定の立場に身を置いている人がいたりします。そういう人達に、今自分の事業で育って巣立っていく人を紹介したりできて、中にはそのまま会社のメンバーになっていく流れを作る事ができたりする為、今はとても充実しています。過去の自分の振る舞いが誰かに影響を与えていて、そういう人がお互いに連携していく様は大きな満足を与えてくれます。自分の過去や今の振る舞いが無駄では無いことを実感させてくれます。これは孤独に争う一つの手段になっているのでは無いでしょうか。

「10年後の彼らが楽しみだ」

という表現をよくするのですが、こうやって未来への芽を育てていく事の充実感は遺伝子に組み込まれているものではないかと感じています。子供を育てたことはないですが、親とはこういう気持ちを持って子供を育てているのかも知れないと想像しています。「ただ放置していただけだ」と僕の両親は言っていましたが。

自社のメンバーについてはそれ以上に成長を楽しみにしていて、僕と一緒にやっている中で何か伝わるものがあれば良いと思っています。ずっと一緒にやっていく事が確定はしていないと思っていますが、一緒の時間を過ごした中で社会人やプログラマーとしての哲学が伝わったらこんなに嬉しいことは無いです。

そういう中でも自分の中の決め事はいくつか持っています。今回の文脈だと下記が合致しそうです。零細企業なのでもっと家族的にやるのが良いのかも知れませんが、

  • メンバーを自分の友達扱いはしない
  • メンバーの会社以外の時間を大事にする

ということは気をつけています。どんなに仲良くできても経営者と従業員と立場の違いはあるので、自分の言葉が強制力になってしまう可能性があるはずです。端的な例で言えば頻繁に「飲みに行くぞ」と誘うのもよくある零細な会社の形かもしれませんが、あまりにプライベートに介入すれば会社や私との関係が悪くなった時に逃げ場所が無くなってしまうでしょう。そういう時にこそ会社外の関係性が大きな意味を持つので、普段から会社外の付き合いを大事にして欲しいのです。私が自分の甘えを律することも必要だと思っています。

健康とか恋愛とか

とりあえずお酒には弱くなりました。

次の36時間くらいの能力の低下を覚悟しないとちゃんと飲めないので、必然的に回数が減っています。会社に関係ない人間関係は夜のお酒からスタートする方が楽だと思う方なので、これが友達が増えないことに拍車をかけました。立場的にも、もっとお酒の場所にも出てネットワーキングした方がいいのかも知れませんが、あまりできていませんね。本当は好きなんですけどね。大好きなんですけどね。お酒。

運動はした方がいいなと思いながら、全然できていません。今後を考えるとしておくべきと思いながらも、今は自分の会社に時間を使う方が有意義ではないかと考えています。「もう少し会社に余裕ができたら」と思っていて、年々良くはなっているのでもう少しですかね。

もう結構長い間恋もしていなければ恋人もいませんが、それなりに楽しくやれています*1。現実問題として魅力的な異性と知り合っても、なかなかそれを赤裸々に表に出しづらいと思います。40越えた頭のハゲかけたオッサンから好意を寄せられて嬉しいと思う人はそうそういないでしょう。元々軽いアクションが好きな方ですが、最近ではそういうことは適度に抑制していて極端に表には出さないように振舞っています。婚活的なものをしようともあまり思っていなくて、いわゆるスペックで相手を探そうとも思っていませんし、スペックで判断されるのも嫌なんですよね。

先に書いたように30歳位までだと夜遊びをよくしていて、そういう場所で知り合うのは結構好きですが、お酒控えるようになってからは減ってしまいました。「飲み歩くよりも『別のこと』に時間を費やしたい」と思い始めてからは余計ですね。『別のこと』はこの後の話に続きます。

...とは言え、たま〜に「こういう時に誘える人いたら良いな」と思う瞬間はあったりもするんですけどね。

夢中になれるものの存在

過去から今にかけて夢中になれるものは下記でしょうか。

  • プログラミング
  • 人を育てること
  • 理想の会社

プログラミングは僕が最も良質なフロー状態に入れる行為なので、成長と幸福感を生んでくれるものです。35歳で定年などせず、今でも新しい言語を学び、欲しいサービスのコードも書いて、レビューもしています。20代の頃にはここまで夢中になれると思っていなかったのですが、もうかれこれ20年以上も付き合っている最高の仕事であり、最高の趣味です。没頭していると孤独など感じている暇は無いので、それだけで充分僕の人生を豊かにしてくれています。

人を育てることについては先に書いたような話ですね。巣立った人たちが活躍するのは大きな喜びです。

ここ数年はこれらに加えて自分の理想とする会社を作りたいと思って日夜励んでいます。若かった頃の僕が「ぜひ入社したい!」と門を叩いてくれるような会社を作るのが目標の一つです。概ね成功しているとは思っていますが、まだ課題はあるので今後も精進していきたいです。今の事業も「苦労してプログラマーとして成長してきた自分が欲しかった存在を自分で生み出したい」と思って続けています。サークルアラウンドが過去の自分のような人を救ってくれるようになって欲しいです。

こんなことを続けていると孤独を認識する暇も無いようです。

未来に夢見ているものの存在

僕は死ぬまでに実現したいこととして「島を買う」ということを決めています。ただこれは「島を買うための大金儲けをしたい」という意味ではありません。根源は以前会社のブログに書いた下記ですね。不幸な未来予測を覆せる自分になりたいんですよ。自分の思う幸福を守るために。

circlearound.co.jp

島で何がしたいかと言えば、実験や研究です。例えば下記でやっているような農業の自動化の研究などはその一環です。うまく自動化できれば極小の労力で死なない程度の食べ物が手に入ったりすると考えています。

blog.farmbot.jp

実は島でなくとも良いというのはわかると思うのですが、象徴として「島」という言葉が良いなと思っていて、こういう話をした時に「何かやろうぜ」と思ってくれるような人と一緒に活動できる事が楽しみの一つでもあると思っています。

「諦めてはいない。だけど覚悟はしている。」という心持ち

ここまでつらつら書いてきましたが、おそらく僕は「より多くの楽しみを手に入れる事で孤独をあまり感じていない」という結果になっていると思います。ただ、これが10年先、20年先にどうなるのかはよくわかりません。本当は家庭を持つようなこともあった方が良いのかも知れません。少なくとも両親はとても喜ぶでしょう。

どこかのタイミングで自分と一緒に歩んでくれる人が現れることを諦めてはいません。そういう人がいたら今よりももっと楽しくなるような気がしますしね。ただ、それを楽観していられるような状況でも無いと認識しているので「ずっとこのままでも大丈夫なように覚悟はしている」というのが今の心境でしょうか。今までに別の道を選べる瞬間もあったけれど選ばなかったのは自分自身なのだから、その事についてはキチッと受け止めていく気持ちであったりします。

そのおかげで気持ちとしては結構安定している、というところでしょうか。

おしまいに

たまにはこういう吐露するエントリーも良いかと。ちょっと書きすぎた感あるので、怖くなったら消すかもです。

*1:生々しい話は割愛します

システム開発のチームでの作法について

f:id:ms2sato:20180830100122j:plain

はじめに

あるあるだよなーと思うことで。コード書けることと、チーム内での立ち居振る舞いが両立している人はかなり少ないんですよね。片方ずつは努力でどうにかできたとしても二つは別々の切り口なんですよね。かたや「一人でも」を重んじていて、かたや「メンバーにとって」を重んじているので。下記の派生エントリの一つでもあります。

ms2sato.circlearound.co.jp

質問すること

私個人の話を書いておくと、個人の開発時代が長かったのと、立場的に自分が牽引する側に居ることの方が多かったのもあり、起業してから「既にかなりの開発が進んでいて、何かしらの文化が構成されている開発チーム」に関係することが増えました。私もそこで結構うまくできなかったりしたこともあって、辛かったなぁ...みたいなことを思い出しながら書いてみます。

当時関わった外部のチームの方々が暖かく対応してくれて良かったです。今でも新しくプロジェクトに関わりはじめる時はドキドキします。

上手に質問するのは難しいです!

特に「なにをいつ聞いてよいか(むしろ聞かなければいけないか)」の呼吸を掴むこと、ですかね。

技術もまだまだ発展途上でプロジェクトに参加した時、わからないことは多数ですし、むしろわからないことだらけだと思うんですよ。でもそれを片っ端からメンバーに聞いてまわったらそれは良い顔されないですよね。「そんなん自力でグーグルで調べてや」って言われてしまいます。

逆に、聞かずにどうにかしようとしてずっと調べ続けていると「なんで聞かないの?聞かないと無理でしょ?」と言われてしまったりします。なんでや!自力で調べろって言ったのはあんたやろ!

あるあるかと思うのですが、整理すると下記3点くらいでやるべき行動が変わるんですよ。

  • 誰かに聞いて良いこと
  • 聞かずに一人で調べるべきこと、考えるべきこと
  • タイミング

誰かに聞いて良いこと

  1. 文書化されていないか、文書が示されていないこと。
    • それがわからなければ最初に聞くのは「xxについてどこかに書いてありますか?読みたいです。」的なこと
  2. そのプロジェクトでしかわからないこと
    • サービスの内容や仕様
    • 文化っぽいこと(タグの付け方、WIPの出し方、レビュアーのアサインの仕方、ブランチの名前付け)
      • ただし、観察すれば類推できることも多いので、ここで先に観察してから仮説を立ててから「確認として」聞けると良いかと。
    • 不自然な実装の経緯*1
  3. 今やるべきことやゴール
    • これがわからないと何もできないはず。明瞭になっていなければ確認しないと進められないはず。
    • 「それを明瞭にさせるために少し進めるのがゴール」というケースもあるので、難しいですよね。
    • ある程度進むまではあまり大きな裁量は無いはずなので、目指すべき直近のゴールについてわからなければ、誰かに聞かないといけない。

(できれば)聞かずに一人で調べるべきこと、考えるべきこと

  • 検索すれば出てくるような一般的な技術のこと
  • コードを読めばわかること(程度はありますが)
  • エラーに対応する方法
  • ツールの使い方

タイミング

これが一番難しいような気がするのですが、上記の条件は状況によって変わっていく場合があります。「今やっていることのゴールがいつまでか」ということに影響を受けるんですよ。時間に余裕があるなら調べる時間を取っても良いでしょうが、時間が無い時には聞いてわかることを聞いて、仕事を終えに行くのも大事だったりします。

初学者の方の場合には、ほとんどの仕事にバッファが見積もられているはずなので、上記のようなことになっても「聞かずに」と言われる可能性はあります。そのあたりの話はこの次の章で書きます。

質問の前にするべきこと(実は質問自体よりも大事!)

いきなり質問する前に、こんなことをしたりすると良いということを書いてみようかと。

「今、時間がかかっている、もしくは時間がかかりそう」と先に伝えること

これが結構大事な気がしています。時間がかかかる予測ができたタイミングで報告や相談をしてみて、先輩などに「その時間をかけるべきか」の判断を仰ぐというものです。「自力解決をすべきかどうか」という判断は自分自身には出来ないケースも多いので、まだよくわかっていないうちは「こいつは手強いぞ」と感じたなら軽く相談するのは良いと思います。

分報を導入しているチームなどであれば「いまxxxに対応してて、苦戦中」などと書いてみるのも良いですよね。

大切なのは「めーーーーーっちゃ時間かけちゃいました。まだできません。わかりません(><)。」という状況になるのを避けることです。この時に既に報告や相談をしているなら、その時間は自分の独断で進めたものでは無いので一方的に責められることは無いでしょう。

## 質問したい内容の整理

何か質問するにつけてもその内容が相手にとって意味不明なことが多いと「こいつ、なんか言ってるけどわけわからん」と思われてしまいますよね。積み重なるとコミュニケーション自体が結構やりづらくなります。少なくとも以下のようなことを整理してみると良いと思います。

  • やりたかったこと
    • 目的とか、前提とか、今実現したかったことを改めて整理
  • 起きている事実
    • どんなエラーが起きているか
    • 画面表示やログ
    • やりたかったことと、事実のギャップがわかる情報
  • 解消するためにした行動
    • どんなワードで検索したか
    • コードをどのように変えてみたか
  • 考えていること
    • うまくいかない理由について足りない知識からでも考えること
    • 打破するためには何が必要か、推察すること

ちなみに、こういうことをしている時に「あ、あれまだ試してない」と気づいて解決できることも多いので、騙されたと思ってまずはやってみると良いと思います。

ツール

この辺は今はコードについてはgitとGitHubの扱いがわかっていれば良いと思うのでこのブログでは論じません。聞いてくれれば私の考えは答えられるけれど巷にいっぱいある情報ですよね。ドキュメントもSaaS型のWEBサービス使っているところが多いと思うのでそれぞれ調べれば良いかと。

どうやって経験するの?

以下は、チーム開発を練習するための場所や方法について考えてみます。

野良プロジェクト立ち上げ型

ただ誰かと集まってやってみる形ですね。以下のような利点欠点があるでしょうか。

  • 低コストで実現可能。
  • 気心の知れた人たちでやれば楽しい。

一方で以下はネガティブな内容ですね。

  • 仲間を選ばないと頓挫してしまう。
  • 全て独学で進むことで、勝手に大きな勘違いをしたり、一般的ではない文化を作ってしまう可能性がある。

就業型

「これができれば苦労しない」という方は多いのかも知れませんが、世の中には稀有な環境もありますのでそういう場所をうまく探せるのであれば良いかと思います。

[PR] チームトレやってます。

弊社ではチーム開発のトレーニングやっていますよ。弊社の社内で実際に利用しているサービスの開発を通して、チームでの作法を学習していただきます。詳しくは下記をご覧くださいませー。*2

就業目指している方も、チーム経験あると強いのでご検討いかがでしょうか。十分な実力が発揮できそうなら、こちらでの成果を弊社からも紹介の材料としています。

circlearound.co.jp

*1:あまり最初の頃はツッコミ過ぎると気を悪くする先輩もいると思うので程々にどうぞ。

*2:最終的にいつもPRに結びつけるのは仕様です

あまりに熱い「弊社トレーニング利用者の声」に応えたくキーボード叩きます。

f:id:ms2sato:20180822215141j:plain

はじめに

travy.hatenablog.com

こんなに熱いメッセージをしていただけたら、黙ってなどいられようか(いや、黙っていられない)。

もう、大筋は本当に尤もだという内容で、弊社のトレーニングについてとても理解していただいていると思います。 今回トレーニングした弊社側からの目線や補足も交えてお伝えできれば幸いです。

トレーニングの流れ、概要

面談

最初の経緯はちょっと省略しますが、面談の際に下記のようなことは伺えました。

  • WEBサービスを作れるエンジニアとしての就職を考えられている。
  • 既に独学でそこそこいろいろ試されている。調べて問題解決できそう。
  • モノを作るのは好き

人に頼る前に事前になにかやってみて、より高みを目指そうとしたり、さらに速度を上げたい人は総じて良いマインドなので、大歓迎だと思いました。

RubyClimbing で腕試し

あとは実際に作っているものや基本部分が本当に備わっているかはお互い不安であったりもしたので、まずは下記で腕試しを勧めました。面談から伺える実力が本物であれば無料期間の二週間で難なくこなしていくだろうから、お互いにとって無駄が少ないと判断してのことです。

circlearound.co.jp

ある程度の実力が備わっていないうちに個別トレーニングを受けられると、結果的に生かせないというケースがあるので、このステップは弊社にとっても、受講する方にとっても良い試金石となるステップだと思っています。記事にもありましたが、Rubyの基礎の基礎(プログラミングの超基礎)を確認し、SinatraでWEB開発の基礎概念を固めてから、Railsを学ぶような構成になっています。

実際にはサクサクとこなされてしまい、担当の小笠原も「よくデキる人だ」という評価をしていたので安心がありました。

個別トレーニング でより良い作法を学ぶ

このあと私がバトンタッチして個別トレーニングを担当させていただきました。過去に書いたコードを事前に見せていただいたりして「『とにかく力技でどうにかしよう』という条件であればどうにか動くものは作れる」と判断していたので、中心になっているのは「より良いコード」であったり「実際の開発現場でも見慣れている形のコード」のような、コードのスタイルを学ぶことでした。Railsであったので、例えば以下のようなことです。

  • アソシエーションを適切に使う
  • enumを使う
  • 画像をアップロードして保存するなどのような基本的な画面構成に慣れる
  • よくあるgemの操作に慣れる

題材としては先のブログでもありましたが元々書いていたものを1から作り直すという経験を通じて行いました。実は「良いものとの差分を理解すること」は実力アップの一つの条件でもあるので、あえてこういう方法を提案することがあります。終わってからその差に気づいて貰えたのは私としても「してやったり」感がありますね。

基本的にはGitHub-Flowのような形でIssue、Pull Request レビュー、マージの流れで進みます。最初はIssueをこちらが出してやってもらうようなことが多いですが、慣れてくれば自身でIssueを出して開発を進めてもらい、こちらはレビューだけするような流れになっていきます。

ちなみにインデントとかスペースとかは慣れると自然にできるようになりますし、ツールでも補えることですが「どういうものが読みやすいのか」を学ぶのには良いと思っています。

チームトレーニングで実践

個別トレーニングはあくまでも自分のコードだけの世界です。つまり「自分にわかるコードしか基本的には存在しない世界」だということですね。 実際の開発現場に入って驚かれた方もいると思いますが、自分が書いたものではないコードを読み解くのは結構(いやかなり)大変なことだということです。このトレーニングの題材のコードはそれでもなるべくコンパクトに作られたものですが、練習になるいくつかのポイントを持っていて「基礎概念を理解していないとソコソコ苦労する」コードになっています。

最初の方でコードを読む際のコツやどこから読むと全体が掴みやすいかなどのポイントを共有しました。この時は同時に二人の受講生の方がチームだったので、確か問答しつつやっていた気がします。コードを読むのが苦では無い様子だったのでキャッチアップが早かったですね。

一緒に誰かが開発しているということは、gitでもコンフリクトが起こりますし、それを解消しながら進まなければいけないという事になります。個人では起こらないことを体験しながら身につけていっていただきました。 また、Issueだけで内容を掴みきれないようなものをあえてチャレンジしてもらったりすることで、必要なコミュニケーションや考え方の勘所を掴んでもらえたはずです。

考察

私が今回一緒にやらせていただいて改めて思ったのは「深く考える訓練」をどこかでできている人はやはり理解や成長の速度が違うということです。かなり順調に伸びていかれていたのはこの点が大きな理由だと思っています。また、考えが深いことは適切に行動できる可能性が上がりますし、振り返りを行って改善することもできるのでしょう。

いわゆる技術という括りにハマらない根底の基礎スキルを伸ばすことは全体的に加速させるのでとても重要であるし、私達もとても大事にしている考え方です。今回のケースは本人が元々備えている素養にもかなりうまくハマったケースであると言えると思います。

「典型的な型にはまった内容を学校教育のように体験したい」というだけの場合には弊社の個別トレーニングはあまり適していないと考えていて、廉価版のRubyClimbingのようなサービスを検討していただいています。

個別のトレーニングであることもあり、いわゆる「同じ目標に向かう仲間」的なものができたりは殆どしません。しかし、目的が自己研鑽であり、昨今オンライン/オフラインでコミュニティを探すことができるようになり始めていることからも*1、それは大きな価値では無いと思います。たとえ一人でも、それでも学習を続けられる基質こそがずっと支えてくれるマインドだと私は考えています。

おしまいに

週末の25日にトレーニングをまるごと説明する会を開くので、ぜひ聞きに来てくださーい。

techdrive.connpass.com

*1:例えば TechBaton など

初学者プログラマーの成長の過程の残し方

f:id:ms2sato:20180811112904j:plain

はじめに

ms2sato.circlearound.co.jp

またこの記事の続き的に繋げます。前回は実力が示せるポートフォリオについて書きました。

ms2sato.circlearound.co.jp

次は情報のアウトプットについてです。

元の記事では「Qiita」でも「ブログでも」と書いてたら、こんな風にツッコミいただきまして。これは間違いないなと。

なので、この辺りで「私が何を見たかったのか」を考えたいと思いました。例のごとく「そんなんじゃ足りねぇ!xxを残さずしてどうする!」とかツッコまれたいです。

本題

見たいのは「課題発生」「考察」「解決」のサイクル

「成長の過程」と一言になっていることを整理しておくといいと思いました。それは結果、下記のようになりました。

  1. 「xxをやろう」という動機
    • ユーザー一覧画面を作ってみるぞ!
  2. 「うわー、これ困った」という課題の発生
    • どうしても、ユーザーの名前が表示できないんだぜ(><)
  3. 課題から事実をブレークダウンして書いている(状況をこちらが想像できる)
    • コンソールにはこんな表示が...(内容ベタッと貼っていいです)
    • こんなエラーが出ていて...(エラーとかベタッと貼っていいです)
    • データの内容をDBで見て見たら...
  4. 考察 している
    • もしかして、URL間違ってる? bin/rake routes いや、合ってた。
    • エラーの英語は「....」という意味らしいから...、user変数にxxしてて...(独り言っぽいけど、いいんです)
  5. 解決へのきっかけ&解決
    • エラー内容をGoogleしたらStackOverFlowにヒットしたんすよ!これで勝つる!
    • 実はDBにデータが入ってなかったとです。悪いのは入力画面みたい。

なんとなく、「起承転結」みたいなことかなと思いました。そして、この中でも重視しているのが「考察からの解決」かと。もちろん瞬殺できていることは考察も何も無いので良いのですが、悩んだ時にはちゃんとそれを書いていてくれると良いなと思います。

綺麗にまとめる必要はありません!

プライドが高い人はすぐに「ちゃんと問題解決までまとまってないなら書きません」とか言い出しちゃうのと、Qiitaだと課題解決までしておかないと書きにくい空気感があるんですよね*1

その意味で @hisaju01 さんが言っていたブログの方がいいというのは私も同意します。

過去書いていた私の開発ブログでは「課題発生の日」があり、「調査ばかりしている日」があり、数日して「過程と解決」が書かれる、というようなことがよくありました。これで良いと思うんですよ。日々やっていることをメモしているだけで構わないと思います。

大事なのは「あなたに会ったことはないけれど、日々努力していることはブログで知っていて、どういう解決をできてたかがわかる」という事実では無いかと思います。

GitHubの草はわかりやすいですが、神経質にならなくても良いかも。

毎日pushすること自体には特に意味がないと思うので(調査ばっかりしててpushできない日とか全然あると思います)、そこは最初は無理せずで良いかと。毎日開発ブログ書いてみる、くらいで十分かなと思います。

おしまいに

採用ちゃんと考えているところであれば、ブログなどURLで伝えると読んでくれるので出しておくとお得ですよ、ということで。最近だとTwitterで名前やアイコンが知られると良いということもありますが、ストックされるブログのような情報もとても有用ですよ。という感じでしょうか。参考にしてください。

*1:元々はそういうサービスではなかったはずなのですが「ノウハウの集合」というイメージが強いので最後解決してないと読んだ人のUXがかなり悪くなりそう

「ITエンジニアは人手不足だから、スキルが無くても問題ない」の嘘

f:id:ms2sato:20180813095119j:plain

はじめに

これと、前に私の書いたエントリについてたブコメのこれ

「未経験から技術を学んで就職するには」で一つのアプローチを整理してみました - 島までは遠い

まず、みずほに潜り込みます / そもそも業界内で人がどの位不足してるかを調べて欲しいが、結構難しいんだよね。不足してるなら何とかなるし、余ってたら無理だし。

2018/08/08 13:55
b.hatena.ne.jp

拝見してたらなんとなく出力したくなったので書きます。先のツイートにRTされている内容も様々な意見があって興味深いです。

プログラマーの仕事、そんなに簡単に見えますか?

エンジニアやプログラマーは人手不足!スキルなくても全然大丈夫

これは、ありえませんから。補足します。

エンジニアやプログラマーは人手不足!(もしも、あなたが仕事の質や直近の成長を捨てる覚悟があるのなら)スキルなくても全然大丈夫

じゃないでしょうか。もしも「スキルなくても全然大丈夫」と言っている職場があるなら、それは「その程度の仕事しかお願いする予定はないし、それでペイする事業を営んでいる」ということで、おそらくあなたが想像するような「自力で問題解決をコードでしているカッコイイプログラマー」では無い筈ですよ。最初から「問題解決をコードでできる」ということを期待されていないということです。

自力で問題解決するにはスキルが必要なんですよ。「スキルなくても大丈夫」なわけがないです。簡単だと思わないでください。

もちろん何にでも例外はありますから、稀有な環境や経営者の下、そういうことができる場合ももちろんあると思います。例えばしっかりとした育成の文化を持っていて、先輩エンジニアが鍛えてくれたりするのであればそういう可能性もあるでしょう。

そんなのは本当にごくごく一部でしかないと思って欲しいです。私の周囲の会社でもゼロレベルから受け入れて伸ばしてくれるような会社なんて殆ど無いです。それができるなら、今プログラミングの学習を補佐する業界自体が成り立たないと思いませんか?(逆に言うとこれも異常ということは後述します)。

割り切り

世の中には様々な環境で仕事している方がいらっしゃると思うので、例えば以下のような考え方であえて「誰でも」となっているところに行く人はいると思います。こういう割り切り判断も時には必要でしょう(むしろそれが救済になっているとも考えます)。ただし、先を考えることは必要だと個人的には思います。

  • 現職の環境があまりにもひどく、退避場所としてでも良いので別の職場を求めている(第一目標が現職からの退避だから)
  • 他業種からIT系の業種への転向を考えているが、例えば年齢などでかなりの不利な環境を持っている為、肩書きだけでも移行し、別途スキルアップして別の職場を目指す為(あくまでステップの一つであり、現場で学ばせてくれないことは前提で考えているから)

おそらく多くの人はこういう事に当てはまらないのではないかと考えます。

どうしてこうなった?という推察

経済などの専門家ではないですが、私や私の周囲・クライアントなどを見ていて思うことを記してみます。

企業側の事情

例えばこういう意見が出ていました。とても真っ当です。私もそう思います。ですがそうやってある程度人を育てていこうという会社に対して現実に多く起こることは

「やっと育ってこれからだと思った頃に社員は別の会社へ出て行く」

なんですね。経営としては最初は完全に赤字だったと思いますし、これからはその人が別の新しい人を育てながら次のステップに入って欲しいと思っていたりするんです。でも、その前に出て行ってしまうことも多いらしい*1です。

個人の行動としては合理的であるし、その結果社会全体では給与が上がる傾向を作れるので良いとも思えます。とは言え最初に雇った会社からすると大問題なわけです。ある程度長い間一緒に歩んでくれるなら良いけれども、これから返していってもらえそうという段階でいなくなってしまうのであれば、経営としてはかなり辛い事になります。投資が回収できないんです。

そうなると会社が「『経験の足らない人を雇って育て上げる』という事に対して臆病になる」と推察できるのでは無いでしょうか。

過去の技術者の怠慢

これは私のようなロートル世代が引きずってきた問題なので、自分自身も当事者であるということも含めた上で記しますが、良くも悪くも「職人文化」「背中で覚えろ」のような考えが横行し続けていて、そもそも人を育てる文化が根付いていないと思います。少なくとも私が過去見てきた会社はそういう場所が大半でした。個人的には抵抗を試みたりしましたが、こういうことができたのはたまたまそれが通用する場所であった為だと思っています。

人を育てない文化は特に今始まったことでもなく、脈々と受け継がれていると言ってもいいような気がします。それではいけないのですけれども。

私の抵抗の話。 ms2sato.circlearound.co.jp

似たような事はこっちに頑張って書いています。

ms2sato.circlearound.co.jp

ブートキャンプやスクールという形式の流行り

というこれまでの流れを考えると、外部でなにか教育するという事が浮かび上がると思います。 海外では全部JavaScriptを用いて3ヶ月でムリクリプログラマーにして現場に送り込む、というようなブートキャンプ形式が一時流行ったのと、日本でそれに乗っかってスタートアップで似たようなことを「スクール」という名目で始めたのが流れでしょうか。

そして、海外でもこういう流れになっていました(2年前の記事)。

jp.techcrunch.com

多くのスクールが、100%近い卒業率と就職率を主張しているが、しかしその主張にはほとんど証拠がなく、スクールの経営実態も多くが開示されていない。

事実開示すべきだという話や、極小のケースを誇張する話が出ています。

スクールの多くが、ある一人の卒業生がY Combinatorに行ったとか、ほんの数名がGoogleに雇用されたとか、そんな一度限りの成果をマーケティングに利用している

今、日本は上記のような海外と同じような流れになっていると思います。おそらく様々なスクールはベンチマークし合った結果、誇大広告と情報商材的な売り方がもっとも売上が上がると考えたのでしょう。

お前のところはどうなんだよ

とりあえず私が誇大広告嫌いなので「xxヶ月で月給xx万円稼げる」とか出したこと無いですね。というか、そういう保証ができないスキルであり、そういう仕事だと私がよく知っているので、保証する事が胡散臭く思えるんです*2。三年半続けていますが、これまで完全初心者よりも少し経験がある人の引き合いの方が当初多かったのもあり、就活系はこれからでしょうか。

困ったのは以前よりもアフィリエイト記事っぽいのがGoogleの検索結果に上がってきて、元々マーケティング下手なうちは前にも増して目立たなくなったことですね。候補に全く挙げてもらえないっぽいです。あはは(笑い事じゃ無い)。

プログラミング トレーニング は流石に強いですが プログラミング 個別指導とかではどこ行った?って感じです。

おしまいに

本当の理想は「会社が組織の中で育てられるから、スキルがなくても問題ない」なんですけど、現実はそうなっていないんですよね。これって私は自分がやっている事業を否定しているわけですが、最終的には弊社がやっているプログラマーのトレーニングの意義が無くなる社会が真っ当だと思っています。

「育て方を、教える」も事業にしたかったりするのですが、それができるのは今の社員メンバーでは無かったりするので、経営としては単純に経営者の現場稼働を増やすだけになってしまう形は作りにくいんですよ。うちがもう少し大きくなって今のメンバーが育ったらできるのかもしれません。

*1:「らしい」と書いているのは、他人の会社の事なので「育ったから出て行く」というシンプルな理由と言い切れないからです。それは副次的な理由で「そもそも長く居続ける理由が無いような会社だった」なのかもしれません。

*2:面接などで聞かれた時に私の返答があまり歯切れが良く無いことを体験している人はいると思います。言い切るの難しいです

実力を示せるポートフォリオのWEBサービスのコードの作り方

f:id:ms2sato:20180809142937j:plain

はじめに

ms2sato.circlearound.co.jp

こんなのを先日書いたので、その続き的なエントリーです。

「『作ったものがある(最低条件)』とか言っても、何作れば良いんですか?」 的な話です。ゴールとして「出来上がった動くもののソースコードを技術者に見てもらう」切り口で書きます。 これはあくまで「私の場合」なので、異論ある人から「こういうところも見ているぞ!」みたいなツッコミとか超欲しいです。

どういうものを作れば実力が測れるのか

以下、私がRails中心に色々やっている(やらざるを得ない)為に、チョイチョイRailsぽい話になってしまったりしますが、お許しください。個人的には言語とかプラットフォームとかに関して中立な考え方です。

レベルで示していますが、数字が上がると難易度が上がるというよりも「下の方をちゃんとこなしていれば上の方も見ていく」ような感じになる気がします。

【レベル0】 とりあえず見る価値を作る

Scaffoldしただけでできるような「単純すぎるものではない」こと

色々と流派はあるかもしれませんが、単純なCRUD*1を作るのに、多くの人は作業を効率化させる為にScaffoldを利用すると思います。Railsならこれで何が起こるかとか、カスタマイズするのにどうしたら良いかある程度把握しているべきだと思います。

シンプルな掲示板を作ろうとしたりすると、ほぼScaffoldで終わってしまうようなケースがあり「あれ?これってあなたはどこをプログラミングしたの?」というようなことになりかねません。レビューする側も、コマンドいくつか叩いただけのコードでは判断できません。当然ですよね。

ちなみに、このレベルのコードでViewを綺麗に飾るだけしているケースはよくある気がします。もしもHTMLやCSSのスキルやデザインでアピールしたいなら、これもありかもしれません。ですがシステムを扱うプログラマーになりたいのであれば、これでは実力が測れないのです。

というわけで、コードのどこか(適切な場所はありますが、この後に示すようにその場所でなくても構わない場合があります)に頭を使うロジックを入れて置いてください。例えば「どこ頑張ったの?」と聞かれた時に「ここめっちゃ頑張りました!」と言えるようなのがあると良いです。

データベースを利用していること

稀に外部APIを呼び出すだけのものとかがありますが、これはDBの扱いやSQLの理解があるかどうかが見れないです。大抵のシステム開発ではMySQLやPostgreSQLなどのデータベースを扱ってシステムを作るので、この知識があるのかないのか見えないと、やりにくいです。

Scaffoldだと基本のコードがいきなり埋まってしまうので、それにプラスしている場所があると良いでしょう。例えば検索機能があって、入れた情報を絞り込んで出力できたり、LIKEの曖昧検索できたりするなどすると、少しは片鱗が見えます。

またテーブルのリレーションとして

  • 1対多
  • 多対多

などの基本的な情報のまとめかたの方法があります。これらは入れましょう。特に多対多は最初の頃よくわからないこともあるかと思いますが、何か作ればすぐに必要になることなので、やれる方が良いです。

RailsならActiveRecordを使ってアソシエーションを利用するようなコードになるはずで、こういうところのコードの扱いでも一定の実力を測ることができます。

ライブラリは利用しても良いが、骨格は自分でコードを書いていること

OSSで出ているRailsのサービスに何個か機能追加したようなものですと、そのOSSの扱い方を理解しただけなのか、Railsについての理解があるのかがわからず、現場に入りやすいかの判断がしにくい場合があります。あくまでサービスをゼロから作れるかどうかを見たいというような目的感があるので、できればrails new からスタートして作っていて欲しいです。

【レベル1】力技でもやりたい処理を自分で考えて書いているか

「美しいコードでなければ見せる価値はない」と思ってしまう人がいるかもしれませんが、それは誤りです。美しさというのは後で磨くこともできることなので、最低限で考えると美しいかどうかではありません。

大事なのは「考えてコードを書いているのか」とか「困った時に工夫できる機転がきくのか」というようなことです。

なので私の場合「全然勉強の余地はあるけれど、めちゃくちゃ考えたんだろうな」という事が伝わる際には一定の評価をします。ただし「どう考えてそうなったのか」については結構聞き込むはずです。ポイントとしては以下かな?と考えています。

  • 少なくともどこかのコピペコードの筈がない(コピペだとそれっぽいコードが多くなるので「メチャメチャ頑張って工夫」になりにくい)。
  • そのコードについて質問した時に「どう考えたのか」が論理的であるかどうか。

例えばですが「MVCとかよくわかってないです」と言って見せてくれた方のコードでViewにロジックべったりだったことがあります。ただ、聞いてみると彼はシッカリと考えていて、単純にロジックの適切な置き場所がよくわかっていないのだとわかりました。こういうケースは評価できると思います*2

【レベル2】作法に従っているか

レベル1を超えているということは、とりあえず動作を実現した動くコードがあるということになります。ただ、それだとよくありますし「家で独学修行を一年続けました」とかでも到達できる可能性は高いです(私も経験していて、とても価値があることですが自分のやり方に染まり過ぎているかもしれません)。

例えば以下のようなところとかでしょうか。

  • MVCに従うことを知っている。ロジックをモデルへ集めている。
  • アソシエーションを適切に使っている
  • enumやscopeを理解して利用している
  • routesをresources中心で書けている、アクションの追加などもこの作法の中でやっている(collection、member)
  • バリデーションでの失敗の処理がおざなりになっていないか(とりあえず動かそうとすると放置しがち)
  • (もう少し後でもいいか?)N+1 問題への対応

【レベル2】よく使われる外部ライブラリを使っているか

ちょっと調べると出てくるような外部ライブラリを利用できていると、よく調べていることは伝わります。Railsだとこの辺でしょうか。

  • Devise(嫌がる人もいますが、導入されているプロジェクトは多いので知っておく方がいいと思っています)
  • Carrierwave(もう使われなくなるかも)
  • Kaminari

【レベル2】自動テストを書いているか

まず、書く意志があって試みてて欲しいのはあります。RailsではRspecがほとんど使われている様子なので、Rspecで書いてください。

  • モデル
  • コントローラー or リクエスト

くらいで書いてみてて欲しい。最低モデルについて書いていてくれるとありがたい(その為にもモデルにロジックが乗る設計になっていないと難しいですが)。 「素晴らしいテスト」という考え方だと色々と難しくなってしまうと思うので、最初のうちは「意味があると思うものを書きました」くらいでも良いかも。

【レベル3】よくある仕様・画面に対応できているか

現場に入ると最初の頃ちょっと戸惑う「あるある」な仕様があります。これに適切に対応できているかですね。例えば以下のような構成の画面とか。

  • 本の紹介と他人からのレビューコメントが並ぶ画面が適切に作れているか
    • バリデーションしなければどうにかやっていることはあっても、そのあたり含めると怪しくなってくる人は結構いるようです。
  • 本の紹介のために複数の書籍のサムネイルを一つの編集画面で一緒に更新させる。サムネイルの最大数を増やすのはDBの変更をしなくてもできる。
    • これもバリデーション含めると、エラーになると入れたサムネイルが無くなったりしてしまうなどあるので、そのあたりのケア。

この項目は「一度ぶち当たって痛い目を見ると覚える」ような部分でもあるのでプラスアルファだと考えることもありますが、こういうのをシッカリ対応できているなら安心だなとも思います。成長を含めて評価するか、今のその人のできることで評価するかの違いです。

【レベル3】バッチ処理が入っている

普通に教本などをやっていてもあまり出てこないのですが、実際の開発では rails runner や Rakeタスク を使ったcron呼び出しのバッチ処理などが発生することが多いです。また、稼働中のサービスに対してDBの情報を更新かけたりもしたりするので、こういったコマンドでサービスに外から働きかける経験があると、本格的な内容理解がありそうだなと感じたりします。

ロジックの入りやすい仕様について

おそらく「ロジック入るようなのはどういうものか?」という疑問が沸いている人がいそうなので、ちょっと書いておきます。

  • ユーザーが複数の種類いて、それぞれ別の権限を持っている(管理者・コンテンツ作成者・見るだけの人など)
    • 権限判断をすべきところが出てくるので、そこで考えて分岐する必要性などが出てきます。よく実開発で必要になる考え方です。
  • 何かの集計を行なっている
    • 例えば「いいね数」のような概念があって、いいね数の数で検索結果を出したりするなど。複合的に検索できると尚良い。
  • 条件付きで見えるような画面がある
    • 例えば他で設定されたユーザーごとのパスワードを入れて、同じパスワードを入れたら見ることができる、など

今だとクラウドファンディングのサービス作ろうとしたりすると、いい感じに色々な仕様が乗ってきそうな気がしますね。ただ、実力がそこに伴っていないと意味がないので、そうでなければ無理くり目指さずにブログサービスを作るとか、掲示板でもちょっと変わったものを目指すとかでも良いのではないでしょうか。

おしまいに

これってつまり「私が実力を評価する場にいた時に見ること、あると嬉しい情報」なんです。私を攻めるならこういう感じで勝利確率が上がります(笑)

普段WEBプログラミング個別トレーニングの面談でもこうやって今の実力を測らせてもらいますし、弊社の受託で一緒に仕事をするメンバーを見る場合も大抵コード見ながら話をさせてもらいます。 circlearound.co.jp

こうやって結局自社の話に繋げるのは仕様です。もし興味わいたら、明日(8月11日)、25日にトレーニングの説明会やるので来てください。

techdrive.connpass.com techdrive.connpass.com

*1:Create, Read, Update, Delete

*2:もちろん適切なところに書けばもっと評価します