IT業界で気づいたことをこっそり書くブログ

くすぶってるアプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業)

若手エンジニアが如何にして老害になるか(過剰品質、過小見積もり問題)

つよいタイトルを付けてしまいました。そんなつよい話じゃないです。

エンジニアの成長曲線と見積もりの相関関係について です。

 

 

見える範囲が変わる 

ある言語の1年目と、3年目の人が、同じ機能の開発を任されるとします。
先に完成させるのはどちらでしょうか?

 

当然3年目・・・と言いたいところですが、おそらく1年目の方が先に完成させるでしょう。これはするべきタスクの洗い出しが甘いからゴールラインが違っているんです。
中身を見ずに判断すると「この1年目は天才かもしれん」となりますが、リリースしてからバグが出たり不都合が生じます。
と言っても、それでもどうにかなるプロジェクトもありますが。

 

このように、我々は学習し経験を積むほどに見えるするべきタスクが増大していきます。

 

f:id:otihateten3510:20191008044849p:plain

 

経験値と、実際のタスク量と、見積もり量の変遷

 

以下のような過程を経ると思います。

図が雑ですが。

f:id:otihateten3510:20191008045331p:plain

 

最初のうちは、知識と経験量が足らずに少ない見積もりで少ないタスク(低品質+不足)をこなし、「完成しました」と言ってしまいます。もちろんバグが沢山出ますが、テストが疎かなら気づかずにリリースしてしまいます。

 

経験値が溜まっていき、ようやくまともに仕事をこなせるようになり始める頃。やらなければならなかったタスクに気づき始め、見積もりも大きく上振れます。
ここまでは問題ありません。

 

更に学習し、経験値が溜まっていくと、やらなければならないと考えるタスクは更に増大しますが、見通しが立つようになって工数は一定か減らすようになります
過剰に自信がある状態、いわゆる「完全に理解した」状態です。
しかしタスク量は増えているので、見積もり通り行くことは稀です。

この時点を老害と起きました。
でもこれ結構初期段階ですよね。若いのに老害(矛盾)

老害と言うか、詳しくてうるさい人ってやつですね、何て呼べば良いんでしょうか?イキリマウントエンジニア?

 

その後、反省して品質やタスク量を上手くコントロールする人と、そのまま若年性老害を続けて本当に老害になる人に分かれると思います。
どっちが多いですかね?半々くらい?

 

ベテランでも良いですが、「おっさん」と呼んでも良いと思います(何が)

 

若年性老害エンジニア vs おっさんエンジニア

おっさんには若年性老害の気持ちがわかるのですが、若年性老害におっさんの気持ちはわからないので、おっさんは特に何も言わないようになると思います

どちらがリーダーになるかによっても非常にプロジェクト内の温度感が変わります。
まあでも遠目で見れば誤差だと思いますけど。何が違うかと言えば、残業時間と仕事の辛さくらいですかね?

何でそれしか違いが出ないのかと言えば

品質 → どちらも必要以上の品質になる
工数 → おっさんは100と見積もって100やる。若年性老害は100と見積もって120やる

だからです。

 

 

おわりに

過剰品質の話とか書こうかと思いましたが長くなるのでやめました。

 

ところで、非エンジニアのPOがエンジニアに見積もってもらった際、エンジニアがどのフェーズの人間かで見積もりは大きくブレますよね。
おそろしいです。
違うフェーズのエンジニア同士も見積もりの議論がうまく噛み合いません。

「数人に聞いて一番大きい値を採用する」みたいな方法良いですよね。

 

あと、「エンジニアを経験した経営者!」みたいな謳い文句良く見ますけど、大抵おっさんフェーズまでは到達していないので悪い方に働くリスクも大いにありますよね。
ディレクション経験もあれば良いんですけど。

 

ということがあるので、見積もりは何かしら客観的なものから経験的に割り出すようにしたほうが良いと思います。画面数やER図や複雑度など。
まあそれ自体の妥当性も説明がつかないので結局話は平行線なんですが(諦観)

 

間違っても成功するし、正しくても失敗する、と言う話

 

社会に出ると「間違っても成功するし、正しくても失敗する」という事象に多く遭遇します。
この現象をきちんと受け入れないと、誤った解釈を産んでしまうことが多いです。というような話をします。

観察してみると結構面白いです。

 

 

1.間違っても成功するし、正しくても失敗する例

理不尽な状況と言うのは大体そうです。社会人になるとそういう状況をよく目にしますね。むしろそちらのほうが自然なのだと思います。逆に学校や創作など、作られた世界ほど理不尽度は低く保たれています。

  • マニュアル通りに行ったが、ソフトは動かなかった
  • 完璧なプレイをしたが、試合に負けた
  • 社長は大きな間違いをしたが、プロジェクトは成功に終わった
  • 100問中40問間違ったが、受験には合格した
  • 会社は成長したが、給料は上がらなかった

 

2.主な原因 

1.環境に対する勘違い(環境誤認)

2.複数行動、程度によるもの

 

原因1.環境差異

人が何かのアクションに対する結果を予測するとき、理想となる環境を想像しています。例えば「ボールを投げたら地面に落ちる」という予測は重力のある地上という環境を想像しているわけです。
この環境が、実際に行う環境と異なれば、結果は異なるでしょう。

