いつも誰かに仕事の邪魔をされると思っている人の仕事の変え方

一生懸命仕事をしているのにいつも想定外のことが起きて思うように仕事の成果が得られない。
関係する人が思うように動いてくれない。

 自分は一生懸命仕事をしているのに、遅くまで残って仕事をしているのにあちらこちらからあれこれ言われてその対応だけで精一杯になってしまう。

こんなことを感じながら仕事をしていたら疲れてしまうし、続かないですよね。もし、そのような仕事をするうえでの壁を無理なく回避できる方法があるとしたらどうでしょうか。

仕事の仕方はその人その人で覚え方やスピードが違うので誰にでもフィットするやり方ではないかもしれませんが、何か1つでも今の仕事が上手くいかないところをなくせるとしたらやってみたいですよね。

上手くやりたい仕事を眺め直してみよう 

タスクを期限までに求められている品質で終わらせたいとしたら、まず、自分が担当している作業の範囲にどのような作業があるかを思い出してみましょう。できれば、紙に書き出したり、メモ帳アプリなどに文字にした方がより良いです。

 

           仕事①②③④

 

例えば、上記の作業イメージだったとします。並べられた作業は誰の作業かを作業の横に書き加えます。ほとんどの人が自分の作業だけを書き、作業の担当者に自分の名前が加えられています。

 

           仕事(自分)①②③④

 

並べた作業は本当に自分一人で完結する仕事かを考えてみましょう。

ひとりで完結する仕事はゼロ 

 分業が進んでいるので自分一人で完結する仕事は皆無です。会社員でもエンジニアでも誰かが仕事を他の誰かに頼み、頼まれた人がさらに他の仲間と一緒になって仕事をしています。そうして完成した仕事の成果を納めて完了です。

つまり、仕事として捉えるときに自分が担当する仕事だけを切り出して、そこだけをみていると仕事の始まりから終わりまでが見えていない、把握できていないということになります。

 

依頼者の仕事(仕事の開始)①→→→→→→→⑨(仕事の完了)
         自分の仕事②③④→→→⑧
        仲間に依頼する仕事⑤⑥⑦
 

誰の仕事に影響を受けているか

上述の作業のイメージ図で真ん中の自分の仕事しか書いていないければ、自分の仕事は依頼者の作業結果と仲間に依頼する仕事の結果に挟まれていることを意識していないということが言えます。

 

             ↓これの結果と
依頼者の仕事(仕事の開始)①→→→→→→→⑨(仕事の完了)
         自分の仕事②③④→→→⑧
        仲間に依頼する仕事⑤⑥⑦
                 ↑  ↑  ↑  これらの結果に挟まれている

 

誰の仕事に影響を受けているか

上記のイメージ図から自分が担当しているはずの仕事は、依頼者の仕事の出来と仲間に依頼した仕事の出来に左右されてしまっているのです。

もちろん、自分の仕事がきちんとできていることは当然です。

思いがけないこと、想定外のことが自分の作業以外のところで起きて、そうしたトラブルの対応でいつも納期ギリギリだったり、深夜まで残業してリカバーしているのは、イメージ図の仕事全体の中で、自分の仕事だけしか視界に入っていないことが原因なのです。

仕事をする上で、誰の仕事の影響を受けてしまうかを把握しておくことが必要になるのです。 

仕事の価値の受け渡しをモニタリングする

 他の担当者の仕事の出来不出来で自分がいつもギリギリの仕事になっているとしたら、それは最優先で解決したいはずです。そんな仕事の仕方は続きませんから。

 では、既出のイメージ図の場合、どこをどうしたら変えられるでしょうか

 

             ↓①を受け取る際に十分必要な情報があるかを確認する
依頼者の仕事(仕事の開始)①→→→→→→→⑨(仕事の完了)
         自分の仕事②③④→→→⑧
  ③を渡すときに十分必要な情報 ↓     ↑ ③を受け取るときに必要な情報が 
  を渡しているかを確認する   ↓     ↑ あるかを確認する
        仲間に依頼する仕事⑤⑥⑦
                 ↑  ↑  ↑  これらの結果に挟まれている

 

