サーバント・リーダーシップ入門

入門となっている本書は、サーバントリーダーシップに関しての背景や著者二人の対談などを通してどんなものであるかの解説を行っている。

サーバントリーダーシップという言葉を聞いたのは随分と昔の話だなぁと思って発売日を見ると、2007年。
もう18年も前の本なんだな、と気づく。
当時はサーヴァントと聞くとFateのことしか思いつかなかったものだ。

世の中的に、今のリーダーシップ像がどうなっているのだろうか？はあるのだけど、現代においてサーバントリーダーシップで語られている話はだいぶ受け入れられているようにも思える。
考え方自体は受け入れられているとは思うのだけど、それはリーダーなのかマネージャなのか？となるとちょっと考え込んでしまう。
人を支える。という意味においてはマネージャのほうがしっくり来るんですよね。

グリーンリーフがサーバントリーダーの持ち味として以下を出している

1. リードするという個人の側の意識的なイニシアチブ
2. 大きな夢、ビジョナリーなコンセプト、究極のコミュニケーション
3. 傾聴と理解
4. 言語と想像力
5. 控えることを知っている
6. 受容と共感
7. 感知力、予見力
8. 直感、信頼、決断
9. 見通し
10. 気づきと知覚
11. 説得上手
12. 癒やしと役立ち

半分くらいはサーバントリーダーとしてわからなくもないけれど、別にサーバントリーダーじゃなくても、というのが正直な感想だ。

本書でも語られているけれど、トップダウンで物事を決めていく従来型のリーダーシップと、フォロワーにつくすというか、フォロワーが動きやすいようにフォローしていくようなサーバントリーダーシップ。
それぞれ必要な場面は存在すると思うので、どちらかという話ではないんだと理解はしている。

そしてどちらを選ぶかは、チームが何に対面しているかにもよるし、チームメンバーの成熟度というかなんというか、そういうものにも左右されてしまう。
自走が難しいからこそフォローをする必要があるんだろうけれど、フォローで方向性に関してうまいこと向かわせることができるのだろうか？
そもそも、この”向かわせることが”って考えている時点で違うのかもしれない
うーん

まぁ、とりあえず引っ張るだけがリーダーじゃないよ！ってところと、当時と今では前提がちょっと変わってきているものもあり、その変わることへの一役を買っていたんだろうと思うことにした。

Audibleで「プロジェクトマネジメントの本物の実力がつく本」を読んだ

書名: プロジェクトマネジメントの本物の実力がつく本 組織力・コミュニケーション能力・リーダーシップ・キャリア構築力を全部鍛える
著者: 橋本将功
出版社: 翔泳社
発売日: 2023年10月19日

本書は、いわゆるプロジェクトマネジメントの手法が書かれているわけではない。どちらかというと、マインドセットや組織のあり方といったものが中心となっている。

プロジェクトマネージャー一筋23年の著者が、これまでに経験した失敗から学び得た知見を注ぎ込んだ一冊で、組織力・コミュニケーション能力・リーダーシップの3つの能力を高めるための考え方と行動が丁寧に解説されている。

印象に残ったキーワード

本書を読んで気になったワードをいくつか挙げる。

• 組織のマネージャとプロジェクトのマネージャを兼任しない
• ブリリアントジャーク(有能だが組織に対して悪影響を与える人材)
• 防衛戦・撤退戦となるプロジェクト
• いつまでプロジェクトマネジメントをし続けるのか
• フェーズにおけるプロジェクトマネジメントの労力
• プロジェクトマネージャへの評価と待遇

思い返して特に記憶に残っているのは、「防衛戦/撤退戦」という考え方と、プロジェクトマネージャへの評価・待遇、そして組織マネージャとの兼任に関してである。

防衛戦と撤退戦という考え方

私はこれまで「負け戦に挑む」と表現していた。どう考えても最初から負け戦になるのが目に見えているプロジェクトは存在する。すでに炎上しているケースが一番わかりやすいが、そもそも内容的に無理なのではないかというものを、政治的な理由や業績的な理由で受けざるを得ない状態がそれに当たるだろう。

本書では、それらに対して「最終防衛ラインをどこに置くのか」を定めるべきだと述べている。なるほどと思った。

これは「勝利の定義をどこに置くのか」という話と似ているが、たとえば「プロジェクト完了時に誰も辞めていなければ勝利」といった定義や、場合によっては「プロジェクトを終わらせること」自体を勝利条件として設定せざるを得ないこともあるだろう。

