島までは遠い

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

「我慢」はし過ぎるな。麻痺するから。

はじめに

www.bengo4.com

痛ましい事件だと思いました。ここから思ったことと似たようなことをあるところで人と話していたのですが、そのことも絡めて書いておきます。

「痛みは体のサイン」

最近私がこの言葉を発したのは、プログラミングする際の姿勢の話とか、椅子の話とかだったのですが、体にも心にも同じようなことが言えるのではないかと思うのでそこから始めます。

多分何か身体に無理がかかった時に「痛み」が発生するのではないでしょうか。つまりその時は「何か気をつけないといけない!」と体が発信してくれていると考えられます。よくない姿勢であったり、体に合っていない椅子に座り続けた時などにこのサインは起こるのでしょう。

そういう時、私たちはいくつかの対応策を考えて行うことができます。たとえば

  • 基本的な姿勢を変える
  • 休憩時間を入れるようにする
  • 椅子・机など設備を変える

のようなことですよね。

我慢できる

実は痛みに関して人間は他にも対応策を持っています。「我慢」という行為です。ある程度痛みがあるにせよ「痛みに耐える」ということができる仕組みになっています。通常は一瞬や短時間なら耐えながら物事を行うと思います。

本来この「耐える」というのは「いきなり活動不能にならずに、上記のような対応策を取る時間を稼げるような『バッファ』として体が発信している」とも考えることができそうです。痛みをこらえながら病院に行くようなことを考えていただければ想像しやすいでしょうか。

我慢し過ぎ

我慢強い人、我慢できない人など、人には色々と我慢耐性の度合いがある様子に思います。通常のイメージで考えると我慢強い人の方が頼りになり、物事を達成しやすいような性質として捉えられていると思いますし、確かにそういう傾向は強いと思いますが、私は時折不安になる時があります。

我慢するにも限度があるので、本来対応策を取るべきだったのに取らずに進んでしまうと、どこかで「我慢の限界」は訪れるはずで、治るはずなのに治らない大きな傷になったりするのではないでしょうか。

身体と心

そして身体だけではなくて、心にもおなじようなことが起こると思います。最初は我慢できたことかもしれませんが、ずっと我慢し続けている間に心に大きな傷を作ってしまうことがあります。昔私が現場で一緒だった知り合いでも、そういう方がいらっしゃいます。我慢強さが仇になってしまうということではないでしょうか。

真面目だったりひたむきだったりする人が、或る日突然折れてしまうことはあると思うのです。

私の会社は真剣に仕事に取り組みたい人ばかりなこともあり、結構気を配っている「つもり」ではあります*1。勤怠がゆるくても別のところで大きなストレスを受ける可能性もありますからね。

逃げてもよい

聞いたところによると、我慢が慢性化すると「通常」がどういう状態かわからなくなってしまうらしいです。

下手するとある程度痛みを我慢していないと「ちゃんとやっていないのでは無いかと不安になる」とか「刺激が足らない」とか思うそうです。個人的には過度の我慢は避けて、痛みとして感じられるうちにある程度距離を置いていくのは必要だと思うし、やって良いと思います。

また、わからなくなった時に誰でも良いので第三者に相談するのは良いことでしょう。会社のことを会社に全然関係ない人に相談したり、公的な機関に頼ってみたり、なんでもいいから「その環境の外に」いる人の客観的な意見を聞いてみるのは良さそうです。

ただ、第三者で適切な意見を言えるかと言うと、それは結構難しいことなのでなかなか対応に苦慮するところでもありますね。私も実際に適切な対応が取れる自信がありません。相手が他社ならまず介入は難しい筈です。

我慢しないのは怠け者?

「我慢しないことが単なる怠け者とどう違うのか」と聞かれれば「従業員においては決められた時間内を真剣にやってくれていれば(我慢などしなくても)怠けてないのでは無いか?」というのが今の私の見解です*2。ただ、仕事って別に怠けててもいいんですよ。どんなに気持ちが入っていなくても望まれた成果さえ出してくれれば会社というチームは存続できるからです。

ただし、会社にどんなメンバーを望むのかは文化によって違います。例えば弊社の場合には怠け者は居心地悪いだろうから来ない方が幸せでしょうね。

おしまいに

一定の我慢が必要なことはもちろんありますが、過度な我慢を長期的に続けるのは避けて欲しいなという意見でした。もしもそんな状況になりかけている人がいたら心が麻痺してしまう前に距離を置いて欲しいものです。

