2007年
プロジェクト
保険窓口の事務効率化、共通化のためのシステムを作るPJに配属される。
同じような画面が100くらいあるので、画面（手続き）のパターンを分析し、フォーマット化し、EXCELに文言や遷移先を入力するとVBA経由でソースを吐き出すようなことをやっていた。
お客さんにEXCELをメンテナンスしてもらって保守よろしくってやりたい感じ。（結果的にこっちでほぼやっていた気がするけど）
トレーナー
会社の制度的に入社して2年間はトレーナーと言われる大先輩について学ぶことになっている。
めちゃくちゃ年が離れていたのと、手取り足取りな人じゃなかったので同期からは「大丈夫なの？」的な感じで見られていたように思うけど、自分的には失敗しても大丈夫な柵を用意してもらって自由にやれていたので性格にもあっていてよかったと思う。
体制
こんな感じの人々がいた。
- 優秀な古参のBPさん1人(開発する上での実質的なトレーナーみたいな人）
- 優秀な新規のBPさん2人
- 後にいなくなる微妙なBPさん1人
- 中国から来ている、よく「チェッ」って舌打ちする（イラついてとかじゃなく癖だと思う）BPさん
- 韓国から来ているVBA開発担当のBPさん's（時期によって増減、金さん多し）
やっていたこと
入った頃プロジェクトは基本設計工程でオーナーレビュー用の資料を印刷して揃えまくった記憶がある。
あとは、入ってすぐの新人にも関わらず「開発品質計画書」という、まぁプロジェクト計画書みたいなものを作らせてもらった。
なんのために作るものなのかを考え、どんな目次が必要で、どのように使うのかなどを考えた。
中身に書くべき内容はわからなかったので参考にした別PJの物をみたり、トレーナーに聞いたりして完成。
その他
手順書作成プロジェクトについて
所属プロジェクトとは別に、新人向けに部内で「なんかさせて育成しよう」みたいないい加減な仕組みがあってそれでやらされたプロジェクト。
プリンタの設定とかドメイン加入の設定とかPCの設定とかいろいろ。そういうのが点在していたのとバージョンがバラバラなのと不明な情報などがあるなど、問題が色々あってそれをどうにかせよということだ。
私は作成する手順書の範囲、体制、期間、フォーマット、調査方法、作業タスクの洗い出し、スケジュール化、進捗報告の方法や頻度などを決めてプロジェクトを開始した。
一部抜粋はこんな感じ。今見るとちょっとあれ。
余談だけど、一緒にやってた同期が年明けたら会社に来ておらずそのまま辞めたとの話をあとで聞いた。検証物の検証観点にひたすらオートシェイプで赤枠をつける仕事やらされたら俺も辞めてたと思う。
不思議だったこと
- 敬称が「殿」だった。（宮崎殿、みたいな感じ）
- 曖昧な状況の中、なんとなくで仕事している人が多い。
なんとなくで仕事をしている人
「後にいなくなるBPさん」とかがその顕著な例だった。
「時間を守らない（会議）」とか「目的を定義しない」とか「誰がやるかを決めない」とかそんな感じ。
当時それが嫌すぎて、「若手の提言」みたいな場で「目的と役割の明確化」みたいな題で発表したくらい。
その反動でか上記の「手順書作成プロジェクト」などでも分かる通り、計画をきっちりやる人になってしまった。
その他品質に対する考え方も適当な人が多かった。（適当という言葉が適切でなければ、人力で、努力でどうにかする、みたいなイメージ）
逆に私は作業項目の漏れがないか、ドキュメント間の入出力関係、関連性を確認しているか、手作業ではなく以下に作業品質を担保する施策を講じたか、などを気にするようになった。
当時アジャイルが身近にあったらまた違った感じだったろうと思う。
2008年-2009年
プロジェクト
前のプロジェクトの保守フェーズ。
画面の追加や、変更対応（法律が変わって手続きや文言を変えなければならないとか）を実施。
あとは、窓口事務のシステムから、他システム（契約の照会とか申込みとか）への連携とかの対応。
体制
PM的な人と後輩のプロパが増えた。
BPさんはコアの数人を残してほぼいなくなった。10人弱くらいだったような。
エピソード
あまり記憶がない。
結合テストでの遅延、システムテストでバグがでて根本原因分析をして偉い人がいる場で報告をしたとか。
サイロ化というのか、縦割り文化というのか、どこもそうだと思うんだけどみんな自分たちのことしかあんまり考えてなかった。結合テストの遅延は自分たちの作業に必要なリソースが他グループから来なかったことが原因だった気がする。
定例会とかで情報共有してるはずなんだけど、「あ、その部品その時期に必要なの？」みたいな感じで言われたり。誰が悪いとかじゃなくて双方を知ってる人が必要だよねってことを思った。
それで、人がやらなそうな間に落ちていきそうなこと（アプリと基盤、顧客とベンダ、デザイナとプログラマ、先行開発と展開、開発と運用など）をやるようになっていった。
あんまり記憶がないと言いつつ、結構大きな転機かもしれない。
この辺から、スペシャリストよりジェネラリスト（もしくはコミュニケータ）みたいなキャリアを積むようになった気がする。
プライベートでは会社の寮（桜木町）をでなければいけなくなったので武蔵小杉に住もうと思ってほぼ武蔵中原に住んでしまった。
他には絶対に行かないと言っていた海外になぜか行きたくなり一人でオーストラリアに行き、カンボジアのマラソンを走り、マレーシアに植林に行った。
余談だけどこの頃はまだmixiをやっていたみたいで、今確認してみたら死にたくなった。黒歴史感半端ない。
2010年-2011年
プロジェクト
車系保険が終わる頃に「もうそろそろ終わるんでこの人に継続するようにアプローチすべし」ってのが分かるシステムを作るプロジェクト。すでに出来上がっているものを保守、追加機能開発をする感じだった。
並行して前までのプロジェクト（保険窓口の支援システム）の保守もやる。
体制
多分PMがいたような気がする。兼務だったのかな？
あとプロパの後輩が数人。
やっていたこと
検索して一覧を出す系のシステムだったのでsqlなんかを結構やった。インデックスどこにはるとか。ほんとほぼ覚えてないけどある特定の検索でめっちゃ遅いレスポンスを劇的に改善した記憶がある。なんだったかな。データの持ち方を変えたんだったか、一時表作ったのか、SQLいじったのか、全部か。まぁそんなところ。
検索項目の追加なんかもやった気がする。
帳票もやった。iWFM。
バッチも。バッチはshellの設計書がなぜかなかったのと、運用ツール(JP1)の設計書がどれが正しい最新かわからないって引き継ぎで言われてBPさんがいなくなったので動いている資産から仕様を起こした気がする。
マネジメント関連は契約、調達以外のことは結構自分がやっていた気がする。計画、スコープ、スケジュール、品質計画・レビュー、作業見積もり、会議体設定・進捗報告。
工程が終わった時やリリースするときに「なぜ次工程に進む（リリースする）ことができるのか？」を説明する会があって、これがあまり好きじゃなかった。
記憶ではほぼ一回で通ってたと思う。
けど資料を作るのにかなり時間がかかる。データを集めるのも大変。普段から集めとけよっては思うけど。
だけど、好きじゃなかった一番の理由はこれじゃない。一番の理由は「なんかもっと他にあるだろう」って言われることだった。
私の報告はいつだって「当たり前のことを当たり前にやって当たり前に品質確保できてます。リスクや課題はあっるけど対処してます」という感じだった。
そうすると聞く側（承認する側）は「いや、他に何かないの？」ってくる。または「この部分（細かい正直どうでもいいところ）は？」ってくる。そう、聞く側は何も言わないで「よしわかった、いいんじゃない」とは言えないのだ。
これが出ると「条件付き完了」みたいなステータスになって宿題がでてやらないといけなくなる。面倒臭い。
まだ経験も少なく、もっと広い視点でリスクを考えてみろって意味もあったとは思う。けどどうでもいい細かいところを指摘して多大な工数をかけてやり直したり調べたりさせるのはやめて欲しかった。こっちだって暇ではない。（そしてこれで見つかったバグなんか一件もなかった）
品質問題／遅延
「当たり前のことを当たり前に」と書いておいてなんだが、それができなかったことがある。2011年の方だ。
この頃は「プロジェクト」には書いていない別のシステムも保守しており、自分が開発を担当できない状況だった。
なので、軽微な変更をお任せしたかったので、バッチとオンラインと帳票とDBとができて（今考えると大したことないな。。）って人を探していた。もちろん引き継ぎ期間ありで。
ところが大人の事情でとある会社に発注することが決まってしまった。スキルシート的なものや経験を見るとかなり不安が残る感じ。
案の定全然ダメ。引き継ぎをしても全然わかっていない。
請負契約だったので会社に是正してもらうように掛け合うもあまり改善せずに、どこかの工程で大きなミスをやらかして赤字覚悟で+2名を追加するもそれでも改善せず。みたいな。（+2名はおじさんで、会社では偉い人で、開発者ではなかった）
そうこうしているうちに、最初からいた人が長残業しすぎて体調を崩してフェードアウト。
これ、どう解決したかあんまり覚えてないけど確か自分が稼働をあげて開発に入って全部やり直した気がする。
それで最後にここの人に言われたのが「こんな扱いを（こんな若造に）されたのは初めてだ」だった。まぁ難しいよねぇ。
その他
応用情報を取得した。
ITストラテジストは午後の論文で落ちた。というか鉛筆で論文を書くのが面倒臭すぎて最後まで書かずに終わったのでそこで採点対象外（C？）になった気がする。
論文
論文を書いた。
「脳と脳をつなぐことによって自己実現のための機会を提供するモデル提言」というタイトルだ。
何を言っているんだろう？中身を読み返したが文章力が未熟すぎ（未だにだけど）てわかりにくい。
「学んだことを実際に試したり、使いたいときにすぐ使えなかったり、次は何を学べば良いかわからない」という人向けに、
「日々の情報を収集し、いつでも引き出し可能な形でサマり、ネットワーク化する」ことで
「いらんことは覚えなくていいのでクリエイティブになれるし、似た傾向なのか補完しあえる人とマッチングすることで新しい価値を生み出せるようになるよ」
みたいなことを言っているっぽいです。今ならやれそうだしやってるところありそう。
そう言えばこれもIoTっていう概念がないときにそういう感じでセンシングしたいって思ってたし、サマるところもパーソナルデータだよね。（どう利用するか考えないと難しそうだけど）
そう言えば入社してすぐに「カメラ越しに家具を仮想敵に配置して寸法やイメージを確認する」というアイデアをだしたら「そんなもんできるかボケ」って感じでボツった。
「思っているだけ」ではダメで「行動する」ことに意味がある、ってよくいうんだけど、それはこういう経験から来た言葉。
2012年
プロジェクト
前年までの「もうそろそろ終わるんでこの人に継続するようにアプローチすべし」システムの次、「こんな感じの契約にしたらどうですか？」っていう提案システムの構築。
外部のデザイナに入ってもらってUXを考慮した画面レイアウト案がすでにできていて、それの調整（実装から見たものと、業務から見たものと）から入った。
例に漏れず前までのシステムの保守も行う。
また、ここのお客さんのフロントはとある特殊なスクリプト言語で作ってるんだけど、今回はAdobe Airで作るという、かなりレアな状況だった。そして「もうそろそろ終わるんでこの人に継続するようにアプローチすべし」システムもAir化することになった。
体制
10人くらい。
やってたこと
プロジェクト全体のマネジメント。
そして「もうそろそろ終わるんでこの人に継続するようにアプローチすべし」システムのAir化の実装。
マネジメントの方は普通に淡々と。
Air化の実装はこれも本当はやる予定じゃなかったんだけど、年末前くらいに実装があまりに進まなくて、設計もイケてなくて（同じ見た目なのに違う部品を使ってるとか、イベントドリブンじゃなくてグローバル変数使って動きを制御してるとかそういう感じの）これはもう、年を越せないなとなり、結局自分で全部実装し直した。
27時くらいまで実装して帰ったり、新年もずっとコーディングしていた。楽しかったなぁ。
2013年(-2014年)
プロジェクト
保険を売り歩く人が持っているタブレット端末に入るシステムの新規開発。ライフプランを入力して保証金額を試算したりそういう。
体制
時期によって違うけどMax120人くらい。
PMがいて、PMOがいて、各チームがいて。
自分は先行開発するチームのリーダー。もう一つは先行開発の結果を受けて大量に作る（それと先行開発のインプットになる業務を分析する）チーム。
やってたこと
外部デザイナとの仕様・アセットのやりとり。
この仕様とアセットのやりとりがめっちゃ苦労した。出した仕様通りに変更されてなくて「あ、忘れてました、次回持ってきます」とかもらうアセットがちょくちょくデグレードしているとか。バージョン管理という概念がなかったんだろうか。いろんなやりとりをして、最終的に「受け入れ時に人力で全て確認する」に落ち着いた気がする。もう任せてられない的な。
先行開発の管理。先行開発結果の展開。
方式を定義し、フレームワーク化して、部品作って、こんな感じで作ってねって展開する感じ。このお客さんが初めての人だらけなので業務的なこととか、システムの基本とかも勉強会的によくやった。
先行開発した後は元々どうしようとしてたのか忘れたけど、もう一つのチームの方がうまくいかなかったのでそっちのテコ入れみたいなのをやった。PMの真下にいるよくわからないポジション。
みんな、「画面遷移がわからない」とかってレベルだったので、代表的なパターンを洗い出して、画面を印刷して、壁一面に貼り付けて、みんなでディスカッションできるようにしたりした。
業務ごとに発注している会社が違い、それぞれ個別最適でやっていてスケジュールが全然あっていなかった（合わせようともしていなかった）ので、全員を集めて一つのスケジュールを作った。この時TOCのエヴァンジェリストをやっていたのでこの時作ったスケジュールはCCPMのスケジュールだ。
開発する人たちからは、私の耳には特に不満は聞こえてきていなかった。うまくやれていたと思う。
逆にPMやPMOからはめちゃくちゃ反対された。
PMは下（私）からと上（課長、お客さん）からの板挟みで辛かったのか、戦略的撤退なのか、会社に来なくなった。
PMOとの関係は最悪だった気がする。もう、何を言っても聞いてもらえない。
で、あんまり覚えてないけどなんだかんだで課題は残りつつも落ち着いた頃に異動の希望を出しただったかでフェードアウトした。
訂正：結合テストあたりで顧客への進捗報告がやりずらすぎる（CCPMだといつまでにできます、と細かいところを言いにくい）と言う問題（という名目？）で従来の管理手法に戻って、体制的にもテスト支援的なことをやる人になった。
で、そんな中、上記の通り TOCによるマネジメント変革を本気でやりたかったのでそこに行きたいと言う希望をだしていた。
結局異動できたのは2015年1月からで、2014年はまた別のPJ(契約の申込みをするシステムの新規開発で70人ぐらいいるPJ）で似たようなことをして、並行してTOCの活動をしてって感じだった。
この辺で思っていたこと [論理的に正しい≠正しい][私の正しい≠正しい]
この頃じゃないけどちょっと前に「ロボットと話しているみたい」と言われたことがある。もっと具体的な言葉では「あなたは自分の中の正解があって、確かにそれは正しいのかもしれないけど、そこにたどり着くように質問の形を取っているだけで、詰問されているようで辛い」と言われた。
この頃もPMやPMOと会話するときには感情よりロジックを優先していた。
そしてこれは今でも思い出すと胸が締め付けられるのだけれども、色々教えてもらった、大切な仲間でもあり大先輩でもある一人の友人を失くしてしまった。大勢の場でその友人のメンツを潰すようなことをしてしまったのだ。その友人にとあるレクチャーをお任せしたのだが、大勢の前で話すのが得意ではなかったのであろう、うまく話せなくて、途中で自分が説明を引き取ってしまった。自分の中では「短時間で分かりやすく簡潔に説明する」が正しさだったのだが、その場での対応としては最悪のものだった。
まずはこういう傾向があることを理解した。
そして意識をすることによって相手側に気持ちを向けられるようにもなった気がする。
ただ、やはり自分に優位性がある（知識や経験や論理的正しさなどがあると思っている）時で気を抜いているとこの傾向はすぐに頭をもたげてくる。つまり「相手の気持ちに配慮しないストレートな言葉を投げかける」ということだ。
これは自分のいい面でもある（場の空気に流されずに意見を言う）のだが、それで傷つく人がいないかどうかを一呼吸置くよう心がけたい。
人に任せる、失敗するということ
当時、本当の意味で人に任せると言うことができていなかったように思う。
つまり、「成功しそうならそのまま」「失敗しそうなら取り上げる」パターン。
些細な自分基準でのできていないことが気になって、それが重なると介入してしまっていた。
ここまでは任せる、みたいなラインを決めて、そこまでは自由に（放置ではなくて）みたいなことをするともっと人が育ったのではないかと思う。
↓気をぬくとほんとこんなことを思っていたりするので（相手には相手の理論と事情があるはずだと言うことを忘れる）、うまくやっていかなければ。
高い目標に向かって努力するのが当然だと思っているので、他人にも目標達成を求めますが、どれぐらい苦労するかなどお構いなしで自分の基準で判断します（そもそも他人に期待しない事もある）