何かしらのライン、目標を持たないと、精神的に全員が潰れてしまうか、ゾンビのような状態になってしまう。このあたりは心の持ちようとして意識していきたい。

プロジェクトマネージャの評価という課題

プロジェクトマネージャの評価に関しては、正直答えが思いつかない。

会社組織における人事制度として、プロジェクトマネージャという職種がどこまで定義されているだろうか。職階としてのリーダーやサブリーダー、マネージャという位置づけはあったとしても、プロジェクトマネージャというのはプロジェクトにおける役割であって、組織上の職階として定義されていないのが私の所属組織である。

そうなると、もちろん評価のタイミングでその業績に基づいて評価は行うが、「プロジェクトマネージャという功績に対しての評価なのか」と問われると悩ましいところだ。技術職上のスペシャリスト的な位置づけとして、プロジェクトマネージャの職階を作ってしまった方がすっきりする気もする。

組織マネージャとの兼任問題

私自身は、プロジェクトマネージャとして動くこともあるが、最近は組織のマネージャに軸足が移ってきている。そもそも、しっかりとプロジェクトを導いていくような難易度の高いことは私には厳しい(組織のマネージャが難易度が低いというわけではないが)。

しかし、兼任している方が世の中的にも圧倒的に多いのではないだろうか。もちろん、何をプロジェクトとして捉えるのかは現場や組織によっても違いはあるだろうが、結局プロジェクトマネージャができる有能なメンバーは、評価された結果、組織のマネージャに任命されそうである。

人事制度として組織のマネージャの方が給料が高い傾向にあり、ある程度昇進してきたら組織を任せる立場に上げないと給料が上がらないという、なんとも本末転倒な理由がありそうだ。このあたりは大きな課題になっていると感じる。

最後に

本書は、プロジェクトマネジメントの実践的な「実力」を身につけたい人、特に新規事業やDXに携わるマネージャー、受託プロジェクトのマネージャー、キャリアアップを図りたいプロジェクトメンバーにおすすめの一冊である。単なるテクニックではなく、プロジェクトマネージャとしてのキャリアや組織との関わり方まで含めて考えさせられる内容だった。

だいぶ前に届いていたのですが、なかなか読み進められず。。時間がかかりました

Software Design (ソフトウェアデザイン) 2025年12月号

今月の特集はID管理。
このあたりはちょっと苦手ですね。。。

BtoBというか、社内システム的なものを作る上ではLDAP連携はあれど外部の認証基盤を使うシーンは無いわけではないですが、結構限られる・・・うーん、相手によりますかね。

それこそOktaとか入れていれば使うことになるでしょうし。
それでも連携の手法というかやり方はそこまで大きくは変わらない印象です。
どうもあまり読み進められませんでした

連載で最近のお気にいりは「技術選定の舞台裏」今回はSUZURIのスマホアプリが取り上げられており、面白く読むことが出来ました。

いつもこの連載では自分の不勉強を感じられて辛いところですが、今回はKMPに関して。
少し前にKotlinのMultiplatformという存在を知ってはいたものの、しっかりと調べておらず今回の内容をきっかけにして調べてみようと思います。

また、Flutterでの難しさに関してもちょっと気になるところですね。
ちょうど今、Flutterに案件で挑戦しようとしているところなので、SUZURIの方々がうまく行かなかったというところが該当するのかどうか。
このあたりも勉強不足です。

というかですね、勉強なんて追いつかんのですよ。もう。
ふんがーってところです。眼の前の仕事にどれだけ積み重ねていけば良いのやら。

眼の前のことばかりだと外に目を向けることが億劫になってしまうので、やはりSoftware Designさんには頑張ってほしいところです。
ありがとうございます（何目線）

なんとなく手に取った本だったが、自分自身が組織運営に関しては悩んでいるというか、なんとかしないとなと思っている背景もあり色々と考えさせられる本だった。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Audibleで10時間近かったけれど、2周してしまった

オフィスワーク、リモートワーク、ハイブリッドワーク

GitLabはタイトルの通り、全従業員がリモートワークを実施しているオールリモートの組織とのこと。
本書としては、リモートワークの推進。それもハイブリッドの形態ではなくGitLabと同様に全従業員をリモートワークにすることを推奨としている

