書籍・雑誌

2021/02/01

本を書く時の心構え

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2020/12/06

考えながら書く人のためのScrivener入門の感想

「考えながら書く人のためのScrivener入門 小説・論文・レポート、長文を書きたい人へ」を読んで、改めて、物書きになる環境について色々気づきがあった。

【参考】
統合執筆環境Scrivenerのリンク: プログラマの思索

「考えながら書く人のためのScrivener入門」の帯には、「書く才能はある!足りないのはScrivener」という文言がある。
僕も出版した経験があるから理解できるが、書物1冊を書き出すのは本当に大変だ。
大変な理由は、1冊20万字くらいの文字数を書き出すこともあるだろうが、むしろ、構成やストーリーの一貫性や整合性を考える点の方にあるだろうと思う。

「考えながら書く人のためのScrivener入門」には、3人の小説家がScrivenerを使って執筆した経験談をインタビューしてくれている。
読んでみると面白い。
気になった点はいくつかある。

一つは、小説や書物という長編を書く場合、何かしらの文書の構成方法や構成を管理する環境が必要になる点だ。
たとえば、200ページの本を印刷してつなげると、16メートルの長さになるらしい。
すると、修正する時に、該当の箇所を探し出すのに、画面スクロールを16メートルも指を動かしているわけだ。

修正を何度も繰り返すたびに、そういう動作を何度もやっているわけで、そういう無駄な作業時間をストップウォッチで計測したら相当なロスになるはずだ。
実際、単純な検索機能では、同じような文言が見つかったり、構成を見直すためにあちこちを修正する場合は、考える時間よりも探し出す時間の方が多くなり、せっかくのアイデアが失われてしまう。

そこで、Scrivenerの出番になる。
Scrivenerでは、文書を1ペインのアウトライナー画面、2ペインのテキスト画面、コルクボード形式でアイデアを発散させる画面など数多くの機能がある。
つまり、ある時はアイデアを適当に発散させたり、あるシーンだけを詳細に書いたり、いくつかの物語のプロットの構成を考えながら節ごとに入れ替えたり、などと考える場面に合わせて変更できる。

他にもタグ付け、ラベル付け、とか、数多くのファイル出力機能、Dropboxと連携してバックアップの同期を取るなどができるらしい。
個人的には構成管理が気になるが、スナップショット機能があるらしいので履歴管理できるらしい。

2つ目は、3人の小説家は統合執筆環境Scrivenerだけで書いているのではなく、小説を書くまでのアイデア発散フェーズではマインドマップやアウトライナーのエディタを使ったり、遂行する段階ではPDF出力して印刷した紙で読み直すなど、割とアナログな面も残していることだ。
結局、ITというツールをいかに使いこなして、生産性を上げているとしても、その根っこにあるアイデアの発散や連想によるアイデアの結合などは、従来のアナログの手法とは変わらない。

この点は、Redmineのようなチケット管理ツールでも、その背後にある開発プロセスの話に結局落ち着く点に似ている。

3つ目は、長文の原稿は数多くの短編に分割して管理するのが推奨されていること。
ソフトウェアにおける分割統治と同じ発想だが、ソフトウェアが階層化してポインタを使う手法に対し、執筆では、文書を階層化するとしても1ペインのアウトライナーを有効に使う手法になる。

つまり、Wordのアウトライン機能のように、レイヤごとに見出しを揃えるが、その見出しはフォルダでもありテキストにもなりうる。
BEITELというアウトライナーのエディタのように、1階層目の見出しだけでもストーリーとして読めるし、2階層、3階層の中間レイヤの内容だけでも十分にストーリーとして読めるような構成にするわけだ。

BEITELとは - アウトラインエディタ BEITEL(バイト)

僕はマインドマップが大好きなのだが、何かしらの報告書や議事録のように、長文の文章を書く時にマインドマップでは何か物足りず、何かしらの機能が必要だと思っていた。
たぶんその原因は、発散したアイデアを一つの文章という1次元のデータに変換して、論理構成を保つには、アウトライナーのようなツールが必要だと直感していたためだろうと思っている。

この辺りの思考ツールや書き方については色々まとめてみる。


| | コメント (0)

2020/04/09

ソフトウェア・ファーストの感想

「ソフトウェア・ファースト」を読んだので、感想をラフなメモ書き。
非常に良い本だったので、自分の気づきをメモしておく。

【参考】
ソフトウェアファーストを読んで開発組織と外部委託について考えた | masaytan's blog

『ソフトウェア・ファースト』読書メモ その1 - Qiita

