悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
IT業界、ソフトウェア開発業界において、古典的な名著がある。
IBMが世界で覇権を握ったメインフレームシステムとそのオペレーティングシステム、OS/360を開発した、フレデリック・ブルックスという人が書いた、『人月の神話』である。
日本では、初版が1977年に出版されている。
以降、40年間にも亘って、「ソフトウェア工学のバイブル」と呼ばれている。
この呼ばれ方には、「誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである」という皮肉も含まれているようである。
『ブルックスの法則』として、最も有名な言葉は、おそらく下記の言葉であろう。
遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
私は昨年、現職に復帰する前には、三年間もの間、心身の不調により休職してしまっていた。
その休職する直前に関わっていた顧客側の責任者（権限者）が、とにかく暴君であった。
システム開発者側として、きわめて現実的で、かつ、それでも最短期間で完了させるスケジュールを提出した時、たびたび「なんでこんなに期間がかかるんだ！」と騒がれた。
その部下である顧客側の担当者は上司の言いなりなので、話にならない。
仕方なく、無理のあるスケジュールで進める事になる。
しかし、それでも結局は、顧客側の仕様調整が甘かったりして、手戻りが発生し、当初に私が提示したスケジュールと同じか、それよりも遅く進行する事が常であった。
パッケージを導入し、業務もそれに合わせるような割り切りをするならまだしも、基幹系業務システムの開発などにおいて、「短納期化」なんていうものは、ただ単にやるべき作業を省くだけであり、後工程にツケが回って、結局は余計に期間がかかるだけで終わってしまうのである。
悪いスケジュールの引き方、良いスケジュールの引き方 その例
ここでは敢えて、「悪いスケジュールの引き方」と、「普通のスケジュールの引き方」と言い換えよう。
下の2つのスケジュールを観て欲しい。
ある程度のシステム開発プロジェクトを経験すると、皆、わかることだと思うが、実際には、モノを作ったり書いたりしている時間に比較して、検討したり情報共有したりレビューしたり、といった対人コミュニケーションの方にも、同程度、もしくはそれ以上の時間が必要とされるのである。
もちろん、顧客とのレビューなどの調整にも、時間がかかる。
これが、案外、見過ごされがちなのである。
プロジェクトが炎上したときに欲しいものとは
様々な理由により、プロジェクトが炎上か、それに近い状態に陥ってしまった時。
もしも神様から、「『お金、人、時間』のどれか一つだけ与えてやる」と言われたら、何を選択するだろうか。
たいていの場合は、『時間』と答えるのではないだろうか。
現場の人間にとっては『お金』などどうでも良いのだし、『人』をその段階で投入されても、かえって迷惑なのは、前述した『ブルックスの法則』のとおりである。
疲弊しきった現場に必要とされるのは、一息休むための『時間』、休んだ後に課題を一つずつ整理するための『時間』、建て直すための『時間』なのである。
一度、炎上してしまい、ガタガタになってしまったプロジェクトは、立て直しするのにも、相当の時間がかかる。
数カ月、もしくは一年単位の時間が必要な場合もある。
そのくらいの十分な『時間』が確保されて、はじめて『新たな人員を補強しよう』という話ができるようになる。
エライ人には、これがわからんのである。
「失われた20年」で本当に失われたものとは……これは現在でも失われ続けており「失われた30年」というものも現実味を帯びている
「失われた20年」で本当に失われたものとは……これは現在でも失われ続けており「失われた30年」というものも現実味を帯びている
今日は東京都議会選挙の投票日であるが、やはり投票率は低迷するのであろうか。
日本は2008年をピークに人口が減少に転じ、ついに人口減少社会に入っている訳であるが、東京の人口だけはまだ増加している。（それでも2020年あたりまでがピークで、その後は急速に少子高齢化が進むとも言われているが）
いまや1300万人という、日本の全人口の1割もの人が東京に居るという事になる。東京の政策の失敗は国政にも大いに影響するだろう。
日本は、1990年頃のバブル崩壊まで、だましだまし経済成長を続けてきた社会であった。
しかし、国策としてバブル景気を発生させ、そして、国策としてそれを崩壊させた事で、ついに日本の経済成長、および経済大国としての実体はなくなった。
その後に訪れた低迷期が「失われた20年」と呼ばれている。
「一億総中流」と言われた社会構造は崩壊し、格差社会が浸透していった。
IT業界においても、1990年代は、景気こそ良いように見えたが、実のところ、情報システムの「オープン化」の名の下に、「ITに関心も興味もないユーザー企業」が、「短期的な利潤のみを追い求めるITベンダー」との利害の一致を見せ、以下の事がどんどん進行していった。
ユーザー企業が自社の情報システムの再構築や開発を上流工程から外部に丸投げ
ITベンダーは多重請負構造を構築して大規模案件を受けまくり、オープン化の名の下にシステムを食い荒らす
そんな状況が、いわゆるITバブル崩壊と言われた2000年代初頭まで続けられた訳である。
残るもの 残らないもの 貴重なもの そうでないもの
上図のように、大きなものを作ったりする場合、システム開発を例にすると、
(1) 基本思想、システム化の目的、考え方、アーキテクチャー
(2) システム化詳細設計、デザイン、実装、プログラム
(3) システムの利用ガイド、手順書、運用資料
…といった、3つのカテゴリーに分解できる。
内容の質という観点から、(1)の方が付加価値は高いし、できる人が少なく貴重である。
ITに無関心なユーザー側経営者ととにかく短期的な売上を得たいITベンダーとの利害の一致が生み出した大安売り
かつては、いまではすっかり聞かなくなったが、上記で言う（1）にあたるような、いまで言う「上流工程」を専門的に行う者として、SA（システム・アナリスト）という存在が居た。
起こったことは、IT技術者が「SA単価」では契約できなくなった。（無論、この単価契約という制度自体にも問題はあるが）
システム化の基本仕様や要求仕様の作成はユーザー側企業の情報システム部でやるから、ITベンダーには決められたそれらに基づいて粛々とシステムを開発すれば良い （実際には、自社業務もろくに知らない、システム開発の経験もない素人が作った「使えない基本設計書」があるのみ）
ITベンダー側も外注化が進んで空洞化しており、とにかく案件を安く受けまくる
ユーザー側企業とは最も距離が遠い下請け企業の技術者が、上記の（2）を実施するためには結局（1）の部分が必要となり、（1）も含めて不完全なものを開発する （もちろん安い単価で）
（1）が不完全な状態で出来上がったシステムが使いやすい訳もなく、炎上案件となる
…という事が、くりかえされた。
近年になって、「丸投げはいけない」とか、「自社の重要なノウハウの流出はマズイ」とか言われるようになったが、あまりにも遅すぎる。
20年間以上も、上記のような状況を作り上げてきたのに、それが簡単に戻せる訳もない。
いまになって、自社の基幹業務の知識を自社内の誰も持っておらず、そのためにシステムの維持すらできなくなって、開発当時の技術者を探し求めても、その人は既に業界を去ってしまっていた、などという事が本当に起こっている。
自業自得である。
真の意味での『同一労働同一賃金』とは何かを考えてそれを実現しなければ日本は滅亡するだろう
前にも言ったのだが、日本型の『終身雇用』自体がダメなのではない。賃金の単純な『年功序列』がダメなのだ。『終身雇用』という名の"無期限の雇用形態"はむしろ生活不安を減少させ生産性を向上させる。つまり必要なのだ。何故こんな簡単な事がわからないのかな？ 有期契約の不安定な雇用が問題。
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2017年7月1日
真の意味での『同一労働同一賃金』とは何か。
それは、仕事の価値を正しく評価して、それに見合う処遇を行うということである。
ただ単に時給を上昇させれば良いという問題ではない。
よく「正社員は簡単には辞めさせられないので、コスト増となり、非正規雇用しか増やせない」という理論を聞くが、それはどうなのだろう。
社員のパフォーマンスが出ないのは、本人だけではなく、仕事を任せる管理職の責任でもある。要するに、その人の「使い方」がうまくないだけではないだろうか。
場合によっては、処遇を落としても良いと思う。
以前にも何度か書いたが、「その仕事をお金を払ってでもやってみたいと思っている人は世の中にはたくさん居る」のである。
正当な理由で処遇を落とされたり、仕事を外されたりしたのであれば、受け入れてみるしかない。
そして、自社とか委託とかに関わらず、真の意味で付加価値の高い仕事をしている人を、正当に評価し、処遇し、リスペクトする文化を醸成しなければならない。
近年、日本を代表するような巨大メーカーが経営不振になり身売りされたり、中国にどんどん技術が流出して、かつてとは立場が逆になりつつあるとか、そんな話がニュースになっているが…。
それは結局のところ、貴重な知識やスキルを保有していて本来は大切に処遇しなければならなかった「人財」を、まったく大切には扱わず低い労働条件で使い倒してきた事の、ツケが回ってきたというだけなのである。
このままでは人口減少、少子高齢化、労働人口現象などと相まって、本当に日本は滅亡してしまう事だろう。
昔はなかった言葉「文系エンジニア」「文系プログラマ」…この言い方やめないか？
昔はなかった言葉「文系エンジニア」「文系プログラマ」…この言い方やめないか？
新入社員たちが最初の新人研修を終えて、現場に配属される季節になった。会社や組織にもよるが、この7月から配属というところも多いのではないだろうか。
ウチの職場は、様々な理由により、そんなには人気も無いし、採用人数も少ない。
近年では、4月の入社式の日に、新入社員たちのコメントが全社向けのイントラネットに掲載される。誠に恥ずかしい風習である。
私が新人だった20数年前には、当然ながらイントラネットもなかったので、そのような恥ずかしいモノはなかった。
さて、その新入社員たちのコメントの内容であるが、まぁ、空気を読んだ内容、読まない内容、様々である。
その中で、気になるワードがある。「『文系』ですが頑張ります」などというものである。
近年、「文系エンジニア」や「文系プログラマ」という言葉をネット上で目にする機会が多い感じがする。
文脈的には、どちらかと言うと否定的なニュアンスで使われている。
曰く、『文系（大学）卒業で、エンジニア、プログラマになれるのは日本くらいだ』
曰く、『海外ではコンピュータ・サイエンスを学んだ上でないとプログラマにはなれない』
曰く、『日本では本当に優秀な理系（大学）卒業者は、プログラマなどにはならない』
曰く、『日本では安い単価で素人をプログラマに仕立て上げて現場に送り出す悪徳商売が横行している』
全否定はしない。
しかし、たちの悪いマスメディアのように、ごく一部分をフォーカスしているだけで、それをあたかも社会全体にも言えるかのように誇張するのも、違う気がする。
そもそも「文系人間」「理系人間」などという種類分けに意味があるのか？
普通科高校における、科目選択としての「文系コース」「理系コース」が、その人間の性質まで決めるのだろうか。
では、商業高校に進んだ人はどちらなのだろうか。文系だろうか。
では、工業高校に進んだ人はどちらなのだろうか。理系だろうか。
実のところ、近年の風潮からして、『学歴』とは、あくまでも『大学の入学歴』の事を指す。
そうなると、商業高校、工業高校、高等専門学校などに進んだ人は、『学歴そのものが無い』という事になる。
十代半ばにおける進路選択で、その人の人生は確定か。
「文系」「理系」および「学歴なし」が確定か。
バカバカしい。本当にバカバカしい話である。
社会人になってみてはじめて勉強の意義がわかってそれから努力する人もいる
どのような職業であったとしても、実際にやってみないことには、自分に向いているかどうかはわからない。
日本型の新卒一括採用は、確かに批判もあるし、その時点にしかチャンスがないという歪んだ採用実態は、改善する必要があるとは思う。
しかし、まったく社会経験がなく『真っ白』な状態のまま採用する事で、その人の本当の適正は、実際の仕事の中でゆっくり育成するという、決して悪いだけではない点もある。
学生時代に選択した科目が「文系」であったとしても、エンジニアやプログラマといった技術職の方が向いているとわかったり、もしくは、本人の努力で同期の「理系」たちに追いつき、追い抜いていく場合だって多い。
まぁ、入社時のコメントで出身大学の名前をわざわざ言う人には、正直、苦笑を禁じ得ないけれど…。
中学の理科から勉強しなおしている
中学の理科から勉強しなおしている
以前にも何度か書いたように、今年は非IT系の分野の勉強もしようと思っている。
（関連記事）
私には自動車が運転できない
実際、電気の勉強ということで、中学の理科から勉強しなおしている。
例えば、こういった世界について。
（フレミングの左手の法則）：モーターの原理
けっこう、やってみるとかなり忘れている。それに奥が深い。
やはりアウトプットは大切だ
磁界の向きと「右ネジの法則」があれば、「フレミングの法則」は左手も右手も不要ではないだろうか、などと思って、実際に絵に描いてみると、なかなか難しい事に気がつく。
やはりアウトプットしてみるのが大切だと感じる。
世の中では、学歴といえば「大学の入学歴」のみを指し、非大卒などは眼中にも入れられないようであるが、こうした工業高校や高等専門学校で学ぶことの方が、普通科の勉強よりも面白いと感じる。
多様性とは何だろうか。
IT業界の本当の問題はユーザーとベンダーとの距離にある
IT業界の本当の問題はユーザーとベンダーとの距離にある
（関連リンク）
「訴えてやる！」の前に読む IT訴訟 徹底解説（42）：
こんなことも知らないんですか？ ベンダーって勉強不足ですね
正しい要件定義のためには、ベンダーにも業務知識が必要
システム開発の上流工程に向く人と向かない人…（単なるグチ）
(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う
ソフトウェア開発でくりかえされる「競争発注」の愚行
最近、敢えてリンクは貼らないが、『日本には文系システムエンジニアなる存在が居てそれらが業界の問題である』とか、『欧米ではソフトウェアエンジニアには文系ではなれないしもっと高待遇である』とか、そういった論調を目にする。
いわんとするところはわからないでもない。
しかし、日本の商慣習や文化的な背景なども踏まえると、そういう問題ではないと思う。
無論、中小IT企業の一部にはびこっている『ろくな経験もない新人を経歴詐称して客先に送り込む』というビジネスモデルはすぐにでも抹殺されるべきだが…。
学歴が、理系だとか文系だとか、そんな事は『思考停止』した結論ではないか。
社会人になってからだって、努力して伸びる人も居るし、その逆も然りである。
何でも学歴に論点を収束させるのは、それこそアタマが悪い。
本当の問題は下記のような事である。
人月単価契約が横行しているため、個人や組織の固有スキルや業務知識などによる『生産性の差』『品質の差』がまったく評価されていない
ユーザー側が要件定義を軽視するために事前見積もりによる請負契約のリスクが高すぎる
システム開発は、建築業界に似た構造を持ってはいるものの、実際の仕事は建築業界と同じようには進められない。
もしも『作業量』に対してしか対価を払えないのなら、見積もりではなく作業結果を見てから払う契約にしなければ…。
（生産性や品質は絶対に人や組織によって差が出る。おそらく驚くほどの差として。）
そして生産性や品質の差にはしっかりと報いなければならない。
日本にだって、各業種/各業界ごとに、キーパーソンとなっている、ある意味でスーパーエンジニアと呼んでも良いような人が居る。
こういう人たちを正しく評価せず、単なる"業者"扱いして買い叩き、使い潰して来たことが、日本のIT業界の本当の問題であり、闇なのである。
本当のコア人材（人財）が育成されるには10年単位の時間が必要
とある地方の公共事業体の業務システムにおいて、その発注のやり方で、格差が出ている事例を最近知った。
一方では、その分野のスペシャリストと呼べるベテランリーダーが、人数も少ないシステム開発/保守の現場を支えている。そこではシステム開発者側の方がユーザー業務に詳しい事もあるらしく、システム開発者側が主導権を握れている。しかし、そのベテランリーダーの後進が育たない事がリスクとなっている。
他方では、競争発注（競争入札）によって複数のITベンダーに同一部門のシステムが切り取られ、保守体制もバラバラになっているという。
まぁ、どちらの事例でも、ユーザー側自らがシステム開発/保守はやっていないという点は同じだ。
欧米と比較するならば、ユーザー側自身のシステム開発への関与度合いだろう。
以前にも書いたが、ユーザーはシステムになんて興味が無く、システム開発者の多くはユーザー業務に興味が無い。
IT業界の若手はユーザー業務知識には無関心だが…それで良いのかな？ - IT (情報技術) 学習記録
これでは、要件定義なんてやる人が居なくなるだろう。
ずさんな要件定義を行って困るのは、ユーザー側でも、システム開発者側でも、どちらも『現業』『現場』の人間である。
アウトプットする良い機会になるなら休日に家でだってやる
アウトプットする良い機会になるなら休日に家でだってやる
近年では情報セキュリティの観点や、企業情報管理の観点、更には労働時間の観点からも、自宅での仕事は厳禁とされている。
まぁ、労働時間の観点は多分にポーズが入っているようであるが、情報セキュリティと企業情報管理の観点は本当に厳しくなった。
いまの若い人には信じられないかもしれないが、15年くらい前なら、家にUSBメモリ（当時は128MBとか256MBとかという容量だった！）やフロッピーディスクに仕事の資料を入れて持ち帰り、休日に仕事をするなんて誰もがやっていた。
いま考えてみると、良い時代だったのか悪い時代だったのか…。
ここで「悪い時代だった」と、何故断定しないのか、不思議に思うかもしれない。
家での仕事は「悪いこと」だと、何故断定しないのか。
確かに、やりたくもない仕事を、サービス残業ならぬサービス休日労働として、疲弊しながらやるのは、悪でしかないだろう。
現にそういう類の労働も経験がある。あれはモチベーションがまったく出なくて、本当に疲れるだけだった。
しかし、である。
昨年、三年間という長い休みを明けて現職に復帰した私としては、違う視点も持っている。
例えば、昨日の記事に書いたような、何かしらの発表（プレゼンテーション）用の資料作成。
これも、もちろん仕事には違いないので、本当はいまのご時世では「家でやってはいけないこと」ではある。
そうなのだが、現実問題、平日は本業で忙しく、なかなかまとまった時間も取れない状況だ。
プレゼン資料などは、内容にもよるが、基本的には、自分の頭のなかにある情報だけでほとんどを作り上げる。
ならば、勉強の延長線上ととらえ、自分の頭の中の知識のみで、自宅のPCのLibreOfficeなどのソフトを使って作成する分には、構わないのではないだろうか。
事実、プレゼン資料を作成するといったアウトプット作業は、自分にとってはとても勉強になることなのである。
メタスキルをどんどん高めて行きたい
先日、拝読した以下のブログ記事がとても良記事であると思った。
fromdusktildawn.hatenablog.com
この内容は本当にそうだなぁ、と同感するとともに、自分も若い人には負けないような存在でいたいと、改めて思った次第である。
無論、この記事内容と、私が休日作業をする事は、直接には何の関連もない。
重要なことは、日々勉強するといった姿勢のことである。
自己啓発もほどほどに…。それは確かに気をつけないといけない。
プレゼンはパワポ派？…私はPDF派
プレゼンはパワポ派？…私はPDF派
弊職場では、定期的に部門内部での発表会が行われている。私は昨年の途中まで休職していて浦島太郎状態であったが、どうやら休んでいる間にエライ人が決めた習慣であるようだった。
今年度は早くも業務繁忙などの事情もあり、なかなか発表者の立候補者が出ず、担当マネージャが困っているとのことだった。他人事のように聴いていたら、何故か私もプレゼンをする羽目になってしまった。
そういったことは若手の皆さんに「ヨロシク」していたのだが、たまには若くない者も何かを示さなければならないようである。
私はどうにもパワポが苦手
トヨタ式のやり方だと、「何事もペーパー1枚にまとめろ」というそうである。
個人的にはそれは同感であるし、大賛成である。
とにかく概要をA3用紙一枚にまとめる。
これ大切。
いままでも顧客やお偉方に対して何かを説明するときには、そういうやり方でやってきた。
しかし、現代は何でもかんでもパワポのご時世である。
電子紙芝居だ。
紙芝居ならまだ良いが、人によってはアニメーション機能をふんだんに使う。それだけは勘弁してくれと言いたい。
実は電子紙芝居は、パワーポイントだけのお家芸ではない。もちろん、マイクロソフト社製以外のオフィスソフトもそうであるが、何よりソフトを選ばないのがPDFである。
PDFでもAdobe Readerで電子紙芝居ができる。
私はアニメーションはいっさい使わないので、PDFで事足りる。
PDFならば、LibreOfficeでも充分なものが作れるので、こっちが良いな…。
アナウンサーが「星の赤ちゃん」「赤ちゃん星」と言うたびに残念な気持ちになる
アナウンサーが「星の赤ちゃん」「赤ちゃん星」と言うたびに残念な気持ちになる
（関連リンク）
アルマが鮮明にとらえた、巨大赤ちゃん星の産声
http://www.astroarts.co.jp/article/hl/a/9175_orion_kl?utm_source=dlvr.it&utm_medium=twitter
今日も単なるグチである。
地球から約1400光年の距離にあるとされるオリオン座の領域に、誕生したばかりと思われる、大質量恒星になりつつあるであろう現象を、世界で初めて電波望遠鏡でとらえた、というニュースがあった。
TVニュースでは昨夜から今朝にかけて、某国営放送のニュースにおいても取り上げられた。
アナウンサーは「星の赤ちゃん」「赤ちゃん星」という言葉を何度も使っていた。
そして、最後には男性キャスターから女性アナウンサーに渡されて、「宇宙のロマンですね」という言葉で締めくくられた。
「恒星」という言葉は一度も使われず
「赤ちゃん星」という言葉に違和感がある。
言いたいことは無論わかる。
しかし、無生物の、しかも巨大なスケールの恒星に「赤ちゃん」というのは、個人的にはしっくり来ない。
そして何よりも、「恒星」という単語はいっさい使わず、例えばこの記事の冒頭に私が書いたような表現もされなかった。
確かに一般向けのニュースにおいて、『専門用語』を多用するのは良くない。それはわかる。
でも、「恒星」は専門用語なのだろうか。
義務教育で習うレベルではないのだろうか。
特に「理系」分野の事を避ける風潮があるのでは？
これは特に何の論拠もない、ただの憶測に過ぎないのだが、感覚的には、特に「理系」分野の言葉や話題を殊更に避ける風潮があるような気がする。
そして今回のようにニュースとして取り上げるとなると、視聴者を『何も知らない』『無知』であると仮定した表現が使われる。
しかし、本当に一般の視聴者は、そこまで無知なのだろうか。
惑星
衛星
恒星
太陽系
銀河系
これらの言葉の意味や、スケール感を、本当にわかっていないのだろうか…。
宇宙は別に「ロマン」でも何でもない
私は個人的には、宇宙とロマンチックを関係付ける事は好まない。
何故なら、たいていの場合、宇宙を「ロマンチックですねー」という人に限って、天文学の基礎を知らなかったりする傾向があるように思えるからである。（多分に偏見を含んでいるとは思うが）
キャスターやアナウンサーは、それこそたいそうな高学歴な人々であると聞いている。
まさか彼らの認識ですら、「恒星」を専門用語と扱うレベルとは思いたくはない。
君たちは、わかっていて、敢えてそんな表現を使っているんだよね？
宇宙は宇宙。いま我々が居る場所も宇宙の一部である。
今回のニュースは、1400光年の彼方の事象だったが。
そもそも1光年よりもはるかに小さいスケールの太陽系であっても、それが人間にとって、どれほど大きなスケールなのか。
人類はまだ月に何度か到達しただけであり、火星にすら今世紀中には行けないのである。
必要な野心と不要な野心
必要な野心と不要な野心
先に書いたグチの続きのようなものであるので、そのつもりでお読みいただきたい。（手前味噌的な部分も大目に見ていただきたい）
（関連過去記事）
業界大手IT企業SEにしては野心がないと思った件
うちの職場などよりも10倍以上もの従業員数を誇り、業界では知らない人は居ないような大手IT企業に、今回は上流工程である要件定義段階から参入してもらっている訳である。
手前味噌という表現が合っているか自信がないのだが。言ってしまうと…。
今回、大規模改修を行うユーザー企業の業務システムは、非常に特殊で、まず類似システムはほとんど世の中には存在しないと言い切れるものである。しかし、その業務領域はユーザー企業にとっては基幹部分に深くまで刺さっているものであり、業務が消え去ることも、システムが使われなくなる事も想定し難い。
つまり、パッケージ化によるスクラッチシステムの廃棄や、事業自体が売却の憂き目を見るといった事はなく、その業務やシステムを一度でも知悉するまでに至れば、ユーザー企業がそのシステムを改修する度毎に、その仕事を高確率で受託することができる。
こういった部類のシステムの大規模改修プロジェクトに、上流工程から参加できるものなら多少の無理があっても参加してみたいと、そう思うITエンジニアやIT企業は多いのでは無いかと思う。
（こんな事を言ってしまうので、手前味噌という表現を使った）
しかし、今回の相手先のリーダー（大手IT企業社員）は、どうにも反応が薄い。
そのリーダーについてきている他メンバー（実はその大手IT企業社員ではなく下請けの方）の方が、よっぽど食いつきが良い。
いままで、他のITベンダーが独占していた業務領域を奪取できるチャンスだと思うのだが、そういう姿勢は感じられない。あくまでも受け身で「成果物のイメージを教えてください」とくりかえすのみである。
一言で言うならば、『野心が無い』
こういった野心ならば、必要な気がするのだが…。どうなのだろうか…。
不要な野心もある
同じ『野心』でも、まったくもって邪魔な、不要な部類の野心もある。
狭い意味での、『出世欲』などがそれにあたる。
承認欲求と自己肯定を周囲に撒き散らしながら、組織内での自分の序列を少しでも上昇させたいと腐心するような『野心』は、結果としては、陰で誰かを犠牲にする事が多いと思う。
出世というものは目標であってはならないのではないか。
良い仕事であったり、良い貢献であったり、そういった事の「結果」のひとつとして、出世というものがあるのではないだろうか。
…そんな風に思うのである。
客先に『何をどんな風に作れば良いですか』と訊くのは上流工程SEとしては敗北宣言なのか…どうかな…
客先に『何をどんな風に作れば良いですか』と訊くのは上流工程SEとしては敗北宣言なのか…どうかな…
（関連過去記事）
『システム開発の上流工程に向く人と向かない人…（単なるグチ）』
システム開発の上流工程に向く人と向かない人…（単なるグチ） - IT (情報技術) 学習記録
『(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う』
(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う - IT (情報技術) 学習記録
UMLのユースケース図なり、Mind-SAなり、様々な、"ユーザー側とシステム開発者側との間での『意思疎通』のためのツール"が開発されてきた訳であるが…。
それらは、基本的には、あくまでも『"最低限"これだけは決めて文書に残しましょうね。お互いのために』というものに過ぎない。
現にUMLのユースケース図などは、大雑把すぎる骨組みだけしか定義しておらず、中身は各々で工夫してね、である。
システム開発工程の、設計以降のドキュメントのフォーマットを細かく規定している企業があるが、それも目的としては、『どんなに業務知識や経験に差がある人がやって来ても、"最低限"この情報だけは決めて記載しましょうね』という事を規定する事で、品質のバラツキを抑えるためにある。
もちろん、大規模システムの場合は、記述レベルを『統一する』こと自体が、品質につながる側面もある。しかし、ルール上で規定するのは『最低限』の側なのである。低い方に統一する方向になってしまう。
それを踏まえた時、特に上流工程においては、『何を作ればよいですか』『どんなイメージの成果物を作れば良いですか』と、顧客側に訊く事は、どういう意味になるのだろうか…。
確かに、作業のマネジメントの観点からは、『誰が』『いつまでに』『何を』『どんな内容で』作成するか、キッチリ確定しながら進めたい。
確かにそれはそうだろう。
しかし、そもそも、上流工程とは『何を』『どんな内容で』これから作って行くか、それ自体を決める作業なのではないだろうか。
従って、ユーザー側とシステム開発者側とで、膝突き合わせて、『お互いの意見を主張し合いながら』進めていくものなのではないだろうか。
こう考えた時に、自分の主張をするシステム開発者が、何と少ない事か。
もっとも、これは開発者側だけの問題ではない。
主張などせずに、言われた通りのモノを作れば良い、という愚かなユーザー側がはびこっている事も問題である。
要件定義の前段階である要求整理すらまともにできないと言うのに。
とりあえず、そうは言っても進めないと…。
今回も結局はグチになってしまったな…。
(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う
(記事紹介)上流工程に向かう時の心構えとして…確かにそう思う
2007年の記事なので、ちょうど10年前の「@IT」さんの連載記事である。
土曜日に私が「単なるグチ」として書いた記事と、内容が関係するようにも思え、かつ、私としては響くものがあったので、ここで紹介したい。
（土曜日に私が「単なるグチ」として書いた記事）
システム開発の上流工程に向く人と向かない人…（単なるグチ） - IT (情報技術) 学習記録
『転職失敗・成功の分かれ道（31）：上流工程にいきたいなら新幹線に乗り換えろ』
転職失敗・成功の分かれ道（31）：上流工程にいきたいなら新幹線に乗り換えろ - ＠IT
なかなか厳しい内容かもしれないが、そうだよなぁ、と思った次第。
私には自動車が運転できない
私には自動車が運転できない
運転するための技能も持ち合わせていない。道路交通法の基本的な部分にも疎い。
何故なら、そのための訓練を受けていないから。
従って、国家資格である「第一種運転免許」（いわゆる普通自動車運転免許）を持っていない。
能力も持っていないし、そのための資格も持っていない。
だから、私には自動車が運転できない。
運転したかったら免許を取れば良いじゃないか、という何気ない言葉
世界でも類を見ないほどの、最高レベルの鉄道技術が普及している日本であっても、自動車運転免許の保有率は、相当に高い。
警察庁の統計情報を確認すると、障害を持っていない人であれば、ほとんどの人が、とりあえず免許だけは持っている、という状況なのがわかる。
子供時代には、将来はバイクを運転してみたいと思った時期もあった。しかし、生まれつき目が非常に悪い方で、矯正視力でもせいぜい「0.5」程度に留まってしまう事から、運転免許はあきらめた。
学生の時分に、割と本気で『一番役に立つ国家資格は自動車運転免許』（私は眼が悪くて取れない）と言ったのを一蹴された。人は皆、隣の芝は青いと言うか何と言うか、自分の持っているものの価値を知ろうとしないものであるな。
— ふじわら775SE@猫icon/職場復帰 (@KF7757) 2017年4月27日
上記にも書いたように、自動車運転免許は、「第一種運転免許」という、立派な国家資格である。
企業の求人広告に、「要普通免許」と書かれたものが何と多いことか。
多くの人が当たり前のように保有しているためか、その資格の大きさに気付いていない人が多くいるように思える。
「免許持ってないんですよね」と言うと、「免許くらい取れば良いじゃないか」と何気なく言われるくらいには…。
持たざる者だからこそあこがれる「免許」としての資格
情報処理技術者試験をはじめとするIT系の資格試験は、実は単なる認定資格にすぎない。自動車運転免許のような、「それを保有していないと行為が許されない」という強力な「免許」としての資格ではない。
今年から、情報セキュリティスペシャリスト試験（SC）が、情報処理安全確保支援士（登録セキスペ）という別の試験に変わり、IPAはこれを「名称独占資格」だと売り込んでいる訳であるが、しょせんは「名乗るのに登録が必要」というだけであり、IT業界の反応は冷ややかである。
情報処理安全確保支援士（登録セキスペ）として登録したからといって得られるメリットは、あくまでもその名称を独占的に名乗れるというだけである。登録することで発生する義務や維持費用なども考慮に入れると、むしろデメリットの方が大きいとさえ思える。
現に、業界大手IT企業の対応は鈍い。
今年度は、思うところもあって、非IT系の分野の勉強をはじめたいと思っている。
そこで目指したいのは、「業務独占資格」や「必置資格」の分野である。
くだらないと思われても良い。
自動車運転免許すら持っていない私にとっては、それがどんなに些細な資格であっても、あこがれなのである。
例えば「第二種電気工事士」とか、例えば「危険物取扱者乙種4類」とか。（あくまでも例だが）
持たざる者だからこそあこがれる「免許」としての資格だ。
10年後には絶対に来るであろう、我々就職氷河期世代（日本版ロスト・ジェネレーション）が社会から閉め出され、過当に競争せざるを得なくなる時代に向けて。
システム開発の上流工程に向く人と向かない人…（単なるグチ）
システム開発の上流工程に向く人と向かない人…（単なるグチ）
今回の記事は要するに単なるグチにすぎないので、そのおつもりで軽く受け流していただきたい。
ちょっとばかり、最近、思うことがあったので、特に整理せずに書いてみたい。
１．（仮定）とある航空業界の航空路管理システムというものがあったとする
いわゆる特定業界/業種のユーザー企業の、基幹系業務システムを考える。
ここでは仮に、とある航空業界のとある空港の業務システムがあると仮定する。（実際にはそのようなシステムはないだろうし、私はそもそも航空業界には属していない）
【システムの概要】
とある空港における、特定の複数本のランウェイ（滑走路）と、その前後の工程を意識した、特定の航空機材（航空機）のたどる航空路の管理・表示を行う。
主要機能のひとつに、航空機材の状況予測を計算表示するというものがある。
【今回のユーザーの要望】
上記の状況予測のための専用の計算仕様を全面的に変更したい。
計算の大まかな考え方はできているが、それを現行システムにどのように当てはめたら良いかは、ユーザー側もわかっていない。
２．ユーザー企業の業界の常識
例えば、順不同に挙げても、下記のような常識が存在する。
航空機は自力ではバックできない
ランウェイの両端に書かれている数字には特定の意味があり、ランウェイの呼び方もその数字が用いられる（つまり同一のランウェイでも呼び方が2つ存在する）
離陸、着陸を、どの方向に向かって行うか、またはどのランウェイを使用するかは、その時の風向きによって常に変化する
航空路の工程には、例えば空港から半径9km以内からは、タワー管制域になるなど、複数の工程が存在する
空港のスポットとランウェイ、またはその他の格納庫などへの移動（タキシング）のルートは、パターンがいくつもあり、状況によって常に変化する
管制官の許可なくランウェイをタキシングで横切る事はできない
ディパーチャー用の航空路、アライバル用の航空路が、それぞれ存在する
……などなど。
実際には、他にも大量の、専門知識が無いとわからないような常識も存在する。（上記にも少しだけ専門用語を混ぜてみたが、これらの用語も業界にとっては専門用語でも何でもなく、当たり前の用語である、と仮定する）
業界にとって、これらは「常識」の範疇であるため、わざわざそれらを丁寧に知らない人向けに解説したドキュメントがあるわけではない。
３．その業務システムに熟知している者は自分以外にはほとんどいない
そもそもユーザー企業側や、私の所属組織の、人材育成面の欠陥かもしれないが、そのシステムの中身をいろいろ知っている者は、今となっては自分のみという状況にある。
以前の記事でも書いたが、ユーザー企業側は、いわゆる中央官庁などと同じで、どんどん官僚化が進んでいる。
また、どうやら私の所属組織の中から新たな人材も投入できないらしい。
最上流工程の要件定義のうちだけなら、まだ自分ひとりだけでも何とかなるかもしれないが、実際にシステムを再設計/プログラム修正/テストの作業を行う場合、とても一人では回せなくなる。
そのため、上流工程から、いわゆる協力会社に入ってもらう事にした。
協力会社は、IT業界では有名な大手IT企業となった。（はっきり言って私の所属組織などよりはるかに立派な会社である）
なお、今回の業界や、特定の業務システムに対する経験値は、あまり高くはない。
４．意識の差による平行線
名のしれた大手IT企業だと言う事もあり、一緒に仕事をして行くパートナーとしての協力会社メンバーには、けっこう期待は大きかった。
投入してくれるSE（システムエンジニア）も、いわゆる上流工程の経験を持つSEだろうと思った。
自分で言うのも何であるが、この仕事は、人によって、もしくは会社によっては、「お金を払ってでも経験したい仕事」であると思っている。
下記の記事でも書いたが、特定業界の特定システムの知識とは、実はそれくらい貴重なのである。
しかし、一緒に検討を進めて行くうちに、意識の差がある事に気がついた。
【私の意識】
いまやっている作業は上流工程（要件定義）であるが、ユーザー側からの強い牽引力は全く期待できない。しかし、これは見方を変えれば、我々システム開発者側が主導して、アーキテクチャー設計を含めて提案できる状況である
まだ基本設計でも無い要件定義の段階なので、作成する資料は100点の完成版である必要はなく、60点のたたき台である。それを検討の場でブラッシュアップして行くのが良い
ユーザー側の担当者は、システム的な「ファイルの図形」「フロー図」などを見てもピンと来ない種類の人達である。従って、システムの全体像をざっくりと把握できるような（俯瞰的な）概要資料が必要となる
上記の概要資料は、システム改訂を行う我々にとっても今後有用になる。何故なら、それが書けないとシステムテスト計画が作成できないからである
システムの調査作業にはいろいろな方法があるが、今回の場合は、どの部分を改定しなければいけないかが、大まかにはわかっている。従って、その部分を起点として、業務目線で影響調査を行って欲しい
システムの設計書などのドキュメントには業界の常識を前提とした記述が多い。自分もその常識の中に居る人間なので、素朴にわからない用語や概念などがあればどんどん質問して欲しい（もちろん、現行システムのドキュメント一式は全てお渡しする）
【大手IT企業メンバーの意識】
ユーザー側の要望事項が全ての出発点である。（システム開発者側からどんどん提案して良いという事を言うと驚かれる）
次回の検討会までに作成すべき資料の内容は、いまの打ち合わせの中で詳細まで確定しないといけない。そうしないと作業にムダが生じる
概要資料を作りたいという言葉の意味はわかるが、それを作成するにはシステムを隅々まで調査しなければならず、時間が非常にかかってしまう
システム概念図のような資料は自分たちなりに作成して来ているが、それでも「ユーザー側にはピンと来ない」と言われると、もはや何を作成して良いかわからない
今回変更となる画面項目などのキーワードを起点として、grep検索などを行い、ボトムアップ的な影響調査がどうしてもメインになってしまう
例えば「宿題」でも良いので、「次回までにこれを調べて来てくれ」といったような具体的な指示が欲しい。それがあると作業が楽である
断っておくと、私は協力会社の方を否定するつもりはない。
おそらく、言っている内容は間違いではない。
ただ単に、意識の差がある。
それだけだろう。
５．ユーザー側はシステムには全く興味がないし、システム開発者（ITエンジニア）の多くはユーザー業務には全く興味がない
官僚気質が強い大企業や、中央官庁などのシステム担当者と話をするとよくわかるのだが、彼らは、システムの事など全くといって良いほど興味がない。
中には、自作PCが好きなどという人も居るが、PCの世界と、システム開発の世界は、また別である。
興味がないという事も、無理からぬ事である。
システムの話は業務のいっかんでついでに覚えられるほど、生易しいものではない。従って、覚えるとなると、相当に頑張らないといけない訳であるが、そこまでして、本業ではない分野を覚えたとしても、2～3年で定期異動になってしまう事を考えると、意義が見いだせないのである。
あまつさえ、システム開発/保守は、アウトソーシングしてしまっている。現場からの問い合わせ業務さえもヘルプデスクとして外注している現状がある。
一方で、本業の業務面はどうかと言うと、これもまた、先に別の記事で書いた通り、支社/支店などの「現場側」に知識が集約される形になり、定期異動でコロコロと部署異動をするため、深い知識はなかなか身に付かないという事になる。
システム開発者の方は、良く言われているように、一般的には、
ユーザー企業 ＞ 大手IT企業 ＞ 中小IT企業 ＞ 中小IT企業 （１例）
…などといった、多重請負構造の中で、どうしても末端近くに位置するエンジニアのユーザー企業に対する帰属意識は希薄となり、それに伴ってユーザー企業の業務への興味も薄れていく傾向がある。
先の別記事にも書いた通り、ユーザー企業の特定分野/特定業務システムの知識を買われて、ユーザー企業や、そこに近いIT企業に誘われて転職する事例もあるのだが…。
しかし、こういった情報は、内容の性質的にも、秘密裏に行われているので、なかなか一般には知られていないのが現状である。
上記のような、「システムには知識も興味もないユーザー側」と、「ユーザー側の業務には興味がないシステム開発者」との、仲立ちをうまく行える人材が、実は最も不足している。
一般的には知られていないが、こういう人材が本当はとても貴重。
花形と思われる「インフラエンジニア」は、実は世の中には数多く居る。そのため、過当競争になっているのである。
６．大手IT企業の人といえども上流工程はなかなか難しいのかな？
上述したような、「システムの事など知らないし興味もない」という人と打ち合わせを数多くすれば、「システム概念図」などのシステム屋がよく作成する資料が、いかに相手に『響かない』かが、わかるだろう。
システム屋から見て、ユーザー業務側の専門資料が非常に難解であるのと同じように、例えば入出力設計書などの、システム屋からすればユーザーにレビューしてもらう対象ドキュメントであっても、それがユーザー側から見れば非常に難解なのである。
例えば元請けIT企業でユーザー側と直接折衝をしている人が居るとして、そういった人は、プログラミングなどは体制的にやらない訳であり、そういった人を小馬鹿にするエンジニアも多くいるが…。
前項で書いたような、ユーザー側とシステム開発者との間を仲立ちする役目を担っているのであれば、それは価値のある仕事であると思える。（一方で、それすらも放棄し、下請けに丸投げしているようなら、たしかに小馬鹿にされても致し方ない）
この役割は、おそらく経験しないと、わからない。
どんなに大手のIT企業のエンジニアだとて、そういった経験がないと、わからないのだろう。
さて…。
上記のような思いを強く思った5月の私なのである。
本当にどうしようかな。
（注１）上記に挙げた業界や業務システムは本当にこの場だけの架空の例です。
（注２）私は航空業界とはいっさい関係ありませんし、専門家でもありません。細かいツッコミもあるかもしれませんが、暖かな目で見てください。
「終身雇用はもう古い」に対する反論…「給料の年功序列」をやめれば良いだけ
「終身雇用はもう古い」に対する反論…「給料の年功序列」をやめれば良いだけ
様々なところで言われている「いまの時代には終身雇用なんて合わない」「終身雇用なんてもう古い」という言説に違和感を覚える。
この言説は、多分に労働者側ではなく、使用者側、つまり経営者側の都合を含んでいる。
終身雇用（正社員など）に関する規制を緩和したところで、得をするのは労働者側ではなく、圧倒的に経営者側であると思える。
就職氷河期世代：日本版ロスト・ジェネレーションに、一応含まれている世代である私から見てもそう思える。（但し、この失われた世代に対しては、別途、救済する制度は必要であると考える）
「終身雇用」だからといって「給料を年功序列にする」必要はない
「終身雇用は維持できない」という言説には、必ずと言って良いくらい「年功序列が維持できない」という論理がセットになっている。これが不思議でならない。
ここで言う「年功序列」は、つまり「給料が」という意味合いが強い。
多くの労働組合は、一般的な家庭における「生計モデル」と、それに見合った「賃金カーブの維持」を主張してきた。20歳代で結婚して、30歳前後で第一子を授かって、40歳代に子どもの教育費などがピークになって、という「生計モデル」である。
この生計モデルは、私の世代からすると、もう古いと言わざるをえない。良い悪いは別にして、このモデルは既に崩壊してしまっているのだ。
崩壊している生計モデルを論拠とした、「賃金カーブ」の維持は、確かに時代に合っていないと感じる。
しかし、その事が、「正社員の規制が古い」とか、「終身雇用はもう維持できない」という考えに発展、飛躍する事が、正直、理解できない。
けっきょく、右肩上がりの「賃金カーブ」だけ見直せば良い話ではないのか。
使用者側と労働者側との合意が軽視されている現代
かつての昭和中期時代の高度成長時代のような、「サラリーマンは気楽な稼業」という幻想は、確かにもう古すぎてお話にならない。
いつまでたっても成長しようとしないような問題社員が居る場合には、しっかりと評価を行った上で、処遇を落とすなどの措置は当然、行われるべきである。そしてその状態が一定期間、改善が見込まれない場合には、退職をしてもらう。企業だって営利団体なのだから、その点は当然である。
これは過去の終身雇用が主流だった時代でもあった事である。ただし、いきなり労働者側の都合や言い分を無視して、使用者側の独裁で行われるのではなく、できるだけ話し合いを重ねた上で、お互いに合意した退職を目指す。
いまの時代、この点が軽視されている場合が多いことが問題なのである。
その「お互いの合意という点が軽視される状況」がはびこっているのが、いわゆる「非正規雇用」の世界や、形式上は「正社員」であっても実質的には「人月商売による派遣」もしくは「偽装請負」が横行している世界である。
このような世界には「使用者側の利益」しか存在しない。
しかし、それは使用者側にとっても「短期的な視点での利益」でしかなく、「中長期的な視点での利益」では、むしろマイナスなのではないだろうか。
「終身雇用」だからこそ中長期的な人材育成が可能
長い職業人としての経歴を積む中では、時には研修を受けたり、すぐには結果が出ない勉強期間も必要である。
そういった個人としての中長期的な成長を考える場合、終身雇用の考え方は利点が多いと思える。
個人としての成長を促すことで、企業としても中長期的には競争力が増加する。
「終身雇用」という言葉が悪ければ他の言葉でも良い
重要なことは、
(基本的には)自分から転職を望まない限り長く働ける職場
中長期的な成長を配慮してくれる職場
育児や介護などといったライフステージ変化にも配慮してくれる職場
…が、制度的に確保される事である。
「旧態依然の終身雇用にしがみついている人々が、非正規雇用の職を奪っている」という言説によって、労働者同士の対立を煽るのは、ブラックな使用者側の狡猾な洗脳なので、それに騙されてはいけない。
「時代に合わない年功的な賃金体系」がある故に、「あの中高年社員はろくにパフォーマンスを上げていないのに高い給料をもらっている」などという不公平感が出てくるのである。
パフォーマンスが悪くなれば、待遇も下げるのは当然の事である。
ただし、順当に経験値を積み上げてきた中高年社員であれば、必ず特定の強みを持っていたり、莫大な経験値のみで大抵の判断ができるため、頭の力をより創造的な面に使ったりできるようになっているものである。
そういった価値は、やはり評価されるべきであるし、日本においては、『失われた20年』によって、取り返しがつかないほど、喪失してしまった真の労働力なのである。
「知ったかぶり」からはじめよう
「知ったかぶり」からはじめよう
はじめは誰もが初心者・初学者である。学問でも仕事のとある領域でも。
人は何者かのフリをする事からはじめ、そうする事で、その何者かに近い存在になって行く。
何かの専門家になりたいと思うなら、その専門家のフリからはじめれば良いのである。
一応、普通の職業人として20年程度、様々な人を見てきたが、何年たっても「その道の専門家」にならない人、「その道の専門家」として周囲からも一目置かれる人、両方いる事がわかってきた。
ここで断っておく事は、必ずしも専門家になる事がすべて良い事である、とは言い切れないという事である。人には「向き不向き」がある。「ゼネラリスト」も世の中には必要であると思う。
その上で、私は個人的には、専門性を高めたいし、これからの世の中に強いのは専門性を高めたスペシャリストであろうと思っている。これはここでも何度か主張してきた事である。
「わからない」と言っているうちは「わからない」
日本人は控えめな方が好まれる。そう思っている人も多いようである。
しかし、仕事において、必要以上に謙遜して「自分はよくわかっていないんですが」と言うことは、マイナスでしかない気がする。
例えは悪いかもしれないが、よく「仕事はできる人に集中する」と言われている。
情報や知識も、実は同じである。たくさん持っている人に、より多く集まってくる。
「わかっていない人」よりも、「わかっている人」に、より多くの情報が集まる。
自分はこの分野をよくわかっていない。よく知らない。
謙虚に自分自身の中で思う事は大切であるが、それが過ぎると、自分に対する言い訳になってしまう。
確かに100点満点の知識はない。でも、60点位の知識はあるかもしれない。
こういう場合、まだまだ100点ではないから「自分はよくわからない」と思い、人にもそのように言うか、もしくは、60点くらいは知っているので「自分はまずまず知っている方だ」と思い、そのように振る舞うか。
実は、100点満点の人など世の中にはほとんど居ない。
従って、前者では、いつまでたっても「自分はよくわからない」と言い続ける。一方、後者は「自分はまずまず知っている」と思い、そのように振る舞う事によって、自然とその知識をさらに高めていく。
「はったり」をそのままにしない
専門家のフリをするという事は、時には「はったり」をしてしまう事もある。
ここで重要な事は、せっかく打った「はったり」をそのままにしない、という事である。
「はったり」を打つ。そうすると、その後、自分の中では、「あのはったりは正しかっただろうか」と必死に思いが駆け巡る。
なお、知識がゼロの人には「はったり」は使えない。知識がけっこうあるからこそ、できる事でもあるのだ。
従って、「はったり」は割と当たっている事が多い。しかし、自信が無い。そこで、上記のように、「はったりは正しかったか」を後でしっかりと検証する。
検証することで、その知識は定着する。
こう言う私も、最近、仕事疲れで勉強が進まない。フリばかりしていないで、早く本当に知識を付けなくてはと思う次第である。
