  |
はてなキーワード: フェーズとは
悩みの大半はさっさと行動すれば解決する話です。
■気がついたら得意分野がなかった
早い話が、流れに身を任せていたら得意分野がなくて詰みかけてるという話です。
基幹業務パッケージのカスタマイズおよびアドオン開発をやってきました。
開発、運用、保守フェーズのすべてを経験していますが、要件定義をはじめとして、お客様と調整、折衝した経験が一度もありません。
様々なプロジェクトで仕事をしてきましたが、「何が得意なの？」と聞かれると閉口してしまいます。
■気がついたら何も身についてなかった
WEBの世界に憧れてITの世界に入りましたが、プログラミング経験のなかった自分が配属されたのは統合業務パッケージのチーム。
続けていれば何かが変わると信じて、目の前の仕事に打ち込みました。
SEの自慢話の常套句にあるように、熱が出ても点滴を打ち、心が壊れそうになっても吐きながら通いました。
配置転換で担当するシステムの業務が何度か変わっても、1から勉強してなんとかついていきました。
有名コンサルティングファームやSIerと一緒に仕事をしていて愕然としました。
自分が5〜10年かけて習得したパッケージの知識は、新人教育とOJTによって数ヶ月で習得するものだったのです。
結局知識はお金で買える。パッケージ導入という狭い世界では、知っているのが当たり前。知らない奴は入ってくるながルールなのです。
■信じてやってきた10年間
結局は自業自得です。自分のキャリアを見つめ直す機会は沢山ありました。業務外でスキルアップをする機会もあったでしょう。
それでもなお、目の前の仕事を一生懸命にこなしていれば、後から良かったと思えるときがくるだろうと、自分を信じ込ませてきたのです。
年齢が上がっても上流を経験する機会がなかなかなく、常に頭を下げながら、「経験はありませんがやらせてください」と頼み込むのが常です。
結局、アサイン先で経験させてもらえることはなく、今に至ります。
私には武器がありません。コミュニケーション能力が高くてセッションが得意なの同僚や、手を動かすのが早くて技術もある同僚と比べると、私には特筆すべき能力がありません。
彼らが早く帰っても「そういうやつだから」と認められますが、私にはバリューを出せるようなスキルがないので、結局のところ量(つまり残業)で年齢にみあった貢献をしようとしてしまいます。
これからどうすれば良いのか。
一応、肩書きはSEだったりコンサルだったりしますが、パッケージ外のこととなれば完全な門外漢。
キャリアをチェンジすることも難しいです。持っている知識もニッチで浅くてバラバラです。
自分の存在価値が日に日に値減りしていく恐怖感で押しつぶされそうです。
私は何と戦えば良いのか。何を乗り越えれば良いのか。
投資家として、M&Aの担当者として、そして自身が起業家として多くのスタートアップを今まで見てきた。
君たちのサービスがいきなり終了とするとして、泣いて悲しむユーザーがどれくらいいるのか？業務が回らなくなる企業がどれくらいいるのか？
サービスの種類にももちろんよるが、サービスローンチして半年以上経っているにも関わらずDAUが100人以下のサービスは今すぐ畳んだほうが良い。
※但し、必要とはされていないが見せ方・売り方が上手な為に売上を上げ価値を高めているスタートアップもいる。
そもそも狙っている市場の規模が小さすぎるスタートアップが多い。
これはシェアリングエコノミー系に多い。
Uberの◯◯版です、AirBnBの◯◯版ですとニッチを攻めるのは良いが、そもそも市場規模が10億円以下であればトップシェアを取ってもロクな売上にならないのはわかるだろう。
またその手のニッチ層は今まで大手が攻めなかった市場だ。言い換えれば攻める価値がなかった市場なのだ。
経験上、失敗の1番の要因はマーケットの選択だが、2番目はチームビルディングにある。
CEOは特にスキルもなく、名ばかりのCTOはWeb系の開発を1年2年やったことがある程度。
最初のフェーズなのに何故かCFOもいたりもするチームもある。
なぜそのチームでその事業をやるのか説明できるだろうか？そのチームが最速でサービスを成長させることができるのだろうか？
経験不足の学生であれば開発マネジメント経験のあるエンジニアを雇おう。
スタートアップを勘違いさせるものがイベントやメディア露出だ。
マイクを持って意識高い系の学生向けイベントで登壇するのは気持ち良いかもしれない。
スタートアップ系のメディアに紹介され、Facebookでちやほやされるのは気持ち良いかもしれない。
ただ、覚えておいてほしい。
それらを見ているのは顧客ではない。
広報や採用のツールとして使うのは構わないが、それよりもサービスの質を良くし、営業を行うことに時間を使うことをお勧めする。
黙っていてもサービスは売れないよ。
Webで見つけて勝手に契約してお金が入ってくる、そんなに甘くはない世界だ。
特に大企業であればコネクションは必須だ。勝手にものは売れない。
オンラインだけでは無理だ。仕組みを作ろう。
他にも20個くらい要因はあるがそれはまた次回にお伝えしたい。
パンク修理は、昔から何度か習得しようとして練習してて、修理の手順自体はわかるんだけど、
あのヘラみたいな道具を使ってゴムを押し込むパワー勝負のフェーズがどうしても突破できないクソ雑魚モヤシナメクジなので、自力では直せない
……というわけでプロに頼むのだけど、家の近くならいつも世話になっている自転車屋まで持っていくのだが、
会社の近くでパンクしてしまったので近くの自転車屋を探して昼休みに持っていくことにした
前も通ったことのない店にいきなり行くのはなかなか勇気がいる
ストリートビューで確認したところ、バイクや車から自転車まで修理します、みたいな小さな修理工場っぽい店のようだ
念のため行く前に電話をかけてみたら、ぶっきらぼうなおじさんが出てビビった
お店自体はちゃんと営業してて、パンク修理もしてもらえるらしい
自転車を押して20分ほど歩いて到着すると、ちょうど何人かおばさんやお姉さんが自転車で乗り付けて整備や部品交換や修理の依頼をしていた
なんか、思ったよりはやっている
作業服は油で汚れてるのになんか妙に小奇麗だし
結構人が多くて、一人で捌ききれず処理落ちしてアワアワしているおじさんをしばらく眺めて待機
電話したこととパンクの症状を伝えると「わ、フレンチバルブかー、コネクタないんだよなー」とか言いながらも、まあなんとか空気入れとくよーと預かってくれた
今まで持ち込んだ自転車屋で何も言われたことがなかったので全然知らなかったけど、通販で見た目が気に入って買っただけの折り畳み自転車のくせになにやら妙なパーツを使ってたらしい
とりあえず昼休みが終わる前に連絡先を伝えて退散した
夕方、自転車を取りに行ったら、おじさんが「なんか２ヵ所、針みたいな小さいのが刺さってましたよー」と言いながら自転車を出してきてくれた
うん、この人あれだ、なんていうか、かわいい系のおじさんだ
そして修理や整備の依頼をしてた奥さん方の中に、かなり常連っぽい人が複数名いたのも多分気のせいじゃないぞコレ
やっすい修理代金を払って自転車を受け取ったら、「タイヤが結構ヘタってるから、近いうちに交換した方がいいですよー」と言われた
一瞬そのままお願いしようかと思ったけど、自転車を預けてしまうと通勤でちょっと困るのと、会社と店の距離が割とあって何度も訪れるのは移動がしんどいので今回はやめておいた
お礼を言って、直った自転車で会社に戻りながら、もしかしたらあれがおじさんの精一杯の営業だったんじゃないだろうかと思って、
なんか悪いことしたような、別に気にしても仕方がないような妙な気分になったので今これを書いている
書いてて思ったけど、俺が罪悪感みたいなのを抱いてるのは、
出先でパンクになった困り具合や、直してもらえて助かった度に対して、1000円ほどの修理代金が不当に安い感じがするせいなのかもしれない
しかもめんどくさい形式のバルブのやつをいきなり持ち込んでるのに追加料金とかなかったみたいだし
昔、田舎の学校とズブズブに癒着した寡占状態の自転車屋で、チューブ交換したわけでもないのにパンク修理１ヵ所で4000円取られたことがあるが、
もし今回も4000円払ってたら、きっとこんな気持ちにはならなかっただろうなーと思う
ゴミのようなツールを使った開発をやってる自社プロジェクトがある
自分はその後別のプロジェクトに引っ張られてそのツールのプロジェクトからは抜けたが、運悪くその開発に入った後輩がいた
大変だろうなと思っており、しばらくあとの飲み会で声をかけた
「大変だろ、自分も大変だったよ」
「社内で上が推進してるからツール使えねー！とか言えないし、苦労するよな」
行き場のない不満を抱えていたら吐き出せるようにと
いいかげん上は理解しないのか、と思いながら自分は遠くから眺めていた
ゴミツールプロジェクトに別の後輩が参画していたのは知っていた
それが今日まで続いているらしいことを知ったのは昨日だ
リーダーになり、顧客の運用フェーズでの開発作業をやっているんだとか
ゴミをゴミだと知らなければ、先の後輩も辞めることはなかったのだろうか
ゴミだと思いながら良い製品だ、がんばれと煽るのが正しかったのか
分からない
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。
最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。
http://arclamp.hatenablog.com/entry/2016/06/23/172941
冒頭，
とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。
それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。
この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。
さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。
答は
である。
すごく当たり前のことなのだが，これが書かれている記事が見当たらない。
そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。
ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。
よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。
そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。
「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」
これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。
その結果，これまでどんなことが起きてきたか。
開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。
「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。
これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。
最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。
そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。
スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。
もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。
ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。
そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。
アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。
1. スコープの変化がありうることを前提としている
2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる
この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。
また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。
もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。
もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。
契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログに対するSIer側からの反応を見て危機感がないよなーと思った。
「ウォータフォールは一切メリットがないので止めておきなさい」っていう言葉のメリットって誰にとってのメリットかっていうのに齟齬がある感じ。
受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。
確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？
実際につくった後で「思ってたんと違う！」と言われても、「要件定義で合意した通りですよね？」と言える仕組みで自分たちがお金を貰えないリスクを抑えてるんでしょ？
だから顧客にとっての価値に言及せずにウォーターフォールにもメリットがあるって言うのはポジショントークじゃないですかね。
そりゃ「ウォーターフォールは一切メリットがない」なんてことはないですよね。SIerにとっては。
ウォーターフォールじゃないと契約できないとか日本の文化があるからアメリカのやり方はなじまないとか言ってて、じゃあその日本に馴染むやり方で価値のあるシステムが組めてるのかっていう。より価値のあるシステムを生み出そうとしてるのかっていう。
そうやって現状に甘えてるばかりで、より価値を生み出せるやり方をするプレイヤーが出現したらどうなるのか、みたいな危機感がないですよね。
知らんけど。
【ぜんぶ実名】パナマ文書に出てくる「日本の億万長者」大公開！ 国税よ、もっとちゃんと調べてくれ
http://gendai.ismedia.jp/articles/-/48745
エマ・ワトソン ソフトバンクグループ社長孫正義 楽天会長兼社長三木谷浩史 丸紅 伊藤忠商事 神戸の大富豪島田文六(シマブンコーポレーション前社長) 事務機器リース大手光通信創業者重田康光 生鮮食料品店「アルス」松下孝明 金沢医科大名誉教授・ベンチャー社長友杉直久 医師・久保伸夫 オーバスネイチメディカルジャパン代表大場剛 佐川印刷元役員・SGチャンギ社元会長村橋郁徳 宮本敏幸 日本企業がタックスヘイブンを「合法的」に活用してきた 影響もあって、'89年には19兆円あった法人税収入は、 '14年には11兆円にまで落ち込んだ。 一方で消費税収入は3.3兆円から16兆円へと激増している。 法人や富裕層が節税した分の税収をカバーするために、 海外へ資産を逃がすことなどできない庶民が、 税金を絞り取られているのである。
「パナマ文書」大公開！ これが税金を払わない日本人「大金持ち」リストだ セコム創業者,UCC代表の他にもいた
http://gendai.ismedia.jp/articles/-/48640
UCCホールディングス社長・UCC上島珈琲グループCEO上島豪太 セコム創業者・最高顧問飯田亮 アイスランド前首相グンロイグソン キャメロン英国首相の父 プロゴルファーニック・ファルド ウクライナ大統領ポロシェンコ ロシアプーチン大統領の「友人」 中国国家主席習近平の義兄 元サッカー選手ブラティニ パキスタン首相シャリフの子 香港ジャッキー・チェン サッカー選手メッシ 伊藤忠商事 丸紅 スターバックス 米アップル
まだ人名「量」の不足感や単発感は否めない。
満を持しての表題作
異星人とコミュニケーションするために言語学者の女性がいろんなアプローチを試みる中で、ところどころに女性の娘へ話しかけるような描写が入る
一見何の関係もないように見えるのに、最後の最後でその構成の意味がわかったとき、めっちゃ感動して鳥肌たった
SFとお話としてのオチがすごく綺麗につながってて、しかもそれが読みやすさにも寄与する構成になっているという、何重にも考え尽くされた構成
どーゆーことかっつーと、娘へ語りかける描写→言語解析アプローチフェーズ→の繰り返しなんだけど、言語解析のところはぶっちゃけ読んでて結構きついのよ
わからないわけじゃないけど（ここもテッド・チャンのすごいところ。自己満じゃなくて、読者にわかるレベルで丁寧に書いてくれる。この話にかぎらず）、
細かすぎて疲れるっつーか、ずっとこの調子で書かれるとちょっとうんざりするなあという感じ
それが娘への語りかけ（これも平易だけど細かいディテールに凝った、感情移入しやすい描写）がはさまることで、かなり緩和されてるのよ
そんでその構成も、ただの読みやすさのためだけじゃなくて、ちゃんと意味があるの
もうファーーーーーーーｗｗｗｗｗｗｗｗ
ッて感じとうっわまじかよ・・・って感じで思わず本を置いてしまった
SF作家じゃなくて言語学者が書いたのかとばかりに凝りに凝ったディテールの、異星人の言語解析描写は、ほんとやばい
全部やばい
いまんとこ面白さは、
かな
マジすげえ
もっと早く読んどくんだった
星を継ぐものとか夏への扉なんかより、こっちを先に読むべきんだった
たぶんこれってIngressが原因ではないと思う。
人付き合い耐性というか生き方のスタイルが問題の大本なんじゃないかなぁ。
パートナーさんはあなたが人と繋がることで、間接的に人と繋がってしまって、それがストレスになっているような気がする。
浮気の心配をしているとかでもなく、自分のコンプレックスを刺激されてしまっているんじゃないかと思う。
いるはずのパートナーの不在っていうのは、単に一人でいるのとは違うんだよ。
たとえ話が適切かどうか分からないんだけど、毎週末ＢＢＱされるとか、即売会で交流されるとか、チケットノルマも楽しみながらライブハウスの舞台に出るとか。
そんな「自分に出来そうもなくて諦めたこと」を忘れたいのに、それを思い出してしまう。
人付き合いってやつを出来れば避けて忘れ去りたいんだけど、あなたの活動で思い出さされてしまって、劣等感を刺激してしまっているんじゃないかなぁ。
なのでIngressであろうと登山だろうとネトゲであろうと、交通手段が車だろうと電車だろうと徒歩だろうと、不満は消えない気がする。
悪く言えば、休日出勤の親に文句を言う子供のように依存してしまっている。
よく言えば、相手はそれだけあなたの存在を大きく感じている（無視したり放っておいたり出来ない）ってことじゃないかしら。
問題が人付き合いのスタイルの問題なので、今後も同様の問題が出てくる可能性は大いにあると思う。
個人的な経験を言えば、Ingressもそのうち飽きが来ると思う。ポケモンGoに移行してフェードアウトしていく人も少なくないし。
仕事や生活のフェーズが変わって、人付き合いの量も変わっていくかもしれない。
また相手も相手で自立して、あなたへの執着が減っていくかもしれない。
そういう変化を前提とせず、このままの状態が続くのだとしたら、今後も仲良くやっていくのはなかなかしんどい気がするな。
どう生きていくかって問題だろうからね。そのへんを話し合わないといけないんじゃないかな。
「ダメなアルゴリズムで書かれたコードは、いくらでも捨てて書き直せる。しかしデータ構造に問題があった場合、プログラム全体の書き直しに発展してしまう」
この話と微妙にカブるようでカブっていないが、言い方だけ真似たものとして
「クソな下請けはいくらでも代わりを探せる。しかし元請けの回し方がダメだったら全員でデスマ確定」
という話もある。これまた開発経験者ならよくご存知だろう。
すなわち、最低でも年収500以上は確実に貰っているであろう、エリート様揃いのITゼネコンの中にも、一握りの、まさに一軍というべきデキる人達と、そうじゃない人達がいると。
そして一軍と二軍以下では、マネージメントにおいて天国と地獄くらいの差が出るのだから恐ろしい。
というかなんでそれだけの年収に見合う学歴がある人達なのに、デキる人が一軍扱いされるほど少数なんだよ、意味わかんねえ。
学歴というのは、努力の仕方、効率の見極め方についての上手い下手の最も分かりやすい数値だと個人的には思っている。
そうなれば当然高学歴は、システム開発という極めつけの頭脳労働で、そのパフォーマンスを遺憾なく発揮し、協力会社含めて皆をハッピーにするのだろう…そう、一軍ならね。って、全員じゃねーのかよ！
具体的にはこうだ。
良い方から説明すると、一軍のマネージメントは要件定義から寸分の隙もない。
顧客の経営戦略に基づいた要望を良く理解し、仕様に取り込んでいることは勿論、システム間通信のような、後でとんでもない話が発覚して色々揉めそうな部分も、既にこの段階において顧客の協力を取り付け、キッチリまとめていたりする。
とにかく裏で細かく調査していたことが見て取れて、仕事したんだね～という感じである。
それから設計に取り掛かるのだが、やはり要件定義の段階で「どうしても見えない部分」はあって、下請け以下が作業の過程で洗い出した結果、それが時にはリスケを招く事故になることがある。
しかし一軍の人らは、本来最後の手段であるリスケにも比較的前向きで、それについての顧客説明もしっかりしているのだろう、大して揉めること無く妥当な落とし所にたどり着くのだ。
また、下請けのグループ(≒サブシステム単位)に必ず1人以上プロパーを配置し、現場感の吸い上げと「同じ釜の飯を食ってる」感の醸成にも抜かりない。
それもあって、現場でよくありがちな「あの人ら(元請け)何も分かってない」という陰口は最小限になる。
強引にまとめるなら、リスクが常に頭にあって、かつその取り方について常に考えを巡らしている。「かもしれない」運転をしつつ、逃げ腰にならない姿勢は見事である。
そして、二軍以下は上述の一軍の振る舞いが全くできない。本当に全部できていないのだ。
要件定義は客の要望を汲み取る所から既に漏れ漏れ、当然後ろの工程で揉めそうな部分は一切見ていない。
設計の大元、ひいてはシステムの大元になる部分がこれだけ不完全だと、その時点でデスマ化・炎上は約束されたようなものである。
その後に起こる事態は、もはやここに詳しく書くまでもない。
穴だらけの要件定義を、場当たり的に客に相談しながら埋めていく作業が設計のお仕事になり、それが相次ぐ仕様変更を呼ぶ。
結果どこまでExcelやソースコードをいじっても作業量が減らない、いやむしろ増える。しかも成果物が増えてくる各フェーズの終わりが近づくほど、「横展開」という名目で作業量が爆発的に増大するのだから始末が悪い。
各成果物を直しきれず「修正漏れ」という事故を仕込むことも頻発し、それに伴い品質も凄まじい勢いで低下する。
それでもケツは絶対に動かない。それどころか人員の追加すら出来ない元請けもいる。お前ら見積もりドンブリ過ぎだろ。
現場では脱落者が日常的に出る。でも下請けチームにプロパーが1人もおらず、そうした危機的な現場感が上に届かない。それも合わさって「あの人ら何も分かってない」という愚痴が漏れ聞こえるようになるのだ。
こんな体たらくじゃテストに漕ぎ着けるなんて夢のまた夢だし、仮にどうにか辿り着いても、何がどう動けばいいの？ってレベルでグダグダだったり。
いやもう、マジで元請けの人らは何やってんの？という感じ。優秀な人が何十人もいるのに機能していないとか、なんでそんなことになるんだか。
みなさんがいつもポイントカードがどうとか袋がどうとか箸がどうとか温めるとか温めないとかで苦戦しているレジ通され。
無駄にストレスを貯めるくらいだったら、いかに早く通されるか、という方向で遊んでみませんか。
－－
あらかじめ概算金額を試算しておき、少し多めの金額を前提に財布から出しておきましょう。
小銭が何円あるか確認しておき、とっさに出せるように整理しておきましょう。
また、下記の各種フラグをどう立てるか、事前に決定しておきましょう。
・必ず立てないといけないフラグ
袋の要不要
ポイントカードの有無
弁当の温める/温めない
電子マネーを使う/使わない
なるべく店員がバーコードを見つけやすいように自然と並べておきましょう。
無理に並べようとするのは逆にロスになるので、可能であればカゴの中に入れている時点でバーコードが全て見えている状態にしておくのがいいでしょう。
ホットスナックを頼む場合、商品をおいた時に同時に宣言するようにしましょう。
なるべく正確な商品名を伝えるのがポイントです。さらには、「普通の」からあげクン、のように、フレーバーの有無を判断できるように宣言することが重要です。
ここが最も神経を集中すべきところです。
店員に多少余裕があるようであれば、先手を打って下記フラグを消化しておきましょう。あるいは、２人レジの場合はピッピピッピが始まった直後でも良いでしょう。
「袋もお願いします／いらないです」
→いらないですの場合、買い物袋が別途ある場合は店員にチラッと見せておくことで、レジ打ちに集中していて聞き取れなかった場合でも察してくれます。
「ポイントカードは無いです」
→ポイントカードがある場合は、金額が出る前の時点からお金入れにカードを置いておきましょう。
→現金払いの時は不要なフラグですが、電子マネー出払う場合はちゃんと宣言しましょう。袋の時と同様に、カードを店員に見せておくことで察してくれます。
さらに、合計金額が客側にも見えるような表示がどこかにあるはずですのでそこを凝視し、合計金額がいくらになるか、出た瞬間に把握できるようにしましょう。
合計金額を確認した直後、ちょうどで払えるか否かを瞬時に判断します。
ちょうどで払える場合はその金額を出しましょう。この場合、お釣りをもらうフェーズをスキップできるので非常に好タイムを叩き出せます。
ちょうどの小銭がない場合、少し大きめの金額を大金のまま出しましょう。
ここで、５円５０円を作ろうと端数だけ合わせるのはあまりオススメできません。
店員の反応速度にもよりますが、一瞬躊躇されてしまう可能性がありますし、何円あるかを数えられてしまいます。これは大きなロスになります。
レジにお金を入れる際にも、大きい金額を ｽｯ と通すのは一瞬ですが、小銭をジャラジャラ入れるとレジの機械の処理で純粋に時間がかかってしまいます。
次のレジで好成績を残すぞ！という気持ちで、涙をのんで多めにお釣りをもらうようにしましょう。
レシートの上にお釣りをおいて渡すタイプの場合、「レシートは不要です」フラグを立てることが非常に難しいです。
明らかにそのモーション（左手にレシートを持ち、右手でお釣りを持った構え）になってしまった時点で、あきらめてレシートは受け取りましょう。
レシートとお釣りを別々に渡す場合、というか「レシートは不要です」に慣れている店員の場合、先にお釣りを渡そうとします。
その場合は、右手でお釣りだけを受け取りつつ、左手の手のひらを軽く相手に向け、「レシートは不要です」フラグを立てましょう。
なお、合計金額ちょうどで払えた場合や電子マネーで払う場合は上記のフローをすべて無視して「レシートは不要です」フラグを立てやすいので、余裕を持って好タイムを狙えます。
商品を素早く受け取り、なるべくスムーズに横にずれ、レジから立ち去りましょう。
弁当を温めてもらっている場合は単純な待ち時間になってしまうので、レジ横で待機するようにしましょう。
このフェーズでは必ずおさえないといけない大きなポイントがありますので、最後まで気を抜かず対応してください。
まず、商品を奪い取るようにしない。
レジ袋に入れてくれた場合、店員さんから手渡されるような形になりますが、あまり強く奪うようにするとすごく悪い印象になります。
「袋はいりません」「お釣りなし」「レシートもいりません」の場合など圧倒的好タイムでのクリアとなりますが、レジの処理が終わる（レシートが出てくる）までは決してレジ前からどいてはいけません。
最悪の場合、ちょっとしたトラブルになる可能性もありますので、レジ通されが完了するまでは落ち着きましょう。
－－
大まかなポイントは以上のとおりです。
お店や店員の癖によって対応も異なるので、場合によって最適な戦略を最適化していってください。
特に、コンビニなどではガチガチのマニュアルがあったりしますので、その流れを先読みするように客側から確認事項を宣言してあげると、好タイムを安定して出せるようになります。
とてつもなくスムーズに行った場合、凝縮した時間を店員を共有したことで謎の一体感が生まれます。
また、後ろに並んでいた人がちょっとびっくりしてたりして、ちょっとﾆﾔﾆﾔします。
ぜひ皆さんも楽しんでください。
街中で妊婦を見かけると、それがどんな女性だろうがハ淫セ(イチャラブ中田氏セックス)してる情景を勝手に想像してしまってとてもつらい気持ちになる。
中にはもちろん不妊の人もいるだろうし不満足なセックスライフを送っている女性もいるだろうけど、問題の本質はそこじゃない。
見目麗しさとは程遠いカップルが目の前でペッティングするよりキツい想像を勝手におっぱじめる脳のせいで本当に不愉快な気持ちになる。
正直とても困っている。
ちなみに小さい子供を連れてる女性を見たときは一割くらいの確率で「セックスだ！！」と思う。
病気なのかな。
---
臨月の妊婦となった今、上のようなことは起こらない。むしろ彼女らの苦労を忍んでしまう。我が身にふりかかる妊娠ゆえのトラブルが重かったのもある。しかし、当時の自分と根本的に異なるのは、セックスの有無は本質ではないと分かったからかもしれない。以下は自分語り。
当時の自分は、人生とセックスは切っても切り離せないものだった。欲望に忠実で、どうしても手に入れたいものが目の前にあるなら手段を厭わず行動していた。行動力の源泉としてブラックホールのようなものが自分の中にあり、自分の中の物足りなさや満たされなさを埋めたくて欲望のままに何もかもを吸い込んでいたと思う。今ならその正体が少しは分かる。生まれてから死ぬまで徹頭徹尾自分は孤独であること、ひとりうまれひとりしななくてはならないこと、不十分な自分の人格を誰かが代わりに育ててくれるということはなく自分が満足するような自分自身になるためには他でもない自分の努力や意思に基づく試行錯誤によってのみ実現すること。近道もズルも存在しないこと。これらが耐えがたい苦痛であるためにずっと目を背けた結果ブラックホールのようなものが誕生したのだった。
そのブラックホールに名前を付けるとすれば驕り、または臆病な自尊心かもしれない。私は妊娠で「底つき」を経験できて、きれいさっぱり驕りが解消されたので、よかったと思う。
重症妊娠悪阻で水も飲めず点滴を打たれて寝ているあいだだけが「人間」でいられた。
一人で外出はおろかシャワーさえ浴びられない。仕事はなくなった。なんのために生きているのか分からなくなった。
まともな食事ができるようになってからは、日中の静かな家に一人取り残されて、孤独感に苛まれ、頭がおかしくなっていくのが分かった。暇を解消しようとするも、体が動かず、情報に敏感で、ラジオすら聞き続けられない。寝ようとしても数分～数十分で起きてしまう。深夜に帰ってくる家族との会話が命を繋いでいた。
仕事もしない、家事もしない、寝ているだけ。今までの人生において、そんな「役立たず」や「穀潰し」になったことがなかった。いつも私は自分で自分を納得させる生きる上での口実があった。こんなにも満足のいかない生活は初めてだった。
初めて知る。「ただ生きているだけでもたいへん」ということを。
人間は生きているだけでもたいへんなので、ほかの要素が組み合わさったら当然カオス的に大変である。解析的に解けないし、適切な数値解にたどりつくには果てしないパラメータチューニングの試行錯誤が必要になる。そして苦心して解を得ても、誤差項を多いに含む。
元の記事に戻ると、人生をモデル化した時に性行為が欠かせないと思うから妊婦を見てセックスを連想するわけだよ。
今の私はもうそうは思わない。人生は存在それ自体が大変。大変であるというのが人生の本質。その大変さの各論は個人によりけりで、ひとによってはセックスが困難かもしれないし、暮らしが困難かもしれないし、自分の体が困難かもしれない。それは外見からは分からないことだよ。
ひとくちに妊婦といってもフェーズによってトラブルはコロコロかわる。
当初、腹の中に人間がいるのさえ自覚がないのに、そのために日に日に変化する自分の体がグロテスクで、第二次性徴への嫌悪感を思い出した。
今でも、腹の中に人間がもう一人いるというのには慣れないが、皮膚が突っ張って痛いほど膨れる腹への受け入れがたさは時とともに薄れていった。そのかわり、乳頭から滲み出る乳汁への嫌悪感は凄まじい。ひとつ解決すれば、別の問題が浮上するものである。
艱難辛苦汝を玉にす、とはよく言ったものだよ。妊娠を経験したおかげで、他人に向ける視線から邪な思いが少しは消えてよかった。
http://www.yukawanet.com/archives/5037350.html
とある知り合いの実家は福島で、両親も被災者であったと聞く。どの程度の被害を受けたかは知らないが自分たちよりもっと大きな被害を受けた人たちへの支援ボランティアをやるようになった。
ボランティア仕事の一つに各地から送られてくる食料の分配作業がある。ありがたいことに日本各地だけでなく外国からも食料が送られてくるのだという。
震災から1年も経ってしまえば、暮らしに不自由は残れども本格的に食事に困る人などはもういなくなる。そうするといわゆる非常食みたいなものにはもう飽きてくる。生きるか死ぬかの時期を超えた被災者のQOLを考えれば「食えるだけマシだと思え！」とは言えない。気持ちはよくわかる。
そういうフェーズになるとあまりにおいしくなさそうなものやよくわからないものは敬遠され始める。
ボランティアをしていた知人の両親が配布していた食料の中にも、東南アジアから来た何を煮たものかよくわからない缶詰や、イタリア語の説明しか書いてない粉末パスタソース、オリーブベース？と思わしきフランス語表記のブイヨンなどが沢山残っていた。上手に使えばおいしい食べ物でも、使い方がよくわからないというだけで誰も手をつけなくなってしまうわけだ。
せっかくの支援物資を捨てるわけにもいかず、結局賞味期限が切れるまで保管され、その後は私のような知り合いが引き受けた。
食べ物でさえ場合によっては邪魔になるというのに、流通が混乱を極め保管場所にも困る被災地に千羽鶴を送ろうなんてのは迷惑でしかないと部外者の私でもわかる。
気持ちがこもってそうなモノだけに、ジャマでも捨てることもできなくなり大きなお荷物と化すケースも多々あるだろう。
気持ちを送りたいとか言ってる人はとりあえず100円でも1000円でも金を送ればいいのに。
被災地を助けたい気持ちや、実際に何かをする時間や、かけられるお金に個人差はあるけれど、せっかくなのだから迷惑はかけない程度に勉強してから動いたらいいと思う。さもないと偽善どころかやらない方がマシになってしまう。
「富士通を退職した話」を読んで、20年近く努めている側からの感想と疑問について書いてみたいと思います。
私も、情報科学を大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空の工場に勤務してメインフレーム関連の仕事をしていました。
その工場に配属される新人は（希望すれば）寮に入るわけですが、高専卒は工場の敷地内にある山頂の寮で二人部屋、学士卒は山の５合目にあるアパートの一人部屋、修士とドクターは街中にあるマンションという感じでした。
街中の下界から工場がある天上界への通勤はバスで移動することになるのですが、わたしは、バスのディーゼルエンジンの排気ガスが苦手なので、頼み込んで工場の敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが２人で一部屋なのですが、学歴の関係か私は一人で２人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。
わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。
２０年前でさえ、メインフレームは古いというイメージがありました。
ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。
そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか？くらいな感じでむしろラッキーくらいに考えていました。
最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく２位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。
ただ、せっかくメインフレームの部署に来たのですが、私の担当はワークステーションで動作するUNIXやPCでの開発が主体でした。
そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXやPCに詳しくなかったので、大学でUNIXやPCを経験した新人が入ってきたことは非常に重宝されました。
その部署では開発言語は、社内の独自の言語（Cよりもさらに機械語に近い言語をマウスでグラフィカルに操作してコーディングする言語）を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションやPC用にも
その言語コンパイラはあり、あわやその言語でUNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分の意見を通しました。当時はJavaやRubyなどの言語は無くCが全盛でしたが、
その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語の勉強会を開くことを提案し私が講師になってC言語をメンバーに習得してもらい、
PCやUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。
元の増田の方は、自分はエクセルのVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか？
元のEXCELを使った業務が非効率であるならば、業務の改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。
忙しい部署にも、改善活動のノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。
下請けのプログラマーからみると富士通のような会社は中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。
私は、富士通本社のSE的な立場、グループ孫会社に出向して、そこから顧客先に派遣される４次受け５次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。
客商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。
私見ている範囲では違う部署に異動したいという希望は100％通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。
もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界のプロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。
もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。
なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン２、バージョン３あるいはメンテナンスのフェーズに入ればそんなに大量の人員は必要がないので、会社としてもその部署の人員を異動させたいわけです。
けれど、プロジェクトで中核の技術を担っているようなメンバー、マイホームを天上界に立ててしまったメンバー、新しい仕事に対応しにくい高齢のメンバーは異動させにくいので、
EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。
もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います。
ただし、異動先の都合もありますので、ここから出たいはほぼ１００％通りますが、あそこに行きたいは必ずしも通りません。
今更「京」のスーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。
色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部と営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。
新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります。
「おおざっぱにはっきりと希望を言うこと」です。
いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。
人事の人は技術には詳しくないですから、研究内容が最先端であればあるほど、人事の人には通じないです。
キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな？だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまいます。
それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。
例えば、
上記のことを強い口調ではっきりというのが良いと思います。
そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります。
私の同期で入社して新人研修で山奥に配属されたバブル時代の末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。
件の互助会言い訳ブログを読んだ時の気持ち悪さがようやく自分の中でまとまった。
「包丁が売っていた。元々の目的とかみんなが何に使っているとかわからないけれどこれで人を刺したら殺せると思ったのでみんなで包丁を買って人を殺しまくっています」と。
こういうと「極論ダー」というアホが湧くのでもう一つだけマイルドな例を書くと、例えばビーチでの水着はOKだ。ビーチから細い県道を渡ったコンビニも水着入店はOKだろう。さすがに駅前の飲食店はTシャツを着てサンダルを履いて入店するものだし、同じ駅前とは言え老舗の海鮮丼屋にはいくらTシャツを着てても湿った水着や砂まみれの浮き輪を持っては入れない。そんなビーチリゾート都市にやっていて「オラ、コンビニは水着でOKやろ？そこの店はTシャツ着てればええ言うたで。海鮮問屋はんも文句ありまへんわなあ」と謎の関西っぽい言葉で攻め立ててるようなもんですよ。
しかもまあ恥ずかしげもなく被害者ぶったブログ書いてまったく知性とか品性とかないのでしょうかね。
「お前ら互助会が仕組みを悪用して適当やりくさるからこちらは迷惑してますよ。仕組みとして可能だからと言って何でもやっていい訳じゃないし、それを排除するために規制を強化するのも手間だし既存住人にもとばっちりが行くんです」と教えてあげたいがああいう面の皮の厚いおバカさんにはわからないのだろう。
はてブも、芸人の有吉の言葉とされる「バカに発見された」フェーズに入ってしまったのでしょう。残念だけどそういうことなのだと思うことにする。
ビジネスモデルの違いが大きいよね。
サービス開発は、沢山の人にプログラムを使い続けてもらうことで収益を上げるモデル。
SI開発は、作ったプログラムで業務効率化をはかり人件費を節約して収益を上げるモデル。
なので
サービス開発は、利用者が魅力を感じるために改善し続ける必要があり、継続投資に意味がある。
UIの改善、パフォーマンスの改善、接続数のスケール、セキュリティ、他社サービスとの接続、各種デバイスへの対応などなど。
早くローンチが重要な場合もあるので、まずベータで出してブラッシュアップさせてVer1.0を目指すことも可能。
受注業務で１０人が電話やFAX応対してたのをWeb化、自動化して３人で回せるようにする。
営業が残業して顧客情報をExcelで管理してたのを一元化して残業代を削減する。
とかとか。
なので開発予算が最初に決まるし、継続的に高いお金をかけて改善していく意味もほとんどない。
（システム導入時のようなコストインパクトを改善では出すのが難しい）
素敵なUIにする必要はないし、少しくらい応答が遅くても問題ない。「運用でカバー」だ。
オーダーメイドなので開発費は高くなる上に
継続的に改善しないので、導入時点でVer1.0どころか、2.0、3.0 の機能を求められる場合もある。
そりゃ保守的になる。
枯れた技術・設計がいいし、少しでも安いエンジニアを使いたくなる。
設計の手戻りは許されないので、顧客との調整力、フェーズごとに仕切れる段取り力、「ここまでしかやらない」と言える交渉力
決められた作業を決められた期間に決められたコストで実行するマネジメントが重要になる。
プログラムは自社フレームワーク化して、コーディングをパターン化していくこと。
新規サービス開発で求められるような技術力は基本的に不要だし、技術動向は一部のR＆D部門の数名が研究していればOKな世界。
マイナンバーやeTax関連でも、クラウドサービス化して「利用者が増えれば収益が上がるモデル」になってるところは
高い技術力の人がいて頑張ってるんじゃないですかね〜
すごく良いこと書いてあったのですが参考にしようとしたらサイトが消えいたので、魚拓から転載。
働・学・遊・美をミックスしましょう
計画は役に立たないが、計画することは不可欠だ。
by ドワイト・D・アイゼンハワー（第34代アメリカ大統領）
人を最もダメにするのは「全体像」を見せずに「部分的なこと」をずっとさせること。
これ続けてると何も考える力のない指示待ち人間ができあがる。こわいこわい。
by 外尾悦郎（スペイン、バルセロナのサグラダ・ファミリア主任彫刻家）
腹が立ったら自分にあたれ、悔しかったら自分を磨け。
神は細部に宿る。
by ミース・ファン・デル・ローエ （建築家）
放っておくと会議の時間の九十五％は「コメントの交換」に使われている。
by 「ケッヘル」（中山可穂）
重要なことは、正しいか、間違いかではない。うまくいくか、いかないかです。
マネジメントとは、そのようなものです。
by ピーター・F・ドラッカー（マネジメントの神様）
やってみせ 言って聞かせて させてみて ほめてやらねば 人は動かじ
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
やっている、姿を感謝で見守って、信頼せねば、人は実らず
あなたに幸運の女神が微笑んだのであれば、プロジェクトは無事に完了し、幸せになれます。とてもとても幸せになれます。多くの人々は、自分では何の失敗もしていないのに、ここまで到達することができないのです。豪勢な夜を計画してください。どんちゃん騒ぎをして散財してください。そして、その時のことをいつまでも語り継げるようにしてください。
by 「アート・オブ・プロジェクトマネジメント」
この５０人時間の差が大規模で長期間のプロジェクトの場合に大差を生む。
２０人のチームの場合。
この４人分の差が大規模で長期間のプロジェクトの場合に大差を生む。
ミーティングと同じようにコストを意識する。読む人の時間をムダに奪ってはいけない。
反省会は、社内グループウェアのメッセージ機能を使って、こんな感じでやってます。
ファイアープロジェクトに助っ人参戦した場合にどうするか。原因のほとんどはマネジメントもしくはコミュニケーション。
２０人程度のチームならこれらを１～２日で終わらせて雰囲気を一新する。あとはふつーのマネジメントへ。
→これは全然OKだよね。これが文句言われる筋合いはさすがにない。
※増田に書かれた「日本死ね」を当の増田に確認せずTVや国会で読み上げる
→これが変なことになってる。
「死ね」という表現が一定の反発を招くことは異論はないと思う。
いくら上場したとはいえネットの片隅はてな村増田部落なら、それは反発されようが無視しやすいレベル。
その反発はほんとうに全部増田に向くべき？
本当なら、TVや国会議員が受け止めなきゃいけない反発が今増田に向かってない？
匿名だからって勝手に当人が想定していないステージに引き上げられて多大な反発を発生させていいのか？ってのは、考えなきゃいかんと
津川雅彦の件を見て思った。
何事も斜に構えてモノを見るようになったのは、自信と夢が無くなったのが原因かも知れない。
目標だけがピシッと残ると、それはそれでただのレベル上げになり、味気ないもんである。
人生をざっくり前と後に分けて、前は「ガムシャラ期」後は「安定期」としよう。
まず、ガムシャラ期は、人生の意味や自分の夢についてゴリゴリに考えて、ガムシャラに行動する。
これは、人によって長さは違う。
ガムシャラに事を進めていると、たくさんの壁にぶち当たる。これをひたすら壊す事に心血を注ぐ。
燃え尽きるか否か。エネルギーの個人差によって期間はそれぞれ異なる。
その中で、分かりやすい「夢」を叶えるのは、このガムシャラ期に事を成した人達だ。
夢とは、余計な打算を抜いた力技で掴み取るものだ。。。と個人的には思う。
その夢には大小がある。
宇宙飛行士、経営者、代議士。。。のようなものから、「絵に描いたような学生生活を送りたい」というものまで。
夢はフーセンみたいなもので。。。
1.しぼんでくると、無くなる事もある。
2.もしくは、大小に関わらず、夢を掴む。
このどちらかの条件を満たすと、人生のフェーズが、ガムシャラ期が安定期に変わる。
安定期については、以下のような事に意味を強く感じるようになる。
人を育てる、後世に何かを残す、自分の手の届く領域を守る…など。。。
ガムシャラ期に感じたもの、手に入れたもの、手に入らなかったもの、その分析…など、夢に向けたホニャララの全部を活かした人生がまた始まる。
つまり、夢とは人生の本題であるが、無くなった所でその後には目標が残る……
という持論です。全然違うと思う人もいるやろうけど。
◼︎悩む
優先順位をつけて、また先達者の意見を参考にしたりして、着実にクリアすることが望まれる。
きちんと悩みや自分自身と向き合うといいことがたくさんある。
◼︎悲しむ
心を傷めること。つらいことだが大事。
涙の数だけ強くなれるよ、ではないが、傷ついた分、他者に対して同情の心や寛容さを持てるようになる。
ただ、あまりに悲しみに意識をやりすぎると、なぜ自分ばかり？と自己中心的な考えになることも。
余裕があるときは噛み締め、余裕がないときはやりすごしたりまぎらわせたりするべし。
どんな悲しみも前向きになればいつかは癒える。
◼︎落ち込む
すみやかに終わらせるべきこと。
落胆は自信喪失につながる。自信喪失すると人はたいてい緊張して自由に動けなくなる。
落ち込んだあとは、「自分はだめなやつだ」ではなく「どうしたらよかったんだろう？」と悩むフェーズに持っていくといい。
(ものごとがうまくいかないのは、自己の能力以外にも、環境・タイミング・相手の考え方との相性などの複数要因も絡む)
落ち込みすぎると、鬱になったり、下手すると周囲への怒りが産まれ攻撃的になる。そうなる前に対処。
◼︎不安になる
悩むと混同されがちだが全く違う。できるかぎり避けること。
悩むは現実の問題に対するものだが、不安は現実にはない架空の問題に対するもの。
わからないこと、しっかり見えないものなどへの負の感情はいくらでも増えてしまう。
こういった感情につけこむ商法に踊らされたり、悪い宗教にハマったりするのを避けるためにも、不安は目に見える形に落とし込むことが大切。
(例:私の年収少なすぎかも…とりあえず高収入と結婚しなきゃ！→いくらあれば自分はやってけるのか計算)
(例:セックスレスすぎてつらい浮気しそう！してもいいよね！→なぜ拒否するのか相手ときちんと話す)
ポジティブでもネガティブでもかまわないけど、大切なのは冷静さと、自責しないでしっかり考えること。
あと煮詰まったらちゃんとゲームやマンガやお風呂やスポーツでスキッとすること。
うん。そいでだいたいは大丈夫だよ。