皆さんの心と身体の健康を祈りつつこのエントリを終わります。

f:id:ms2sato:20181018190807j:plain

*1:こういうことは、こちらがそのつもりでも相手にはそうで無い場合があると思うので、あくまで「つもり」止まりです。多分大丈夫だろうと思ってやっています

*2:経営者はよくわかりません。やりたくてやっている事業だし、それに関して怠ける怠けないという基準がそもそもうまく当てはまらない気がします

Googleが抱える問題(と、私が思っていること)

はじめに

qiita.com

からのこれ

anond.hatelabo.jp

この話自体については私は以下のような意見です。この記事は別の切り口で書いておきたいです。

問題は書き手側にあるのではなく、Googleにある

「ゴミ記事」かどうかを判定してフィルタリングするのはGoogleとそのユーザーの責務です。

他の記事でも書かれていましたが、私もこの意見には賛成です。そして、だからこそ気になっていることがあります。

私たちの仕事は検索をして適切な情報に辿り着くこともスキルの一つに数えられます。つまり検索が一般人よりも上手なはずの専門職なんだと理解しています。そういう私たちの仲間ですら「適切な情報が手に入らない」と考えているとすると、専門職ではない一般の人からすると「もはやどうやっても適切な情報にたどり着けないことがあるのではないか」という事です。

少し前に WELQ の記事に関して大きく問題になったことを思い出した人もいるのではないでしょうか。それによって改善もなされたと記憶はしています。ですが同様の問題がずっと続いている様に感じています。以下のような記事でも結果的に変わっていないというような論調で終わっていました。

seo-lpo-consultant.com

最近の他の例

medit.tech

ノーベル賞の話に関連して出てきていた記事ですが、検索ワードによっては虚偽と誤解を与えかねない情報で溢れていると指摘されています。私は対象となっているワードを検索した結果を見ましたが、正直申し上げてどれが虚偽や誤解を与えかねないのかわかりませんでした。もし当事者になってしまったら、検索の上位のものは間違い無いのだろうと思ってしまうはずです。

技術記事については私たちは一次情報へ当たることが比較的容易で、ソースコードを読んだり実際に試したりすることで虚偽は判断できます。上記の様な自分で試すこと自体が困難であったり、不可逆なことに関して玉石混交の中から選別するのは大変困難だと考えています。

同様の話は、以下のようなところにも見受けられます。

megalodon.jp

megalodon.jp

プログラミングスクールについてです。どうやら最近はアフィリエイトの記事が大量に出回ってしまった為、自身に合うプログラミングスクールを検索で探すことが大変困難になっているそうです。プログラミングのスクールは一般的に高額なので、一度試してみようというやり方で虚偽を判断することが大変難しいことの一つだと考えます。

これは想像ですが、違約金を高めに設定すれば受け始めてから良く無いと思っても、抜けられない問題があると思います。

フォークソノミーとタクソノミー

もう死語になってしまいましたが、Web2.0 時代を見てきた私にとってこの課題はフォークソノミー・タクソノミーという言葉を思い出させます。

用語解説辞典|【公式】NTTPC

ザックリ伝えると以下の様な感じでしょうか。

  • タクソノミー: Googleの検索などのように機械的に分類され、分類の結果に一般ユーザーが関与できないもの
  • フォークソノミー: はてなブックマークのように人がタグやコメントで分類し、分類の結果に一般ユーザーが関与するもの

今タクソノミー的なGoogleの検索結果があまり有益な結果を運んでこないとすれば、フォークソノミー的なアプローチを混ぜた別のあり方を模索したくなります。

私のやってみたいこと(妄想)

プログラマー向けは別のアプローチもありますが、一般向けならGoogleのSearchAPIを使って検索結果を出し、その結果をフィルタできるシステムを作ってみたいですね。たとえば以下の様なフィルタを用意します。

  • 正規表現で特定のURLやドメインを含むサイトを弾く
  • 特定のURLに対して + or - の信憑性評価ができて、多くの人がどのように捉えているかがわかる
  • ユーザーに対して特定の専門分野への特異性の重み付けをつけられる(たとえばガンに詳しい医師の方が + をつけるガン関係の記事は有用であると考えられる思います)

