コンピュータ書籍の学習をどのようにされていますか

知識は道具です。道具にも色々ありますよね。 使わない事が確定している物。 その内使うかもしれないけど今は必要無いもの。 頻繁に使うから手元に常備しておかないといけない物。 確実に使う予定があり、使用方法が複雑で熟知しておく必要がある物。 全部一緒くたにしては効率が悪いです。 仕事と同じで、知識も使用目的が決まっているなら優先度を付けられるはず。 優先度に応じて習得の度合いを変えましょう。 高いのだけしっかり読んで、低いのは付箋でも貼っておけばOKですよ。

個人の知識レベルも違うし、やり方が合う・合わないもあるから、 一概に、効果的な方法を見つけることは難しいと思います。 個人的には、知人SEさんと多分同じ。 複数のアプリケーションを使った経験から、基本的な機能・操作に ついては感覚的に理解出来るので、分からない部分だけを調べることが 多いですし、そもそも書籍はほとんど買いません。 まずは製造元のWebで公開されているマニュアルやFAQ、サポートや インターネットで検索して、対応することが多いです。 トピ主さんがなされているように、 書籍・マニュアルを読み進める方法でもいいと思いますが、 一アプリケーションの中でも各機能を利用する頻度がまちまちですし、 中には全く使わない機能もあるから、全体を知る必要はないかなと 思ってしまいます。 まあ、詳細部分を含めた全体を把握したいのか、 ひとまずは使う機能だけでいいのかによると思いますが。

私は200人程の中小企業に勤め、自分でも製品に搭載するプログラムを組んだし、会社のシステムを外注に頼んで構築し、いろんなソフトに触れました。 会社業務にどのソフトを入れたら良いかは、デモソフトを見たり、担当者の説明、パンフレットに頼るしかありません。 でも、過去に経験したことで、そのソフトの長所や弱点が見え、弱点について説明を求めると、自分の考えが合っていることが多かったです。 実際にソフトを導入し、簡単な説明を受けて、社員へ説明をしますが、実際に操作してみて使い方がわかりました。 ソフト（アプリケーション）の使い方を知るためには「ソフトの目的」（何のために存在するソフトか）を理解する。 さらに、その目的を達成するために、どんな「機能」があるかを知ることが大切です。 それと「このソフトなら、こんな機能があるはずだ」と思って探したら、たいてい備わっています。 大抵のソフトは同じような操作方法になっているので、ある程度は経験で操作でき、分からないところをマニュアルを「辞書代わりに」参照します。 それで、業務で通常使う部分さえ習得できれば、仕事は十分できるわけです。 そうではなくて、一般的なICT技術で「今どんなものがある」「今後の流れ」などを理解したいのなら、1日100ページ以上は読み、カルテ作成は必要ないと思います。 たくさんのアプリに触れることができるのなら、使って見て比較することで、だいたいの使い方や長所・短所が見えてきます。 プログラミング言語を学ぶのなら、書籍を（理解できなくても）一通りは読むのが良いですが、実際にプログラムを組みながら、分からないところを理解する方が早く学べます。 ソフトの使い方も同じで（昔は誤操作でデータが壊れるソフトもありましたが、今はほぼないので）実際に使ってみて、分からないところを調べるのが効率的で習得も早いです。

私（63・男）が在職中、新しいシステムが導入されますと、その取扱説明書・図面集だけで　1万ページを超えたものでしたから、数名で読むところを分担したものでした。 ＩＣＴ　情報・通信・技術ですから新しいシステムとなれば通信回線の建設には土木部門もはいってきます。パソコン・タブレット・ＬＡＮだけが　ＩＣＴではないからです。 着工から竣工まで　数年かかることもあります。一人でなにもかもということは期間らして無理でしたから、作業分担をしてそれぞれ勉強し、それを持ち寄って作業を進めたものでした。書店にその分野の書籍が売っているわけではありませんでしたから、ひたすら　説明書を分担して読むしかなかった。

