« 2021年1月 | トップページ | 2021年3月 »

2021年2月

2021/02/25

関西IT勉強宴会の感想~コロナワクチン接種管理システムのデータモデリング

関西IT勉強宴会で、コロナワクチン接種管理システムのデータモデリングを解説されていたので、聞いていた。
ラフなメモ。

実際のデータモデリングは、Youtubeの動画を是非見て欲しい。
ITエンジニアであれば、解説の内容や説明の意図はすぐに理解できるはず。

【参考】
緊急開催「新型コロナワクチン接種管理システム」をローコード開発してみた - connpass

「新型コロナワクチン接種管理システム」をローコード開発してみた<第82回IT勉強宴会inZoom> | IT勉強宴会blog

「新型コロナワクチン接種管理システム」のデータモデル公開: 設計者の発言

(1)やっぱりデータモデリングができる人は要件定義に強い。
業務をヒヤリングしただけで、どんなデータモデルが必要なのか、どんな業務フローになるのか、業務のどこにボトルネックが発生するのか、をデータモデルから推測しているし、その根拠を明確に説明している点がすごい。

(2)渡辺さんがメーリングリストで、エンジニアであるならば、要件を聞いて実際にプロトタイプを作って、見せることで理解するよりも、データモデルを作っただけで理解して欲しい。
それがプロでしょ、という意見が本当に切れ味が鋭い。
データモデルが描ければ、データモデル上の制約条件から、業務フローも画面内容も画面遷移もほぼ一意に決まるし、それくらいの内容はエンジニアなら連想して欲しい、と。

| | コメント (0)

デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している

今年のデブサミはOLだったので、在宅勤務中でも、ラジオ番組みたいに流していた。
来年度以後もこういうスタイルであって欲しい。
思いつきをラフなメモ書き。

Developers Summit 2021(2021.02.18-19)

(1)動画を見るよりも、講演者の声がハッキリしているか、発言内容にキレがあるか、の方が印象の残り方がまるで違う。
最近、ClobuHouseが流行しているらしいけど、動画よりも音声の方が今後重視される気もする。

(2)沢渡さんのパネルディスカッションは聞いていてとても楽しい。

ファンを3つ作る。
技術のファン、プロダクトのファン、カルチャーのファン。
デベロッパーこそ、ファンを増やし、自己ブランディングしていくべき。

今はデベロッパーのルネサンス。
コロナ感染の現状では、アナログの環境よりもデジタルな対話が当たり前。

そして、先進的なデベロッパーが使っていたツールが当間になった。
Slack+Zoomが一般的。
会社組織ではTeamsになるだろうか。

つまり、対面の対話が今は物理的に難しくなり、OLコミュニケーションが当たり前となった。
OLツールが使えない人は致命的。
誰とも会話できなくなる。

(3)日立の方の講演では、コロナ禍で社内・プライベートのコミュニケーションが全てデジタル化されたことにより、OSS開発者の価値が上がった、とか、コミュニティ活動の経験者がより上手く適応している、みたいな話があった。
社内の根回し、とか、顧客調整が得意であっても、今はTeamsでやり取りするしか無いから、こういうツールに慣れていないと能力を発揮できない。

一方、OSS開発者は以前から世界中の開発者とオンラインでやり取りしてきたので、何も変わらないし、彼らのやり方をSIも既存企業も真似ようとしている。
また、コミュニティ活動の経験者も、こういうツールに慣れている人も多いし、ノウハウを共有する場作りに長けているから、彼らもその能力を発揮しやすい。

今は、コミュニケーションのスタイルが完全に変わってしまった。

(4)コミュニケーションのスタイルがアナログからデジタルに変わった事態により、何が起きるのか?

年を取るほど、大企業の社内の人間関係をベースにした根回しが期待されてくるが、Teamsでしかやり取りできない現状では、全く無意味なスキルになってる。
新人の営業マンが訓練と称されて、100枚の名刺を配って新規顧客をどぶ板で集める手法も、コロナ感染の現状では実現不可能。

オンラインのツールで他人と深く関わるやり方に早く慣れないといけない。
たぶん、多くの人が試行錯誤しながら、OLツール上で初対面の人と会った時、どうやって仲良くなって意思疎通できるようになるか、試しているはず。

