IT本

2022/05/26

「コーディングを支える技術」は良い本だ

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読んで、良い本と思った。
ラフなメモ書き。
プログラミング初心者の適当な感想。

【参考】
コーディングを支える技術――成り立ちから学ぶプログラミング作法:書籍案内|技術評論社

「コーディングを支える技術」著者公式ページ
「コーディングを支える技術」著者公式ページ 補足記事

【1】Javaで開発経験をした後、RubyやPythonを覚えた今、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読むと、ああそういうことか、と気づくことがある。

【2】IF文の裏ではGOTO文が動いている、という内容を読んで、VBのことを思い出した。
VBでは、例外処理などのAPIが貧弱なので、割とGOTO文がよく出てくるので、VBは好きでなかった。
たぶん、APIが貧弱な古いプログラミング言語ほど、GOTO文が幅を利かせている。
その分、何でもできるが、とても読みづらく保守しづらい。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」の一節に、大学でC言語を初めて習った人が、「while文があればfor文はいらないのでは?」と思ったらしいと書かれていた。
僕も似たような感覚を抱いていた時があった。
JavaでもRubyでも、なぜ、while文、do-while文、for文、拡張for文など、似たようなループ処理の文法があるのか?と不思議に思っていた。

理由は単純で、当初はIF文みたいにwhile文を使っていたが、カウンタ変数のスコープがブロック外にあるので使いにくいから。
だから、while文からfor文の記法により、カウンタ変数のスコープはブロック内に収まった。
さらに、拡張for文により、カウンタ変数そのものも不要になった。
さらに、ListのforEachメソッド、Rubyのブロックのように、for文はクロージャとして吸収される。
つまり、プログラミングの文法もどんどん進化しているわけだ。

【3】変数のスコープの説明では、Perlで静的・動的スコープをプログラムで説明してくれている。
Perlを初めて書いていた時、なぜlocalやmyを変数に付ける必要があるのか、分からなかった時を思い出した。

Pythonでは、わざわざglobal/nonlocalで変数のスコープを制御できるようにしてくれている。
この文法を見た時、Perlみたいだな、と思ったことを思い出した。

Rubyなら、def~endのブロックとクロージャのブロックで、変数のスコープが異なるように使い分けている。
この文法は最初は理解しづらかったが、このおかげで、Rubyはメタプログラミングでやり放題ができるわけだ。

【4】オブジェクトとクラスでは、JavaとRubyでは考え方が全く違う。
親子で継承関係にあるクラスがあった時、インスタンス変数、インスタンスメソッド、クラス変数、クラスメソッドの挙動がJavaとRubyで異なる。
Javaでは、インスタンス変数、クラス変数、インスタンスメソッド、クラスメソッドは、親子クラスそれぞれで保持する。
ただし、親クラスの変数に、子クラスのオブジェクトを代入した場合、インスタンスメソッドは、子クラスのメソッドを利用する。
つまり、Javaでは、親クラスの変数の振る舞いは、ポリモーフィズムで動的に処理が変わるように見せかけられる。

一方、Rubyでは、親子間でインスタンス変数が共通として扱われる。
親クラスが定義したインスタンス変数と同じ名前のインスタンス変数を子クラスで使うと、親クラスのインスタンス変数は子クラスで上書きされる。
この書き方に慣れると、「クラス(型)は仕様である」を時々忘れてしまう。

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその1)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその2)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその3)

資格取得に40代後半からチャレンジ JavaとRubyを比較(注意しておくことその4)

Javaでは「クラス(型)は仕様である」が、Rubyではメッセージを渡したオブジェクトに全てを委ねる。
Rubyはまさにダック・タイピングなので、例えばdesktop.printが変数なのか、メソッドなのかも動かしてみないと分からない。

【5】多重継承のデメリットをどう解決するか?も、Java、Ruby、Pythonなどで全く違う。
Javaは多重継承を禁止するが、インターフェイスを導入して解決しようとした。
Javaでは、継承の代わりに委譲を進めるが、さらに委譲の参照をソースにハードコードするのではなく、依存性の注入により、設定ファイルを使って動的に変更できるような手法が多くなった。
JavaのフレームワークではDIが多いから、設定ファイルにXMLを用いることが多く、その分、プログラムを書くよりもXMLを書いている時が多くてあまり楽しくなくなる。

