構成管理・Git

2022/05/08

小説活動にプルリクエスト駆動が必要になってきた

小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。

【参考】
Pull Request駆動で小説を開発する

GitHub上に構築した小説執筆環境について

akipiiさんはTwitterを使っています: 「コミット履歴を整理するためにプルリクエストを使う発想。面白い。Pull Request駆動で小説を開発する https://t.co/EJ5fHkyr1O」 / Twitter

【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること

【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。

小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。

【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。

本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。

そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。

【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。

トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。

プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。

【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。

akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter

門屋浩文@redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii まだ、なさそう https://t.co/PO5I82pmft 参照してください」 / Twitter

デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter

過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。

GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。


そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。

そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。

| | コメント (0)

2022/01/14

【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine

プロジェクト&プログラム・アナリシス研究部会で講演した資料「チケット駆動開発の解説~タスク管理からプロセス改善へ」を公開します。

【参考】
お知らせ2点:P&PA研究部会「チケット駆動開発」(1/11)、BOMに関する1日集中セミナー(1/27) : タイム・コンサルタントの日誌から

プロジェクト・マネジメント・システムは存在しうるか : タイム・コンサルタントの日誌から

【1】資料のテーマは、下記の通り。
基本的な前提として、Redmineの経験者を対象としている。

チケット駆動開発は、ソフトウェア開発で使われる障害管理ツールをタスク管理に利用する開発手法を指す。
チケット駆動開発はアジャイル開発と親和性が高いので、アジャイル開発のプラクティスを利用しやすく、チーム運営に役立つ。
チケット駆動開発を支えるチケット管理ツールは、汎用性が高く、とても有用な為、色々な業界の現場のプロセス改善に使われている。
チケット駆動開発の発端、仕組み、事例、プロセス改善に使われる理由を解説する。

チケット駆動開発、チケット管理ツール、Redmineというものを知らなければ、たぶん理解しにくかったかもしれない。

僕は、そういう内容を前提の上で、現時点で、チケット駆動開発とチケット管理ツールがどういう課題を乗り越えて、ここまで進化してきたのか、そして、今後はどんな未知の分野や課題があるのか、を整理して示したかった。
よって、70ページものボリュームになってしまった。

分かってくれる人に理解してもらえれば本望かなと思って公開してみる。

| | コメント (0)

2022/01/09

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ

「プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ」というツイートを見つけたすごく共感した。

【参考】
Rui UeyamaさんはTwitterを使っています 「少数派の意見かもしれないけど、プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。」 / Twitter

結城浩さんはTwitterを使っています 「@rui314 デバッグしてるときと証明読んでるときはなんか似てる。素直に読みつつ穴探ししてるみたいな感覚。」 / Twitter

英語勉強中さんはTwitterを使っています 「@rui314 めちゃくちゃわかります。僕は書いてるとき数学のことなんか考えてないです」 / Twitter

akipiiさんはTwitterを使っています 「プログラミングはこの感覚に近いな」 / Twitter

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラマに必要なスキル: プログラマの思索

プログラムを書いている時、数学の知識を使っているかと言われるとそうではない気がする。
むしろ、APIやFWのライブラリをまずは頭に叩き込んでおき、自分が実装したい目標に対して、それらAPIをどうやって組み合わせて意図通りに動かすか、に注力している。
ちょうど、ブロックで巨大な積み木を組み立てている感じに似ている。

だから、「プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じ」にはとても共感するし賛同する。

たとえば、RDBでSQLをデータ抽出したり、機械学習や深層学習のライブラリを使って母集団を推定したり、マーケットを予測したり、Web上の通信を暗号化したりする時、数学の理論はAPIやライブラリの中に隠れてしまっている。
それらライブラリを呼び出すだけで、高尚な理論を使えるのは素敵だが、だからと言って、プログラミングが楽になっているわけではないと思う。

一方、やりたいことを実現するには、PythonやRDB、Webサーバー、Dockerなどの開発環境を揃えて、Githubで構成管理し、CIツールでビルド&デプロイできるようにして、Jupyter を動かせるようにしたり、IntelliJなどの開発環境を構築したり、とプログラミングの前準備がすごく多い。
普通の初心者はこの部分で挫折するのだろうと思う。

僕自身、新しい環境を揃えてプログラミングスタイルを覚える時は割と苦痛に感じる時もあった。
Ruby on Railsもそうだし、AWSでの環境構築、GNS3でのCiscoルータ&スイッチの環境構築の時もそうだ。
Python+Anacondaはまだマシだった。
プログラミングは奥が深い。

| | コメント (0)

2021/12/28

チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine

チケット駆動開発のプロセスとチケット管理システムの全体像はこんなイメージではないだろうか?

【1】チケット駆動開発とは、チケットを起点として、業務の活動をすべてチケットで追跡する仕組みでありプロセスだ。