ノンプログラマーの機械屋が読んだ「ソフトウェア・ファースト」

【1】「ソフトウェア・ファースト」は良い本だ。
「ソフトウェア・ファースト」のターゲットは、特にメーカーの経営陣、中間管理職の人達だと思う。
そういう言葉は書かれていないが、トヨタの話やメーカーの生産管理とソフトウェア開発の比較、などの話が多いので、メーカーの人にはとても響くだろう。
特に、メーカーにいて、ITに詳しくないが、ITが経営に直結している立場の人達、つまりメーカーで経営上の意思決定をする人達が読むべき本だ。
どのメーカーも、トヨタが生み出したJIT生産、なぜなぜ分析、自働化など数多くの概念を自社に取り入れようと努力してきたから、あのトヨタも変わっているのか、と気づくだろう。

【2】IT技術者として「ソフトウェア・ファースト」を読んで興味を惹いた部分はいくつかある。

【3】メーカーがソフトウェア開発を内製化していない点を痛烈に批判している。
メーカーの生産管理では、自社の工場で生産計画・生産統制をできるだけ内製化し、その品質管理だけでなく、外部取引先から調達する部品の品質管理も徹底的に行なっている。
「手の内化」というトヨタの言葉はその通り。

たとえば、日本の元請け企業は自社の技術社員を、下請け企業に派遣して、調達する部品の品質管理や進捗管理を行うだけでなく、わざわざ下請け企業の社員に技術指導まで行っている場合が多い。
つまり、日本のメーカーは、自社の工場だけでなく、自社の製品に関わる下請け企業までを生産管理の対象とみなし、一連のサプライチェーンを品質管理することで、品質向上を図ってきた。
だから、日本の製造業が生み出す製品の品質はとても高い。

一方、メーカーのソフトウェア開発では、自社でソフトウェア開発は内製化しないだけでなく、外部からの委託・調達したソフトウェア製品やソフトウェア成果物の品質管理すらも全くできていない。
つまり、メーカーは製造プロセスのサプライチェーンまで自分でコントロールしているのに、なぜ、ソフトウェア開発ではまともな品質管理すらせず、コントロールしないのか、と。
IT技術は知らないから、というのは言い訳に過ぎない、と痛烈に批判している。

たとえば、「ソフトウェア・ファースト」の一節に、トヨタの豊田章一郎社長が社長に就任した時に、企画開発チームに実際に赴いてその知見を乞うたが、あのトヨタの社長でもそうならば、ITが経営上重要になっているならばソフトウェア開発の現場に経営陣も自ら赴くべきではないか、と。
3現主義と言いながら、ソフトウェア開発の現場は見ていないでしょ、と。

【4】SaaSはソフトウェアの特徴をうまく活用している、という主張は本当に興味深い。
SaaSの最大の特徴は、ユーザの生の声をフィードバックで収集できる点だ。

自動車であれ大半のメーカーでは、工場や最新機械などの固定費が膨大な為、資本を減らすために、販売店などを切り離している。
よって、メーカーは販売した製品に関する消費者の生の声を集めるチャネルを持っていない弱点がある。
この弱点は、昨今のGoogle・Apple・Facebook・Amazonを見る通り、メーカーにとって致命的。
トヨタのようなガソリン自動車メーカーは直販プロセスを持っていない一方、後発の電気自動車メーカーであるテスラは、直販チャネルを持っている上に、さらに、自車の運行データをユーザから収集して自動運転に活用しようとさえしている。

Saasでは、ユーザの生の声はカスタマーサポートからシステムのアクセスログに至るまで、数多くのチャネルがあるので、それらを収集して分析することで、より良い製品へ改良するきっかけになるし、開発チームにとっても、製品改良のモチベーション向上にもつながる。

特に、GAFAは、ユーザのフィードバックの収集・分析・改良・リリースという一連のプロセス構築がうまいのだろう。
その一連のプロセスは、アジャイル開発そのものだ。
従来のメーカーが大事にしてきたPDCAサイクルとは本質的に違っていると思った方が良い。

僕自身が持つアジャイル開発の認識も古くなっていると思った。
僕は以前は、アジャイル開発の本質は小規模リリースだ、と思っていたが、今は1日数十回もリリースできるような高速な開発プロセスにまで洗練されている。
そのアジャイル開発の本質は、DevOpsだ。

DevOpsは単に、運用も開発もチームが一体化したもの、という認識だけではないと考える。
ソースを機能改善したら即反映できるリリースプロセスを整備したもの、と認識すべき。

