—以下資料作成時のドラフト— 普段はソフトウェアエンジニアや情報系の大学の学生に話すことが多いが、今回は経営系ということで、まずはITの話から

ITとは何か

  • IT: 情報技術

  • 情報を扱う

  • 人間が扱うよりコンピュータの方が圧倒的に得意なので実質的に「コンピュータ利用技術」

  • コンピュータとはcompute(計算)するもの、コンピュータサイエンスを日本語では計算機科学という。

  • 計算機の歴史における大きな一歩

    • 1952年 IBM 701発表
      • 真空管1071本
      • 月額レンタル料1~2万ドル程度
      • その後IBMがどうなったかはご存知の通り
    • 1957年 FORTRAN発表
      • FORmula TRANslation system(数式変換系)
      • 現代のほぼすべてのプログラマが使う「プログラミング言語」のはしり
  • 計算機に何を計算させるかの指示が「プログラム」

  • 物理的なものとしての「計算機」と、実体のない情報としての「プログラム」の2つに分かれた

    • 分かれる前はワイヤーを配線して計算内容を記述していた
    • ENIAC配線風景
  • 前者を「ハードウェア」、後者を「ソフトウェア」と呼ぶ。

  • 現代においてプログラミングとは「プログラミング言語」という道具(=これ自体がプログラム)を使って、プログラムを作ること。

  • ソフトウェアエンジニアの仕事は

    • コンピュータに何ができるかを把握し、
    • 顧客価値を生み出すためにコンピュータに何をさせるべきか考え、
    • それをコンピュータに理解できる形の指示情報にまとめる。
    • より効率よく価値を生み出すように設計する。
  • 会社経営は

    • 各従業員に何ができるかを把握し、
    • 顧客価値を生み出すために従業員に何をさせるべきか考え、
    • それを従業員が理解できる形の指示にまとめる。
    • より効率よく価値を生み出すように設計する。
  • だいたい同じ。

  • 似ている→違いは?

  • 易しい所、難しい所

    • コンピュータは感情がないので、モチベーションに配慮する必要がない。仕事が嫌になってやめたりしない。
    • コンピュータは察したりできないので、事細かに指示を出す必要がある。
  • 事細かに指示を出すのが面倒!

    • 何がやってほしいことであるのかの言語化が必要
    • 特に受託などの場合、コンピュータにやってほしいことのある「顧客」と、それをコンピュータに指示する「プログラマ」が別人なので、やってほしいことの言語化を頑張る必要がある
  • そこで指示を出すことを容易にするために、プログラミング言語が発展してきた

  • C言語でHello! C

#include<stdio.h>

main()
{
    printf("Hello!\n");
}
  • PythonでHello! python
print("Hello!")
- これは2004年に作られたポスター
- ここから10年で何が起こったか
    - Apple製品上でのプログラムを作るために長らく使われ続けてきたObjective-C
    - Swiftリリース
        - ObjCのリリースは1984年
        - Swiftのリリースは2014年
    - Flash/ActionScriptの死
        - iPhoneがFlashを搭載しないことを決定
        - HTML5/JavaScriptの飛躍的進歩
        - 2005年にYouTubeが創業、Flashを使った動画再生で有名になる
            - 2007年にAppleがiPhoneをリリースする。しかしiPhoneではFlashが使えなかった。
            - Adobeが「2020年にFlashのサポートを打ち切る」と宣言した(2017年の7月に。すごい最近だな!)
    - Visual Studio 2005 Express マイクロソフトがプログラミング言語を無償化
        - プログラミング言語の販売市場が焦土に
  • 機械学習・人工知能のブームにより、Pythonが格段にシェア拡大

  • 特殊なものづくり

    • 言葉(プログラミング言語)を道具に使ってものを作る
    • その言葉自体が作られる対象
    • その言葉が外的要因によって変化する
  • ダグラスエンゲルバート

    • 知能増強
  • 概念を作る

    • 代入、関数、再帰的定義、モジュール、クラス、トレイト

    • 文字列

    • 変数の概念

      • メモリ上の0と1の羅列に過ぎない
      • 番地を指定して読み書きする
      • 人間につらい
      • わかりやすい「名前」を付けられるようにした
      • x = 1 でxという名前に紐づいているメモリ上の番地に書き込みを行う
    • 関数の概念

      • 繰り返し使われるコード中の一部にわかりやすい名前を付けて再利用可能にする
      • 物理的なものづくりとの大きな違い
        • 物理的なものづくりでは、ある部品(例えば水道の蛇口)を100個使うと、100個分の原価が掛かる
        • 情報空間でのものづくりでは、ある関数を100カ所で使ったとしても、関数自体の作成コストは一定。
        • 再利用性の高い部品作りに強いインセンティブが発生する
        • もちろん部品に分ける設計では部品の継ぎ目でオーバーヘッドが発生して、グローバルな性能が低下する。それは物理的なものづくりと同じ。#モジュラーとインテグラル
        • だけどMoore’s law
    • コーディングを支える技術

    • image

    • 2013年4月に出した本だけど、今でもSNS上でしばしば肯定的に言及されている

  • CUIとGUI

    • グラフィカルユーザーインターフェイス
    • 一般人にはとっつきやすかった
    • 物を指さすジェスチャーによってコミュニケーションするようなもの
    • 音声ユーザーインターフェイスが登場したことで、一般人に「言葉で指示を出す」が広がった
    • 易しくなったことによって門戸が広がる効果
      • メモリ管理が必要なくなったことでプログラマが増えたのと同じ
    • 仕事はなくなるか
      • ワイヤーをつないでいた仕事はなくなった
    • 今の意味でのプログラマの需要は減るかもしれないが、代わりにより多くの人が当たり前に使う「プログラミング的な何か」が増える
      • 文科省 義務教育でのプログラミング教育
      • プログラミング的思考の習得