具体的には、リリース計画を作成して、チケットを一括登録したり、チケットを随時登録する。
登録されたチケットは担当者によって日々更新されたり完了されて、その進捗状況は、ガントチャートやロードマップなどのチケット集計機能によってリアルタイムにモニタリングできる。
管理者はこの情報を使って日々の意思決定やリスク管理に適用する。

リリースバージョンでグルーピングされたチケットが全て完了になったら、そのバージョンはCloseされて、成果物がリリースされる。
ソフトウェア開発ならば、バージョンつまりスプリントやイテレーションがCloseされると同時に、そのバージョンのモジュールがビルドされてデプロイされてリリースされる。

リリースされたモジュールや成果物は開発者が検証したり、ユーザが実際に使ってみて、開発者が見つけた障害修正やユーザの改善要望が管理者へフィードバックされる。
管理者はそのフィードバック情報を元に、次のリリース計画をブラッシュアップして、次のスプリントを開始する。

すなわち、チケット駆動開発とはアジャイル開発を実装したプロセスの一つとみなせる。

【2】一方、チケット駆動開発はチケット管理ツールという具体的なソフトウェア製品よって支えられている。
このソフトウェア製品という特性と実際の運用をまとめたものをチケット管理システムと呼ぶことにしよう。

【2-1】チケット管理システムの具体的な中身は何か?
基本はPMBOKが言うPMIS、つまりプロジェクト管理情報システムだ。
すなわち、チケットというインプット情報をPMISへ食わせた後、PMISがいろんな観点で加工して、PJ管理に必要な各種レポートをアウトプットして吐き出す仕組みだ。

第三者の観点から見れば、チケット管理システムはすごく単純だ。
なぜなら、インプット+プロセス+アウトプットという逐次実行の仕組みに過ぎないからだ。

【3】しかし、チケット管理システムというPMISの機能を解剖すると、単純な機械でありながら強力な機能を持っていることが分かる。
PMISの主な機能は、フロー管理とストック機能の2つだ。

【3-1】まず、フロー管理は、チケットを流通媒体とみなし、タスクをサクサク流すことに力点を置く。
MS Plannerのタスクカード、Agile開発やカンバン駆動開発のストーリーカードやタスクカード、申請承認ワークフローの申請書に相当する。
フロー管理では、作業のリズムを重視する。

【3-2】次に、ストック機能は、チケットを記憶媒体とみなし、日々の作業結果を記録していくことに力点を置く。
障害管理票や課題管理票、WBSなどの記録媒体。
過去の作業履歴、得られた経験や知識はチケットに記録されているので、チケットが蓄積されるほどナレッジ資産になる。
ストック管理では、ナレッジ基盤を目指す。

【3-3】実際は、チケットがフローとストックの2つの意味を二重に持っていることから、PMISはフロー管理とストック管理の機能を自然に持つようになる。
この特徴により、数多くのチケットを集計した結果から有用なメトリクスが得られる。
例えば、ガントチャート、EVM、リソース管理、タスクボードなど。
また、この特徴により、蓄積されたチケットの履歴やチケット間の関係、成果物とチケットの相互関係から、トレーサビリティの機能が生まれる。

【3-4】チケット駆動開発では、ビルドしたモジュールはバージョンというタグがあり、バージョンでグルーピングされたチケットがあり、そのチケットには作業履歴が残っていて、チケットには構成管理ツールの配下に置かれたソースコードや設計書などの変更履歴が紐づくように、運用される。
このトレーサビリティという機能があるからこそ、開発者は自信を持って開発できるし、管理者もリリースしたモジュールの品質を自分でコントロールできるようになる。

【4】チケット管理システムには、その運用を支える数多くのロールがある。
チケット管理をスムーズに運用するために必要なアクターがあることは、Redmineコミュニティで数多く研究されてきた。

【4-1】チケットを起票する現場の人は、PMISを業務のナレッジ基盤とみなす。
自分が入力した作業結果だけでなく、他人の作業結果も参考にして、ナレッジを利用することで自分の作業手順を効率化することに役立つ。

【4-2】管理者は、PMISをメトリクス集計のプロセス黄ばんと看做す。
彼らは、ガントチャート、EVM、リソース管理、タスクボード、信頼度成長曲線など各種の有用なメトリクスを用いて、業務活動の進捗管理、品質管理、要員管理をモニタリングし、日々の意思決定に活かす。

【4-3】お巡りさん(Redmine警察)は、チケット管理の守護神だ。
彼は、現場の人や管理者がチケット管理に困っていたら支援して、チケット管理をスムーズに運用させる。
チケットは生鮮食料品みたいなもので、日々更新されなければ、ただのゴミに過ぎない。
だから、お巡りさんは定期的にチケット管理システムを通じてチケット管理が運用されているか見て、チケット駆動開発を守る人になる。