他の人が担当する作業を確認するということは作業の品質をモニタリングするということです。これは他者の仕事を監視するという意味ではありません。他者から引き継ぐ情報が期待する状態であり続けることを確認することであり、自分から他者へ引き継ぐ情報が他者から戻ってくる際に状態を保ったまま、さらに他者に依頼した作業で情報に追加の情報が加えられて戻ってくることを期待どおりになっているかを確認し続けることなのです。

この考えに基づく仕事の仕方は、自分の作業を自分が予定している仕事の進め方で終わらすためにすることなのです。

 

仕事は、価値を増やし続けながら回します。その価値は期待するものでなければなりません。それをモニタリングし続け、自分の仕事が予定どおりに終わるようにコントロールしましょう。

 

 

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

 
カンバン仕事術

カンバン仕事術

 

 

完璧を目指して終わらないのではなく、埋もれている作業をしているから終わらないだけ

facebookザッカーバーグが言ったらしい、有名なフレーズです。

終わらせろ、と。

 

http://oreoka.com/wp-content/uploads/0208002.jpg

 

神よ、完了予定日までに終わらないエンジニアには罰をお与えください。

マジこれな。

 

それを言いたいのではなくて、エンジニアの仕事が終わらない理由は様々あるけれど、納期とコストと実現しなければならない品質があったとき、エンジニアは何を考え、意思決定しなければならないのかということの方が語りたいのです。ええ、語りたい。

 

プロジェクトですから、プロジェクトの目的があって、有期限性の業務活動であることは何度も書いてきていることです。そう言えばそんなことも見た記憶があるなーと思い出してもらえれば結構です。上で書いたし。

 

そうした制約、エンジニアにとっては制約です。作業をする前から決められている枠のようなものですから。その上で、プロジェクトの目的のシステムを完成して届けるためのパーツを作ったり組み立てたり、稼動確認したりするのがエンジニアの仕事です。

 

さて、このエンジニアがしなければならないことのどこに完璧があるのか。

 

どこにもないし、世の中には、第一、完璧なんてないんです。それに完璧なんて目指す必要もないし。しなければならないのは、品質要求を満たすシステムを期日までに完成させることだけです。

 

まあ、もしも顧客が完璧なシステムをと言ってきたら、完璧という言葉を定量的に定義して、必要なコストを見積もれと差し戻せばいいです。出来やしないので。なぜ出来なか。それはシステム開発においてSIerだけで完成しないから。そう、顧客自身の役割分担があるもので、そちらで多くはfaultが起きるから。

 

どこでかって。それは要件定義でですよ。

 

話を戻して、エンジニアは仕事を終わらせなければならない。でも終わらせられないエンジニアが多く、こうしたエンジニアは何をしていて期日までに終わらないのか。

 

それは自己満足の完璧を目指して今その技術情報を調べる必要があるのか、ということをしているから自分で見積った時間内に終えられないんです。

 

エンジニアがやらなければならいことは、納期までに品質要求を満たすパーツを完成させることだけです。作業を初めて調査をするような仕事のやり方をしていてはダメなのです。材料は先に揃っていないとおかしい。なぜならば、それは作業プロセスのインプットだから。

 

インプット → 作業プロセス → アウトプット

 

作業プロセスで調査をするな、ということです。それが必要なら、タスクは分けて、調査の作業と実装の作業を設けることです。

 

あれ、おかしいですね。完璧を目指していたはずが実は調査という埋もれていた作業をしていたのではないかという疑惑になってしまいました。ここでコナンくんが出てきたら誰か死んでますね。エンジニアでしょうけど。それともエンジニアに殺められたPMか顧客でしょうか。

 

エンジニアが仕事としてやらなければならないことは、納期までに要求品質を満たすパーツを作り上げることだけです。それに必要な作業は列挙されていなければならないし、まるっと括ってしまっているなら、何が詰め込まれているかはっきりしておかなければ、1つの作業で進捗を計られ、期日を超過したと責められるだけだし、PM的には何やっているんだこいつは、となるだけです。誰も嬉しくないのです。

 

終わらせましょう。期日までに。

 

 

 

亜人ちゃんは語りたい(5) (ヤンマガKCスペシャル)

亜人ちゃんは語りたい(5) (ヤンマガKCスペシャル)

 
名探偵コナン 93 (少年サンデーコミックス)