(まどろっこしい言い方ですが、要は「予想が外れた」って状況です)

 

成功すると思ってやった正解のアクションなのに失敗したとき
あるいは
失敗すると思ってやった間違いのアクションなのに成功したとき

その原因は理想環境実環境に差があったのかもしれません。

 

f:id:otihateten3510:20190924230000p:plain

わかりにくいですが、難しい話ではないです。結局「正しい」の前提となってる環境と、行使した実際の環境は別物だった。予想が外れたと言う感じです。

 

環境誤認の例

環境:転職前の会社 と 転職後の会社

Aさん「前の会社ではこの行動で上手く行ったんだけど、今の会社じゃ全然うまくいかないよ〜」

 

環境:Web系の業界 と SIerの業界

Bさん「Web系の業界ではこんなの当たり前なんだけど、SIerでやったらこっぴどく怒られた」

 

環境: 世間一般 と 会社

Cさん「メールで承知しましたって書いたら、拝承を使うようにとたしなめられた」

 

環境:猫 と パンダ 
猫を飼ったことがある人が、同じようにパンダを飼育したら上手くいかなかった。

 

なぜ環境誤認を起こすか

極端な例だと「そりゃそうだろ」となりますが、これが複雑になると途端にわからなくなります。

たとえば、環境が別物だとわかりやすいです(猫とパンダ)
しかし、例えばWeb系もSIer同じIT業界だと認識すると、頭の中で両者が同じ環境だと認識してしまい、環境誤認という結論に中々至らないものです。

誤認する原因はいろいろあります。

  • 同じカテゴリだと思っている
  • 両者が似ている
  • 1つの環境が、時間や条件で不変だと思っている

特に最後のモノが曲者です。
例えば入力条件、内部状態でも出力は変化します。

例)イケメンがナンパをするのと、ブサメンがナンパをする場合、環境=人に対し同じ行動をしても結果が異なる
例)母が忙しい時に話しかけたら怒られるが、落ち着いた時に話しかけても怒られない

一見して同じ環境でも、タイミングや条件で変わるわけです。

 

似ている環境も厄介です。
あるアクション群にたいして、環境Aと環境Bが同じ結果を示したとすると、AとBは似ていると思ってしまいますが。じゃあ次の行動に対して同じ結果が得られる保証はどこにもありません

 

環境構築に問題がある

環境の分類というのは学習によって行われます。
これは強化学習などの機械学習の考えに近いです。その環境に対して色々行動をして反応を見て、似ているものを分類するわけです。
あるいは、同じカテゴリだとか、似ているだとか、いろんな情報から環境の切り分けをし、その環境下である行動をすればこういう結果が得られるという経験値を貯めていきます。

ですが、人間はその環境構築があまりにも雑かつ早すぎるきらいがあります。学習が早いというのはメリットでもありますが、デメリットでもあります。機会学習なんて、一個の環境を調べるのに数千〜数万回の試行を行うわけですが、人間はせいぜい数回で一般化(環境構築)してしまいます。「わかった気になる」んです。これは注意するべきなのだと思います。

 

環境構築時点で間違っている常識が多々ある

ある環境下で、常識的に正しいと言われている行動をして、失敗しました。

このとき考えられるのは

  • 自分が環境を誤認している
  • 常識の一般化が早すぎる(例外を考慮できていない)

です。

 

逆の結果が出たらどうするか

「予想が外れた」わけですから、その正しいと思った行動は実環境下で間違っていたわけです。
素直にそう捉えれば良いのだと思いますが、これが非常に難しいです。
なぜなら頭の中で「理想環境=実環境」だと思っているから。これを剥がすのにはなぜか苦しみを伴います。

結果出てくる感情は「実環境が理想環境ではないのがおかしい」という、認知的不協和です

  • 国はこうあるべきだ
  • 会社はこうあるべきだ
  • のび太のくせに生意気だ

もちろんこういう感情は進歩のために必要なのですが(環境改変)、それは認知的不協和であって、環境構築を再確認することもできます。
そこで一歩踏み込めば、理想環境と実環境の差は何から来ているのか?という疑問に発展し、それは非常に有益なモチベーションとなるはずです。

「実環境が悪い!」という結論はもったいないです。

 

理想環境を捨てるという手もある

理想環境、すなわち常識なんて邪魔なだけなので、実環境に対してアクションをした結果そのものだけをベースに考えるのは一つの手です。
認知的不協和もあまり起こりません。

 

応用:会社が成長したのに給料は上がらなかった 

理想環境:会社が成長したらそれに寄与した社員の給料が上がるものだ

得られた結果:給料が上がらない

  • 今の理想環境はどのように自分の脳内に構築されたか?常識か、経験か、知識か、願望か
  • 実環境はどのようにしてそうなっているのか?決めている機構や権限はどこにあるか
  • 理想環境と実環境の差はどこにあるか
  • では今後どうするか?

 

原因2.複数行動、程度によるもの

環境誤認がなくても、「間違っても成功するし、正しくても失敗する」は起きます。