【4-4】エバンジェリストはチケット管理の伝道師だ。
チケット管理がいかに素晴らしいか、チケット管理を通じて組織をどのように発展させていくべきか、現場の人や管理者を啓蒙する人だ。
エバンジェリストは熱い気持ちを持ち、チケット管理に関わる人の心に息吹や熱気を注入する人だ。

【4-5】PMISは、現場の人達や現場のプロセスに合うようにカスタマイズしたくなるので、マイスターという開発者がPMISをその現場特有のPMISへカスタマイズし、現場のプロセスに局所最適化する。
マイスターはまさにPMISの職人だ。
マイスターから見れば、PMISはPJ管理の開発基盤という側面も持つ。
つまり、チケット管理システムというPMISはプロジェクト管理を実現するソフトウェアフレームワークという開発基盤とみなせる。
すなわち、チケット管理システムはカスタマイズしやすい特徴を持つので、いろんな現場に適用できるように局所最適化しやすい。
だからこそ、改善が大好きな日本人にはチケット管理システムが合うのだろう。

【4-6】活動家は、PMISのログ(Redmineの活動タブ)を見て、現場の人達の活動、さらには組織の活動をモニタリングし、PMISを組織のプロセス改善の基盤として使う。
活動家は、1個のPJや1個の部署だけでなく、複数のPJや部署を横断して、人間の血液診断や健康診断のように、PMISを通じて組織の活動診断を行う人になる。

【5】こういうポンチ絵を描いてみると、チケットで作業も課題も障害も管理する、という単純なアイデアから生まれたチケット駆動開発は、いろんな側面に支えられて、豊富な応用結果を持つことが分かる。
こういうことを考えるのが楽しい。

脱Excel! Redmineでアジャイル開発を楽々管理:エンジニアがお薦めする 現場で使えるツール10選(3)(1/5 ページ) - @IT

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要: プログラマの思索

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

| | コメント (0)

2021/11/28

第21回東京Redmine勉強会の感想 #redmineT ~Redmineは業務も組織も包み込む柔軟性がある

第21回東京Redmine勉強会の感想をラフなメモ書き。

【参考】
第21回勉強会 - redmine.tokyo

2021/11/27 第21回勉強会 - redmine.tokyo #redmineT - Togetter

【1】最初は、@g_maedaさんのRedMica、そしてRedmineの最新機能の紹介。

【1-1】複数キーワードによるAND検索の実装は嬉しい。
チケット一覧から、Google検索みたいに細かい条件で検索できる。
チケット検索機能の強化につながるので、Redmineをナレッジ資産として使う現場としては貴重な機能と思う。

【1-2】チケット一覧でカスタムクエリをデフォルトで表示できるようになった。
PJごとに、みんなが見たいビューはたいてい決まっている。
最初にカスタムクエリで絞り込んでおけば、今日はどの作業に注力すればいいのか、考える必要もないはず。

【1-3】CommonMarkdownの試験的なサポートも興味深い。
斎藤さんのLTでは、Confluenceがすごく便利と話されていた。
実際、Confluenceでは、Wordのような直感的なUIで表も挿入できるし、履歴管理もすごく楽。
Confluenceがあれば、Excelの設計書を廃止して、すべてConfluenceで設計書を書くことができる。

一方、RedmineのWikiでは、Markdownの原稿を逐一プレビュータブで開いては確認する手間がかかる。
また、表のセルの結合、細かな文字の装飾も直感的ではない。

本来は、WikiはWordやExcelの代替機能になるべきだ。
そうすれば、Redmine上で、日々のタスク管理や課題管理はチケット、技術情報や設計書はWikiに全て集約できる。
それ以外の足りない機能は、REST APIやGit連携などの機能によって、他の外部ツールと連携すればいい。
最終的には、Redmine一つでPJの情報をすべて一括管理できるし、Redmineはナレッジ基盤そのものになるはずだ。

【1-4】Mermaid.jsによる作図機能は面白い。
PlantUMLみたいに、UMLのクラス図、シーケンス図、フローチャートをテキストで表現できる。
ただし、redmica_ui_extensionプラグインの機能なので注意。

個人的にはPlantUMLは好き。
モデルそのものもテキストで管理できれば、Gitで履歴管理できるので、設計書をソースコードと同じように管理できるのはいい。

My Redmine インストール済みプラグイン | My Redmine

GitHub - redmica/redmica_ui_extension: This plugin adds useful UI improvements to RedMica.

plantuml - Plugins - Redmine

Redmineには2つのPlantUMLプラグインがある - taikii blog

【2】第21回 パネルディスカッション <Redmineとわたしたち>では、モデレータ、パネラーの女性5人によるフリーディスカッション。

【2-1】面白いのは、5人の女性のキャリアが全員違うことだ。
もちろん、5人全員がRedmine経験歴は10年なのでベテランばかり。