誰でもフィルタをつくれますが、フィルタはフォークしていくらでも複製可能かつ全て内容がオープンにされており、透明性の高いものとして機能するようにします。ソースコードもオープンで良いと思います。この仕組みは作為性が疑われると崩壊するからです。

他にも妄想はありますが妄想で埋めても微妙なのでこれくらいで。

おしまいに

Googleは毎日利用させていただいている素晴らしい検索エンジンだと思っています。ただ、それを逆手にとって自分の利する形を作っている者がいるという現状の様子です。個人的にはこういう課題は人が必死に何かをするようなことではなくて、そのシステムの改善が必要ではないかと考えます。

ちょっと時間できたら色々作ってみたいものです。

本当はこういうものをビジネスに昇華できればもっと多くの時間をつぎ込めるのでしょうが、皆にとって利益のあるものを作ろうとする時、その結果会社や個人にお金が入る形を考えると公平性が失われるのでは無いかと考えてしまうところがあります。いい手は無いものか。

f:id:ms2sato:20181011124316j:plain

燃え尽きない定年退職エントリに寄せて

はじめに

d.hatena.ne.jp

最近週一くらいで更新しているのですが、今週も色々とキャッチーな話題はあったかもしれないけれど*1、このエントリーへの言及は今しかできない気がするのでしたいなと思ってキーを叩きます。

私は著者とは2000年代のデブサミでのご縁で一回飲み会で同席したことがあるくらいです。なので特別濃厚な何かがあったりするわけではありません*2。あの頃鼻息荒かった私が42才オッサンになるのだから、当時Miracle Linuxにいらっしゃった吉岡さんが定年退職もなさいますよね。時間が経ったのだなと思います。拝読していたらMiracle Linuxにいらっしゃった時期が今の私と同じくらいの年齢だったので、あの頃とこれからに思いを巡らせるなどしてしまいました。

私の心に残ったことを何点か触れさせてください

「私たちには既にわからなくなってしまった過去のこと」を記してもらえること自体に価値を感じました。DECでの開発手法を拝読して、クールな開発手法は時代が変わってもそれ程変わらないのではないかと感じます。「デイリービルド」など、名前は聞いたことあったけれど...というものがCIとなって当たり前になっているのも再発見した気持ちでした。

ちょうど私が現場に出た頃はPCがシステム開発の当たり前になった頃で、いわゆる「オープン化」の流れのようなものがありました。 この言葉は私の実感としては薄い言葉で、少し年かさの先輩が話してくれたような内容から「へーそうなんだ」という形で記憶しています。どうやらその頃に、開発のスタンダードというものがゴソッと代わり、PCが現場に入ること前提で色々と作るようになったらしいです。

私も少し後に出てきたJavaのことを「おもちゃ言語だな」などと言っていたら、あれよあれよと言う間に業務システム開発のスタンダードになったのですから、おもちゃは侮れないなと振り返って思います。かく言う私も一時期はJavaのフレームワークを作る仕事を何本かやらせてもらえて、現場は徹夜上等のとんでもない働き方だったとは思いますが、それなりに魅力的な内容に携われる時代でもあったのでしょう。

当時は30過ぎてプログラムを書いているのなんか頭がおかしいと言う風潮が日本にはあった、

30までの若い人材は激務で使い倒されて、それを乗り越えられるようなコード書きにはマネージメントをさせるという流れが当時は特に強かったと思います。この言葉からもそれが伺えます。

Netscapeのことは本当に驚きました。元記事で明言されていませんでしたが、この話はFirefoxが誕生する前身の話なんですよね。MosaicというWEBブラウザがあり、Netscapeが生まれ、後発のIEとの競争の末、オープンソースにするという決断をする。下記の記事が詳しいかもしれません。

tech.nikkeibp.co.jp

「オープンソースという魔法の粉を振りかければすべてがうまくいくわけではない」

という言葉の通り、衰退していくことになったのは残念でなりません。でもその後もFirefoxとして今も私たちが利用するブラウザとして残っているのは、OSS化の功績であるようにも感じました。

システム開発の仕方が安定していない時代

少し脱線します。今多くの人たちはPC向けのシステム開発は基本的にはブラウザ上で動くものを作るのだと思っているかもしれませんが、以前は専用のクライアントソフトを開発する*3いわゆる「クラ・サバ」があったり、WEBブラウザ上のJSがAjaxやプロトタイプ志向オブジェクト指向で再発見される前で非力であるというような背景がありました。