例えば、80点取れば合格する試験があるとします。
そしたら、20点分間違っても合格しますし、70点分正しくても不合格になります。
そのテストで、問題毎に正解/間違いが分かればいいですが、合否の結果みアウトプットされた場合、どの行動が正しかったか、間違っていたかわからないのです

すると、局所的に「正しい解答をしたのに結果失敗する」という現象が起きます。
これも非常に多いです。

 

f:id:otihateten3510:20190924234437p:plain

 

絶対に失敗を返す環境が存在する

これの応用で考えると、絶対に失敗を返す環境も存在しますし、絶対に成功を返す環境も存在しますし、ランダムに成功/失敗を返す環境も存在します

厄介なのは、複雑な環境においてはそのことを知るのが困難だということです。

 

入力しているのが自分だけとは限らない

例えばチーム戦・組織戦の場合、自分だけが100点の働きをしても、他の人がポンコツなら簡単に失敗します。

これは逆も言えます。

 

まだまだある厄介な環境

f:id:otihateten3510:20190924235241p:plain

反応がない環境

 

f:id:otihateten3510:20190924235301p:plain

結果が複数ある環境

 

3.行動の評価は非常に難しい

私達は「行動と結果から環境を類推する」と同時に「行動と結果から、その環境下でその行動が正しいか間違っているか」を学習すると思います。

でも上記の通り、とにかく行動と結果というのは様々な要因で合わないケースがあります。こんなの簡単に学習できるわけがないんです。

実はこれを言いたかった。

分かったふりしてる人は大体一般化が早すぎます。

 

4.再現性のある成功への戦略

以上からわかることを短めにまとめます。

正しい行動を見定めるにはどうするか?

環境×行動のパターンは膨大です。
ある程度範囲を絞らなければなりません

これは人気サービスなんかがグロースハックでやっていますね。

選択と集中という話はよく出ますが、私は分析可能なサイズまで落とす必要があるのだという認識をしています。

 

環境を正しく理解する

自分が行動をとっている対象の範囲をよくよく観察しなければなりません。
別の環境で起きた事象を参考にするとノイズになってしまいます。

 

未知であることを自覚し、予測し、行動し、結果を比較する

科学的アプローチでも良いですし、リーンスタートアップ的アプローチでもいいですが。

学習できる流れを作っていく必要があります。

 

検証可能な環境を選択する

フィードバックが得られない環境に対峙するのは無駄です。
あるいは、フィードバックが得られるように工夫する必要があります。

 

検証可能な行動を取る

一気に行動をすると何が良かったのかわからなくなります。

 

成功するか失敗するかギリギリの環境×行動を選択する

常に成功が返ってきたり、常に失敗が返ってくると学習できません。

 

5.あるいは全部諦める

なにかの環境に対して再現性ある成功を求め、正しい行動を追求するのは素晴らしいことです。でもあまりにも難度が高く、そんな都合のいい環境や行動の取れる人はかなり稀です。例えば大企業の中に居ると非常に厳しいと思います。人が多い分、行動が良かったのか悪かったのかは非常にノイジーというケースが多いでしょう。成功しても自分が上手くやったのか、会社がすごかったのか、わからないはずです。

じゃあそんなことは諦めて、正解を知っている人に乗っかる方が手っ取り早いかもしれません。おそらくそれが一番賢いです。

 

6.諦めても知っておきたいこと

成功しても、失敗しても、「原因が◯◯にある」だなんて安易に言えないはずです。

誰かのせいかどうかもわからないし、自分のせいかどうかもわかりません。あまり悩んでも無駄で、「わからない」以上にはならないと思います。

 

おわりに

ここらへんの話は、事業の勝ちパターンってどう発見すればいいだろう?と考えていた時にグルグル頭の中を回っていた話です。

結局無理ゲーじゃん!です。ほとんどのケースはたまたま勝ったか、勝ってるものを徹底的にパクったかだと気づきました。

たまーにガチで世界の深淵に挑んでいるすごい人が居ますけど。どうやったらなれるんでしょうね?やはりまずはそういう実験場を作る環境なんでしょうか。でもそういうのを狙ってやれてる人はどれだけ居るのか疑問です。

なぜ仕事はクソゲーなのか? どう考えても詰んでる話

これは数年前に某社を退職するか悩んだ際に考えたことです。

その会社のエンジニアにおける状況で考えたんですが、ほとんどの仕事に当てはまる気がします。というかたぶん組織論の一種になるので、仕事以外でも似た事象は発生しそうです。

 

 

 

シンプルな例え話

ある会社の製品の評価軸が2つあるとします。

  • 製品の硬さ
  • 製品の色の良さ

しかし、実際のところ売上に寄与しているのは「製品の硬さ」のみで、「製品の色の良さ」は寄与していないという真実があったとします。
自分はその事に気づいていましたが、会社は気づいていませんでした。

さて、その会社から同様の製品を作ってくれと言われたとき、色はどうしますか?

(これは外注という目線でも、社員という目線でも大丈夫です)

 

行動パターン

  1. 色は事業に寄与しないから色付けは手を抜く
  2. 依頼者(上司)の価値観に合わせて、色付けを頑張る
  3. 何に対しても妥協せず全部頑張る
  4. あなたの色に対する認識は間違っていると説得し落とし所を探す