　本職はプログラマーではありませんが・・　自分達の職場のオフコンで使う業務用プログラム作成程度の経験者です。 　マニュアルや参考書を頭から全部を読むことは考えません。プログラム作成時なら「こんな命令がなかったかな・・」プログラムを読む時は「このコードは何だろう・・」と必要に応じて調べます。トピ主さんが言う「辞書の様な使い方」です。ABC順でも機能順でも使用頻度とは連動していませんから、使う可能性の殆どない命令なども含めて頭から読んでいては、時間もかかるし理解も追いつきません。皮肉を言えば「Ｚ」まで理解した頃には、そのアプリや言語は時代遅れになっています。 　私は知識より、知恵とセンスが重要だと思います。だから本を読むより、実際のプログラム作りの練習等を優先し、分からないことを参考書で確認します。 　現在の言語はバグがあっても大暴走をするリスクは少ないですよね。外部から切り離されたシステムでの実践を通じた習得はかなり楽になりました。 　知恵と最小限の知識があればプログラムは組めます。後は効率や速度やデータ量や分かりやすさといった付加価値(＝センス)です。 　レベルが分からないので、思いっきり初心者向けの例を使いますが・・ 　例えば「０にＡを一万回足した回答Ｘを求めよ」という場合 「X=0: X=X+A: X=X+A: X=X+A ・・・」という長いプログラムでも正解です。でもスマートではありません。 　だから 「同じ命令を、指示した回数繰り返せ」という命令はないか？ 「かけ算」の命令はないか？　と探します。 　まずは、質が悪くてもプログラムを扱えること、 　その次に、スマートにプログラムを扱えることです。 　ある意味で英会話のスキルアップと同様です。 　ですから私の使い方は辞書と同じです。 　長い辞書を全部読むことよりも、片言でも使うことを優先します。　

最近新しいアプリの開発を始めました。 まずは手元に環境を作って、公式ドキュメントとそれを解説したサイトとかを参考に自分で「手を動かして」います。 読んだだけではダメです。手を動かす。 今githubでサンプルがいくつもあります。それを落としてくる。 やってみると気になる点がいくつも出てきます。改造したくもなります。トライしてエラーを出す。そしてエラーを検索する。その繰り返しです。 最初何のこっちゃわからないドキュメントもとりあえず読んでおくと、その点と点がいつか繋がる時がきます。それが線になって面になります。 以上はプログラミングのアプリ開発の話ね。 そうでなくて、単にアプリの使い方とかなら別に検索すれば何とかなります。 あとSEはプログラミングできる人ですか？上流の開発を書籍だけで読むと必ずプログラマとの齟齬が出ます。また上流から下流に下りてくるので時間がかかります。 昨今はSEもプログラマです。アジャイルとかオプデプスとかいいます。 スピード感が違います。意思決定も早いし決まれば修正も早い。 知識としてのICTなのか身に付けるためのICTなのか分かりませんが、プログラミングはやっておいて損はないです。論理的に物事を考えることは大きな意思決定に重要ですし些細なことにも応用が利きます。 プログラミングは新しい概念の切り替えには苦労しますが、ベースの知識があれば言語が変わっても書き方に相違点はあまりないのでオススメです。

皆さま、親切にご指導下さり、本当にどうもありがとうございます。 私は、皆様のレベルまでいっていません…しかし、恥ずかしながら現在行おうとしている学習法を、記載をします。 （例えば）私は、ZoomとTeamsを使えるようになりたい。 　　 　　手元にはそれぞれ、ZoomとTeamsの200頁のマニュアルがある。 ●私の学習方法：25頁ずつ付箋で区切って8日間で読む。 　　　　　　　　（理解ができなかったら、何回か回す。） 　　　　　　　　解らない言葉は、ネットで調べてカルテに記載する。 ●長所：読了後、割と躓くことなく、力強くZoomやTeamsを使用できる（と思われる。） === しかし、ICTに卓越した方々は、↑の学習方法ではない気持ちがするのです。何だか、もっと別のやり方をされていると思うのです。 セキュリティやPhotoshopElementsや、VBA書籍は、上記のやり方で3回程回しました。メルカリなどは、2回程、WordやExcelの解らない機能は、辞書代わりに使っています。 恐れ入りますが、引き続きご指導頂ければありがたいです。 貴重な知識を頂くことになり、大変申し訳ありません…。