ただ、個人的には少し極端な気もする。
ハイブリッドの問題として挙げられているのは、オフィスワーカーとリモートワーカーそれぞれのメリット・デメリットによるお互いへの不満から来ているもの。
オフィスワーカーにとっては、通勤時間があることへの不満はありつつもオフィス設備の利用や情報取得の即時性。特に会社組織の上位レイヤーが出社している場合は、それらの人たちからの覚えの良さや情報伝達のスピードが利点として挙げられる。
リモートワーカーはなんといっても通勤が無いことによる時間の有効活用が一番の利点となる。一方で、オフィスワーカーだけが享受できる設備や情報取得に対する格差を感じてしまうところかもしれない。
先輩社員が出社している場合は、直接的な指導を受けやすいのは間違いなくオフィスであるだろう。

実際問題、新入社員やロースキルの若手メンバー育成を考えた場合、オフィスワークのほうが質問のしやすさや、問題を抱えていることへの察知のしやすさという点で良いように感じる。
どうしても、こういう有名企業の場合は、そもそもそこに入ってくる人のベースが高いという前提があるのではないかと勘ぐってしまう。
このあたりは、単純に管理の仕方の問題はあるかもしれないが、正直できる気がしないのが実情。
結果として、これを実現するためには先輩社員も出社をする必要があるなど、全体的にリモートから逆行してしまうという問題が生じる。

GitLabをオールリモートで効率的な組織足らしめている一つの要素として、情報を徹底的にドキュメント化していることを本書では紹介している。
このドキュメント化ができるのであれば、ハイブリッド状態でもある程度まで情報格差は解消できるのではないかとも思う。
オフィスワークするかリモートワークをするかの選択肢がエンジニア側に委ねられているのであれば、そこまで問題にならないのではないだろうか。もちろん、このドキュメント化の徹底ということの難しさは大いに感じることではあるのだけれど。

ドキュメント化

本書を読み、そしてGitLab Handbook の存在を知ってから、自社のドキュメント化をなんとか進めないといけないという認識を強く持つようになった。
あまりにも暗黙のルールが多すぎてしまい、ルールが定まっていない。
もしくは、明確になってなくその時その時で判断されてしまっている。これは臨機応変とは違うだろう、と。

リモートワークをするためではなく、しっかりとしたルールを明確化する。記録を取るということはこの先のAI活用が当たり前となる会社組織の中で非常に重要な要素に感じる。
ツールの進化によってドキュメント化も随分と以前と比べればやりやすくなっている。
特に私はミーティング中に話に夢中になってしまってあまりメモを取ることが出来ない。自動文字起こしをしっかりと活用しつつ、そのテキストをどう活用していくのかを含めて検討し、明文化していくことで組織の中での浸透を図っていかなければいけない

うーん、現状があまりにも出来ていないのでやることが多すぎてめまいがしてくる

これまでは正直、そのあたりをバックオフィス部隊の仕事であろうと文句をいうだけの立場だったが、少なからずメンバーからの質問は定期的に発生する。
それを考えると、二度手間なところはあるが、整備したほうが全体としては良くなりそうな気もする。
一方で、それはあくまで暗黙のルールで、公式的に明文化されていないのであればそれを明文化する方に組織内へ働きかけるのが正攻法ではある。

正攻法ではあるのはわかるんだけれど、結果としてすごく面倒くさい方向になりそうな気もするので気が進まないというのも正直なところ。

まとめ

読んでいて、学びになることは非常に多かったのだけど、モヤモヤしていたりだめだなーって思うところが多く、「ではどうするか」に関しては足がすくむところはある

言ってしまうと、本書で書かれていることの殆どは、会社組織における人事制度を中心とした枠組み。
開発組織に属している中で、どこまで独自制度を整備できるかということには結構な制約がかかる。
そして全社的な立場に立ってしまえば良いのかもしれないけれど、それは別にやりたいことじゃないんだよなーって。

まずは自組織でできるところ。
特にドキュメント化に関しては進めていくとしてそれ以上の範囲をどうするかは戦略を考えないと行けない。

今回、本の主題であったリモートワークに関して記事を書いたが、それ以外にも初めて聞く単語や考えさせられること満載の書籍だった。
GitLab Handbookは公開されていることなので、膨大ではあるが少しずつ読み込んでいってエッセンスを有効活用していきたい。

いい本だった。