(5)緊急事態宣言のもとでは、外食チェーンや居酒屋、個人料理店ですら、大人数で集まって会話することさえ禁止された。
ショッピングモールや百貨店、商店街などに行くことすら、緊急事態宣言のもとでは、ちょっとした罪悪感さえ感じさせられた。

デジタルネイティブ世代がコンシューマになって登場したら、現状のままでいると、おたくの会社の製品は買ってもらえないですよ、と言われているが、まさにそう。

オフラインで、街中でビラ配りしたり、イベントを開いて沢山の人を集める、というプロモーションは今は事実上禁止された。
つまり、今後は、オンラインのプロモーションが重要になるし、O2Oと言われるプロモーション、つまり、オンラインで集客してオフラインの店に来てもらう、というプロモーション手法がより一般的になるだろう。
以前は一部の企業しか試していなかったが、今は大企業だけでなく、中小企業や個人商店ですら、O2Oを実行しなければ生き残れないのだろう。

(6)オフラインからオンラインにコミュニケーションスタイルが激変した事態のもとで、従来の既存ビジネスをいかにIT化で売上を維持、拡大していくべきか、という問題にすり替えた。
この問題こそ、DXというのではないか。

| | コメント (0)

2021/02/15

TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか

TeamsとSlack、Zoomの違いについて、たまたま同一の日にツイートを見かけた。
TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【参考】
akipiiさんはTwitterを使っています 「TeamsとSlackの組織文化の違いが面白い。」 / Twitter

Dai Fujihara | ノーコードテスト自動化SaaS「mabl」 | アジャイルコーチさんはTwitterを使っています 「最近、Teams使うお客さんに出会うことが増えてきたけどSlackなら「やっほー」で済むのがTeamsだと「お世話になっております」になるのが面白い / Slack 対 Teams…スラックの成功がマイクロソフトのおかげというのは「見当違いで、馬鹿げている」 https://t.co/3Ds3uHAlei https://t.co/fWDPik2D1H」 / Twitter

akipiiさんはTwitterを使っています 「TeamsとSlackを使う組織文化の違いは、色んな所で話題になるね。個人的にはTeamsを使うのに慣れて割と便利だと思っていて、逆にGoogleChatやSlackは機能が限定されすぎていて痒い機能がなくて、使いにくく感じる。」 / Twitter

沢渡あまね新刊 #業務改善の問題地図 #ここアジャ #職場の科学さんはTwitterを使っています 「申し訳ないが(私の使い方に問題あるのかもしれないが)、Teamsは組織外との人たちとのコラボレーションまだまだしにくい。特に、私のように複数の組織に属する人間の場合、「顔」を切り替える必要があるのだがそれが出来ない(?)。『役割切替』機能欲しい。パラレルキャリアへの対応、プリーズ。」 / Twitter

コミュニティ活動では、SlackとZoomを一般に使っている。
オンラインの勉強会、打合せ、イベントは、今までの経験ではZoomだけだった。
Slackも、コミュニティの時系列チャットみたいに使っている。

特に、Zoomは日々Updateしている感じで、ブレイクアウトルームやいろんな機能が使えるようになっているので、使っていて楽しい。
音声もクリアだし、利用しているだけなら支障はない。

一方、Teamsは会社の業務で使うのが一般的。
Office365を採用している企業であれば、Teamsがそのまま付属してくるので、そこから使ってくるのではないか。
Teamsの使い心地は割と良い。

チャットはSlackみたいに普通にできるし、Zoomみたいにテレビ会議も普通にできるし、Sharepointもバンドルされているので、Excelやパワポも普通に開いて保存もできる。
OutlookもTeamsの一機能になっているので、予定表でカレンダーを見れるし、Plannerも使えば、タスクかんばんみたいなタスク管理もできる。
一昔前のMicrosoft製品のように、ゴチャゴチャした感じではなく、今風なUIなので便利だと思っている。

しかし、Teamsのせいなのかどうか分からないが、@daipresentsさんの指摘の通り、Teamsではチャットに敬語を使う。
業務で使っているせいかもしれないが、そういう組織文化が出てくるのかもしれない。

また、@amane_sawatariさんの指摘通り、Teamsでは組織というグループ管理が強固なので、グループ外の人は入れない。
会社の業務のように、内部統制やIT全般統制、情報セキュリティを厳しく管理する場合はそういう使い方が必要なのかもしれないが、縦割り文化を助長している面もある。