アジャイル開発とは何か

  • ITにおいて変化の速さと、物でなく情報であることによって「再設計のコスト」が低かったことが、学びの速度を重視するアジャイル開発と相性が良かった

  • アジャイルとは何なのかについて解説

    • まず経営戦略という言葉には色々な意味がある、戦略サファリ

    • 2つの考え方がある

    • 「環境から効率よく学び、変化に適応することが重要」

    • 「自社の強み、弱みをしっかり分析して戦略を策定することが重要」

    • 2つの考え方を比較することで、書かれていないことが分かります。

      • 「自社の強み、弱みをしっかり分析して戦略を策定することが重要」というとき、暗黙に「戦略の策定は事前に行われ、その後、それを実行する」という前提が入っています。実行フェーズで戦略の間違いに気づいたらどうするのか、環境からどう学ぶかの視点が抜けています。
      • 逆に「環境から効率よく学び、変化に適応することが重要」というとき、暗黙に「環境は変化するものであり、事前に時間をかけて戦略を練ってもしかたがない」という前提が入っています。事前の戦略策定が軽視されているわけです。
    • U理論とアジャイルは根が同じ────U理論・中土井 僚(4)/西尾 泰和の「続・エンジニアの学び方」 | サイボウズ式

    • どちらが正解というものではない

    • 筆者はラーニング・スクールの考え方にとても親近感を抱いています。企業の経営だけでなく、エンジニア個人の「自分経営」に関しても、いかに環境から学び、変化に適応するかがとても大事だと感じているからです。

  • 「アジャイル」という言葉を連想する人もいることでしょう。アジャイルという言葉の定義はあまり明確ではありませんが、「事前にしっかり仕様を設計して、それからそれを実装する」のではなく、「速やかに顧客に提供し、その結果から学んで仕様を変えていこう」という開発スタイルだと言ってよいでしょう。この2つの開発スタイルの関係は、上で説明したデザイン・スクールとラーニング・スクールの関係によく似ています。「効率よく学ぶこと」これがアジャイル開発の目的なのです。

  • リーン・スタートアップ

    • IT業界でよく参照・言及される経営書
    • 構築・計測・学習のループ
    • スタートアップの経営論
    • 限られたお金を消費しながら進む
    • お金がつきる前に、自分が作り出したものに対してお金を払ってくれる「顧客」を見つけなければいけない
    • 「こういう製品を作れば売れるだろう」という考え、「お金を払ってくれる顧客がいる」という仮説
    • 仮説は検証しなければならない
    • なるべく早く検証して、正しくなさそうだったら方針転換をしなければならない
    • 手持ちの資金を全部使って製品バージョン1を作って、そこに顧客がいなければ倒産あるのみ
  • 細かい制約条件の違いはあれ、リーンのコンセプトは広い範囲に応用可能

パラレルキャリアの時代

  • 首相官邸の働き方改革

  • 厚労省のモデル雇用契約の改定

  • 経団連

  • いま大学院生のみなさん、あなたの親の時代は副業禁止で、一つの組織だけで働くのが当たり前の時代だった

  • 大学卒業後、「就活」をして、大企業に入り、定年までそこで働く、というイメージ

  • ドラッカーのパラレルキャリア

    • 2020年
    • 日本
  • 大企業:潰れない企業

    • 日本においては人間より長命
    • IT技術発展前に生まれた会社
  • 新しいものを生み出せという圧力

    • 組織の外から知識を得る必要性

    • オープンイノベーション

    • 知識の乗り物としての人間

      • 知識を蓄えるところは電子化されうる
        • 状況を観察し、重要な特徴を切り出した上で、それに適用可能な「書かれた知識」を取り出してくる機能
      • 「新しい結合」を作り出すところ
        • 「コンピュータにはできない」などという人がいるが筆者はそう思わない
        • 言えることは「コンピュータにできるところは、すぐにやられて競争優位につながらなくなる」
        • 競争優位を作り出すのは、境界の少し外側
    • 物理的集合

      • 場所の分散
      • 時間の非同期
      • Scrapbox
        • 増井研
        • 大学=大部分の人が4年でいなくなる場=離職率25%
  • ベン図、オーバーラップ

    • コミュニケーションコスト
    • 共通語彙はどうやって習得されるか
    • 共同体の一員として
    • 共同化
  • コミュニケーションの難しさ

  • 組織が違うなら目的も違う

  • 囚人のジレンマ、互いに個別に最適化をした結果、全体最適ではない解に落ちる

  • 囚人のジレンマの解消法、観察者の導入

  • このネットワーク構造の成立要因

  • IPAが行う事業のネットワーク形成システム

  • 大学は有望な選択肢

    • 卒業後に異なる立場になる人とのネットワーク形成
  • 企業の場合は退職者との関係維持や、パラレルワーク

講義ドラフト