このとき、1は依頼者に対しての裏切りであり、2,3は事業に対しての裏切りです

こういうのって生きてればちょくちょくありますよね。親や先生が間違ってること言っていても、それに従わざるを得ない、みたいな。

問題は4です。

 

価値観の説得は難しい

状況次第で説得可能な場合もありますが、大抵の場合は難しいです。

  • 依頼者の経験的に色が重要だと結論づけた
  • 依頼者の上司が色が重要だと言っている
  • 慣例
  • 他の職人の中にも色が大事だという人がいる
  • 世間一般でも色は大事だと言う人がいる
  • エビデンスを用意できない(普通公開されない)
  • 自分が間違っている可能性もある
  • 色付け職人がいる

 

依頼者1人の価値観ではない可能性が高い

そうなると組織全体に対して説得しなければならないわけで、それは無理ゲーに近いです。

 

自分が間違っている可能性

事業というのは摩訶不思議で、何に対しても確証というのは中々得られないものです。それが自分の会社でなければなおさらでしょう。

たとえば、売上には寄与されていないようで、顧客満足度には影響しているとか。ある一定の品質を割り込むと影響が出るとか、ある一定の品質を超えると影響が出るとか。

更に厄介なパターンは、色の品質を上げていることで、有能な職人が採用できるという、採用面に影響しているとか。職人のモチベーションに影響していて、手を抜くと硬さの方にも影響が出てしまうとか。

そういうのを考えると慣例でやってしまいますよね。

 

専門の職人がいる場合

その場合、依頼者は安易に説得されるわけには行かないでしょう。
こうなるともはや雇用問題です。

 

説得できるのはコンサルタント

もちろん影響度合いによって説得できる対象もありますが、ある程度大きな価値観となると、組織全体の共通認識になっているケースが多いでしょうから、説得するにはコンサルタントのような働きかけをしなければなりません。

今、仕事を依頼されているわけですが、そこでそういうアプローチをするか?と言う話になります。つべこべ言わず仕上げたほうが早いでしょうから、そんなアプローチをしてきたら疎まれること間違いなしです。

 

詰んだ\(^o^)/

これで詰んだと思います。

依頼者に対しての裏切りを選択するか、事業に対しての裏切りを選択するか、無理とわかって説得するか、しかありません。

 

正しいと思うことを押し通すのは良いことか?

依頼者に対して裏切り、事業にプラスになるような行動をすることは果たして良いのか?と言う話です。(これ1個だけで重いテーマなんですが)

漫画なんかだとこれが一番好まれる選択だと思いますが、中々そううまく行きません。
上手く行かない理由を書きます。

 

事業が失敗したら依頼者は真実に気づくか?

NOです。

「色合いが悪かったから事業が失敗したんだ」という結論になります。

人間は失敗した時に自分の価値観を改めるより、自分の価値観で失敗を説明しようとします
毒を薬だと信じている人が、毒を飲んで体調を崩したら「これは毒だ」とならず「飲む量が足りなかったんだ」となります。
もちろんその対象をどれだけ信じているかに依りますが、仕事における価値観は大抵強いものです。

 

そもそも事業は失敗しない

間違っても成功するし、正しくても失敗する法則」があります。(この話、ずっと前から書こうと思ってまだ書いていないんですが)

追記:書きました

otihateten.hatenablog.com

 

簡単に言えば大勢に影響しないケースが多いわけです。

今回の例で言えば、色に力を入れようが手を抜こうが、変わるのは掛かった経費くらいのもので、誤差の範囲になってしまいます。
だからそこで価値観の変容は起きません。

※そういう意味では、安定した大事業に居るほど行動が結果に影響しなくなるので真相から遠ざかります。一手間違ったら死ぬ事業に居るほど真相に近づけます。が、もちろん職としてはまるで安定しません。

 

依頼者を裏切ったらどうなるか?

「真実を教えてあげたんだから感謝されるだろう」とかいう発想はげろ甘です。基本評価が落ちるか、外注なら切られるだけなので、余計に話を聞いてくれなくなるでしょう。

 

依頼者には色んな人が説得してくる

ある人は「色は関係ありません!」と言うし、他の人は「色が重要です!」と言ってきます。依頼者は基本的に職人ではないので、そのどれかを採用するしかありません。

これは信用問題です。

 

最適解その1

まとめると

依頼者(上司)に対しての裏切り 
 → 評価が落ちる、依頼者が真実にたどり着くのは望み薄

説得する
 → 無理

なので、事業に対して裏切って、依頼者(上司)の言うことを聞くが最適解です。

今やってることがどんなに間違ってると思っても、上の価値観に従って行動するのが一番賢い選択なようです。

 

クソゲーでしょ?

 

仕事で重要なのは真実ではなく、上長の価値観

別の視点から考えてみると、結局こういう結論になります。

この結論は誰もが嫌がるでしょうが、自営業になってみると案外しっくりきます。自営業であればここの上長=依頼者はお客さんになるわけです。
お客さんの事業も大事だけど、お客さんの満足度も大事だよね。と考えればしっくり来ると思います。