Rubyは、多重継承の問題を「どの順番で継承関係を検索するか」という問題に置き換えた。
Rubyでは継承関係は、Objectを頂点とするツリー構造だから、継承ツリーをメソッド検索することで解決しようとする。
include, prepend, refinementsはそういう使い道だろう。
また、Rubyでは、どうしても多重継承したい時は、モジュールでMix-inを使う。

Pythonでは多重継承できる、と聞いていてまだ理解できていなかったが、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」によれば、C3線形化のアルゴリズムで継承関係の検索を決めることで解決しているわけだ。

[Python入門]多重継承:Python入門(1/2 ページ) - @IT

Pythonのメソッド解決順序(MRO) - 情報系大学院生の勉強メモ

【6】それから、並行処理のプログラミングの章も非常に分かりやすい。
Windows3.1やMacOS9は強調マルチタスクで、プリエンプティブマルチタスクではなかった、という一節を読んだ時、昔のPowerbookがMacOS9だった時を思い出した。

並行処理の問題点は、競合状態が起きること。
競合状態は3つある。
1つ目は、2つの処理が変数を共有している。
2つ目は、少なくとも1つの処理がその変数を上書きする。
3つ目は、一方の処理が一段落付く前に、もう一方の処理が割り込む可能性がある。

1つ目の対策は、結局スレッドを使っているので、変数を共有しない方向で解決していない。
アクターモデルのように、メッセージを送ることで解決しようとしている。
Erlangがその例だろう。

2つ目の対策は、メモリを共有しても書き換えないようにする方針もある。
全ての変数はImmutableにすればいい。
Haskellなどの関数型言語がそうだろう。

3つ目の対策は、協調的なスレッドを使う。
たとえば、Rubyのファイバー、Cのコルーチン、Pythonのジェネレータ。

あるいは、ロック、ミューテックス、セマフォ、モニタのような機構を使う。
Javaなら、synchronizedブロックで囲むだけでいい。

【7】自分は「プログラミングのできない山羊」出身なので、プログラミングを経験してやっとこういう本の内容が分かってきたという気がしている。
ソフトウェア開発は、数学や物理、経済学、財務会計、心理学などと違って、やっぱり独特の考え方がいると思う。
自分の中で言語化できていない部分は気づいたらブログで残しておく。

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

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

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

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

| | コメント (0)

2022/01/09

「RubyやRailsは終わった」という記事のリンク

「RubyやRailsは終わった」という記事があったが本当なのか?
見つけた記事だけをリンクしておく。
自分が後で読むためのメモ書き。

【参考】
“Rubyは死んだ”のか? まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1 - ログミーTech

Ruby2系はチームの幸福度を最大化できなかった - Qiita

「Railsは終わった」と言われる理由 - Qiita

Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

Rubyは果たして死んだのか | 日経クロステック(xTECH)

Rubyは終わった?将来性と今後の展望をまとめてみた│エンジニアハック

将来性のないプログラミング言語5選として「Ruby」が挙がり話題に | スラド IT

個人的にはRubyは好きだ。
メタプログラミングRuby 第2版」を読んで、色々動かして、やっとダックタイピングの意味が分かった。
やはりRubyはJavaとは違う。
Rubyは究極のオブジェクト指向言語なのかもしれない。

また、Rubyというコミュニティも素晴らしいと思う。

なぜソフトウエア後進国の日本でRubyは成功したのか?~ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある: プログラマの思索

一方、RubyはPerlのシンタックスを受け継ぐ部分があるせいか、初心者には読みにくい記法がある。
慣れないと使いこなせない部分もある。

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

Ruby技術者認定試験の感想: プログラマの思索

Ruby初心者が間違いそうなこと: プログラマの思索

メタプログラミングRubyの感想: プログラマの思索

Rubyのブロック、Proc、lambdaのメモ: プログラマの思索

RedmineやRubyについては今後も追いかけていく。