ツールの機能の違いが組織文化を助長しているのかもしれないし、逆に、組織文化が、組織に合った機能を持つツールを選択しているのかもしれない。
いくら優れているツールであっても、ツールの利用者が使いこなせなければ意味がないから。

| | コメント (0)

2021/02/13

トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog



【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか?

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意=クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか?

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

| | コメント (0)

2021/02/12

信頼度成長曲線の落とし穴

@MadoWindaheadさんの信頼度成長曲線の記事を読み直して、色々感じたことがあったのでメモ。

【参考】
信頼度成長曲線を語る夕べに参加 | マドびっ! Madosan's View

信頼度成長曲線については、過去に、SRATSのようなツールを試していた時もあって、色々考えていた。
個人的には、信頼度成長曲線は品質管理の中で華のような技術の印象を持っていた。
なぜなら、その他の品質管理の技法よりも、見た目は美しいが実際の中身は統計処理が含まれて割と複雑なので、研究するのにお手頃だから。

また、テストの収束傾向やテストの終了条件の判定に最終的に使うので、リリース判定というタイミングで使われるから、品質管理の中ではかなり重要な位置を占める。

いつテストを終わらせるか?: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

アジャイル開発はメトリクスが取りやすい: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

しかし、上記の記事の書いてある通り、信頼度成長曲線は前提条件がある。
前提条件とは「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」こと。

信頼度成長曲線は別名、バグ収束曲線でもあるから、バグの発生傾向やバグの発生頻度が重要な観点になる。

僕の理解では、信頼度成長曲線の前提では、テスト作業プロセスそのものにバラツキはないと想定する。
つまり、「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」。

一方、システムの機能に依存したバグ数にばらつきがあっても良い。
実際、システムの機能に関係なくバグが機能毎に全て一定の割合で埋め込まれていたら、S字型曲線にはならず、直線になるはずだから。

具体的には、システムテストでバグ出ししていくと、最初はテストは順調に進んでバグもあまり出ないが、途中からバグが出る機能にぶち当たって、大量のバグを検出するフェーズになる。
そして、何とかバグを全て解決して、最後は、全ての機能をテストし終える頃には、潜在バグも残存バグも抽出しきって、バグも収束傾向になって落ち着く、というイメージ。
すなわち、バグ収束曲線はS字型曲線、イメージとしてはロジスティック曲線みたいな感じになる。

そういう経験則が成り立つ状況であれば、開発規模や過去のバグ密度の経験値、システム特性などを元に、信頼度成長曲線の予定曲線をゴンペルツ曲線とか、S字型曲線に似た曲線で予定しておく。
そして、システムテストでのバグ管理の実績を取ることで、信頼度成長曲線の予実管理を行って、バグの収束傾向を見て、残存バグが出し尽くしたか否か、を判定するわけだ。

しかし、実際のシステム開発の経験では、そもそもバグ累積件数はS字型にならない。
むしろ、一直線に発散する感じの場合が多い。
特に新規加入した開発者が多いチーム、過去のシステム保守の経験がないチーム、新しい技術を使った案件などでは、試行錯誤して、ハンドルが荒れた車の運転みたいな感じになるから。

また、横軸にテスト実施日を取ると、テストしない日とか、テストケースの実績が少なければ、信頼度成長曲線は自然に横向きになるが、それはバグが収束した傾向を示すとは限らない。
横軸には、テスト工数を引くとか、テスト作業そのもののバラツキをなくすように、正規化する必要がある。

こういう処理をExcelでやるのはとても面倒。
信頼度成長曲線はBTSがあればデータをExcelにプロットするだけで実現できるのがメリットの一つだが、実際に正確なグラフを描き出すのは面倒。

結局、信頼度成長曲線にせよ、ソフトウェアメトリクスは、安定したプロセスで初めて有意義な意味を持つ。
そういう意味では、一発限りの請負型案件ではとても使いづらい。

Redmineのようなチケット管理ツールは、最終的にはソフトウェアメトリクスを集計・出力するプロセス基盤であると僕は思っている。
しかし、安定したチームで長期間活動するのは、日本のSIではとても実現が難しいので、ソフトウェアメトリクスを効果的に使えた経験は正直少ない。
パッケージ製品の自社開発、長期間の自社の基幹システム保守のように、長期間のPJでは当てはめやすいかもしれない。

| | コメント (0)

Astah C4 model pluginが公開された

Astah C4 model pluginが公開されたと聞いたのでメモ。

GitHub - ChangeVision/astah-c4model-plugin