akipiiさんはTwitterを使っています 「Redmineを使う女性だけのパネルディスカッション。サーバ管理者、プロジェクトマネジャー、SEPG、PMO等の色々なキャリアを持つ。組込ソフトウェア会社、外資系、サービス系、メーカー系など色々な属性。面白そう。 #redmineT」 / Twitter

【2-2】僕の琴線に触れたのは、ともこさんとりょうこさんの発言だった。
りょうこさんは外資系SIのPMでPlanioを使っているので、プロマネ観点が多い。
だから、Redmineパトロールみたいにチケット保守や、多数の社外関係者のユーザの権限管理の観点が多くなる。

akipiiさんはTwitterを使っています 「PMの方の意見では、Redmineのパトロールが大事。Redmineの運用がずれてしまうので、定期的にチケットの運用をパトロールする。ゾンビチケットを駆除したりとか。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineの良さ。半年前のチケットを元にコピーして今回の作業チケットを作れるので、差分だけ見ればよく作業漏れがなくなる。関連チケットでチケットを相互関係付けられる。色んな会社の人が使うので権限管理が細かく決められるのがいい。 #redmineT」 / Twitter

一方、ともこさんは全社のソフトウェアの障害管理、全社PJのゲートレビューの管理、Redmineサーバーの管理をされているので、PMOの観点が多い。

akipiiさんはTwitterを使っています 「Redmineが使いにくい所では、UIが初心者のハードルが高い意見が多いが、UIよりもワークフロー設計の方に課題がある意見の方に興味を持った。トラッカーとステータスで障害管理、定常業務の作業管理のワークフローをどう設計するか?の方が重要だし腕の見せ所と思う。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineに限らずチケット駆動の弱点の一つは、チケットの説明欄が自由すぎること。起票者の能力によってバラついて作業連携やコミュニケーションにロスが出る。そこでテンプレートを用意したり、事前にテンプレートチケットのリンクをWikiに用意して誘導する。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineを通じて対面だけでなく非同期のコミュニケーションもやっている。1年前の障害チケット、既に去った人が書いたチケットを読んで意図を理解する。チケットの説明欄に、障害内容や関連するチケットがこれです、と書けば伝えられる。書いて伝える能力が要求される。 #redmineT」 / Twitter

【2-3】女性ならではの観点では、お母さんみたいな役割もあるらしい。
この辺りは中年男性の僕には分からない笑。

akipiiさんはTwitterを使っています 「管理者がオレオレ運用ルールを押し付けると、メンバーは何でやねん!と反発してしまう。そこで相談しやすい雰囲気を作って、お母さんみたいな役割を持って、悩みを聞きまくる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineをパトロール中に、この表現はダメだよね、と気づいたら、チケットもコメントもコッソリ直したり指導する。IT技術者の説明はぶっきらぼうで、これが仕様です、と書いてもノンITの人には伝わらない。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「心理的安全性を高めて雰囲気を良くして、チケットに書いたら、お互いに時間を有効に使えるよ、と伝えたい。 #redmineT」 / Twitter

【2-4】5人のディスカッションでは、「柔軟性」というキーワードが多かった。
「Redmineはユーザとツールの観点で柔軟である」と。

ツールの観点では、Redmineはプラグインやパッチのおかげ機能追加がすごく柔軟な特徴を持つ。
一方、ユーザの観点では、Redmineは現場の人たちのニーズに応じて、運用ルールを柔軟に変更してFitさせることができる。

僕は、「柔軟性を英語でいうと、Elasticと思う。AWS用語でよく出ると思う。 #redmineT」と思っていたが、どうやらFlexibilityの方がイメージが合っていると思う。

akipiiさんはTwitterを使っています 「柔軟性には、ツールの柔軟性と人としての柔軟性の2つの観点がある。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「100人上のユーザの中で女性PMが一番Redmineが詳しいが、若い人の意見に時々はっと気づく時がある。自分が決めた運用ルールが絶対ではないのでこう変えてもいいかもと思う時もある。人の柔軟性を実現してくれる柔軟なツールがRedmine。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「Redmineは、各人が貯めている経験や知識を吐き出すのに向いている。他人の言葉にハッとする時はむしろTwitterや対面の方が多いのではないか。 #redmineT」 / Twitter

【3】田畑さんの森林管理でRedmineを利用している事例はとても面白かった。
岡山の山奥の村に、林業でDXをやっているらしい。

【3-1】Redmineを使う場面は、補助金の申請業務や日々の作業管理。

akipiiさんはTwitterを使っています 「林業だけでは収入が少ないので、補助金の書類が大事。書類が多い。そこでRedmine。人によって情報格差が大きい。知っている人は作業できるが、知らない人は作業できない。ストレスが溜まる。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「ステータスは、下請けさんの作業街が多いので追加。監督者対応中も追加して65歳の監督者を想定。補助金の申請業務は他者対応待ちを追加。実際の業務で必要だから。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「プロジェクト=現場。バージョン=作業監督。チケット=作業で数時間。トラッカー=設計、実施、監査など。 #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「トラッカー=設計、監督、実施後で作ったが、WFが同じなので分ける必要はなかったかもしれない。 #redmineT」 / Twitter