＞読了後、割と躓くことなく、力強くZoomやTeamsを使用できる（と思われ そこまで「さほど躓かず」に「自信を持って」使いたいですか？ ＞ICTに卓越した方々は、↑の学習方法ではない気持ちがする 今はICTに強くない一般の社員にパソコンを配り「このソフトを使え」という時代です。 そんな人も「簡単な使い方」だけ教えれば ・わからなくてもやってみる ・躓いたところで調べる （パソコン担当者に聞く） のやり方で使っています。 トピ主さんの方法は（極端に言うと）まったく泳げない「カナヅチ」の人が「泳ぎ」を覚えるため「水泳の教本」を読んで「うまく泳げるように」なってから初めてプールに入るのと似ています。 （ZOOMはやってませんが）私がZOOMのような会議を業務として社内に導入するなら「隣の席の同僚とZOOM会議」をしながら操作方法を調べたり、覚えてから、社員に操作方法などを通知します。 パソコンに触るのも苦手な営業マンでも、今回のコロナで、突然「ZOOMで会議をしろ」と言われ、恐る恐る会議をしている人が多いはずです。 パソコン設定はしてもらい、簡単な使い方を教えてもらったら、あとは会議しながら実践して覚えているはずです。 まずはやってみる、操作してみることが大切だと思います。 PhotoshopElementsは個人的に20年位使ってますが、マニュアルをまともに読んだことはありません。 初めての時だけは簡単な使い方だけ読みます。あとは使いながら、分からないところを調べています。 だから20年使っても知らない機能が多くあり「こんな機能があることを知っていれば良かったのに」と思う事もありますが、基本機能は十分に使えています。 トピ主さんも、本を読んでから使うのではなく、本を見ながら使う。使いながら本を見る。と言うやり方に変えませんか？

皆様、ご返信をありがとうございます 私は一時期、誰にも頼れずに指導をさせて頂く時期があった為、完璧主義になってしまったのかもしれません。 自分に浸透しているやり方について、長年の習慣を捻じ曲げていくのは、とても苦しいことですが…やるしかない、と思います…。 自分のどこを変えていくのか、どこを変えていかないのか、一遍には変えられず、簡単なアプリケーションから始めて、徐々に段階を経ていきたいと思います。 まだ、考えがまとまらず、もう少し試行錯誤が続くと思います。 明らかなことは、私のICTは私だけでは成り立たず、多くの先輩方のご助力が必要ということです。私も、自分のICTへの向き合い方が定まった時に、困っている人達を助けられる私でいたいと思います。 これからも、宜しくお願いいたします。 いつも、ありがとうございます。（secure base拝）