例えば自分が美容師だとして、お客さんがかなり変な、10人が見たら8人がオカシイと思える髪型を指定してきたとします。その時に「それはオカシイからやめましょう!」と言うのは半分正解で半分間違いなのではないでしょうか。依頼者の価値観・要望はたとえ間違っていたとしても無視できません。

もちろん、依頼者が事業を成功させたいと切に願っていれば少し話が変わります。その時はダメ元で説得は試みても良いかもしれません。大体失敗しますけど。

 

現実ではもっと評価軸が多く複雑

今回は例え話で「色」「硬さ」というわかりやすい例にしましたが、実際はもっと遥かに多い評価軸があり、さらに良い/悪いで語りにくいものも多いです。

しかも依頼者がその評価軸をすべて認識していないケースもありますし、何がどの程度影響するかなんて、専門家でなければわからないはずです。

 

別解:そんな価値観の奴ら、自ら切ってしまえ!

さて、こういう結論に達した人はアラサーあたりで結構いると思います。

上手く自分と同じ価値観・思想の人たちと合流できれば仕事はしやすくなるはずですから、この選択肢は間違っていません。

ただし事態はそれほど甘くない事が多いです。
事業というものはそもそも難しく無理ゲーなため、どこへ行っても間違い・勘違いというのは大量に存在します。
どこへ行っても似たような状況に陥るわけです。

 

最適解その2:昇進する

GoogleのTeam Geekという本にも「安全な位置まで昇進しろ」的なことが書いていましたが、自分の価値観が正しいと信じているなら、自分が決定者になるところまで昇進すればいいわけです。

ですがこれもちょっと難ありです。

  • 昇進するまでは上司の価値観に沿わなきゃならない
  • 昇進しても異なる価値観を持った人は存在する
  • 昇進すると、自分の分からない評価軸に対してジャッジしなきゃならない

何か解決しているようで、俯瞰で見ると大して変わっていないんです。
そもそも上で出てきた依頼者(上司)も良かれと思ってやっていたわけですから。総合的に自分と元上司のどちらが良いパフォーマンスを出すかはわかりません。

 

最適解その3:真実究明を組織で行う

何が事業にとって正しいのかというのを組織で研究する仕組みがあれば大分マシになると思います。ただこれも難ありです。

  • 非常に頭を使う
  • コストを使う
  • 研究できるだけの過去の実績や記録が必要
  • 結論は受け入れなければならない、全ての結論が自分の意見と合うとは限らない
  • そもそも大半は興味がない(特に事業に対して)

実際やれている組織は滅多に無いです。

最近話題に「心理的安全性」とかはここらへんの話ですね。

 

最適解その4:真実究明を業界で行う

これが理想的だと思います。
皆が拠り所にしている価値観というのは、大体が偉い人・インフルエンサーの言説の受け売りだったりします。だとすれば、そういう人たちが正しく研究し、ドンピシャで正解を言ってくれれば皆迷わずに済みます。

これは業界によってかなり差があると思います。
挑む対象にもよります。結果がわかりやすい領域ほど楽です。

ITはその意味では、プロダクトや事業の評価が若干しづらいという点で難ありと言われていますが、情報交換は活発です。ただWeb系においては「偉い人・インフルエンサー」というのが民主的に選ばれている感じがあるので、皆の興味の向かない範囲は甘いという印象があります。

 

この最適解の問題は、自分1人でどうこうできないということです。
自分自身ががんばって真実にたどり着いて、登壇して布教するというのは一つのやり方ではありますが、例えば企業毎の事情などは汲み取れないので難しいところです。

自社内で研究して皆に発表するという手ももちろんあります。
かなり地道な活動になりますが、真面目に考えたらそれが一番なのかもしれません。
実際真面目にそうやってる方はいらっしゃいますね。

 

最適解その5:依頼者を相手にしない

市場や、自然を相手にすれば良いわけです。
市場や自然は非常に厳しいですが、評価は限りなく真摯です。一切綺麗事なく、やった通りの結果を返します。

この方法は割と究極的だと思っているんですが、まず誰でもできるわけじゃありません。エンジニアなら自分のサービスを持たないと難しいです。
しかも自分自身について解決しても社会全体で見れば大して解決していません。「仕事はクソゲー」というのは変わってないわけです。

 

別解: 自分の価値観を大事にして、他は無視

なんかこれで良い気がしてきました。

 

まとめ?

よく視座を高く持て、経営目線を持てなんて言ったりしますが、あれは正しいんでしょうか?
私はいろんな視座・視点で考えるタイプですが、あーだこーだ考えた結果、上記のような結論に至りました。最近は「別解:自分の価値観を大事にして、他は無視」でいい気がしてます。その方が楽です。
他視点で考えるのは癖なのでやめませんが。

 

とは言え私はそっちの手段を取っていません。
もう一つのやり方としては「極力柔軟に対応する」です。依頼者の価値観に合わせる方です。いろんな価値観・基準・考え方を理解しないといけないので面倒くさいですが、1個の価値観に依存するのは個人的に怖いです。常にどれも間違ってる気がしています。

 

ちなみにこの話は組織における構造的問題なんだと思います。
今回は書きませんが、この構造を「自分ー上司ー事業」じゃなくて「自分ー上司ー上司ー上司ー事業」にしたり、「部下ー自分ー上司ー事業」にして考えるともう発狂するようなめんどくさい話になります。
何が正しい行動なのかは結局トレードオフです。

 