【3-2】Redmineで工夫している点は、ワークフロー設計と、GTTプラグインを入れて、チケットに地図情報を記載している点だ。
実は、第20回勉強会 - redmine.tokyoで「 第20回 LT: Redmineで地理空間情報を扱う、Redmine GTT (Geo-Task-Tracker) plugin の紹介」で知って、取り入れたらしい。

Redmineと地図情報を組み合わせるアイデアは面白いと思う。
営業活動や配送管理などにRedmineを適用できるのではないか。

akipiiさんはTwitterを使っています 「森林管理は口承伝承。作業手順を文字化して標準化したい。作業手順記録はWiki、作業状況確認はRedmine+GTTプラグイン。前回勉強会LTのGeoTaskTrackerプラグインを使う。 #redmineT」 / Twitter

GitHub - gtt-project/redmine_gtt: Plugin that adds spatial capabilities to Redmine

akipiiさんはTwitterを使っています 「チケットにGTTプラグインの地図情報が表示される。チケット説明は簡単に書く。詳細はWikiに書く。チケットの説明に詳しく書くと流用しにくい。 #redmineT」 / Twitter

【4】僕も久しぶりに「Redmine屋から見たMS Planner #redmineT」を講演した。
Teamsに付属しているPlannerを使っているのだが、とにかく使いづらくて仕方ない。
Plannerは所詮ToDo管理に過ぎず、もっと細かなタスク管理や課題管理をやるのには向いていない。
当たり前なんだけどね。

MS PlannerはRedmineと違って使いにくいのは複雑なワークフロー管理ができないから: プログラマの思索

懇親会で聞いてみたら、ブレークアウトルームの大半の人はTeamsを使っている。
Slackを使う人はごく少数。
Office365を使う企業は多いので、Teams利用者が圧倒的に多い。
すると、フリーのPlannerも付属してくるので皆知っている。

しかし、Plannerは使えませんという声が圧倒的だった。
興味深い意見は、Plannerのタスクには更新履歴が残らないので、ナレッジにならない。
使い捨てのカードみたい。
PostItの感覚でしか使えない。
本来は、Redmineのように、完了したチケットでも後から参照したいのに、と。

【5】今回の勉強会は参加者が100人にも到達しなかった。
同日開催の裏番組のOL勉強会が多かったせいだろう、という意見が多かった。

また、@naitohさんのRedmine.tokyo21 questionnaireの通り、初めての参加者が少なく、4回以上の参加者が圧倒的に多くなっている。
この傾向に危険を感じる人も多い。

でも僕はあまり気にしていない。
我々の勉強会が楽しくて盛り上がっていれば自然に人は集まる。
誰でも参加できるような雰囲気さえあればいい。
他人の都合に合わせる必要はないし、こちらの雰囲気が良くて気になるなら、こちらの都合を合わせてくれればいい。

コミュニティはボランティアなので、過大なコミット感まで持たなくていい。
むしろ、緩く長く続けることのほうが大事と思う。
年2回開催という絶妙のバランスのおかげで、スタッフの作業負荷も大きくない。
5月、11月に定期的に開催できるリズムがあるから、参加者もスタッフも講演者も予定を入れやすい。

この勉強会ももう10年以上も続いているのは一つの奇跡だと思う。
他のアジャイルコミュニティも浮き沈みがあって、スタッフの入れ替え時期には開催できなかったりしていた。

三浦かずひとさんの通り、純粋に楽しめればいいと思う。

みうら かずひとさんはTwitterを使っています 「#redmineT 最近RedMineに対する思いもないし、特段興味を持って参加ではなかったのだけど…「利用者視点かつファンでない視点で見つめる」と、「お、工場?」「お、林業?」とか、凄く純粋に楽しめました。」 / Twitter

【6】2021年もAdventCalendarをやっているので、興味のある方はぜひ応募してみてください。
書いてみると、1年後には記念になるのがいいです。

Redmine Advent Calendar 2021 - Adventar

| | コメント (0)

2021/10/30

AWSサービスとSW品質特性のマッピングはどうなるか

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
AWS初心者のロジカルでないメモ。

AWS Fargate とは?「コンテナ」と「仮想マシン」の違い|AWS上のコンテナ関連のサービス | FEnet AWSコラム

AWS Fargateとは?Amazon ECSとの関係性やメリット・デメリットを解説|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本

AWSサービスとSW品質特性のマッピング一覧を作ることで、クラウドが何を解決しようとしているのか、整理したいと思っている。

AWSの最大の恩恵は移植性だろう。OSパッチやセキュリティパッチの作業から基本は解放される意義は大きい。
他にも、障害耐性などの機能性やAutoScalingなどの効率性もあるだろうが、盲点なのは保守性ではないだろうか。

