この記事の主旨

成功するためには、枠組みづくりが大事だ

どんなに優秀でも、たった一人でできることには限界がある。
成功させたいと思うなら、成功できる枠組みを作ることだ。

それを実現したら喜んでくれる人たちがいますか

「ナンバー１の◯◯企業になる」を掲げる会社に、共感して喜んでくれる人はいません。それは、その会社の人しか喜びません。
あなた方の実現する製品・サービスに共感してもらえますか。
それが作りだす内容に価値がなければ出資者は現れません。
社内においても、開発の予算が付きません。
それが実現したら喜んでくれる人たちがいる開発提案になっていますか。

->　喜んでくれる人があれば、将来利用してくれる人になる。
-> もっと惚れ込んでくれれば、開発に参加してくれる・営業に参加してくれる人になる。
-> 世の中にとって価値があると判断すれば、投資してくれる人もでてくる。

目標

その目標は未来につながってますか

開発の目標を達成したとして、それは未来につながっていますか
それを達成した時に、次の発展に結びつかないとしたら、効果が薄い。

例：ソースコードの共有と共同開発を可能にしたgit, Github

git, Githubは、ソースコードの開発スタイルを、Git以前、Git以降でまったく別の世界に変えてしまった。
複数人による開発を簡単にしたし、
Pull Request, Review と承認の仕組みは、
変更分の品質を高めるものになった。
論文には、github のURLがあって、他の人は、OSSのライセンスであれば、それを改良した版を作成できるようになった。
確実に未来を変えてしまった。

例：飲食店での注文のしくみを変えたタブレット

飲食店での注文をとる際に、人が対応していた際は、なかなか注文が決まらなかったりと、注文に時間がかかることがあった。
また、注文のリクエストがあっても、すぐには対応できないこともあった。
注文への受けこたえという工数が、飲食店従業員にとって、利益が出にくい手間になっていたろう。

このような仕組みが、１つの店舗形態で実施されるだけでなく、多くの店舗でなされるようになった。
だから、未来を変えた技術になっている。
その技術の先に、セルフレジという方法へ結びつくという発展も遂げている。

目標の設定は妥当ですか

相手が得意な分野に、競争の中心をおくのは賢くない。
- 例：海外メーカーによる低価格製品に対して、自社製品の低価格化をすすめることだけによる対応。
- その結果が、わずかの低価格化を進める改良が評価され、新しい製品・新しいビジネスを作る人員を失わせることにつながった。
- 技術レポート雑誌の発行停止や鳴り物入りで作ったショールームの閉鎖するほどに余力をなくしている。
  ->　自分たちが得意な分野で勝負ができれば、勝負を有利に展開できます。
  -> 他者が容易に真似ることができない分野を作り出せていれば、競争を有利にできます。

実現の可能性を感じさせない「理想的すぎる目標」になっていませんか

それができたらうれしいからといって、目標の設定としていいわけじゃない。
いまの状況に比べて、あまりに理想すぎる目標になっていませんか。
あまりにも理想的すぎる目標を掲げるのは、無謀さを意味します。
実現可能性を出資者に信じてもらえるものにすること。
理想すぎる目標の場合には、達成にいたる道筋が描けていない。

実現しやすことを実現して、改良を繰り返す目標になっていますか

実現しやすいことを実現して、改良を繰り返さないと、難しいことは実現できません。
どうすれば実現しやすい実装になるかなんて、着手した時点ではわかっていないのですから。
実現しやすいことを実現して、改良を繰り返すことで、困難の数が少しづつ減っていきます。
最後に残るのが一番手ごわい困難です。
でも、それ以外の困難は既に潰してあるので、その１つの問題に専念できます。

完璧でなくても、価値がでるような目標になってますか

ホールインワンを満たさないと役に立たない目標になっていませんか
参考：眼の進化

最初は眼点
次にピンホール眼
その後にレンズ眼
どの段階でも、見返りがあることで改良を続けることができた。
例：化合物半導体のロジック素子
化合物半導体が高い移動度を実現するのはわかっていても、どの時点でもシリコン素子を置換えることはなかった。
例：液晶ディスプレイ
液晶ディスプレイが各段階で産業界全体としてみたときには見返りがある状況が続いている。
だからこそ、スマートフォンとしての大画面化と高解像化が続けることができている。

ホールインワンを満たさないと役に立たない目標は、多くの場合失敗します。
もしくは、それができるだけの能力が最初からある場合には、話は別ですが。

-> 完璧でなくても価値がある状況になっていれば、それを利用することができます。
-> 利用できるものがあることで、枠組みの妥当性は証明されています。
-> あとは完成度を高めていけばいいのです。

ほんとにいい課題設定で、目標の設定になっている場合、その課題設定や目標の設定自体が価値を持ちます。
いい課題設定を見つけられれば、いずれだれかがそれを解決してくれることもあります。

いいアイディアは共有する価値がある

いいアイディアは、共有されてこそ力を発揮できる。
いいアイディアは、実現したくなる。
いいアイディアは、成功を導きやすくなる。
いいアイディアは、ユーザーを引きつける。

仲間

その目標に共感してくれる人を増やそう