あと、出資者なのか労働者なのかというのも絡んできます。
究極的に言えば、労働者なんて穴掘って埋めても給料はもらえる素晴らしいものなので、真実とか正しさを追求するべきは出資者であるはずです。

「いや、自分は労働者だけど真実を知りたいんだ」というのは別に構わないんですが、依頼者(上司)はそう思ってないかもしれないし、彼もおそらく労働者ですから、真実がどうとか関係ないんです。だから「善意で真実を教えてあげよう」は案外正しい行動とは言えません。「こんな穴掘り作業は間違っている!」みたいな。
より正確に対処するなら、経営者に話をする際と分けるべきなのかもしれません。

 

じゃあ出資者に対しては真実ベースで語れるのかと言えばそうでもなかったりします。一般消費者と同じです。やりたいように金を使ってるんですから、まずはその人の意志を聞かないと何とも言えません。
この世はエゴイスティックですね。

 

おわりに

仕事論というのはアラサーあたりで一回ハマると思います。私もかなりハマりました。

でもアレです。たけしの挑戦状的に言えば

「こんなげーむにまじになっちゃってどうするの?」です。

第一に生き残ること、第二に自分の気になることを追求した方が幸せなんじゃないかと思います。

自分が出資者・経営者になったら、改めてこの問題とまた向き合う時が来ると思います。 

エンジニア・プログラマーのタイプを考えてみる

昔書こうとしてイマイチしっくり来ず放置していた話。

 

プロジェクトが上手く行っているか、上手く行っていないか。
その人の行動が正しいか、正しくないか。
などというのは、一意に決まらないものです。
プロジェクトには非常に多くの評価軸があるため、人や案件によって「正しさ」が全く違ってきます。

 

 

こういう点はフリーランスのほうが感じているのかもしれません。
30代正社員となれば、経験社数はせいぜい1〜3社と言ったところでしょうが、フリーランスになると取引する会社は二桁に及んだりします。

二桁も会社を経験したら法則性が見えてくるのかと思うのですが、価値観は会社や人によって千差万別なようで、げんなりしてしまいます。
おまけに大抵の人は「他の会社でも似た価値観だろう」と思っていたりするので非常にめんどくさいです。
ある会社では「そうですね、黒ですね」と言って、別の会社では「そうですね、白ですね」と言ったりします。

 

エンジニアのタイプ

前置きが長くなりました。

昔から考えてるエンジニアのタイプです。エンジニア内でも人によって価値観が千差万別で話が合いません。最近は意見を戦わせるのが面倒なので、相手に合わせるようにしています。

 

 

f:id:otihateten3510:20190923002155p:plain

 

イマイチしっくり来ない図ですが。このようなタイプに分けてみました。
四隅にあるのは、気にする話題です。

簡単に説明。

社会派タイプ

社会に影響を及ぼしたくてプログラミングをやっている。
大きい案件や影響度の高い、やり合いのある案件が好き。
コードそのものには興味ないが、興味ないからこそ世間で言われてる方法を安易に採用してしまいがちで、そこで失敗することもある。

 

事業家タイプ

要は社長タイプ。
どう作るかには興味あるけど、それはあくまで事業のためであってコードが好きというわけではない。
PM向き。エンジニアは手段であると思ってる。
エンジニアを辞めてしまうので希少種。

 

解決思考タイプ

コードでも事業でも社会でも組織でも、何でも問題と捉えてそれを解決するという発想で動いているタイプ。
技術志向の度合いでまた少し変わる(技術で解決したいタイプ、解決手段の中の1つが技術タイプ)
打算的。PL向き。
ある程度枯れた技術ばかり追っている傾向があり、最新技術には割りと疎い。何が流行ってるかだけフォローしている。
デスマしがち。

 

職業人タイプ

エンジニアをあくまで仕事と捉えているタイプ。
勉強する=コーディングの勉強になりがちなため、周囲の意見に流されがち。Web系ではコードに対するモチベーションが高くなるだろうし、SI系ではプロジェクトに対するモチベーションが高くなる傾向。
けどそれらは「世間でいいと言われているから良い」というもの以上ではないので、「流行ってるようで実はあまり使われていない」みたいなものに引っかかりやすい。

 

ものづくりタイプ

何かを作るのが好きなタイプ。
この中で更に「作ることが好きなタイプ」と「作る物が好きなタイプ」に分けられる。
良いものを上手く作りたいと思っているけど、厳密にどの方法が最適かというよりは、楽しさ面白さを重視しがち。
プロダクトによって仕事のテンションが大きく変わる。

 

技術好きタイプ

面白い技術、新しい技術、流行ってる技術が好きなタイプ。
非常に目立つが、他のタイプと評価軸がかなり異なるため揉めたりもする。
イノベーターというよりはアーリーアダプター
結構多い。
採用技術によって仕事のテンションが大きく変わる。

 

科学者タイプ

「技術好き」より更に踏み込んで、数学的な正しさとかスピードとか効率とか、厳密に何がどれほど良いかという真理を探求する研究好きタイプ。
ハマれば非常に有用な人材だけど、ハマらなければまったく関係ないところにこだわるタイプにもなる。
イノベーターになりがち。他の人が触れないコードを書きがち。
希少種。
 

