後輩SEとの勉強会（2019/01/09）設計思想と方向性、使えそうな知識体系、スキルと資質について
久しぶりに後輩SEと話す。
彼は今組み込み系のパッケージソフトを使う業務に参加しているとのこと。それで悩みなのが、パッケージのできること・できないことは開発ガイドを読んで一通り分かったものの、「こういうのできない？」と聞かれたときに「できる」、「できない」という返事以上に踏み込んだ話ができないとのこと。
どういうことか聞いてみると体系化や設計思想などが腑に落ちていないみたい。こういう設計思想のパッケージだからこういうことをしようとするとめんどくさくなるとか、そういった話ができるようになりたいらしい。これって、なにか良いショートカットないだろうか、、、。複数のパッケージを比較してそれぞれの製品が推している特長から設計思想が見えてくるのでは？とちょっと思った。これが横並びでの体系の把握とすれば、時系列での変遷というのがわかるとまた良いのかも。現場にベテランがいるらしいので、もしかするとパッケージ以前の開発についても話が聞けるかもしれない。そうすると、過去のどういう課題を解決するためにこのパッケージが出てきたかがわかる。
たとえばモジュール化することで疎結合な仕組みを実現した、ということであれば密結合な作りは望ましくないことが分かる。
次に、今の現場では１つに集中しすぎだと怒られることが多いとか。代わりに求められるのが大局的な視点。おそらく現在のチームでは大枠をだれも提示しないまま、役割を増やされていて、慣れることを求められている。これはちょっと効率が悪いように思う。もしかするとあるのかもしれないが、作業の関連が結びついていないのかも。PMBOK やITILだとドキュメントや手順が決まってていいよ、という話をした。
今思えば、業務プロセス設計について話をした方がピンときたかも。成果物から、業務と業務からのアウトプット・業務へのインプットとなるドキュメントをざっくりでも整頓すると全体像や前後関係が把握できるかも。
それで、ITILについて紹介。沢渡あまねさんがITILを業務改善に応用した本を出していてなかなかよさそうだったので。
あとは、PMBOKのちょっとした紹介と、PMBOKのブログで勇気づけられた話を紹介。プロジェクトマネージャーとかを個人の資質と考えてしまいがちだけど、知識＋スキルと考えればある程度のレベルまでは資質がなくてもできるのではという話。ぼくがどちらかというと視野が狭く、まんべんなく調整できるタイプではないので、PMBOKを身に着ければある程度はプロジェクトの推進ができるという話を聞いて、勇気づけられたという話をしました。詳しい話はこのブログ参照。
