小衣のため息

IQ1300の天才少女、明智小衣のボヤき

【IT業界座談会】

悠里「"分社化を認めれば増資を引き受ける"

という契約は言わば建前で我々の事業と矛盾しません。特定目的会社を経由します。」

?「結構。奴隷の業界が奉仕を怠ると貴族の業界が飢えますからねぇ。」

悠里「人手不足は奴隷産業を潤す。業界の行動憲章からは些か外れますがね。」

?「いや貴方達こそ知識集約産業を名乗られるが実際は典型的な労働集約的産業だ。製造業としては実に理想的ですな。」

悠里「労働の実情はなかなかそうは…と言っても必要な時にカネの配分で操作できますよ。所詮、エンジニアの矜恃なんてどうにでもなります。彼らも資本主義社会の住人ですからねぇ。」

(元ネタ:攻殻機動隊,士郎正宗)

【サービス事業(〇aaS)の成功に必要な要素】

[業界展望]

市場占有率トップ企業が利益最大

(創業3年以内に市場占有率16%を確保した企業が業界の勝利者になる)

→技術仕様の標準化及び公開化が進行しており、それにより工程が汎用化する。結果、事業の参入障壁が低下し、多数の事業者が市場に参加する。価格競争により、最終的にスケールメリットを活かした企業が業界の勝利者となる。

[事業として成功させるために必要な要素]

1.高品質のサービス

⑴可用性(フェイルセーフ)

⑵保安性(セキュリティ)

⑶遡及性(ロギング・証跡管理)

2.広域圏のサービス網

⑴地域横断(グローバル)

→進出先の需要を確認する

垂直統合(マニファクチュール)

→技術優位性を持つ

水平統合(ユニバーサル)

→良き企業市民になる

3.統合化された一元的な事業管理

⑴効果的なマーケティング戦略の立案

⑵機動力のある営業力の構築

⑶未開拓分野に対する積極的な情報収集

[事業モデル]

労働集約的な事業モデル

→作業要員が多ければ多いほど生産性が上がる(Speed&Scale)

⑴単価の安い大量の労働者

⑵スピードの速い事業運営

⑶効率的な作業工程

[事業戦略]

1.創業期

・ニッチ戦法

→既存企業が進出していない分野を調査して徹底的に攻める

⑴独創性

⑵高い専門性

⑶開拓者精神

2.成長期

・コピペ+差別化戦法

→流行に対応し、差別化した商材で特定の顧客や市場を狙う

⑴地域密着

⑵業態特化

⑶新興企業の買収&協業

3.成熟期

モグラ叩き戦法

→ライバルが現れそうな分野を見つけたら資本力と営業力ですぐに制圧する

[事業参加者に必要な能力]

1.幅広い知見

2.深い思考力

3.高い問題解決能力

→新しいビジネスモデルの創出

(ICT Engineer用語で例えると

BusinessFunctionに

FullCommittedした

Solutionを

考える)

メモ:【仕事を任せられるエンジニアになるために意識して欲しいこと】

by西尾(ビビッドガーデン:食べチョクエンジニア)

 

1.意識面

⑴作業の見積もりができる

技術力が低い(コーディングができないなど)よりも敬遠されるエンジニアは、作業の見積もりができない方です。第一線で活躍している方は、作業見積もりが他の方に比べて正確です。

見積もりをするためには、どういう設計をして、どういう機能を作り、どういう影響範囲があるのかを正しく理解する必要があります。見積もりができないということは、作業内容を正しく理解できていない、技術的な困難性を理解していない、不確定要素を洗い出せていない、そして自分たちのスキルを正しく理解していないということです。

⑵作業タスクを細かく洗い出すことができる、TODOを作ることができる

作るべき機能や設計を正しく理解していれば、作業を細かくタスク化できます。タスクを細分化できないのならば、作るべき機能の理解が足りないということです。

TODOを作って細かくタスク分解をして作業を進められると、あとどのくらいでタスクが終わるのかをおおまかに把握できます。紙にタスクを書き出すでもなんでもいいので、タスクを細分化できるようになってください。

