Pythonの開発環境では、Pycharmが使いやすい。
デバッグやリファクタリング、色やキー操作の細かな設定が優れている。
しかし、PycharmのCommunity版では、ipynbファイルは素のJsonファイルで表示されてしまって使いにくい。
調べてみたら、下記のやり方で、Pycharmからjupyter notebookを起動してブラウザ上で表示できるようになる。
PyCharmでjupyter notebookを使用する方法（Windows10） - Qiita
一方、VSCodeでjupyter notebookを使用するには、Pythonエクステンションを入れるだけ。
ブラウザ上のでjupyter notebookではなく、VSCode上でipynbファイルが自動変換されて表示されるので便利。
VS Code でPython，Jupyter を動かす - Qiita
jupyter notebookを使いたい場合、PycharmCommunityよりもVSCodeが手に馴染んでいい感じ。
「ゼロから作るDeep Learning」を読み始めた。
一気に7章まで読んだ。
理論とPythonの実コードを行ったり来たりする説明がとても素晴らしい。
思いつきをメモ。
【参考】
ゼロから作るDeep Learningのメモまとめ - Qiita
ゼロから作るDeep Learningで素人がつまずいたことメモ: まとめ - Qiita
以前から、機械学習やら深層学習に関する本は斜め読みで乱読してきた。
また、統計検定やQC検定の資格勉強を通じて、実際に使う統計理論と、メーカーによる品質管理の事例のイメージは分かっていた。
だから、理論の部分はだいたいイメージできていた。
でも肝心のソースが今まで分からなかったので、ブラックボックスみたいなイメージだった。
PythonもNumpy・Pandas・MatPlotlibもある程度慣れたおかげで、Pythonのソースコードを読みながら、なるほど、こんなアルゴリズムで作っているのか、割とベタベタにプログラムを書いているんだな、とか、色々気づきがあった。
Githubのソースコードを実際に動かした後で、本の文章の行間に書かれている内容を想像するのが楽しい。
oreilly-japan/deep-learning-from-scratch: 『ゼロから作る Deep Learning』(O'Reilly Japan, 2016)
Githubのソースを動かす時は、下記を参考にした。
Jenga 妄想の大気開放 オライリーの『ゼロから作るDeep Learning」でMNISTデータセットが読み込み出来ない件（Windows10上で動作するeclipseにて）
まだまだ分かってないけれど、いくつか気づきはある。
０か１を返す関数の引数にNumpyデータを渡した時、そのままでは計算できないが、Numpyのトリックを当てはめて解決する。つまり、np.arrayの要素に不等号演算を渡し、np.int型を返すようにする。
この部分は上手いなと思った。
パーセプトロンの合成は行列の積と同値なので、Numpyライブラリが有効に使える。
よって、行列の成分が膨大な個数であっても演算の個数自体はそれほど増えるわけではない。
実際のPythonの計算式では、かなり大きな数同士で四則演算する場合にオーバーフローの問題が出やすいとか
無限大に近い数値が出てしまう時がある。
そこで、あるMax値を付与したり、微小値を式に付与したりする場合がある。
ディープラーニングのような学習プログラムは、学習効率をいかに上げるか、という観点で損失関数をバロメーターにしてその精度を評価する。
これは丁度、小中高校生の学習でも、少ない学習時間でいかに暗記できたり、理解できるか、という観点にもつながる。
つまり、コンピュータの学習も人間の学習も、そのアルゴリズムは同じように思える。
多分そのように思える理由は、深層学習がそもそも人間の脳をパーセプトロンで表現してコンピュータ上でシミュレーションできるようにしたのだから、トートロジーなのかもしれない。
教師あり学習は、今のようなビッグデータと言われる時代では、非常に有効なのだろう。
SaaSで自動的に収集できるログデータ、電気自動車や家電製品から集まるデータなど、現代ではビジネスの副産物としていくらでもデータを集められるので、そのデータを使えば、いくらでも機械学習や深層学習エンジンに食わせることはできる。
強化学習の考え方を深層学習エンジンで実装するアイデアは面白いと思った。
強化学習はエージェントに報酬を与えることで、試行錯誤させながら学習させて賢くさせる。
この考え方は、組織人事理論にある「期待理論」の考え方に似ている。
期待理論では、動機付けの強さは「報酬への期待ｘ報酬への魅力」「期待ｘ誘意性」で決まると考える。
よって、期待理論を実際の組織に当てはめた場合、利益分配制度のような変動給与制、業績連動制度、成果主義人事制度を構築することで、社員の動機を誘発し、誘導させる。
なお、昨今の人事制度構築でも期待理論は非常に有効な考え方と言われている。
つまり、強化学習の考え方は、従来の組織人事理論の期待理論の考え方を適用し、実際にPythonプログラムで実装したに過ぎないように思える。
この考え方を発展させれば、機械学習や深層学習の学習効率を上げたいと研究したいならば、組織人事の理論を片っ端からPythonで実装して、比較すればいいだろう。
もう少し理解できたらまとめてみる。
Pythonのリスト内包表記についてメモ。
Python初心者なので間違っていたら後で直す。
Pythonリスト内包表記の使い方 | note.nkmk.me
Pythonのリスト内包表記はチューリング完全だから純LISPだって実装できる - Qiita
Pythonの習得を始めたところ、Rubyと微妙に異なる点でいくつかハマった。
個人的には過去の記事が参考になった。
【Ruby】PythonプログラマーがRubyを触って感じたこと - 歩いたら休め
（引用開始）
逆に、RubyのプログラマーがPythonを勉強したいなら、以下の3点を押さえておけば、ちゃんとしたプログラムが書けると思います。
リスト内包表記
ジェネレーター（遅延評価）
ふつうに定義した関数がオブジェクトであること
（引用終了）
確かに、リスト内包表記が一番難しく感じた。
個人的には、
[str(i) for i in [1, 2, 3]]
と書くよりも
list(map(str, [1, 2, 3]))
の方が読みやすいし理解しやすい。
[i for i in [1, 2, 3] if i % 2]
よりも
list(filter(lambda x: x % 2, [1, 2, 3]))
の方がカッコよく感じていた。
しかし、mapやfilterよりもリスト内包表記の方が高速らしいので、リスト内包表記を使うべきなのだろう。
実際、Pythonのリスト内包表記は奥が深い。
Pythonのリスト内包表記はチューリング完全だから純LISPだって実装できる - Qiita記事が面白かった。
（引用開始）
Pythonにはリスト内包表記というとても便利なものがあります。
どれくらい便利かというと、チューリング完全です。
（引用終了）
最初の印象は、for文を使いまくって手続きっぽいな、Rubyのブロックみたいに書ければ綺麗なのに、と思っていたが、Pythonはリスト内包表記があるから関数型言語の側面もあるのだ、と感じた。
Pythonで色々書いてみた気づきは色々ある。
Pythonのmap, filter, reduceは、Rubyのmap(collect), select(find_all), reduce(inject)と同じだが、文字・リスト・ハッシュ(辞書)のメソッド名が微妙に異なっている。
例えば、PythonはList.remove(要素)、RubyはArray.delete(要素)。
例えば、PythonはList.extend(要素)、RubyはArray.push(要素)。
Rubyのクロージャはブロックで簡単に書ける一方、Pythonのクロージャは、関数内関数を使う。
その時、関数内関数の外側の変数は参照できるが、更新したい時は、nonlocal宣言が必要。
その点は、何となくPerlに似ている。
Rubyではインスタンスメソッド、クラスメソッド(特異メソッド)が単純に書けるが、Pythonでは、インスタンスメソッドの第1引数にselfを明示したり、クラスメソッドにはアノテーションを付けて第1引数にclsを明示する。
その点は、Pythonは機械語により近い感じがする。
Pythonは多重継承をサポートしている部分は驚いた。
JavaもRubyも、ほとんどのプログラミング言語も多重継承はないから。
Rubyなら継承チェーンは必ずツリー構造なので、メソッド探索は単純だが、Pythonで多重継承ができるとなると、いわゆる菱形継承が問題になってくる。
どうやって解決しているのか、調べてみる。
教育における読み書きというアナログの重要性の記事をリンク。
オンライン教育に関する主張のないラフなメモ書き。
【参考】
｢ノートが取れない｣中学生。日本の子どもたちの読解力はなぜ落ちたのか。新井紀子さんインタビュー | Business Insider Japan
読解力不足をどうとらえるか～新井紀子さんの答えをまとめる～: 風にふかれて
一人に一台、タブレットPCを配りますか？（その２） | ICT for Development .JP
オンライン授業でもアナログ感あるデザインで「考えること」を促す｜Yoshikazu TATENO | たってー｜note
【1】2020年4月時点では、日本の小中高学校はほとんどが休校状態なので、ほとんどの子供は勉強すらしていないだろう。
自ら目標を立てて、自ら題材を探して知識やスキルを身に着けていく、という作業は、大人でも難しいのだから、ましてや普通の子供ができるようには思えない。
そもそも、それができる子供であれば、学校という仕組みがなくても、自立していけるだろう。
とはいえ、昨今ではそういう能力が早い段階から期待されているけれど。
しかも、学校だけでなく対面の学習塾も閉まっているので、オフラインで先生から教えを請うこともできない。
公立図書館、大規模書店も閉まっているので、紙の書籍すら手に入らない。
結局、オンライン教育に頼るしかないけれど、色んな理由でおそらく日本の環境では敷居が高いのだろうと思う。
PCやWifi環境というIT基盤だけでなく、子供の適正に見合った教育方法とか、色々試行錯誤する問題があるだろうと推測する。
響いた言葉を引用しておく。
【2】「読む」「書く」はプログラミング同様に不自然な行為
（引用開始）
４ 新井さんの著書を読むと、むしろ読解力を上げるには、板書をするなど「書く」行為をさせること、つまり「昭和的」な教育の方が効果が上がった実例が書かれています。ＩＣＴ教育を進めて、読解力が上がるとは思えないのですが、どうでしょうか？
①「書く」行為は、そもそも人間にとって不自然な動作であると認識してほしい。「読む」「書く」はプログラミング同様に不自然な行為ですから、その時代と環境と要請に従って、カリキュラムを構築して確実に身に付けなければならない。
②けれども、私たち大人は、自分が子供だった時代に、読み書きを「自然に」身に付けた思い込んでいます。ですから、自分たちの子供の世代も、放っておけば、「それくらい」はできるだろうと信じています。でも、自転車もただ乗れるようになるわけではないのと同じように、字を書くというのは相当に集中力とトレーニングが必要なのです。
（引用終了）
「「読む」「書く」はプログラミング同様に不自然な行為」という指摘は同意する。
学習や勉強は割とアナログ作業が多い、という気はしていたから。
だから、アナログ作業であるがゆえに、それに適した訓練は必要だろう。
ただし、学習は割とアナログ作業が多いという現状は2つの側面があると考える。
学習という作業は、読む・聞く・書く・話す、など五感を使った動作が多いので、身体で覚えるべき部分が多いという点。
一方、日本では高校入試や大学入試がペーパーテストなので、問題を読んで答案に書く、という試験そのものに対応した技術が必要である、という点。
読む・聞く・書く・話すを使った学習を訓練する時、前者と後者のどちらに比重をおく方が効果的なのか、という疑問はある。
個人的には、後者のペーパーテストの為の訓練は不要と思うが、結果的にそれに適合しすぎた人達を生んでいる事象も多いのだろう。
また、プログラミングも不自然な行為、という指摘は同様に思う。
新しいプログラミング言語を覚えて習得していく時、今までとは違った頭の使い方を要求させられる。
AWSやアジャイル開発など新しい技術を習得していく時も同様。
周囲を見ていても、プログラミングの習得が早い人とそうでない人には、雲泥の差があると実感する。
「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索の通り、プログラミング能力は、読み書き以上に、その人の向き不向きが現れやすいのかな、と思う。
プログラマの能力や生産性は10～100倍以上の差が出る、という点は、そういう所に原因があるのかもしれない。
【3】タブレット教育、アクティブ･ラーニングは高度な能力を必要とする
（引用開始）
６ 一人一台タブレット政策。小学校からのタブレット導入については、どうでしょうか。
①これは、もう終わりだな、と。特に小学生は絶対タブレットは良くないと私は確信しています。
②先進的に導入した私立学校や家庭で既に弊害が出ています。小学校からタブレットドリルで学ぶと、紙や長文にはもう戻れないのです。意外なことですけど、検索すら自分ではできない生徒が出てくる。学びが常に“消費的”になるのでしょう。けれども、大学や社会で求められる学びは“生産的”な学びなので、タブレットドリルで育った子は立ち直れないほど挫折してしまう。
③タブレット導入で今まで７時間かかっていた授業が２時間で終わり、残りは深く考える授業に当てるというような授業は、麹町中学校のようなある意味「特殊な環境」の学校だけでできることだと思います。それが本当に地方でもできるのかも検証せずに、タブレットという言葉が一人歩きしています。
④しかもローマ字入力ができるのは、小学校５，６年生なので、それまでキーボードは使えません。その間、一体何をやるのでしょう。
（引用終了）
（引用開始）
②日本の公教育以外で格差をなくす平和的な方法はないと思っています。
ちなみに、アクティブ･ラーニングは格差を広げてしまいます。それは戦後最初のアメリカ主導の学習指導要領である、ディーイ式の「生活単元学習」の失敗で明らかになっています。
③小学生のうちは比較的ワイワイやっていますが、中学生になると、出来る子が言ったことに他の子は追随します。だから、授業を全てディスカッションでやることは、現場を見ていない人の寝言に過ぎない。
（引用終了）
昨今流行しているタブレット教育、アクティブ･ラーニング教育を批判する理由が参考になる。
著者の方はおそらく、現場経験が豊富で、数多くの失敗事例も見ているのだろう。
現状では感染症の流行が終わらない限り、オフライン教育は無理でオンライン教育にシフトせざるを得ないだろう。
しかし、そういう指摘の元で、今後のオンライン教育を考えると、子供の成熟度に見合ったオンライン教育の方法を見つけないと、教育を受けられなかった世代や就職できなかった世代を大量に生み出してしまう事になる。
今後、試行錯誤しながらオンライン教育の可能性を探っているしかないのだろう。
残念なことに、日本では、教育現場が最もIT技術が遅れた場所であり、知識だけでなく環境も揃っていないので、数多くのハードルが高いのかもしれない。
【3】オンライン教育の手法は、実は、以前からMOOCなど反転教育の概念で知られていた。
具体的には、自宅でオンラインで講義を受けた後、学校で対面で先生に質疑応答して疑問点を解決していく、というやり方。
サルマン・カーン「ビデオによる教育の再発明」 - YouTube
『世界はひとつの教室』技術、教育、そして世界は動く - HONZ
教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索
知的誠実さの大切さ～Moodleが持つ教育のイノベーションの可能性: プログラマの思索
サルマン・カーンのYoutubeの説明を見た時に、講義の動画配信、子どもたちのテスト結果の採点・集計・分析・フィードバック・理解度確認などのシステム基盤などITを駆使しながらも、「技術を使って、本来の教育をヒューマナイズする（humaizeする）」という彼の言葉がすごく引っかかった。
IT技術を使うことで人的関係を効率化させて、人的介入を減らすのではなく、逆に、コミュニケーションや対面のやり取りの密度や濃度を上げていくのだ、という意見が半常識的に感じたからだ。
おそらく、こういう取り組みも現場で試行錯誤しながら、時間をかけてあるべき姿を探っていくしかないのだろう。
MLOps（機械学習基盤）の記事が面白かったのでメモ。
【参考】
機械学習システムの設計パターンを公開します。 - Mercari Engineering Blog
mercari/ml-system-design-pattern: System design patterns for machine learning
機械学習システムにおける「技術的負債」とその回避策 - Qiita
“Hidden Technical Debt in Machine Learning Systems”
記事を読んで理解したことは、機械学習はアルゴリズムが重要なだけではなく、そのシステムを支える開発基盤の構築に膨大な工数がかかること。
データ収集・分析だけでなく、データや分析結果の構成管理、サーバー・システム監視なども含まれるので、開発もインフラ基盤も両方とも詳しくないと、システムの全体像を把握することすら難しいだろう。
一昔前の業務システム開発よりも、はるかに難易度は高いと思う。
ゆるふわMLOps入門 - Re:ゼロから始めるML生活に紹介されている先進企業の事例が参考になる。
Google、Facebook、Netflix、Airbnb、Uber くらいの大企業であれば、自前で構築して、その基盤を他企業や一般利用者にも使わせることで、サブスクリプションサービスによる売上、エコシステムの拡大を狙っているわけだ。
この辺りの技術も探してみる。
行動経済学の記事を読んで、チームビルディングやプロジェクト運営に行動経済学の知見を活用できると面白いだろうな、と思った。
ラフなメモ書き。
【参考】
わずか15年で3件ものノーベル賞を出した「行動経済学」の知見が、仕事の役に立ちすぎる件。 | 識学式リータ゛ーシッフ゜塾
マーケティング活動に活かせる行動経済学の基礎知識５選 | PINTO!
IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索
【1】上記の記事には下記の例がある。
1.上司への悪い報告は、良い報告とセットで。かつ悪い話は先にせよ。
「終わり良ければ全て良し」のような経験則が人には染み込んでいるので、その先入観を活かす。
2.人材育成は「褒めても叱っても同じ」
(引用開始)
実際は、単に結果がランダムであり、「極端に悪かったら、次回はすこしマシになる」「極端によかったら、次は当然悪くなる」という現象が起きていただけだ。
(引用終了)
そう簡単に人材育成はできない。
3.昇給はできるだけ小刻みに。できる社員にはカネでなく「地位」を。
(引用開始)
具体的に言えば、年収400万円の人が、年収600万円となったとしても、それはたった４年で「慣れて」しまう。
要は「思い切って給料を上げて、従業員を幸福にする」のはコストパフォーマンスが悪い。
(引用終了)
社員への報いは、お金よりも地位を与えた方がコスト面で良い、ということか。
4.成功企業を検証して法則を導こうとする行為は無意味
過去の成功事例は、「ハロー効果と後知恵バイアス」を起こしやすい。
(引用開始)
これは、人間は「うまくいっている企業には、必ずなにか合理的な理由があるはずだ」と思い込んでしまうためによる。
だが実際、データが証明しているのはそれと真逆の結果だ。
分析から導き出した法則の多くは普遍性、再現性がない。「その時」「たまたま」うまく行ったことがほとんどなのだ。
(引用終了)
5.「わかりやすい」だけで、「知的だ」「信頼できる」と認識される
(引用開始)
これは人間の脳が「認知に関しての負荷が低いほど、好ましいと感じる傾向」を有しているいことに由来する。
(引用終了)
プレゼンではこのテクニックをうまく活用すべき。
【2】心理学の知見を使って、人間の言動が人事制度やチーム運営、経営などにどのような影響を与えるのか、を研究して、その経験則を生み出すのは面白い。
こういう行動経済学の学問は、昨今は、従来からの統計学の理論とコンピューティングパワーの強化によってすごく研究しやすくなったのだろうと思う。
【3】個人的には、チームビルディングやプロジェクト運営に行動経済学の知見を活用できないか、と思う。
プロジェクトリーダーがどのような言葉遣いや行動を行えば、チームをまとめて、プロジェクト運営をスムーズに行えるのか？
プロジェクトリーダーはどのような言動を行えば、リーダーシップをより一層発揮できるのか？
ソフトウェア行動経済学のようなものがあっても面白いだろうと思う。
astahによる状態遷移テストの事例が紹介されていたのでメモ。
【参考】
状態遷移テストと1スイッチカバレッジ｜Tsuyoshi Yumoto｜note
astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索
上記の記事を読んで、自分の気付きがいくつかあった。
テスト技法には、デシジョンテーブルやオールペア法のような組合せテストが多い気がする。
それらは「テストパラメータの事前入力のバリエーション」に注力する。
一方、状態遷移テストでは、「テストケース構造の事前状態（事前条件）に着目」する。
つまり、単なる事前入力値の組合せだけでなく、事前入力の状態までの履歴も考慮する点が異なる。
この指摘は、改めて気付かされた。
状態遷移テストには、テストカバレッジの考え方にN-switch coverageがある。
詳細は下記を参照。
状態遷移表を使用したテスト手法【後編】 (1/3) - MONOist（モノイスト）
おそらく、単体テストレベルでは0-switch coverage、結合テストでは1-switch coverage、総合テストでは、N-switch coverageのようなイメージもあるだろう。
つまり、条件分岐処理に関するC0・C1・C2網羅のような考え方と同じく、状態遷移テストでもN-switch coverageを考えることでテスト網羅性を高めるわけだ。
では、どうやって、0-switch coverageやもN-switch coverageのテストケースを作るか？
おそらくテストケース生成ツールなしでは、状態遷移テストの網羅性を高めることは難しいだろう。
幸いなことに、astahでは品質管理プラグインがあるおかげで、状態遷移図を描けば、状態遷移表を生成し、それに基づくテストケースをExcel出力することができる。
開発者もテスト担当者も、精度の高い状態遷移図を描くことに注力するだけでいいのはすごく良いメリットだ。
改めて思うのは、テスト技法はモデリング技法に密接に関係している。
その意味は、単にモデルの正当性にテストが必要、というだけではない。
開発したソフトウェアをテストするには、何らかの観点が必要であり、それはモデルが提供すべきもの。
モデルがテスト技法を支援しているわけだ。
そういう考え方も色々考えてみる。
「ソフトウェア・ファースト」を読んだので、感想をラフなメモ書き。
非常に良い本だったので、自分の気づきをメモしておく。
【参考】
ソフトウェアファーストを読んで開発組織と外部委託について考えた | masaytan's blog
『ソフトウェア・ファースト』読書メモ その１ - Qiita
ノンプログラマーの機械屋が読んだ「ソフトウェア・ファースト」
【１】「ソフトウェア・ファースト」は良い本だ。
「ソフトウェア・ファースト」のターゲットは、特にメーカーの経営陣、中間管理職の人達だと思う。
そういう言葉は書かれていないが、トヨタの話やメーカーの生産管理とソフトウェア開発の比較、などの話が多いので、メーカーの人にはとても響くだろう。
特に、メーカーにいて、ITに詳しくないが、ITが経営に直結している立場の人達、つまりメーカーで経営上の意思決定をする人達が読むべき本だ。
どのメーカーも、トヨタが生み出したJIT生産、なぜなぜ分析、自働化など数多くの概念を自社に取り入れようと努力してきたから、あのトヨタも変わっているのか、と気づくだろう。
【２】IT技術者として「ソフトウェア・ファースト」を読んで興味を惹いた部分はいくつかある。
【３】メーカーがソフトウェア開発を内製化していない点を痛烈に批判している。
メーカーの生産管理では、自社の工場で生産計画・生産統制をできるだけ内製化し、その品質管理だけでなく、外部取引先から調達する部品の品質管理も徹底的に行なっている。
「手の内化」というトヨタの言葉はその通り。
たとえば、日本の元請け企業は自社の技術社員を、下請け企業に派遣して、調達する部品の品質管理や進捗管理を行うだけでなく、わざわざ下請け企業の社員に技術指導まで行っている場合が多い。
つまり、日本のメーカーは、自社の工場だけでなく、自社の製品に関わる下請け企業までを生産管理の対象とみなし、一連のサプライチェーンを品質管理することで、品質向上を図ってきた。
だから、日本の製造業が生み出す製品の品質はとても高い。
一方、メーカーのソフトウェア開発では、自社でソフトウェア開発は内製化しないだけでなく、外部からの委託・調達したソフトウェア製品やソフトウェア成果物の品質管理すらも全くできていない。
つまり、メーカーは製造プロセスのサプライチェーンまで自分でコントロールしているのに、なぜ、ソフトウェア開発ではまともな品質管理すらせず、コントロールしないのか、と。
IT技術は知らないから、というのは言い訳に過ぎない、と痛烈に批判している。
たとえば、「ソフトウェア・ファースト」の一節に、トヨタの豊田章一郎社長が社長に就任した時に、企画開発チームに実際に赴いてその知見を乞うたが、あのトヨタの社長でもそうならば、ITが経営上重要になっているならばソフトウェア開発の現場に経営陣も自ら赴くべきではないか、と。
３現主義と言いながら、ソフトウェア開発の現場は見ていないでしょ、と。
【４】SaaSはソフトウェアの特徴をうまく活用している、という主張は本当に興味深い。
SaaSの最大の特徴は、ユーザの生の声をフィードバックで収集できる点だ。
自動車であれ大半のメーカーでは、工場や最新機械などの固定費が膨大な為、資本を減らすために、販売店などを切り離している。
よって、メーカーは販売した製品に関する消費者の生の声を集めるチャネルを持っていない弱点がある。
この弱点は、昨今のGoogle・Apple・Facebook・Amazonを見る通り、メーカーにとって致命的。
トヨタのようなガソリン自動車メーカーは直販プロセスを持っていない一方、後発の電気自動車メーカーであるテスラは、直販チャネルを持っている上に、さらに、自車の運行データをユーザから収集して自動運転に活用しようとさえしている。
Saasでは、ユーザの生の声はカスタマーサポートからシステムのアクセスログに至るまで、数多くのチャネルがあるので、それらを収集して分析することで、より良い製品へ改良するきっかけになるし、開発チームにとっても、製品改良のモチベーション向上にもつながる。
特に、GAFAは、ユーザのフィードバックの収集・分析・改良・リリースという一連のプロセス構築がうまいのだろう。
その一連のプロセスは、アジャイル開発そのものだ。
従来のメーカーが大事にしてきたPDCAサイクルとは本質的に違っていると思った方が良い。
僕自身が持つアジャイル開発の認識も古くなっていると思った。
僕は以前は、アジャイル開発の本質は小規模リリースだ、と思っていたが、今は１日数十回もリリースできるような高速な開発プロセスにまで洗練されている。
そのアジャイル開発の本質は、DevOpsだ。
DevOpsは単に、運用も開発もチームが一体化したもの、という認識だけではないと考える。
ソースを機能改善したら即反映できるリリースプロセスを整備したもの、と認識すべき。
以前のアジャイル開発のボトルネックは、リリース工程にあったと思う。
継続的インテグレーション、継続的デプロイなどがXPのプラクティスにも含まれていたが、それらが重要なプラクティスであった理由は、リリース工程がソフトウェア開発の最大のボトルネックだったからだ。
実際、今でもWF型開発でソフトウェアを開発していれば、製造工程よりもテスト工程とリリース工程で膨大な工数がかかっているはずだ。
多くのプロジェクトマネージャは、テスト工程でリリース工程で手を焼いているはずだ。
つまり、下流工程と呼ばれるテストやリリースの工程がソフトウェア開発のボトルネックであり、それを制御するのは難しい、という現実を示唆していたのだと思う。
しかし、今では、クラウド上でカナリアリリースやInfrastructure as Codeのように、本番環境やリリース作業を構成管理の配下でコントロールできるようになったおかげで、自信を持ってソースの機能改善ができるし、新機能に挑戦できる心理的メリットも生まれているはずだ。
つまり、システムの機能改善という、ソフトウェアの本質的な価値を具現化するものにより力を注げる開発プロセスを構築できるようになったわけだ。
【５】メーカーがソフトウェア開発を内製化した時の組織構造や組織文化の話も非常に興味深かった。
一読した限りでは、メーカーの組織文化とソフトウェア開発の組織文化は水と油なので、ソフトウェア開発は別の組織で分社したり、企画開発に特化したり、マトリクス型組織にする、などの示唆があったのは興味深い。
たぶん、著者自身も数多くの試行錯誤をされているのだろう、と思う。
メーカーではないが、サイボウズの組織構造の変化のコラムが興味深かった。
サイボウズも中小企業だった頃は、機能別組織であって、開発・運用基盤・企画営業など縦割りの機能に分かれていた。
しかし、SaaSを販売してユーザのフィードバックをSaaSに反映していくようになると、そういう縦割りの機能別組織では、社内のコミュニケーションが取れず、現場が混乱した。
そこで、製品別組織に立て直し、企画から開発・運用に至るまでのプロセスを一つの部門で担当できるようにしたら、上手く回るようになり、組織文化も良くなっていった、という。
つまり、機能別組織から事業部制に変化したわけだ。
この話を読んで、チャンドラーの「組織は戦略に従う」という文言を思い出させる。
チャンドラーの組織発展モデルでは、企業内部の組織は事業の発展によって、単一の機能別組織から事業部制組織、そして分社化した子会社・関連会社を持つコングロマリットという多国籍企業へ変わっていく。
ソフトウェア開発の組織構造も、メーカーと異なっているとしても、組織構造のモデルという自然法則に従わざるを得ないわけだ。
【６】ソフトウェア開発組織の職種として、エンジニアという技術専門職だけでなく、プロダクトマネージャーとエンジニアリングマネージャという管理職も上げている点が興味深かった。
僕の理解では、エンジニアリングマネージャはアーキテクトかつプロジェクトリーダーのイメージ。
プロダクトマネージャーは、Scrumのプロダクトオーナーのイメージ。
プロダクトマネージャは、ソフトウェア開発の経験があるのは良い点だが、その経験が逆に邪魔する時がある。
本来の製品のあるべき姿は、その時代の技術の制約から離れて考えるべきなのに、ソフトウェア開発の経験が邪魔して、その時代の実装方法に依存した製品イメージを描いてしまい、本来の姿とかけ離れてしまう弱点もある、と。
そういう指摘は非常に参考になった。
「Rubyのしくみ」の感想とRubyの感想をラフなメモ書き。
主張は特になし。
間違った点は後で直す。
【参考】
書籍紹介『Rubyのしくみ Ruby Under a Microscope』
『Ruby のしくみ』を読んだ - blog.kymmt.com
『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第1~5章＞ - kenju's blog
『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第6~7章＞ - kenju's blog
『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第8~9章＞ - kenju's blog
『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第10~11章＞ - kenju's blog
『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第12章＞ - kenju's blog
Rubyの定数探索、instance_evalやmodule_evalの挙動、特異クラスの性質について、分かったような気がしないので、「Rubyのしくみ」を買って読んでみた。
「Rubyのしくみ」の中身はかなりDeep。
まだ全部は分からない。
RubyがYARVというVMベースのインタプリタ言語であることも、この本を読んで初めて知った。
JavaがJavaVMで動いているのと似ているが中身は全く違う。
「Rubyのしくみ」を読んで、良かった点と自分の気づきをメモしておく。
【1】下記の章が読みたかった部分だった。
第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング
Rubyは、他のプログラミング言語に比較すると、ほぼ完璧なオブジェクト指向言語と思うので、メモリ上にオブジェクトやブロックがどのように実現されるか、というイメージがないと、本当に理解できた気にならない。
ソースコードを解釈したイメージの絵を多用しているので、理解しやすくなっているのは良い。
【2】「Rubyのしくみ」を読んで、include/prepend/refinementsの仕組みが腑に落ちた。
Rubyのモジュールは、内部ではクラスと同じ。
includeの実装は、インクルードしたモジュールをクラスとしてコピーして、継承チェーン上に挿入するイメージ。
prependの実装は、prependを含むクラスをoriginクラスとしてコピーして、継承チェーンの最下部に挿入するイメージ。
prependを使えば、簡単にオーバーライドできるので、エイリアスメソッドチェーンを多用する必要もない。
refinementsも、refineしたクラスを無名クラスとしてコピーして継承チェーンの最下部に挿入するイメージ。
【3】Ruby特有の仕様がある点に注意する。
RubyはJavaと違って、インスタンス変数とクラスインスタンス変数は明確に異なる。
それぞれインスタンスメソッド、クラスメソッドでアクセスして編集する。
Javaと違って、オブジェクトは必ず特異クラスも持つ。
クラスメソッドは、該当クラスの特異クラスに住んでいる。
もちろん、特異クラスにあるクラスメソッドとインスタンスメソッドは異なる。
Rubyのメソッド検索は、継承チェーンを下から辿ってマッチするまで探す。
マッチしなければ、method_missingで補足されて、NoMethodErrorになる。
他方、動的プロキシでは、method_missingでゴーストメソッドを補足して、別メソッドに変換してしまう。
Rubyの定数検索は、まずレキシカルスコープで定数を検索し、その次に継承チェーンで定数を検索する。
レキシカルスコープで定数検索するロジックは、Module.nestingの順に検索すること。
この仕組みを知らずに何度も引っかかった。
ブロックはRuby特有の書き方の気がする。
Rubyのブロックに慣れたら、JavaScriptやPythonよりも直感的で、読みやすく感じる。
メタプログラミングはRubyの真骨頂。
JavaやC#がXMLを多用するのとは違い、Rubyは内部DSLで全てRubyで実現できるのは素晴らしい。
JavaやC#が嫌になる時は、XMLばかり書かされている時と同じだから。
instance_evalもclass_evalも、evalと仕組みは一緒。
但し、処理は異なる。
instance_eval内のメソッド定義(def～end)は特異メソッドになるので、インスタンスメソッドを定義したい場合は動的メソッド(define_method)を使う。
一方、class_eval内のメソッド定義はインスタンスメソッド。
また、instance_eval do～endと、instance_eval(<<-EVAL)：ヒアドキュメントでは、定数検索が異なる。
Module.nestingで出力してみると、前者は[]なのでトップレベルの定数、後者は[特異オブジェクト]なので、特異オブジェクトに属する定数になる。
この点も知らずによく引っかかった。
Proc#[]という書き方があるのもびっくりした。
「改訂2版 Ruby逆引きハンドブック」を読んでいたら、メソッド呼び出しに似せるためにProc#[]のように書く、という説明があって、なるほどと理解できた。
【4】Rubyには異音同義語が割と多くある。
mapとcollect、injectとreduce、selectとfind_all、detectとfind。
lengthとsize, count。
他にもいっぱい。
aliasはキーワードで、alias_methodはModuleのprivateメソッド。
undefはキーワードで、undef_methodやremove_methodはModuleのprivateメソッド。
module_functionで、メソッドを関数化できる。
RubyはVerUpで言語仕様がどんどん機能追加されているので、その歴史による経路依存性のせいかもしれない。
【5】Ruby初心者が悩みがちな特殊記法も多い。
慣れれば、短く書ける。
Ruby初心者を脱した人が悩みがちな、ちょっと特殊な記法・演算子・イディオム - Qiita
*args：配列で受け取る可変長引数。splat引数。
**opts：ハッシュで受け取る可変長キーワード引数。
*変数：splat演算子で配列要素を展開する。
&block：ブロック引数。
&:method_name：メソッドに & とともにシンボルを渡すとto_proc が呼ばれて Proc 化され、それがブロックとして渡される。
なお、メソッドオブジェクトを呼ぶ場合、&method(:メソッド)を使う。
動き方は、(1)Object#method でオブジェクトにあるメソッドをオブジェクトにする。(2)メソッドオブジェクトには、Object#to_proc があるので、&演算子でブロック引数に渡すことができる。(3)メソッドをブロック引数に渡すことができる、になる。
_変数：使わない変数名を宣言。だから、Rubyのローカル変数は「英小文字かアンダースコア(_)始まり」になる。
||=：通称「nilガード」。初期化イディオムとして使う。
<=>：宇宙船演算子、UFO演算子
->：lambda式で用いる「lambdaリテラル」や「アロー演算子」と呼ぶ。
「::」：スコープ演算子。ネームスペースで使う。定数探索でよく出る。
=>：「ハッシュロケット」と呼ばれ、ハッシュリテラルを書く際にキーと値を区切るもの。
「&.」：呼称はSafe navigation operator、通称ぼっち演算子。obj&.my_method形式でのメソッド呼び出しで、objがnilでなかったらmy_methodを実行。
「!!」：すべてをtrueかfalseにする。
リモートワークの推進によって、リーダーシップの振る舞い方も変わってきているように思う。
オンラインのリーダーシップの概念が必要になっているように思う。
ラフなメモ書き。
【１】リモートワークのノウハウについては、倉貫さんの会社が日本で一番持っているのではないだろうか。
［議論］新型コロナでリモートワーク急拡大、でも少し変じゃない？：日経ビジネス電子版
相手に「伝わる」ビデオ会議、14の鉄則。全社員リモートワークのソニックガーデンに聞く ｜ iXキャリアコンパス
リモートワークで生産性を上げる仕組みやノウハウが非常に細かく書かれていて参考になる。
そんな記事を読んでいると、いくつか疑問が出てくる。
今までは会社、学校というオフラインの場所で、仕事や教育を行ってきたし、その仕組みに特化するように、洗練されていた。
しかし、昨今のコロナウイルス流行の影響でオフラインの場所を確保できない状況になり、一時的であっても、オンラインで仕事や教育を実施する必要性が出てきた。
すると、感染症が終わって正常の世界に戻った場合、既にリモートワークで生産性が上がっているならば、以前のオフラインの世界に戻る必要はない。
その意味では、現在の感染症は、オフラインの仕組みに依存してきたビジネスモデルそのものも劇的に変更されるだろう。
もはや会社や学校という物理的な場所はなくてもビジネスも教育が回るからだ。
感染症が終わった後の世界では、会社も学校も大きな環境変化が生じているだろう、と推測する。
【２】では、オンラインとオフラインの環境の本質的な違いとは一体何だろうか？
オンラインの作業についての問題点もいくつか出ている。
その問題点は、技術的課題と適応的課題の２つに分けられるだろう。
技術的課題は、オンラインのツールに慣れない、普及しない、環境が揃っていない、など、技術を克服すれば解決できるもの。
たとえば、「強い者や賢い者よりも変化に速い者が生き残る」という言葉は、まさに、オンラインの環境にいち早く適用した人ほどその利益を得やすい事実を示唆していると思う。
一方、適応的課題は、そういうツールや環境が揃ってきた上で、コミュニケーションや意思疎通をより深く太くしていく為には何が必要なのか、それぞれの現場や人、組織に依存したもの。
これらは、コンテキストに依存している場合が多いだろうから、出てきた課題を一つずつ皆で解決しながら、課題のレベルを上げていくしかない。
上記の記事を読んだ後、いかに一人ぼっちにさせないか、という仕組みが非常に重要になっているような気がした。
オンラインのリモートワークの環境になると、身近に物理的に人がいないので、困った時に声掛けできない。
そのために、Twitterのタイムラインのようなデータを流したり、顔を常時写したり、いろんな工夫がされている。
【３】僕が一番興味を持つのは、オンライン環境ではリーダーはどのようなリーダーシップを振る舞う動作が必要なのか、という問いだ。
あるいは、オンライン上のチームビルディングでは何が必要なのか、という問いだ。
倉貫さんの下記の意見に非常に興味を引いた。
(引用開始)
倉貫氏：改めて考えてみると、これまではなんて牧歌的な時代だったんだろうと驚きますね。チームビルディングを「同じ場所に集まる」という偶発的なものだけに頼って、ほとんど何もやらずにさぼってきたのかと、自分の反省も含めて思います。
(引用終了)
従来のチームビルディングの手法は、オフラインの環境に依存しすぎていないだろうか？
従来の手法をそのままオンライン環境に持っていっても、チームビルディングが上手く行かないのは明らかだろう。
【４】会社、役所、NPO法人、コミュニティなどの集団は、必ず何らかのトップとなる人がいて、彼らがその組織文化を生み出す責任を持っている。
組織文化はトップが作り出すものであり、その逆ではない、と僕は習った。
実際、どんな集団も共通目的があり、その目的に賛同した人たちが結集して、集団の目標を実現しようとする。
そういう集団を最初に作る創始者が組織文化を生み出し、メンバーとの化学反応を起こして集団をより進化させていく。
以前ならば、オフラインの空間では、実際に人が集まってトップの話をうやうやしく聞いたり、あるいは、実際にトップが自ら動いて汗をかく場面を見て、メンバーの貢献意欲が刺激されて、一致団結していく、などの事例があった。
しかし、オンラインでは、トップの行動も話も声もPCの画面を見なければ伝わらない。
TV演説に近い部分もあるかもしれない。
以前のオフラインのリーダーシップの発揮方法とは本質的に異なっている気がする。
特に、昔ながらのリーダーシップの発揮方法である「制度的リーダーシップ」は、オンライン環境では非常に難しくなっていると思う。
つまり、役職を前提としたリーダーシップは、オンライン環境ではその権力を影響させにくい。
オンライン環境では、社員が真面目に働いているのか、を管理職が逐一監視するのは難しいからだ。
制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索
最近では、トランプ大統領がツイッターでどんどん発言することで影響力を増しているように、オンラインのリーダーシップの発揮方法はいくつかのやり方があるように思う。
一方、オープンソースの開発のように、最終的に意思決定するリーダーがいたとしても、世界中に散らばった開発者の技術力を結集して、優れた成果物を作っていくやり方もある。
いずれにしても、まだ僕の中ではスッキリした答えは持っていない。
でも、世界を見渡せば、オンライン環境でもリーダーシップを発揮して、メンバーをあるべきゴールへ導くようにメンバーの意欲を向上させることができているリーダーもいる。
彼らはどんなやり方を使っているのか、そのやり方の本質的な特性は何なのか、考えてみる。
最近のコメント