| | コメント (0)

実践した後に勉強するのがエンジニアの本来の道

実践した後に勉強するのがエンジニアの本来の道というツイートに共感したのでメモ。

はじめ??ソシャゲフリーランスエンジニアさんはTwitterを使っています 「中島聡さんが プログラミングの勉強は、アプリの開発を通してするもの と仰っていたけど完全同意です 恐らく100冊の技術書を読むより1アプリを作るほうが勉強になる そして1アプリを作った時の答え合わせのために技術書を読む 勉強→実践が普通の思考ですが 実践→勉強がエンジニアの本来の道です」 / Twitter

エンジニアは、仕事でシステムを開発して経験した後、技術書を読んで自分の経験を振り返る方が良い。

なぜなら、IT、プログラミングの技術書は抽象的で具体性がない。
具体性をいくら書いても、所詮プログラムなので、実際に動かさなければ、どこに落とし穴があるか分からない。
本の中身を丸暗記しても、実際にプログラミングがスムーズにできるとは限らないし、思ったようにプログラミングできない場合が多い。

一通りプログラムを書いて、アプリを動かして体験した後で、その体験内容を技術書で採点する感じ。
技術書に書いている内容に、ふむふむその通りと納得する時もあれば、こんな使い方があったのか、もっと速く知っておけばよかった、と思う時もある。
一方、こういう部分が泥臭くて難しくてハマる部分なのに、技術書に書いていなくて、消化不良だな、と思う時もある。

「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

| | コメント (0)

2021/08/01

OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない

あるブログ記事で、OODAループの時代は、大事なのは使命であり、目標は使命達成のための手段に過ぎない、というメッセージが非常に心に残ったのでメモ。

【参考】
成績未達のものは、きつく叱責すべきか - ウィリアムのいたずらの開発?日記

PDCAサイクルは、1年毎の年間計画でよく使う。
しかし、超短期のサイクルでは使いづらい。
また、コロナ禍のような時代では、当初立てた計画が無意味となってしまった場合、PDCAを最初から作り直さないといけなくなる。

「PDCAサイクル全盛の時代は、目標を数値化してたてて、それを達成したらちょっと伸びた目標を立て続けていく」そんなやり方だった。
しかし、OODAループの時代では、「会社で大事なのは使命であり、目標は使命達成のための手段に過ぎない。」
つまり、「目標が達成しようがしまいが、目標と現実との差を常に感じ、使命達成のために行動する。そのためには目標の変更もあり得る。」

OODAループの考え方は、More Effective Agile ~“ソフトウェアリーダー"になるための28の道標で知っていたけど、腹落ちできていなかったと思う。
飛行操縦士が敵機を撃ち落とすための意思決定構造を形式化しただけ、というイメージで、ソフトウェア開発や経営に活用するイメージがなかった。

OODAループでは、目標よりも、価値や使命が最重要であり、目標や計画は達成するための手段に過ぎない。
目標や計画よりも、価値や使命が最優先であるという行動を誘発させること。

そんなことを考えると、OODAループはスクラムと相性が良いように思える。

| | コメント (0)

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントの感想~日本に足りないのはプロダクトマネジャーだ

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントを読んで、日本に足りないのはプロダクトマネジャーだと改めて思った。
ラフなメモ。

【参考
ソフトウェア・ファーストの感想: プログラマの思索
プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想: プログラマの思索

(2) 伊藤 大地 / Daichi ITOさんはTwitterを使っています 「NHKのデジタル人材採用の募集要項に並ぶ言葉がもはや「メディア」ではなくて、「テック」企業のそれ。全てはソフトウェアの構築とその応用…というデジタルの性質が募集要項にそのままアウトプットされている。 https://t.co/yIZHbpQG5y https://t.co/Yu4YGX97Wu」 / Twitter

一括請負案件では、どうしてもプロダクトマネージャーという役割は持ちにくい。
プロジェクトマネージャが案件の中心にいて、顧客とプロジェクトマネージャが対峙するというクライアント・ベンダー・アンチパターンにはまりやすい。