⑶進捗を正確に報告する

進捗報告は重要です。これは本当に重要です。

あと1日で終わりますと顧客に報告して、できていなかったら印象は最悪です。次の仕事をもらえなくなります。

もうすぐできますといって根性で何とかしようとする(徹夜してでも終わらせようという)のもやめてください。徹夜して次の日のタスクがまともにできないのは困ります。重要なのは”正確に”進捗を報告することです。

遅れそうならば、遅れる旨を伝えましょう。できてなくても、こういう理由で遅れそうとちゃんと伝えれば、お客さんもわかってくれます。まわりもサポートしてくれます。できないのならば”できない”といいましょう。

⑷言われたことだけをしない

「詳細設計書にはこう書いてあったから、変だと思いましたがそのとおりに作りました。」という人がたまにいます。設計書に書いてあったからと行って、そのままうのみにして作らないでください。変だと思ったらちゃんと報告してほしいし、そのへんはちゃんと自分の頭で考えてみてください。言われたことだけをするエンジニアはいらないです。

優秀なエンジニアの方は、こんな機能も必要だと思うからつけておきましたっていう提案しつつすでに実装してた、みたいな方もいます。報告なしで勝手な機能つけられるのは困りますが、そういう提案してくれる方のほうが、仕事をまかせたいと思えます。

⑸わからなかったら相談する

わからないまま何日も考えて全くタスクが進んでいなかった、という人がたまにいます。その方に割当てていた作業スケジュールが狂ってしまいまわりに迷惑をかけるので、早めに相談してほしいです。プロジェクトが忙しくなると、リーダーも全員に意識がまわらなくなるので、その人の作業が進んでないということに気が付かないこともあります。

30分考えてわからなかったら、相談してください。けど何も考えずによくわかりませんといってとりあえず相談するのも、やめてください。

⑹自分が何ができて、何ができないのかを理解する

誰にでも得意・不得意分野があります。不得意で時間がかかりそうならば教えてほしいし、なんなら別の方にタスクを渡しても大丈夫です。なんでもできますといわないでください。スケジュールが狂うし、できていなかったときにまわりが尻拭いをしないといけなくなり迷惑です。

⑺なんでもできるとは言わない

これは先輩の言葉です。

 

僕が思うプロっていうのは「この壁に窓つけたいんだけど」っていうお客さんに対して「できるけど、西日が差し込んで使い勝手が悪いし、隣の土地には家がすぐに家が建って埋まっちゃうことになるからやめときな」って返すことであって、後先考えずに「ハイではこれがお見積もりです」ということではない

— ハイパーむとう(@masa_edw)


⑻生産性のマイナスを理解する

エンジニアの生産性は、人によって10倍も100倍も違うといいますし、実際そのとおりだと思います。そして生産性にマイナスに働く方がいるのも事実です。

設計・プログラムが適当すぎて、次に機能を作る人が全部作り直す、みたいな事になる場合があり、そういう仕事をする人は生産性にマイナスに働いています。マイナスに働く人は居ない方がましなので、そうならないようにしてください。

⑼成果物をすぐ見せる

優秀な方は作ったものをとりあえずでもすぐに見せてくれます。逆になかなか成果物をみせてくれない人もいます。いざ作業完了の期日になって見せてくる人もいます。そしてもう期限が無いのでこのままいこう、みたいな提案をしてくるのは最悪です。

方針が間違っていないかを確認するためにも、とりあえずすぐに成果物をみせてください。プログラムを書く人ならば、最低でも1日1回はPRを送りましょう。設計する人なら、雑でもいいので考えたことを文章なりなんなりでみせてください。

(10)作った機能に責任を持つ

機能をとりあえず適当に作って放置し、バグがでても他の方にまかせるといった方がいます。自分が作った機能は自分が最後まで面倒を見る気でいてください。自分が作ったものに責任を持てない人には、仕事はまかせられないです。

(11)技術に責任を持つ