Infrastructure as Codeにより、サーバー構築は全て構成管理の配下に置かれ、保守性を大きく担保する。
しかし、それはアプリケーション層のApacheのhttpd.confの構成管理を意味しているわけではない。
むしろ、AWSがNW機器の物理的実体からデータプレーン、コントロールプレーンという論理的実体へ分離することで、膨大なネットワーク機器を一括管理し構成管理できるようにした点が大きな利点のはず。
AWS上で「データプレーン」を提供しているのは「AWS Fargate」と「Amazon EC2」、AWS上で「コントロールプレーン」を提供しているのは「Amazon ECS」と「Amazon EKS」です、という文言を偶然拾って、ああそういうことなのか!と気づきを得た。
だから、Kubernetesが画期的な技術なわけだ。
CCNAを取得したおかげでこの辺りの意義がなんとなく実感できたから。

インフラ関係のPJをレビューしていていつも思うのは、専用回線の切り替えやDNS切り替えだけのNWリプレースの作業のPJで割と本番障害が多くて、なぜたかがNW機器の入れ替えぐらいでそんなに作業ミスが多いの?といつも思ってた。
DNS切り替えなんて所詮、向き先を変えるだけでしょ、と思ってた。
たぶん、その背後には、数多くのNW機器があり、その設定ファイルを手作業で書き換えて、手作業で検証する必要があって大変なのだろう。
だから、NW層のレベルで構成管理できる意義はとても大きいのだろうと推測している。

| | コメント (0)

2021/04/18

なぜInfrastructure as Codeが必要なのか?

最近ようやく、Ciscoのスイッチやルータの使い方が分かってきた。
GNS3上のルータやスイッチをCiscoコマンドで設定したり、動かしているうちに、ネットワーク技術の奥深さや難しさが何となく見えてきた気がする。
以下はラフなメモ書き。
間違いがあれば後で直す。

そもそも、ネットワーク技術の根本問題は何なのか?
根本には、ネットワークは動いていて当たり前という高品質が前提の上で、コスト、高性能、冗長性、セキュリティというパラメータのトレードオフがあると考える。

コスト=F(高い品質、高い性能、冗長性、セキュリティ)という複雑な方程式から、最小コストとなるパラメータの組み合わせを探そうとしている。

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察: プログラマの思索

ネットワーク技術の必要性が高まっている: プログラマの思索

ネットワークは動いて当たり前であり、通信できなくなると、即座に業務が止まってしまう。
ルータやスイッチを設定してみて分かったのは、設定が複雑すぎる。
数十、数百のスイッチ、ルータの設定が1つでも間違えば、ネットワークは動かなくなる。
ネットワークの素人では無理。

たとえば、中小企業で100人以下で、バックボーンエリア1個だけで済むようなルーティングのOSPF構造の経験があっても、エリアIDが2個、3個と増えて、ルータが数百台になってしまうと、相当に難しいと思う。
ネスペ・支援士塾 - connpassで講師や参加者の話を聞くと、普通のエンジニアでは、エリアIDが1個だけのルーティングしか経験がない人が多い感じ。

たとえば、冗長性を実現することで、どこかで配線が切れても、代替のルートで通信を継続できる。
いわゆる耐障害性につながる。
冗長性は、スイッチではSTPで実現するか、PAgPで実現するか、色々ある。
しかし、L2層ではフレームのTTLが無いので、下手なNW設計では、L2ループが発生してしまい、通信帯域を消費して、通信速度が落ちてしまう場合がある。
「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」を読むと、STPで冗長性を確保するトレードオフとして性能悪化してしまう症状に対して、どんなネットワーク設計をすべきか、をすごく丁寧に説明してくれている。
他にも、デフォルトゲートウェイとなるサーバーの冗長性をHSRPで実現したり、floating static routeでバックアップのdefault routeを設定したり、色々ある。

たとえば、ネットワーク設計ではセキュリティが非常に重要だ。
データリンク層のスイッチのレベルでは、スイッチに不正接続があればPortSecurityを使ってポートそのものをシャットダウンできる。
VLANで営業部、経理部などの組織単位でサブネッティングできる。
ネットワーク層のルータのレベルでは、ACL、NAT、RADIUSサーバー認証などでパケットフィルタリングできる。
また、SNMPで常時監視、Syslogにネットワーク機器のログを残したりできる。

Ciscoルータ/Catalystコマンド一覧のリンク: プログラマの思索

GNS3の情報のまとめ: プログラマの思索

ネットワーク学習のためのチートシートのリンク: プログラマの思索

では、最近、なぜInfrastructure as Codeが必要なのか?