Audibelで「本質をつかむ」を読んだ

本質をつかむ

先日、会社の研修でマネージャーに求められるスキルとしていくつか挙げられた中に、この「本質を見極める」というようなものがあった。

本質

自分自身、色々な場面でものすごく表面的な反応をしてしまうことがよくあると思う。
色々な場面でそれを感じるわけだが、特に上司と話をしている中で、物事の捉え方が違うな、という場面に出会うこともある。
何かしら検索でヒットしたものを、そのまま鵜呑みにしてしまうというと考えてない感じがするが、でも実質的に考えが足りていないのだと思う。
反射になっているのだと思われる。

そんなこんなで色々とモヤモヤしている中で本書を見つけたので手にとって見たというわけだ。

前半は本質を見抜くことのメリットなどが書かれているが、基本的に本書を手に取る人であればそのメリットを列挙することにそれほど意味が無いのではないかと思う。

読み進めていくとわかるが、結局のところ、考える訓練を続ける必要がある。
ただ、そもそも考えた結果導き出した自分なりの答えが、本質なのかどうかの判断が難しい。
考えた結果の確からしさがわからないと、なぜなぜを続けて行っても終わりが見えなくなることもあるはず。
この、答えがあるようでないような問いはどうしたものかと攻めあぐねる

面白いと思ったのが、本質をつかむトレーニングとして、1週間のメニューを提案してきている点。

• 月曜日: 本質的な「意味」を見抜くトレーニング
• 火曜日: 本質的な「原因」を見抜くトレーニング
• 水曜日: 本質的な「目的」を見抜くトレーニング
• 木曜日: 本質的な「特性」を見抜くトレーニング
• 金曜日: 本質的な「価値」を見抜くトレーニング
• 土曜日: 本質的な「関係」を見抜くトレーニング
• 日曜日: 本質的な「大局」を見抜くトレーニング
  題材はニュース記事や仕事の中から選ぶことになる

やってみないとわからないところだが、変に深読みしているだけで本質にたどり着くことができるのだろうか。
まぁ、でもやってみないとわからないところはありそう。

技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック

読書術と銘打たれているが、読書の方法にとどまらず、本の選び方から始まり、読み方。そして情報発信や共有の方法までを含めた構成になっている。

選び方に関しては、書店や図書館での選び方は正直私にとってはあまり活用することはないかな？と思ったが、洋書を買う際のHumble Bundle, Better World Booksなどは初耳でした。
ちなみに、紹介されていたBookDepositoryはすでに閉鎖されているそうです。。。

特にHumble Bundleは、1.0USDでのまとめ買いもできるみたいで、その時々でラインナップの差はあるのですが試してみるのには面白そう。
洋書の場合は読むのが大変そうという問題はあるのですが、このあたりはLLMを駆使するなりしてなんとかしていきたいところですね。
Humble BundleはPDFでの提供をしてくれそうなのでまだなんとかなるのですが、問題はKindleでの洋書です。
Kindleで購入して読み進められていない本も実は手元にあったりするので。。。
そういう意味で考えると、Amazonで洋書を買うのはやめておいたほうが良いかな、という気がしてきてしまいます。
Kindleで読みたければPDFを取り込めば良かったと思うので。

読み方に関しても、わかっていながら実践できていないことが多いです。
特に、物理本であればパラパラとめくるということはよくあるのですが、電子書籍になるとパラパラと進めるのが正直難しいんですよね。
ただ、技術書などで例題をコーディングするような系統だとどうしても時間がかかり、結果として最後まで走り切ることが出来ないケースがよくあります。
そういうときに、定期的に先を見ることで、進めるためのモチベーションを復活させるということはいいな、と改めて感じました。
このあたりは実践していきたいところ。

本を読んだあと。
基本的に私はBlogに書くことにしているけれど、書いているだけだな、と改めて思った。
あまり活かしきれていない。

仕事におけるコミュニケーションは、すべからく行動に結びつく必要があるということをどこかで読んだ気がする。
本に関してもそうであって、この本を読んだ後で、では自分の行動として何に活かしていくのか。どう変えていくのか（場合によっては何も変わらないこともあるとは思うけれど）
つまりは何かしらの学びがあってほしいところ。
その整理ができていないのだと思った。