新しい技術を採用するとき、なんとなく流行っているから、自分がやってみたいからだけで採用しないでください。採用するのならば、自分が一番のプロフェッショナルになって、なんなら他の人に啓蒙するくらいの気持ちを持ってください。

触ったことのない技術をいきなりプロダクションで採用するとかもやめてください。自分が詳しくないのにとりあえず新しい技術を入れて、まわりもよくわからずにシステムが崩壊するというのは、誰にとっても不幸せです。

(12)スピードとクオリティのバランスを考える

フェーズや開発箇所によって開発スピードが求められる場合と、クオリティが求められる場合があります。

お金を扱う機能、契約を扱う機能など、この機能はバグってたら絶対にダメだろうというところは、開発スピードを落としてクオリティを上げることに神経を使ってください。逆に管理画面とか、まあバグってても大丈夫だろうというところはスピード重視で機能開発するなどしてください。

(13)作る機能に興味を持つ

これから作るものに興味・関心をもってください。

ここはどうなってるんだろうとか、こういうパターンだとどうなるんだろう、実際に業務で使うときはどういう使われ方をするんだろうとか、想像して機能を作ってください。興味もなくとりあえず動けばいいや、みたいな考えで機能は作らないでください。

(14)難しいタスクにもトライする

いつも簡単そうなタスクだけをとって、難しいタスクにはチャレンジしない人がいます。難しいことをやって進捗がでなくなってしまったら印象が悪くなる、とかそういうことを気にしているのかもしれませんが、リーダーの方はちゃんと技術わかっているので、難しいタスクなんで時間かかったんだなとか理解してくれますし評価してくれます。簡単そうなタスクだけやってとりあえずたくさん仕事してる、みたいなのは、見る人が見ればわかるし評価できないです。

(15)優先順位を理解する

自分がやりたいタスクから着手ではなく、優先順位が高いものから着手しましょう。最悪できなかったときに、どうでも良い機能作っていて遅れたとならないように。

(16)集中力をあげる

プログラムを設計する、あるいはコードを書くには相当な集中力が必要なことを理解しましょう。集中力を上げる努力をする、そして作業の割り込みをできるだけ少なくする努力をしましょう。

(17)一日の集中力には限度があることを理解する

エンジニアが一日に集中できる時間には限界があります。

システム開発は神経を使う作業です。そんなに長時間ずっと作業できないですし、そういうものだとちゃんと理解して作業しましょう。徹夜して仕事したら、次の日は絶対作業効率が落ちますし、ダラダラ長いあいだ仕事していても意味ないです。

(18)長時間労働=仕事しているとは考えない

どういうわけか、いまだに長時間労働している人=できる人だと勘違いしている人がいます。長い間働いているようにみえても、実際全然成果を上げていない人もいます。海外だと長時間労働してる人は、時間内に作業ができないやつだと思われて評価低いですし、私もそう思います。

1日の集中力には限度があることを理解しましょう。ダラダラ仕事してるくらいならば、短い時間でさっと仕事を終わらせて、残った時間で新しい技術でも勉強するとか、そういう時間に使ってください。

(19)体調が悪いときは休む

体調悪いまま仕事しても成果はあがらないです。集中して作業しないと成果はでないです。休んでください。

(20)何事も効率化する

同じ作業を何度もするのならば、なにか効率化できないか考えてください。エンジニアは作業を効率化する人であってほしいです。

(21)タスクを持ちすぎない

タスクを持ちすぎないでください。なんでも自分で面倒みないと気が済まない、なんでもやりたがる、自分の能力を過信している、あるいは単純に人が足りていないのが原因かもしれません。タスクを持ちすぎると、すべてのタスクがうまくいかなくなります。他の人もそのタスクに振り回されることになります。

自分が処理できる限界を超えたタスクをもたないでください。タスクが増え過ぎたらアラートを上げる、他の人に渡す・まかせる、あるいはやらないときめてやらないなどして対応してください。やらないという決断ができる人は優秀な方です。

(22)小さなタスクは大きなタスクより時間がかかることを理解する