では、日本では、どんなソフトウェア開発でプロダクトマネージャーという役割が必要になるのか?
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメントのあとがきでは、日本でプロダクトマネージャーが必要とされる場面は、スマホアプリの開発だという。

なぜなら、スマホアプリの開発では、利用ユーザの観点で、利用ユーザの導線を極力簡素化すべきであり、そのために機能はできるだけ削ぎ落とし、シンプルでワクワクするUIをいかに作り出すか、が大事になるからだ。
実際、一括請負案件でも、スマホアプリの開発が混じってくると、従来のウォーターフォール型開発で要件をガチガチに固めた後に機能やUIを開発したとしても、最後のユーザ受け入れテストで数多くの不満が出て収拾がつかなくなる場合も多い。
スマホアプリを実際に触ってみて、初めて操作感だけでなく、本来のユーザ導線を考えるという手戻りも発生しやすい。
僕もそういう現場を見てきた。

つまり、スマホアプリの開発はとりわけアジャイル開発に適していて、利用ユーザのユーザエクスペリエンスを重視するには、プロダクトマネージャーという役割の人が統括する方がうまくいきやすいと思う。


| | コメント (0)

CISOは経営がわかる情報セキュリティ最高責任者である

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドを読んで、CISOは経営がわかる情報セキュリティ最高責任者であると知った。
ラフなメモ。

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドは、セキュリティの本というよりも、IT技術者が経営層になった時、こういうふうに考えたり行動していくべきで、こういう考え方を持つべき、という点が参考になった。
既存の経営陣に情報セキュリティの重要性を認識してもらうよりも、IT技術者自身が経営の知識を持つ方が手っ取り早いし、その方が実際はうまくいくと思う。

リスク管理は、予想される潜在リスクへの対策だけでなく、想定よりも状況がうまく行った時に備える場合もある。
たとえば、ベンチャー企業が社員20名から200名へ急激に成長した時、事業拡大の速度が速い分、いろいろな歪が出てくる。
上手く行っていたチームも、業務量が増えてメンバーが増えると、チームが回らなくなる。
ソフトウェア開発では人員増はうまくいかないという先入観がありすぎて、人員増を極力抑えるのは失敗しやすい。

事業が予測よりもうまくいくと、問題が少しずつ表面化する。
そこで、こんな対策がある。
業務をアウトソースして、固定費(人件費)費を変動費化する。
商流を変えて、固定費(人件費)を販管費にする。
業務をシステム化して効率化することで、固定費(人件費)を抑制する。

組織的には、事業や業務の観点で組織構造を変えて、チームを分けたり増やしたりする。
チームリーダーを社内で育成する。
それでも不足するなら、リーダーを外部から採用する。

つまり、良い状況に変わることも一つのリスクとみなして、リスク対策は考えるべき。

| | コメント (0)

2021/06/20

なぜか2000年代にIT系の良い本が多いと感じる今日この頃

最近、Ciscoベースのネットワーク、組み込みソフトウェア開発・設計のためのモデリング、業務システムやERPを設計・分析するためのデータモデリングや業務フローの本を読み漁っている。
他にも、Matlab・Scilibのようなシミュレーション関係の本も探している。

たとえば、下記の本になる。

【1】「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版」「インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン 実務で使えるネットワーク構成の最適解27」は、オンプレのネットワーク設計の解説でピカイチだった。
インフラ担当者なら当たり前の知識なのだろうが、アプリ開発の経験しかない僕にとってはとても新鮮だった。
クラウドやInfrastructure as Codeが何を解決しようとしているのか、について、考えさせてくれた。

なお、この本は2010年代の本だが、ほとんどのCiscoルータ・スイッチの解説・コマンドリファレンス本は2000年代が多い。

【2】「組込みソフトウェア開発のための オブジェクト指向モデリング (組込みエンジニア教科書)」も良かった。
話題沸騰のポットを題材に、ハードウェアのポットを要件定義から、オブジェクト指向設計、C++のソースコードまで落としてくれる。
業務システム設計とは違う観点で、状態遷移図やパッケージ間の依存関係が非常に重要になってくる。
2006年頃の出版で絶版。