上記のように、たくさんのスイッチ、ルータ、ワイヤレスLANコントローラ、DNSサーバー、NTPサーバー、DHCPサーバー、SNMPサーバーなどのネットワーク機器を個別に1つずつ設定するのは非常に大変すぎる。
数百台、それ以上のネットワーク機器のstartup-configを一つずつ手作業でセットアップするのは、現実的でない。
1つでも設定が間違えば、L2ループが発生して通信帯域を圧迫して性能を落としたり、通信経路そのものが遮断されてしまって代替経路が動かない、とか、色々起こってしまう。

「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」で印象に残った話は、ユーザはスイッチの空きポートがあると何を差し込んでもいいと勘違いしていて、そこに量販店で買ったブロードバンドルーターを接続して、付属したDHCPサーバーが動いてしまい、フロア全体の通信を落としてしまった、実は新人の私でした、という話があった。

だから、それらネットワーク機器を一括設定、管理するような機能、つまり、SDNが必要になる。
そのSDNを仮想化したアーキテクチャとして、Infrastructure as Codeがあるわけだ。

僕は、Infrastructure as CodeをApahceのhttpd.confなどをGitで構成管理するぐらいの程度で考えていたが、たぶん全く違う。
そういうアプリケーション層ではなく、データリンク層、ネットワーク層のレベルでネットワーク機器を構成管理して、Infrastructure as Codeを実現しようとしているのだろう。

SDNコントローラで制御できるならば、管理画面からREST API、NetConf、SSH、Telnetで一括操作できる。
以前なら、ChefやPuppetが紹介されていたが、今はAnsibleが一般的なのだろう。
なにせ、SSHやNetConfが使えるし、エージェントレスだし、Playbookを書いてPushするだけでいい。

すると、Infrastructure as Codeによって、ネットワーク設計の仕様が一連のプログラムないし設定ファイルというテキストで管理できる。
テキストであれば、Gitで履歴管理できるから、設定ファイルのUndo、ReDoも簡単だ。

そして、ネットワークの仮想化、ソフトウェア化によって、クラウド環境が一般的になった今では、そういうネットワーク設計仕様のテキストは、kubernetesで可搬性を持つようになる。
kubernetesがもっと進化すれば、AWSやGoogleCloud、Azureというクラウド環境にも依存しない設定ファイルとして使えるようになるはずだ。
そうすれば、ネットワーク設計を抽象的に設計できれば、その設計構造をkubernetesで書くだけで、どのインフラ環境でも、どのクラウド環境でも動作できるようになるはず。
つまり、6つの品質特性のうち、移植性を完全に実現できるはず。

ネットワーク設計であれ、Windows7やWindowsServerの廃棄対応であれ、ソフトウェアの移植性は従来からずっと問題だった。
Infrastructure as Codeという考え方はそれを解決する一つの技術と捉えられるのだろう、と思う。

| | コメント (0)

2021/03/26

ITの技術や知識はツールの習得と表裏一体である

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。
とても当たり前の内容かもしれない。

【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。
でも何か分かったような気がしなかった。
何か真似事しているだけのような気がした。
なぜだろうか?
いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。

【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。
具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。

理由は、2つある。

【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。

たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。
昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。

今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。
実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。
PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。
ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。

たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。
特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。
それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。
ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。

たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。
実際にモデルを描いてみると、数多くのモデル間の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。

特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。
ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。
だから、データモデリングの考え方自体も普及していない。

【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。

たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。
RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。
しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。
つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。
もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。

たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。
しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。

実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。
IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。
100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。
そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。
そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう

たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。

たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。
すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。
また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。
つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。
Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。

逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。
Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。
たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力もあったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。
「ツールがプロセスを改善していく」という発想が僕は好き。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索

ツールがサポートすれば考え方も変わる: プログラマの思索

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

開発プロセスの型をツールで構築する #tidd: プログラマの思索

【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。
換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。

それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。

だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。
そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。

最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。
いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。
視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。

昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。
そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。

| | コメント (0)

2021/01/04

YoutubeのCCNA講座が秀逸だった

インフラの勉強がしたくて、Youtubeを探していたら、下記のCCNA講座が秀逸だったのでリンクしておく。

【参考】
【CCNA動画支持率No.1】未経験からのインフラエンジニア勉強講座【ネットワーク基礎入門 #1】 - YouTube

【CCNA講座】「OSI参照モデル」が30分で絶対分かる!【インフラエンジニア基礎入門 #2】 - YouTube

【高評価97.2%】CCNA「物理層」を完璧理解できる講座【インフラエンジニア基礎入門 #3】 - YouTube

【CCNA合格講座】「イーサネットとは?」を徹底解説!【インフラエンジニア基礎入門 #4】 - YouTube

【CCNA合格講座】TCP/IPとは?「仕組み」完全解説!【インフラエンジニア基礎入門 #5】 - YouTube

【CCNA講座】「TCP」「UDP」を日本一易しく解説!【インフラエンジニア基礎入門 #6】 - YouTube

なお、すべての講義はUdemyで見た方が早い。

新CCNA(200-301)完全未経験からの合格講座(上)【YouTube高評価率98.2%のパワーアップ完全版】 | Udemy