1時間でおわるタスクが8つと、1日かかるタスクが1つある場合、前者のほうが圧倒的に作業に時間がかかります。コンテキストスイッチにはコストがかかることを理解しましょう。

(23)成果を0から1、1から9、そして完成にもっていくまでの作業時間は線形ではないことを理解する

何もない状態から機能を作るのと、ある程度作ってからの作業時間はイコールではありません。そして完成にまで持っていくのはもっと時間がかかることを理解しましょう。9割完成しているからといって、作業時間はあとちょっとではありません。

(24)会議は人の時間を奪うということを理解する

何の考えも無しにとりあえず会議を要求するのはやめましょう。会議は他の人の作業時間を奪っているということを理解してください。どうしても会議が必要ならばアジェンダを決める、ゴールを決める、必要な人だけを呼ぶ、そして会議の時間を短くと決めましょう。会議を効率化する努力をしましょう。1時間以上の会議は集中力も続かず効率が落ちるので、無駄です。

(25)Y理論で管理する、あるいはされるエンジニアになる

驚くことに、事細かに作業を指示しないといつまで立っても作業を進められない、してくれないエンジニアは一定層います。細かく指示を出してくれないと何もできないと主張したエンジニアも過去にはいました。

あの人はいつも怠けている、仕事を命令しないとやってくれない、そう思われるエンジニアにはなってほしくないです。まわりの優秀な方も、マネージャーがマイクロマネジメントに走るようになると迷惑です。

自主的に行動できるエンジニアになってください。タスクは与えられるものではなく、みずから作れるようになってください。X・Y理論でいうY理論である職場であってほしいです。

2.設計面

⑴ビジネスを理解する

ビジネスあってのシステムだということを理解しましょう。機能を使う人の身になってシステムを作る努力をしてください。この機能はどういう使われ方をするのか、今現状はどういうフローで作業しているのか、あるいはどういう機能にしたら使いやすいのか、ビジネスサイドの業務を理解してシステムを作ってください。

業務系システムほど使いにくい傾向がありますが、多くの場合エンジニアが実作業を理解していないことが原因です。エンジニアにまかせて作った画面は使いにくい、そう言われないようにしてください。

⑵将来の事を考える

その場しのぎの機能を作らないでください。新しい機能を作るときは、将来どういう拡張がされるのか、どういう機能になっていくと思うかを想像してシステムを作ってください。

いきなりすべてを作る必要はありません。ただし設計・想像をする努力はしてください。一部のケースに対応できないためにすべてがひっくり返される、機能を全部作り直す、そういうことは往々にして発生します。一度動き出したシステムを変えるのは容易ではありません。優秀な方ほど、先を見越してシステムを設計・開発します。千里眼を身に着けてください。

⑶影響範囲を理解する

新しい機能を足す、あるいは既存の機能を改修するとき、どの機能にどういう影響があるのか、影響範囲を必ず洗い出すようにしましょう。

⑷保守にも手間がかかる事を理解する

新しい機能を何も考えなしに追加しないようにしましょう。作って動き出した機能の面倒をみるのも、コストがかかるのです。

⑸機能をシンプルに保つ

優れたシステムほど、驚くほど機能がシンプルです。条件分岐が多いシステムは品質が下がり、開発、保守、テスト工数が指数関数的に増加します。パターンを増やさない努力をしましょう。

⑹異常系に目を向ける

正常系よりも異常系の設計をする方が難しいです。そして異常系にどれだけ対処できるのか、設計できるのかがエンジニアの技術レベルの違いに現れます。

バリデーションが正しく書けるようになってください。自分の思ったとおりのデータを入れて動いた、だけでは不十分です。この項目は空のままサブミットしたらどうなるんだろうか、不正な入力値を入れたらどういう挙動をすべきだろうか想像できる人になってください。ユーザーは想像もしないような操作をするものです。

⑺テストの仕方を理解する

ソフトウェアテストの基本を学んでください。テスト設計ができないと、品質の高いシステム設計はできません。

