Toru Ishihara
·
フォロー
Senior Software Engineer5月7日
日米でプログラマーしていますが、日本のIT企業で一番欠けている人材はマネージャーだと感じています。学歴や文系理系関係なく、リーダーシップを持ったマネージャ人材が不足していると感じました。学歴が高いだけの人が、無理して部長をやっている感じがしました。
アメリカでは、別の成功した会社と比較したマネージメントをします。ある会社では、ソースコードの可読性を重視して成功しているので、自分の会社でも重視しようとか。ある会社では、技術力の高いエンジニアの給料を上げて成功した。初心者エンジニアを増やすと現場が混乱する。ジュニア・シニア比率が大切、などなど。
アメリカでは、部下のエンジニアに負担をかけると、すぐに辞めて転職していきます。部下の転職が多いとマネージャーとしての評価が下がるので、部下エンジニアにも気を使っています。そのため、上司部下とのバランスを取った、リーダーシップあるマネージャーが多いです。学歴が高くてもリーダーシップがなく威張ってばかりのマネージャーは解雇されています。
日本のマネージャーは、顧客を怒らせない事と、部下に残業させる事しかしていない傾向があります。威張っている人も多いです。部下エンジニアの事を考えている様子は、あまりありません。マネージャーは、正社員の終身雇用なので、解雇される事もありません。プロジェクトに失敗しても、「全員残業した頑張ったのですが」との言い訳ができます。日本のIT企業では、マネージャーに向いていない人が無理してマネージャーをしている感じです。
閲覧数:1,956回53件の高評価を見る1件のシェアを表示
Hideki Ikemotoさんのプロフィール写真
Hideki Ikemoto
·
フォロー
愛媛でフルリモート5月8日
職種としてはプロダクトオーナー(PO)、あるいはプロダクトマネージャーです。
まずウォーターフォールと請負契約は論外です。なので多くの場合、アジャイル開発で準委任契約になります。なので今後はこれを前提として話します。
Hideki Ikemotoさんのプロフィール写真
Hideki Ikemoto
愛媛でフルリモート3月4日
「これ損するのに何でみんなやってるの？」ってことは何ですか？
ウォーターフォール開発ですね。完璧な計画を時間をかけて作って大失敗なんてものを選ぶ気持ちが分かりません。アジャイルでなくても小さくやればいいのに。
Agile is Better than Waterfall Projects (Standish Group Report 2020)
The 2020 Standish Group Chaos Study shows Agile Projects are 3X more likely to succeed than Waterfall projects, and Waterfall is 2X more likely to fail.
https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/
閲覧数:169回8人が高評価
Hideki Ikemotoさんのプロフィール写真
Hideki Ikemoto
バックエンドエンジニア4月27日
「あ、多分この仕組みを考案した人は地獄行き確定だな…」と思う仕組みはありますか？
ITシステム開発における「請負契約」ですね(「受託開発」ではありません)。
元々請負契約は一般的ではなく、委任型契約が主流でした。この記事が2007年で、次のように書かれていることから、1987年頃までは委任型契約が多かったようです。
約20年前までは圧倒的に委任型の契約が多く、請負契約は一般的な契約形態として普及しなかった。
第2回 ソフト開発の3つの契約形態、成果物責任の免責が不可欠
システム開発契約には、「請負型契約」「委任型契約」「混合型契約」の大きく3種類があり、受注者であるソリューションプロバイダには、それぞれメリットとデメリットがある。現在、受注者側が成果物に責任を負う請負契約が主流だが、契約時には、請負責任に関する免責事項を明確にしておく必要がある。
https://xtech.nikkei.com/it/article/COLUMN/20070601/273310/
代わりに台頭したのがSIerです。
その後「SI（システムインテグレーション）契約」と呼ばれる、ソフト開発の請負を含むシステム構築請負契約が誕生した。
SIerが主流になることで、発注者の丸投げ、多重下請構造、オフショアといった業界を作り上げ、IT業界のみならず、日本の全ての業界を巻き込んで競争力を低下させました。
Hideki Ikemotoさんのプロフィール写真
Hideki Ikemoto
· 2月25日
IT業界とSI（システムインテグレーション）業界とはまったく別物という話を聞きましたが、どのように違うのでしょうか？また、何故そのような違いが生まれたのでしょうか？
いわゆる「Web系とSIer」という分け方になると思いますが、一言でいうと、現代と石器時代くらい違います。そして違いが生まれたのは、インターネットが業界を2つに分け、統合したからです。以下正しくないところもあると思いますが、自分の感覚を書きます。 まず一般人にインターネットが普及し始めたのが1995年頃です。そしてこの前後にインターネット関連の会社の多くが創業しています。例えば、Amazon.comは1993年創業です。 そして、1998年に「オープンソース」という言葉が生まれ、Netscapeが自社のコードを公開し、IBMが当時「おもちゃ」だったLinuxをサポートし始めました。 この前後から、インターネットの期待が高まりました。しかしこの時点ではインターネットというのは「おもちゃ」でした。 その結果、ドットコムバブルが生まれ、多くの企業が生まれ、バブルが弾けて、多くの企業が消えました。オープンソースもその波に巻き込まれました。その件はこの記事が読み応えがあります。 まだインターネットは「おもちゃ」だったためドットコムは弾けたのですが、生き残った企業は伸びていきました。 受託開発業界はこれらと協調しつつも、また別の流れがありました。ウォーターフォール開発ではうまくいかないことから様々な開発手法が生まれましたが、その一つがエクストリーム・プログラミング(XP)です。 XPは今では広く受け入れられていますが、少なくともこれが生まれた1999年頃は「おもちゃ」でした。しかし、これらの開発手法からアジャイルソフトウェア開発宣言ができ、現在では広く普及しています。 そして2005年頃、Web 2.0という言葉が生まれました。SNSやブログなどの「おもちゃ」でしたが、技術的、社会的にはむしろ今では当たり前になっているものも多いです。 この時点ではWeb業界と、それ以外の業界は分断されていました。ECなどは普及していましたが、まだインターネットは「おもちゃ」で、リアルの「ビジネス」とは異なる、そんな認識でした。 ウェブ進化論という本では『ネットの「こちら側」』と『ネットの「あちら側」』という表現をしていましたが、それはこの「ビジネス」と「おもちゃ」の分断を表しています。 この辺りまでが分断の歴史です。 しかし一旦は分断された『ネットの「こちら側」』と『ネットの「あちら側」』がまた1つになり始めました。その要因はいくつかありますが、特に大きく、分かりやすいのが、クラウド、SNS、そしてスマートフォンです。 SNSは負の影響も大きかったり、日本だとガチャゲーが問題になったりしましたが、SNSやスマートフォンによって、リアルとネットの境目が曖昧になってきました。 そして、2010年代からはSaaSが本格的に普及してきました(最近ではX-Techと呼ばれたりしますが)。クラウドやスマートフォン、あるいはSNSを使ったマーケティングが普及しました。その結果として、リアルのビジネスと、インターネットが統合されました。 そして、インターネットとビジネスが統合された結果、比較できなかった2つの業界が比較できるようになりました。これがWeb業界とゲーム業界ならあまり比較されなかったでしょう。 Web業界は翻弄されつつも、様々な武器を手にれています。技術だけではなく、組織文化も変わってきました。技術だけではなく、人を大切にする、孤独な作業ではなく、チームで協力する、そのようなスタイルが当たり前になってきました。 一方でずっとリアルにいたSI業界はオンプレ、ウォーターフォール、上下関係の世界です。現代と石器時代くらい使う武器が違います。言葉も通じません。 しかし、IBMが「おもちゃ」だった時代からLinuxを採用し、日本企業もオープンソースに貢献してきました。しかしこれだけ差がついてしまった。自分はその原因は世代の違いだと思っています。しかし世代と言っても単に若いかどうかではなく、ある年代を境にした、価値観の違いです。 それは、楽しいことを良いと思えるのか、そう思えないのか、その違いです。Linusの伝記のタイトルは英語で "Just for Fun" ですが、面白いことが良いこと、そういう人たちかどうかです。 そして、その境目は1974〜1976年生まれあたりにあります。Web 2.0のときにはナナロク世代という言葉がありましたし、デジタルネイティブの定義でも1975年が境目とされています。 この世代は子供のころにファミコンで育って、大学時代にインターネットに触れた、楽しいことと良いことが直接結びついている世代です。もちろんその後の世代も同じです。 IBMは「おもちゃ」だった時代からLinuxを採用しましたが、あくまでも「ビジネス」の会社として、「おもちゃ」を使えるようにする、そんな文化でした。「エンタープライズ」の方が価値がある、そのような価値観でした。 しかし「おもちゃ」の方がシンプルで価値がありました。それが自然に分かっている人と、全く分からない人、そこの断絶がもたらした結果だと思っています。
諸悪の根源と言ってもいいくらいの所業です。
閲覧数:2,004回36人が高評価シェア数: 3件1件のコメント
そして、プロダクトオーナーはユーザー企業側の人でないと務まらないと結論が出ています。この図ではこれまでは左上の「丸投げ」でしたが、右下の「◎」になる必要があります。
IPA の アジャイル開発版「情報システム・モデル取引・契約書」｜木下史彦｜note
IPA から アジャイル開発版「情報システム・モデル取引・契約書」が公開された。
https://note.com/fkino/n/n40d038c359ff
気軽にクリエイターの支援と、記事のオススメができます！
じゃあプロダクトオーナーって何かというと、一番近いのはトヨタの「主査」です。プロダクトの「社長」ですね。
いまや世界の常識！？トヨタの成功を支えた○○制度とは | カーデイズマガジン
トヨタは、昔からユニークな社内制度や手法を採用して成功を収めてきました。その社内制度や手法は他のメーカーにも取り入れられ、いまや「世界の常識」となっているものも沢山あります。
https://car-days.fun/blog/kuruken/689
トヨタは、昔からユニークな社内制度や手法を採用して成功を収めてきました。
また、その社内制度や手法は他のメーカーにも取り入れられ、いまや「世界の常識」となっているものも沢山あります。
今回はそんなトヨタの社内制度に関する問題です。
- 2級(第2回)
トヨタの生産方式として「かんばん方式」が有名ですが、1953年、トヨタが他社に先駆けて導入した”製品開発に関する社内制度”は、次のうちどれですか？
①OEM供給制度
②主査制度
③期間工採用制度
④風洞実験制度
どれもトヨタが先駆けて採用していそうな制度ですね。
それでは、正解と解説を確認していきましょう。
社長と同等な権限を持つ、チャレンジングな任務！
トヨタは約60年前から、「主査制度」というものを採用しています。
これは、1人の製品企画室主査に、担当プロジェクトに関する企画、開発、製造・販売の全てを委ね、全決定権と全責任の所在とを一元化する製品開発体制を意味します。
簡単に言うと、「1人の主査に1つのプロジェクトの全権限と全責任を持たせる」ということです。
このような体制をとることで、製品に対するビジョンやコンセプトを、企画、開発、製造・販売など、全てのプロジェクトメンバーと深く共有できると共に、各部署との折衝を効率よく解決できるのです。
トヨタの初代会長だった豊田英二氏は、主査制度について次のように語りました。
「主査は製品の社長であり、社長は主査の助っ人である。」
現在、この主査制度は他の自動車メーカーも採用しており、自動車業界では主流の組織作りとなっています。ということで、正解は②主査制度でした。
主査とは、なかなかチャレンジングで名誉ある役職ですね。
続いて他の選択肢の解説も参考にご覧ください。
①OEM供給制度
「OEM」とは、「Original equipment manufacturer」の略。
例えば、自動車メーカーAに軽自動車の販売ランナップが無いい場合、他の自動車メーカーBから供給を受け、自動車メーカーAの自社ブランドとして販売することをいいます。
自動車メーカーAは、販売利益率は低いものの、自社の製品開発コストが削減できるというメリットがあります。
③期間工採用制度
自動車の生産工場で生産ラインに入り、組み立てなどを行う作業員を契約社員として採用する制度のことです。
④風洞実験制度
風洞実験は、目に見えない空気の流れを定量化、可視化することにより、その自動車が受ける空気力の測定を行う実験です。この実験には、制度という概念はありません。
異業種も注目するトヨタの経営方針
トヨタの「主査制度」は、実は自動車メーカーではない他の業種の組織作りを取り入れたものだそう。この視点が大当たりし、トヨタを成功へと導いたのでした。
そんなトヨタの取り組みは、アップルやグーグルなどの企業も注目し、参考にしているそうです。
職種としてはプロダクトオーナー(PO)、あるいはプロダクトマネージャーですが、必要な能力はまず、プロダクトに対する情熱です。
あとはプロダクト思考と、プロジェクト思考の違いを理解することです。
tomoima525's blog
Androidとか技術とかその他気になったことを書いているブログ。世界の秘密はカレーの中にある！サンフランシスコから発信中。
1990年代に勤務していたISP（インターネットサービスプロバイダ）では、SIerを介さずに必要な機材をベンダーから直接購入したり、SIerから購入することはあっても、開梱からリリースまですべて自前でやってました。当時のエンジニアとしては「自分でやりたいんだから何もしないで配送だけしてくれればOK」。ISPだけでなくキャリアでも「自分たちでやる」のが当然でした。
2010年代に勤務していたベンダーでは、顧客にISPやキャリアが多数ございましたが、納入した機器の設定はもちろんのこと、その機器を使用するシステム全体の提案から設計まですべてベンダー側でした。
20年ですっかり変わってしまいました。非IT企業だけでなく、IT企業も変化しました。
社内で育成すべきIT人材というか、ITが好きな人が社内にいてくれればよいかと。そしてその好きを突き詰めることを許容する環境を、会社は与える。
現在のようになってしまったのはITに夢を見る人がいなくなったのが原因かな、と個人的には感じています。
関連する質問
日本はIT人材が不足していると言われています。ここでいうIT人材とは、開発ができる人材のことでしょうか？それともIT商材を扱える営業職なども含めているのでしょうか？
アメリカでは中小でも企業にITの部署や人材を確保しているので、外注するにも丸投げは無いと聞きました。正しいですか？日本ではIT企業以外の中小にITの人材が少ないのはなぜでしょうか？
ITエンジニアの求人に「SIer出身も多数活躍しています」と書かれています。SIerってそんなに印象が悪いのでしょうか？
Shin Kusanagiさんのプロフィール写真
Shin Kusanagi
·
フォロー
元Senior SE Manager (2016–2019)1年前
この問題は、業界で働くものにとってはいつか解決されるべきだと思いながら、ほんの少しづつしか変わってこなかった問題です。日本が先進国ではダントツと言っていいほどIT後進国になってしまった理由は、IT人材を内部で育てずSIerに依存し、IT投資をコストと見なす風潮が長く続いたからです。
その証左は、以下Gartnerが発表している各国のクラウドの採用率でもわかります。日本は、アルゼンチンやインドネシアと同じレベルにあり、その成長率も低いままであることが予想されています。クラウド利用がITの全てではないとも言えますが、従来のモデルに固執しクラウドへの移行に対する抵抗が強いのは見て取れます。SIerとしては、自らの取り分を減らすことになるクラウドへの移行に消極的であるのは、ある意味当然ですので、顧客側のSIer依存が強固であると考えていいと思います。
なぜこうなってしまったのかというと、政治家も企業人も含むこの国の権力者達が、IT投資を重要なものだと考えてこなかったことが一番の理由だと私は考えています。ITの進展により自動化を推進し、人力での作業を減らし、企業価値を高めるという話をすると、「人力減らしちゃ駄目なんだよ、その人達やることなくなっちゃうじゃない」、と今まで何度も何度も言われました。雇用を生み出すのが企業の社会的責任だという信念を持つ日本の企業にとっては、人力を減らすというITの考え方はなかなか受け入れられないのかもしれません。（菅政権になってから、少し流れが変わってきたようにも感じますが。）
その結果企業ではITへの投資、それもまずはIT人材への投資が立ち遅れました。IT投資を進め業務を改革するには、考えてみれば企業内部で人材を育成する以外にないのです。驚くほど時代遅れの業務システムが日本中で未だに作られ続けている理由は、SIerとしては以前のまま変えないほうが儲かるからです。クラウドにしたりすると取り分が減るからです。これは当然のことでありSIerの責任ではなく、何がいいのか判断することができない企業側の問題です。その企業に何が今必要か、という判断ができる高度なIT人材がいないために、時代に合わないシステムがそのまま納入されてしまう。こういう話を見聞きするたび、とても残念に思います。
さて、長くなりましたが、回答です。企業の中のIT人材に必要なものは、まずはその企業の未来に対する思いです。その企業がどこに進むべきか、ITを活用してその企業の未来にどう貢献できるかを考えられる人材であることが大切です。技術や知識は、素養さえあればなんとかなるんじゃないかと思います。自分でセットアップし、自分でプログラミングすることも厭わず、会社への思いがある人。そういう人と一緒に働けると、楽しいだろうなと思います。
Chat Katzeさんのプロフィール写真
Chat Katze
さんのプロフィール写真
Chat Katze
·
フォロー
ネコねこ🐱1年前
関連
どの会社でも通用する人材とはどんなひとどんな人でしょうか？
私がそうですね．慶應はビジネスマン養成所として知られていますが，特に三田キャンパスでは経済，法律，政治，商，文というようにビジネスに直結した学部が集まっています．(文は違うだろと言われそうですが，外国語あるでしょ)
塾生の頃考えたのは，これからの時代に活躍するには，コンピュータ，外国語，会計，法律が必要だと考え，他学部の講義もジャンジャン出席したのです．それにSFCに入り浸ってUnixワークステーション使い倒しましたし．
すると社会に出てどうなったか，どんな会社に行ってもいきなり活躍できるビジネスロボットの一丁上がりですわ．古狸が威張ろうとも関係なく，学力で仕事進めるのでミスも非常に少ない．
Iura Masahiroさんのプロフィール写真
Iura Masahiro
·
フォロー
2月23日
関連
なぜ日本のIT業界はいわゆる上流工程（要件定義など）に集中し、実際のコーディングを重要視しないのですか？
大昔、
リチャード・ストールマン - Wikipedia
との酒宴前に周りの人間から注意されたことがあります。
「SE とは言うな」「システムエンジニアは日本語、ソフトウエアやサービスエンジニアが適当なところ」
ストールマンはスーパーハッカーです。上流も下流もないのです。自分で資金集めからプロジェクトの立ち上げ、方針設定、エンジニア雇用、コーデング、配布なども行います。
上流下流などアメリカではありません。
リーダーやマネージャーなどはあります。
日本の場合、SE といえばソフトウエアエンジニアより高い工賃を取れるのです。プログラミングもできない人間が上流工程を行うことも多いのです。
ソフトウエアは全てシステムです。システムエンジニアは意味不明です。
miki takeさんのプロフィール写真
miki take
·
フォロー
詳しい分野:英語(言語)1年前
関連
経済産業省のIT人材の需給に関する試算によると2020年時点で30万人不足しているようですが、Web系企業への転職が一向に簡単になりません。Web系企業は具体的にどんな人材を欲しているのでしょうか？
・社内調整力の高い人。コミュニケーション能力が高くて、気難しい社員や、気難しいクライアントとも粘り強く交渉してまとめ上げることができる人。
・クライアントの無茶ぶりを論理的に説明して、なんとか工数を増大せずにクライアントの満足度を高める人
例）訳の分からない話ばかりするクライアントに対して、「つまり、言いたいことって○○ですよね。」と課題解決をしながら、その課題解決にかかる作業工数を最小化できる人。
WEB系の開発技能保有者はたくさんいるので、別にわざわざ正社員で雇いたいとは思わないでしょう。それは外注してもよいです。正社員に求めているのは、交渉力や人間関係調整力やリーダーシップ、課題解決力とかその部分です。この能力と開発能力の両方を持っていれば、有能です。
林 裕隆さんのプロフィール写真
林 裕隆
·
フォロー
地球人8ヶ月
関連
IT系の企業で「社員のスキル」を会社が把握する際に用いる、なにか体系だてられた手法はありますか？
わたしは国内外様々な企業で働いてきましたが、体系立てられた手法が存在します。
·
フォロー
ネコねこ🐱1年前
逆にアメリカの会社は社内のアマチュアが情シスやってるから、ぬるい仕事してんなぁと呆れましたけどね。サーバーもWindowsしか使っちゃダメとか。おいおい。
ハードウェアもソフトウェアも自由自在に扱うことができて、トラブル時にサッと直してしまえる異能はOJTで育成なんかできないよ。
MORITSUNE Hikariさんのプロフィール写真
MORITSUNE Hikari
·
フォロー
フリーランスエンジニア (2016–現在)11ヶ月
自分の所属する会社の事業の本質と経営者の意向を深く理解し、
事業を発展させる上で発生する課題に対して、ITを使った課題解決手段を取りまとめることができ（課題の抽出まで出来れば尚よし）、
その手段を実現するために最適なITベンダーを調達でき、
そのITベンダーの開発作業を適切にコントロールでき、
無暗に安値で買いたたかず、ITベンダーと自社とが（ズブズブではなく）Win-Winな関係を構築でき、
ITによる課題解決手段の導入がスムーズに行くよう、社内調整ができる人、
でしょうか。
という人がそもそもいなければ、ほかの人を育てようもないでしょうから、まずは外から連れてきた方がいいですね。
もちろん一人で全部できる必要はないです。部署としてできれば。
Tanino Kenichiさんのプロフィール写真
Tanino Kenichi
·
フォロー
プログラマ (1996–現在)1年前
その意味の「IT人材」は最低限、以下の工程はこなせないといけないと思います。
プロジェクト計画策定
要件定義
WBS記述
システム仕様書
システムテスト設計
大抵の非IT企業内の人は業務要件、つまりやりたいことしか頭にないでしょう。
でも「IT人材」は業務要件だけでなく、機能要件、つまり何をどうコンピュータに落とし込むか、あるいはしないか、は理解しないといけないと思います。
そのためにはどのようなプロジェクトかを明確にし、実現すべき要件を定義し、作業を分解し、システムが持つ仕様を定義し、テストを行い正しいものであることを証明できる必要があります。
もちろん運用もするので、その設計とかもしますが。
と言ってる私は、近年この仕事してないですがね。。
考えてみて欲しいのですが、他国はいざ知らず日本はここ数年ずっとデフレに悩まされ、そのデフレ経済を前提とした社会構造や文化や価値観が根付いてきているわけです。一方で、グローバル市場にはデフレでないどころか昇り龍が如く成長を続けインフレも進んでいる国々が少なからずあります。そういう国々で、デフレの国の価値観を体現するようなサービスが流行ると思いますか？ 僕が考えたのは、そういうことです。
（※僕自身はベンチャー・スタートアップの経営には全く詳しくなく、況してや経営者としての経験など何一つないので、素人の単なる思いつきに過ぎない意見であることを最後にお断りしておきます）
閲覧数:1.1万回176件の高評価を見る3件のシェアを表示
Ichikawa Masanori
さんがリクエストした回答
Taiyo Nakashimaさんのプロフィール写真
Taiyo Nakashima
·
フォロー
セント・ローレンス・カレッジ（オンタリオ州、キングストン）卒業3年前
関連
非IT人材からIT人材になるには何をすれば良いですか？
今、ML/AI関連が空前のブームとなり、圧倒的な人手不足が起きています。
正しいスキルを持つ人であれば、ブームが「定着」に変わっていく向こう20年は仕事には困らないでしょう。
私のケースを紹介します。私はこれまでいわゆる「IT業界」に務めたことはありません。（WEB制作などにも一部関わりましたので完全に無縁だったわけでもありませんが）
AIについて個人的に興味がありましたので、 datacamp.comなどのオンラインサイトで2017年、39歳から独学で勉強を始めました。Rstudio、H2O、Keras、Tensorflowなどの無料で使える素晴らしいOSSソフトを使って学習機を作ったりや可視化の手法で遊びまくりました。
昨年、会社の空き時間で業務データを適用した需要予測、ログデータ分析などを行い、既存事業の収益強化案をプレゼンした所、トントン拍子で新規事業部の開発マネージャーを任される事になりました。
AIどころかITそのものから遠い、古臭い業界です。
・
これは全てタイミングが良かったのだと思っています。
ちょうど会社としてAIについて大小様々なコンサル会社さんからプレゼンを受け、実際見積もりも取っていた所だったようですが、それらのどこよりも中身が明確で業務に即しており、しかも「完成」していた事に代表含めてかなり驚いていたそうです。
上記のコンサルさん達は、完成がいまいちイメージしづらいPoCレベルの提案で1000〜2000万以上の見積もりが来ていたと聞きました。PoCだけで
なく、「AWS上で実働しているモデルまで完成している」「内製なので追加費用実質ゼロ使える」とくれば使わない理由は少ないと思いますが、迅速に立ち回って手配して頂いた上司同僚と経営陣には心から感謝しています。
着手から半年でサービスインまで行い成果は今のところ順調です。数字についてもじわじわ積み上がって行っているので現時点では成功と捉えています。
今は業務の時間は100%開発のみをやれています。面倒な「客先プレゼン・仕様書作成」などを一切やらないで済んでいるのは「社内」で動いている強みです。面白いデータが取れたら社長を呼んで見せたらキャッキャッと喜んでくれるのがなにより楽しいです。
・
私は小学生の頃からコンピュータが大好きでしたが、いわゆるITゼネコンを筆頭とする業界の構造には疑問がありましたのでSE，SI的な仕事に進まずITとほぼ関係ない(と言われる)エンタメ業界界隈に努めてきました。
ですが技術に関しては単純に「楽しい」ので読んだり実装したりは、趣味の範囲で触れ続けてきました。これまでの業務経験と趣味、全てが今の仕事で繋がったと思っています。
Linkedinなどのサイトにも昔から登録しているのですが、今の業務をプロフィール登録してからのスカウトメールの多さには本当に驚いています。（今の会社と社長が大好きなので転職は一切考えていませんが、誘われて悪い気は当然しません）
「誰かがあなたをIT人材にしてくれる」なんて事は今後も絶対に無いと思います。
ですが同時に、誰もあなたのITスキル向上を止めることは絶対に出来ません。
まずはお一人で、出来ることから楽しい事を見つけられるのが近道なのかなと思います。完成したら、今の会社でも、外のどこかでもそれを「見せてみる」事が最も重要です。
良いスキルでしたら必ずそれを必要とする人がいますよ。
・
とはいえ本当に一人でしたらつまづいたりもすると思います。色んな「もくもく会」が日本各地で開催されていますので気軽に参加してみると良いと思います。
私の場合は、初めて参加したAI開発のトークセッションでものすごく勇気をもらったのが、今に繋がったと思います。あの時の方には感謝してもしきれないです：
Q:「自分みたいな中年でも、今からAIの勉強初めて遅くないですか？」
A:「海外では40代50代で新しい事を始めるために大学に入り直すのなんて当たり前の風景。39歳からAIの勉強、遅いなんて事は全く無いと思います」
あの時の講師の方に心からの謝意を表して、締めさせて頂きます。
・
PS. もし今IT以外の業界にお努めでしたら、「ドメイン知識」はAIをやる上で圧倒的な強みになりますので、変に悲観せずまずは今の業界を極めることを考えるのも全く悪くないと思います。最新のIT技術は誰もが無料で触れられるものですのでどこかに所属する必要性は薄いです。
AI関連技術はFAX機やスプレッドシートのように誰もが使える一般的な技術として普及すると思います。その時に「備えておく」「回りより少し早く動き出せる」事が出来ればかなりのヘッドスタートが切れると思います。
閲覧数:5,931回45件の高評価を見る1件のシェアを表示
SOL - Scribble Osaka Lab - スクリブル大阪ラボさんのプロフィール写真
SOL - Scribble Osaka Lab - スクリブル大阪ラボ
·
フォロー
詳しい分野:英語(言語)2年前
関連
優秀な人材を集めるには国内だけにとどまらず、海外人材にも目を向けなければと思いますが、海外からの人材が日本で活躍するために私達にできることはありますか？
日本で働くにはまず日本語を習得してもらう、という私たちのスタンスを捨て去る必要があると感じています。
これまでは日本市場はマーケットサイズが十分に大きく、日本語を習得してまで参入したいほど海外から魅力的に映っていたかもしれませんが、これからの労働人口の減少に伴い、世界でのプレゼンスが落ちていくのは不可避です。
そんな中で、日本でビジネスしたかったらまず日本語を覚えてくださいというスタンスでは通用しません。
日本人が日本語だけで国内の閉じたマーケットの中でビジネスし続けるのであれば問題ないかもしれません。ただその市場は徐々に縮小しつつあります。
海外から優秀な人材を招き入れたければ、日本を、少なくとももっと英語でビジネスしやすい環境に作り替えていく必要があります。
一方で、海外の人材で、日本で働きたいという希望を抱いている優秀な人材は数多くいます。とくに東南アジア諸国において。やはりさまざまなインフラが整っていますし、治安も良くとても暮らしやすい。そして一番はアニメ！日本のアニメのパワーは絶大です。
幼少期から日本のアニメやゲームに慣れ親しみ、日本のファンになってくれている。これらのソフトパワーがまだ威力を放っているうちに、日本をもっと多様性に富んだ人材の力を取り込める社会に作り替えていくことができれば。
コロナウィルスや気候変動など、さまざまな不確定要素が増え、グローバル化の波も何かのきっかけで簡単に逆方向にねじが回り出します。ただ観光ニーズのインバウンド客だけを取り込むのではなく、日本で働いたり起業したり、日本に根付いて活躍してくれる人材をもっと増やしていかなければ本当の意味での国際化は果たせません。
翻訳ツールの発達により、コミュニケーションのハードルは格段に低くなりました。あとは私たちが世界標準で、海外の人材ともっとコミュニケーションを取ろうと努力することが第一歩かなと思っています。
閲覧数:497回7件の高評価を見る1件のシェアを表示
Tsuji Ryutoさんのプロフィ
Tanino Kenichiさんのプロフィール写真
Tanino Kenichi
·
フォロー
プログラマ (1996–現在)2年前
関連
日本でIT人材が育たない理由は？
トライアンドエラーという概念自体認めないぐらい、間違いを恐れる国民性だからだと思います。
昔SIerの時も、確実に成功することだけをするよう、失敗しそうなことは先にしないようにしていました。
何かをして失敗すると、とても怒られます。それより何もしない方が、その方がよく考えてるとみなされて、怒られない。そういう国民性があるように見えます。
IT系は基本やることはすべて失敗の可能性があります。なので失敗の可能性がかなりあるとしても、やってみないと何も始まらないです。
でも日本の会社の場合、成功の可能性が高くないと始めないので、いつまでたっても始まらないという悪循環に陥ってると思います。
始めないからIT人材も育たないのでしょう。
そして、この国民性は強固なので、ちょっとぐらいトライアンドエラーをしてもいいよという人が、むしろ失敗を絶対認めない人だったりして、闇が深いような気がします。
Piyomaru Naganoさんのプロフィール写真
Piyomaru Nagano
·
フォロー
インフラ1年前
をやっていない」という点です。
（Pkg203 - 投稿者自身による作品, CC 表示-継承 3.0, File:Lyft Pink Mustache.jpg）
見方を変えて、既に成功した企業たちを見てみましょう。例えばUberやLyftは「自分で車を運転しなくても移動できるプラットフォームがあったら良いな」という潜在的かつ世界的に見ても共通の人々の欲求を形にしたスタートアップたちです。彼らの着目点が正しかったことは、彼らの手が及ばない中国本土でも滴滴、シンガポール含む東南アジアでもGrab、といった同様のライドシェアスタートアップたちが成功したのを見れば良く分かります。
民泊におけるAirbnbもそうですし、電動キックボードのBirdも然り。「普通は皆が自分で持っているものを使うけれども、他の人が使っていない時に代わりに気軽に使えたら良いな」という、ある意味世界共通で普遍的な人々の欲求を形にしたスタートアップが成功しているように個人的には感じています。
言い方を変えると、「普遍的に世界中の人々の欲求を満たし得るものを先駆けてプラットフォーム化してしまえば、グローバルでも成功できる」ということなのだと思います。その意味ではTeslaなんて最たるもので、世界中の人たちが憧れて買ってくれるモノさえ作り続けられればずっと赤字を垂れ流していても良いわけです（投資家が逃げない限りは）。
しかし、日本発のベンチャーやスタートアップというとどうしても「まず日本で成功してからその後海外へ」というルートを例外なく辿っているように見えます。これでは、日本で成功するまでの間にどんどん日本に特化というかジャパナイズというか過剰適合してしまい、成功を収めた頃には全く環境の違う国と地域だらけのグローバル市場に適応できない小回りの利かない組織になってしまっていることが多い印象があります。USに進出して失敗した日本のベンチャーやスタートアップの話題は覚えている範囲でも十指に余るくらいありますが、おそらくそういうことなのでしょう。
とはいえ、これは日本の投資家や出資者の側にも問題があるのかもしれません。「まず日本で成功しない限りはグローバル進出のための資金は出せない」と言われたら、ベンチャーやスタートアップの側もまずは日本で成功するために必死に過剰適合するしかないでしょう。そして日本で成功することには、もはやグローバルでは成功できない体質になっているというわけです。
ちょっとール写真
Tsuji Ryuto
·
フォロー
人事や組織の課題を解決する仕事更新日時:2年前
関連
面接で優秀な人材かは見抜けないと証明されていますが、なぜ企業は面接を続けるのでしょうか？
面接で優秀な人を見抜くことは確かに難しいです。ただ、会社に合う人か合わない人かを見抜くことは比較的可能です。明らかに合わない人を入社させないこと、それだけでも面接をやる意義は大きいのです。
面接には三つの原則があります。
できるだけ自社に合う人を採用する。
絶対に自社に合わない人を採用しない。
迷ったら最後は採用しない。
これを踏まえて、１の中でできる限り優秀な人（優秀と思われる人）を採ることが重要であり、２や３であればどんなに優秀でも（優秀に見えても）採らないということがさらに重要になります。「優秀かどうか」は最も高い優先順位ではないのです。
その理由は、応募者が、自社が目指していることに共感してくれる人か、社風にマッチするか、社員たちと馴染めるか、逆に社員たちが仲間として受け入れてくれるか・・・この辺がズレていると、いくら優秀な人材であったとしても、入社しても周囲に迷惑をかけるか、結局長く持たずに離職してしまうことになるからです。こういうことは面接を通じて、実際に会ってよく話し合ってみないとわかりません。
また、WEBで回答させる適性検査が普及し、精度も上がってきていると思いますが、なりすましの問題（本人ではない人が回答していてもわからない）は常に懸念がある状態です。
こうした技術的な問題がクリアになっていないこともあって、「一度も会ったことがない人を一緒に働く仲間として迎え入れるのは気持ち悪い」と大半の人が思っていると思います。
ということで、企業が面接を続ける理由は2点。明らかにダメな人を入社させないためと、会ったことがない人を仲間として迎え入れることに対する抵抗感が根強くあり、これを払拭するような技術が確立されていないためです。
閲覧数:1.5万回75件の高評価を見る1件のシェアを表示
西村 颯馬
さんがリクエストした回答
水谷 哲さんのプロフィール写真
水谷 哲
·
フォロー
SCMコンサルタント MDMコンサルタント11ヶ月
関連
なぜIT業界ではモノができるのが遅いのでしょうか？
ITが製造だと思っていませんか。ITでやっているのは製造ではありません。製造業で言う「製品企画」「設計」「量産準備」です。製造業で数年かけることも多々あります。だからITは決して遅くない。
ITの「製品」は実働するバイナリで、「製造」するのはコンパイラやインタープリタという「工場」です。ソースプログラムは設計図です。設計図を「工場」に渡したら、無人かつ自動でモノができる理想工場です。検査までやってくれます。もし量産したければ、コピーと言えばオシマイです。
この理想工場、あまりに便利なので存在を忘れてしまいがちです。でも製造業と対比するなら決して忘れてはいけません。
製造のノウハウであるカイゼンを、設計であるIT に持ち込もうとして大失敗します・・・しました。
Chat Katze
関連
日本はIT人材が不足していると言われています。ここでいうIT人材とは、開発ができる人材のことでしょうか？それともIT商材を扱える営業職なども含めているのでしょうか？
営業職も含めて人材不足は出ていますよ。
ただ、不足している層はどの職でも中堅以上の層です。
知識豊富なベテランで、しっかり自分で仕事を進められるタイプなんて絶滅危惧種です。
口だけ上手くて中身のないおじさんなんかは営業にも技術にもいます。
手順書に指示された事しか出来ないオペレーターや初級エンジニア、ヘルプデスク要員みたいな人材はたくさんいます。
ただ、仕事を任せられる人間となるとなかなかいません。
人に指示を出しながらプログラムの完成までスケジュールを守れる人。
お客様と会話して需要を聞き出し、適切な提案をしてたくさん受注してくる営業。
こんな人材を求められますが、それぞれ、色々なスキル、知識などをフル活用してこそ出来る難しい仕事で、いたとしても会社でそこそこ活躍してる人を引っ張らないといけないわけですから、良い条件を出さないときてくれません。
そして、良い条件は日本企業ではなかなか出せなくて外資に取られていくという転職市場での競争の結果、常に人材が不足するのです。
IT業界で良い人材というのは1人で新人20人分くらいの成果を残したり出来るので、そういう人は引っ張りだこですね。
西村 依澄さんのプロフィール写真
西村 依澄
·
フォロー
詳しい分野:英語(言語)1年前
関連
日本は、給料が低い人材に、完璧を求めすぎていませんか？
その通りです、おかしいですよね。
給料に見合わない労働はするべきでないし、させるべきではない。
我々日本人は社畜精神が元々あるのか分かりませんが、悪質な労働環境にも関わらず真面目に仕事をしてしまいます。もしくは我慢して働く人が殆どではないでしょうか。
会社は従業員に対して仕事を「してもらっている」立場です。
従業員は会社から「給料をいただく対価」として仕事をします。
対等なんです。
どの給料でも同じ働き方をしろだの言う人はまさにブラック気質な方で、日本の労働環境を悪化させている原因の1つでもあるでしょう。
今日もいい天気さんのプロフィール写真
今日もいい天気
·
フォロー
東京大学大学院で博士号を取得1月6日
関連
日本のIT人材育成に足りないこととは？
ないよ。人材を「育成」なんてするのは間違っている。ITやっている奴は育成されなくても自分でなんとかする。そういう自分でなんとかできない人をいくら「育成」してもほとんど役に立たない。だから、育成なんて必要ない。
Aoyama Hirokazuさんのプロフィール写真
Aoyama Hirokazu
·
フォロー
クラウドサービスの企画および開発2年前
関連
日本でIT人材が不足しているのはなぜだと思いますか？
それは、理系で最も頭の良い人達がみんな医学部に入ってしまうからでしょうね。
日本でITやってる人達というのは、エリート揃いのアメリカとは真逆で、理系の底辺層が多いのです。そもそも理系ですらない人も多いですし。
何故そうなってしまうのかというと、言うまでもない話ですが、日本では医者の方が圧倒的に稼げるからです。ITエンジニアの収入は世間一般で考えれば悪くはない方ですが、それでも、稼いでいる医者に比べたら10分の1以下です。
日本でも年収が数千万円あるいは億単位で稼ぐエンジニアがそのへんにゴロゴロいる状態になれば、医学部ではなく情報系を選ぶエリート学生が増えるかも知れませんが、現状ではITで稼ぎたければ単にアメリカに行けばいいだけの話ですから、アメリカの大学に入学するのが正しい選択です。少なくとも2020年現在の時点では、エリート人材が日本の大学でITを学び日本企業に就職すべき積極的な理由は全く何もないと言えます。
もちろんプログラマーとして優秀な人は日本にも大勢いますけど、お金を生み出す能力に欠けた人達が多いという印象です。プログラミング能力が高くてもそれだけではビジネスには大して役に立たない、ということが理解できていないというか。何というか、業界全体が下請け根性に染まってしまっているんですよね。下請けはいくら頑張っても永遠に下請けです。一方世界ではPh.Dを持ってる人達を大勢集めて論文書きまくって実用性の高いソフトウェアも作りまくって世界のスタンダードを手中にする、というバトルをやっています。それがIT業界における基本的な戦いです。日本のプログラマーの大半はその戦いに参加していません。まあ論文書く人がいないわけではなくて日本にも大勢いるんですけど、そっちはそっちで逆にデファクトを取れそうなプログラム作ってませんし(ビジネス知らないから作れないでしょうし)、論文書いて実証コード書きゃ仕事終わりですからね。それもまた無意味というか。
ただ日本でも若い企業を中心に少しずつエンジニアの待遇に関して変化の兆候が見られるので、あと5年10年経てば能力をきちんと評価して数千万〜1億円といった高給を払う企業が増えてくるかも知れません。そのためには当然、数十億円以上の売上増加にしっかり貢献できるようなエンジニアである必要はあるでしょうけど。エンジニアを使う側の経営手腕も重要ですが、エンジニア自身も世界観をアップデートしていく必要があります。
実際、エンジニアの側でも「ITで世界を変える」といった概念を肌感覚で理解して実践しようとしている若い人達が増えていますから、少しずつですが確実に良い方向に変化している部分はあると感じます。
ちなみに私はシリコンバレーで働けるほど優秀ではないので日本でのんびり稼いでます。ライバルが少ないため毎日2〜3時間しか仕事する必要がないので、私みたいなぐうたら人間にとっては日本もまあ悪くはないとは思います(笑)
閲覧数:2.2万回170件の高評価を見る5件のシェアを表示
Takashi J. Ozakiさんのプロフィール写真
Takashi J. Ozaki
·
フォロー
Data Scientist (2012-present)2年前
関連
日本でGAFAのようなIT企業が育つことはありえますか？
あり得ないことはないと思います。GAFAと言われようとFANGと言われようと、所詮ひとつひとつはただの民間企業です。
ですが、最近「ポストGAFA」とうたわれながら伸び悩んでいる日本のベンチャーやスタートアップを見ていて、そういう方面には素人ながらどうしても一つだけ気になる点があるのです。
それは「最初から『日本で』流行ることばかりやっていて『世界でも』流行ること
プロダクト思考とプロジェクト思考を理解し、優れたプロダクト、チームを作り出す方法
ツイッターで偶然見かけたプロダクト開発に関する一連のツイートが、プロダクトチームと経営陣、あるいは開発メンバーやプロダクトマネジャーの間に起きる摩擦を見事に言語化していました。
このスレッドに感銘を受け、プロダクト開発に関わる全ての人が知るべきと思いツイート主である Shareyas Doshi さんに日本語で翻訳させてくださいとお願いした結果、快諾いただいたので訳しました。
Shareyas Doshi さんは Stripe, Twitter, Google などでプロダクト開発をしてきた方で、他にも大変参考になるツイートを連投されているので、ぜひフォローしてみてください!
読みやすいように節を分けています。
それではどうぞ。
大企業やスタートアップのチームは、規模が大きくなるにつれて、知らぬうちにプロジェクト思考に偏り、プロダクト思考が欠ける傾向があります。
プロダクト思考は絶対に忘れてはならない心構えでありプロセスです。
プロダクト思考とプロジェクト思考について、このスレッドで整理してみましょう。
過去数十年にわたり、インディビジュアルコントリビューター(IC)やリーダーとして働いてきた経験、また多くの急成長したスタートアップのアドバイザーとしての経験から、創業者、CEO、幹部、そしてわたし自身も以下のようなことについて心配するのをよく目にしてきました。
創業者/CEOs/役員
- わたしたちのチームは大きな視点が足りない
- 顧客との接点が失われている
- わたしたちは受け身すぎる。ニーズに対して予見できていない
- 製品ローンチは多いが、期待するような成果がでていない
- 期待したものをリリースできているかわたしが詳細を確認しないといけない
- ローンチ後のレビューでプロダクト品質がないがしろにされている
また一方で、キャリアの大部分をプロダクト開発の現場で過ごし、何百人ものプロダクトマネジャーやそのマネージャーを管理・指導してきた経験から、わたし自身、そして他の IC やマネージャーが以下のようなことについて心配しているのをよく目にしました。
プロダクトマネジャー/デザイナー/エンジニア
- 長期的な視点をもてというが、短期的な結果をもとめられる
- 大口顧客の CEO への要求がロードマップを台無しにする
- プロダクト開発の初期段階には不要な融通の効かないプロセスがある
- 高品質のプロダクトをローンチすることを期待されるが、そのための時間は与えられない
- ローンチ予定日を遅延させるとトラブルになる
わたしたちは皆、顧客のために大きな価値を創造し、会社のビジネスを成長させ、良い影響を与えたいと考えています。なのにこの仕事特有の複雑さはどうして上記のような相反する「真実」を生み出してしまうのでしょうか？
その答えの少なくとも一部は、しばしば互いに異なる言語で会話しているにもかかわらず、そのことに気づいていないという状況にあります。一方がプロダクト思考、他方がプロジェクト思考であることを認識することなく、瑣末な事柄をわたしたちは争っているのです。
プロダクト思考とプロジェクト思考とは？
まずはこの２つの思考について理解を深めていきます。これらを理解しないことには、大きな進歩は望めません。
そのためにはわたしたちが職場で目にするいくつかの例から始めるのが一番です。(これらは実際の出来事に基づいています。）
ここでは、アリス（元 PM、現ジェネラルマネージャー）とボブ（プロダクトマネジャー、アリスの部下）が、2 つの緊急な機能要求について CEO へのエスカレーションについて話し合っています。
GM アリス: 重要な顧客である X 社が CEO にこの件に関してエスカレーションしました。３ヶ月以内に監査用のログ機能とコンプライアンスレポート機能をプロダクトに追加してほしいそうです
PM ボブ:はい、この件についてチームと話し合いをしました。残念なことにこの要求はわれわれのロードマップを台無しにします。しかしもし、X 社を満足させるためにこの機能をどうしてもいれたいということであれば、チームの半分のメンバーをこの機能開発にあてないといけないです。そのため機能 Y のローンチは 2 ヶ月先延ばしになります。どうしたいですか?
ここでボブの反応に注目してください。このような状況ではかなり一般的な反応であり、古典的なプロジェクト思考でもあります。
別の例を見てみます。
ここではダン（PM）がイブ（CEO）と製品レビューのミーティングをしています。
PM ダン: こちらがプレミアム顧客に対するオンボーディングに関する提案書です。
CEO イブ: 顧客の質問への返答に２日かかると書いてありますね。重要な顧客に対して、30 分以内に返答するにはどうしたらよいですか?
PM ダン: 最初のローンチでは不可能ですね。これらの質問はカルロスのチームに行きます。カルロスと話しましたが、今の人員では２日以内の返答しか確約できないそうです。
イブがユーザーエクスペリエンスに焦点を当てた質問をしているのに対し、ダンはリソース、スコープ、SLA について回答していることに注目してください。これもまた古典的なプロジェクト思考です。
プロジェクト思考の例をいくつか見てきましたが、プロジェクト思考とプロダクト思考はどう違うのか、もっとしっかりと探ってみましょう。そのためにはプロジェクト思考とプロダクト思考のそれぞれの思考において関心がある質問事項について見てみるのが手っ取り早いです。
プロジェクト思考
- いつまでに仕上げるのか?
- 誰がするのか?
- 他に似たようなやり方は?
- どうやってやるのか?プロダクト思考
- なぜこれが重要なのか?
- なにがわたしたちのゴールなのか?
- 他に何が起こりうるのか?
- どうやって差別化するのか?
プロジェクト思考では「いつ」「誰が」に最初の関心が向かいますが、プロダクト思考では「なぜ」「何が」にフォーカスしていることに注目してください。またどちらの思考法でも、 「ほかには?」「どうやって?」を問いますが、実際に問われる質問は、どちらの思考法であるかによって異なります。
これらの問いが何を求めているか（そしてどのような答えを引き出すか）の違いが、まさにプロジェクト思考とプロダクト思考の違いの本質なのです。
プロジェクト思考
期待を理解し、計画を立て、リソースを集め、その期待に応えるために行動を調整すること。
プロダクト思考
動機を理解し、解決策を考え、その効果をシミュレーションし、望んだ効果に至る道筋を選ぶこと。
ここで先ほどの 2 つの例に戻り、もし PM がプロジェクト思考だけでなくプロダクト思考を取り入れていたら、会話はどのようになるでしょうか。
GM アリス: 重要な顧客である X 社が CEO にこの件に関してエスカレーションしました。３ヶ月以内に監査用のログ機能とコンプライアンスレポート機能をプロダクトに追加してほしいそうです
PM デイブ:はい、この件についてチームと X 社で話し合いました。まず２つの要求を別々に捉えることにしました。監査用のログ機能は他の顧客にとっても非常に重要なものとなります。なのでわれわれのロードマップを修正し、この機能の開発を優先しましょう。X 社には最初の利用者となってもらいます。
コンプライアンスレポート機能については、ほとんどが手作業で行われるプロセスであり、われわれの戦略に則っていません。なので彼らに期ごとのエクスポート機能を提供し、彼らの方でレポートを作ってもらいましょう。まとめると、監査用ログ機能の開発をスタートし、Y 機能については 1 ヶ月先延ばしにしましょう。
PM デイブがプロダクト思考を取り入れた結果、アリスへの返答はもっと詳細なものとなります。機能要求の 1 つは、実は非常に戦略的なものであり、それを実装することをデイブは推奨しています。もうひとつの機能要求についてはワークアラウンドを適用することを勧めています。
それだけではありません。プロジェクト思考のボブがこの状況を危機と捉えたのに対し、プロダクト思考のデイブはこの危機をチャンスに変えたのです。X 社が新しい監査ログ機能の最初の顧客になれば、自分の会社にとってどれほど価値があることかを彼は理解しています。
次に、2 番目の例を見てみましょう。プロダクト思考のパットは、2 日間の応答時間が理想的でないと知っており、重要な顧客たちに対して応答時間を 10 分未満に短縮する解決策を先んじて検討していました。
CEO イブ: 顧客の質問への返答に２日かかると書いてありますね。重要な顧客に対して、30 分以内に返答するにはどうしたらよいですか?
PM パット: よく聞いてくれましたね!われわれはこの件について調査してました。最も重要な顧客リストに入っている顧客であればアカウント管理チームに質問を回すようにすれば、彼らは 10 分以内に返答できます。残りの質問はサポートチームに回しましょう。一日以内に返答をさせたいのであれば、あと４人追加人員が必要です。
プロダクト思考によりパットはサポートチームが抱えるリソース制約を越えて、より明確なトレードオフを CEO のイブに提示できます。"工夫とこれこれこういった投資で、より良いユーザーエクスペリエンスを生み出せますよ!"。
プロジェクト思考とプロダクト思考における会話ともたらされる結果には実に大きな違いがあるのです。 これらの思考がどう異なり、どのような点で価値があるのかをより理解するためのチートシートがこちらです。
次に進む前に、このチートシートを見直し、自分の仕事、あるいはチームや会社を率いている場合は自分のチームが行う仕事にどのように適用されるかを確認することをおすすめします。
プロジェクト思考とプロダクト思考を自分の仕事に活かすには？
どんな小さなプロジェクトでも、正しい答えはこれではありません。
こうでもありません。
これでもない。
どんな複雑なプロダクトであれ答えはこれです。
プロダクト思考から始めて、差別化された創造的な解決策にたどり着き、プロジェクト思考でその実現可能性を評価することが重要と何度となく気づきました。
今日直面している制約と明日直面するかもしれない制約を考慮しつつ、プロジェクトにおける最終的なゴールと実現に向けてどう行動するかが、この思考プロセスの果てに明確になります。それが、決断力のある行動を可能にするのです。
プロダクト思考はプロジェクト思考より優れているわけではありません。 チームが一貫して成功するためには、プロダクト思考とプロジェクト思考の両方がうまくできる必要があます。どちらか一方が得意な人もいるでしょう。それでもよいのです。なぜなら、プロダクト思考は学ぶこともできますし、チームにプロダクト思考のイロハを教えることもできるからです。成功するためには、わたしたち全員が世界レベルのプロダクト・シンカーである必要はないのです。しかし、この 2 つの思考モードを認識できれば、より良いコミュニケーションと意思決定ができるようになります。
プロダクト思考力を上げる方法
長くなってしまったので、最後にあなた自身のプロダクト思考力を向上させ、他者に教えるための術を伝えます。
長年、多くの有能なプロダクト・シンカーと話をして見い出した、プロダクト思考のステップを紹介します。
1. プロジェクト思考を停止する
- プロジェクト思考をやめ、プロダクト思考に切り替える
2. 真の目標の優先順位付け
- なぜ? と だから? を頻繁に問う。ユーザーに対し、どのような効果をもたらしたいのか。
3. ユーザーニーズの把握
- 文句を言っていることとつまずきやすい点に注意を配る。表現されていないニーズを探す。
4. 選択肢の生成
- 大きなアイデアを恐れない。想像力と差別化を大切に。
5. シミュレーション
- それぞれの選択がどうなるか視覚化する。シミュレーションがまとまるまで繰り返す。
どのステップも非常に簡単ですね（むしろ自明かもしれません）。にもかかわらず、このステップを体系的に実践することがうまくできていないケースを散見します。われわれは急いでいたり、すでに知っていると思い込んでいたりするのです。これこそが、プロダクト思考の真の敵なのです。そして各ステップにおいてプロダクト思考を実践するために、"プロダクトセンス"が鍵となるスキルであると忘れないでください。
プロダクト思考の実践を示す例
それでは、プロダクト思考の実践を示す製品・機能の例をいくつか見てみましょう。
Spotify Wrapped は、プロダクト思考の素晴らしい例だと思います。Spotify のチームには、このような魅力的な振り返り機能を作らない理由が 1000 個はあったでしょう（バグを潰したり、何十もの機能要求を出したりするのに精一杯なのに、1 年に 1 回しか使わない「くだらない」振り返り機能を作るの?みたいな）。
もう一つの良い例は、Gmail の「ファイル添付を忘れましたか」機能です。この機能は、長年にわたってわたしを何百回も恥ずかしめから救ってくれました。オプションボタンをよくよく調査しなければ、彼らはこれほど上手に実装することはできなかったでしょう。
もう一つの例は、@usehonkのこの画面です（@round)。細部へのこだわり、何にサインしているのかに細心の注意を払うよう仕向けられるよく洞察された作り、そしてそれらがユーザーに与える影響のシミュレーション、すべてが賞賛に値するものです。
最後に
このスレッドを終えるにあたり、2 つのことを残しておきます。
まず、映画アベンジャーズのこの短いクリップをご覧ください。
先ほども言いましたが、シミュレーションはプロダクト思考における最大の秘訣です。もしあなたがより良いシミュレーションを行うことができ、またチームに対してシミュレーションをするように促すことができれば、素人には魔法のように見えることを実現できるはずです。まるでドクター・ストレンジのように。
最後に、プロダクト思考に熟達すると、プロダクトだけでなくさまざまなことに応用できます。究極的に、プロダクト思考とは、自分の本当の目標、与えたい影響、どのようにその影響を生み出すかということへの体系的な取り組みなのです。
今日はここまでです。このスレッドが、より良いプロダクト、より良い体験、より大きなインパクト、そしてより賢明なチームを創り出すために役立つことを願っています！
0 件のコメント:
コメントを投稿