【1】上記のCCNA講座の対象は、SIに入社した新人社員、5年目までの若手までのレベル。
インフラ専門で仕事している技術者は当たり前の話だろう。

しかし、アプリ開発しかやっていない人、AWSをかじっているけどインフラ基盤の知識が薄い人には、とても参考になると思う。
たとえば、ハブ、スイッチ、ブリッジ、ルータの違いが分からない、というレベルであれば、とても参考になる。
AWSサービスを組み合わせてインフラ基盤を構築する時にも役立つはず。

そういう知識は、IT業界にいたら、既に知っている知識のはずだろう。
しかし、別の業界の人にとっては、未知の知識なので、そういう初歩レベルからつまずく。
そういう人たちがいきなりAWSをやるぞ、と言っても、たぶん訳がわからないのではないだろうか。

同様に、IT業界のベテランであっても、法律系や財務系の知識はほとんど知らず、経理や法務の部署の人から見れば、その部署の新人レベルに過ぎない、という人も多い。

僕は理系人間なので、会計システム構築の経験を踏まえて、財務や会計は面白いし、知識も習得できた。
一方、法律だけはどうしても理解できなかった。
ああいう変な日本語の文章で書かれて、判例があるたびに例外の処理が増えて、しかもGitで構成管理されていないから、変更履歴が入り混じった変な因果関係で書かれた文章は、性に合わない。

結局、IT技術者であっても、別の業界に移れば、新人ないし5年目までの若手レベルに過ぎない。

【2】最近、こういう動画配信の講義がすごく増えてきて、書籍を買うよりも分かりやすい、という評判をよく聞くようになった。
自分も色々試してみて、動画と書籍による学習方法やその効果の違いもだいたい分かってきた気がする。

Udemyのような動画のメリットは、映像化されているので、その分野では自分は素人または初心者の時は有効。
Python機械学習、AWSのクラウドネットワーク講座、ビジネス法務検定みたいない法律系、とかは、いきなり書籍を読んでも分からないので、こういう初心者向けの動画を見ながら、PCでメモを取って、基本単語に慣れることから始める。

動画のデメリットは、長時間で目が疲れること。
初心者レベルから解説しているので、どうしても3~20時間ぐらい見ないといけないのは割と辛い。
最初は2倍速で聞き流して、何回も繰り返して見る。

一方、書籍のメリットは辞書代わりになること。
ある程度、基本概念に慣れたら、中級向けの本が読めるようになる。
図書館で数冊の本を借りて乱読すれば、どんどん理解が進むので楽しくなる。

書籍のデメリットは、初心者向けの本ですら最初は読みにくいこと。
基本的な用語すら分かってないので、写経みたいな感じで結局読了すらできない。
だから、Udemyみたいな動画から取り組んだ方が早道。
Udemyクラスの先生は、その道のプロなので、初心者がハマりやすい箇所を知っていて、比喩の使い方がすごく上手。

最近は、こういう勉強ツールがすごく揃ってきた状況を考えると、自分が高校生だったり新人社会人なら、もっと効率的に学習できただろうに、と思ったりもする。
つまり、現代では、高速道路を使って一気に最低限の基本知識を習得する基盤が揃ってきたわけだ。
そういうツール、学習方法を知っているか否かで、その後のキャリアも変わってくるのだろう。

いつまでも学習を続ける、みたいな感じなのかな。


| | コメント (0)

変更管理プロセスが弱いとトラブルが多い

以前、ITILの研修を受けた時、講師から「変更管理プロセスが弱いとトラブルが多い 」という話を聞いて、非常に心に残った。

【1】ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。
例えば、OSやソフトのバージョンアップ、システム移行、マイグレーションなど。

つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。
このギャップがトラブルだ、と。

だからと言って、ITシステムの変更を生じるインシデントを全て拒否することはできない。
むしろ、ITはバージョンアップすることで、使いやすくしていくのが最大の特徴だから。
そこに矛盾がある、と。

【2】ITシステムは変化があって当然だし、その変化を受け入れて、その変化をコントロールする技術を持つことが重要だ。
その技術が、変更管理プロセスであり、構成管理プロセスであったりすると考える。

つまり、プログラミングやモデリングそのものに問題があるわけではない。
それら技術の進化が激しく、5年も経てば老朽化が当たり前で、5年おきにリプレースしてシステム移行だけでなく業務移行も伴う。
そういう変化をコントロールする術をあなたは持っていますか?と問われている気がする。

ITILはそういう変更管理プロセスに着目した考え方だと思う。

僕は、そういう変化をコントロールできる開発基盤として、Redmine+Gitが必要ではないか、と考えている。
そのアイデアも膨らましてみる。

変更管理の基盤は構成管理が支えている: プログラマの思索

XDDPと言う派生開発: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない: プログラマの思索

| | コメント (0)

より以前の記事一覧