「素晴らしい技術が発表されました」に対する反応

社会派タイプ:社会的なインパクトを予想する

事業家タイプ:競合に差をつけられそうか考える

解決思考タイプ:それで何が解決できそうかを考える

職業人タイプ:次のプロジェクトで使うことになりそうか考える

ものづくりタイプ:それでどんな物が作れそうか考える

技術好きタイプ:技術的にどこが面白いか考える

科学者タイプ:他技術と比較して考える

 

主な生息域

社会派タイプ:大きな事業、大きな事業が見込めるスタートアップ

事業家タイプ:ベンチャー、中規模受託(大企業内にもいると思いますが)

解決思考タイプ:PL、受託、ベンチャー

職業人タイプ:安定企業

ものづくりタイプ:C向け事業会社、小規模受託

技術好きタイプ:イケイケベンチャー、有名企業、技術ブログ

科学者タイプ:研究部門、大学院、OSS界隈

 

当たってるか自信薄ですが。

 

どのようにタイプが決定されるか

先天的なものと後天的なものがあると思います。
会社や周りの価値観に同一化されることがよくあります。
我が強い人はすぐ辞めちゃうイメージ(私です)

 

あまりタコツボ化するとエコーチェンバーになるので注意が必要ですね。

エコーチェンバー現象 - Wikipedia

 

話が合う相手 

社会派タイプ:ファウンダー、企画、投資家

事業家タイプ:執行役、PM、企画、投資家

解決思考タイプ:PM、ディレクター

職業人タイプ:PM、ディレクター

ものづくりタイプ:企画、デザイナー

技術好きタイプ:同じ技術者、科学者タイプ

科学者タイプ:同じ科学者、技術好きタイプ

 

合わない相手は割愛しておきます。
が、解決者タイプの合わない相手は同じ技術者だと思います(つらみ)

 

締め

それぞれ対処方法も書きたいんですけど、永遠に完成しなさそうです。
上記で分かる通り、皆別のこと考えてるので話が合わないんですよね。
せめて合わせようとしてくれる人が多いといいんですが。皆が自分と同じ考えだと思ってる人が結構多い印象です。

昔この話を作ったときは、タイプ毎に分けて、それぞれが気にしているポイント(例えば仕様や設計や技術やプロダクトやテストなど)を分けて傾向と対策を練ろうかと思ったんですが、無理でした。無理です。でも何か色んな人が居るのは確かです(雑)

UIWebViewからWKWebViewに移行する際にハマること(特にCookie周り)

Qiitaに書こうかと思ったんですが、完全に理解できていない情報が多いため、ログとして残します。

 

Cookie周りが非常に厄介

UIWebViewとUIWebViewはCookieやSessionが同期されます。
iOS11以降において、WKWebViewとWKWebViewも同期されます(?)
iOS10以下において、WKWebViewとWKWebViewは同期されません。
iOS11以降においても、UIWebViewとWKWebViewは同期されません。

同期するためにおそらくこちらの方法を使うと思いますが未検証です。

WKWebViewでのSessionの共有 - Qiita

同期されるのかされないのか問題は未だ非常に曖昧です。
同期される条件やタイミングなど。

 

参考

WKProcessPoolが違ってもWKWebView同士のcookieを同期されていた - しめ鯖日記

 

バージョンアップでセッションが切れる

当然、UIWebViewをWKWebViewに移行すると、Sessionが切れるため対応が必要です。
対応方法は未検証。

 

iOS10以下ではCookieの取り出しが困難

これは調べると結構でてきます。ただ取り出し方はこれだというサンプルコードがありません。javascriptを使い強制的に取るしか無いようです。

 

Cookieの設定タイミングが妙

webページ読み込み終了した後Cookieを取ろうとして取れないことがありました。UIWebViewとタイミングが違う可能性があります。要検証。

 

Cookieの削除が厄介

普通に消えないようです。
ここが非常に詳しい。

[Swift]Cookieの削除|杏z学習帳

 

認証関係で少しハマる

ググれば出てきますが、Basic認証SSL

func webView(_ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void)

こちらを使用する場合、UIWebViewのときとは処理の方法が少し変わります。

特に何もしない場合は

completionHandler(.performDefaultHandling)

を呼んでやります。呼ばないと落ちます(やめて!)

 

WKWebView操作に関するキーワード

WKNavigationDelegate ほとんどこれです
NSKeyValueObserving 上とこの2つがメインです
NSURLConnectionDelegate Auth関係で使う場合があります
WKHTTPCookieStoreObserver(これは動くのか不明、私が未検証なのではなく公式的に曖昧)

 

 

罠だらけ!

WebViewアプリはiOS13,14対応で一回血反吐吐くかもしれませんねこれ。

 

何故こんなに厄介なのか?

おそらくですが、UIWebViewと、WKWebView(iOS10まで)と、WKWebView(iOS11から)の情報が混ざってるからです。

 

 

追記:2019/11/26

 

メモ:WKWebViewの特徴