まずは、Blogに書く前にObsidianに記載してその内容を整理可能にする。
そしてこの本を受けてどうしていくのかを考えて見るということをやってみようと思った。
洋書に関しての挑戦もしていくとともに、技術書を継続して続けるためにも定期的に先を見てモチベーションを上げる。先を見てモチベーションが上がらないようであれば、それは逆にあまり現時点の自分にとってはタイミングとしてあっていない本なのかもしれない。
その時はおいておこう。

また、新しいプログラミング言語などを学ぶ際には図書館で複数冊借りて違いを見るというのも面白い方法だと思った。これは直近でDartを勉強しようとしているので試してみたいところ。
ただ、千葉市の図書館でFlutterを検索したら3年前のSoftware Designしか出てこなかった。。。

技術書はなかなか厳しいな。現実は。。
これは、都内の図書館のほうが良いのかもしれない

創刊50周年記念号であるランナーズ1月号が届きました

ランナーズ 2026年1月号 

私自身はランナーズを定期購読し始めて数カ月というひよっ子ですし、そもそも走り始めて3～4年というレベルなので、50周年と言われても何にも懐かしさの欠片もないわけですが、これまでの歴史を感じる一冊です

面白いのが、それぞれの時代に色々なトレーニング方法が紹介されているのですよね。
LSDが初めて紹介された号や、ファルトレクなどなど。
知っているトレーニング方法からちょっとしたTips的なものまで紹介されていて面白かったです。

個人的に取り入れてみたいな、と思ったのは2012年11月号「信号待ちはジャンプの時間！」
これは面白い。

走っていると少なからず赤信号や車を待つようなシーンに遭遇します。
トラックを走っているわけではない以上しょうがないですね。

これまでは迂回したり信号無視したりウロウロしたりとしていましたが、ジャンプによってバネを鍛えるという発想はなかったです。
これであれば、無理に信号無視する必要もないし、かえってリラックスしてトレーニングすることができそうですね

また、同じようにバネを鍛える方法として縄跳びも紹介されており（2019年10月号）、そういえば縄跳びは地味に長くやるの大変なんだよなぁと思い返します。

多くの著名人が50周年に寄せてコメントを入れているのでまだ見切れてはいませんが、のんびり眺めていきたいと思います

「一分で話せ」でおなじみの伊藤羊一さん著「壁打ちは最強の思考術である」をAudibleで読んだ

壁打ちは最強の思考術である

伊藤羊一さんといえば、Voicyで話をよく聞いており、壁打ちに関してのよく話が出ていたことを思い出しました。
（最近はVoicy自体を諸々の理由で聞かなくなってしまったのですが）

何年もVoicyで伊藤さんの話を聞いてきているので、なんというか書かれている内容がどれもいつも話されている内容であることに、本当に日常的に壁打ちが溶け込んでいるのだと気が付きます。

実際のところ、壁打ちに限らず発話することで思考が整理されるというのは何度も経験していることで、それは部下との1on1でもよく生じる現象です。
ただ、これを壁打ちとして日常の中に取り入れるというのは、職場環境にもよるとは思いますが、どうすれば良いのかがパッと出てこない。

多分、余裕がなさすぎるのだろう

本書の中でも、コーヒー片手にウロウロしていると壁打ちの依頼が来る。。。なんてエピソードが紹介されているけれど、それは壁打ちが組織レベルで根付いている職場であるし、そもそも日常的に壁打ちをするようなネタがある・・・？

と、ここまで考えてふと思うのは、我々IT技術者に取ってみれば、壁打ち＝ソースコードレビューなのではないかと。
いやいや違うだろうと。

レビュー ＝> 対象に対してのレビューアーからの評価や改善点の指摘
壁打ち ＝> 壁打ちをしたい人の思考の整理・深堀り・気づきの創出

と考えるとやはりレビューを壁打ちとするのにはちょっと無理がありそう。
レビューを出すもっと前の段階なんだろう。

であるならば、タスクを与えた後でその実装方針やなんかの検討結果を話してもらうような”壁打ち場”を意図的に作ってしまうのが良いのかもしれない。
ペアプロやモブプログラミングに近いのかもしれない

そんな気がしてきた。
いずれにしても、時間を取って行う行為ではあるので全てに適用するというのは難しいところだけれど、やってみる価値はありそうだ。

そしてここまで書いていてちょっと思うのは、私にとってこうやってブログを書くという行為も一人でやっているけれど壁打ちみたいなものだよな、と。
誰かに読んでもらって反応が返ってくるわけではないので、打ちっぱなしな感じはあるけれど。
まぁ、それはそれだろう。