【3】「7つの要素で整理する業務プロセス (for Mutual Interest SERIES)」は、業務フロー図の演習本だ。ひたすら、7種類の業務フローのサンプルと解説をしてくれている。
内部統制が導入された頃に、ITに関係ない人が業務フローを使うことになった時に使われたのだろう。
2007年頃の出版で絶版。

【4】しかし、それらの本は2000年代に良い本が多く、2010年代はほとんど出版されていない。
オブジェクト指向モデリング、データモデリング、オンプレのネットワーク、シミュレーションなどの基本的な技術の解説本がほとんど出版されていない。
なぜなのだろうか?

おそらく、IT技術のトレンドが激しく変化してしまい、従来の設計や技術は基盤として埋め込まれて、見えなくなってしまうくらい、当たり前になってしまったからではないか。
実際、データモデリングやオブジェクト指向モデリングも、その概念や考え方は、20年前も10年前も変わらない。

しかし、SOEのWebシステムでも、枯れた業務システムであっても、データモデリングは必須だし、オブジェクト指向モデリングも知っていて当然だろうが、そういう技術を知らずにどっぷり最先端の技術にハマってしまう。
今となっては、最先端の技術から古い技術に遡るしか無いのだろうが、基本的な技術無しで取り組んでいる感じで、何か腑に落ちない時が多いと思う。

2000年代に良い本が多いのに、割と絶版になっていたりする。
すると、それらの本に含まれているノウハウや優れた説明は継承されることなく消えてしまう。

たぶん、ベースとなる技術はもはや当たり前であって、ベースの技術や基盤の上で、次々に新しいサービスをどんどん生み出していくのが普通になっている。
だから、逐一古い基礎的な技術を掘り返すのは手間がかかり過ぎるのかもしれない。

この辺りの理由は色々探りたい。
そして、その悪影響についても考えてみたい。


| | コメント (0)

2021/05/08

『オブジェクト指向でなぜつくるのか』第3版が出版された

『オブジェクト指向でなぜつくるのか』第3版が出版されたのでメモ。

【参考】
『オブジェクト指向でなぜつくるのか』第3版

オブジェクト指向でなぜつくるのか 第3版|日経の本 日経BP

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」は良い本だ: プログラマの思索では、第2版を改めて読み直してみた。
オブジェクト指向プログラミングがヒープ領域を使っていることから、UMLによる汎用の整理術、XPに至るまでのアジャイル開発、そしてパターン言語まで幅広い。
こういう一大ストーリーでまとめているのはすごいと思う。

僕が思うに、オブジェクト指向の考え方をアジャイル開発、特にスクラムに適用している所が一番興味はある。
たとえば、「More Effective Agile “ソフトウェアリーダー”になるための28の道標」では、「スクラムチームはブラックボックスとして扱うべきだ」という主張が何度も使われている。
つまり、スクラムチームはInputとOutputだけ管理すればよく、プロジェクトマネージャはマイクロマネジメントする必要はないし、マイクロマネジメントすべきでない、という主張が一貫して流れている。
これもオブジェクト指向のカプセル化がわかっていれば、とても腑に落ちる。

More Effective Agileは良い本だ: プログラマの思索

「オブジェクト指向でなぜつくるのか」本はずっと読まれ続けてほしいと思う。

| | コメント (0)

2021/02/01

本を書く時の心構え

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2020/12/09

GTDは箱の使い分けが鍵を握る

GTDは興味を持つけど、なかなか使いこなせない。
GTDは箱の使い分けが鍵を握ると気づいたのでメモ。

【参考】
何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

GTDを噛み砕く

プロジェクトマネージャの意思決定プロセスや判断プロセス: プログラマの思索

【1】GTDが難しいのははぜか?
Inboxに溜まったタスクをふるい分ける箱の数が多すぎて、迷ってしまうからではないか。

GTDを噛み砕く 第1章 GTD をわかった気になる

(引用開始)
ただ、この「箱」が曲者で、GTD では何個も「箱」が登場します。
(引用終了)

7 つもあるの? 何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

(引用開始)
GTD ではリストを 7 つほど使う。この 7 つのリストについて解説する。