テストとはとりあえず適当に画面を叩くことではありません。正しい要因(水準・因子)やシナリオを洗い出し、組み合わせを考え、さまざまなパターンを想定することです。テストもまともにかけない、できないエンジニアは技術レベルが低いと断言できます。

⑻本質を理解する

お客さんの言っている言葉を鵜呑みにしないでください。

「こういう機能が必要で、こういう画面にしたらいいと思うんだけど」。そういう提案をしてくる顧客はいますが、そのとおりに作る必要があるかは自分の頭で考えてください。お客さんの言ってることをそのまま作っても、多くの場合良いシステムはできません。うまくいかなかったとき、責任を顧客になすりつけないでください。自分から改善案を提案してください。

3.実装面

⑴サーバーサイドでのバリデーション

バリデーションは必ずサーバーサイドでも実施してください。クライアントサイドバリデーションは、UI・UXのために行うものです。データを扱うのはサーバです。画面でいくらブロックしても、不正な値が保存されてしまう状態ができてしまうのでは、意味がないです。

⑵何も考えずにコピペしない・わからないものをそのままにしない

ネットにあったコードをコピペして良しとしないでください。よくわからない機能を放置しないでください。自分で考えてコードを書いてください。

⑶開発時もログを見る

開発時にログを全く見てない人がいます。見ればエラーだとわかるし、N+1のようなパフォーマンス問題も見つけられます。そういう基本的な問題を見逃さないでください。

⑷割れ窓を直す努力をする

割れ窓理論、というものがあります。建物の窓が割れたままの建物を放置すると、その周辺の治安が悪くなるというものです。

システムも同じです。汚いコード・設計が入ると、その周辺の治安が悪くなり品質が下がります。窓を割らない努力をしましょう。そして汚いところを見つけたら直す努力をしてください。

4.コードレビュー

⑴レビュアーはテスターではない

コードのレビューを出す時、明らかに動かないコードを提出してくるエンジニアがいます。自分でちゃんと動かしていますか。コードを書き換えて、自分で”テスト”してからレビューに出してください。コードを書いて、一回も自分で動かさないままレビューを出すのは失礼です。レビュアーはテストする人ではないのです。最低限のマナーを守りましょう。

⑵強い言葉を使わない

「このコードは駄目だ」、「ひどい設計だ」、人の人格を否定するような言葉は避けましょう。いくら優秀な人でも、言動に問題あるような人には仕事を任せたくありません。その人の発言によって、まわりのモチベーションや生産性を大きく下げる可能性があるためです。

5.よりよいエンジニアになるために意識してほしいこと

⑴新しい機能を自分で作れるようになる

既存の機能は改修できるが、新規の機能設計・開発を任せると全くできない、あるいは品質が著しく低いものを作る方がいます。自分で新しい機能を生み出せるよう技術的な研鑽を積んでください。新しいものを作れないのならば、いつまでたっても仕事はまかせられません。

⑵昔から使われている技術を理解する

いまどきRDBは流行らない、Linuxの運用なんてマネージド・サービスに任せれば良い、そういって基本的な技術を理解していないエンジニアがいます。昔から使われている技術を勉強するモチベーションを持ってください。今なお使われているのには理由があります。基本ができていないエンジニアは、応用もできません。

⑶新しい技術を理解する

常に新しい技術をキャッチアップする努力を惜しまないでください。

ソフトウェア業界は技術の流れがとても早いです。去年流行っていた技術が今年は廃れている、よくあることです。重要なのは新しい技術を追い、なぜ流行っているのかを理解することです。毎日仕事が忙しくて新しい技術を追いかけていなかった、のではいつのまにか使えないエンジニアになってしまいます。

⑷巨人の肩の上に立つ

自分が最初に全く新しいアイデアを生み出すことは、ほとんどありません。必ず前例があるはずです。誰かが作った成果物を真似し、その上に新しいものを作ってください。巨人の上に乗れば、よりよいものを早く作れます。

関数型言語を勉強する