複雑なUMLの代わりにC4モデルが提案されている: プログラマの思索

ソフトウェアアーキテクチャのためのC4モデル

ソフトウェアアーキテクチャのためのC4モデル - 雪泥鴻爪--IT技術者の随筆

C4 Model - albatrosary's blog

(引用開始)
C4 Model は
コンテキスト(context)
コンテナ(containers)
コンポーネント(components)
コード(code)
の略です。
(引用終了)

C4モデルは、クラウド上のWebシステム構築に特化したモデリング技法とみなした方がいいのだろう。
astahでもC4modelが描けるプラグインが出たので今度試してみる。

| | コメント (0)

2021/02/08

GNS3の情報のまとめ

Cisco機器のOSSエミュレータGNS3をメモ。

【GNS3のセットアップ】
GNS3の設定方法、操作方法の解説

GNS3の導入方法(Windows編その1) | いっとねっと。

GNS3 Architecture - GNS3

ネットワーク実験室の構築(macOSへGNS3の導入) - Qiita

【GNS3が必要な理由】
GNS3 でバックエンド開発を便利に(前編) - Qiita

GNS3 でバックエンド開発を便利に(後編) - Qiita

【GNS3+IOUが必要な理由】
断捨離は『したいができない人』もいるようです。 | mixiユーザー(id:4324750)の日記

【GNS3+VirtualBox】
GNS3を使って仮想ルータでシミュレート【インストール手順】 | SyachikuLOG

【GNS3 on VMware Player】
【GNS3 on VMware Player】インストール&設定手順, 必要スペック | SEの道標

【GNS3+IOUの設定】
AWSにGNS3サーバを立ててみた - 元パチ屋店員NWエンジニアの技術ブログ

ぼちぼちな感じで WindowsのGNS3でIOUをようやく動かせたという話~その1

ぼちぼちな感じで WindowsのGNS3でIOUをようやく動かせたという話~その2

ぼちぼちな感じで WindowsのGNS3でIOUをようやく動かせたという話~その3

GNS3でRSTPの実習をするには: 技術系memo

macのGNS3でNETWORK(CISCO CCNA)の勉強 ?①GNS3導入? - イノベーション エンジニアブログ

GNS3VMをVirtualBoxからVMWareへ移行してみる - Shadow-log

【GNS3およびIOUのセットアップ方法(Windows10 PC)】
GNS3およびIOUのセットアップ方法(Windows10 PC) : スペースお母さんの逆襲

【Packet Tracer】
誰かが言ってそうなこと Cisco

01_概要 | Cisco Packet Tracer(パケットトレーサー)を使いこなそう!

Cisco Packet Tracer でネットワーク構築実践 #1 | matsublog

【GNS3について理解したこと】

GNS3のメリットは、OSSでありながら、CiscoIOSを完全にエミュレートするので、Cisico機器によるネットワークを完全に実現できること。
CCNP/CCIEレベルの人は、GNS3で経験を積んだ方がいいこと。

一方、GNS3のデメリットもある。
CiscoIOSを手に入れにくいこと。
ネット上では、ググってみるとGNS3対応のIOSは全て手に入れられるが、合法的ではない。

GNS3対応のIOSが何でも動くわけではなく、下記に限定されていること。
1.シスコルータならば1700/2600/3600,3700,7200のIOS
2.L2/L3SWは3700/2600のIOSにNE16SWEユニットを拡張スロットにいれてESWとして使う(L2/L3レイヤのシュミレーションが可能)
3.CatalystシリーズのIOSは使用できない。

特別な目的が無い限り、Cisco 7200ルータの使用が推奨される。
また、SVI(VLAN)インターフェイスを使用する場合には、NM-16ESWモジュールを取り付けたCisco 3725を使用することが推奨される。

上記を解消するには、IOUとは「IOS on Unix」、つまり、GNS3上で直接動くわけではなく、Linux/UnixOS上で動くソフトウェアを入れる必要があること。
L2/L3スイッチの検証環境を作る時に必要になる。
L2/L3SWはIOU(VMWareで操作することを前提に作られている)を無料ダウンロードしてマウントする。

IOUの性能要件は厳しい。
VMWareが走る環境も最低でもXEONクラスのCPU(コア数4コア以上)メモリ32GB以上、HDDは最低でも1TB以上は必要になってくる。
個人PCでは厳しく、ちょっとしたサーバーが必要になる。