7 つもあるの?
7 つというと多そうだが、「気になること」およびそこから派生するタスクには色々性質があり、ちゃんと運用したいなら役割分担がどうしても必要になる。GTD では「こんなリストがあったら便利だよね」という発想で、異なる役割を持つリストをつくって厳選した結果、7 つほどになった。

プログラミングでも神クラスをつくったりはせず役割ごとにクラスを分けたりするが、発想としては同じである。
各リストについて、名前だけ

インボックス(Inbox)
いつかやる(Someday)
資料(Pointer)
カレンダー(Calendar)
連絡待ち(Waiting)
プロジェクト(Project)
次に取るべきアクション(NextAction)
(引用終了)

GTDでは、頭の中にあるモヤモヤしたアイデア、不安なこと、ちょっとした気付きなどは全て、Inboxに吐き出す。
そこから、箱に分けていくのだが、そこで手が止まる。
どこに入れればいいのか、迷ってしまうのだ。
はじめてのGTD ストレスフリーの整理術を読むと、なぜか混乱してしまう。

結局は、それぞれの目的に箱があるだけと思えばいい。
プログラム的には、IF文で条件分岐しているだけと思えばいい。
下記のPythonプログラムが分かりやすい。

何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita


(引用開始)
フローチャートというとひるみがちになるが、イメージとして以下のとおり、ただの条件分岐の列挙なのでひるむことはない。

def proceed_inbox(list_inbox, list_itukayaritai, list_siryo, ...):
for kininaru_koto in list_inbox:
if kininaru_koto means 'いつかやりたい':
list_itukayaritai.append(kininaru_koto)
continue
if kininaru_koto means 'あ、これ改めて見たら不要だわ':
continue
if kininaru_koto means 'これってただの情報源だよね':
list_siryo.append(kininaru_koto)
continue
...
# 全部処理したのでインボックスを空にする
list_inbox = []
(引用終了)


【2】GTDが難しい理由のもう一つが、箱を整理するタイミングが混乱しやすいこと。
「週次レビューが重要だ」とはじめてのGTD ストレスフリーの整理術でよく書かれているのだが、ピンとこなかった。
結局は、箱に溜まったタスクを整理するだけのことだ。

箱ごとに、中身を整理するタイミングは微妙に異なる。
重要度が高ければ、日次レビューだし、随時レビューすることもある。
一方、レビューのタイミングは、週末だけ、月末だけ、年に1回だけのこともある。

リストとは 何かとわかりづらい GTD について、エンジニア向けにざっくり説明してみる - Qiita

(引用開始)
各リストは以下の設定(使い方などのルールを定めた設定)を持つ。

Write Timing …… いつ書き込むか。書き込む頻度はどの程度か。
Write Content …… どんな内容を書き込むか。
Review Timing …… いつ見直すか。見直す頻度はどの程度か。
Review Action …… 見直しとして具体的に何を行うか。
要するに「いつ、何を書き込むの?」と「いつ読み返すの?読み返して何をするの?」を定める。
(引用終了)

【3】「GTDとはリスト駆動生活である」ということだ。
リストを作っておき、1日の生活をリストから駆動して、タスクをこなしていく。
チケット駆動開発と発想は似ている。

(引用開始)
リスト駆動生活とは、リストを中心に生活を回すこと。具体的には

朝起きたらリストを見る
やることが書いてあるので、一つ選んで消化する
リストに戻ってきて、次のやることを選ぶ
...
こんな生活。窮屈そうだが、リストにさえ書いておけば忘れない という状態を手に入れることができるため、ほぼ必須の概念である。

GTD では、「次に取るべきアクション」リストがこれに相当する。
(引用終了)

GTDはリスト駆動開発であり、箱の整理のタイミングを重視している。
その発想をチケット駆動開発に適用すれば、チケット駆動開発でも、チケットの整理や棚卸しはタイミングが重要だ。
チケットの整理のタイミングに対し、プロジェクトのイベントを対応付ければ、チケット駆動開発は上手く運用できるはず。

| | コメント (0)

より以前の記事一覧