その為「今後のシステム開発はどのように進めていくべきなのか」というところが大きな話題だったりしたんです。「配布の容易さ」という面で有利なWEBであるけれども、「操作の快適さ」という面ではクライアントソフトには叶わないという、今のスマホアプリの開発と同じようなことを「PC上の開発をどうするか」というテーマで行なっていました。

その中で両者のいいとこ取りをしようという リッチクライアント/RIA というポジションが現れます。典型的な仕組みの一つとしてはブラウザにプラグインを入れて、そのプラグイン経由で当時のWEBよりもリッチなUIを提供するというような考え方です。

thinkit.co.jp

私はそういう中で、リッチクライアントを推進している会社に関わっていて、自分自身も理想の作り方を有志のメンバーと模索していました*4

そして2009年〜今

デブサミのコミュニティ枠*5でLTさせてもらったのが2009年だったようです。多分ほぼ初LTでこの大舞台だった気がします。

発表者が事前に集まって顔合わせした時に吉岡さんとお目にかかったのでした。昔過ぎて記憶がおぼろげですが、楽しそうに話すナイスミドルだったという印象は強く残っています。その後はイベントに参加した時などお話しされているのを一方的に見かけているだけになってしまいました(ビビリィなんで自分から話しかけるの苦手でごめんなさい)。

そうして10年近くの時がたっている中でも、ずっとコード書きとして生きていきたいなと改めて思った矢先に、冒頭のエントリを拝見して胸が熱くなってしまいました。私も35歳定年説などなんぼのもんじゃと思ってやっています。そのあたりは下記エントリへ。

ms2sato.circlearound.co.jp

おしまいに

ずっと現場でIT技術を扱い、定年などものともせずに一生成長を続けられるような素晴らしいロールモデルだと感じました。私も後進を育てながらそんな風に生きていきたいです。そして区切りまでには胸が熱くなるような何かを発信できたらなと願っています。

遠くからですがご活躍を応援しています!

f:id:ms2sato:20181004185528j:plain

*1:毎度のごとく「あれがダメこれがダメ」って言っているよね。もうお腹いっぱいだよ

*2:おそらく吉岡さんの記憶に私はいないでしょう。なのでひっそりエントリ書こうかなと

*3:スマホのネイティブアプリのイメージが近いかも

*4:まさかまだWEBページがあるとは。懐かしいけど気恥ずかしくもある

*5:当時はそういうのがあって、デブサミは開発者コミュニティがかなり自由にブースを出したりできたんです。最近は違う様子かもしれませんが

好奇心を持ってコード書いたりしたいんだ!

f:id:ms2sato:20180927140032j:plain

はじめに

「あーこれそうだよなー」と感じて、その他のことも色々と考えてしまったので記しておこうかと。

「プログラミングが楽しいと感じて、それを仕事にしていく」という流れはとっても良いと思っています。私は仕事の選び方を「お金を稼ぐ手段」という考え方よりも「生き甲斐」のようなところに置いているので、大金儲けできるけれど退屈な仕事よりは、お金は程々とか多少少なくても熱中できる仕事を選びたがっています。

プログラマーに限らず世の中「仕事は仕事、プライベートはプライベート」と割り切った考え方の方は数多くいると思いますし、それは特に否定しようとは思いませんが、私自身の人生は「生き甲斐たる仕事」を中心に今まで進んできていますし、それがプライベートも侵食している状態がずっと続いていると思います。

ただ、それを他人に押し付ける必要は無いとも思っています。

仕事でのコードの書き方

あくまで私や私のチームのメンバーはそうなっているだろうという話ですが、仕事では以下のような点から様々な意味で保守的に振舞っています。

  • 顧客が望むことが最優先であり、私たちの望みが仕事の中で果たされることは二の次である。
  • 納期があり、間に合わせようと仕事をしている。
  • 自分たちの書いたコードは自分たちが去った後も残っていき、別の人が扱う(ずっと関われそうなら別の考え方もありますが)。

これってどうなるかと言うと「なるべく失敗しない選択をして、冒険せずにゴールにたどり着くこと」が至上命題であり、私たちがチャレンジをすることは減るという結果になりますよね。これが嫌なのか?と言われたらそんなに嫌なことではありません。安定して結果を出すの、すごく大事なことだと思っているんです。ただね...というのがこの話の続きになります。