名探偵コナン 93 (少年サンデーコミックス)

 

 

 

PERT図を描け。騙されて描け。

プログラム開発のように要件定義から工程を進めることでToDoを詳細化するプロジェクトのWBSは(スコープ漏れや機能漏れは除いて)、何をすれば作業が完了するか明確なので計画も見積もりも予実の較差の把握も対処もし易いのです。

ですが、企画や構想立案や事業立ち上げ的なものは、そうは行かないのです。なぜなら、アウトプットと要求品質が定義しようがないから。

#うーん、アウトプットは企画書などのドキュメントには違いないけれど、何を書けばいいかはそのときどきによるんですよねぇ。あっても標題だけは統一フォーマットがあるかもしれないけれど、大体カウンターになるクライアントや偉い人の気分で変わるんだよなぁ。

流され易い

企画系のプロジェクトはとにかく流され易いのです。何に流され易いかって。それは、ステークホルダーが多くてそれぞれ好き勝手なことを思いつくままコメントするのを全部、受け止めなくてはと思って仕事をするから。

そう、仕事の進め方が流され易い。コンサルのように自己流であっても軸を持ってこのやり方に乗れと言い切れればいいのだけれど、まだ、経験の浅い担当だとそうも行かないのです。

特に、エンジニア上がりは流されますね。

なぜなら、お伺い体質が染み付いてしまっているから。どれだけ口すっぱく言ってもダメです。

本来であれば、委託を受けているとしても、シナリオを描いてステークホルダー全員を同じバスに乗せないといけないのです。バスに乗せる以上、どこを目指すのかバスガイドもしなくちゃいけない。

結果的に、お伺い体質のエンジニアは風見鶏になってしまうのです。

流されないために

では流されないために何をしたら良いか。

少なくとも何をするか、企画なら企画書を作らないとプロジェクトは終われないのだから、それがゴールになるのだけれど、その企画書のコンテンツはたたき台を作って、合意形成をしつつ、修正を掛けてどこかにソフトランディングさせないといけないのです。

こうした企画系のプロジェクトはシステム開発のように細く作業のWBSを切ったり、日程を当てはめてスケジュール化はしないので、そこに担当者が甘えてしまう悪魔の誘惑に負けてしまうパターンが多いです。

どうしたらいいかといえば、PERT図を描くのです。どうせ、WBSのワークパッケージの作業量は見積もりなんてできないでしょうが(仕切れていないのだから)、だからこそ、スケジュールをPERT図にしてマイルストーンからいつまでに終わらないと全体のスケジュールがオーバーランしますよと、企画系のプロジェクトで示し続けるのです。

PERT図を使ってステークホルダーの時間感覚を揃える、ということですね。

締め切りにならないと自分事にならない

どうして締め切り的なマイルストーンがいいのかというと、締め切りが近くまでステークホルダーが自分がやらないといけないと思わないから。

自分たちが意思決定しないといけないということを自覚しないからです。

それを締め切りですよとPERT図でプレッシャーをかけていくわけです。大の大人にそんなことをするのかって。しますよ。大人ななんかいい加減に大きくなった子どもですから。

 

Not My Fault! ~俺のせいじゃない!~

Not My Fault! ~俺のせいじゃない!~

 
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

 

 

このツメの甘いSEに祝福を!「ツメの甘いSEめ、今すぐに爆裂魔法で吹き飛ばしてくれる。エクスプローション!」

子どもさんを持つようになってから学習できることの1つに、

「人は頭の中で何考えているかわからん」

ということです。いくら自分の子どもだと言えども、人格の違う人間の頭の中で何を思い、考えているかまではわかりません。ましてや、何を判断基準にしているかなんぞは全くもってわからないです。

補足しておくと、子どもさんと同じ年齢のときの自分と成績を比較するととても優秀なのである意味どうしてこうなった(褒めてる&親バカ)なのでこのまま好きになことをやって育ってくれ、です。

仕事場では、成人済みのメンバがいて一緒に働いているのですが、これまた、子どもさんと同じように何を考え、何を判断基準にしているかは測り知ることはできません。CTスキャンしても思考までは可視化できないですし、第一言語化できないですからねぇ。

仕事のツメ