以前のアジャイル開発のボトルネックは、リリース工程にあったと思う。
継続的インテグレーション、継続的デプロイなどがXPのプラクティスにも含まれていたが、それらが重要なプラクティスであった理由は、リリース工程がソフトウェア開発の最大のボトルネックだったからだ。

実際、今でもWF型開発でソフトウェアを開発していれば、製造工程よりもテスト工程とリリース工程で膨大な工数がかかっているはずだ。
多くのプロジェクトマネージャは、テスト工程でリリース工程で手を焼いているはずだ。
つまり、下流工程と呼ばれるテストやリリースの工程がソフトウェア開発のボトルネックであり、それを制御するのは難しい、という現実を示唆していたのだと思う。

しかし、今では、クラウド上でカナリアリリースやInfrastructure as Codeのように、本番環境やリリース作業を構成管理の配下でコントロールできるようになったおかげで、自信を持ってソースの機能改善ができるし、新機能に挑戦できる心理的メリットも生まれているはずだ。
つまり、システムの機能改善という、ソフトウェアの本質的な価値を具現化するものにより力を注げる開発プロセスを構築できるようになったわけだ。

【5】メーカーがソフトウェア開発を内製化した時の組織構造や組織文化の話も非常に興味深かった。

一読した限りでは、メーカーの組織文化とソフトウェア開発の組織文化は水と油なので、ソフトウェア開発は別の組織で分社したり、企画開発に特化したり、マトリクス型組織にする、などの示唆があったのは興味深い。
たぶん、著者自身も数多くの試行錯誤をされているのだろう、と思う。

メーカーではないが、サイボウズの組織構造の変化のコラムが興味深かった。
サイボウズも中小企業だった頃は、機能別組織であって、開発・運用基盤・企画営業など縦割りの機能に分かれていた。
しかし、SaaSを販売してユーザのフィードバックをSaaSに反映していくようになると、そういう縦割りの機能別組織では、社内のコミュニケーションが取れず、現場が混乱した。
そこで、製品別組織に立て直し、企画から開発・運用に至るまでのプロセスを一つの部門で担当できるようにしたら、上手く回るようになり、組織文化も良くなっていった、という。
つまり、機能別組織から事業部制に変化したわけだ。

この話を読んで、チャンドラーの「組織は戦略に従う」という文言を思い出させる。
チャンドラーの組織発展モデルでは、企業内部の組織は事業の発展によって、単一の機能別組織から事業部制組織、そして分社化した子会社・関連会社を持つコングロマリットという多国籍企業へ変わっていく。
ソフトウェア開発の組織構造も、メーカーと異なっているとしても、組織構造のモデルという自然法則に従わざるを得ないわけだ。

【6】ソフトウェア開発組織の職種として、エンジニアという技術専門職だけでなく、プロダクトマネージャーとエンジニアリングマネージャという管理職も上げている点が興味深かった。

僕の理解では、エンジニアリングマネージャはアーキテクトかつプロジェクトリーダーのイメージ。
プロダクトマネージャーは、Scrumのプロダクトオーナーのイメージ。

プロダクトマネージャは、ソフトウェア開発の経験があるのは良い点だが、その経験が逆に邪魔する時がある。
本来の製品のあるべき姿は、その時代の技術の制約から離れて考えるべきなのに、ソフトウェア開発の経験が邪魔して、その時代の実装方法に依存した製品イメージを描いてしまい、本来の姿とかけ離れてしまう弱点もある、と。
そういう指摘は非常に参考になった。

| | コメント (0)

2019/12/27

捏造された聖書の感想

とても面白い。
キリスト教が誕生して、カトリックと三位一体説が正統派として確立するまでの間、数多くのキリスト教の流派があり、それぞれで議論して闘争していたのがよく分かる。

つまり、中国の諸子百家、インドの仏教とジャイナ教の対立のように、原始キリスト教も数多くの流派がそれぞれの自説を主張して生存競争をしていたわけだ。

「捏造された聖書」を読む前に、下記を読んで、キリスト教における三位一体説を理解していたので、聖書が改ざんされた意図や背景が良く理解できた。

キリスト教の発展、分裂後の東西ローマ帝国 http://www.geocities.jp/timeway/kougi-19.html

論点は「イエスは神なのか?人間なのか?」
現存のキリスト教は、三位一体説を奉じるので、イエスは神であり人間でもあるが同質である、という立場。

原始キリスト教の世界では、イエスは人間だったという養子論、イエスは神であるが旧約聖書にあるユダヤ教の神とは違うという仮現論、イエスは人間イエスと神キリストの二つの物理的存在に分割されているという分割論、など多数の流派があった。