GNS3のVMイメージはあるので、GNS3+VirtualBoxイメージをマウントすればいい。
しかし、最近では VirtualBOX よりも VMware WorkStation が推奨されている。
そちらの方が安定しているらしい。
バージョン依存があるので注意。

CCNAを取得するレベルであれば、GNS3は必須ではなく、PacketTracerで十分なこと。

【1】「GNS3によるネットワーク演習ガイド ――CCENT/CCNA/CCNPに役立つラボの構築と実践」の本がとても良かった。

本のサンプルは下記から落とせる。

GNS3によるネットワーク演習ガイド ―CCENT/CCNA/CCNPに役立つラボの構築と実践:書籍案内|技術評論社

サポートページ:GNS3によるネットワーク演習ガイド ―CCENT/CCNA/CCNPに役立つラボの構築と実践:|技術評論社

本のサンプルを動かすには、Cisco 3725のIOSを取得して、拡張子をbinからimageに変更してIOSをマウントする。

「GNS3によるネットワーク演習ガイド ――CCENT/CCNA/CCNPに役立つラボの構築と実践」の本が素晴らしいのは、L2スイッチのVLANやSTPの話は1章分だけだが、L3ルータのルーティングプロトコルを5種類以上サンプルを通じて紹介してくれていることだ。
Cisco機器のコマンドを実際に試すことができるのはとても良い。

| | コメント (0)

2021/02/01

本を書く時の心構え

結城さんが本を書く時の心構えを公開していたのでメモ。

【参考】
次に書く本を考えているときのこと(思い出の日記)|結城浩

(引用開始)
でも、次に書く本を考えているときは、モードがずいぶん違います。
自分の心をとにかく広く広く広げる。遠くの地平線のその向こうまで見るような気持ちで、自分の四方を見渡す。
自分の両手がまるで大きな大きなコンパスになったような心持ちで、ぐるーりと巨大な円を描く。
「よーし、ここまでは届くかなあ。いや、もっと行けないかな?」などと考えつつ。

自分が、現在の段階で、その領域の境界部分を詳しく知っているかどうかはあまり考えない。
でも、数ヶ月の後に、その境界付近にある「とっても面白いところ」に接近できるかの見込みは立てる。

……私が次に書く本を考えているときには、そんなことをイメージしているように思います。

書き始める時点では知らなくてもよいけれど、書き終えた時点ではかなり詳しくなっているはず……という微妙な案配を見極めるのは難しい。
つまり、「自分がすでに知っていて何も考えなくても書ける」という難しさの本だと、私は書いていてつまらなく感じる。
それよりも「調べつつ・考えつつ・謎解きしつつ書かなくちゃ」という難しさの本がよい。
(引用終了)

僕は、本を書くということは、「今ここにいる自分」の知識と経験をフル動員して書くものだと思っていた。
僕は、全ての書物は、私小説だと思っていたから。

なぜなら、何かを書いて本として公開する、という意味は、自分がどこまで理解して、今まで誰も知らなかったことを発見したから世の中に広く知らしめたい、と思っていたから。
たとえば、自分の理解度が浅かったり、経験が少なければ、書物の内容はとても浅薄なものになりがちだ。
よって、書き始める時点で、内容のほとんどは自分が抑えていて、コントロールできなければならない、と思っていた。

たとえば、戦前の日本の小説家が書いたスタイルである私小説は、小説家自身の生活をベースに書いていたから、彼らのインプットが非常に少ないので中身はとてもつまらないと思っていた。

一方、結城さんの意見では、「最終的に本を書き上がる時点の自分」の知識と経験を書けばいい、というスタンスだ。
つまり、書き始める時点では、中身はまだ曖昧模糊でもいい。
書き終えた時点で、骨格も中身もプロットも全て完成していればいい。

よって、書き始める時点では、調べて考えてストーリーが決まったな、という範囲を予測できればいいし、その予測した範囲が自分の手の内に収まる程度であるか見積もりすればいい。
つまり、調べながらあれこれ考えたり、空想したりする余裕がある。
謎解きする楽しさの余地を残している。
書き始めた時点のストーリーが、謎解きするうちに、書き終えた時点では全く違うストーリーで完成度が仕上がっている、みたいなイメージになるのだろう。

今度書く機会があれば、こういう発想を使ってみたい。

| | コメント (0)

« 2021年1月 | トップページ | 2021年3月 »