これまでの流れや顧客の要望によって技術選定は狭まります。弊社はRailsを扱うことが多いのでRailsから積極的に離れることは今現在はありません。jQuery以上の何かを顧客が望んでいることも無いので、jQueryのコードを書きます。

人がスイッチすることを可能にしたいなら同じ技術を皆が扱える方がやりやすいですし、やり込んでいる技術の方が単価も適切に設定できるという経営側の事情もあります。

保守的のストレスと、プライベートでの開発

「顧客が喜ぶ」をモチベーションに仕事ができる人は保守的でも十分かもしれませんが、私はそれだけのタイプでは無いので、これはそれなりにストレスを溜めて進んでいるのだと最近気づきました。20代の頃にあった「今日もあのコードの続き書きたい!」という目覚め方をしていなかったですし「もっとこのコードの続き書きたかったのに!」という気持ちで寝付いてもいませんでした。

私はプライベートでは言語や環境も興味あるものを選びたいですし、設計が気に入らなかったらリファクタリングしまくってみたいです。納期とか気にせずに全力投球したいだけです。この事に頭で考えた理屈なんて無いです(後付けでいくらでもメリットは出せますがそういうことじゃない)。そうやりたいだけなんですよ。

最近golangとvue.jsとappengineで個人のサービスを作り始めたら楽しくて仕方ないです*1。こういうワクワクする感じも必要だったんだと改めて気づきました。メンバーもそれぞれ自分のサービスを作るようになっていて、その話を聞くのも楽しいですし、相談受けてアドバイスしたりするのも楽しい*2

さて、私たちは「勉強」や「努力」をしているのでしょうか?あまりそういう風に思っていない気がします。もちろん業務で言い渡してもいませんので「仕事」でも無いでしょう。好きなもの作って楽しんでやっていればいいんですよ。

これはきっと文化みたいなものだと思うので、こういうことできる人は弊社にマッチすると思うし、できない人は離れていくと思います。それでいいんです。合う人と集まっていろいろやったら楽しいですよ。きっと。

老いることと向き合う

ただ、自分がいつまでもこの知的好奇心を持ち続けることができるのかと自問自答するとイエスとは言えない自分もいるのだ。

これ、実はずっと不安でした。26歳の私は「劇的な成長もきっとできないし、淡々とやっていくだけなんだ。」と思っていました。 42歳の私は「あんまりそういうこと気にせず、全力投球のコード書いてればいいんじゃない?」と思っています。結局自分の本質的なところは変わってはおらず、ほじくり返せば一番感じやすい自分の核に出会える気がします。

会社作ってここ数年はいろいろと自分に決め事を作り戒めていて、ほじくり返して解放することを避けていました。でも、今の方がいいなぁ(笑)今の自分なら死ぬまで全力投球できる何かを探して続けられる気がします。もちろんコードを書くことだけじゃない楽しみも全力でやりたいです。若手を鍛えて自分よりも若くて凄い人をザクザク誕生させられたら、10年後とかメチャクチャ楽しいと思っています。

おしまいに

最近読んだブログの中にもすごく良い言葉があって首がもげるかと思いました。フツフツと湧いてくる好奇心を失わずに今後も生きたいです。楽しんでいるだけなのに、成長できるなんて一石二鳥過ぎてお釣りがいっぱいです。

成長が鈍化している人は好奇心を失っている。

若いうちの苦労は買ってでもしろとか言うおっさんがムカつく - 毎日がもふもふ

「知らないことを知る」というのもまた楽しいことだし、「難しいことを工夫して結果を出す」のもやはり楽しいことの一つなんだと思います。今の所「工夫して新しい何かを作り出す」が私の心を最も刺激してくれるのだと感じています。いつか変わるかもしれないけれど自分自身の変化にも興味を持っているので、それも楽しみです。

[PR] 一緒にもくもく開発するイベントやるんですよ。良かったら一緒にどうですか?

そんな僕らと好奇心を満たしませんか? もうすぐ満席ですけどまだ入れるので埋まったら枠広げますよ! techdrive.connpass.com

*1:この件はまたどこかで書きたいです

*2:誤解が無いように書いておきますが、仮にこのサービスを毎日作っていることが仕事になったとしたら、遠くない将来私はこの事に保守性を感じ始めるんです。k8sも使いたいしElixirだってやってみたい。WebAssemblyをベースにして新しい言語とか作ってみたい。

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に結びつけるのは仕様です