及川 フルタイムでコミットしていてもいいんですけど、0→1が得意な人が1→10や10→100のフェーズでずっとその企業に残っていてももったいない話だし、逆に0→1が不得意であったとしても、安定稼働させることに関してはめちゃくちゃ得意な人もいるわけですよね。
その人が企業の成長のステージとは無縁に、ずっとその企業にい続けること自体がおかしいので、例えば年単位でもいいと思うので、その人たちが自分の活躍できるところに移っていくことをやるだけでも、限られたタレントというリソースの活用にはなっていくと思うんです。
だから、藤井さんがおっしゃったとおり、日本はエンジニアのリソースが圧倒的に足りないというなかで、それをどう回せばよいかというところは考えていったほうがいいかなと思います。もちろん、それ（エンジニアの絶対数）を増やしていくという方向でね。
藤井 そうですね。ある意味、それが業務委託もしくは準委任だったならば、実はそれとまったく同じことを言っているんです。どこの会社に所属しているのかということを置いておけば、そこのCIOとして「これから2年間、このステージをここまで上げます」という。
こういうものをベンダー派遣型と呼ぶのか、それともアーキテクトやCIOと呼ぶのか、というのはおもしろいかなと思いますね。
質問者２ 今日はお話ありがとうございました。エッジ側を含めて、とても可能性が広がっているなかで、そのアーキテクチャを誰が考えたらいいのか、全体の責任を誰がとったらいいのかが非常に複雑になってきて、すべてができるオールマイティの人がなかなかいない気がしています。
先ほどシリコンバレーでは、数時間単位でいろんな人たちが（仕事に）コミットする、というお話がありましたけれども、どうやって責任をとる人を決めて、どうやって異なるスペシャリティのある人をつなぎ合わせて、責任がとれるようにしていけばいいのか。それについて、みなさんがどうお考えになられてるのかをお伺いできればと思います。
澤 じゃあ先に僕から。これは2つの考え方があると思うんです。例えばちょっと大きい企業で、責任の所在を明確にしないと経営そのものが信用されなくなる、というのであれば、これは実はまったく違う観点です。
僕があちこちで働き方改革の話をするときに、必ず言っている話なんですけど、ジョブ・ディスクリプションがない会社は圧倒的に多いんですよね。
僕から言わせると、そもそも「誰が責任をとるのか」じゃなくて、「責任範囲を明確に定義してないのに、そんなこと言う資格はそもそもないでしょ」なんですよ。「先にジョブ・ディスクリプションを作ってからにしなさいよ」なんですよね。
そのうえで、新しいことをやる時に誰が責任をとるのかを語るべきであって、それ以前に、社員の責任の所在もはっきりしてないのに、何かの行動に対してだけ「責任をとれ」というのはおかしいと思うんですね。そうなっていると、おそらくはイノベーションなんて永遠に起きないですし、前に進むことも基本的にないと思うんですよ。
もしそういった大企業や、ある程度の組織体ができている企業が、ジョブ・ディスクリプションがなくてそう言っているんだったら、まずは「全力でジョブ・ディスクリプションを作りなさい」ということなんですね。それがまず1つ。
澤 そうではなくて、もうちょっと新規事業的なものだったり、それこそスタートアップなどの実験的なものであれば、責任なんてものはとらなくていいと思います。失敗したら賞賛し、祝福をするくらいのカルチャーをつくることが大事かなと思います。その代わり、早めに失敗することです。
致命傷をいきなりくらうんじゃなくて、早めに失敗してすぐに修正できる。そういった流れ、サイクルでやっていくこと。責任をとるとなると、場合によっては犯人探しになるんですよね。そんな暇はないんです。そんな人を探している場合ではなくて、早く前に進むためには何をすればいいのかを考えておかなきゃいけない。
そのためには、責任をとる云々という話ではないんです。僕はオーナーシップという考え方でよく言っているんですけれども、「誰がこれのオーナーなんだっけ」というふうに言えば、必然的にその人は、誰から言われるでもなく責任をもって行動するはずなんですね。
そうしたら、「あ、これ失敗した、ごめんやり直す」。それでいいと思うんですね。それだけで次のステップに行けばいい。それが2つあります。
藤井 僕も澤さんの後半の考えと一緒です。失敗をできるだけ早くして修正して、正しい方向に結びつけていく。ムービングターゲットを追えるようにする。正しいことをしようとするから失敗するわけです。
とくにそういうイノベーションを目指しているところに関しては、それ（正しいこと）が変わっていくというふうに考えたほうがいいと思うんですよね。
（中略）
アーキテクトの話はまたちょっと別かもしれないですけどね。そのアーキテクトがどこを目指しているのかをみんなで議論していれば、「誰から何を学べばいいのか」も明確になってくるので、それでムービングターゲットを追えるようにして前に進んでいけばいいのかなと思います。
及川 ジョブ・ディスクリプションの話というのはそのとおりです。たぶん、日本企業はずっとやっていなかったことなんですよね。日本企業の雇用モデルはメンバーシップ雇用と言われていて、その人の職種・役割を定義しないまま採用し、かつ、その役割がなくなってもあなたの雇用は守りますから、ということをやっていました。
なので、やはり澤さんの言うとおりだと思うんですよ。それを変えていかないといけないなと思います。失敗を許されるような組織と、職種・役割を明確にしていくところの両方をやっていくことが、もしかしたらこういったテクノロジーを活用する組織において、必要なことなのかなと思いますね。
澤 そうすると、本当にスキルを持っている人が、テクノロジーを磨いていくところに集中できると思うんですよね。いつ営業にすっとばされるかわからないという今の状態になると、そのカッティングエッジの技術にものすごくコミットするにはやりづらいんじゃないかなと思っています。そこを救う意味でも、ちょっと意味があるかなと思いますね。
もっといろいろやりたいなと思う。もっといろいろできると思う。
（休息含めて）24時間をいまの会社のことだけに使うのではなくて、
自分のできることにちゃんと使ってやりたいと思う。
他のひとでできることは他のひとにやってもらい、自分にしかできないことに時間を使いたい。
そうあるべきだと思う。いまの会社だけだなんて、なんだかまどろっこしいと思う。
それはそうなんだけど、だからといって、今すぐ外向きな何かをしようってわけではなく。
いまは今の会社のことをやっておきたい。自分のために。
胸張って自信を持って「これだけやった」と言えるように。
だからいつまでたってもスキルアップは必要なのである。