しかし、三位一体説を奉じる流派が唯一生き残ったことにより、それら流派の解釈を許さないように、聖書の文言を改ざんしていった、というストーリー。

だから、最近になって、三位一体説を否定するキリスト教の流派、たとえば、エホバの証人、とか、モルモン教などが、現存のキリスト教はおかしいのであって自分達が本来のキリスト教なのだ、と主張しているわけなのか。

こういう理解ができた後、今のキリスト教を信じている人は、この本は信仰を否定するような内容になるので、危険な本だろうな、と思う。
読んでいてハラハラした。

捏造された聖書では、他にも、現代から真の聖書を探していく作業、つまり文献分析学の話を相当詳しく説明してくれているので、とても分かりやすい。

| | コメント (0)

失敗の本質―日本軍の組織論的研究の感想

旧日本軍という当時最先端の高度な官僚組織が日本を破滅に陥れた原因を、組織論に求める、という内容だった。

(1)7つの失敗事例の詳細は、地図を見ながら読まないと完全理解できないと思うけど、失敗に至った話を読むと、とても身に沁みるように感じるのは、たぶん、自分も古い日本の大企業にいるからかもしれない。

改めて思うのは、80年前も今日も、日本のトップは、巨大な官僚組織を上手く使いこなすのが下手、ということ。
一人ひとりの部下を動かせても、「組織を動かす」という能力が足りない、という感触を受ける。

日本の大手企業や官公庁のトップは、その大きな組織の重みをコントロールできず、誰も舵を取らないまま暴走してしまい、破滅に向かう。

一方、アメリカや中国は、官僚組織を使いこなすのが上手い感じはする。
その違いは何にあるのだろうか?

| | コメント (0)

お金2.0 新しい経済のルールと生き方の感想

自然界のあらゆるものは時間の経過と共に価値が減っていくのに、通貨のみは価値が減らないどころか、金利によって増えていく。それは欠陥だ。
だからスタンプ貨幣を導入して、通貨にマイナス利子率をつけよう、というゲゼルの主張。

ビットコインは、報酬設計が秀逸。
インセンティブを強調しすぎて崩壊する金融市場。
誰が得するのか不明な新技術。
理論の美しさのみで実現する気のない思想論文。
しかし、ビットコインは、経済、テクノロジー、思想のそれぞれが役割を果たして、うまく報酬設計がなされている。
ビットコインの発案者は理想主義者ではなく、動くものを作りたい現実主義者ではないか、と。

| | コメント (0)

2019/02/11

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

【追記】
hekitterさんはTwitterを使っています: 「「サピエンス全史」「ホモ・デウス」の図解のリンク https://t.co/6KSKQH4Dph 今日UMLのことを調べてたら、思いがけず興味深いのがあるやんとみてたら、やはりakipiiさんの記事だった。(まだちゃんと読めてないので改めて読む)」 / Twitter

| | コメント (0)

2014/07/05

出版システムや文書共有システムを作った事例

出版システムや文書共有システムを作った事例の資料が最近たくさん出ている。
以下リンクしておく。

注目点は、いくつかある。

1)GitHubやBitbucketを執筆データのリポジトリにする。
2)執筆データはMarkdownのようなテキストファイルで保存
3)ReViewやSphinxなどのツールでPDF・EPUBに変換する
4)定期的にビルドしてDropboxなどに配布する

昔は手書きの原稿用紙に書いて、その後、推敲して修正して、組版に載せていた。
僕も小学校の頃、ガリ版で卒業文集を書いた経験がある。

でも、今は、Wordでもなく、テキストに書いて、即座にビルドして配布する仕組みが普通だろう。
スマフォへ定期的にビルド&配布すれば、通勤や待ち時間でも、著作物をレビューできる。
そのフィードバックを受けて、著作物をさらに洗練させていくことができる。

執筆環境ももっとアジャイルになるべき。

| | コメント (0)

2011/12/17

ユーザの力を利用するアジャイル開発

グーグルで必要なことはみんなソニーが教えてくれた」を読んで思ったことをメモ。

グーグルで必要なことはみんなソニーが教えてくれた」の著者は、元ソニーのエンジニアの方がソニーで四苦八苦したプロジェクト内容とグーグルへ転職した時の雰囲気について書いていた。

気になった文章は、「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」の二つ。

前者は、製品をすぐに作ってはユーザへフィードバックして評価してもらい、その結果を製品に取り込んで機能改善していくこと。
後者は、すぐに作った製品の完成度があまり良くなくても、ほどほどの品質で早めにリリースして、ユーザにバグ報告とバグ検証をしてもらうような仕組みを作ること。