PhotoshopElementsで今年１月に私が「発見」した機能がありました。 写真の上にテキスト文字を重ねる場合がありますが、普通に単色（たとえば白）で書くと、白い雲と重なると文字が読めません。 文字の背景全部が白ければ「黒」にすれば良いのですが、白い部分もあればどうしますか？。 文字を白色にし、輪郭線を黒色にすれば、背景がどんな色でも文字が読めます。 そのような輪郭線がついた文字はどのようにして書くのでしょうか。 私のPhotoshopElements１４では、メニュー一発ではできません。 トピ主さんの作った「カルテ」にやり方が書いてあり、そのカルテが１０分程度で探し出せてやり方がわかり、（もしもカルテが探せなくてもやり方を覚えていて）すぐに実行できるのなら、トピ主さんの「PhotoshopElementsは、上記のやり方で3回程回しました」という苦労は「たいした物だ」と凄く凄く尊敬します。 そうであれば、トピ主さんのやり方は、時間はかかりますが、そのやり方自体に凄く効果があると思います。 私は今年１月にヘルプを見たのですが、やり方を忘れてしまい、今、ヘルプを見てやり方を探し出すのに１０～２０分かかりました。（ヘルプで「文字色」を検索し「塗りと線」のページの「レイヤー上のストローク（アウトライン）オブジェクト」がそうでした） 方法は ・白い下地を作る（写真がないので） ・その上に白色で文字を書く（60ptで書きました） ・書いた文字のレイヤーをラスタライズする ・書いた文字のレイヤーを選択する ・上部のメニューから「編集」→「選択範囲の境界線を描く」をクリックする ・境界線の幅（ピクセル）と色を決める（5ピクセル・黒色にしました） ・位置は中央 ・合成の描画モードは通常、不透明度100％、透明部分の保持はチェックなし でできます。どうでしょうか。

コンピュータシステムの用語、メニューやコマンドの名前は、ある電気信号で行われる事象に人間の生活で使う言葉を無理やりつけているだけです。その裏の機械の動きの想像力が必要な仕事です。それは基礎力がないとできません。基本を勉強してたら読みやすいかと。 図も多い分野だけに２０ページどころか100ページも そうかそうかと読めます。ただ自分の基礎力を超えたら辛いです。 言葉が異質で コピぺならコピーで一時記憶装置メモリへデータをおき 貼り付けでそこから違うメディア行きを指示 保存コマンドでハードディスクへ。これが頭にあるかないかで仕事が、かわります。 だからディスク保存、CPU計算、出力のコンピュータの基礎機能に通信OSI参照モデルくらいは聞いたことないとつらいはず。またさらに専門的なキャドなどセンサーやＧＰＳになると三角関数わからないと読めないものもあります。又、できるだけ安心して失敗していくことも必要。検証し失敗かどうか見極められる時間や心も。皆さんが言うようにためしにやってみれる部署であるべき たとえばメモリを理解するには、本を閉じて実際にやり保存し忘れ全部消える体験をしてみる 見えないメモリとハードディスクの差の意味がわかるように。 車の運転は教習所が日本の場合はあり 水泳は浅めの安全なプールがある、同じく書籍や各ソフトにはチュートリアルなどがあり仮サンプルがあります。ただ！最新ソフトZoomなどやりたければ毎日２０ページてなく新しい機能は1分の英語ビデオ解説理解できないと。ZoomやMS。さらに進歩すOSやメディア、新しい通信規格で新旧ソフトは想定外バグはやみませんから、そこは文章化されたものじゃ間に合わない。そこを分析するには各種コミュニティが。それが英語。そこがキツイなら日本ののみで仕事すべき。私もそうしてます。一日百頁読める得意な分野にうつったほうがいいです。

分かりやすく言えば”機能”だけ覚えれば良いんです。 機能の主だったものは詳細まで覚えておけば良いですが、それ以外は売る覚えで良いんです。 主様のやり方を否定はしませんが、私の場合すべてを読むとパンクしてしまいます（笑 ですので”何ができるのか”だけを覚えるようにしています。 ちなみに知人から聞かれてもそう答えます。

プログラミング言語、一文字も書けない私でも、zoomは普通に使えますけど。ICTとか大袈裟に聞こえます。単なるWEB会議用ツールですよね。マニュアル読んでません。とりあえずインストールして画面に出てくる指示に従うだけです。 一からマニュアルを全部読むのは時間の無駄だと思います。 分からない箇所があればヘルプページで検索すればいいだけです。