実現したい目標をことばにします。
そのことばをいろんな場所で発信していきましょう。
そして賛同してくれる人のネットワークを作っていきましょう。

一緒になって取り組んでくれる仲間を作れてますか

一緒になって取り組んでくれる企業を見つけ出せない限り、成功は絶対ない。
出来上がったもの買ってくれない限り、開発は続けられない。

製品ができたあとも、一緒に取り組んでもらえる仲間を見つけること

それができていない時点で、失敗は約束されてしまっている。
所定の条件を満たせば使うことがわかっている部品は開発に成功しやすい。

スポンサーを獲得しよう

手をこまねいているとその分野は、日本にはなにもないままになってしまう。
その技術にともなう利益は、全て他国のものになる。
その技術ができたらうれしい人をスポンサーにしよう。
収益が上げられるストーリーを描いたら投資家を募ろう。
社内の部署の場合でも、会社の上層部をスポンサーにすることだ。

使いたいと思わせるニッチを見つけよう

使いたい人が見つけられない場合、それは「技術」ではない。
使いたいと深く思って購入してくれる人がいることが大事。
「いいねえ」と言うだけで購入してもらえないならば、何かが足りてない。
使いたい人を別な場所で探してみよう。

巨大すぎる開発項目をブレークダウンする

巨大すぎる開発項目を巨大なままにしておくと失敗する。
巨大な開発項目をブレークダウンして、扱い切れる開発にしていこう。
なるべく既存技術を流用できるところは既存技術を流用しよう。
既存技術を評価して、どういう条件の範囲で使えるのかを明らかにする。
そうすることで、既存製品の利用で、新規の開発を減らす。

成功する仕組みを作ることが、個々の成功よりも大事

ある程度以上の複雑さをもつプロジェクトの場合、一人のエンジニアで成功にたどり着くことは難しくなる。
一人のエンジニアがすごい成果を出して、ある程度ものにすることができても、その先が続かなくなる。

しくみ１: チーム内のメンバーが２人で一緒に話をするきっかけを増やす。

人と人の関係を作り出すには１対１での対話がよいです。
３人以上になってしまうと、話さない人や他のメンバーを気にして話を遠慮してしまう。
施策例：　会社の中で２名でのランチに補助を出す。
　新しい組合せで２名で話をしながらランチをすると、食費補助を出す。
　ある会社では、このような施策で、社内の人と人とのコミュニケーションをはかっていた。

チームの運営のしかたをチームで作っていこう

成功する開発チーム作りとは？人員構成・リーダーのあり方や、アジャイル・スクラム開発とは？
“心理的安全性”が保たれている
心理的安全性とは、チームメンバーが「自然体で対応できる」「周囲から信頼されている」などと感じる状態を指します。

しくみ２: 利用したい人たちのコミュニティを作る

ソフトウェアの場合：
OSSでライブラリを公開する。
そのライブラリに興味を持ちそうな人たちの集まる場所でアナウンスをする。
その開発する一群のライブラリの目的を明らかにする。
なにがうれしいのかが伝わるようにする。
オープンソースコミュニティをどのように作るか

開発を塩漬けにしない

開発には予算と人員が必要だ
そのため、なんどもあるパーツを作り直すことができない。
そのため、こうすればよくなることがわかっているのに、放置されてしまうことがある。
それを塩漬けと私は読んでいる。

塩漬けになってしまうと生じること

開発されていることになっているから、表面上の言葉尻ではうまくなっていることに組織上なってしまうことがある。
「うまくいっている」ことになっているから、改良のための提案さえ受け付けなくなることがある。
そのため、開発計画の軌道修正ができなくなってしまう。

今の競争相手は、どれくらいの速さで動いていますか

あなたが着目している技術分野について、ウォッチしてくれている人をX(=旧twitter）でフォーローしましょう。
そうすると、どれくらいの速度で世の中が動いているのかわかります。
それに負けない開発のしくみを作っていくことです。

失敗はチームとしての失敗だ

ある作業をメンバーのだれかにまかせたとしよう。
それが失敗に終わったとき、それはチームの失敗だ。
失敗しそうな不安があるときに、チームに助けを求めるようにしていたか、
助けを求めている人に対して手助けを差し伸べていたか
失敗の多くは、失敗を回避するためのチームワークができていないことによる。
あなたの組織は、メンバーに助けを求めることができるものになってますか。

プロジェクト・マネジャーが知るべき97のこと
プロジェクトの失敗は組織の失敗

なにも工夫しなくて成功することはありえない

トラブルはあってあたりまえ
トラブルを乗り越える必要があるから開発なんだ。
トラブルが見えてくることは、知見が増えてきているということなんだ。
何を改良すれば、実用になるのか（＝成功するのか）を明らかにすることだ。
それを知ったうえで、助けを求めることだ。
どこかに、その課題を解決している人がいるかもしれません。
トラブルはあってあたりまえなんです。

協力をあおぐためには、手持ちの材料を公開しよう

協力関係を作っていくには、まずは自分から一方的に提供しよう。
あなたが提供した知見は、他の人の発想の材料になる。
見返りを期待せずに、一方的に提供することを繰り返そう。