いずれの文章もAgile開発の発想にとても良く似ている。
ポイントは、「ユーザの力を利用して継続的に製品の完成度を上げる」「ユーザの力を利用して問題発見と問題修復を継続的にやっていく」ということ。
つまり、単なる継続的改善だけでなく、ユーザのフィードバックを吸い上げてその内容を製品へ反映していく仕組みも必要なことを示唆している。

Agile開発の発想がソフトウェア業界だけでなく、ソニーのような家電製品などの業界でも必要とされている。
その事実に正直驚いた。
しかし本を読む限り、その発想を著者が在籍していた時代のソニーは理解できていなかったらしい。
著者は「日本人の完璧主義が足を引っ張っている」と言っている。

アジャイル開発の発想をITエンジニア以外に他業界の技術者が理解して実践していく環境は、現在も揃っていないのではないかと思ったりする。

その中でも、「ユーザの力を利用する」仕組みがとても難しいのだろうと思う。
製品の購入ユーザには熱心な人も入れば、アンチなユーザもいる。
彼らの声を全て正しいと仮定して製品に全て取り込むには現実的に難しい。
また、彼らの声がたくさんあるほど、重要なメッセージを見落としやすい。
そして、ユーザの声を反映した製品を更にユーザに使ってもらえるように、届ける仕組みも大事。

最近流行しているFacebookやTwitterは、そういうユーザの声をリアルタイムに集めやすい。
だからFacebookファンページでユーザの声を収集してはユーザへフィードバックしていく手法で、マーケティングをやっている会社も多いのだろう。

チケット駆動開発でよく使われるRedmineやTracも、高機能化したBTSやITSを単なるバグや課題を収集するシステムではなく、一つのポータルなシステムへ拡張していると思う。
例えば、収集したデータを各種の観点でレポートしたり、問題修復した製品をアナウンスしたり、ユーザと議論するフォーラムがあったり、製品のTipsを公開するWikiがあったりする。
それらの機能があるおかげで、ユーザと製品の開発者がリアルタイムに議論して、より良い製品へ改善していく仕組みが整うはず。

アジャイルという発想は僕はとても自然だと思う。
でも、実際の組織に当てはめて運営していくには、まだまだ何かが足りない。

| | コメント (0) | トラックバック (0)

2011/11/03

日本のIT業界のホラー小説「人形つかい」

一部で有名だったシステム開発の読み物(全23話)を読んでみた。
あらすじはネタバレになるので書かないが、いくつか感想をメモしておく。

【元ネタ】
Press Enter■: 人形つかい(1) 未知との遭遇

日本のIT業界で働いた経験がある人なら、リアリティがありすぎて思わず引き込まれるだろう。
他の業界の人が読んだら、何故今の日本で奴隷のように働くのだろうと不審がるだろう。

感想を二つほど書く。
一つは、日本の製造業に特徴的な多重下請構造をIT業界が真似たことで、技術者が手配師になるか一匹狼の技術者になるかどちらかしか選択肢がない状況になっていること。
この件については過去にも色々考えた。

手配師になるか技術屋で生き残るか: プログラマの思索

個人的には、松原友夫さんの指摘「しかし、品質に関して重大責任を負うに至ったソフトウエア開発ビジネスで、成果責任を負わない派遣形態がかくも横行しているのは日本だけである。 」が最も本質を突いていると考える。

人月ビジネスの特質~成長しないこと: プログラマの思索

日本のソフトウエア産業、衰退の真因 | スラッシュドット・ジャパン

日本のソフトウエア産業、衰退の真因 - 真髄を語る:ITpro

もう一つは、SIが独自に作る俺様フレームワークに技術上だけでなくマネジメント上も致命的な欠陥があること。
この件も過去にも色々考えた。

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

SIerの俺様フレームワークは最悪だ

SIが俺様フレームワークを作りたがる理由は、昔のCobol開発のように、上流工程の設計さえできればプログラムは自動生成すればいい、という発想があるのだろうと思う。
その考え方は多分アジャイル開発とは相容れないと思う。

Continuous Delivery~TDDとCIの次に現れた自動化の概念: プログラマの思索

SIerは自動化する対象が違っているのでは? - Togetter

IT勉強会カレンダーを見る限り、日本のIT技術者は向上心があるし、RubyやSeasarなどを日本人が生み出したのだから、技術的に劣っているとは思えない。
オープンソース活動やコミュニティ活動が日本の変革の鍵を握っているように直感している。

| | コメント (0) | トラックバック (0)