HBRの12月号をようやく一通り。
今月号は「P. F. ドラッカー 『真摯さ』とは何か -経営と人生の指針-」特集でした

DIAMONDハーバード・ビジネス・レビュー 2025年12月号 ［雑誌］特集「P. F. ドラッカー 『真摯さ』とは何か -経営と人生の指針-」 ＤＩＡＭＯＮＤハーバード・ビジネス・レビュー

ドラッカーの言葉として、「真摯さ」という言葉はそれなりに認識しているつもりでしたが、元々の言葉である”integrity”という単語の意味。ニュアンスという認識は全く持っていませんでした。
そういう意味では日本語訳に頼るというのはある意味難しいものですね。
Google先生でインテグリティを検索すると下記のようになります

インテグリティとは「誠実さ」「真摯さ」「高潔さ」を意味し、高い倫理観や道徳観に基づいて、自分の信念や原則に忠実に、一貫して行動する様を指します。単なる正直さにとどまらず、不利な状況でも自分の信念を貫くことが本質です。特にビジネスにおいては、経営者や管理職に不可欠な資質とされ、企業全体の信頼性を高める要素と考えられています。 

インテグリティの主な意味

• 誠実さ・真摯さ: 正直であるだけでなく、自分の言動に責任を持ち、言葉と行動を一致させること。
• 高潔さ: 自分の信念や原則を、妥協することなく一貫して守り抜くこと。
• 完全性・健全性: 語源のラテン語「integer」が持つ「完全な」「健全な」という意味合いも含まれます。
• 責任: 失敗や困難な状況に直面しても、現実から逃避せず、自分で責任を負おうとする姿勢。 

ビジネスにおけるインテグリティ

• 経営者・管理職の資質: 信頼を築く上で不可欠な資質と見なされ、特に管理職や経営者に求められる重要な要素です。
• インテグリティ・マネジメント: 法令遵守だけでなく、より広範な社会的責任や企業倫理を実践する経営手法を指します。
• 企業文化への影響: インテグリティの高い人材を採用・育成することで、組織全体の誠実性を高めることができます。 

では、ここで言う「自分の信念や原則に忠実に、一貫して行動する様」で挙げられている”自分の信念や原則”がなにか？と考えてしまうと途端に自信がなくなってしまうものです。。。

ただ、物事を判断するうえで何を重視するのか？何を基準にして良し悪しを決めていくのかということに関してはある程度作ることができるのではないだろうか。
もちろん、IT技術に関して言うと判断基準が変わらなかったとしても、その時その時での最新技術の変化によって判断結果が変わることは多くありそう。

逆に言うと、そういった変化によって生じた前提条件の変化も、基準を明確にすることで一貫性を持った形で受け入れられるのではないかとも思う。
ようは一度判断した内容に対しての一貫性ではないという話なんだろう。

まぁ、判断基準がブレブレになってしまわはないようにだけはしないといけません。

ドラッカー。
一時期、かなり感銘を受けて著作や関連作を色々と手を出したことがあります。
今思うと、ちゃんと身になっているのだろうか？は非常に怪しいところではあるのでこれを機会に読み直してみたいと思います。

ドラッカー名著集1　経営者の条件

少し前に購入した、AIエージェント開発の本を亀スピードですが進めています。
Kindleで購入したのですが。。。

https://amzn.to/44cXD3H

まさかの固定レイアウト本でした。

AIなどを取り扱うのであればデータの重要性が第一に考えてほしいものですが、まさかの固定レイアウト。つまりは画像本です

スマホで見ると文字が小さくて読みづらいし、拡大すればスクロールを必要とするのでこれも読みづらい。
更にKindleでマーカーを引くこともできない。

なぜ固定レイアウトにしたのでしょう。。
レイアウトにこだわりを見せたかったのかもしれませんが、作中のコードもコピペできなかったりして、正直Kindleで買ったことを後悔したくらいです。
紙で購入したほうが良かった。

よくよくAmazonのページを見ると、「※この電子書籍は、「固定レイアウト型」で配信されております。説明文の最後の「固定レイアウト型に関する注意事項」を必ずお読みください。」と書かれているので、それに気が付かなかった自分が行けなかっただけなのかもしれませんが。。

残念だ