Jupyter NoteBookでは、ソースコードを始め、プログラムの実行結果など，プログラムに関するすべての情報をノートブックと呼ばれる単位で管理する。
ノートブックの画面は、ソースコードを入力するセルと呼ばれる部分と、その実行結果を表示する部分で構成されている。
セルは必要な分だけ用意できるので、いきなり長いプログラムを1つのセルに入力するのではなく、複数のセルに小分けにして入力し、それぞれのセルで実行結果を確認しながら作業をすすめ、最終的に1つのプログラムにする、という開発ができるのが特徴。

■ノートブックの作成

してみたら500エラーが起きた。。。現在調査中

【pythonエラー対処】jupyter notebook 500 : Internal Server Error | In-Silico NoteBook

500エラーは、Anacondaをアップデートすることで解決できた。
システム開発ってこういうことがあるから難しいよね。

物体・画像認識と時系列データ処理入門 [TensorFlow2/PyTorch対応第2版] NumPy/TensorFlow2(Keras)/PyTorchによる実装ディープラーニング

作者:チーム・カルポ
秀和システム

Amazon

2023-08-27

2. 座組とチームビルディング

プロジェクトマネジメント

-- 失敗すると取り戻すのが大変。

座組が適切でないとプロジェクトの障害となることがあるため、

プロジェクト計画の段階で座組が適切なものになっているか確認する。

何千万円と大きなお金が動くプロジェクトであるにもかかわらず、社内政治や人材不足でなんとなくプロジェクトのキーパーソンのアサインが決められていたり、偉い人の付き合いで実力が伴わないベンダーが選定されてたりと、不思議なことに座組が軽視されるケースは実は多い。

座組は発注者や自社内の決済者の確認や承認プロセス、実行を担当するプロジェクト全体の体制を指す。

座組はプロジェクトの外部環境も含むため、プロジェクトマネージャが決めるというより前提条件として与えられることが通常。

座組は一度固めてしまうと、組み直しが極めて難しいもの

プロジェクトの途中で座組を組み直そうとすると、人や企業を入れ替えるといった政治的な交渉や調整が必要になり、難航しがち。組み直しが原因でプロジェクトの継続が危機に陥る可能性も十分ある。

プロジェクトに失敗しても自らの懐は痛まないなどという気持ちでいると、

組織の事業計画に遅れや停滞が生じたり経済的なダメージを受けたりする
プロジェクトが炎上して、プロジェクトメンバーの生活や心身、家庭がダメージを負うことにつながる
炎上したプロジェクトからはメンタルを病む人や転職してしまう人が出て、組織はさらに人材の面でもダメージを受ける。
プロジェクトが失敗すると、社内でも責任のなすりつけ合いになることもあり、その結果、関わった人が組織内での評価を失うことにもなります。

プロジェクトが適切な座組になっているかどうかのチェックポイントは2つある。

ステークホルダー(利害関係者)のリテラシーレベル
関係者のマインドチェック

-- ステークホルダー(利害関係者)のリテラシーレベル

新規事業や業務改善ではIT(情報通信技術)を完全に切り離して考えることが難しい時代になっている。
だが、現実には年齢や経験の差によって、ステークホルダーのリテラシー(知識)レベルはばらばらであることが通常
ITは目にみえず、絶えず進歩しているため、正確に理解するためには専門知識や継続的な業務経験を必要とする。
プロジェクトで必要な技術のリテラシーレベルが低い人が意思決定者であったり重要な関係者で合った場合は、資料作成や打ち合わせの説明で多くの労力を必要とする。また、理解力が足りないため、プロジェクトにとって間違った判断が下させるリスクがある。

CHAT GPTで子供にもわかりやすくしてみた。

新しいビジネスや業務を考える時、コンピューターやインターネットみたいなテクノロジーを使うことが普通になりました。でも、みんながそれを同じくらい知っているわけじゃないんだよ。年とか経験によって、知識のレベルが違うんだ。テクノロジーは目に見えないし、いつも進化しているから、それを正確に理解するには、専門的な知識や経験が必要なのさ。

プロジェクトでテクノロジーの知識が足りない人が、大事な決定をする人か重要な人と一緒にいると、資料を作ったり説明をしたりするのが難しくて、たくさんの労力がかかるんだ。それに、理解が足りないと、プロジェクトが失敗するリスクもあるんだよ。

対策

そのプロジェクトで必須となる技術や専門知識があったら、「大事なことを決定する人がどれくらい理解しているか」をヒアリングの際に確認しておくといいよ。
その際、その人が分かっていると思っていることや、肩書を信用しすぎないようにしよう。その人が技術を知っているつもりでも、昔の知識でまったく通用しなかったり、昔に少し関わっただけで深く理解していないケースも残念ながらあるよ。
「プロジェクトそのもの」についての知識が足りない場合は、何が急に起こるか分からないことを上手くやらないといけないことを理解していないために、あとから、大変なことを言ってきたりすることがあるよ。ヒアリングやプロジェクト計画を説明するときに、こうした姿勢がないかチェックしておくのがよいよ。