Cookieをセットしてcompletionが呼ばれてもセットされていない
・例えWKWebViewから該当のCookieを取得できてもセットされていない
・WKWebView1に反映したのに、別のWKWebView2に反映される
・アプリ削除して再インストールしてもCookieが消えていないことがある(大抵消えます)

 

求人情報から必要スキルを洞察する(モバイルアプリ・iOS版)

求人情報や、エージェントからの会社情報というのは頻繁に曖昧なスキル要件で書かれています。原因はいくつかあります。

  • 書いた人がそれしか知らないから、その情報を書けばわかると思っている
  • 書いた人が技術者ではなく、伝言ゲームになる
  • 該当の技術者が居ない
  • エージェントがよく解っていない

もちろん不明瞭な表現をしている案件ほど危ないので、避けたほうが良いのですが、「別に曖昧なプロジェクトでもやっていけるよ」という人も居ると思います。

そんな時どう予想をつけるかという話。(iOS版)

 

基本的な求人

iOSネイティブ
Swift4
iOS11以降

こう書かれていれば8割くらいは一般的なiOS求人です。

 

ハイブリッドアプリ

例1
iOSAndroidの経験者

例2
iOSjavascriptの経験者

例3
モバイルアプリ経験者
javascript

 

このように書かれていたら、jsで書くハイブリッドアプリを疑います。
ReactNativeはReactNativeと書かれていることが多いので分かりやすいですが、たまに書いていません。

 

APIもやって欲しい案件


iOSPHP経験者

 

こういう書き方もあります。
PHPiOSを作っている案件を見たことが有るので、その可能性も無きにしもあらず。

 

Rx

大凡iOSネイティブの求人っぽいけど

RxSwiftと書かれていたらかなり別物のコードになっているはずです。

 

その他あり得るパターン

iOSAndroid両方やってほしい案件は見分けが付きづらいです。

Androidの方の求人に「Swift」と書かれていたり、iOSの求人の方に「Kotlin」と書かれていたりするともう確認するしかないです。

 

締め

自分ができる領域って割と狭いですよね。

無駄時間を取らないように、求人読解力を付けておきたいです。

実務におけるSwiftUI,Combine登場の影響(随時更新)

QiitaなんかではSwiftUIやCombineが活発で注目されています。
iOS界隈はAndroidやWebに比べて一歩慎重に進行しているらしく、先進的な人にとってはそれがもどかしいようです。

 

私はどちらかと言えばアーリーマジョリティーで、先進的なものを少し毛嫌いするタイプです。明らかに悪影響も見えてしまうので。
そこで実務的にどういうふうになるか?という観点で、分かり次第メモしていこうと思います。
(現状は大して調べられていません。半日程度)

 

 

SwiftUIを使うために必要な環境

Xcode11以上(2019/09/08時点でbeta)
iOS13以上(今月リリース)
MacOS10.15(2019/09/08時点でbeta)

 

Macは任意ですが、一部使用に制限が出るようです。
私はMacOSをbetaにすると仕事に影響が出そうなので諦めました。

 

iOS13以上は必須要件

つまり、iOS12を切れるアプリじゃないと使えないです。
2019/09/08時点で少し調べてみましたが

Twitter iOS11以上
Facebook iOS9以上
Yahoo iOS11以上
LINE iOS10以上

まあここらへんですよね。
多くのアプリでSwiftUIが使えるのはおそらく2年〜4年後です。iOS15か16の頃。
Swift2から4にあがるまで2年くらいなので、そういうイメージですね。
割と長いので慌てる必要はないです。

じゃあ勉強するにはどうすればいいか?といえば
iOS13以降のアプリを作るしかないです。

StoryboardとSwiftUIは混合できるか?

できるようです。
既存プロジェクトにSwiftUIを含めることもおそらく可能ですが、最低バージョンがiOS13以上でないとエラーになります。

 

多くのプロジェクトではSwiftUIとStoryboardのブリッジになる

約束された未来です。
Androidの方も今そういう感じですね。
SwiftとObjective-Cとのブリッジみたいなイメージでしょうか?
SwiftUIで覚えなければならないことが割と多いので、非常に高コストな期間が2021年〜2025年くらいまで続くと思います。
そういうとこやぞ。

新しくiOSを始める人はSwiftUIだけ覚えればいい?

まだNOです。
これが許されるのは2021年以降の新規案件くらいですね。

 

Storyboard,Xibは消滅する?

これはまだわかりません。
例えばObjective-Cはほとんど成りを潜めましたが、Xibはまだ生きています。

3年くらいで答えは出るでしょう。

 

 

一旦まとめ

先進的な人にあてられて慌てて勉強する必要は無いですが、スイッチングに関しては戦略的に動けるようにしておきたいですね。
私は本格的に覚えるのは来年にしようと思います。

それにしても新しく覚える人は何世代分の知識を覚えなきゃならないんでしょう?また参入障壁が高くなってませんか?

あと主流の方法がガンガン変更される中で、独自路線で作ろうとするのはやっぱり危険ですね。自己満足のために苦しむだけです。巨人の肩を信じましょう。

ちなみに私がSwiftを触り始めたのは2.2からだったと思うのですが、一番盛り上がっていたのはSwift1の頃でしたね。世間の加熱と実務には乖離があるので怖いです。