仕事に対する考え方、取り組み方はその人ごとに違いがあると思うのです。労働の対価を得るためというストレートな方がまだ素直な印象ですが、社会貢献なんて言われると「はあ、すごいですねぇ(棒」と反応しかねないですけれど、どう思って労働していただいても結果が出ていれば動機はどれでも構わないのです。

ただ、仕事ですから任された仕事のオーダ元が受け入れてくれる、つまり承認できるレベルに持っていくことが必要で、そこに到達できるように仕事をしなければならないのは誰の仕事でも同じです。

同じはずなのに、そこのレベルに到達しないSEが少なくないし、多分、いくら口で言っても治らないと思っています。ただし、一定の改善まではできます。

こうした受け入れてもらえるレベルに到達していない仕事の仕方をツメが甘いなーと思うわけです。

ツメの甘さの材料

 ツメが甘くなるのは、甘くなる材料を使っているからです。それは、ツメの甘い仕事をしているSEが何かしら燃料を投下しているから起きているのであって、ツメが甘くならないようにするには排除できればいいのです。

ツメの甘さの作品例

 ツメの甘さを仕事に生かすとどのような作品としての作業結果ができるでしょうか。あまり見たくはないですけれど。

  • シナリオを書けないので要点を掻い摘んで話せない
  • 他人に仕事を振りたいが説得できない
  • 数字(金額の積み上げなど)に間違いがあり信用されない

 などなど他にもあるし、仕事場でよく見かける事例ではないでしょうか。

ツメの甘さのレシピ

 仕事のツメの甘さはどうやったらできるのでしょうか。材料を探ってみましょう。

 

このツッコミに対する反応ですが、まるでハードニングをしていないOSぽいなーと思いますが。賛同してくれる人はいるかしら。

 

仕事の甘いSEのアウトプットに対してツッコミを入れるとどういう反応が返ってくるでしょうか。

 

  • ツッコミされた所の出来ていない言い訳をする
  • 声が大きくなる
  • 不機嫌になる
  • 他責にし始める

 

多くは言い訳を始めますよねぇ。言い訳なんて尋ねていませんけれど。そのうち、声も大きくなってあからさまに不機嫌に…。誰もSEを怒っていないんだから。どうして、って聞いているだけなんだから。

だってさぁ、わからないんですよ。他人の頭の中で何を考えているか。どうしてそうなったのか。それを知りたいなぁと思っている=理解したいから訊ねているわけなんですがそれも理解されない…。

ツメの甘さの秘伝の素材

ツメの甘さの秘伝の素材。それは、判断基準の置き所です。

判断基準を置く位置が、ワタシとあなたでは違うのです。これは人それぞれで。ただ、中心線から幅を持った上限下限の幅に入っていればなんとなくわかるんですよ。

ところが、その幅に入っていないSEもいるわけです。それはそれでそのSEの特性です。その性質はそういうものだ、として、仕事では困ることもあるのです。中心線の幅の中に置いてくれればいいのですが、幅から飛び出てSE寄りに置いてしまうこともあるのです。このときツメの甘さとなって仕事の出来に影響するんです。

どうして幅の外に、自分の方に寄せてしまうか。そのSEのこれまでの仕事上での経験の積み重ねと性格が影響しているからでしょう。

そうした根っこに近いところにあるものをいくら口で言っても変わるものではありません。

ちょっとずれているだけなので、補助器具を用意しれあげればいいのです。例えば、視覚で認識できる公式や手順のなどを使うようにすればある程度の歩留まりで幅の中に入れることができるようになります。

 

そうは言っても、SEの価値観に近いところにあるので、厄介ではあります。仕事の結果がリジェクトされないように、受け入れられる判断基準の範囲に収めようとしてもらえないと変わらないので。

まぁ、自己中で終わったことにするな、ってことですけど。

「ツメの甘いSEめ、エクスプローション!」

 

この素晴らしい世界に祝福を! 爆裂道 Tシャツ ブラック Lサイズ

この素晴らしい世界に祝福を! 爆裂道 Tシャツ ブラック Lサイズ

 
この素晴らしい世界に祝福を! めぐみんのナイス、爆裂Tシャツ Lサイズ

この素晴らしい世界に祝福を! めぐみんのナイス、爆裂Tシャツ Lサイズ

 

 

PMBOK6版におけるアジャイルの記述頻度と何で読んだらいいか

PMBOKの6版はすでにPDFでPMI会員向けにリリースされています。ネタのように版が上がるたびにページがマシマシになるPMBOK。今回も期待を裏切らない増量っぷりに二郎系技術書としてエンジニアに対してマッスルを鍛えよ、という暗黙な要求が盛られているのではないかと疑わざるを得ません。

表紙

以前のエントリでもご覧いただいていますが、PDFの5版の表紙は紙媒体と同じデザイン。

一方、6版はどう見ても中表紙のデザイン。つまり、真っ白。

5版

f:id:fumisan:20171016073206p:plain

6版

f:id:fumisan:20171016073200p:plain

ちなみに、5版の中表紙はこんな感じ。

f:id:fumisan:20171016073507p:plain

レイアウトも5版と6版と変えているんだなぁと変に感心したり。

ページ数

5版 633ページ

6版 776ページ

その差、143ページのマッスルな盛りです。これ物理、つまり、紙で買ったら後悔しそうなページ数ですねぇ。PMBOKは大判なのでカバンに入れて通勤で読もうなんて考えられない。家においても読まないだろうなぁ。ということは、届け先を会社にしないと一度は持って歩かないといけないことになるのか。

PDF、つまり電子書籍推奨になるのでしょうけれど、これだけページ数が多いと位置や場所で覚えるタイプの人はいちいち検索しないといけないので面倒に感じるかも。

アジャイルの登場回数

実は、5版でアジャイルは既出でない、つまり、全く触れていないと思っていたんですが、これは間違いでした。

アジャイルで検索したら、10件出てきました。

PMI-ACPもすでに出ていたのか…2011年にはパイロット始まっていたから間に合ったんですねぇ。多分だけど。

f:id:fumisan:20171016074807p:plain

では件数です。

アジャイル」検出数

5版 10件

6版 75件

なんと、75件…。7倍強の出現。

f:id:fumisan:20171016075244p:plain

 

記載方法の特徴

6版でのアジャイルの記載の特徴は、各マネジメント、例えば、プロジェクト・スケジュール・マネジメントの概要に「アジャイル型環境や適応型環境への考慮事項」とした章立てとして設けられています。

さらに、付属文書X.3 アジャイル型、反復型、適応型、ハイブリット型プロジェクトの環境として別編が立てられています。

結局、全部目を通さないといけないという…。

何で読んだらいいか

PDFの場合、何かしらのリーダで読まなければならないので、好きなリーダを使ってね、でおしまいなのですが。

Acrobatだと縦スクロールで縦にスワイプスするのが好みなら、Acrobatで。Kindleは横スワイプなので親指でページ送りしたいならそちらで。

何が障害になるか

もう、ページ数が多くてファイルサイズが大きいことです。タブレットなりKindleなりにデータを転送するのが面倒。

何せ、Mac上でもファイルサイズが5版だと15.6MBが一気に6版は104.8MBだもの。 

f:id:fumisan:20171016080654p:plain

 PDFでも転送に時間がかかるとかアホすぎ。

 

 

 

Kindle Oasis (Newモデル) 32GB、Wi-Fi、電子書籍リーダー

Kindle Oasis (Newモデル) 32GB、Wi-Fi、電子書籍リーダー

 
Kindle for Mac [ダウンロード]

Kindle for Mac [ダウンロード]

 
Kindle for Android

Kindle for Android

 

 

 

私のセンパイがマジメ過ぎる講師の件

(私)あー勉強会のお手伝いで疲れた。こんなこと週末にやっているんですか。
(先)ちゃっかりというかしっかり勉強会自体も聴講していたからじゃん。普段どれだけ頭の同じところを使っているかわかるな。
(私)ひどーい、そんなことないですよ。こっちを使ったりあっちを使ったりしてるもん。
(先)そんな都合よくあっちもこっちも使わないって。
(私)細かいと嫌われますよ、センパイ。早く片付けて帰りましょうよ。
(先)この後、スタッフはふりかえり会に行くんだよ。ほら、支度して行こう。みんな待っているからさ。
(私)まだ何かやるんですかー。
(先)ふりかえり会だけど美味しいおつまみとクラフトビールとレアな無加水原酒の日本酒が出てくるんだけどなぁ。美味しいんだよなぁ、あの店のおつまみはなぁ。クラフトビールを喋り続けて乾いた喉に流し込んだら「くぅぅー」ってなるだろうなぁ。オレは行くけどどうする。
(私)「くぅぅー」ってひどいじゃないですか。疲れきっちゃったけど、センパイがそこまで土下座して頼み込むんだからやむなしです。ほら、行きますよ。
(先)土下座してないし。
(私)何か言いました。
(先)い、いえ。何卒、ご同伴いただけますようお願い申し上げます。

 

(私)美味しいですね、このお店のおつまみ。あ、これも美味しい。俄然元気が出てきた。くぅぅー、クラフトビールの香りが美味しい。あー、シアワセ。
(先)ほら、付いてきてよかっただろう。
(私)私、付いてきてなんてないですよ。センパイがどうしても一緒に来て欲しいっていうから来てあげたんですよ。勘違いしてはいけません。さて、次はどれを食べようかなー。
(先)復活してよかった。いつもだけどさ。
(私)何か言いましたか。お話を聞いてあげますから、次の質問に答えなさい。どうして勉強会のスタッフやろうと思ったんですか。はい、どうぞ。ごくごく、くはー。
(先)どうして勉強会のスタッフになろうと思ったのかって。長いよ。いいの。いいんだ。そりゃ聞いている間はたくさん飲んでたくさん食べられるもんな。
(私)(うんうん)
(先)社内のイベントでさ、何度か講師をやったんだけどさ。今はさ、社内より課外活動をしている方が多いのは知っているだろうけど。最初の頃は思ったような反応がもらえなかったり、アンケートの結果が自分と距離があったんだよ。それをさ、受講者のせいにしたことがあったんだ。
(私)センパイでも上手くいかないことがあるんですねー。
(先)そんなのばっかりだよ。距離感を感じたことが2回連続であって、これ、もしかしたら自分の方が間違っているいるんじゃないのか、って思ったんだよ。自虐とか後ろ向きな意味じゃなくてどっちかといえばさ、自己満足な講座になっていたんじゃないかって。
(私)それすごいじゃないですか。自分で気づくなんて。普通は気づかないものですよ。
(先)そんなことはないよ。誰でも気づける。でさ、どうしたらいいのかって。
(私)うんうん、それで。
(先)よく考えたら、人に教えるための勉強をしたことないな、って気づいてさ。特にエンジニアはそうじゃないかと思ったんだよ。根拠はないけど。たださ、技術的にレベルがシニア層になったり、配属が特化した技術を担当していたから育成部署から講師をやってくれと言われてオレオレで講師をやっている方が多いだろうって。
 実際、オレもそうだったと気づいたんだ。教育課程を受けていれば教育実習もあるしそのための教育も受けているから基礎はあるはずじゃないか。でも、オレにはないんだって。
(私)このおつまみとこれと。あとこれ似合う日本酒くださいー。
(先)マイペースだなぁ。
(私)何か。
(先)いえいえ。それでさ、ネットで調べたの。そうしたら丁度、いい本があったんだよ。で、読み進めたら目から鱗で。あ、これまで間違っていた、聴講者にごめん、でも、やっと気づけたから次の機会は任せてくれ、と思ったんだよ。
 そうしたら次は実践したいじゃん。な。で、関心があったジャンルの勉強会に何度か参加していたら、親しい友達ができてスタッフが少なくて手伝ってくれないかって言われて、こっちも実践する側になれるなって、さ。
(私)へー。エライですねー。成長してますねー。知識だけ、だけど。
(先)だけはいらないだろう。ほんとのこというと気づくときもあるんだよ。まぁ、ちょっとずつな。
(私)続けて、つづけて。
(先)教材も作り変えたよ。勉強会のパートをやらせてもらったりしてさ。意識できるようになった。聴講者の立場をさ。
(私)すごいじゃないですか。久しぶりに関心しました。褒めてあげます。
 じゃあ、私の可愛い後輩としての立場もわかって対応してくださいね。
(先)(また奢れってことか…でもそんな顔はしてないけど…)

 

企業内人材育成入門

企業内人材育成入門

 
教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)