一度で良いので関数型言語を勉強してください。優秀なエンジニアは関数型言語の基本を理解しています。副作用のないコードを書く、命令的ではなく宣言的に処理を書く、正しく処理を分割する。関数型の基本を学ぶと、プログラムの設計・書き方も大きく変わります。

⑹一つの言語・技術を極める

自分の強みをもってください。浅く広く勉強するのも大切ですが、何の特技もないのではどういう仕事を任せていいのかわかりません。

⑺複数のプログラミング言語またはフレームワークを勉強する

1年に1つは新しい言語・フレームワークを学ぶ努力をしてください。優秀なエンジニアは、必ず複数の言語を勉強しています。他の言語から新しい考えを学ぶことができます。Rubyできれいなコードをかける人は、JavaだろうがPHPだろうが言語が変わってもきれいなコードがかけます。

デバッグ力を上げる

プログラムのデバッグができるようになってください。バグが発生したら、なぜそのバグが起きたのだろうかとすぐ想像できる力を身に着けてください。障害対応をするのは、大抵優秀なエンジニアです。

⑼技術力を貯金する

休みの日に仕事ばかりしないでください。新しい技術をみにつける努力をしてください。技術力は貯金が必要です。仕事と関係のない技術でも、必ずいつかプロジェクトの役に立ちます。

(10)人の評価を気にしない、当てにならない

あなたの事を一番分かっているのは、あなた自身です。人から評価されるように仕事をする、振る舞うよりも、自分が納得できる最高の仕事ができるよう、日々努力してください。

6.最後に重要なこと

楽しく仕事をする

仕事を楽しんでください。つまらない仕事、興味のない仕事を続けていても成長はできないし成果も上げられません。まわりにもその空気は伝わりますし、生産性・モチベーションに大きな影響を与えます。つまらないと思うのならば、潮時なのかもしれません。

今やっている仕事を楽しむ、興味を持つ、より良くしていきたいと思えるようになってください。

 


#SE

【ちょまど講演会まとめ】

日本マイクロソフトのちょまど様の講演内容が参考になったのでメモしておく


1.ネットの発展とアナログからデジタルへの移行

2.これにより、モノとの関わり方が所有から利用・体験へと変化

3.マネタイズの仕方も売り切りからサブスクリプション

4.いかに売るかでなく、いかに使い続けてもらうかが重要に

5.ユーザーが製品をどのように使っているか深く理解し、改善を続ける

6.そのためには、開発と運用を一体化するDevOpsの考え方が必要

7.Lean、Agile、DevOpsなどはあくまで型。何を作るかが重要

8.プラットフォームだけ作っても成功は難しい

9.成功するプラットフォーマーは自ら事業を行っている

10.自ら事業を行うことで、プラットフォームに必要な機能が見えてくる

11.プロダクトマネジャー(PM)はWhat、Why、Whenに責任を持つ

12.PMだけでなく、チーム全員がプロダクト志向を高めることが重要

13.自分のプロダクトを愛せるか。家族に誇れるか

14.ユーザーに実際に会って話を聞くことでプロダクト愛が深まる

15.どんな失敗もネタにできる鋼の心があれば大抵のことはなんとかなる(byちょまど)

 

#ちょまど講演

 

【論理的思考の正しいプロセス】

【フロー】

What

・何をすべきか?

・何を実現すべきか?

Where

Which

When

あるべき姿(事象の仮説)

How

Why

When

具体的方法論

【備考】

Howから考えると本来のあるべき姿が見えなくなる。安易な解決策から始めると対処療法になり、真の問題解決に繋がらない。ビジネスにおいて一番大切なのは問題を定義することである。

日本の( )ITエンジニアの特徴

1.わがままで、好きな仕事しかせず、いやなことはやらない

2.成果が出なくても自社の一般職より高い基本給がもらえるので、周りの士気を下げてしまう

3.人格的に問題があり、他者と協力関係を築けず、結果として仕事ができていない

4.自分の仕事を守るために、わざと仕事を引き延ばしたり、効率が悪いやり方をしたりする