たまにはABAP ALV LIst その１
以前、ALVリストの資料のリンクを紹介したのだが、REUSE_ALV_GRID_DISPLAY関係のリンクが切れているという状態であることに気が付く今日このごろ。
しょうがないので、たまには自分でやってみるか、と、思いったった次第。
書くこと・・・方針めいたもの
ALVリストの作成方法としては、ALVのクラスを使用して作るやり方と、REUSE_ALV_GRID_DISPLAYを使うやり方の二つのやりかたがございまして。
ALVのクラスを使用するやり方は、SDNにおちている「An Easy Reference for ALV Grid Control」が、いまだに最強と思われるため、ちょいとパスして、ここでは、REUSE_ALV_GRID_DISPLAYの使い方を、ちょろっと書いてみようかと思います、はい。
で、REUSE_ALV_GRID_DISPLAYなんですが、まあ、たくさんパラメータがあるわけなんですよ。EXPORTINGが38、IMPORTINGが2、Tablesが1、EXCEPTIONSが2。なんせ大量にあるEXPORTINGに何を設定していいのかわからん、というお話なんですな。
じゃあ、わたしが全部知ってるかというと、当然、そんなわけないので、今までやってきて「これでいいんじゃね？」というレベルまででいいかな、と、勝手に決める次第。具体的には、ALVリストに自作のメニューを配置し、リストにラジオボタンを表示、メニューのボタンを押すと、何かしらPOPUPで表示、というところまでやってみようかな〜と、思います。あ、表示バリンアントの保存もいるかな〜
最初の一歩。めっちゃシンプルなALVリスト
で、REUSE_ALV_GRID_DISPLAYなんですが、絶対必要なものが、
・表示するデータ
・表示するデータの型
以上、二つなわけです。
逆に、この二つを渡してやれば、表示だけはできるわけなんですよ。他のパラメータいらん。
で、表示するデータについては、TABLESパラメータのT_OUTTABに渡してやればいいわけです。
そして、表示するデータの型なんですが、表示するデータの左から順番に、型の情報を内部テーブルに登録し、IT_FIELDCATに渡してやればいいんですな。
しかし、このIT_FIELDCATに渡すデータというのが曲者で、このパラメータの一行に、すっげ〜いろんなデータを設定してやる必要があるんです。
そいつは面倒だ、というので、便利なのがI_STRUCTURE_NAMEというパラメータ。こいつに、ABAPディクショナリの構造やテーブル名を指定してやると、IT_FIELDCATの中身を自動生成してくれます。つまり、表示したい項目を構造としてABAPディクショナリに定義しておいて、T_OUTTABに渡す内部テーブルとして使い、I_STRUCTURE_NAMEにその構造名を指定すると、あっという間にリストを生成してくれるわけです。
表示バリアントの保存
ALVリストのいいところは、表示バリアントを使うことで、項目を絞ってみたり、ソートしてみたり、集計をしてみたり、ということができるところ。
なんですが、REUSE_ALV_GRID_DISPLAYでリストを作ると、最初、バリアントの保存ができませぬ。バリアントを保存するためのキー情報を定義し、保存を許可するよう、パラメータ設定してあげる必要があるのですな。
そのパラメータがIS_VARIANTとI_SAVEでございます。
IS_VARIANTには、プログラム名とハンドルをセット。ハンドルって何かというと、プログラム内で複数のALVリストを表示させたりする場合に、別々の表示バリアントが必要なわけですが、それを区別するキーです。4文字で適当なのでOK。
I_SAVEはその名の通り、表示バリアントをSAVEできるかどうか、のパラメータ。今回はSAVEさせたいので、'X'をたてます。
第一回目のソースコード
ということで、サンプルソースコードっす。
構造を定義するのも面倒なので、みんな大好き、SFLIGITのテーブルとその内容を使います。
Form data_getで、SFLIGHTのデータを全件抜いてきて、Form display_alvで表示させます。
REUSE_ALV_GRID_DISPLAYのパラメータは、data_getでとってきたデータと、I_STRUCTURE_NAME。
data_getでとってきたデータの型は、SFLIGHTなので、I_STRUCTURE_NAMEに指定するのもSFLIGHTです。
第一画面に何もないのは寂しかったので、ALVリストの真上に表示されるタイトルを指定し、I_GRID_TITLEに入れています。
表示バリアントのハンドルは、適当に「0001」なんてのを設定してみました。
type-pools:slis は、ALVリストを作るときのお決まり。
REUSE_ALV_GRID_DISPLAYを使うときのType定義の塊でございます。
*&---------------------------------------------------------------------*
*& Report YTEST_ALV_LIST
*&
*&---------------------------------------------------------------------*
*&
*&
*&---------------------------------------------------------------------*
REPORT YTEST_ALV_LIST.
type-pools:slis .
data : itab_out type TABLE OF sflight .
data : str_variant like DISVARIANT.
PARAMETERS p_title type sy-title .
START-OF-SELECTION .
PERFORM data_get .
PERFORM set_variant.
PERFORM display_alv .
*&---------------------------------------------------------------------*
*& Form DATA_GET
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------*
FORM DATA_GET .
select * from sflight into table itab_out.
ENDFORM. " DATA_GET
*&---------------------------------------------------------------------*
*& Form SET_VARIANT
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------*
FORM SET_VARIANT .
str_variant-report = sy-repid.
str_variant-handle = '0001'.
ENDFORM. " SET_VARIANT
*&---------------------------------------------------------------------*
*& Form DISPLAY_ALV
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------*
FORM DISPLAY_ALV .
CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
EXPORTING
* I_INTERFACE_CHECK = ' '
* I_BYPASSING_BUFFER = ' '
* I_BUFFER_ACTIVE = ' '
* I_CALLBACK_PROGRAM = ' '
* I_CALLBACK_PF_STATUS_SET = ' '
* I_CALLBACK_USER_COMMAND = ' '
* I_CALLBACK_TOP_OF_PAGE = ' '
* I_CALLBACK_HTML_TOP_OF_PAGE = ' '
* I_CALLBACK_HTML_END_OF_LIST = ' '
I_STRUCTURE_NAME = 'sflight'
* I_BACKGROUND_ID = ' '
I_GRID_TITLE = p_title
* I_GRID_SETTINGS =
* IS_LAYOUT =
* IT_FIELDCAT =
* IT_EXCLUDING =
* IT_SPECIAL_GROUPS =
* IT_SORT =
* IT_FILTER =
* IS_SEL_HIDE =
* I_DEFAULT = 'X'
I_SAVE = 'X'
IS_VARIANT = str_variant
* IT_EVENTS =
* IT_EVENT_EXIT =
* IS_PRINT =
* IS_REPREP_ID =
* I_SCREEN_START_COLUMN = 0
* I_SCREEN_START_LINE = 0
* I_SCREEN_END_COLUMN = 0
* I_SCREEN_END_LINE = 0
* I_HTML_HEIGHT_TOP = 0
* I_HTML_HEIGHT_END = 0
* IT_ALV_GRAPHICS =
* IT_HYPERLINK =
* IT_ADD_FIELDCAT =
* IT_EXCEPT_QINFO =
* IR_SALV_FULLSCREEN_ADAPTER =
* IMPORTING
* E_EXIT_CAUSED_BY_CALLER =
* ES_EXIT_CAUSED_BY_USER =
TABLES
T_OUTTAB = itab_out
* EXCEPTIONS
* PROGRAM_ERROR = 1
* OTHERS = 2
.
IF SY-SUBRC <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDFORM. " DISPLAY_ALV
40の手習い WordPress
いや、ヒマなんですよ、実は。
あまり大っぴらに言えたことじゃないんですが、今やっている仕事、かなり落ち着いているし、今までは自分でやらなきゃいけなかったことを、他の人たちがちゃんとやってくれる。おお〜、それもやれるようになったか、やってくれるようになったか、うんうん、と、おじいちゃんのようなことを思っていたら、いつの間にか、自分の仕事がなくなったというお話。
こうなると、客観的にみて潮時なんでございますが、なぜか契約は残っていて、なにしようかな〜と思う始末。
何年ぶりかで、定時に帰る日々のため、ちょっとやってみようかな〜と思ったのが、WordPressでございます。
昔の挫折を乗り越えて
このブログなんかを書けるCMSってやつは、その昔、2005年のころでございましたか、MovableTypeをちょっとやってみたことがあったんですね。
しかしながら、すぐ挫折。
ブログのサイトを作りたかったわけではなく、どっちかというと、企業のHPを作りたかったんですが、ブログのサイトを作ることに特化したような紹介本ばかりで、どうやったらHP作れるのかわからない。それに、Perlわからないんですよ、私。ということで、早々で挫折したわけで。
ところが、WordPressは、PHPじゃございませんか。それならまだ少し、ほんの少し勝負になる気がする。
ということで、やってみるべ！！
世間の進歩は速い
いや、今回やってみて一番驚いたのが、Windows環境へのテスト環境構築のしやすさ。なんだこれ？って感じですよ、ほんと。
2004年くらいに、WindowsでもApacheが動くと知ったときも驚いたんですが、今回初めてXamppの存在を知ったわけですよ。なんですか、これは。
2005年にRubyとRailsをやったときに、こんなのなかったよね。ApacheとPHPとMySQLとphpMyAdminが全部ついてる？？意味がわかんない。ほんとに簡単に開発環境ができちゃった。
んでもって、WordPressのインストールも、本当に簡単。ファイルを展開して、インストール用のアドレスから実行するだけ・・・なんじゃそりゃ。その昔、MobableTypeの環境構築＋インストールに丸1日かけたのがウソみたい。本当に30分。ダウンロード時間こみでも、1時間くらい。
これじゃ、40の手習いにならんのではないか？？と、思うほどの簡単さでございますよ。
ページ作るのも簡単だよ・・・
で、WordPressの公式サイトをみつつ、ページを作ってみる。
デフォルトでは、Homeにブログ形式の記事が出て、そのほかのページは「固定ページ」になっているらしい。
じゃあってんで、ブログ形式のページは無視し、固定ページをいくつか作ってみる。
これがまた、簡単にできる。画像はりつけて、位置を設定し、あとはテキストを埋め込んでいく。フォントと色も指定できる。HTMLで書けるモードもあるから、気に入らなければ、HTMLのタグを自分でほうりこめる。フリーのホームページ作成ソフト並の出来なんじゃね？これ。
で、固定ページを作ったら、メニューに登録し、そのメニューを表示させるように設定すれば、再起動なしですぐに確認できる。
う〜ん、いい時代に生まれた。本当に。
ブログページをトップではなく後ろにもってくる
ちょっと迷ったのが、トップページをブログのページにせず、固定ページにして、ブログページをメニュー選択で表示させるようにしようとしたとき。
メニューの登録順序はHomeは対象外になっているみたいだし、どうすんだこれ？と、思ったら、「設定」メニューの「表示設定」で設定するんだね、これ。
フロントページの設定で、固定ページを選択。そうすると、ブログのページがなくなっちゃうんだけれど、固定ページにダミーのページを用意しておいて、メニューに組み込み、表示設定の「投稿ページ」の項目に、そのダミーのページを指定したら、トップページは固定ページで、ブログページはメニュー選択で出るようにあっさりなった。
・・・いや、本当に簡単だよ、これ。
組みなおそう、マジで
一応、自分の会社のHPは持っていて、それを全部手組みのHTMLで書いてたんだけれど、こっちで作ったほうがよほどいいじゃんか！！シャレたテーマを持ってくれば、素人くさい今のHPも随分とそれっぽくなるよ、実際。
ということで、今週末は、レンタルサーバーへの設定にチャレンジするのであった。
「コミュニケーションミス」のお話 伝達率とシンクロ率
ちょっと大上段に構えてみましたが・・・まあ、要するにまたしてもグチなわけですな。
「コミュニケーションミス」をなくせって言っただろ！みたいな叱責を受けたことに対する、ちょっとした考察？自己弁護？そんな感じですよ、ええ。
二つの指標を導入です！
で、お題は「コミュニケーションミス」でございまして、それに対する傾向と対策、なんてのが、今回の流れ。傾向と対策だから、まず、コンサルらしく、いくつかのパターン分けを試みるわけでございます。
パターンわけをするには、指標を導入するのが効果的。っていうか、適当に指標を導入しても、それっぽく聞こえる、魔法の手段。今回は、「伝達率」ってのと、「シンクロ率」っていう二つの指標を導入してみっかな、なんて思います、はい。
伝達率というは、「伝えたい事象が過不足なく伝わったか」という指標。「シンクロ率」は、「伝わった事象を背景を含めて、情報の発信者および受信者が同じ理解を得たか」という指標。こう定義してみる。
で、コミュニケーションミスというは、この指標値のどちらか、もしくは両方が低い状態を言うのだ！！と、またしても大上段にふりかぶってみる。
伝達率が低ければ、シンクロ率は低くなる。そりゃそうだ。しかし、伝達率100%であっても、シンクロ率が低いっていう状態も、多分ある。そういう意味で、伝達率アップは、シンクロ率アップの必要条件ってやつだ。ということで、まずは、伝達率が低い状態の傾向と対策を見ていって、そのあと、シンクロ率が低い状態の傾向と対策を見ていくのがよかろう、そう思うわけですわ。
最初のパターン・・・対象としての認識ミス
最初は、伝達率0%の状態。
この状態は、そもそも情報を渡す相手、コミュニケーションをする相手を落っことしてしまった、という状態が相当しますなあ。
まあ、伝えてないんだから、コミュニケーションもへったくれもないわけで。本当に必要とされている人に情報が行かなかった、もしくは、必要とされる人ではない人に情報が行ってしまった、というパターンなわけで。
原因としては、最初に、コミュニケーションを行う人のリストアップが漏れていたり、リストアップした人に対して、どういう情報を渡すべきか、という、まあ、PIMBOKでいうところの、コミュニケーションプランの立案に失敗しとる、そんなことが考えられるわけですよ。
そうなると、このパターンのミスっていうのは、大体プロジェクトの初期段階に起こりやすい、ということになりますわ。はじめたころには、プロジェクト内の組織図ってのもふわふわだし、プロジェクトを進めていくうちに、「ヤツに話を通しておけば、間違いない」だとか、「アイツは話を通しておかないと、めんどくせ〜ことになるな、おい」みたいなことが、わかってくる。わかってくれば、「話を通し忘れた」みたいなことは、どんどん減ってくる。まあそうでしょう。
ということで、最初のコミュニケーションプランの立案と、プロジェクトを進めていくなかでの経験の積み重ねで、このパターンのミスは減らせるわけですな。
ふたつめのパターン・・・情報の質とその劣化
今度は、伝達率が低い状態。
伝達率が低い状態の原因としては、
・そもそも、伝えるべき内容が網羅されていない
・一旦伝わった内容が、忘れられていく
という、二つのパターンがありますな、きっと。情報の質にかかわるお話と、その情報の劣化という問題。
情報の質を高めるためには、正確に、もれなくダブりなく・・・いわゆる論理的思考で物事を伝えましょう、というのが、一般的なお話。集合場所を書き忘れた飲み会の案内とかが、典型的な例になるんではないかと。
情報の劣化ってのは、結局人は忘れるものだ、というところ。口頭でやり取りをしているときには、「こんな大事なこと、忘れるわけね〜よ」と思っているわけだが、あっさり忘れていく。自戒を含めて。なので、メモを取るとか、口頭ではなく、メールもしくは文章でやり取りをする、なんていうお話になっていく。
まあまあ、これも基本的なお話で、確かに、コミュニケーションミスっていうのは、ほぼこのパターンだったりする。そして、気をつけていれば、ある程度防げる。いや、実際、このパターンで起こるコミュニケーションミスで、ネチネチ言われるのは、まあ、仕方ないかな〜と、自分でも思うわけですよ。
しかし、しかし。次のパターンは、回避が非常に難しい。
みっつめのパターン・・・伝達度は高いがシンクロ率が低い
同じものを二人の人が見ているのだが、考えていることが違うっつうパターン。伝達度は間違いなく高いんだけれども、シンクロ率が低い状態。これが厳しい。つっか、こういうパターンとふたつめのパターンとの区別が出来ていない人が多い印象があるんだよね〜
ま、ちょっと例を。
たとえば。ある人の趣味というか趣向が、「プロレスがすきで、女子高生がすき」であったとする。で、この人が喜ぶ話相手を探してきて、というお話になったとする。
これ、「プロレスの話ができる女子高生」を連れてくれば、おｋだね〜という話になるだろう、きっと。まあ、そんな子がどの程度いるかはわからないけど、これ一択なわけですよ、普通に考えれば。
しかしですね。「セーラー服を着たプロレスラー」をつれてきたら、いかがなもんでしょ？上記の条件にバッチリあってませんか？
確かに、この例は極端なんでございますが、じゃあ、「セーラー服を着たプロレスラー」の選択肢をはずすために、上記の条件に付け加えるとすると、つれてくるのは女子高生とします〜とか書くことになるわけですよ。普通書かないでしょ、こんなことは。これは、情報を出している私と、コレを読んでいるあなたに、「この人」というのはおそらく男性で、男性なら女子高生とお話したいに違いない、という前提があるので、書かなくてもいいわけなんですよ。
つまり、何が言いたいかというと、シンクロ率を高めるためには、両者が意識的もしくは無意識に持っている前提が揃っていることが必要、なわけです。揃っていれば、セーラー服を着たプロレスラーは出てこない。けど、もし、揃っていなければ？シンクロ率は低くなり、セーラー服を着たプロレスラーが出てくる可能性が高くなる。
そして、これは「伝えるべき内容が網羅されていない」という、ふたつめのパターンとは、明確に違うわけですよ。なぜかというと、すべての前提を情報として放り込むことは不可能だから。それは、上記のセーラー服を着たプロレスラーを回避するために、何を書けばよかったのだろう、というのを、事前に把握するのがほぼ不可能なことからもわかるわけで。
実際、ユーザさんと仕様調整をしていて、同じ話をしていると信じていたのに、前提がぜんぜんちがって、うおぉぉ！手戻りじゃ！！！と、なったことは結構多い。失敗は記憶に残るから、多く感じているだけかもしれないけれど。しかし、これ、ユーザさんから見れば、まさに、「セーラー服を着たプロレスラー」が出てきた状態そっくりなわけで。
で、それはなんで起こるかというと、こちらは、ユーザさんの会社にずっと勤めているわけではないので、その会社の文化とか、暗黙知とか、やっぱりわからないわけ。そうすると、知らず知らず、セーラー服を着たプロレスラーを出現させてしまうわけですな。
これに対する対応って、本当に難しい。前提の違いって、違いが明らかになるまで、両者に潜在的に存在し、決して表に出ることはないわけで。唯一できることは、一度その前提の違いが出たら、それに関連する前提の違いが他にはないかチェックすること。まあ、それも程度があって、完璧にはいかないけれども。
最後はグチで締めるのだ！
ということで、この手のコミュニケーションミスは、発生不可避と考えるほうが妥当だと私は思うわけで。だって、有効な手が打てないんだもの。
ところが、先にも書いたが、伝達率が低いのか、シンクロ率が低いのか、その区別がつかない人が多い印象がある。有効な手のあるなしという点で、海の深さほどの違いがあるのに。
その原因はなにか、というと、やっぱり、前提がそろっている状態で、仕事をする人のほうが世の中圧倒的に多くって、伝達率さえ高ければ、シンクロ率は自然に高くなるなためではないか、なんて分析してみる。
普通の会社勤めをしているときに、前提がそろっていない、つまりは文化が違う人と仕事をする機会って、そうそうあるもんじゃない。客先にバンバン出て行って仕事する、ITドカタやコンサル会社のほうが、全然特殊なわけで。
しかも、コンサル会社でも大手SIerでも、出世していくと、客先に出ることが少なくなるもんだから、周りが同じ前提で動く人ばかりになってくる。すると、この発生不可避のコミュニケーションミスが理解できなくなっていく。端的に言えば、現場感がなくなっていく。すると、伝達率とシンクロ率の違いなんて忘れていき、結果として・・・
「なんでコミュニケーションミスが起きるんだ！なくせと言ってるだろ！！」
とまあ、こんなお叱りを受けるハメになるわけで。やれやれ、ですわ。
新しい肩書き
昨日、PMP試験を受けにいきまして、なんとか合格して参った次第。
40の手習い
なんで受けてみようかと思ったか、と、いいますと、直接の原因は、ITコーディネータの資格更新を、今年からやめちゃったことだったりするわけで。ちょっと肩書きがさみし〜な〜、というわけで、PMPにしてみました。
ITコーディネータという資格については、う〜ん、なんとも言えない後味が残りまして。まあ、ケース研修で一緒になった皆さんから、ちょいちょい情報をもらったり、人脈を広げるという点ではプラスだったんだけども、それなら継続しなくても人脈は残るわけで。
逆に、あまりに営業効果が見えない、つう話はありまして。そのわりには、資格更新の必要なポイントをためるためのセミナーとか、資格更新料とか、出費が正直バカにならんのですわ。
まあ、そのセミナーが役に立つものだったら、それはそれでいいか、と、思うわけなんだけれども、実際「あれれ〜？」ってのも多い。自分の知識が増えたせいもあるのかなあ、とは思うんだが、基本的にリタイアしたおっさんが、えらそうにしゃべる（さらに、かなりの確率でポイントをはずしている）、というのがセミナーの実態であり、私が欲している最新の技術動向だとか、そういうセミナーではないわけですな。んじゃいっか、と。
苦難の申し込み
で、PMP試験を受けることにしたんですが、この試験も、試験料高いんだよね〜。そんでさあ、申し込みが面倒で面倒で。
何が厳しいかって、申し込みが英語なのが厳しい。え〜ん、書いてあることがわかんないんだけど〜PMI日本支部に、日本語の手引きがあるんだけど、ちょっと変わっちゃってるし。Google翻訳さんにだいぶお世話になりながらですわ。
で、プロジェクト経験と、プロジェクトマネジメント研修の実績を登録するわけなんですが、このプロジェクト経験の登録ってのが、本当にやっかい。
まず、どんなプロジェクトなのか、というのを、英作文する必要があるんですよ。英作文なんて、20年前に大学受験したとき以来で、まずダメージを受ける。そんで、そのあと、プロマネとしての経験した時間を入力する。それがまあ、細かいこと。
PIMBOKに出てくる、42個のプロセスに、プロジェクトでの経験時間を割り振るわけなんでございますよ。ちょっとめんどくさくって、プロジェクトの終了のフェージングに時間を入れなかったら、「そこ入ってないよ〜」と、チェックでエラーになって、申し込み完了できないでやんの。ひょえ〜
35時間のプロジェクト研修ってやつは、その昔、ITCのポイントがほしくって受講したe-larningの修了で代替OK。らっきー。けど、最終学歴を入れるところで、大学の住所まで英語で入れる必要あり。住所なんて覚えてないよ〜ってので、また調べて入力。本気で1日仕事ですわ、これ！！
やっとのことで入力すると、「審査が終わるまで待ってね〜」とのメールが着信。
5日くらいすると、審査OKとなり、決済の案内がメールできた。クレジットカードで決済。受験料はお高い。555ドル。円高だけど、5万円するのね、これ。キャバクラ3回分だな〜勉強なんかせずに、キャバクラに行ったほうがいいんじゃないかな〜という、悪魔のささやきを無理やり押し殺し、申し込み完了。
と、思ったら、メールがまたやってきて・・・
「Your application has been randomly selected for PMI's audit process.」
ぎょぎょ！？監査対象？？
もうやだ・・・とはいえ、受験料は払ってしまったので、卒業証明書その他、一式取り揃えてエアメールでございます。
これでダメだったら、本当に踏んだりけったりでしたよ、ええ。
そうだったのか・・・
http://www.puni.net/~anyo/etc/heartcatch.html
「敵幹部の否定的評価」って、これ、明らかに物分りの悪い父親の論理っすよね。
そういや、家に帰るたんびに、ムスメに「ここらでがまんの限界よ！」と、言われて攻撃されます。
ウチ、三姉妹だし。
これから、こっそり砂漠の使途、支援。がんばれ、クモジャキー！
いまさらの「もしドラ」・・・これはバッドエンドなのか？
すんげ〜今さらなんですが、実際。ちょっと書いてみようかと思うわけですな。
みんなが知ってる「もしドラ」ですよ。
もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら
- 作者: 岩崎夏海
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2009/12/04
- メディア: 単行本
- 購入: 265人 クリック: 12,967回
- この商品を含むブログ (1008件) を見る
まあ、売れること自体は納得なんですが・・・
気に入らない
んですよね〜実際
以下、ネタばれ注意
ドラッガーを使って、高校野球の女子マネージャがチームを立て直す、というのが基本的なお話で、昔なつかしタッチ的なスパイスっていうのか、そんなのが入っているこの本。
当然、ドラッガー単品でも、よくあるストーリー単品でもモノにはなっていなかったんだろうけれども、それを組み合わせるとミリオンセラー。そういう組み合わせの妙ってのは単純にすげーな〜、と、思うわけですよ。
ドラッガーの入門書としてみれば、非常に敷居が低くていい感じだと思ってます。ええ。
なので、読んでみてどうだった？と、人から聞かれれば、読みやすくていい本だよ〜、そう答えるわけですな。いや、実際いい本だと思うんですよ。
ですけどね〜。気に入らないのは、この一点。最後のシーン。
「甲子園では、どんな野球をしたいですか？」
「それを、みなさんに聞きたいのです」
はああああああああ？？？？？？
何いっちゃってるんでしたっけぇぇぇ？？？？？？？
「顧客の声を聞く」ってさあ・・・
いや、文脈としてはですよ。
ドラッガーは、組織には目的、目標があって、それの設定に関して、一番重要なのは、顧客の声だ、という話は実際にあるわけですよ。
しかしですよ。
これは、目標の設定のためのインプットであって、目標自体を顧客に決めてもらう、なんて話では決してない！と、思うわけなんです。
いや、その「顧客」ってのが、狭いセグメントの中で、非常に明確である、って話ならわかりますよ。その顧客の満足度が、組織の存続条件そのものになってくるわけですから。受託開発しているのに、要件を出すユーザの話を聞かない、なんてことがある？というお話なわけです。
ところが、組織が大きくなり、多くの人々が「顧客」として出てくると、話が違うわけですな。個々、別々に、好きなことを言い始めるわけです。
で、その最大公約数に対して何かをしようと思うと、まあ、要するに、「普通」の話しか出てこなくなるわけです。その「普通」の話を単にやる、というのが、組織の目的、目標なんですか？というのが、私が違和感を持つところなわけです。
だってさあ、「普通」の話を単にやるっていて、イノベーションなんて生まれるわけないじゃないですか。
顧客は、今あるものしか、イメージできないわけですよ。じゃあ、その最大公約数の「普通」の話を真摯に聞いたところで、その延長線上にあるのは、今あるものの精度を高めることしかないわけで。
実際、日本企業は得意ですな、そういうの。そういう意味では、この本の「顧客の声を聞く」ということを、緻密に実践している。
しかし、結果、iPhoneだのiPadだが出てくると、全部持ってかれる。
新しいものが出てきて、顧客がそちらを選ぶと、顧客の最大公約数の言うこと自体が変わるわけです。もちろん、Appleは顧客を無視していたわけではないと思うし、顧客の声をインプットにしていたと思うんですが、それとは別の何かを提示しているわけです。
「もしドラ」の容易に想像できるその後
で、「もしドラ」に戻ると。
甲子園に出場を決め、注目度があがった段階で、顧客としては大きく広がり、全国区。この段階では、顧客の最大公約数を聞いてしまえば、ごく普通の話しか出てこない。しかし、「普通の話」の精度を高めるには、チームとしての基盤は明らかに他のチームより劣る。そういう状況で、みんなの声を聞いちゃうと、元のなんの特徴もないチームに逆戻りしちゃう危険のほうがはるかに高いわけですな。
それって、面白いことをやってたベンチャーっぽいところが、えいっと大きくなったときに、広がった顧客層の言うことを聞いてるうちに、結果として没個性になってしまい、資金力に勝る旧来の企業にぶっつぶされる、という、とってもよく見る風景をトレースしているにすぎないわけで。
そう思うと。最後に「それをみなさんに聞きたい」として、この話を締めてしまうのには、猛烈な違和感があるわけなんですよ、私は。
まあ、そういう現実を踏まえたうえで、実はハッピーエンドではないバッドエンドのお話でした〜というところまで、著者が意図して書いてるんなら、ただただ、脱帽でございますが・・・