トピ主さんの長年の習慣を一気に変えるのは難しいかもしれませんね。 とはいっても、アプリを習得するのに、マニュアルを最初から最後まで 何回も読む方法は、時間がもったいない気もします。 マニュアルの全ページに目を通さないと不安になってしまうのなら、 丹念に読む個所とページをめくる程度でよい個所のメリハリを付ける 工夫が必要かと思います。 ご提案ですが、 ・マニュアルに取り掛かる前に、超がつくような入門書を１日で通読 ・マニュアルは、最初のページから読まない を試してみてはいかがでしょう。 最初に、入門書を１日で一気に読みます。 途中で理解が不十分な部分には付箋をつけておきます。 次に、マニュアルを１日１章（または数節）、 最初からではなく、気になるテーマから読んで行きます。 その際、入門書で理解不十分であったことろがクリアされたら、 入門書の付箋を外します。 マニュアルは、重要だと感じた部分に、付箋やアンダーラインなど 印を残し、自分なりにわかりやすいようにしておきます。 また、わからなかった箇所は、ネットなどで調べて、マニュアルに 書き込んだり貼り付けなどをして、その１冊さえ見ればよい形にします。 途中、索引部分のキーワードにアンダーラインをしておくと、 学習するテーマで肝要となることが明確になります。

プログラミングからネットワークのアーキテクト、セキュリティコンサルなどやってます。 本は大量に買いましたが、とっかかりしか読みません。 使って覚えます。

【学習の心掛け】 １．優先順位>知識は道具。アプリによって習得の方法を使い分ける。 　　<判断材料> 　　1使わない事が確定している物。 　　2その内使うかもしれないけど今は必要無いもの。 　　3頻繁に使うから手元に常備しておかないといけない物。 　　4確実に使う予定があり、使用方法が複雑で熟知しておく必要がある物。 ２．実操作重視>読んだだけでは駄目。 　　実際に使いながら、解らない所をマニュアルで確認、 　　理解する方が早く習得できる。 ３．知恵とセンスが重要 　　>もっと効率の良い方法はないだろうか、と常に探し続ける。 ４．まず、かたことでも、アプリを扱えること。 　　次に、スマートに扱えることを目指す。 【習得の方法】 １．辞書代わり>使う機能だけで良いのではないか。 　　 　　1最初の頁から読まない。 　　　（全部読み終わったら、そのソフトは時代遅れになっている) 　　2丹念に読む頁とさらり流す頁を分ける。 　　3理解不能な所は、付箋を付け、解ったら外す。 　　 　　4情報を、マニュアル一冊に完結させる。 ２．協力者を募り、作業分担をして学習。 ３．映像・音声などを上手に取り入れる。 === 恐れながら、こちらのレスの内容を、まとめてみました。 皆様、真摯に意見を出して下さり、全員の書き込みが嬉しかったです。 心から、どうもありがとうございました。（securebase拝）

トピ主さんのまとめを読むと、マニュアル本を読むためのマニュアルを作ってるだけのような…。 ZoomもPhotoshopElementsもWordも、開発者側ではなく利用者側の立場ですよね。これらのツールは一般的に誰でも使えるようにUIがデザインされていて、そこまで複雑なものではないと思います。 他の人も書いてる通り、使う目的がはっきりしていればそれに即してポイントを抑えて憶えればいいわけです。 「誰にも頼れずに指導をさせて頂く時期があった為」と書いてありますが、 トピ主さんの仕事はもしかしてツールを使う仕事というよりも、ツールの使い方を教える仕事なのでしょうか？ もしそうであれば、トピ主さんにとってソフトウェアやプログラミングは目的を達成するためのツールではないわけですよね。つまりポイントもおさえられず目的もなく学ばなければいけないわけです。 興味もわかないだろうし達成感もないだろうし、なかなかきついと思います。 もし社内で「とりあえず一人覚えて、それを人に教える」というシステムをとってるのであれば、それを変えた方がいいのでは…。トピ主さんを通さず現場の人が直接学ぶシステムの方が確実じゃないでしょうかね。